Why doesn't Amazon Cognito return an audience field in its access tokens?

user_152567 0
Viewed 7297

When Amazon Cognito issues access tokens it doesn't include an aud field.

In the documentation for Cognito tokens, the aud field is listed for id tokens (always set to the same value as client_id), but not for access tokens.

The relevant section of the JWT specification says:

If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected.

So, what's going on here. Who's right? Is this a security concern?

I notice that the iss section of the token is specific to my user pool, and that can't have been tampered with, since it's signed by Amazon, so I think I should be safe

OAuth 2 and JWT are very confusing though, so I wanted to get more opinions.

jwt amazon-cognito oauth-2.0 amazon-web-services
4 Answers

From my reading of the RFC I do not think that AWS is doing anything wrong, specifically (note my emphisis):

If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected.

Use of this claim is OPTIONAL.

Which, I believe, means that AWS is fine, because it's simply omitting the claim in the case of the access token, but it is identifying itself (in it's own way), by setting it to client_id when it does make the claim on the id token.

It should be noted that the access token itself does encode and enforce the audience; in that when you use it against AWS' APIs it will enforce that you only receive the resources available on the client_id/scope that it was issued for.

user_25311320

Many dotnet web application cognito tutorials are based on the wrong assumption that the client id will be the Audience Id in the following setup which will NOT WORK. 

          services
          .AddAuthentication(options => {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
            .AddJwtBearer(options => 
            {
                options.Audience = "Client ID";
                options.Authority = "https://cognito-idp.ap-southeast-2.amazonaws.com/USERPOOLID";
                options.RequireHttpsMetadata = false;

            });

A temporary workaround is not to validate the audience:

services
            .AddAuthentication(options => {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
            .AddJwtBearer(options => 
            {
                // AWS cognito jwt token does not have aud included so that we cannot validate audience.
                // options.Audience = "Client ID";
                options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateAudience = false
                };
                options.Authority = "https://cognito-idp.ap-southeast-2.amazonaws.com/USERPOOLID";
                options.RequireHttpsMetadata = false;

            });
user_19825240
user_4992200

Typically, an aud claim is used to identify the recipients or principal such that the recipient can verify that the jwt is meant for it to validate.

However, aud is an optional claim. So, AWS keeps it optional.

Instead of tying who can process the jwt using the aud claim, AWS leaves it up to the recipient (e.g. aws api gw) to check for a client_id claim to identify if the jwt should be processed.

References:

https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3

user_59927140
Related