OAuth2 JWT Signing with OAuth2 Application Secret Key

Question

Abstract (sorry, this is a mouthful):

I would like to facilitate back end system-to-system Authorization via OAuth2 and JWT by making use of the JWT 'aud' param to specify a resource specific to an application (via a JWT Authorization grant request to the Authorization Server), and then have the Authorization Server sign (or encrypt) the JWT with the OAuth2 secret key of the registered OAuth2 Application that holds the resource specified by the 'aud' param so that the Resource Server for which a token was requested can validate the token with its OAuth2 Application secret key.

Summary:

I have a question regarding back end system-to-system Authorization with OAuth2 and JWT.

• Given a Resource Server RA
• And a Resource Server RB
• And an Authorization Server AS
• And RA and RB are registered OAuth2 applications with AS

We would like to make use of the OAuth2 specification with JWT to achieve the following:

1. RA requests an JWT from AS
2. AS responds to RA with a JWT
3. RA requests a resource from RB using the JWT
4. RB responds to RA with the resource data (without having to calls AS)

The Problem:

The goal is for RB to have the capability to validate the JWT independently of AS. That said, RB must have a way to validate the JWT that was send in the request by RA. Since AS issued the JWT sent by RA, then AS and RB MUST have a shared secret.

It would be bad security practice to have a shared secret between all Resource Servers and the Authorization server for the express purpose of using it for JWT signing and/or encryption. This solution would side-step the OAuth2 (Authorization Delegation) spec which has painstakingly attempted to mitigate the security issues that arise from largely distributed symmetric keys, etc.

Proposal:

My rough proposal is to solve this issue is as follows:

1. RA requests a JWT from AS using JWT Authorization grant and specifies a resource in the RB API in the 'aud' param (https://www.rfc-editor.org/rfc/rfc7523#page-6 see number '3.')
2. AS Responds with a JWT signed/encrypted with the secret key of the RB Application (AS can identify which application secret to use based on the URI of the 'aud' param)
3. RA requests a resource in RB using the JWT
4. RB validates the signed/encrypted JWT using the OAuth2 secret key

My Question:

Does the proposal make sense here? Is there a much more straightforward implementation that would still meet my goal and stay within the OAuth2 specification? Is this a misuse of the 'aud' JWT param?

Thanks a lot for reading this, and for your help.

Answer 1

This sounds like a case where the new introspection service added to OAuth2 (https://www.rfc-editor.org/rfc/rfc7662) would be useful. It allows your RB to validate the access token (the JWT) forwarded by RA against the AS.

This breaks your request that there is no communication between RB and the AS. But that should not be a problem, as these services already trust each other. There are no globally known symmetric keys or implicit trusts between RA and RB involved.

Interpolating it into your stream:

1. RA requests an JWT from AS
2. AS responds to RA with a JWT
3. RA requests a resource from RB using the JWT
4. RB validates the JWT against the AS/introspection service
5. RB responds to RA with the resource data