3 ms·
Only partially correct. I think the earliest drafts of OpenID Connect were completely agnostic of JWT, and so is OAuth 2.0, but the final Open ID Connect Core s
by unscaled 7y ago
Only partially correct. I think the earliest drafts of OpenID Connect were completely agnostic of JWT, and so is OAuth 2.0, but the final Open ID Connect Core spec is tightly coupled to the JWT standard in multiple places.
The first and most important coupling point is the ID Token. There are three types of tokens issued by Open ID Connect: Access Tokens and Refresh tokens are opaque, just as in OAuth 2. ID Tokens, on the other hand, most follow a more-or-less well-defined JWT format (as much as JWT can be well-defined - it is a somewhat wild west of a standard).
The rest of the places you could use JWT are in the spec, but I admit I've never seen them in the wild (and I would probably avoid them like the plague if I was trying to implement a _secure_ subset of an OpenID Connect IdP):
1. JWT request signing (and even encryption!)
2. JWT for signing and encrypting any JSON response
3. JWT for client authentication
4. JWT for aggregated claims
And I may have missed more things.
If you want to implement Open ID Connect without being crazy, forget about all of these and only use/implement the Auth Code flow with a client secret. You should still verify the ID Token according to the spec, but if you fail to verify it's no longer an issue, since this is a value you get directly from the the Authorization Server on an authenticated TLS channel (the same channel you'd trust for getting the ID Token signing keys).
- user5994461 7y agoOpenID Connect predates JWT so it certainly couldn't have been used from the beginning. I'm not aware if there is a re edition of the spec. Either way, pretty much everything in OpenID Connect is optional and/or implementation specific. OIDC providers have to be integrated one by one, adjusting to their slight differences.
- TJSomething 7y agoOpenID Connect Core, section 2: "The ID Token is represented as a JSON Web Token (JWT) [JWT]." (https://openid.net/specs/openid-connect-core-1_0.html#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke...)
- user5994461 7y agoWell, that's good to know on the one hand. On the other hand, I've never seen a provider that respected that section in full.
- andyroid 7y agoHuh? The ID token and it’s claims is one of the core concepts of OIDC. Are you thinking of OAuth? That spec says nothing about token formats.
- unscaled 7y agoThis is more or less one of the only part that is respected in full. I've got to say, I've seen providers without proper discovery, I've seen providers with strange hybrid flows and I'm pretty sure most providers don't implement the request/response signing and encryption (after all, if you want insanity, you'll be more than happy with SAML). But I've never seen a provider who doesn't implement an ID token. I think everybody would agree that OpenID Connect without an ID token is just plain OAuth 2.
- user5994461 7y agoI've had providers with blackbox tokens. Basically a random string that has to be passed to the /userinfo endpoint to retrieve the user claims. I've had providers with the id_token and access_token being the same value. Other where they were different values. One that didn't support refresh_token at all. Then a variety of screw ups where the required claims in the JWT tokens are missing or incorrect. It's wild really. It always takes a bit of work to integrate any OpenID Connect provider. Most libraries only care to handle Google or Facebook login.
- unscaled 7y agoOpenID Connect predates the final JOSE RFCs, but not the drafts. It was not published by IETF, so it allowed itself to refer to internet drafts describing JWT before being released. The JOSE RFCs and Open ID Connect were basically authored by the same people (M. Jones, J. Bradly, N. Sakimura).
- jogux 7y agoSpot on - in fact over time what we're seeing happen is the authors of the OpenID Connect standards submitting the parts as RFCs to the IETF. The OpenID Foundation is able to move a lot faster than the RFC process whilst coming with similar benefits of protection against patents etc. Obviously there's always speed vs quality tradeoffs, but given the number of interoperable OpenID implementations and the adoption into various openbanking systems (e.g. the UK OpenBanking standards) then it seems like (with the benefit of hindsight) the OpenID Foundation made some good choices. From example, the request object in OpenID Connect (that can prevent authorization request parameters from tampering) is only just now coming out as an RFC https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19 https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19