After reading the docs and a few other tutorials, I can't seem to determine what the flow is for a User that has just been Authenticated w/ an external service (such as Auth0).
Once a NEW user has been auth'ed with Auth0 for the first time, and the client passes the JWT for know to decode and verify, what is the proper way of handling this new user?
self.from_token_request to then find the user like so: self.find_by email: email; but if this is a new user, should we instead be calling self.find_or_create_by: email?馃憤 I have been trying to figure out this same exact issue for the past day. This is actually not just a question amongst rails application but for Auth0 / API design as a whole. Really interested to hear not only what the @nsarno has to say about this but also what the Auth0 team has to say about this as well. For some reason I'm having a hard time giving them an @mention here...
Agreed; I'm working through the same workflow myself and am stuck. In the case where, say, a single-page app client registers a new user with Auth0, I can expose a POST endpoint for it to hit with the JWT in the authorization header, but that's where things get confusing.
As it stands there are only two outcomes from analyzing the token in the auth header:
I think there needs to be the availability of a callback, which is passed the claims, that applications can provide in order to handle another case:
This presents the opportunity to create a local User record from the information in the JWT.
From there, the docs say to use self.from_token_request to then find the user like so:
self.find_by email: email; but if this is a new user, should we instead be calling self.find_or_create_by: email?
@jegodwin Yes.
- Web token is valid, but we don't have a matching user in the database
This presents the opportunity to create a local User record from the information in the JWT.
@whazzmaster Yes.
Basically it's up to you to implement User.from_token_request in a way that matches your authentication flow. In this case, using find_or_create_by sounds perfectly reasonable.
Hope this makes sense.
Most helpful comment
Agreed; I'm working through the same workflow myself and am stuck. In the case where, say, a single-page app client registers a new user with Auth0, I can expose a POST endpoint for it to hit with the JWT in the authorization header, but that's where things get confusing.
As it stands there are only two outcomes from analyzing the token in the auth header:
I think there needs to be the availability of a callback, which is passed the claims, that applications can provide in order to handle another case:
This presents the opportunity to create a local User record from the information in the JWT.