Anyone here who runs oauth2-proxy next to Oathkeeper and behind another proxy (e.g. ingress-nginx in K8S)? Since Oathkeeper doesn't handle the login redirection, I need oauth2-proxy for that, but after there are credentials, I'd like to use Oathkeeper to process them further. Should NGINX redirect to Oathkeeper and then Oathkeeper should have a fallback redirect to oauth2 proxy ?

Actually, NGINX would not redirect, but delegate the authn&authz to oathkeeper. If the required auth data is not present, authkeeper would then redirect to the oauth2 proxy, like you've written. However, after the auth2 proxy has handled the actual oauth2/oidc flow, you need a redirect back to the initial endpoint (in front of which oathkeeper is located). That can easily be achieved by setting the

redirect_to

query parameter and having a very simple service behind the oauth2 proxy, which would react on that. That way, after the oauth2 flow is finalized, the oauth2 proxy will set a corresponding cookie upon the redirect handled by the aforesaid service, which can then be used by oathkeeper to extract the token from and perform the actual authentication of the request in front of your api.

Actually, NGINX would not redirect, but delegate the authn&authz to oathkeeper

Yeah, sorry that's what I actually meant 🙂 At the basic level, I just want to use Oathkeeper to validate external JWTs from various providers (Azure AD, Hydra, whatever) and then hopefully use a custom hydrator service together with the

id_token

mutator to produce an "internal JWT". That way, microservices only deal with this single-issuer internal abstraction. I think that's all achievable and would work for most of the use-cases, because when it comes to initializing oauth (e.g. Azure AD), frontends will be doing that themselves. It's only for the cases where people need to hit a REST API that expects this internal JWT from the browser. This is why I'm thinking oauth2-proxy, because it can initiate the entire human-facing oauth flow, take the

id_token

from the cookie and put it into the header and send the request onwards to the API. Where this is breaking for me is how do I make sure that oauth2-proxy, once finished with the oauth flow, sends the request to Oathkeeper before going downstream. I still need the Oathkeeper pipeline to happen, because the

id_token

(now in auth header thanks to oauth2-proxy) is at this point still e.g. an AzureAD

id_token

and I need Oathkeeper to produce the "internal JWT". Assuming any of this was remotely understandable outside of my own brain 😅 ... Do you think your solution with the custom service (redirect target) could help me with that ?

Where this is breaking for me ...

This is exactly the point with that small redirect service. As far as I know, the oauth2-proxy will forward the request to some upstream service once finished with the flow and will also set a set of cookies once that upstream responses. The only pattern, which I know to work, is to let that service behind the oauth2-proxy redirect to the address set in the query parameter by oathkeeper when doing the initial redirect. Here it would encode the initial url which was used, when the request hit oathkeeper. As soon as the request comes back to that original url and is handled again by oathkeeper, you'll have to configure the corresponding authenticator to extract the token from the cookie previously set by the proxy in addition to the regular locations (I think oathkeeper does it automatically). That way, your "regular" upstream service will always get the same, as you've named that, "internal JWT". A small disclaimer: I'm not so familiar with the oauth2-proxy as I use https://github.com/zmartzone/lua-resty-openidc for the same purpose if I need to. That NGINX plugin, puts the access token into the cookie and you can configure it to make the id token available as well. Don't know how oauth2-proxy behaves in this regard. To have that working outside of the browser, you'll need to ensure the clients of you API follow redirects and handle the Set-Cookie header accordingly. So that, when the redirect happens, the cookie is set and hits oathkeeper.