Usage of aud claim?

[huyennbl]

Hi, I would like to ask about how people use aud claim. It’s a bit vague to me. I’m using it like this, could you please this is a correct way to do it?

Suppose that:
I’m having 2 frontend apps, admin portal, and user portal.
I’m having server to do login function, that will handle login, then sign a jwt token, send it back to browser. <1>

I’m having an api gateway that will handle requests from browser, including jwt created by <1>. After validation, this gateway decide whether to route the request to admin (e.g. admin.foo.com) system or to a user (e.g. user.foo.com) system. <2>

I’m using the aud like this:
During the <1> step, I check if the login request comes from a user portal, or admin portal, then put the value of the audience field like admin.foo.com and user.foo.com

During <2> I’ll check if the jwt value of aud claim then redirect the traffic respectively. The purpose of this usage is to avoid users from user portal to use their valid jwt token to access some admin resources.

Assuming that the system of admin.foo.com and user.foo.com don’t have additional authorization layer, can I do as above?

[stephanie.chamblee]

Hi @huyennbl,

According to the JWT spec, the use of aud refers to the recipient of the Access Token. When following the OAuth 2.0 protocol, this would be the resource server (your API in this case).

The spec also states that the interpretation of aud is application-specific, so I believe your flow follows the general use of the claim:

4.1.3. “aud” (Audience) Claim
The “aud” (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. 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. … The interpretation of audience values is generally application specific…

I think it’s more common to follow role-based access control (RBAC) for authorization. RBAC may be more scaleable if you’d like to ever introduce more types of users than “user” and “admin” and there are resources to help you set it up such as Auth0’s core authorization and the authorization extension.

However, given that the use of aud is application-specific, to my knowledge, there isn’t anything wrong with how you are currently using it.

Hope that helps!

Stephanie