ory/oathkeeper

Decision API is not respecting the token_from config

osbornk opened this issue · 1 comments

Preflight checklist

Ory Network Project

No response

Describe the bug

I am trying to send a custom token header to the Oathkeeper API for token auth. But it seems to not pass a custom token header to the check_session_url. Instead, it does not send a token at all.

Oathkeeper does check the token. If I don't include the token, Oathkeeper immediately returns a 401. But it never gets passed onto the check_session_url.

Reproducing the bug

Here is my command:

curl -H "X-Forwarded-Method: GET" -H "X-Forwarded-Proto: http" -H "X-Forwarded-Host: myhost" -H "X-Forwarded-Uri: /xyz" -H "xyz: sometoken" -X GET http://oathkeeper-api:4456/decisions -v

From my logs, my request makes it to Kratos, but without the token, so it produces a 401.

My expectation is for Oathkeeper to read the header xxx and send Authorization: Bearer sometoken to Kratos.

If I remove the token_from section from the config and use the default values, this works.

curl -H "X-Forwarded-Method: GET" -H "X-Forwarded-Proto: http" -H "X-Forwarded-Host: myhost" -H "X-Forwarded-Uri: /xyz" -H "Authorization: Bearer sometoken" -X GET http://oathkeeper-api:4456/decisions -v

Relevant log output

No response

Relevant configuration

config:
    access_rules:
      repositories:
        - file:///etc/rules/access-rules.json
    authenticators:
      bearer_token:
        enabled: true
        config:
          check_session_url: http://kratos-public/sessions/whoami
          preserve_path: true
          token_from:
            header: xxx
          extra_from: "@this"
          subject_from: "identity.traits.my_id"
    authorizers:
      allow:
        enabled: true
    mutators:
      header:
        enabled: true
        config:
          headers:
            X-User: "{{ print .Subject }}"

Version

0.40.6

On which operating system are you observing this issue?

Linux

In which environment are you deploying?

Kubernetes with Helm

Additional Context

No response

Having this issue as well, the only thing that works is the default i.e not providing any token_from value at all. If you provide anything else, you get 401.