Suggestion: Allow audience validation against collection of valid audiences

[serioga]

I suggest to improve validation for aud so that we can use collection for “valid audience” but not a single value only.

buddy-sign/src/buddy/sign/jwt.clj

Lines 27 to 28 in 2009c4d

	Checks one or more audiences in the `:aud` claim against the single valid audience in the passed `:aud`.
	If no `:aud` is passed, this check is not performed.

[iarenaza]

Hi @serioga

This feature has existed since at least version 2.0.0. The documentation doesn't state it explicitly, but both iss and aud claims can be a collection of values.

So maybe the issue should be about updating the documentation to reflect the code behavior 😃

[iarenaza]

Sorry, my bad. I read the code wrong 😞 The code allows for a collection of audiences in the token itself, not in the verification claims. The original issue still stands.

[dpiliouras]

Why would you want multiple audiences at the point of verification? The way i see it, you might need multiple audiences at the point of issuing (i.e. producer/issuer supports multiple consumers/audiences), but the service that verifies is the audience, right? So that service just needs to be one of the issuer audiences. The code looks fine to me regarding that, unless I'm missing something big...

The documentation improvement definitely stands though 👍

In other words, assuming two generate (producer) and verify (consumer) functions, here are the params they could take:

{:generate {:issuer "com.foo.auth"            ;; single issuer (identification)
            :audiences ["foo-auth-service"]   ;; can address multiple audiences
            :ttl-max-hours 3}                 ;; max-age (allows clients to ask for custom exp)
 :verify {:issuers ["com.foo.auth"]           ;; can verify against multiple issuers
          :audience "foo-auth-service"        ;; single consumer (identification)
          :leeway 15}}

[iarenaza]

Why would you want multiple audiences at the point of verification? The way i see it, you might need multiple audiences at the point of issuing (i.e. producer/issuer supports multiple consumers/audiences), but the service that verifies is the audience, right? So that service just needs to be one of the issuer audiences. The code looks fine to me regarding that, unless I'm missing something big...

It depends on whether you are thinking about OAuth2 or OpenID Connect (our use case). In the former, where the JWT is an access token, the service that verifies the token is the audience. But in the latter, it may not be (and in our case, it is not). Because in OpenID Connect you also use have JWT tokens for Authentication (when using ID Tokens). And in that case, multiple different Relaying Parties[1] may use the same OpenID Provider [2].

This is exactly our case. We have three Relaying Parties: a mobile app, embedded hardware and a single page application. We have them as three separate Relaying Parties because we want to restrict the allowed authentication and authorization flows depending on the type of client. E.g., embedded devices can't use Authorization Code flow, only implicit flow. But we don't want to enable implicit flow in the other two cases. So we have three relaying parties, each with its own client_id value (hence, their own aud value in the ID Tokens issued by the OpenID Provider).

But all of them use their ID and Access tokens with the same REST service. So we need to be able to validate ID and Access tokens with three different aud values. Probably this is not a very common case, but it's exactly what we are doing in several of our projects. We routed around this "limitation" in our code since the beginning, but it makes the validation slower due to having to catch the exceptions, etc.

[1] OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider, from https://openid.net/specs/openid-connect-core-1_0.html#Terminology
[2] OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User, from same URL as note [1]