Multiple audiences and JWT validation

[richardprice]

Looking at the code for audience validation:

if len(e.Audience) != 0 {
	for _, v := range e.Audience {
		if !c.Audience.Contains(v) {
			return ErrInvalidAudience
		}
	}
}

It looks like the intention there is to require the JWT to have all of the expected audiences, and fails if one is missing from the JWT, is that correct?

For example, if the JWT has an audience claim of https://my-resource-server, and the resource server has an audience configuration of [ "https://my-resource-server", "https://my-other-server"] then the validation will fail, because the JWT does not include https://my-other-server as an audience claim.

Other implementations I have used approach multiple audiences on the resource server side as a "can be any one of these" validation check, rather than "must be all of these" validation check, which would allow the resource server to serve content for multiple audiences.

Is the current approach intentional or would you be open to a PR changing its behaviour?

[therealsphinx]

@richardprice What is the impact here?

[agnewp]

i ran into this as well. my expectation is the audience in the claim is contained within the expectations. NOT the other way around. the impact is that i can not check for audience using your library without a audience validation error

[richardprice]

@richardprice What is the impact here?

The impact is that if you list 4 audiences in your service, the validation currently requires all 4 to exist in your token.

The change I propose would reverse that - you list 4 audiences in your service, the token can have any single one of those audiences and it would successfully validate.

[shnmorimoto]

Currently, I'm facing same issue.
Any update this?

If this behavior is correct as JWT. I can raise PR.

The change I propose would reverse that - you list 4 audiences in your service, the token can have any single one of those audiences and it would successfully validate.

[richardprice]

Currently, I'm facing same issue.

Any update this?

If this behavior is correct as JWT. I can raise PR.

The change I propose would reverse that - you list 4 audiences in your service, the token can have any single one of those audiences and it would successfully validate.

Never got a response, but the behaviour I suggest is how Microsoft handles it in ASP.Net Cores token validation (any single audience in the token matches any single audience in the services configuration validates - once it finds the first match it stops checking) - https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/92d3f24cdcb0d148d1a8c236bc073157e776f4d5/src/Microsoft.IdentityModel.Tokens/Validators.cs#L137

[jsha]

Confirming that the new behavior is correct per RFC 7519 Section 4.1.3:

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. In the general case, the "aud" value is an array of case-
sensitive strings, each containing a StringOrURI value. In the
special case when the JWT has one audience, the "aud" value MAY be a
single case-sensitive string containing a StringOrURI value. The
interpretation of audience values is generally application specific.
Use of this claim is OPTIONAL.

(emphasis mine)

Edit: actually, now I understand this change better and I'm not so sure about correctness; the RFC seems to envision that each principal identifies itself with a single value, not multiple.