Consider customizing 'azp' and 'aud' claims in ID Tokens

[rocketk]

Is your feature request related to a problem? Please describe.

According to the OIDC specification:

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.

azp OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The azp value is a case sensitive string containing a StringOrURI value.

I think the 'azp' is the relying party client that the ID Token is issued to (which RPC requested the ID Token), and the 'aud' is the relying party client that the ID Token is intended for (which RPC will finally consume the ID Token).

In most cases the 'aud' and 'azp' are the same one, but in other cases they are not.

For example, I have a front-end SPA and several backend services with different client_id, let’s say “spa”, “service1”, “service2”. I initiate the authentication flow with my SPA, and then I want the SPA to get an ID Token that “aud” equals to [“service1”, “service2”] and “azp” equals to “spa”.

I think that will be useful for mobile native apps or single page apps.

Describe the solution you'd like 'azp' and 'aud' in a id_token can be different. 'azp' is the client_id who initializes the request flow (like authorization flow). 'aud' is the client_id who will finally consume the id_token, 'aud' may be a string or an array.

Describe alternatives you've considered

Additional context

I captured some network traffic of google oidc flow (with a third-party iOS app and its backend service), the id_token that google issued had both 'azp' and 'aud' claims with different values, so I guess one of them was the client_id of the iOS app and the other one was the client_id of its backend service.

So will this feature be implemented in future version of hydra?

Thanks!

[aeneasr]

Tracking as a feature, contribs welcomed :)

[rocketk]

Tracking as a feature, contribs welcomed :)

Thanks, I'm learning the source code of hydra, but it's not that easy for me now. thanks for accepting this suggestion to the next version.

[v4rn]

@aeneasr New here. Can I pick this issue?

[ashutosh887]

Please let me work on this Issue

[kmherrmann]

Contributions welcome! A short outline of the implementation design would be a great first step. thanks!

[rajrohanyadav]

Hi,

I found below updates to the OIDC spec, that clarify the azp and aud situation. Core 2 / 3.1.3.7 - azp claim underspecified and overreaching PR-340: errata-clarified-that-azp-does-not-occur

Initial request:

For example, I have a front-end SPA and several backend services with different client_id, let’s say “spa”, “service1”, “service2”. I initiate the authentication flow with my SPA, and then I want the SPA to get an ID Token that “aud” equals to [“service1”, “service2”] and “azp” equals to “spa”.

I don't think the clarified spec supports the initial request even with this feature implemented. In the above case, the structure after including azp in ID token would be (refer):

{
    ...
    "aud": ["service1", "service2", "spa"],
    "azp": "spa"
    ...
}

In short,

• azp: Store the audience that got the token issued
• aud: Store a list of all audiences Therefore, azp would always be an item from the aud list.

Let me know your thoughts.

Thanks, Rohan

[toonalbers]

As a partial solution for customizing the audience, I'm using the following: https://github.com/toonalbers/hydra/commit/f7d3a2fdd6cdf1657b68bf7c3875cee2d484dc6f (I did not include changes for azp)