OAuth2 JWT Encryption for Tokens with Scopes to Multiple Resource Servers

Question

Within the context of an OAuth2 deployment, I would like to grant a Client an encrypted JWT that has scopes that to several Resource Servers and can be decrypted by each Resource Server independently of the Authorization server sharing a secret between all Resource Servers.

Do specifications to solve for this scenario exist?

The requirements in the next section specify a few remaining constraints.

###Requirements###

• The decryption must occur at the Resource Server layer, without having to proxy the token back to an Authorization Server (via Token Introspection endpoint, or otherwise).
• The Resource Servers must all have distinct secret keys in order to limit the attack surface that could result in any given secret key being compromised.
• The JWT must use the compact format in order to remain compliant with OpenID Connect (is this true, or can OpenID Connect work with JWT (JWS/JWE) JSON serialization formats?)

###An Example Use Case###

I will map out a use case for the authorization code grant (https://www.rfc-editor.org/rfc/rfc6749#section-1.3.1) in order to further demonstrate my use case.

• As a registered User of an Authorization Server

• When I visit a registered OAuth2 Client Application (with my User-Agent) for the first time

• Then I should be redirected to the Authorization Server with the query required query params for the Authorization Code Grant (including scopes="photos.read,photos.write,friends.read")

• And I should see an authorization dialog requesting delegated access to the following services:

• Read your photos

• Upload photos on your behalf

• Read your friends

• When I click 'Authorize'

• Then I should be redirected back to the registered OAuth2 Client Application with an Authorization Code

• When the OAuth2 Client Application system used the Authorization Code to request a token

• Then the OAuth2 Client Application system should receive a token with the following scopes:

  • photos.read
  • photos.write
  • friends.read

(...)

In my implementation of this system, the "Photos Resource" and the "Friends Resource" live on two distinct Resource Servers. As mentioned above, the goal is that these resource servers do not share identical secret keys.

###Possible Solution###

1. JWE JSON Serialization with multiple recipients (https://www.rfc-editor.org/rfc/rfc7516#appendix-A.4.7). This violates the requirements above since is uses the JWE JSON Serialization method rather than the JWE compact format. As per the question above, it would appear that OpenID Connect can only use JWT Compact format. If my assumption is incorrect here, then maybe this is a reasonable solution?

Thanks for reading this. I would really appreciate any suggestions or pointers.

Answer 1

I read you question a couple of times because I confronted with a "problem" like your. The solution presented by you, using OAuth2 with OpenID Connect and JWT as token is correct. I wrote on Medium an article where I described in details how to use OAuth2 with OpenID Connect. If you have any questions, please ask me.

LATER EDIT

One of the weaknesses of OAuth2 is that there is no prescribed way for the Resource Server to validate the access token or to use the access token to establish the identity of the user.

Google and other OAuth2 providers solved this problem by providing a TokenInfo endpoint. Resource Servers could pass the access token to this endpoint and get back information about the token validity, user identity, token scope, and expiration time. In my case this endpoint correspond with the Authorization Server.

This concept was expanded in OpenID Connect with the introduction of the ID token. The ID token is a signed and potentially encrypted token which contains the user’s identity and any claims that were in scope.

The ID token is a JSON Web Token (JWT) that contains identity data. It is consumed by the Client and used to get user information like the user’s name, email, and so forth. This is also useful when you have a chain of Resource Servers and a Resource Server can be a Client of another Resource Server.

The JWT feature gives Client applications and Resource Servers the ability to securely get information about the user directly without having to contact the Authorization Server every time.

If you want to prevents the issuance of overly broad access tokens, you can provides an authorization check at each point in the chain. A Resource Server can be a Client for the Authorization Server, present its JWT, and request a new JWT for the next Resource Server in the chain.