How to add an aud claim to JWT ID token?

Question

I want to use Microsoft Entra ID (Azure AD) as an access provider to an external database (Fauna). However, when authenticating using Microsoft Security Authentication Library (msal) the generated JWT ID token aud claim is the application ID (as expected). But for Fauna to accept it, for authentication, it needs its audience ("https://db.fauna.com/db/xxxx...) to be within the aud claim. Is there some way to add an audience to an ID or access token, so it'll become an array of strings?

• I have tried using the audienceOverride claim but that would cause authentication to fail for the web app since the application URI/ID was no longer in the audience, and I would still like to have the default aud claim in the token to use it for authentication in my web app. It also did not consistently override the aud claim either
• I also tried creating a separate web API app to create a new JWT token (and use the audienceOverride claim) for authenticated users through my web app (exposing it as an API and adding it to the web app's API permissions), but I could not figure out how to authenticate users given the initial (web app's) ID token and persist the roles and claims within it, and if that would secure/safe

Am I going about authentication correctly, should I try to have more than one audience in a JWT?

Answer 1

Hello @Christofer Cousins

Here's a high-level overview of how you might approach this:

1. Adding an Audience to an ID or Access Token: The aud (audience) claim in a JWT is meant to refer to the Resource Servers that should accept the token. In general, the audience of a token is the intended recipient of the token. It's possible to have more than one audience in a JWT. However, the consumer of the token only identifies as a single audience. In this case, the consumer accepts and validates a token only if his own audience is in the audience claims of the token.
2. Audience Override Claim: If the audienceOverride claim is causing authentication to fail for the web app because the application URI/ID is no longer in the audience, you might need to reconsider its usage. It's important to ensure that the default aud claim remains in the token for authentication in your web app.
3. Creating a Separate Web API App: If you're creating a separate web API app to generate a new JWT token for authenticated users through your web app, you'll need to ensure that the initial ID token's roles and claims are persisted. This can be complex, but there are resources available that discuss how to authenticate users given the initial ID token and persist the roles and claims within it
4. More Than One Audience in a JWT: Whether you should try to have more than one audience in a JWT depends on your specific use case. If you have multiple APIs that can be used by multiple clients, having more than one audience per API could potentially simplify your authentication process.

Remember, it's crucial to ensure the security of your authentication process. If you're unsure, it may be beneficial to consult with a security expert or conduct a security audit of your system. Always prioritize the security and privacy of your users' data.

---

I hope that this response has addressed your query and helped you overcome your challenges. If so, please mark this response as Answered. This will not only acknowledge our efforts, but also assist other community members who may be looking for similar solutions.