HMAC Authenticator

[jnodorp-jaconi]

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.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Context and scope

We want to place a service that uses HMAC signed tokens for authentication behind Oathkeeper. HMAC signed tokens works similar to JWT, but use a shared key instead of public key cryptography. I suggest adding an additional authenticator supporting HMAC signed tokens.

Goals and non-goals

HMAC signed tokens are not standardized. The initial implementation should provide some flexibility to support the most common configurations. However, more complex configurations should only be added if explicitly requested, keeping the code as simple as possible. For example: different hashing algorithms and different names for the expiration field are common, while non JSON payload formats are not.

The design

A new HMAC authenticator has to be added. The HMAC authenticator accepts tokens of the following format:

base64(<payload>.base64(hmac(<algorithm>, <payload>, <key>)))

If the payload is JSON formatted, the authenticator can optionally extract (and validate) an expiration timestamp from the payload.

The authenticator configuration should look like this:

algorithm: SHA-256 # the hash algorithm to use (for example, SHA-256)
key: s3cr3t # the shared secret
expiration_from: exp # the JSON payload field containing the expiration as UNIX millis
token_from: # same as for other authenticators

APIs

No response

Data storage

No response

Code and pseudo-code

Draft: https://github.com/ory/oathkeeper/compare/master...jaconi-io:hmac?expand=1

Degree of constraint

The new HMAC authenticator should be implemented the same way other authenticators are already implemented in Oathkeeper.

Alternatives considered

We built a custom OAuth 2.0 Token Introspection endpoint and used the oauth2_introspection authenticator to validate our HMAC signed tokens. However, the additional network roundtrip (and the respective performance impact) could be avoided when adding support for HMAC signed tokens to Oathkeeper.

[aeneasr]

Thank you for the request. Unfortunately, we can't accept non-standardized methods in Ory Oathkeeper. If we do, we would end up with a lot of different mechanisms for authentication, some of them with potentially very severe security flaws. If you use non-standardized tokens, please consider using the bearer_token or the soon to be released request forwarding authenticator: #949

Thank you for your understanding!