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