keephand

Sorry but that’s just wrong. The biggest auth systems in the world (Google, Amazon, Microsoft) do not rely on OAuth2 for internal services. Isolating auth into a central service and acquiring user consent as a third party, which very literally is the only purpose of OAuth2, are two very different things. Saying that you need a third party delegation tool to „scale“ an auth system is like saying that you need a good combustion engine to build an electric car.

JWT is not OAuth2. In fact, OAuth2 shouldn’t even use JWTs in the first place. For example, all big systems (Google, Amazon, Microsoft) use opaque tokens for OAuth2 (in third party contexts) due to revokation, PII, and other concerns. Complexity doesn’t scale if used in the wrong context. And needing to put a nail in the wall (pass by value tokens) justifies buying a hammer (JWT) but not a chainsaw (OAuth)

Cool to see such a comprehensive guide! At the same time, are people seriously still pushing OAuth2 for first party auth? Shouldn’t everyone know by one that OAuth does not solve:

* registration * account recovery * profile management * 2fa * …

and is generally completely overblown for first party auth? I always to cite from the abstract of the OAuth2 RFC:

> The OAuth 2.0 authorization framework enables a *third-party* application to obtain limited access to an HTTP service

Yet somehow all of these proprietary software companies (FusionAuth, Auth0, …) cling to the only „open protocol“ to push „portability“ of protocols. But the problem of portability is really a problem of data (you user’s data and migrating that data from system A to B), not the way you exchange or validate tokens or cookies.

I think it’s exciting to see new open source projects like https://github.com/ory/kratos or https://github.com/supertokens/supertokens-core that finally break up this misconception!