Question about Provisioning Users in DB After Okta SSO via Auth0

Hello - just have a question about specific logic related to provisioning users in my own (Postgres) database after a user logs in via SSO.

My current idea is create a post-login action, have a flag on the user app_metadata, and depending on the value of that flag, hit an endpoint on my server to provision that user in my own database. This seems reasonable conceptually, but as someone relatively new to SSO and auth0, I am unsure if this is considered best practice.

Is there a standard or more robust way to ensure every Auth0 user (from any connection) is also provisioned in our DB?

Thank you!

Hi @billy2,

Welcome to the Auth0 Community!

Your approach is definitely suitable and considered best practice as well for exporting users to your own external database. Creating a Post-Login Action is a great way to accomplish this, along with using app_metadata. Once a user profile is created in Auth0, regardless through SSO or any other connection you can update your external database.

I hope this helps!
Thanks,
Remus

1 Like

@remus.ivan Ah awesome! Thanks so much for the reply. Is this Post-Login Action approach preferred over listening to the user.created event stream and hitting a custom webhook endpoint to create the user? Just discovered the event stream but wondering if there are any pitfalls with that approach (like should it not be used for things like user provisioning/ was it intended more for auditing purposes or etc)?

Hi @billy2,

There is no preferred method over the other, this all depends on the complexity of your use case. The more straightforward way would be using a Post-Login Action if you just need to export the basic user information from the registration process and want to keep things a bit simpler.

Otherwise, if your intent is a more complex automatic user export you can also rely on creating Event Streams using a custom webhook ( currently in Early Access ), which covers user provisioning, as well as updating or deleting them. This will require more work, given that the trigger is asynchronous, so I would recommend checking out the Events Best Practices, as well as this blog post - Discover User Lifecycle Changes via Event Streams.

Thanks,
Remus

1 Like