2

A common misuse of OAuth2 is as a strict authentication protocol. OpenID Connect addresses this by extending OAuth2 to include an id_token. Implementing clients for OAuth2 and OpenID Connect is a monster project. The fact that access_token is opaque makes it non-interoperable between implementations. Additionally, implementing proper OAuth2 and OpenID Connect clients and servers is very difficult to get right.

As an exercise, I was dreaming up a new spec. I was thinking of having a single JWT (we'll call it auth_token for now) that acts as an OAuth access_token, but contains user data similar to an OpenID Connect id_token. The aud claim would include both the client_id and the resource server, so it can be read by both parties. Any sensitive data that needed to be encrypted could go in some encrypted_data claim (ie the entire JWT will not be encrypted, only the data in that claim). The new spec would offer similar grant types to OAuth2 to create this auth_token.

Hopefully, this would accomplish both delegated authorization and authentication while also introducing interoperability by introducing some standard claims for user data, ala id_token. Obviously, a LOT more thought would need to go into this to make it a real spec. What are the drawbacks to this general design?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.