feat: introduce auth scheme and jumping to next authentication

[Marlinc]

Some (legacy) application don't use Bearer as auth scheme in the Authorization header, in the current implementation this means Oathkeeper cannot be used to handle these legacy applications. The bearer token (and cookie) authenticator currently also don't support handling multiple authentication configurations (for example an access token in a header but also in a query parameter).

This change adds an optional auth_scheme option to the bearer token authenticator that allows changing the scheme it accepts, it also supports setting an empty scheme for applications that provide a token directly in a header. For compatibility it defaults to Bearer when the header is set to Authorization. The second change is that the session store endpoint can now return a HTTP 406 Not Acceptable response to tell Oathkeeper to jump to the next authentication rule.

This changes were previously discussed on Slack.

I will add some documentation too about these new features.

Related issue(s)

Checklist

• I have read the contributing guidelines.
• I have referenced an issue containing the design document if my change
  introduces a new feature.
• I am following the
  contributing code guidelines.
• I have read the security policy.
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security. vulnerability, I
  confirm that I got green light (please contact
  security@ory.sh) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added or changed the documentation.

Further Comments

[codecov]

Codecov Report

Merging #982 (2e345a4) into master (1738e61) will decrease coverage by 11.47%.
The diff coverage is 100.00%.

❗ Current head 2e345a4 differs from pull request most recent head 64e332f. Consider uploading reports for the commit 64e332f to get more accurate results

@@             Coverage Diff             @@
##           master     #982       +/-   ##
===========================================
- Coverage   77.79%   66.31%   -11.48%     
===========================================
  Files          81      107       +26     
  Lines        3873     4771      +898     
===========================================
+ Hits         3013     3164      +151     
- Misses        587     1325      +738     
- Partials      273      282        +9     

Impacted Files	Coverage Δ
helper/bearer.go	100.00% <100.00%> (ø)
pipeline/authn/authenticator_cookie_session.go	83.33% <100.00%> (+4.08%)	⬆️
metrics/prometheus.go	93.33% <0.00%> (-2.42%)	⬇️
rule/fetcher_default.go	76.65% <0.00%> (-1.92%)	⬇️
credentials/fetcher_default.go	64.89% <0.00%> (-1.07%)	⬇️
pipeline/mutate/mutator_hydrator.go	65.09% <0.00%> (-1.00%)	⬇️
metrics/middleware.go	97.36% <0.00%> (-0.51%)	⬇️
driver/registry_memory.go	89.91% <0.00%> (-0.18%)	⬇️
cmd/serve.go	100.00% <0.00%> (ø)
driver/health/event_manager_default.go	94.11% <0.00%> (ø)
... and 44 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[CLAassistant]

All committers have signed the CLA.

[aeneasr]

Thank you @Marlinc and sorry. for the late review! I'm wondering if it would make more sense to use a generic authenticator in such a case? The bearer token authenticator is supposed to solve https://datatracker.ietf.org/doc/html/rfc6750 which is expecting the Bearer to be in the header. If that's not the case, wouldn't it be a different type of authentication (same mechanism maybe, but a different HTTP auth mechanism).

We could add another authenticator that handles this (e.g. a more generic one)

[aeneasr]

This would potentially be solved by: #949