Granted audience not set in OIDC token

[kewde]

Describe the bug
The granted audiences are not included in the OIDC token. The aud field always contains merely the clientID.

This is not conforming to the spec AFAIK.
https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.2

To Reproduce
Steps to reproduce the behavior:
Request custom audience and grant it with the consent accept.
Taking a look at the sessions for this particular user, the granted audiences look alright!

[
  {
    "grant_scope": [
      "openid",
      "scope1",
      "scope2"
    ],
    "grant_access_token_audience": [
      "https://CUSTOMAUDIENCEURL/"
    ],
    "session": {
      "access_token": {},
      "id_token": {
        "email": "REDACTED"
      }
    },
    "remember": false,
    "remember_for": 3600,
    "consent_request": {
      "challenge": "ccbb70cbd2694076959d5734b073c2ba",
      "requested_scope": [
        "openid",
        "scope1",
        "scope2"
      ],
      "requested_access_token_audience": [
        "https://CUSTOMAUDIENCEURL/"
      ],
      "skip": false,
      "subject": "REDACTED",
      "oidc_context": {},
      "client": {
        "client_id": "website",
        "client_name": "website",
        "redirect_uris": [
          "https://localhost/"
        ],
        "grant_types": [
          "authorization_code"
        ],
        "response_types": [
          "code"
        ],
        "scope": "openid scope1 scope2",
        "audience": [
          "https://CUSTOMAUDIENCEURL/"
        ],
        "owner": "",
        "policy_uri": "",
        "allowed_cors_origins": null,
        "tos_uri": "",
        "client_uri": "",
        "logo_uri": "",
        "contacts": null,
        "client_secret_expires_at": 0,
        "subject_type": "public",
        "jwks": {
          "keys": null
        },
        "token_endpoint_auth_method": "client_secret_basic",
        "userinfo_signed_response_alg": "none",
        "created_at": "2019-01-18T22:30:10Z",
        "updated_at": "2019-01-18T22:30:10Z"
      },
      "request_url": "REDACTED",
      "login_challenge": "c6a4524e995a4af4bf9d7a7003fe140b",
      "login_session_id": "",
      "acr": ""
    }
  }
]

We grab the OpenID Connect token and decode the second part to:

{"at_hash":"cQ6HWugWTY1tEQ-AJw3eoQ","aud":["website"],"auth_time":1547851671,"email":"REDACTED","exp":1547855271,"iat":1547851671,"iss":"http://localhost:4444/","jti":"e8b7e7bb-3c52-418d-bdde-560ac76e0499","nonce":"","rat":1547851671,"sub":"REDACTED"}

The aud element is still set to just website, whilst we additionally granted the scope https://CUSTOMAUDIENCEURL/

Expected behavior
We expect the audiences to be included in the OpenID Connect token.

Version:

• Environment: Debian
• Version v1.0.0-rc5

[kewde]

Perhaps an issue in Fosite.

The exact line in Fosite where the ID token is generated and the field gets set:
https://github.com/ory/fosite/blob/4e4121bac5cda8efa7d3eb6aaf7720f3ff59c329/handler/openid/strategy_jwt.go#L233

The Audience is retrieved from the "Claim". I've tried including it in "aud" field in the claim, but it seems (understandably so) to have gotten filtered out somewhere but not replace with the granted audiences.

[aeneasr]

You're setting the access token audience but expect the id token audience to be different - here lies the problem. The ID Token audience is usually only the client id. The access token audience might be different because you may want the access token to be applicable only for certain resource servers.

[kewde]

You're setting the access token audience but expect the id token audience to be different

I was actually setting the access token audience array (using the granted option through consent accept) and expecting the id token audience array to be the same.

[aeneasr]

Those are conceptually different:

• The access token audience targets the resource servers (your internal stuff / first party)
• The id token audience targets the relying party (the third party / client / external developer)

Therefore it doesn't make sense for the two to be equal.

[kewde]

Hmm, what options do I have to set id token audience in hydra? I can get around it, but I'd like to adhere to the terminology of the spec.

I have a single page application (clientid=website) which wants to interact with a resource server (clientid=secrets). website retrieves the ID Token and want to use it to authenticate to secrets.

Relying Party (RP)
OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.

My relying party is not the requester (website) but secrets, a resource server.

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.

The authorized party (field=azp) is in my case the client website.

[aeneasr]

The ID token is used to authenticate at the client side, not the first party resource server (secrets). If you want to access a resource at secrets simply use an access token.

[kewde]

I'll close the issue, thanks for the information.

The secrets only allows inbound connections for a specific port, no outbound connections are allowed so it can not retrieve the id token from Hydra using the access token. (I intended to have the JWKs/Signing keys preloaded).
I could setup exceptions in the firewall but the statelessness of the OIDC tokens is an interesting property I want to maintain.