Hacker News Reader

I agree that OAuth by itself doesn't solve registration, account recovery, profile management, 2fa, etc.

Most OAuth2 servers (whether the ones you mention or others like keycloak, identity server, azure ad b2c, ping identity, etc, etc) augment the standard with this functionality. Other than OIDC for authentication, I am not aware of any other high level standards for these problems (though https://datatracker.ietf.org/doc/html/rfc6238 is useful for 2fa).

I think that software companies push OAuth2 because it solves a real problem and is a standard. If there are other standards around identity, they'll also be used by these folks (SCIM, other OAuth grants). If there are holes in functionality, those will be filled by custom implementations (whether the software is OSS or not).

I don't see how those open source projects that you mention get us closer to data portability. Can you explain that?

FYI, both FusionAuth and Auth0 allow exports of password hashes, which is fundamental to letting the data owner migrate easily.

Disclosure: I work for FusionAuth.

Integrating Kratos with anything is just so much work. The only nice thing differentiating Kratos from Keycloak is the ability to provide your own UI out of bound. In Keycloak, one has to use the template language provided by Keycloak and embed all those templates in a JAR file, which can be an operational hassle. Kratos makes it nice because it decouples the registration/login/recovery/settings flows from the UI but wow - integrating it even with Hydra is a mess. I mean, look at a simple case of passing your subject info to hydra token. There's a dedicated admin API in Hydra for that.

In practice, I still find Keycloak more ergonomic because it comes with batteries included and it also provides authorization services. I've written more about those here: https://gruchalski.com/posts/2020-09-05-introduction-to-keyc....

“People” don’t want first-party authentication and accounts. With OAuth2 (or rather OpenID Connect) it’s ridiculously trivial to get started with third-party auth (not really third-party but “auth as a service”). This isn’t about portability at all.

Sure you’ll regret it later as new requirements regarding auth as requirements about the flow and page design and whatnot keep coming. However, you have to admit that it’s very tempting. Ready-to-use OIDC/OAuth2 adapters exist for just about anything. Decision-makers and customers can rarely grasp the consequences, but they certainly see the immediate cost-savings.

Hey keephand, I’m working on a project that tries to solve first party auth in a more intuitive way (and doesn’t use OAuth). I’d love to chat more. Don’t see a way to reach you in your bio; if you’re open to it, could you reach out to the email in my profile?

> 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...

I assume you are using "Auth" for authentication, and not authorization (as OAuth does). Indeed, OAuth does zero for first or third party authentication of users - authentication is a set of extensions provided by OpenID Connect.

The reason people use OpenID Connect as the API for first party authentication is because you _need_ an API for integrating externalized authentication systems, and (excluding SAML) every other system is proprietary with minimal cross-vendor support.

However, that OpenID Connect API only provides for authentication with a few (possibly supported) hints for behavior. It is up to the OpenID Provider software to provide all the IAM features you mention - registration, account recover, profile management, multi-factor authentication, etc.

There is no standard for registration, account recovery, profile management, or MFA because all of these are business processes or user experience customizations - they are software, not protocols. That is why OpenID Connect is used to integrate with a piece of off-the-shelf software which implements your business policy and which is customized for your desired experience.

At most, you see things like https://github.com/w3c/webappsec-change-password-url - website configuration to tell a password manager where to navigate the browser in order to change the user's password.

> 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!

These both have the same architecture as say an Auth0. Supertokens API provides a proprietary alternative to a constrained OpenID Connect protocol. Kratos has a companion project which exposes the server via OpenID Connect.

The supertokens API may have been easier for _them_ to implement than all of the potential OAuth and OpenID Connect extensions, but when going with constrained profiles like the OpenID Connect Basic Client Profile it would be difficult to be substantially simpler without being less secure.

It works really well for scaling your systems. In the case of "third party" this can mean disparate services within your platform, permitting you to fully isolate the authentication from literally everything else.

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.

Google and Microsoft do use OpenID Connect for internal services, as well as their consumer-facing services.

While they do not necessarily use consent for delegation, they do use automated policies to restrict API access to what the application needs.

Likewise, having a common protocol for getting authentication and API access allows them to decompose systems. Having to build first party authentication and API access systems would naturally encourage applications to become monolithic.

You are wrong. You do not need to acquire consent, either, when it is implicitly granted because the service is the same system as the IdP. I.e., consent is requested/granted when they sign up with your IdP.

I think a bunch of frameworks already have support for JWT validation and OIDC/OAuth in Auth middleware. Also everyone used it at some point.

So might as well use something that's there and known and will scale.

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)

Actually, many vendors use JWTs as the OAuth tokens, though they don't have to. And they are required by OIDC.

There's a standard for using JWTs as OAuth tokens, though it is a new one that may not be well supported yet: https://datatracker.ietf.org/doc/html/rfc9068

> Actually, many vendors use JWTs as the OAuth tokens, though they don't have to. And they are required by OIDC.

Clarification - only the id_token defined by OIDC needs to be a JWT. This is because it is an authentication statement to the client, so the client needs to be able to verify and understand the data.

Fair point. I didn't realize that the access token was referenced in the OIDC spec, but sure enough, there it is:

"After receiving and validating a valid and authorized Token Request from the Client, the Authorization Server returns a successful response that includes an ID Token and an Access Token"

https://openid.net/specs/openid-connect-core-1_0.html#TokenR...

Heya. I own Microsoft Oauth2. We use JWTs for our access tokens. (the consumer service uses encrypted tokens, yes).

Auth0 just championed the RFC for a standard for JWTs as access tokens too, largely informed by the architect there working on our access token format.

CAEP and RISC are how we're tackling revocation. Encrypted JWTs handle PII.

Oauth is a fantastic way to scale complexity - the whole "first party" consideration here is a red herring. Do you think we want Outlook calling the Exchange backend via a different auth protocol from the one we tell 3p clients to use? That's a waste of time to go build.

We also just added support for the JWTs emitted by Google and AWS, so that you can token exchange their JWTs for an access token in our ecosystem.

How does that token exchange work? does the user need to have a previously linked account?

The Microsoft-side app owner provides a trust description of the incoming token based on issuer, subject, and audience - https://docs.microsoft.com/en-us/azure/active-directory/deve...

> OAuth2 shouldn’t even use JWTs in the first place.

OAuth2 considers its refresh tokens to be opaque to all parties except the AS which issued them, and its access tokens to be opaque to the client (only understood by the API resources where they are used).

Thats not to say they need to be self-contained - several OAuth systems will just make these both database indexes, and require resources to make an introspection call to validate and get information on access.

There are many clients which have found out that the server access token is a JWT and have extracted information from it. These are at a minimum breaking their compatibility contract, but also often doing something inherently insecure like using the access token as an authentication statement.

Note also that JWTs can be encrypted as well as signed, which would eliminate any PII leakage.

Revocation at a central location typically doesn't happen in large scale (geographically distributed or otherwise eventually consistent systems) unless it is essential for the business case - instead you just tune how long access tokens are good for, so that the client (and not the resource) needs to go back to the central location for a new policy statement in the form of a new access token.