JWT: Why is audience important?

Question

JWTs typically include an audience claim. I've read in many places (articles, code examples, the spec itself) that you must check that the token is intended for you and not another audience.

I'm happy enough to accept that. I'm not planning on building anything that sends to JWTs to the wrong audience. But I'm curious as to why it's important to reject it.

You should be able to verify that the token was issued by an authentication server that you trust. So you have to accept that the claims in there are not fabricated.

The only risk I can think off is if the auth server produced different values, for the same claim, to different audiences. Other than poor namespacing, I can't think of a reason this would happen.

E.g.

{
  "aud": "foo",
  "roles": ["admin"]
}

Instead of:

{
  "aud": "foo",
  "foo.roles": ["admin"]
}

Perhaps the question could be better phrased as:

What bad things can happen if I accept another audience's (valid) JWT token?

Answer 1

I would argue that in a sense you are correct in that there's nothing special about the audience claim that you couldn't handle yourself through namespaced claims and custom security checks.

The JWT specifications notes that the aud claim (as well as the other registered claims) are optional and that the application needs should define when to use or not use them.

As to why it's commonly advised to authenticate on audience, it's basically a simple and standardized way to test whether the incoming JWT is meant for your application. It can be a hassle to create namespaced tokens for each and every application you want the identity to work for. Following the standard approach also makes things easier if you need to integrate with 3rd party apps or identity services.

The only real danger I can think of is if you or the next developer forget to do any additional checks that are now necessary due to not using audience checking.

Answer 2

Suppose I regularly use JWTs from AUTH SERVER to sign in to several several websites, including A and B. Without the aud claim, the JWTs would be identical. This would allow a malicious admin from A to use my JWT to authenticate to B.

Answer 3

This is the same answer as Irfan434 gave, but I would like to explain it with an example to help explain how this can go really wrong.

Imagine you have a big JWT issuer, like Google.

Now imagine you have a low-security app that uses this JWT issuer for user accounts. Lets say it's a mobile app called "Earl's Eats". It's just an app to review restaurants, so maybe security isn't a top priority, or maybe Earl is evil and decides he wants to exploit his user base. Earl has thousands of JWTs. All of them are valid. All those users did really sign in to Earl's app.

Your app might be a higher security/risk/impact app however. Maybe it's a banking app. In the normal course of things: a user signs in, Google issues a JWT, you validate the JWT, you know who the user is, and you let them transfer money. If however Evil Earl starts sending you requests with JWTs he has accumulated from his users, you won't notice unless you are checking aud.

If you are using a big public issuer like Google, this is a huge problem. If you are using an internal JWT issuer, the issue is less severe, but it still opens you up to credential passing attacks.

TLDR

If you validate aud, a JWT says "This is Allice"

If you don't validate aud, a JWT says "This is Allice, or some one Allice trusts, or someone that person trusts, or someone they trust..."