- Newest
- Most votes
- Most comments
This is indeed a complex scenario involving multiple JWTs for different purposes and providers. Here are some potential solutions to your questions:
-
Auth0 Access Token: The issue with the missing audience and empty payload in the access token seems to be due to the way Auth0 generates tokens. When the audience is not specified, Auth0 generates an opaque token instead of a JWT. This opaque token is not intended to be decoded and used by clients. It's only useful for the
/userinfo
endpoint. If you want a JWT from Auth0, you need to specify theaudience
parameter during the authorization request. However, as you mentioned, this isn't directly possible with Amazon Cognito. One potential workaround could be to use Auth0 as the primary identity provider and then use AWS's Assume Role with Web Identity to authenticate with AWS services. This way, you can get a JWT from Auth0 with the correct audience and payload, and then exchange this token for temporary AWS credentials. -
Pre-Token Generation Lambda: You could potentially use a pre-token generation Lambda trigger to modify the tokens issued by Cognito. However, this won't solve the issue of the missing audience in the Auth0 token. This Lambda trigger is used to modify the Cognito tokens, not the Auth0 tokens. As mentioned above, you might need to use Auth0 as the primary identity provider to get the correct Auth0 token.
-
Client-Side Token Generation: The
nextjs-auth0
library provides agetTokenSilently
function that can be used to get or refresh the Auth0 tokens. This function can be used to get a new Auth0 token with the correct audience and payload. However, this would require a separate login process for Auth0, which might not be ideal. Another option could be to use the Auth0 Management API to get or refresh the tokens, but this would require storing and managing the client credentials securely.
In summary, it seems like the main issue is the inability to specify the audience during the authorization request with Cognito. One potential solution could be to use Auth0 as the primary identity provider and then use AWS's Assume Role with Web Identity to authenticate with AWS services. This would allow you to get a JWT from Auth0 with the correct audience and payload, and then exchange this token for temporary AWS credentials. However, this might require significant changes to your current authentication flow.
Relevant content
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
This is was an extremely helpful and detailed answer, thanks so much @YusufVendii! Ended up going with a strictly Auth0 auth approach given Auth0 has the audience parameter that is required to make authenticated tokenized requests. It works great, and really appreciate all of the different angles you shared that we could go down.