Why and when should I use an Identity Provider like Auth0 or Azure AD B2C instead of just storing the user credentials within my database?

Question

I'm developing an ASP.NET Core API, and I'm trying to do the authentication and authorization part as best as I can. I'm studying OAuth 2 and OpenIDConnect (very preliminary studies at this point). But from an API developer standpoint, what can I gain from inserting an Identity Provider like Auth0 or Azure AD B2C in the process instead of just storing the user credentials using some form of cryptography?

Also, Oauth 2 seems to allow many flows, is the job of the API to be concerned with the flow of the application consuming that API? Seems a bit unreasonable. What I want is just to have a safe way to store the user credentials, and allowing the users of my API to perform authentication and authorization before consuming and manipulating resources within the other services within the API.

I understand that authentication and authorization is a sensitive topic within an application, as they deal with security concerns, and I'm planning on building an application that will deal with sensitive financial operations. That's the reason I wend after Auth0 and Azure AD B2C. But to be honest I'm having a little trouble trying to understand what Identity Providers like these will bring to the table, I know they'll bring something of importance, I just need some help to see what and why should I use them.

Answer 1

what can I gain from inserting an Identity Provider like Auth0 or Azure AD B2C in the process instead of just storing the user credentials using some form of cryptography?

Well, you get the freedom of not storing credentials in your database. Most likely these service providers are taking better care of their security than you would. Another thing that you gain is Single Sign On. Many apps can use the same identity provider for the users, so the users only need to sign in once to use all of the apps.

Of course it is not zero cost, there is complexity involved in OAuth/OIDC. But neither is building your own user store.

Also, Oauth 2 seems to allow many flows, is the job of the API to be concerned with the flow of the application consuming that API? Seems a bit unreasonable.

No, the API usually does not care what flow the caller uses. What it cares about is that it receives a valid access token that contains the necessary permissions to access a particular resource. It is a concern of the client app to choose the flow to use.

But to be honest I'm having a little trouble trying to understand what Identity Providers like these will bring to the table, I know they'll bring something of importance, I just need some help to see what and why should I use them.

Well, here are the things that come to my mind:

• Better security (most likely, it isn't only about the password hashing algorithm etc.)
• Better SLA (building a 99.95% SLA service like Auth0 is not cheap)
• Proven track record
• Single Sign-On
• Single identity for users to all your apps, can easily disable their account as well to prevent access to all apps at once
• Can easily add support for federated authentication with other identity providers
• No need to store password hashes etc. in your app
• Ready-made administration tools (which you need to build otherwise)