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

[cameron-martin]

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

[aeneasr]

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]

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]

Potentially relates to https://github.com/ory/oathkeeper/issues/441#issuecomment-652587583

[PeteMac88]

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[bot]]

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 🙏✌️

[Serhii-the-Dev]

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]

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?