I’ve been following this example of a mobile + api flow for PKCE-supported authentication.
One thing that seems to be lacking there is the case where you want to create users in your own database based on the returned data of the id token of say a facebook authentication request.
I’ve been contemplating this and I was considering connecting to my api through auth0 itself, with a rule, much like Hasura does. That way you just call the authorization service and this in turn upserts the user in your database as well, so the mobile app doesn’t have to call your create-user endpoint after you received the access token and refresh token.
The other option would be the opposite. You get back the access token, id token and refresh token and you call your own api with the id token so it can decode it serverside and create a new user if necessary.
I don’t know what the best practice is here and how most people do it?
I can’t speak for everyone but I believe, if you are using Facebook login, you should not be creating users in your own database for those Facebook login users. The point (or at least one point) of using a social or enterprise login connection is to leave user account management to that 3rd party.
Why are you creating user accounts in your local DB? What problem are you trying to solve?
Because that would mean I am entirely dependent on that third party for anything related to users and their relations. I am using an rails backend and I feel it would be better to have a user representation in my own database. Also, I feel that would be a better solution when dealing with different ways of authenticating. But I am new to all this, so any suggestions are welcome!
Ok, I think I understand, but correct me if I a wrong. You don’t want to create your own user accounts so much as you just want to store data about users in an application database? We do this with lots of our Auth0 protected apps … e.g., a postgres database behind an django app that stores application specific data. In our case we let the application handle this using data returned in the ID and / or access tokens.
Using a Rule should be fine as well, I think. Just make sure it doesn’t block the login process.
I still want auth0 to take control of authentication but with the email/avatar/name I get back as the id token, I’d still want to create a user in my own database.
So I think it’s more or less the same process you have in place.
So in your opinion both approaches are valid in this case?
I think both approaches are fine… feels more like a standardization thing to me. E.g., deciding between “I will centralize this kind of stuff in Auth0 with Rules” or “I will leave this kind of stuff to my app(s).” And you can always do both of course! There might be use cases for that, or use cases for using hooks to interact with your database.