Oathkeeper as relying party in OIDC/Authorization code flow

[synclpz]

Use case

As discussed in #646.

Oathkeeper as an OIDC relying party and cookie-based session proxy.

I need Oathkeeper to act as an OIDC RP (oauth2 proxy). In this case Oathkeeper stands between my front-end (browser) and back-end (server) and my app uses OIDC from external provider for user authentication.

Oathkeeper needs to be able to: receive auth_code, exchange it for tokens, validate tokens and create cookie-based session for browser, mutating all incoming requests with Authorization and/or other headers using cached tokens before forwarding to back-end.

Sequence is as follows:

1. Browser requests https://myapp/some/path
2. Oathkeeper intercepts request, checks if session cookie is available and valid (it is not)
3. Oathkeeper sets a session cookie and redirects browser to OIDC provider /auth endpoint setting in query all required and configured parameters (client_id, client_secret, scopes, acr_values, etc..) and redirect_uri which is Oathkeeper's endpoint for myapp client_id (initial request is cached in Oathkeeper)
4. OIDC provider performs authentication and consent, then redirects browser to Oathkeeper's endpoint (e.g. https://myapp/oauth2/callback) with auth_code and other required parameters
5. Oathkeeper receives callback with code, exchanges it for tokens, validates and caches tokens, finds out cached initial request by previously issued session cookie, resets session cookie to a new (authenticated) value and redirects browser to initial request
6. Browser performs initial request
7. Oathkeeper checks session cookie, finds cached tokens, validates them if necessary, proxies initial request with configured mutations (e.g. access_token in Authorization header, id_token claims in additional headers and so on).
8. PROFIT

This case is discussed in #646 and https://ory-community.slack.com/archives/C012RBW0F18/p1614294029035400.

As an alternative one could use https://oauth2-proxy.github.io/oauth2-proxy/ it does implement this scenario but lacks some configuration options available in Oathkeeper (I need to dig deeper though).

[aeneasr]

Thank you for raising this issue! This is currently not implemented. We also thought about this in the next iteration of Ory Oathkeeper ( #441 ) but stated this explicitly as a non-goal as there are other projects like Pomerium which have UIs etc included. We're still open to address this but want to keep Ory Oathkeeper free of any UI which might be difficult for this specific use case.

[synclpz]

I think this case does not require any UI. It's all back-end functionality + config files, a converter for an OIDC-session to cookie-session, nothing more. Anyway, if it's non-goal at this time I'll better stick to our own implementation or oauth2-proxy. Thanks.

[synclpz]

Does this "closed" mean "won't implement"?

[aeneasr]

Sorry, forgot the message:

I am closing this issue as it has not received any engagement from the community or maintainers in a long time. That does not imply that the issue has no merit. If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you to anyone who participated in the issue! 🙏✌️

[bennesp]

Given this is the 5th most upvoted issue, can we discuss re-opening this issue?

To my knowledge, the solution right now, without this feature being built in oathkeeper, requires a custom implementation of the flow, as described by @synclpz, which is often undesirable in the "Don't code. Configure." approach.

This working custom-solution with the home-made implementation of the OIDC relying party is described in this blog post in the Auth service section: https://blog.commit.dev/articles/open-source-sundays-building-a-user-management-solution-using-ory-oathkeeper-and-auth0

It is nothing but a server that:

1. Initialize the OIDC flow with a redirect
2. Exchange the code with a token
3. Store the token in a cookie

I understand that the difficulty here doesn't rely on the feature per se but in fitting this feature in the already existing ones of ory/oathkeeper, but I was wondering if keeping this issue open could lead to more potential contributors seeing this and to a more open discussion.

Probably the easiest step is the very first one: initialize the OIDC flow with a redirect. This could be performed by an error handler, very similar to the redirect one, potentially configured like the following:

errors:
  fallback:
    - oidc_redirect

  handlers:
    oidc_redirect:
      enabled: true
      config:
        auth_url: https://my-idp/authorize
        client_id: a1b2c3
        redirect_uri: http://myself/callback/oidc/exchange # this could be potentially optional, auto inferred from the existing domain configuration and with a fixed-by-default callback path
        scopes:
          - openid
          - profile
          - email
        when:
          - error: [unauthorized]
            request:
              header:
                accept:
                  - text/html

With this, the redirect could be performed on unauthorized error, but instead of going straight to https://my-idp/authorize, it would go to https://my-idp/authorize?respose_type=code&client_id=a1b2c3&redirect_uri=http%3A%2F%2Fmyself%2Fcallback%2Foidc%2Fexchange&scope=openid%20profile%20email, initializing the OIDC flow