Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow falling back to anonymous authenticator when previous authenticator matches but fails. #682

Closed
cameron-martin opened this issue Mar 28, 2021 · 7 comments
Labels
stale Feedback from one or more authors is required to proceed.

Comments

@cameron-martin
Copy link
Contributor

cameron-martin commented Mar 28, 2021

Is your feature request related to a problem? Please describe.

I have some endpoints that are accessible to anyone, but the API server is still interested to know who the user is if they are authenticated. These routes have two authenticators defined, cookie_session and anonymous, the intention being that the anonymous one is fallen back on if the cookie_session one fails. However, if a session is present but has expired then oathkeeper returns a 401 and does not fall back to the anonymous authenticator. According to the documentation this is intentional:

If handler a is able to handle the provided credentials, then handler b and c will be ignored.

Describe the solution you'd like

Possibly there could be an extra option in the authenticator configuration in the access rules to allow falling through to the next authenticator upon failure.

Describe alternatives you've considered

The default could be to fall through to the next authenticator upon failure, but I'm sure there is a good reason why this is not done.

Additional context

None

@cameron-martin cameron-martin changed the title Allow falling back to anonymous authenticator when Allow falling back to anonymous authenticator when previous authenticator matches but fails. Mar 28, 2021
@aeneasr
Copy link
Member

aeneasr commented Mar 29, 2021

This is tricky as misconfiguration - or assuming fallthrough per default - will lead to security issues as you can now access stuff without any credentials. The default should always be: "you are not allowed to do this" - so explicitly allowing stuff.

I understand the use case though, not sure how to implement it best however. Maybe something with error handling?

@cameron-martin
Copy link
Contributor Author

cameron-martin commented Mar 29, 2021

This is tricky as misconfiguration - or assuming fallthrough per default - will lead to security issues as you can now access stuff without any credentials.

How does it make it less secure than currently? If I'm understanding correctly you would only be able to access stuff without any credentials if the anonymous authenticator was enabled in an access rule. This allows the same level of access as can be gained now because the user can currently create a request that is ignored by previous authenticators even without falling through on errors, for example by not supplying a session cookie & Authorization header.

I understand the use case though, not sure how to implement it best however. Maybe something with error handling?

Error handling seems like a reasonable place to have this. I see that you're doing a redesign of this currently as a part of #441. I'll catch up on that and try to see if it can neatly fit in.

@cameron-martin
Copy link
Contributor Author

Potentially relates to #441 (comment)

@PeteMac88
Copy link

I also think an option to evaluate the next authenticator instead of failing the request is also interesting to support multi-tenancy regarding the auth server. In case I want to secure the same route with two different auth servers via oauth2_introspection this is not possible because the depending on the access tokens one of the introspection requests would fail.

@github-actions
Copy link

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

  • open a PR referencing and resolving the issue;
  • leave a comment on it and discuss ideas how you could contribute towards resolving it;
  • leave a comment and describe in detail why this issue is critical for your use case;
  • open a new issue with updated details and a plan on resolving the 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 erroneous 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 🙏✌️

@github-actions github-actions bot added the stale Feedback from one or more authors is required to proceed. label Sep 21, 2022
@Serhii-the-Dev
Copy link

Serhii-the-Dev commented Apr 22, 2024

There should be some methods to resolve this issue. We are currently migrating from a homemade JWT-based authorization on static tokens to Hydra using the client credentials flow and we obviously need to add the oauth2_introspection authenticator...which immediately breaks our current bearer_token authenticator if placed on top and vice versa. So far we simply put the new version under a specific URL prefix however I'm not sure it's the best solution that will work for everyone.

@renom
Copy link

renom commented Oct 2, 2024

Btw, how kratos api endpoints solves this? Does it work the same way as in oathkeeper?
For example: call some endpoint with incorrect token in a cookie, but with a valid token in a header. Will it return an error?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Feedback from one or more authors is required to proceed.
Projects
None yet
Development

No branches or pull requests

5 participants