-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Add Authorization: Bearer <jwt>
as an optional header from OIDC style providers
#530
Comments
We too have extended oauth2_proxy to do the same function for the dashboard. It would be nice to have this in the upstream version of oauth2_proxy. In addition, we implemented an endpoint inside the oauth2_proxy called exchangeCookie, which takes the cookie presented, authorizes it, and returns the oidc id token, access_token, refresh_token (if there), and expire_in field as part of a json response. |
@mmerrill3 Have you got a link to your branch with this implementation? I've also created an internal tool similar to the There is a PR open in the core Kubernetes codebase you might be interested in following, they're trying to make kubectl perform the OIDC login's directly. |
Hi @JoelSpeed , thanks for the link. Here is where I implemented the new endpoint for oauth2_proxy: https://github.com/mmerrill3/oauth2_proxy/tree/feature/id_token |
I'll try and raise a PR over the weekend |
@mmerrill3 @gtaylor I've raised a PR #534 which includes this work. It also includes an attempt at a fix for overflowing the 4kb limit of a single cookie. Used Azure as my OIDC provider and it turns out the JWTs they issue are massive compared to what Google or Dex provide. It is unlikely, however possible, that the tokens will ever get that big from a normal OIDC provider, but I've added the support anyway. Stops someone later on wondering why their cookies are being silently dropped (The go http library drops them without an error if they overflow the 4kb limit) @mmerrill3 Did you ever see any cookie size issues with your implementation? |
Awesome! Thanks, @JoelSpeed! |
I also have the same type of changes locally and would love to see this |
@JoelSpeed , I didn't see any issues with the cookie size when using google as my oidc provider. Thanks for the pull request! |
One question, is oauth2-proxy also able to identify externally obtained tokens and let requests pass/go through (Authorization header)? For a "simple" realistic scenario, let's assume Github as provider and a Kubernetes deployed app.
Let's assume that oauth2-proxy has no redirect bugs, all good when I hit a protected url in the browser
I'm getting some 403 errors here with the following relevant
Is it a scenario that you've used or tested yourself, with oauth2-proxy? I was conducting initial experiments with Github prior trying couple of things with Azure AD. In my particular use case if oauth2-proxy block/allow unauthorized requests upfront that's better. the individual "secured apps" would just do "whatever" they need to do with the token itself to extract more info. |
Just answering my own question, it's apparently not supported by oauth2-proxy:
My java application is more or less a much smaller oauth2-proxy with a barebone UI to initiate the authentication workflows. I could probably tweak it to do more and become aware of the "Authorization" header |
I've come across several applications/apis
Authorization: Bearer <jwt>
as a header for authentication, a major one of these being Kubernetes and the Kubernetes Dashboard.I have my own copy of this repo where the OIDC provider returns the raw
IdToken
instead of the Access token to put in front of Kubernetes, but I did this quickly and in a hacky way. I'd like to make it proper and provide the functionality upstream.I would like to propose the addition of
pass-authorization-header
andset-authorization-header
flags to the OAuth Proxy. The effect of which would be similar to thepass-access-token
andset-x-auth-request
flags respectively.The effect of this would be, that for certain providers, where the login process generates an
IdToken
(can see this in the OIDC provider and Google providers for instance), then the proxy would add a header to the proxied requests/auth requests ofAuthorization: Bearer <IdToken>
.To do this, you could add an
IdToken
field to theSessionState
object.oauth2_proxy/providers/session_state.go
Lines 12 to 13 in 1209c63
Then providers such as the OIDC provider and the Google provider could set this field during the
Redeem
method and then the proxy could set the headers in a very similar way to the below snippetoauth2_proxy/oauthproxy.go
Lines 698 to 700 in ae49c7d
I don't know too much about how the other providers work, but they may well also be able to set Authorization headers in a similar way.
If you think this is a worthwhile and a reasonable approach, I will start working on a PR.
The text was updated successfully, but these errors were encountered: