Rewriting the bearer_token authenticator request method

[BracketJohn]

We now used oathkeeper in two of our projects - both times the same problem came up: The session stores we use for token validation only accept certain request methods for token validation, but oathkeeper always preserves the HTTP method.

Hence, PUT requests may not be authenticated correctly, but GET requests are. In one project we've solved this by adding a mini-service that takes any request from oathkeeper and forwards it to the session store, while changing the HTTP method to GET.

To us, this feels like a real hack, especially since other proxies often support HTTP method rewrites. What's a pattern that we can use to solve this problem on our second project? So far, wee had the following ideas:

• use oathkeeper as a sidecar API of an nginx or similar that rewrites requests
• add the "oathkeeper middleware" that transparently re-writes methods to a supported method

Both don't seem all that nice, I hope that maybe we're missing something here. Thanks!

[aeneasr]

Yeah we also got stung by this recently - would happily accept a PR towards changing this or making it configurable :)

[BracketJohn]

What would that change look like? Make it so that rewrite_http_method can be specified on the authenticator?

[aeneasr]

Yes, I think that's a good idea. Maybe rewrite_http_method_to: "GET" ?

[lanphan]

Hi @BracketJohn,
You got this problem when using oathkeeper as a proxy? I use oathkeeper as a decision engine only and seems I dont have problem you got

[BracketJohn]

Hey @lanphan,

exactly, we used it as a proxy with some light rules to restrict access to some methods. Weird that is doesn't happen when only used as a decision engine.

In the end we switched away to use nginx with auth-sub-requests, as we didn't use much of the awesomeness of oathkeeper anyways.

[a-manraj-pvotal]

we are using oathkeeper with ambassador as an authentication service (with oathkeeper maester). We are not encountering the same issue (in this config it is more the destination host the problem, but by using namespaced rules and correlating namespaced ambassador mappings we avoid host security problems). Providing some of our config for ref, if you guys are looking to use something similar.
Ambassador mapping :

bypass_auth: false
  connect_timeout_ms: 50000
  cors:
    credentials: false
    exposed_headers:
    - x-user-agent
    - grpc-status
    - grpc-message
    - content-type
    - x-grpc-web
    headers:
    - Content-Type
    - authorization
    - x-user-agent
    - x-grpc-web
    max_age: "86400"
    methods:
    - DELETE
    - GET
    - OPTIONS
    - POST
    - PUT
    origins:
    - 'applicative_host.company.com'
  grpc: true

Oathkeeper crd example :

authenticators:
  - config:
      allowed_algorithms:
      - RS256
      jwks_urls:
      - https://hydra.company.com/.well-known/jwks.json
      required_scope:
      - company.user
      target_audience:
      - https://product_a.company.com
      trusted_issuers:
      - https://hydra.company.com/
    handler: jwt
  authorizer:
    handler: allow
  match:
    methods:
    - DELETE
    url: <http|https>://oathkeeper_host/operation/delete/object<[-a-zA-Z0-9]*>