Hey community, A question about accepting login requests (in Hydra 1.11.10) If the case of a "double submit", one of the accept login request works and returns a redirection to Hydra with a

login_verifier

, so that we get redirected to the consent URL. But if then another accept login request comes in with the same

login_challenge

, Hydra returns a 409 Conflict, which makes it impossible to get another URL with a

login_verifier

, so that we could still redirect to the consent URL in the end. Instead, we are only achieving to make the user restart entirely, get a new login challenge, having to enter credentials again. Has someone else encoutered this? Is there a way to workaround this? 🙂 🤔

Oh man, I was just coming here to post this very question. 409 responses are not documented, so I also want to know what's the proper thing to do with them. Should our delegate also return a 409? But I think your question is better. (Also on 1.11.10)

There's a redirect url in the response body of the error

Docs document only 200 and error. For the latter, the only fields documented are • error • error_debug • error_description • error_hint • status_code

right... I'm fetching the login request again, which may result in a 410 Gone if it has already been accepted (mind you, I'm currently using 1.10) but fetching the login request again to get the redirect url might be a route to take on 409 errors 🤷

That would make sense; these 4xx error responses could use some documentation tho

I'm fetching the login request again, which may result in a 410 Gone if it has already been accepted (mind you, I'm currently using 1.10) but fetching the login request again to get the redirect url might be a route to take on 409 errors

For now, that's what we ended up doing: on a 409, fetch the login request again. If the response it a 410 Gone with a

redirect_to

, redirect to this URL. However, this URL is actually (re)starting an OAuth2 flow. So our user experience is still degraded since they have to input their credentials again, but at least they are unblocked 😕

That sounds imperfect. Would be nice to get a 409 with a redirect URL if the accept login already exists and a 410 if it has expired

That would be great 🙏

Some related tickets: • Login request admin endpoints are unaware of login request having expired • feat: fail login request if request has expired

Thanks David for creating the issue 🙏

I'm wondering if there are concerns about replay attacks and that's why the auth flow is restarted 🤷🏼‍♂️

Yeah, I wondered about that, too. If so, it should be documented: Here's what to do with a 409 (or 410).

we're talking about user sessions too. setting cookies and sending session tokens, etc.

I think so, yes, but someone has to get their hands on the token, and if it's short-lived that seems unlikely. Much bigger issue for sessions of course, which tend to be long-lived