The

granted_audience

should be included in the payload sent to the webhook URL. If it's not included, there might be an issue with how the consent request is being handled. When performing the Client Credentials Grant, the

audience

parameter from the POST body of the

/oauth2/token

request is decoded and validated according to the rules described in the previous section, excluding login and consent, which are not a part of this flow [source](https://www.ory.sh/docs/hydra/guides/audiences#audiences-in-client-credentials-grant). In the consent endpoint code example, the

grant_access_token_audience

is set to

body.requested_access_token_audience

[source](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#consent-endpoint-code-example). If the consent is skipped, the consent request is accepted immediately with

grant_scope: challenge.requested_scope

and

grant_access_token_audience: challenge.requested_access_token_audience

[source](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#implementation). If the

granted_audience

is not being received, it might be due to the consent being skipped. When the consent is skipped, the

grant_access_token_audience

is set to

challenge.requested_access_token_audience

. If the

requested_access_token_audience

is not set in the challenge, then the

granted_audience

might not be included in the payload. You might want to check the

requested_access_token_audience

in the challenge when the consent is skipped. If it's not set, you might need to set it before skipping the consent.

If you're using the

authorization_code

grant type and not receiving the

granted_audience

in your webhook, it might be due to the way the authorization request is being made or how the consent flow is being handled. In the Authorization Code flow, the client needs to include the

audience

parameter in the authorization request. This

audience

parameter should match the

aud

claim in the ID Token [source](https://www.ory.sh/docs/hydra/guides/audiences#audiences-in-authorization-code-grant). The

audience

parameter is then included in the consent request and needs to be accepted in the consent flow. If the consent is skipped, the

grant_access_token_audience

is set to

challenge.requested_access_token_audience

[source](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#implementation). If the

requested_access_token_audience

is not set in the challenge, then the

granted_audience

might not be included in the payload. You might want to check the

requested_access_token_audience

in the challenge when the consent is skipped. If it's not set, you might need to set it before skipping the consent. If you're still having issues, you might want to check the client configuration. The client needs to be allowed to request the

offline_access

scope and the user has to accept that the client may use the

offline_access

scope on the consent screen [source](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow#get-a-refresh-token). You can check the client configuration using the

ory get oauth2-client {client.id}

command [source](https://www.ory.sh/docs/hydra/debug#refresh-token-flow-fails).

If you're using the

kratos-selfservice-ui-node

for the consent screen, it's important to ensure that the consent flow is correctly implemented. In the

kratos-selfservice-ui-node

, the consent flow is handled by the routes defined in the application. For example, the registration route is defined in

src/routes/registration.ts

[source](https://raw.githubusercontent.com/ory/kratos-selfservice-ui-node/master/src/routes/registration.ts#L0-L0). The views for these routes are defined in the

views

directory. For example, the registration view is defined in

views/registration.hbs

[source](https://raw.githubusercontent.com/ory/kratos-selfservice-ui-node/master/views/registration.hbs#L0-L0). If the

granted_audience

is not being received, it might be due to the consent being skipped. When the consent is skipped, the

grant_access_token_audience

is set to

challenge.requested_access_token_audience

. If the

requested_access_token_audience

is not set in the challenge, then the

granted_audience

might not be included in the payload. You might want to check the

requested_access_token_audience

in the challenge when the consent is skipped. If it's not set, you might need to set it before skipping the consent. If you're still having issues, you might want to check the client configuration. The client needs to be allowed to request the

offline_access

scope and the user has to accept that the client may use the

offline_access

scope on the consent screen [source](https://www.ory.sh/docs/oauth2-oidc/authorization-code-flow#get-a-refresh-token). You can check the client configuration using the

ory get oauth2-client {{client.id}}

command [source](https://www.ory.sh/docs/hydra/debug#refresh-token-flow-fails).

If you've confirmed that

grant_access_token_audience

is correctly assigned to

body.requested_access_token_audience

in the consent challenge acceptance, the issue might lie elsewhere. Here are a few things you could check: 1. Audience Parameter in Authorization Request: Ensure that the

audience

parameter is included in the authorization request and that it matches the

aud

claim in the ID Token [source](https://www.ory.sh/docs/hydra/guides/audiences#audience-in-authorization-code-implicit-and-hybrid-flows). 2. Client Configuration: Check the client configuration to ensure that the client is allowed to request the necessary scopes. You can check the client configuration using the

ory get oauth2-client {{client.id}}

command [source](https://www.ory.sh/docs/hydra/debug#refresh-token-flow-fails). 3. Consent Flow: Ensure that the consent flow is correctly implemented. If the consent is skipped, the

grant_access_token_audience

is set to

challenge.requested_access_token_audience

. If the

requested_access_token_audience

is not set in the challenge, then the

granted_audience

might not be included in the payload [source](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#implementation). 4. Webhook Implementation: Check your webhook implementation to ensure it's correctly processing the payload and that there are no issues with how it's handling the

granted_audience

. If you've checked all of these and are still experiencing issues, it might be worth reaching out to the Ory community or support for further assistance.

The

aud

(audience) claim in the ID Token is intended for the client that requested the token. In the context of OAuth 2.0 and OpenID Connect, there are two types of audience concepts: - OAuth 2.0 access token audience: The

aud

claim of an OAuth 2.0 access token defines the endpoints at which the token can be used. - OpenID Connect ID token audience: The

aud

claim of an OpenID Connect ID Token defines which clients should accept it. It MUST contain the OAuth 2.0

client_id

of the Relying Party as an audience value [source](https://www.ory.sh/docs/hydra/guides/audiences). If you're seeing a UUID in the

aud

claim of the ID Token, it's likely the

client_id

of the client that requested the token. This is expected behavior as per the OpenID Connect specification. If you're expecting to see a different audience in the

aud

claim, you might want to check the audience parameter in the client's metadata and the audience parameter in the authorization request [source](https://www.ory.sh/docs/hydra/guides/audiences#add-audiences-to-the-client-allow-list). Remember that certain keys (such as the

sub

) claim can't be overwritten [source](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#id_token-claims).