Consider customizing 'azp' and 'aud' claims in ID Tokens #2042
Description
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!
