oauth2: Allow multiple audience claims on ID token

[lsthornt]

In our setup, we have a backend and frontend service that are both issued different client ids.

Once logged into the frontend service, we have an ID token with {aud: "frontend"}, but it cannot be used to make requests to the backend service, because the aud claim must match the client_id of the backend service.

OpenID Connect claims docs:

aud
REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.

Looks like #314 took care of making the claim an array, so presumably this would involve an addition to AcceptOAuth2ConsentRequest, potentially just a special case for when aud is included in Access/IdTokenExtra?

[aeneasr]

Sorry for my silence on this, but we tracked this issue internally and will address it with the 1.0.0 release!

[aeneasr]

This is an upstream issue in fosite (patch pending). When upgrading, we'll also have to change how IDTokenClaims is initialized in oauth2/handler.go.

[OvermindDL1]

For note, I'm trying to run the master HEAD version of hydra right now and multiple OpenID Connect libraries are reporting something akin to:

oauth2: error validating JWT token: audience in token does not match client key

Such as, for an open source example, the one at: https://github.com/go-gitea/gitea/blob/master/vendor/github.com/markbates/goth/providers/openidConnect/openidConnect.go#L202

[OvermindDL1]

And more testing, it looks like hydra is returning "aud":["my_client_id"] instead of "aud":"my_client_id", which is what these libraries expect. Any chance of hydra putting out a string instead of an array when it is only a single value?

[aeneasr]

This is tracked as #883

[aeneasr]

Regarding string/array - array MUST be supported according to spec. String MAY be supported, see JWT spec:

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.

[OvermindDL1]

Regarding string/array - array MUST be supported according to spec. String MAY be supported, see JWT spec:

Yep, I've already submitted a PR to them. Just curious if there is a way to just send a single string regardless when there is only a single string in the array, at the very least it lowers processing and network time every so tiny slightly. :-)

[aeneasr]

The issue is that the jwt-go library doesn’t support that very well at the moment. I’ll check into that again to confirm.

…

On 6. Sep 2018, at 17:51, OvermindDL1 ***@***.***> wrote: Regarding string/array - array MUST be supported according to spec. String MAY be supported, see JWT spec: Yep, I've already submitted a PR to them. Just curious if there is a way to just send a single string regardless when there is only a single string in the array, at the very least it lowers processing and network time every so tiny slightly. :-) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[OvermindDL1]

I think that was a similar issue the library itself had, they ended up writing their own (obviously incomplete) JWT handler, my fix for this issue for them is at: markbates/goth#240