Closed Conduitry closed 1 year ago
I'm able to reproduce this with the quickstart app here by editing quickstart.yml
to include a short value for the TTL_LOGIN_CONSENT_REQUEST
environment variable.
The logs indicate that the GET to retrieve the login request and the PUT to accept the login request both succeed, and then browser is redirected to http://127.0.0.1:4444/oauth2/auth?xxx which then redirects to http://127.0.0.1:5555/callback?error=request_unauthorized&error_description=The+request+could+not+be+authorized.+The+login+request+has+expired.+Please+try+again.&state=xxx
any plan on this case? I would like to get the status of whether the login request is expired through Hydra Admin endpoints,
So that we can handle expired login requests at the login provider
side, instead of redirect expired error messages to client side. if the system has many clients, It's a repetitive job.
So do we have any other way to get expired information of login request from Hydra Admin endpoints? @aeneasr
For context please see: https://github.com/ory/hydra/pull/2823#issuecomment-953953549
We could probably include the expired property in the response, helping you identify when such a request has expired
Hello contributors!
I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.
Unfortunately, burnout has become a topic of concern amongst open-source projects.
It can lead to severe personal and health issues as well as opening catastrophic attack vectors.
The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.
If this issue was marked as stale erroneously you can exempt it by adding the backlog
label, assigning someone, or setting a milestone for it.
Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!
Thank you 🙏✌️
Describe the bug
Hydra Admin endpoints do not appear to be aware of when a login request has already expired. Depending on OpenID client configuration, this will result in an error message being displayed to the end user that the identity provider using Hydra has no way of knowing about or guarding against.
Reproducing the bug
Steps to reproduce the behavior:
/oauth2/auth/requests/login
and/oauth2/auth/requests/login/accept
succeed./oauth2/auth
fails.Server logs
The first four entries here are the successful get login request and the accept login request. After that are the browser's (redirected) request to the public OAuth endpoint and its subsequent redirection to the OpenID client's callback endpoint with the error.
Server configuration
The
TTL_LOGIN_CONSENT_REQUEST
of1m
is just there to make reproducing this more convenient.Expected behavior
When Hydra Admin is queried to get a login request, the response should indicate in some way that this login request is expired. This could be with an error response from
GET /oauth2/auth/requests/login
andPUT /oauth2/auth/requests/login/accept
or it could be with another field in theGET /oauth2/auth/requests/login
response.I do see that
GET /oauth2/auth/requests/login
tells when when the login request was created, but it shouldn't be my identity provider's responsibility to know what TTL Hydra happens to be configured with at the moment (nor does there seem to be a way to directly query Hydra for this information).Environment
Additional context
If end users can generate new login requests on demand, what sort of attack is having a limited TTL on the login request attempting to mitigate?