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.
- 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://tools.ietf.org/html/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:
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.
- JWE JSON Serialization with multiple recipients (https://tools.ietf.org/html/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.