Hacker News Reader

Comment by keephand | Hacker News Reader

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)

View on HN

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.

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

Reply on news.ycombinator.com