The current challenge is too long and may be mistakenly identified as risky by the browser

[ruchee-intrivo]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

The current challenge is too long and may be mistakenly identified as risky by the browser.

The challenge of v2.x is more than 1,000 characters, while the original challenge of v1.x is only a few dozen characters.

Is there a way to make the challenge shorter? I haven't found any place in the document to configure it.

Reproducing the bug

Occasional, may not always recur

Relevant log output

Relevant configuration

Version

2.2.0

On which operating system are you observing this issue?

macOS

In which environment are you deploying?

Kubernetes

Additional Context

No response

[SamP20]

It looks like this issue is closely related to #3777

From what I can tell, the reason the challenge is so long is because it contains the entire login/consent request state (compressed and encrypted).

The linked issue suggests solving it with a POST request. It could also be solved by storing the state in persistent storage, although I imagine that wasn't chosen as it would open Hydra up to potential DoS attacks.

[aeneasr]

An upgrade to 2.3.x should go a long way

[ruchee-intrivo]

An upgrade to 2.3.x should go a long way

The latest 2.3.0 is also very long. I ran the 2.3.0 demo locally and saw that it was more than 1,200 characters. 😂

[ruchee-intrivo]

It looks like this issue is closely related to #3777

From what I can tell, the reason the challenge is so long is because it contains the entire login/consent request state (compressed and encrypted).

The linked issue suggests solving it with a POST request. It could also be solved by storing the state in persistent storage, although I imagine that wasn't chosen as it would open Hydra up to potential DoS attacks.

Using POST instead sounds like a good idea. 👍

[aeneasr]

POST doesn't solve the challenge, because the redirect to the UI (303 /login?consent_challenge=...) still needs to happen which can't be done with a POST unless we do some hidden iframe stuff that will for sure not work once 3P cookies are no longer working. We have it on the roadmap to further reduce the size of the challenge, right now it's not causing issues in our systems. You should consider reducing the payload you're sending as part of accept login/consent.

[ruchee-intrivo]

@aeneasr Is it possible to leave a place in the configuration to allow the generation of short challenges? 😂

[vdbulcke]

POST doesn't solve the challenge, because the redirect to the UI (303 /login?consent_challenge=...) still needs to happen which can't be done with a POST unless we do some hidden iframe stuff that will for sure not work once 3P cookies are no longer working. We have it on the roadmap to further reduce the size of the challenge, right now it's not causing issues in our systems. You should consider reducing the payload you're sending as part of accept login/consent.

Wouldn't it be possible to have solution similar to OIDC response_mode=form_post (https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) but instead between the hydra server and the login/consent UI?

The OIDC response_mode=form_post is working with a auto-submitted form POST request from the Authorization Server domain to the Relying Party domain (i.e. cross site request) as long as the required cookies for the flow (e.g. csrf) have the proper flags (Secure, SameStite=None https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#none).

So since hydra already have configuration settings for its cookies, I suppose it should be feasible to have a config flag allowing to perform the redirect from the hydra server to login/consent (and from login/consent to hydra server) using a very similar auto-submitted html form as the one described in the OIDC spec:

For example, a response from the authorization endpoint of hydra when redirecting to the login UI via HTML form post:

  HTTP/1.1 200 OK
  Content-Type: text/html;charset=UTF-8
  Cache-Control: no-cache, no-store
  Pragma: no-cache
  Set-Cookie: hydra_csrf_cookie=[cookie value];  Max-Age=300; Path=/; Domain=hydra.domain.example.com; Secure; HttpOnly; SameSite=None


  <html>
   <head><title>Submit This Form</title></head>
   <body onload="javascript:document.forms[0].submit()">
    <form method="post" action="https://login.page.domain.example.com/login">
      <input type="hidden" name="login_challenge" value="[large login challenge value]" />
    </form>
   </body>
  </html>

I understand that this is not an ideal situation, because browsers may invent new cookie restriction in the future. And if it is in the roadmap to have a reasonable upper bound on the request size, that would solve the underlying problem.

However, as long as it is not possible to guarantee a reasonable upper bound it would be required that every single middlebox (F5, firewall, reverse proxy, etc) in the request path must be adapted to allow those large request. In some environment this can be quite challenging because it is not the same team managing those middleboxes as the team managing the hydra server.

@aeneasr if you think this is an idea worth implementing, let me know. I can try to implement this and submit a PR.

[aeneasr]

Thank you very much for the great write up!

I think that hidden post form submit on the login and consent challenge are challenging - because the app needs to keep state now of the challenge so that when the user agent opens the page the correct flow is used. That’s security relevant! This can be done with cookies (which also have upper bounds!!) but as noted before, there is an industry wide push to deprecate third party cookies and Safari already blocks a lot of it. And hidden JS initiated form submit to potentially another (sub-)domain falls under this category. I feel like we need to solve this in a way where we aren’t changing the API again in a year or two.

Cutting down the unused data in the challenge/response bit by bit is a painful but probably necessary process to reduce the challenge size. It’s not on the immediate roadmap though because it works for us and our customers in the current set up very well and we have no commercial demand to prioritize this right now.