Make bearer token prefix configurable to support API key migration with Ory Hydra #1245
Description
Preflight checklist
- I could not find a solution in the existing issues, docs, nor discussions.
- I agree to follow this project's Code of Conduct.
- I have read and am following this repository's Contribution Guidelines.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Ory Network Project
No response
Describe your problem
Our current API authentication relies on a static API key approach, using patterns like Authorization: API_KEY_TYPE_A xxxxxxx and Authorization: API_KEY_TYPE_B xxxxxx. This allows us to issue and support multiple key types. However, the bearer token authenticator in Oathkeeper currently only supports tokens prefixed by "bearer", making it impossible for us to migrate to bearer authentication while preserving support for our existing API key prefixes. We need to support a configurable approach to the "bearer" prefix to allow backward compatibility during migration.
Describe your ideal solution
We would like to make the "bearer" part of the Authorization header in the bearer token authenticator configurable, similar to how the current API key prefixes are handled. This would allow us to continue accepting existing keys (with custom prefixes) while issuing new keys with Ory Hydra using the bearer token standard. The authenticator should accept tokens with a configurable prefix (e.g., "Authorization: BEARER xxxxx", "Authorization: API_KEY_TYPE_A xxxxx") and not only the static "bearer" prefix.
Workarounds or alternatives
The alternative is to require all clients to migrate immediately to the "bearer" prefix, which is not feasible due to legacy integrations. Another alternative is to run multiple authenticators, but this increases complexity and overhead.
Version
0.40.9
Additional Context
This change would enable a smooth migration to Ory Hydra and provide a path for legacy API key support. The implementation should be backward compatible and opt-in for prefix configuration.