Allowing users to register to your app using another service (e.g. Facebook, Spotify, Google) requires OAuth. That’s what I use authlib for, anyways. It simplifies the OAuth process so much that I don’t have to think about the authentication process when designing an app.

Your experience is not necessarily others': IME, OAuth is widely adopted, and OIDC is rapidly gaining traction. GitHub Actions, for example, offers ephemeral identity credentials through OIDC.

OAuth (OIDC) still makes a lot of sense in some scenarios. I work at a university and I just used Authlib a few months ago to consume our single sign-on, and let me tell you, that was much easier than using the API would have been.

Isn't Auth0 a commercial product? That might not be an option for everyone.

Having multiple options on the market is healthy.

The alternative is called monopoly and it's not good for consumers.

> I don't know any service that still uses OAuth last I checked

But

> Besides, for any new project I just go for Auth0 these days, that's just me.

Auth0's primary mode is OAuth2.

The level of ignorance many developers have these days about foundational technologies that power SaaS platforms is truly astounding.

Hopefully there are still people around to build SaaS when the current vanguard retires.

> I just go for Auth0 these days

That's a service that manages OAuth2 for you, for $ at scale

I was just at a developer conference and was amazed at how many people used Auth0 and OAuth interchangeably. They've done a super job of capturing mindshare, and have a great brand.

More likely those people were somewhat junior. It makes no sense to interchange a vendor with a technology unless the name is literally the same.

Isilon for instance was a brand where there main product was... Isilon clusters.

Possible. I didn't dig into their understanding, but this past week wasn't the first time it has happened.

Never even heard of Auth0, lol

The world's a big place!

Full disclosure, I work for an auth server vendor.

So there are three primary use cases for OAuth (I'll include OIDC as well, as they are often paired and OIDC is built on top of OAuth).

* Authentication. Using OIDC for authentication lets you use one of many authentication servers (FusionAuth [my employer], Keycloak, Python OAuthlib, Django with https://django-oidc-provider.readthedocs.io/en/latest/ Auth0, Cognito, etc etc). Using such an identity server lets you have one single place to store user data. It's normalizing user data, which has the same benefits and tradeoffs as normalizing any other kind of data.

* First party API authentication (where the same org controls both the end client and the API server). This is comparable to API keys, but has some differences. Setup is more complicated, but you have credentials that are automatically time bound (tokens expire), support multiple useful flows, and have a refresh mechanism built in. Plenty of security experts have banged on OIDC/OAuth and helped fix issues, and j random developer you just hired is probably more familiar with OAuth than your custom API key scheme. You also have the ability to put more data in the token (if you use JWTs) and have the tokens verified without contacting a central server. This can lead to some nice scaling properties.

* Third party API access. When you are the client and want access to third party APIs, you have to use what the API dictates. That is often either OAuth or API keys. OAuth here has a lot of flavors. See this article which was on HN a month or two ago: https://www.nango.dev/blog/why-is-oauth-still-hard

Source: I work for FusionAuth, an auth provider which supports OAuth and OIDC, and help support users and customers implementing FusionAuth.

Can you use Auth0 in your own , Airgapped intranet? Can you use Auth0 without exposing your user information to Auth0 providers? Can you modify source code of Auth0 for your customizaiton needs?

The answers are No. So i will never need it.