Forward access token from OIDC login as Authorization Bearer token. #843
Comments
|
We are setting the stage for this in this PR: #826 At the moment we are just back porting the new header configuration libraries to legacy configurations. The end goal is to provide much more header customization power in a structured configs we are targeting for an upcoming major major release. We are aiming to support features like this. |
|
Hi, I also faced this issue with Kubernetes and Keycloak, unlike louketo-proxy oauth2-proxy does not pass |
|
@kvaps If you are using Try |
|
@JoelSpeed Might be worth revisiting our conversation on Having them as different header prefixes with different flags that configure them seems to be resulting in a lot of Issues/Questions lately -- Envoy/Nginx subrequest getting popular out of the blue lately. |
|
Hi @NickMeves my oauth2-proxy is running as a sidecar and proxying the requests to the application itself: - args:
- --provider=keycloak
- --client-id=kubernetes
- --client-secret=7b412da4-548a-44af-a2c1-6b42a5c46431
- --cookie-secret=x-1vrrMhC-886ITuz8ySNw==
- --upstream=http://localhost:8080/
- --http-address=0.0.0.0:3000
- --email-domain=*
- --pass-basic-auth=false
- --pass-access-token=true
- --set-xauthrequest=true
- --skip-jwt-bearer-tokens=true
- --set-authorization-header=true
- --pass-authorization-header=true
- --skip-auth-regex=^\/config\.json$
- --skip-auth-regex=^\/favicon.*\.png$
- --skip-auth-regex=^\/static\/
- --skip-auth-regex=^\/$
- --scope=openid email groups
- --oidc-issuer-url=https://keycloak.example.org/auth/realms/kubernetes
- --login-url=https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/auth
- --redeem-url=https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/token
- --validate-url=https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/userinfo
- --keycloak-group=ipausersBut after the successful authentication my application see only these headers: Hostname: kubeapps-84f7f5f7f6-v4hq4
IP: 127.0.0.1
IP: ::1
IP: 10.112.2.173
IP: fd00::2:f2c0
IP: fe80::8ce:b4ff:fe9e:10e7
RemoteAddr: [::1]:47192
GET /a HTTP/1.1
Host: kubeapps-stage.example.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: ru,en-US;q=0.7,en;q=0.3
Cache-Control: max-age=0
Cookie: < my cookies here >
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-Access-Token: < Bearer token here >
X-Forwarded-Email: andrei.kvapil@example.org
X-Forwarded-For: 10.31.2.82, 10.112.1.245
X-Forwarded-Host: kubeapps-stage.example.org
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Real-Ip: 10.31.2.82
X-Request-Id: 40aa3757f3387296d30fcad6b8a0b089
X-Scheme: httpsHowever if I use louketo-proxy: - args:
- --discovery-url=https://keycloak.example.org/auth/realms/kubernetes
- --client-id=kubernetes
- --client-secret=7b412da4-548a-44af-a2c1-6b42a5c46431
- --encryption-key=oowuPaquoxe5ephaehah6aeb8ieweesu
- --upstream-url=http://localhost:8080/
- --listen=0.0.0.0:3000
- --resources=uri=/config.json|white-listed=true
- --resources=uri=/favicon*.png|white-listed=true
- --resources=uri=/static/*|white-listed=true
- --scopes=openid+email+groups
- --enable-session-cookies=true
- --enable-refresh-tokens=true
- --enable-logout-redirect
- --enable-logging=true
- --verbose=trueI'm seeing more headers: Hostname: kubeapps-654c8b8db4-m2vmf
IP: 127.0.0.1
IP: ::1
IP: 10.112.2.159
IP: fd00::2:7973
IP: fe80::e4:27ff:fe3b:702d
RemoteAddr: [::1]:60838
GET / HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip
Accept-Language: ru,en-US;q=0.7,en;q=0.3
Authorization: Bearer < Bearer token here >
Cache-Control: max-age=0
Cookie: < My cookie here >
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Auth-Audience: kubernetes
X-Auth-Email: andrei.kvapil@example.org
X-Auth-Expiresin: 2020-10-26 22:05:17 +0000 UTC
X-Auth-Groups: < My user groups here>
X-Auth-Roles: offline_access,uma_authorization,account:manage-account,account:manage-account-links,account:view-profile
X-Auth-Subject: 337a5e4b-ecce-4ef6-b28e-d89220ec0830
X-Auth-Token: < Bearer token here >
X-Auth-Userid: kvaps
X-Auth-Username: kvaps
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: localhost:8080
X-Forwarded-Proto: In fact louketo-proxy is working, but with oauth2-proxy I'm getting, when I'm trying to access Kubernetes API: {
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
"reason": "Forbidden",
"details": {
},
"code": 403
}#826 does not solves this problem, should I open new issue? |
|
At the moment, we only support the Can you add some comments to that PR for @JoelSpeed if you think it doesn't cover your Access vs ID Token Authorization header concerns? I thought that PR was aiming to tackle that problem. Structured configs that make this fully configurable currently targeted for v8. We are looking into adding alpha flags to give early access to these features in the codebase in v7.X Weird that I don't see the I'm not a Keycloak user, so I've lost track of the use cases. I've seen some people use the |
Keycloak has an opportunity to request the ID token, eg kuberos is succefully doing that: But all others: louketo-proxy, oauth2-proxy and kubelogin are requesting and using Bearer (Access token) for some reason |
|
If you try the oidc provider instead of the keycloak provider, does that give you an access token? As far as I remember the keycloak provider doesn't store an ID Token in the session, hence not getting an Authorization header |
@NickMeves Does this not go away when we introduce the structured configuration? Since users will just set request or response header injection? |
|
I more mean consolidating around a unified header prefix ie I think with the nginx or kubernetes ingress subrequest architecture, users get very confused about the need for (Then further confusing matters, they then likely want to forward the client's response headers to the upstream in the proxied request -- so in this architecture, the headers are I support both the subrequest model for Kubernetes ingress resources to hook into as a central Access Proxy & deploying OAuth2-Proxy as an intercepting sidecar proxy with the apps. My backend app developers get very confused where to get the identity headers and which architecture they are using under the hood (since it is mostly transparent to them). They just confusingly get different sets of headers that do the same thing and they don't know why. And then they come bug & blame me! 😅 |
|
I think you could configure them to be the same needing the new configuration if you wanted to! The new configuration should be totally flexible so that you can do that. I think normally if you were configuring nginx you would rename the response header from the OAuth2 Proxy before you copy it onto the request to the upstream |
With |
|
Fixed by setting the following annotations for nginx-ingress: nginx.ingress.kubernetes.io/proxy-buffer-size: "64k"
nginx.ingress.kubernetes.io/proxy-buffers-number: "8"Thanks to https://stackoverflow.com/questions/58943111/nginx-ingress-returns-502-after-post-with-redirect |
|
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed. |
|
Hi, perhaps I missed it, but since 7.x is out - is it possible to configure the access token to be used as authorization bearer token? Currently I'm still on 6.x and I'm switching my Javascript Frontend to use MSAL v.2which sends the access token in the authorization bearer to my API calls, which unfortunately gives ma an unauthorized. Yet I would still like to keep the OAuth2 Proxy to protect my API and other endpoints. Thanks |
|
If you are willing to use the alpha configuration that is largely undocumented, and potentially going to change in the future. Then yes you can do this, you'll need to do something like |
|
When using keycloak we really need to get back more detail or the token otherwise we have to reimplement all this logic back into every service. For example, when we're running traefik and oauth2-proxy I get back the following But that doesn't give the microservice enough information to process the request, sure I've got a authenticated user, but does that user have group access or role access? We really need oauth2-proxy adding enough information to the request for the microservice to make access decisions. I'd suggest at a minimum we'd need the following: |
OMG! This is AMAZING!! It's exactly what I have always wanted out of oauth2-proxy!! THANK YOU SO MUCH! It works SO well in my environment! |
|
Hi All, |
|
As per previous comments, if you want to do this, use the alpha config as others have |
|
Hi @InfoSec812 @JoelSpeed, I am trying to authenticate the request(istio-bookinfo demo productpage) using Keycloak. but the POD is not coming UP and throwing error -- Any help is highly appreciated. |
|
2 issues which I noticed.
|
|
Hey @InfoSec812 , thanks for the quick reply. I applied the config you suggested. -- But I dont know why I am still getting the same Index [0] error -- As I checked the validation code, I guess this is related to Provider config but I am unable to figure out the missing/incorrect config here :( |
|
I had the same error @siddharth201983 It should be like this I think - |
I had to add a whitespace after Bearer: Took me while to find it. Maybe some helps that. |
Forward access token from OIDC login as Authorization Bearer token.
Expected Behavior
It should be possible to forward the access token gained from the OIDC provider in upstream calls as the Authorization Bearer token.
Current Behavior
It is only possible to forward the ID Token as Authorization Bearer token. The access token can only be forwarded in the X-Forwarded-Access-Token header (or X-Auth-Forwarded-Access-Token).
Possible Solution
Make it configurable to forward the Access Token as Authorization Bearer token.
Suggestion:
pass_access_token="true"
pass_access_token_as_bearer="true"
With the second option the oauthproxy can do:
if p.PassAccessToken { if p.PassAccessTokenAsBearer { if session.AccessToken != "" { req.Header["Authorization"] = []string{fmt.Sprintf("Bearer %s", session.AccessToken)} } else { req.Header.Del("Authorization") } } else { if session.AccessToken != "" { req.Header["X-Forwarded-Access-Token"] = []string{session.AccessToken} } else { req.Header.Del("X-Forwarded-Access-Token") } } }I have made this fix locally, and are willing to contribute with a PR, but need to discuss what needs to be checked/tested.
Also, if this option is enabled, it should not be possible to configure
pass_authorization_header="true"I noticed there is requirements on the cookie secret if PassAccessToken is set to true. Therefor it feels most correct to extend that option with this new one. Rather than add an extra option to pass_authorization_header, which is based on id token.
Context
Our organization manage our own OAuth2 authorization service and OIDC provider. All our microservices expects the access token to be present in the Authorization header as Bearer token.
The access token can be both opaque or as JWT.
An ID Token is not an access token. It doesn't contain the scopes claim.
Your Environment
The text was updated successfully, but these errors were encountered: