A reverse proxy that provides authentication with Google, Github or other providers.

Overview

OAuth2 Proxy

Build Status Go Report Card GoDoc MIT licensed Maintainability Test Coverage

A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain or group.

Note: This repository was forked from bitly/OAuth2_Proxy on 27/11/2018. Versions v3.0.0 and up are from this fork and will have diverged from any changes in the original fork. A list of changes can be seen in the CHANGELOG.

Note: This project was formerly hosted as pusher/oauth2_proxy but has been renamed as of 29/03/2020 to oauth2-proxy/oauth2-proxy. Going forward, all images shall be available at quay.io/oauth2-proxy/oauth2-proxy and binaries will be named oauth2-proxy.

Sign In Page

Installation

  1. Choose how to deploy:

    a. Download Prebuilt Binary (current release is v7.0.1)

    b. Build with $ go get github.com/oauth2-proxy/oauth2-proxy which will put the binary in $GOROOT/bin

    c. Using the prebuilt docker image quay.io/oauth2-proxy/oauth2-proxy (AMD64, ARMv6 and ARM64 tags available)

Prebuilt binaries can be validated by extracting the file and verifying it against the sha256sum.txt checksum file provided for each release starting with version v3.0.0.

sha256sum -c sha256sum.txt 2>&1 | grep OK
oauth2-proxy-x.y.z.linux-amd64: OK
  1. Select a Provider and Register an OAuth Application with a Provider
  2. Configure OAuth2 Proxy using config file, command line options, or environment variables
  3. Configure SSL or Deploy behind a SSL endpoint (example provided for Nginx)

Security

If you are running a version older than v6.0.0 we strongly recommend you please update to a current version. See open redirect vulnverability for details.

Docs

Read the docs on our Docs site.

OAuth2 Proxy Architecture

Getting Involved

If you would like to reach out to the maintainers, come talk to us in the #oauth2-proxy channel in the Gophers slack.

Contributing

Please see our Contributing guidelines. For releasing see our release creation guide.

Issues
  • Support for Traefik

    Support for Traefik

    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?

    help wanted question 
    opened by mazzy89 55
  • Introduce example kubernetes deployment & documentation

    Introduce example kubernetes deployment & documentation

    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.

    enhancement help wanted docs Stale 
    opened by Kamilczak020 52
  • Use the raw url path when proxying upstream requests

    Use the raw url path when proxying upstream requests

    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.
    opened by FStelzer 41
  • Add support to ensure user belongs in required groups when using the OIDC provider

    Add support to ensure user belongs in required groups when using the OIDC provider

    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?

    enhancement 
    opened by stefansedich 38
  • Implement subdomain-based routing

    Implement subdomain-based routing

    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.
    enhancement Stale 
    opened by rustyx 36
  • extract email from id_token for azure provider

    extract email from id_token for azure provider

    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.
    opened by weinong 34
  • Describe ingress setup for dynamic callback urls

    Describe ingress setup for dynamic callback urls

    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
    
    1. 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.

    1. 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!!

    Stale 
    opened by elsesiy 33
  • Proposal: Deprecation of cookie splitting

    Proposal: Deprecation of cookie splitting

    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
    enhancement help wanted high-priority breaking 
    opened by JoelSpeed 33
  • Use X-Forwarded-{Proto,Host} on redirect as last resort

    Use X-Forwarded-{Proto,Host} on redirect as last resort

    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.

    opened by linuxgemini 28
  • Extra Headers to Upstream

    Extra Headers to Upstream

    Expected Behavior

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

    Current Behavior

    No option exists

    enhancement help wanted Stale refactor 
    opened by kfox1111 28
  • Split session save function to detect redis duplicate/not found session key error

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

    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.
    opened by wadahiro 0
  • No error message from failed token exchange

    No error message from failed token exchange

    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.

    opened by andreas-p 0
  • Add phabricator provider

    Add phabricator provider

    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.

    opened by kragniz 0
  • Release 7.2.0

    Release 7.2.0

    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.
    docs 
    opened by JoelSpeed 0
  • Provider OIDC with keycloak : refresh_token not replace during re code flow ==> Error 500

    Provider OIDC with keycloak : refresh_token not replace during re code flow ==> Error 500

    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)
    opened by GFlo69 5
  • session refresh error: auto logout after expiry of id token

    session refresh error: auto logout after expiry of id token

    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
    opened by salmanisd 1
  • Vulnerablities in the Container Image

    Vulnerablities in the Container Image

    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)

    image

    opened by rmkanda 1
  • oauth2-proxy behind a ingress redirect to root path, not oauth-proxy

    oauth2-proxy behind a ingress redirect to root path, not oauth-proxy

    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

    opened by szediktam 13
  • Redirect loop in JWT based authentication

    Redirect loop in JWT based authentication

    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.

    invalid 
    opened by nielsn 1
  • Make sure JWT is never expired

    Make sure JWT is never expired

    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.
    opened by stippi2 3
Releases(v7.1.3)
Owner
OAuth2 Proxy
Independent organization for OAuth2 Proxy project
OAuth2 Proxy
A reverse proxy that provides authentication with Google, Github or other providers.

A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain

OAuth2 Proxy 4.2k Oct 19, 2021
The boss of http auth.

Authboss Authboss is a modular authentication system for the web. It has several modules that represent authentication and authorization features that

Volatile Technologies Inc. 2.9k Oct 19, 2021
A proxy that authorizes and enforces a given label in a given PromQL query

prom-authzed-proxy prom-authzed-proxy is a proxy for Prometheus that authorizes the request's Bearer Token with Authzed and enforces a label in a Prom

authzed 25 Oct 6, 2021
JWT login microservice with plugable backends such as OAuth2, Google, Github, htpasswd, osiam, ..

loginsrv loginsrv is a standalone minimalistic login server providing a JWT login for multiple login backends. ** Attention: Update to v1.3.0 for Goog

tarent 1.8k Oct 16, 2021
Golang OpenID Connect Client

adhocore/goic GOIC, Go Open ID Connect, is OpenID connect client library for Golang. It supports the Authorization Code Flow of OpenID Connect specifi

Jitendra 19 Oct 17, 2021
The Single Sign-On Multi-Factor portal for web apps

Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for your applications

Authelia 10.6k Oct 22, 2021
Local proxy for authenticating requests to Cloud Run

Cloud Run Proxy is a small proxy to assist in authenticating as an end-user to Google Cloud Run. It leverages Cloud Run's existing Clo

Seth Vargo 49 Oct 13, 2021
Package goth provides a simple, clean, and idiomatic way to write authentication packages for Go web applications.

Goth: Multi-Provider Authentication for Go Package goth provides a simple, clean, and idiomatic way to write authentication packages for Go web applic

Mark Bates 3.4k Oct 24, 2021
GLAuth 1.2k Oct 14, 2021
Go login handlers for authentication providers (OAuth1, OAuth2)

gologin Package gologin provides chainable login http.Handler's for Google, Github, Twitter, Facebook, Bitbucket, Tumblr, or any OAuth1 or OAuth2 auth

Dalton Hubble 1.4k Oct 16, 2021
Authentication server for Docker Registry 2

The original Docker Registry server (v1) did not provide any support for authentication or authorization. Access control had to be performed externally, typically by deploying Nginx in the reverse proxy mode with Basic or other type of authentication. While performing simple user authentication is pretty straightforward, performing more fine-grained access control was cumbersome.

Cesanta Software 1k Oct 15, 2021
A standalone, specification-compliant, OAuth2 server written in Golang.

Go OAuth2 Server This service implements OAuth 2.0 specification. Excerpts from the specification are included in this README file to describe differe

Richard Knop 1.8k Oct 17, 2021
Scaffold to help building Terraform Providers using AWS IAM authentication.

Terraform Provider Scaffolding This repository is a template for a Terraform provider. It is intended as a starting point for creating Terraform provi

Paul Zietsman 2 Sep 6, 2021
An authentication proxy for Google Cloud managed databases

db-auth-gateway An authentication proxy for Google Cloud managed databases. Based on the ideas of cloudsql-proxy but intended to be run as a standalon

null 21 Oct 9, 2021
Go-Guardian is a golang library that provides a simple, clean, and idiomatic way to create powerful modern API and web authentication.

❗ Cache package has been moved to libcache repository Go-Guardian Go-Guardian is a golang library that provides a simple, clean, and idiomatic way to

Sanad Haj Yahya 308 Oct 10, 2021
A collection of authentication Go packages related to OIDC, JWKs and Distributed Claims.

cap (collection of authentication packages) provides a collection of related packages which enable support for OIDC, JWT Verification and Distributed Claims.

HashiCorp 301 Oct 12, 2021
sso, aka S.S.Octopus, aka octoboi, is a single sign-on solution for securing internal services

sso See our launch blog post for more information! Please take the SSO Community Survey to let us know how we're doing, and to help us plan our roadma

BuzzFeed 2.8k Oct 16, 2021
HTTP Authentication middlewares

goji/httpauth httpauth currently provides HTTP Basic Authentication middleware for Go. It is compatible with Go's own net/http, goji, Gin & anything t

Goji 210 Oct 12, 2021
Provides AWS STS credentials based on Google Apps SAML SSO auth with interactive GUI support

What's this This command-line tool allows you to acquire AWS temporary (STS) credentials using Google Apps as a federated (Single Sign-On, or SSO) pro

Quan Hoang 24 Sep 25, 2021