Access Token audience claim

[sagarshah1983]

Hello,
From the documentation here, I see the aud claim during token introspection endpoint (for a token create using authorization code workflow) invocation, but when I try the same on my hydra instance. I only see following elements.

Am I missing some configuration to enable or support aud claim in the token.
{ "active": true, "scope": "openid offline_access", "client_id": "enterprise", "sub": "sagar", "exp": 1608050407, "iat": 1608046806, "iss": "http://127.0.0.1:9000/", "token_type": "access_token" }

Client is set up with this audience.
"audience": [ "https://api.my-cloud.com/user" ]

Note: I am using 1.7.4 version of Hydra.
Please let me know, if any client configuration is required to be set to return audience claim in the token introspection

Appreciate your inputs!

[vinckr]

Hey,

I would like to reproduce your issue, could you tell me how to set it up?

We have documentation on advanced Oauth2 flows, including audience, maybe that can clear things up here.

URLs must not contain whitespaces

Maybe "audience": ["https://api.my-cloud.com/user"] fixes it? (Without whitespace before/after audience)

[sagarshah1983]

Thanks for getting back on this. Here are the steps at high level. I am not sure, if I missed something or if its a version issue of Hydra or a bug.
Please let me know, if any additional details are needed. In below example, I am using client_credentials grant to get token to simplify, but I tried the same with auth flow with user login too and I see no aud claim in token when performing introspection.

1. set SECRETS and DSN env variables
2. docker run -it --rm --network hydraguide oryd/hydra:v1.7.4 migrate sql --yes $DSN
3. Start container - docker run -d
   --name ory-hydra-example--hydra
   --network hydraguide
   -p 9000:4444
   -p 9001:4445
   -e SECRETS_SYSTEM=$SECRETS_SYSTEM
   -e DSN=$DSN
   -e URLS_SELF_ISSUER=http://127.0.0.1:9000/ \
   -e URLS_CONSENT=http://127.0.0.1:8080/consent.html
   -e URLS_LOGIN=http://127.0.0.1:8080/login.html
   -e TTL_REFRESH_TOKEN=2190h
   oryd/hydra:v1.7.4 serve all --dangerous-force-http
4. Create a client - docker run --rm -it --network hydraguide oryd/hydra:v1.7.4 clients create --endpoint http://ory-hydra-example--hydra:4445 --id client --secret secret --grant-types client_credentials --response-types token,code --audience "http://test.com"
5. curl --location --request POST 'http://127.0.0.1:9000/oauth2/token'
   --header 'Authorization: Basic Y2xpZW50OnNlY3JldA=='
   --header 'Content-Type: application/x-www-form-urlencoded'
   --data-urlencode 'grant_type=client_credentials'
6. Response as below
   { "access_token": "Vedfp2ecMdI62Np-hCAU6H0tt0APUVVo7Ib2d4NqYpM.YAIiMdaZu45RXA6bnyjCj87tVsNjBgzbWF8NbxelMTM", "expires_in": 3599, "scope": "", "token_type": "bearer" }
7. Introspection call
   curl --location --request POST 'http://localhost:9001/oauth2/introspect' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --header 'Accept: application/json' \ --data-urlencode 'token=Vedfp2ecMdI62Np-hCAU6H0tt0APUVVo7Ib2d4NqYpM.YAIiMdaZu45RXA6bnyjCj87tVsNjBgzbWF8NbxelMTM'
8. Response
   { "active": true, "client_id": "client", "sub": "client", "exp": 1608133165, "iat": 1608129564, "iss": "http://127.0.0.1:9000/", "token_type": "access_token" }
   Appreciate your help!

[vinckr]

Hey, so I tried to reproduce it, but I ran the latest hydra version 1.9.0.-alpha.3 and this this was my introspection response:

{
        "active": true,
        "aud": [],
        "client_id": "my-client",
        "exp": 1608142085,
        "iat": 1608138485,
        "iss": "http://127.0.0.1:4444/",
        "nbf": 1608138485,
        "sub": "my-client",
        "token_type": "Bearer",
        "token_use": "access_token"
}

This was my response for some random strings

{
        "active": false,
        "aud": null
}

Maybe you cant see the aud field because of your version? Is there a specific reason why you want to use 1.7.4?

[sagarshah1983]

Thanks for getting back again. We had started our initial research on 1.7.4 on our test servers so we just continued there. we can definitely upgrade with small effort but that being shared environment I was trying not to change anything, if possible. and I tried the same settings locally to reproduce. I will check with latest 1.9.0 alpha and plan to migrate and if that works, will plan on upgrading.

[sagarshah1983]

@vinckr Thanks for your help!
I fixed it locally with an upgrade to 1.9.0. That worked smooth, but I too see aud as an empty array []. I have set the audience for the client, should I not be expecting that in the access token response with aud claim? Or do I have to do anything custom to set that aud claim in the access token respomse?

[sagarshah1983]

I am still unclear on how do I expect the value to be populated in "aud" claim of token introspection. Is there a documentation to refer to it? Or is this a bug?

[vinckr]

What command did you run? The same as before just with a different version?
Did you use the same steps as you mentioned before?

Did you set the audience like this?
"audience": ["https://api.my-cloud.com/user"] .
Could you provide your config file, that would help alot!

Also feel free to contact me directly on Slack.

Cheers :)

[sagarshah1983]

Thanks for responding. I sent messages in slack indicating the steps. I followed same steps after upgrading Hydra and now I am getting aud claim in token, but it's value is an empty array every time.

[vinckr]

Was able to reproduce the problem and have the same response

{
	"active": true,
	"aud": [],
	"client_id": "client",
	"exp": 1608647202,
	"iat": 1608643601,
	"iss": "http://127.0.0.1:4444/",
	"nbf": 1608643601,
	"sub": "my-client",
	"token_type": "Bearer",
	"token_use": "access_token"
}

What are we missing here? @aeneasr

[sagarshah1983]

Has there been any progress on this further? Please advise, if I should report it as bug. It seems somewhat similar to #2266

[aeneasr]

The audience is empty unless specified in the OAuth2 request. The values in the client are meant as a allow-list so the request initiator can only request the audience allowed by the client or no audiences at all. To set these values in the request check out the answer from @k9ert here: #2266 (comment)

[sagarshah1983]

I realized what I was missing in Authorization flow from here - https://www.ory.sh/hydra/docs/advanced/.
I had not set grant_access_token_audience during approval of the consent.

Also, I noticed that for client token flow, I can get the access token back in token, when audience is passed in the token request. This can be closed.

Thank you for all the suggestions and clarifications @aeneasr