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.
After successful authentication, Amazon Cognito returns user pool tokens to your app. You can use the tokens to grant your users access to your own server-side resources, or to the Amazon API Gateway. Or, you can exchange them for AWS credentials to access other AWS services.
To use the refresh token to get new ID and access tokens with the user pool API, use the AdminInitiateAuth or InitiateAuth API operations. Pass REFRESH_TOKEN_AUTH for the AuthFlow parameter.
After a user logs in, an Amazon Cognito user pool returns a JWT. The JWT is a Base64-encoded JSON string that contains information about the user (called claims). Amazon Cognito returns three tokens: the ID token, the access token, and the refresh token.
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.
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;
});
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With