openID connect id_token policy key

Hi,

We’re trying to use hydra to authenticate against a minio instance using a security token. We’ve gotten most of it to work, but Minio expects a policy claim in the OIDC token.
Is this something we can manage to do using hydra? Or can we use oathkeeper to mutate an existing token and add the missing key?

Thanks
M

I’m not 100% sure but I think the openid connect session data is merged into the toplevel of the JWT claim, right?

Hi @hackerman,

Thanks for the quick reply! Indeed, all available data is merged into the top level as far as I can see. We’d expect to see a policy claim in the token, but it’s not there.
Do we need to add this ourselves during the consent step of through oathkeeper? I supposed this claim is part of the standard.

thanks again
M

If it’s merged into the top level then you should be able to set policy though, right? I’m talking about the openid connect session data you establish when accepting consent

To give a more detailed explanation:

  • When ConsentRequest is accepted a “policy” claim is added to the AccessToken & IDToken
Session: &models.ConsentRequestSession{
  AccessToken: map[string]interface{}{"policy": "readonly"},
  IDToken:     map[string]interface{}{"policy": "readonly"},
},
  • I can verify this is added to the session as a request to the REST API /oauth2/auth/sessions/consent
    show the added policy claim:
"session":{"access_token":{"policy":"readonly"},"id_token":{"policy":"readonly"}}
  • The access code is then used to Exchange and obtain an jwt encoded openid token
    which does contain the "policy":"readonly" jwt claim as expected

  • We restart the flow again in exactly the same way and ask for a new access code and exchange it to get an id_token
    but now the "policy":"readonly" jwt claim is gone in the openid token

I would have expected these additional/custom claims to always be present even if this second code/token flow reuses the accepted consent request ( we set Remember = true in the consent app ).

Additionally these additional/custom claims saved in the session during accept consent aren’t present in the userinfo response nor in the introspect response

Are we trying to add these additional/custom claims the wrong way or is this a bug? Or is the remember consent functionality causing this?

If you redo the consent flow, you need to set the session again with that data. Hydra does not assume that the claims should be the same again, you have to do that explicitly.

Pretty sure this is covered by tests and supported - make sure you’re running the latest version of ORY Hydra. If not, please open a bug report with reproducible steps!

We were already sending the additional session claims again when accepting even when Skip=true. Knowing this and you now confirming this is how it should work, led me into looking at other possible causes and I found out one of our nodes in the container cluster didn’t pull in the latest consent app image version (older version wasn’t setting the additional session claims when skip=true).

This also explains why in previous tests we didn’t notice the “bug” of missing claims as at that time it was probably running on a node dat did have the updated image. When the latest hydra version was released we also restarting all hydra related services, the consent app ended up on the “broken” node, with the old image but since this coincided with the hydra upgrade I thought (wrongly) the cause would be in an undocumented change or bug.

So in the end I got it all running as expected now thanks to your assistance even-though the cause ended up being on our side :blush:

Glad to hear you got it figured out! Happy to help