Does anyone know if there any plans to offer the ability to use the POST /api/v2/users endpoint for non-database connections (such as other OAuth 2.0 identity providers) in the future? Or some details about why this isn’t possible?
I would have hoped this would be possible by passing in just the connection, user_id (if known) or email_address and then Auth0 would be able to associate a pre-created user when they login via that connection.
Our scenario for wanting this is that we already have (in Auth0) an API, backed by multiple microservices, which can have m2m / client credentials access tokens issued for it and we are now adding the ability for users to login via Auth0 and also get access tokens for the API. One journey is that a m2m client will create resources for a user via the API and later on the user will login via Auth0 to a SPA to view those resources. We want to create the user in Auth0 at the same time the user is created in our backend, so it is easier to use the Auth0 access tokens for authorizations decisions later in other services (which will contain the Auth0 ID for that user).
I haven’t seen this type of scenario covered much in the Auth0 docs. There is a bullet point within the User Data Storage docs, under the heading External database vs. Auth0 data store, but doesn’t address how users can be created in advance. I’ve had a quick look through the forums too.
As far as I know there are no plans to add this feature.
With a database connection, Auth0 is the owner of the data. But with federated connections, Auth0 is NOT the owner, the 3rd party IDP is the owner. Since Auth0 is not the owner, it doesn’t make sense to “create” a user - there is no way for Auth0 to contact the 3rd party IDP and say “Create this user”.
While this is very inconvenient, it is architecturally sound.
From your use case, I think you might require a DB user first, and then allow users to link other federated identities. By linking, you limit it to the one user you initially created. Note that this linking behavior is NOT what is provided by the Auth0 linking extension, that is more flexible, and not what you want.
Thank you, I appreciate the response. I didn’t intend to suggest that Auth0 would attempt to create the user in the IDP associated with the connection, more that it would be possible to create the expectation for a user to come through that connection - but your explanation still makes sense to me as what I’m looking for is quite different to how the create user endpoint is currently used, thank you.
I will take a more detailed look at the option to create a DB connection user first then link to an identity coming from another IDP later on.
One other option we are considering is to just create a user in our backend only to begin with and then when a user logs in, check to see if they can be linked to an existing record in our backend or create a record if not (either via Auth0 actions or via the app), but to do this safely we either need to ensure email is verified or have some other identifier provided via our API when the user is created that will also be provided by the IDP.