> when you look at these auth solutions they typically will handle three things
> 1. handshakes with third party IDPs (login with google, etc)
> 2. session management
> 3. user storage
> 1+2 are boring and i’m 100% down to offload it to someone else
> the problem is #3
I think you are assuming you do #3 (user storage) yourself in your own database, which is possible.
But lots of auth providers want to store the users for you and make it look appealing (user dashboard already made, don't have to store PII, SSO: can share single account across multiple services, etc)
That is exactly what one of my clients decided after I introduced them to UserFront. But then ran into problems just rendering a list of items in the app because only the UserFront id was stored in the local DB. User names, email addresses, were all stored in UserFront.
You can choose to store username, email addresses, etc in your own database, but then you have to be careful about syncing at least the user id + email address(es) between the auth service and your own DB.
> 1. handshakes with third party IDPs (login with google, etc)
> 2. session management
> 3. user storage
> 1+2 are boring and i’m 100% down to offload it to someone else
> the problem is #3
I think you are assuming you do #3 (user storage) yourself in your own database, which is possible.
But lots of auth providers want to store the users for you and make it look appealing (user dashboard already made, don't have to store PII, SSO: can share single account across multiple services, etc)
That is exactly what one of my clients decided after I introduced them to UserFront. But then ran into problems just rendering a list of items in the app because only the UserFront id was stored in the local DB. User names, email addresses, were all stored in UserFront.
You can choose to store username, email addresses, etc in your own database, but then you have to be careful about syncing at least the user id + email address(es) between the auth service and your own DB.