CODEWITHSUNDEEP
asp.net-web-apioauth-2.0owinjwt
mattnaik
mattnaik

Reputation: 43

JWT multiple audiences per resource server

After spending a number of hours researching using JWT in Web API using OWIN I'm still rather confused on what the purpose of the Audience represents. Some pages are saying that the audience is the resource server on which the token will be validated. Others suggest that audience is the client that is accessing the resource server and frequently actually refer to this value as client_id and audience interchangeably.

According to the JWT spec it appears the Audience is intended to be the resource server (https://www.rfc-editor.org/rfc/rfc7519#page-9). So I don't see a need to ever have more than one Audience per API application. But a number of implementations are adding multiple Audiences to a single Web API app and Microsoft's implementation of JwtBearerAuthenticationOptions allows for it as well.

In these implementations where they are using the audience and the client_id interchangeably (here is one example: https://auth0.com/docs/server-apis/webapi-owin) I feel this too closely couples your resource servers to your clients and is enforcing the client claim on your resource server. I feel like this is the job of the authentication server (hence the ability to add multiple audience claims to the token according to the JWT spec).

I feel like I'm missing something important here. My goal is to be able to develop multiple API's that can be used by multiple clients but having to dynamically manage the audience claims at both the resource server and auth server seems to go against the spirit of JWT. Yet many people have implemented it otherwise and even MS allows multiple audiences per resource server so I was hoping for some clarity here.

Upvotes: 3

Views: 7005

Answers (2)

Joschi von Rehberg
Joschi von Rehberg

Reputation: 1

A bit late to the party, but: A JWT token should only contain one audience. It is the job of the developers/architects to design logical applications (~audience). Imagine you have two UIs:

  • Admin UI
  • Consumer UI

Where as the Admin UI consumes

  • service1
  • service2
  • service3

And the Consumer UI consumes

  • service3
  • service4
  • service5

When you log into the admin UI, you don't want to request 3 tokens with 3 different audiences. Same is true for the consumer UI. That's why you design two logical applications:

  • admin
  • consumer

Now you tell your service1 and service 2 to check the JWT audience for "admin". Service4 and service5 will check for "consumer". Service3 will be fine with tokens issued for either "admin" or "consumer".

Upvotes: -1

Eugenio Pace
Eugenio Pace

Reputation: 14212

The audience identifies the intended "consumer" of the token. Normally it is the application (API) that receives the token from a client app.

Services that expect a JWT need to inspect (and validate) the audience to prevent someone from sending (a valid) token that was meant for someone else.

You can imagine a situation where API-1 and API-2 use both role based security for example, and a user obtains a claim admin for API-1. If API-2 doesn't check audience there's a chance the user can send the token (with admin claim in it) and succeed (when it shouldn't).

Upvotes: 2

Related Questions