Hi! Accoding to the getOAuth2LoginRequest API documentation,

requested_access_token_audience

should be an array of strings. However, the JSON response from hydra contains

"requested_access_token_audience": null

. Thefore deserialization fails in hydra-client-rust. Any idea how to solve this problem?

This probably needs to be fixed in Hydra itself. Did you encounter any other serialization problems?

No other serialization problems yet. However, there seems to be a mismatch between the

.challenge

in the login request and the

.login_challenge

in the consent request (in the same flow). The first is a relatively large (1129 Bytes) base64-encoded value and the latter is a smaller (16 Bytes) hex-encoded value. AFAIK they should be equal, when they belong to the same flow.

That's entirely possible and comes from a semi-recent change in how the flow is implemented: https://www.ory.sh/oauth2-oidc-server-performance-tuning-scale/ Did you encounter this mismatch while interacting with Hydra's APIs or while looking at the internals? Only the long ID should be necessary when talking to Hydra via API.

I want to make sure that a login flow and a consent flow that belong together are performed within the same browser session. This mitigates a certain class of attacks. To do so, I bind the login challenge to the user's session at the IdP. So far so good. But as soon as the user gets redirected to the consent UI, the login challenge (obtained from

consent_request.login_challenge

) is a different one (the short one), so it's not bound to the user and my mitigation prohibits the user from proceeding.

I'm delighted you're already working on a mitigation ❤️ It's been a while since I looked at the persistence code in this part of hydra. The short ID is mostly (exclusively?) used as a database key. I don't think we persist the long ID (not persisting that was the whole point of the optimization). But it's probably possible to change that.

It wouldn't need to be persisted. It would be sufficient if the long ID contains the short ID somewhere. Though when decoding the base64, I get some binary data that doesn't seem to contain the short ID as a subslice.

The long ID contains the complete flow structure, encoded as gzipped json and aead-encrypted.

Then the encryption would prevent the IdP from extracting the short ID.