I'd like to ask if any of you has the experience to configure oauth2-proxy with Traefik? Is it supported out of the box?

Currently, there is no documentation and/or examples on how to deploy oauth2-proxy on kubernetes. This would be a neat addition, especially for begineer k8s users to have something to base off of.

I'd gladly work on both the example manifests and documentation, provided it's a desired feature.

This way escaped char's like /%2F/ will still work instead of returning 301. The proxy should ideally touch the request as little as possible / needed.

Description

Adds a new configuration flag to enable passing of the raw path to upstreams

Motivation and Context

https://github.com/oauth2-proxy/oauth2-proxy/issues/844

How Has This Been Tested?

a couple of new tests and running in our production setup for ~6month now.

Checklist:

• [X] My change requires a change to the documentation or CHANGELOG.
• [X] I have updated the documentation/CHANGELOG accordingly.
• [X] I have created a feature (non-master) branch for my PR.

Description

By adding the ability to provide a group-claim when configuring the OICD provider, this enables the ability to perform validation to ensure that a user has a specific group claim present.

This comes in handy in our case when using Dex we can fetch all groups, and then in our individual oauth2-proxies handle fine grained group level checks.

Motivation and Context

Closes https://github.com/oauth2-proxy/oauth2-proxy/issues/600

How Has This Been Tested?

Unit tests have been added and manual testing performed within a local kind cluster, it should not affect existing behavior as this is an addition and by default group-claim=""which means that we do not perform any checks.

Checklist:

• [X] My change requires a change to the documentation or CHANGELOG.
• [X] I have updated the documentation/CHANGELOG accordingly.
• [X] I have created a feature (non-master) branch for my PR.

Documentation has been updated, to show the new field, just unsure on the changelog is it manual or automatically generated?

This PR adds subdomain-based routing.

Description

This PR makes it possible to route based on domain name in addition to by path, for example:

upstreams = [
    http://default-upstream:8082/
    delta|http://delta-service:8083/
    echo|http://echo-service:8080/
    echo|http://echo-service-api:8080/api/
]
cookie_domain = ".mydomain.com"

With this new config it's possible to route https://delta.mydomain.com/, https://echo.mydomain.com/ as well as https://echo.mydomain.com/api/ differently.

Motivation and Context

Sometimes it is desirable to route not only based on the path, but also on the subdomain. This allows the use of the same oauth2 callback URL and oauth2_proxy for multiple sites in the same domain.

How Has This Been Tested?

We tested this patch in our production domain. A modified version (based on the bitly/google-oauth-proxy) has been running successfully for us for a few years now.

Checklist:

• [X] My change requires a change to the documentation or CHANGELOG.
• [X] I have updated the documentation/CHANGELOG accordingly.
• [X] I have created a feature (non-master) branch for my PR.

extract email from id_token, if present, for azure provider

Description

this change fixes a bug when --resource is specified with non-Graph api and the access token destined to --resource is used to call Graph api

Motivation and Context

Fixes #913

How Has This Been Tested?

unit test and end to end validation

Checklist:

• [x] My change requires a change to the documentation or CHANGELOG.
• [ ] I have updated the documentation/CHANGELOG accordingly.
• [x] I have created a feature (non-master) branch for my PR.

Hi @JoelSpeed,

I'm facing the same issue described in #12 and have been trying to get the described setup working but the redirect to the downstream ingress doesn't work. Do you have some more documentation on how this exactly should look like?

Here's what I did:

1. Install the chart

helm install stable/oauth2-proxy --name login-oauth2-proxy \
    --namespace xyz \
    --set config.clientID="clientId" \
    --set config.clientSecret="clientSecret" \
    --set config.cookieSecret="cookieSecret" \
    --set extraArgs.provider="azure" \
    --set extraArgs.azure-tenant="tenantId" \
    --set extraArgs.whitelist-domain=".mydomain.com" \
    --tls

2. Create the ingress for oauth2_proxy:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: login-ingress-oauth2
  namespace: xyz
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: login.mydomain.com
    http:
      paths:
      - backend:
          serviceName: login-oauth2-proxy
          servicePort: 80
        path: /oauth2
  tls:
  - hosts:
    - login.mydomain.com

By now browsing https://login.mydomain.com/oauth2/sign_in works as expected.

3. Configure downstream ingress to use the oauth2_proxy:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myservice-ingress
  namespace: xyz
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-url: "https://login.mydomain.com/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://login.mydomain.com/oauth2/start?rd=service.cdhamap.com"
spec:
  rules:
  - host: service.cdhamap.com
    http:
      paths:
      - backend:
          serviceName: service-backend
          servicePort: 1337
        path: /
  tls:
  - hosts:
    - service.cdhamap.com

Browsing https://service.mydomain.com now correctly redirects me to the Microsoft Login but still shows https://login.mydomain.com/oauth2/callback as the redirect_uri which then after successful authentication falls back to default-backend.

What am I missing?

Thanks a lot!!

Currently (v5.1.0), when a session is encrypted and the size of the session exceeds 4kb, there is logic within the proxy to split the cookie. This is required so that we do not exceed the maximum size of a cookie. As far as I'm aware this is guaranteed to happen when using Azure because of the size of the ID Tokens they generate, and it has caused a number of issues in the past.

There is an alternate solution however. By using redis as a session store (potentially we need to implement other alternate session stores? sqlite could be a good option for small deployments, dynamo or other cloud dbs for scaled deployments? Kubernetes CRDs for those running on Kubernetes), the larger sessions can be stored server side and the client need only keep track of a session ticket encrypted within the cookie, which is typically much smaller.

There are other additional benefits of server side session storage as well, eg you are less likely to have authentication fail during refreshes as the session can not go stale in a cookie.

My proposal would be that we remove this behaviour from the proxy in a couple of steps:

• First, introduce a warning that the cookie is being split
• Secondly either remove the splitting altogether or feature gate it behind a flag
  • If feature gated, make a note that this is unsupported behaviour and that support will not be provided when using the feature

I would like to gather feedback from the community on this idea before we make a breaking change, so please post comments below

Related issues:

• #458
• #350
• #138
• #69
• #29
• #388
• #266

Use X-Forwarded-{Proto,Host} headers in the requests to oauth2-proxy as a last resort to get where to redirect.

Description

Reverse proxies like Traefik currently don't have a dynamic way to manipulate headers, thus handling redirects is not easy.

On Traefik v1, you could set the rd query string per frontend, thus allowing more customization. However on Traefik v2, the entire config structure changed and these customizations has to be general purpose middlewares; and having no dynamic way to modify headers gives very little chance to configure a central auth environment.

Motivation and Context

This change hopes to resolve #46 and is code is somewhat based on #762.

How Has This Been Tested?

On a Traefik v2 host, this File (YAML) config is used:

http:
  routers:
    a-service:
      rule: "Host(`a-service.example.com`)"
      service: a-service-backend
      middlewares:
        - oauth-errors
        - oauth-auth
      tls:
        certResolver: default
        domains:
          - main: "example.com"
            sans:
              - "*.example.com"
    oauth:
      rule: "Host(`a-service.example.com`, `oauth.example.com`) && PathPrefix(`/oauth2/`)"
      middlewares:
        - auth-headers
      service: oauth-backend
      tls:
        certResolver: default
        domains:
          - main: "example.com"
            sans:
              - "*.example.com"

  services:
    a-service-backend:
      loadBalancer:
        servers:
          - url: http://172.16.0.2:7555
    oauth-backend:
      loadBalancer:
        servers:
          - url: http://172.16.0.1:4180

  middlewares:
    auth-headers:
      headers:
        sslRedirect: true
        stsSeconds: 315360000
        browserXssFilter: true
        contentTypeNosniff: true
        forceSTSHeader: true
        sslHost: example.com
        stsIncludeSubdomains: true
        stsPreload: true
        frameDeny: true
    oauth-auth:
      forwardAuth:
        address: https://oauth.example.com/oauth2/auth
        trustForwardHeader: true
    oauth-errors:
      errors:
        status:
          - "401-403"
        service: oauth-backend
        query: "/oauth2/sign_in"

On oauth2-proxy, the changed config is:

http_address = "172.16.0.1:4180"

reverse_proxy = true
real_client_ip_header = "X-Forwarded-For"

redirect_url = "https://oauth.example.com/oauth2-proxy/callback"

oauth.example.com itself does not have a website to host for this example configuration.

Checklist:

• [X] My change requires a change to the documentation or CHANGELOG.
• [X] I have updated the documentation/CHANGELOG accordingly.
• [X] I have created a feature (non-master) branch for my PR.

Edited: Apparently I included a middleware on services accidentally, this has been corrected. I have also redone the example config to be a bit more readable.

Expected Behavior

There to be a configuration option to inject arbitrary request headers when contacting the upstream after authentication

Current Behavior

No option exists

Split session save function to detect redis duplicate/not found session key error.

Description

Currently, redis store implementation uses SET command when creating or updating session. It can't detect the following cases:

• When creating a session with a key that already exists in Redis.
• When updating a session with a key that does not yet exist in Redis.

To detect them, I split current Save function into the following three functions:

• Create : If the same key exists, don't create it using SET NX command
• Update: If the key doesn't exists, don't create it using SET XX command
• CreateOrUpdate : Create or Update (Same as current implementation)

Motivation and Context

Current implementation causes the following problems:

• If the same session key is generated by oauth2-proxy extremely unlucky, the Redis session will be shared between users.
• Updating Redis session by refreshing may revive discarded session depending on timing.

Note: The session key issued by oauth2-proxy is random enough, but I believe it should be checked for duplicate, as described in the OWASP Session Management Cheat Sheet as follows:

Additionally, a random session ID is not enough; it must also be unique to avoid duplicated IDs. A random session ID must not already exist in the current session ID space.

How Has This Been Tested?

• Automated test by make test

Checklist:

• [x] My change requires a change to the documentation or CHANGELOG.
• [x] I have updated the documentation/CHANGELOG accordingly.
• [x] I have created a feature (non-master) branch for my PR.

I was stuck quite a while getting V7.1.3 to run with that dreaded "error loading cookied session" until I found out that proxy_prefix was configured wrong.

When there's an unexpected response from the auth server trying to exchange the token, there should be an error message logged.

This adds support for using phabricator as an auth provider.

This is based on a provider we've been running internally for a few years.

It'd be nice to be able to run unmodified upstream code, but since there's a freeze on new smaller providers I'll leave the PR as a draft in case others want to use it. I'll likely keep this branch updated to keep up to date with the tip of master.

Description

Prepare the changelog and documentation for the v7.2.0 release

Motivation and Context

We haven't had a release in a little while. We have many fixes and new features to release.

How Has This Been Tested?

N/A

Checklist:

• [x] My change requires a change to the documentation or CHANGELOG.
• [x] I have updated the documentation/CHANGELOG accordingly.
• [x] I have created a feature (non-master) branch for my PR.

During the re init of the second session, the value of the lifetime of the refresh token is never updated

Expected Behavior

Current Behavior

My keycloak realm is configured to

• not allow mutilple use of the same refresh_token.
• refresh token's lifespan is 3 min
• access token's lifespan is 1 min

My oatuh2-proxy is configured to

• execute a refresh cookie every minute

I can see the correct execution of the refresh_token on my keycloak instance every minute. I also see it in the logs. However, the first alert is logged on the expiration of the refresh token. When its lifespan is exceeded, the flow code is restarted but generates an error 500. I see in the logs always the same value of the lifespan of the refresh token

Note : To return after the 500 error to an acceptable state, I have to delete my keycloak user session

Possible Solution

Verify value expiration of refresh_token in cookie ?

Steps to Reproduce (for bugs)

1. Configure keycloak client with lifespan token at 1m and Client Session Max at 3m
2. Configure proxy with refresh cookie at 1m
3. Connected on proxy and show logs
4. No problem before 1m
5. At +1min refresh cookie (refresh token) is execute
6. At +2min refresh cookie (refresh token) is execute
7. At +3min Error 500. Log show :

./oauth2-proxy --config configv2.file
[2021/10/16 23:14:40] [proxy.go:70] mapping path "/" => upstream "http://127.0.0.1:8080/"
[2021/10/16 23:14:40] [oauthproxy.go:143] OAuthProxy configured for OpenID Connect Client ID: oauth2-proxy
[2021/10/16 23:14:40] [oauthproxy.go:149] Cookie settings: name:_oauth2_proxy secure(https):false httponly:false expiry:2m0s domains: path:/ samesite: refresh:after 1m0s


127.0.0.1:42656 - fbfca142-309e-4f8a-aed7-280da0344530 - MAIL [2021/10/16 23:15:27] monsitesecure.DOMAINE:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 404 19 0.000
[2021/10/16 23:15:49] [stored_session.go:122] Refreshing 1m16.665170101s old session cookie for Session{email:MAIL user:IDUSER PreferredUsername:USER token:true id_token:true created:2021-10-16 23:14:32.334829899 +0200 CEST expires:2021-10-16 23:15:32.325781796 +0200 CEST refresh_token:true} (refresh after 1m0s)
[2021/10/16 23:15:49] [oidc.go:158] refreshed session: Session{email:MAIL user:IDUSER PreferredUsername:USER token:true id_token:true created:2021-10-16 23:15:49.882520819 +0200 CEST m=+69.233994635 expires:2021-10-16 23:16:49.866585362 +0200 CEST m=+129.218059178 refresh_token:true}
[2021/10/16 23:15:49] [cookies.go:84] Warning: request host is "monsitesecure.DOMAINE" but using configured cookie domain of "DOMAINE:4180"
127.0.0.1:42656 - 4ac608b7-b493-4b51-9475-325d6ac37533 - MAIL [2021/10/16 23:15:49] monsitesecure.DOMAINE:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 404 19 0.056


127.0.0.1:42656 - efd0af57-b0cf-4b13-a234-ba76af6fa885 - MAIL [2021/10/16 23:16:49] monsitesecure.DOMAINE:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 404 19 0.000
[2021/10/16 23:16:56] [stored_session.go:122] Refreshing 1m6.117479181s old session cookie for Session{email:MAIL user:IDUSER PreferredUsername:USER token:true id_token:true created:2021-10-16 23:15:49.882520819 +0200 CEST expires:2021-10-16 23:16:49.866585362 +0200 CEST refresh_token:true} (refresh after 1m0s)
[2021/10/16 23:16:56] [oidc.go:158] refreshed session: Session{email:MAIL user:IDUSER PreferredUsername:USER token:true id_token:true created:2021-10-16 23:16:56.70730767 +0200 CEST m=+136.058781486 expires:2021-10-16 23:17:32.706985363 +0200 CEST m=+172.058459079 refresh_token:true}
[2021/10/16 23:16:56] [cookies.go:84] Warning: request host is "monsitesecure.DOMAINE" but using configured cookie domain of "DOMAINE:4180"
127.0.0.1:42656 - d123c070-024d-4c2f-addf-3c203fc94881 - MAIL [2021/10/16 23:16:56] monsitesecure.DOMAINE:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 404 19 0.041

127.0.0.1:42656 - befecc94-2edc-43c1-84c0-4d32ec710020 - MAIL [2021/10/16 23:17:52] monsitesecure.DOMAINE:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 404 19 0.001
[2021/10/16 23:18:06] [stored_session.go:122] Refreshing 1m9.29269233s old session cookie for Session{email:MAIL user:IDUSER PreferredUsername:USER token:true id_token:true created:2021-10-16 23:16:56.70730767 +0200 CEST expires:2021-10-16 23:17:32.706985363 +0200 CEST refresh_token:true} (refresh after 1m0s)
[2021/10/16 23:18:06] [stored_session.go:76] Error loading cookied session: error refreshing access token for session (Session{email:MAIL user:IDUSER PreferredUsername:USER token:true id_token:true created:2021-10-16 23:16:56.70730767 +0200 CEST expires:2021-10-16 23:17:32.706985363 +0200 CEST refresh_token:true}): error refreshing access token: unable to redeem refresh token: failed to get token: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Token is not active"}, removing session
127.0.0.1:42656 - 87958b27-3706-40bf-949a-ef8bcace859a - - [2021/10/16 23:18:06] monsitesecure.DOMAINE:4180 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 403 8069 0.032
127.0.0.1:42656 - bde4c1e8-b97b-4764-a56f-421ccabddf32 - - [2021/10/16 23:18:14] monsitesecure.DOMAINE:4180 GET - "/oauth2/start?rd=%2F" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 302 350 0.000
[2021/10/16 23:18:14] [oauthproxy.go:748] Error redeeming code during OAuth2 callback: could not verify id_token: oidc: token is expired (Token Expiry: 2021-10-16 23:17:32 +0200 CEST)
127.0.0.1:42656 - c8b67e9d-d079-4def-a91e-189a9c4d08c3 - - [2021/10/16 23:18:14] monsitesecure.DOMAINE:4180 GET - "/oauth2/callback?state=E7RCCS2wFE80x1ebMu81N6jBdGPnqLqrmiPOIk_roeQ%3A%2F&code=ca6e03e8-6927-43ea-b422-502c9cd7b127.e6ba9645-bde4-4f23-8cae-ed2d01cfb159.a74724de-e96a-4f47-b158-901173991f69" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" 500 2841 0.032

Show the line : [2021/10/16 23:18:14] [oauthproxy.go:748] Error redeeming code during OAuth2 callback: could not verify id_token: oidc: token is expired (Token Expiry: 2021-10-16 23:17:32 +0200 CEST)

Token Expiry is the value of the before last refresh : CEST expires:2021-10-16 23:17:32.706985363

The code flow

Context

Your Environment

http_address = "127.0.0.1:4180" reverse_proxy = false provider_display_name="RALALA" redirect_url = "http://monsitesecure:4180/oauth2/callback" upstreams = "http://127.0.0.1:8080/" request_logging = true auth_logging = true email_domains = [ "*" ] provider = "oidc" client_id = "oauth2-proxy" client_secret = "f0e26e1e-XX" oidc_issuer_url="https://KEYCLOAK/auth/realms/TEST" cookie_secret=1234567891234567 scope="profile openid" cookie_expire="60m" cookie_refresh = "1m" cookie_httponly=false cookie_secure=false skip_provider_button=false ssl_insecure_skip_verify = false

• Version used: 7.1.3 (tested on 6 and 5)
• keycloak used: 12.04 (tests on keycloak 15)

If the same user account in two different browsers, the logins will be successful but after the id token expiry time, the first browser will clear the session and auto log out the user.

Expected Behavior

The user should stay logged-in in every browser irrespective of id token expiry time

Current Behavior

User is logged out after id token expires the first time

Oct 15 07:32:54 oauth2-proxy[786]: [2021/10/15 07:32:54] [stored_session.go:122] Refreshing 10m9.733237754s old session cookie for Session{email:[email protected] user:CiZ1aWQ9YWRtaW4sb3U9VXNlcnMsZGM9bXktZG9tYWluLGRjPWNvbRIEbGRhcA PreferredUsername: token:true id_token:true created:2021-10-15 07:22:44.266762246 +0000 UTC expires:2021-10-15 07:32:43.258243151 +0000 UTC refresh_token:true groups:[Administrator]} (refresh after 10m0s) Oct 15 07:32:54 oauth2-proxy[786]: [2021/10/15 07:32:54] [stored_session.go:76] Error loading cookied session: error refreshing access token for session (Session{email:[email protected] user:CiZ1aWQ9YWRtaW4sb3U9VXNlcnMsZGM9bXktZG9tYWluLGRjPWNvbRIEbGRhcA PreferredUsername: token:true id_token:true created:2021-10-15 07:22:44.266762246 +0000 UTC expires:2021-10-15 07:32:43.258243151 +0000 UTC refresh_token:true groups:[Administrator]}): error refreshing access token: unable to redeem refresh token: failed to get token: oauth2: cannot fetch token: 400 Bad Request

Steps to Reproduce (for bugs)

1. Login with a user account on e.g) chrome
2. Login with the same user account on another browser e.g) Edge
3. Wait 10 minute
4. User is logged out of first browser (chrome) but continues to work normally in second

If the account is used only in one browser with duplicated tabs, refresh session works perfectly even handling multiple requests hitting oauth2-proxy at the same time.

Your Environment

oauth2-proxy + redis + dex all behind nginx reverse proxy (using cache)

dex expiry: idTokens: "10m" oauth2-proxy cookie refresh: "10m"

• Version used: oauth2-proxy 7.1.3

Please refer the scan report of Latest container image Since the last release was made 6 months ago. Alpine has patched Vulnerabilities in few libraries. Can we rebuild the release 7.1.3 and provide a patch release 7.1.4 (Rebuilding with latest alpine image will solve the problem)

I deploy oauth2-proxy as a sidecar container with my component. And expose it as a path in my vip,(https://xxx.xxx.xxx.xxx/aaa/bbb/oauth2-proxy) oauth-proxy config: containers: - args: - --https-address=:4180 - --upstream=http://localhost:8080 - --provider=oidc - --provider-display-name="HHHHHHHH" - --oidc-issuer-url=https://xxx.xxx.xxx.xxx/dex - --client-id=oauth2-proxy - --client-secret=ZXhhbXBsZS1hcHAtc2VjcmV0 - --scope=openid+profile+email+groups+ext - --redirect-url=https://xxx.xxx.xxx.xxx/aaa/bbb/oauth2-proxy/oauth2/callback - --login-url=https://xxx.xxx.xxx.xxxx/aaa/bbb/oauth2-proxy - --email-domain=* - --ssl-insecure-skip-verify=true - --tls-cert-file=/etc/tls/private/tls.crt - --tls-key-file=/etc/tls/private/tls.key - --cookie-secure=false - --cookie-secret=ZXhhbXBsZS1hcHAtc2VjcmV0 - --cookie-expire=0h20m0s image: quay.io/oauth2-proxy/oauth2-proxy:v7.1.3

Expected Behavior

when i view https://xxx.xxx.xxx.xxx/aaa/bbb/oauth2-proxy，it will jump to my dex and then to my componet.

Current Behavior

when i view https://xxx.xxx.xxx.xxx/aaa/bbb/oauth2-proxy，it jumps to https://xxx.xxx.xxx.xxx/oauth2/start，not https://xxx.xxx.xxx.xxx/aaa/bbb/oauth2-proxy/oauth2/start. I cant jump to dex to login in

When I add a option --proxy-prefix=/aaa/bbb it jumps to https://xxx.xxx.xxx.xxx/aaa/bbb/oauth2-proxy/oauth2/start. But not oauth-proxy is working at /aaa/bbb/oauth2/start

Your Environment

Kubernetes v1.21.2 oauth2-proxy v7.1.3 as a sidecar container with my component in a pod. expose oauth-proxy to https://xxx.xxx.xxx.xxx/aaa/bbb/oauth-proxy

I run a setup with oauth2-proxy, Dex and and NGINX ingress-controller, fairly standard. The applications we expose comprise of both web applications (interactive authentication) and APIs (using programmatic Bearer tokens).

The interactive authentication works fine:

• browse to the exposed URL
• the associated Ingress makes sure I'm redirected to oauth2-proxy, who in turn redirects me to the Dex login screen (using authorization code flow)
• I provide credentials
• authorization code workflow completes, a cookie is set
• I can access my application

This kind of convinces me that my setup is spectacularly wrong, so I expect the workflow using bearer tokens to work as well.

Expected Behavior

• obtain OIDC ID token from my OIDC endpoint: Dex
• add this as a Bearer token to my request headers
• perform the API call against the exposed, external address

I now expect to see the request succeed; i.e. get a 200 response from my API.

Current Behavior

A loop occurs:

the API logs:

│ INFO:     10.0.0.124:54836 - "GET /api/upload/uploads HTTP/1.1" 307 Temporary Redirect                                                                                                                                                                                     │
│ INFO:     10.0.0.124:54836 - "GET /api/upload/uploads HTTP/1.1" 307 Temporary Redirect                                                                                                                                                                                     │
│ INFO:     10.0.0.124:54836 - "GET /api/upload/uploads HTTP/1.1" 307 Temporary Redirect                                                                                                                                                                                     │
│ INFO:     10.0.0.124:54872 - "GET /api/upload/uploads HTTP/1.1" 307 Temporary Redirect                                                                                                                                                                                     │
│ INFO:     10.0.0.124:54872 - "GET /api/upload/uploads HTTP/1.1" 307 Temporary Redirect                                                                                                                                                                                     │
│ INFO:     10.0.0.124:54872 - "GET /api/upload/uploads HTTP/1.1" 307 Temporary Redirect                                                                                                                                                                                     

oauth2-proxy logs:

│ 10.0.0.124:52652 - 5902917e2911137e9778ad00f7081335 - [email protected] [2021/10/11 17:16:48] oauth2proxy-oauth2-proxy.customer.svc.cluster.localGET - "/oauth2/auth" HTTP/1.1 "PostmanRuntime/7.28.4" 202 0 0.000                                                                                       │
│ 10.0.0.124:52652 - e766893729474416cbd86a51ca92f909 - [email protected] [2021/10/11 17:16:49] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "PostmanRuntime/7.28.4" 202 0 0.001                                                                                       │
│ 10.0.0.124:52692 - a35e848f003e7ccdd009339f6ceb0166 - [email protected] [2021/10/11 17:16:50] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "PostmanRuntime/7.28.4" 202 0 0.001                                                                                       │
│ 10.0.0.124:52652 - 0cd6f80e4df0e4883bdb8827b1489640 - [email protected] [2021/10/11 17:16:50] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "PostmanRuntime/7.28.4" 202 0 0.000                                                                                       │
│ 10.0.0.124:52692 - e55b72faefc6ffc31f9ae9460f0d4cbd - [email protected] [2021/10/11 17:16:51] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "PostmanRuntime/7.28.4" 202 0 0.000                                                                                       │
│ 10.0.0.124:52652 - 80439af8a47551dfe6a7444d0eddf4ad - [email protected] [2021/10/11 17:16:52] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "PostmanRuntime/7.28.4" 202 0 0.000

Ingress controller logs:

│ 10.0.0.205 - - [11/Oct/2021:17:16:48 +0000] "GET /auth/auth HTTP/1.1" 202 0 "-" "PostmanRuntime/7.28.4" 1524 0.001 [customer-oauth2proxy-oauth2-proxy-80] [] 10.0.0.189:4180 0 0.000 202 5902917e2911137e9778ad00f7081335                                                  │
│ 10.0.0.205 - - [11/Oct/2021:17:16:48 +0000] "GET /api/upload/uploads HTTP/1.1" 202 0 "-" "PostmanRuntime/7.28.4" 0 0.051 [customer-upload-api-8000] [] 18.195.79.36:443 0 0.044 202 5902917e2911137e9778ad00f7081335                                                       │
│ 10.0.0.205 - - [11/Oct/2021:17:16:48 +0000] "GET /api/upload/uploads HTTP/1.1" 307 5 "-" "PostmanRuntime/7.28.4" 1283 0.113 [customer-upload-api-8000] [] 10.0.0.9:8000 5 0.064 307 5902917e2911137e9778ad00f7081335                                                       │
│ 10.0.0.205 - - [11/Oct/2021:17:16:48 +0000] "GET /api/upload/uploads/ HTTP/1.1" 308 164 "https://customer.example.com/api/upload/uploads" "PostmanRuntime/7.28.4" 1137 0.000 [customer-upload-api-8000] [] - - - - f96e3d019ca2e2ce0ff7a86e7d47397d                        │
│ 10.0.0.205 - - [11/Oct/2021:17:16:49 +0000] "GET /auth/auth HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1582 0.004 [customer-oauth2proxy-oauth2-proxy-80] [] 10.0.0.189:4180 0 0.004 202 e766893729474416cbd86a51ca92f909    │
│ 10.0.0.205 - - [11/Oct/2021:17:16:49 +0000] "GET /api/upload/uploads HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 0 0.016 [customer-upload-api-8000] [] 18.195.79.36:443 0 0.016 202 e766893729474416cbd86a51ca92f909         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:49 +0000] "GET /api/upload/uploads HTTP/1.1" 307 5 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1341 0.019 [customer-upload-api-8000] [] 10.0.0.9:8000 5 0.004 307 e766893729474416cbd86a51ca92f909         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:49 +0000] "GET /api/upload/uploads/ HTTP/1.1" 308 164 "https://customer.example.com/api/upload/uploads" "PostmanRuntime/7.28.4" 1137 0.000 [customer-upload-api-8000] [] - - - - d26b717abf299ebb09fd67838291c526                        │
│ 10.0.0.205 - - [11/Oct/2021:17:16:50 +0000] "GET /auth/auth HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1582 0.002 [customer-oauth2proxy-oauth2-proxy-80] [] 10.0.0.189:4180 0 0.000 202 a35e848f003e7ccdd009339f6ceb0166    │
│ 10.0.0.205 - - [11/Oct/2021:17:16:50 +0000] "GET /api/upload/uploads HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 0 0.012 [customer-upload-api-8000] [] 18.195.79.36:443 0 0.016 202 a35e848f003e7ccdd009339f6ceb0166         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:50 +0000] "GET /api/upload/uploads HTTP/1.1" 307 5 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1341 0.015 [customer-upload-api-8000] [] 10.0.0.9:8000 5 0.000 307 a35e848f003e7ccdd009339f6ceb0166         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:50 +0000] "GET /api/upload/uploads/ HTTP/1.1" 308 164 "https://customer.example.com/api/upload/uploads" "PostmanRuntime/7.28.4" 1137 0.000 [customer-upload-api-8000] [] - - - - dbea494e8eaff1708a6f4a07bc8b3846                        │
│ 10.0.0.205 - - [11/Oct/2021:17:16:50 +0000] "GET /auth/auth HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1582 0.003 [customer-oauth2proxy-oauth2-proxy-80] [] 10.0.0.189:4180 0 0.004 202 0cd6f80e4df0e4883bdb8827b1489640    │
│ 10.0.0.205 - - [11/Oct/2021:17:16:50 +0000] "GET /api/upload/uploads HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 0 0.014 [customer-upload-api-8000] [] 18.195.79.36:443 0 0.016 202 0cd6f80e4df0e4883bdb8827b1489640         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:50 +0000] "GET /api/upload/uploads HTTP/1.1" 307 5 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1341 0.016 [customer-upload-api-8000] [] 10.0.0.9:8000 5 0.004 307 0cd6f80e4df0e4883bdb8827b1489640         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:51 +0000] "GET /api/upload/uploads/ HTTP/1.1" 308 164 "https://customer.example.com/api/upload/uploads" "PostmanRuntime/7.28.4" 1137 0.000 [customer-upload-api-8000] [] - - - - 732fa73fdf88dfd8d0cf6f1d4bcb0850                        │
│ 10.0.0.205 - - [11/Oct/2021:17:16:51 +0000] "GET /auth/auth HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1582 0.007 [customer-oauth2proxy-oauth2-proxy-80] [] 10.0.0.189:4180 0 0.008 202 e55b72faefc6ffc31f9ae9460f0d4cbd    │
│ 10.0.0.205 - - [11/Oct/2021:17:16:51 +0000] "GET /api/upload/uploads HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 0 0.020 [customer-upload-api-8000] [] 18.195.79.36:443 0 0.016 202 e55b72faefc6ffc31f9ae9460f0d4cbd         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:51 +0000] "GET /api/upload/uploads HTTP/1.1" 307 5 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1341 0.022 [customer-upload-api-8000] [] 10.0.0.9:8000 5 0.004 307 e55b72faefc6ffc31f9ae9460f0d4cbd         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:51 +0000] "GET /api/upload/uploads/ HTTP/1.1" 308 164 "https://customer.example.com/api/upload/uploads" "PostmanRuntime/7.28.4" 1137 0.000 [customer-upload-api-8000] [] - - - - 276c58113a3a7b5f8a94073f19340b41                        │
│ 10.0.0.205 - - [11/Oct/2021:17:16:52 +0000] "GET /auth/auth HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1582 0.042 [customer-oauth2proxy-oauth2-proxy-80] [] 10.0.0.189:4180 0 0.044 202 80439af8a47551dfe6a7444d0eddf4ad    │
│ 10.0.0.205 - - [11/Oct/2021:17:16:52 +0000] "GET /api/upload/uploads HTTP/1.1" 202 0 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 0 0.048 [customer-upload-api-8000] [] 18.192.2.100:443 0 0.048 202 80439af8a47551dfe6a7444d0eddf4ad         │
│ 10.0.0.205 - - [11/Oct/2021:17:16:52 +0000] "GET /api/upload/uploads HTTP/1.1" 307 5 "http://customer.example.com/api/upload/uploads/" "PostmanRuntime/7.28.4" 1341 0.050 [customer-upload-api-8000] [] 10.0.0.9:8000 5 0.000 307 80439af8a47551dfe6a7444d0eddf4ad  

Funny thing: I actually see this same kind of behavior in the interactive flow when accessing the web application:

oauth2-proxy logs:

│ 10.0.0.124:35354 - 766ba5dfa5594069558ada4ff36fad67 - - [2021/10/11 17:32:34] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" 401 13 0.002                        │
│ 10.0.0.124:41768 - e2faaa778fccc2417b2945869b1cd298 - - [2021/10/11 17:32:34] customer.example.com GET - "/oauth2/start?rd=%2Fdashboard%2F" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" 302 306 0.002                                  │
│ 10.0.0.205:44098 - ee294da2-c13e-4059-98af-b2baa4316302 - - [2021/10/11 17:32:34] 10.0.0.189:4180 GET - "/ping" HTTP/1.1 "kube-probe/1.19+" 200 2 0.000                                                                                                                    │
│ 10.0.0.205:44148 - da084a0e-5977-4539-9de0-aeb56d2829c1 - - [2021/10/11 17:32:36] 10.0.0.189:4180 GET - "/ping" HTTP/1.1 "kube-probe/1.19+" 200 2 0.000                                                                                                                    │
│ 10.0.0.124:41768 - 9565364d45c2289f331c423b722a5bae - [email protected] [2021/10/11 17:32:38] [AuthSuccess] Authenticated via OAuth2: Session{some redacted stuff}                                                                                                            │
│ 10.0.0.124:41768 - 9565364d45c2289f331c423b722a5bae - - [2021/10/11 17:32:38] customer.example.com GET - "/oauth2/callback?code=bix6r2cxjch67zyac6hffkfvr&state=MMnH7iB3vPDNgOqY_eaysJaZ6xQsWP2kbKcLo_rxz-k%3A%2Fdashboard%2F" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; r │
│ 10.0.0.124:35450 - 8d96aaf5e876b5adb5730b112b8ddcf1 - [email protected] [2021/10/11 17:32:38] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" 202 0 0.000            │
│ 10.0.0.124:35460 - 2f91ee9020feb88c6c47675270aab91f - [email protected] [2021/10/11 17:32:38] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" 202 0 0.000            │
│ 10.0.0.124:35462 - 620a365bb023816a9fb22ceb3b319cf7 - [email protected] [2021/10/11 17:32:38] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" 202 0 0.000            │
│ 10.0.0.124:35466 - 5a0c0cbd7d7c85f633ad09ae7eeb8a1d - [email protected] [2021/10/11 17:32:38] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" 202 0 0.001            │
│ 10.0.0.124:35474 - ac276b0747df8fece705d16caf48bdb1 - [email protected] [2021/10/11 17:32:39] oauth2proxy-oauth2-proxy.customer.svc.cluster.local GET - "/oauth2/auth" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" 202 0 0.000            │

Your Environment

• Version used:

  • Chart version 4.2.2
  • Application version 7.1.3

• Endpoints:

  • https://customer.example.com/oidc: Dex
  • https://customer.example.com/auth: oauth2-proxy root, rewritten to the regular oauth2 path (yes I know, I should use the provided setting for this but one problem at a time).

• Application Ingress annotations:

  nginx.ingress.kubernetes.io/auth-signin: https://$host/auth/start?rd=$escaped_request_uri
  nginx.ingress.kubernetes.io/auth-url: http://oauth2proxy-oauth2-proxy.customer.svc.cluster.local/oauth2/auth
  

• API Ingress annotations:

  nginx.ingress.kubernetes.io/auth-signin: https://$host/auth/start?rd=$escaped_request_uri
  nginx.ingress.kubernetes.io/auth-url: http://oauth2proxy-oauth2-proxy.customer.svc.cluster.local/oauth2/auth
  

• oauth2-proxy config:

  Args:                                                                                                                                                                                                                                                                  
       --http-address=0.0.0.0:4180                                                                                                                                                                                                                                          
       --metrics-address=0.0.0.0:44180                                                                                                                                                                                                                                      
       --extra-jwt-issuers=https://customer.example.com/oidc=api-access                                                                                                                                                                                                     
       --oidc-issuer-url=https://customer.example.com/oidc                                                                                                                                                                                                                  
       --provider=oidc                                                                                                                                                                                                                                                      
       --provider-display-name=OIDC                                                                                                                                                                                                                                         
       --redirect-url=https://customer.example.com/auth/callback                                                                                                                                                                                                            
       --skip-jwt-bearer-tokens=true                                                                                                                                                                                                                                        
       --skip-provider-button=true                                                                                                                                                                                                                                          
       --whitelist-domain=.customer.example.com                                                                                                                                                                                                                                      
       --config=/etc/oauth2_proxy/oauth2_proxy.cfg
  
  
  

My guess is that I'm overlooking something simple? Incorrect redirect-url? Bearer token not correctly processed? Maybe I need to forward authorization headers upstream? I've been staring at this for quite some time now, any help would be greatly appreciated.

Description

This change makes sure session expiry takes precedence over periodic session refresh.

Motivation and Context

The session expiry is initialized from the JWT expiry. However oauth2-proxy previously only refreshed sessions based on the configuration, and it's possible to disable the refresh completely. My intuitive understanding was that JWT expiry was then still taken into account, and that periodic refresh was something "on top" of automatic session refresh for expired JWTs. That was not the case.

Previously it was possible to completely disable refresh, or use an expired JWT for a period of time if JWT expiry happened to overlap with periodic refresh.

I would like to get feedback first. If this change makes sense, I will provide test coverage. Please wait with merging until there is test-coverage.

How Has This Been Tested?

I've tested this with JWTs that have a very short expiry and stepping through the debugger and validating sessions are refreshed when necessary.

Checklist:

• [x] My change requires a change to the documentation or CHANGELOG.
• [ ] I have updated the documentation/CHANGELOG accordingly.
• [x] I have created a feature (non-master) branch for my PR.