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

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.1.0)

    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.

Owner
OAuth2 Proxy
Independent organization for OAuth2 Proxy project
OAuth2 Proxy
Comments
  • Support for Microsoft Identity platform with Azure provider

    Support for Microsoft Identity platform with Azure provider

    At the moment the Azure provider supports only Azure Active Directory (v1.0) endpoints. Version v1.0 is deprecated by Microsoft and not fully compliant with the OIDC protocol.

    Expected Behavior

    The azure provider should be able to retrieve a JWT token using the v2.0 endpoint.

    Current Behavior

    At the moment if you use a v2.0 endpoint you get the error:

    AADSTS901002: The 'resource' request parameter is not supported.
    

    Steps to Reproduce (for bugs)

    This should be a working configuration:

    provider: azure
    azure-tenant: [REDACTED]
    oidc-issuer-url: https://login.microsoftonline.com/[REDACTED]/v2.0
    resource: 6dae42f8-4368-4678-94ff-3960e28e3630
    set-xauthrequest: "true"
    

    Your Environment

    • AKS managed AAD cluster
    Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"9a45ba1752db920873e084791faff8d470278b09", GitTreeState:"clean", BuildDate:"2021-05-19T22:28:02Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}
    
    • oauth2-proxy: chart v3.3.2, application v7.1.3
  • 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.

  • CookieRefresh option does not refresh session age, spams logs

    CookieRefresh option does not refresh session age, spams logs

    When a session is old enough to be "refreshed", its age is never reset, causing subsequent authenticated requests to continually spam "Refreshing old session cookie" in the logs.

    Expected Behavior

    When:

    • --cookie-refresh=1m is set
    • multiple calls to /oauth2/auth are made over the course of several minutes

    I expect that:

    • in the logs, at most 1 request per minute has a "Refreshing old session cookie" message
    • in the logs, the age of this request message never significantly exceeds my --cookie-refresh parameter.
    • On the client, I see an updated cookie with a new CreatedAt

    Current Behavior

    For simple CookieSession sessions backed by basic auth, every request after the initial refresh duration logs a "Refresh" message.

    For OIDC sessions backed by redis, it appears to continually re-authenticate an unexpired access token, until eventually the access token expires.

    Possible Solution

    When a session should be refreshed, it's CreatedAt could be reset to now. Alternatively, a second RefreshedAt could be tracked. Alternatively, the --cookie-refresh option could be removed.

    Steps to Reproduce (for bugs)

    A simple reproduction of the case:

    1. Run a test oauth2_proxy (using password file auth for test simplicity)
    docker run --mount type=bind,source=/path/to/passwordfolder,target=/data -p 127.0.0.1:4180:4180 quay.io/oauth2-proxy/oauth2-proxy  -http-address='0.0.0.0:4180' -htpasswd-file=/data/passwords.txt -cookie-secret='YmJiYmJiYmJiYmJiYmJiYg==' -client-id=foo -client-secret=bar -cookie-secure=false -cookie-refresh=60s
    
    1. log in via curl, saving the cookie
    curl -c cookies.txt -v 'http://127.0.0.1:4180/oauth2/sign_in' --data 'rd=%2F&username=testuser&password=testpassword'
    
    1. continually re-request authentication status
    while true; do
      date
      curl -v '127.0.0.1:4180/oauth2/auth' -c cookies.txt -b cookies.txt
      md5 cookies.txt
      tail -n1 cookies.txt | ruby -rbase64 -rjson -ne 'p JSON.parse(Base64.decode64($_.split.last.split("|").first))'
      sleep 15
    done
    
    1. observe the log output: oauth2_proxy:
    172.17.0.1 - testuser [2020/04/13 23:33:58] [AuthSuccess] Authenticated via HtpasswdFile
    172.17.0.1 - - [2020/04/13 23:33:58] 127.0.0.1:4180 POST - "/oauth2/sign_in" HTTP/1.1 "curl/7.54.0" 302 0 0.000
    172.17.0.1 - testuser [2020/04/13 23:34:03] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.000
    172.17.0.1 - testuser [2020/04/13 23:34:18] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.000
    172.17.0.1 - testuser [2020/04/13 23:34:33] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.000
    172.17.0.1 - testuser [2020/04/13 23:34:49] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.001
    [2020/04/13 23:35:04] [oauthproxy.go:872] Refreshing 1m5.5872417s old session cookie for Session{email: user:testuser PreferredUsername: created:2020-04-13 23:33:58.4127583 +0000 UTC} (refresh after 1m0s)
    172.17.0.1 - testuser [2020/04/13 23:35:04] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.001
    [2020/04/13 23:35:19] [oauthproxy.go:872] Refreshing 1m20.5872417s old session cookie for Session{email: user:testuser PreferredUsername: created:2020-04-13 23:33:58.4127583 +0000 UTC} (refresh after 1m0s)
    172.17.0.1 - testuser [2020/04/13 23:35:19] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.000
    [2020/04/13 23:35:35] [oauthproxy.go:872] Refreshing 1m36.5872417s old session cookie for Session{email: user:testuser PreferredUsername: created:2020-04-13 23:33:58.4127583 +0000 UTC} (refresh after 1m0s)
    172.17.0.1 - testuser [2020/04/13 23:35:35] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.000
    [2020/04/13 23:35:50] [oauthproxy.go:872] Refreshing 1m51.5872417s old session cookie for Session{email: user:testuser PreferredUsername: created:2020-04-13 23:33:58.4127583 +0000 UTC} (refresh after 1m0s)
    172.17.0.1 - testuser [2020/04/13 23:35:50] 127.0.0.1:4180 GET - "/oauth2/auth" HTTP/1.1 "curl/7.54.0" 202 0 0.001
    

    bash(edited)

    MD5 (cookies.txt) = 19502faba8fd0ea08293130b8b577904
    {"User"=>"7F31PtJ13MC1MRepdbxdR57tHIRDAHq7", "CreatedAt"=>"2020-04-13T23:33:58.4127583Z"}
    ...
    MD5 (cookies.txt) = 7e53bd520ddb9dc1e9d7e9830fc7557c
    {"User"=>"0WsAYW4zvAIKq9kvkba7hPjLg7Lsqbuh", "CreatedAt"=>"2020-04-13T23:33:58.4127583Z"}
    ...
    MD5 (cookies.txt) = 0eb4c50b0a28563df35574bc5674a11a
    {"User"=>"oP6+kfZDu6MitpHE007d0Pz+7265EWEh", "CreatedAt"=>"2020-04-13T23:33:58.4127583Z"}
    ...
    

    Context

    While investigating other issues related to traffic and redirect loops, I was led astray by the surprising frequency of these Refresh messages, especially frequent & continual Refreshes for the same user that were well after the --cookie-refresh parameter.

    Your Environment

    We're using oauth2-proxy as a delegated authentication endpoint for ingress-nginx in kubernetes. However, the same issue reproduces outside that environment.

  • 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.
  • 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?

  • Add Azure groups support and Azure OAuth v2.0

    Add Azure groups support and Azure OAuth v2.0

    Description

    This PR adds support for Azure groups and Azure OAuth v2.0 (https://login.microsoftonline.com/{tenant_id}/v2.0)

    Resolves https://github.com/oauth2-proxy/oauth2-proxy/issues/1231 Resolves https://github.com/oauth2-proxy/oauth2-proxy/issues/1505 Resolves https://github.com/oauth2-proxy/oauth2-proxy/issues/888

    Motivation and Context

    This is an extended PR for https://github.com/oauth2-proxy/oauth2-proxy/pull/1514

    How Has This Been Tested?

    Tested with Azure environment using both OAuth v1 and v2.0 Validated that it works with and without allowed-group configured.

    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.
  • Not redirecting to subpath after login using Traefik's 401 errors middleware

    Not redirecting to subpath after login using Traefik's 401 errors middleware

    Expected Behavior

    1. Attempt to access service on subpath example.domain/sub/path
    2. Get redirected to oauth2-proxy on example.domain/oauth2/auth
    3. Log in through auth provider
    4. Get redirected to example.domain/sub/path

    Current Behavior

    1. Attempt to access service on subpath example.domain/sub/path
    2. Get redirected to oauth2-proxy on example.domain/oauth2/auth
    3. Log in through auth provider
    4. Get redirected to example.domain instead of example.domain/sub/path

    Steps to Reproduce (for bugs)

    1. Use following config values for oauth2-proxy
      oauth2_proxy.cfg: |-
        provider = "oidc"
        provider_display_name = "Keycloak"
        redirect_url = "https://example.domain/oauth2/callback"
        oidc_issuer_url = "https://example.domain/auth/"
        cookie_secure = false
        reverse_proxy = true
        email_domains = [ "*" ]
        upstreams = [ "file:///dev/null" ]
        pass_access_token = true
        pass_authorization_header = true
        set_authorization_header = true
        set_xauthrequest = true
        pass_user_headers = true
        whitelist_domains= [ ".example.domain" ]
    
    1. Set up traefik middlewares and ingresses as currently described in the docs: https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#forwardauth-with-401-errors-middleware In kubernetes CRD form:
    apiVersion: traefik.containo.us/v1alpha1
    kind: Middleware
    metadata:
      name: auth-headers
    spec:
      headers:
        sslRedirect: true
        stsSeconds: 315360000
        browserXssFilter: true
        contentTypeNosniff: true
        forceSTSHeader: true
        stsIncludeSubdomains: true
        stsPreload: true
        frameDeny: true
    ---
    apiVersion: traefik.containo.us/v1alpha1
    kind: Middleware
    metadata:
      name: oauth-auth
    spec:
      forwardAuth:
        address: https://example.domain/oauth2/auth
        trustForwardHeader: true
    ---
    apiVersion: traefik.containo.us/v1alpha1
    kind: Middleware
    metadata:
      name: oauth-errors
    spec:
      errors:
        status:
          - "401-403"
        service:
          name: oauth2-proxy
          port: 80
        query: "/oauth2/sign_in"
    ---
    apiVersion: traefik.containo.us/v1alpha1
    kind: IngressRoute
    metadata:
      name: oauth2-proxy
    spec:
      entryPoints:
        - websecure
      routes:
      - match: PathPrefix(`/oauth2/`)
        kind: Rule
        services:
        - name: oauth2-proxy
          port: 80
        middlewares:
        - name: auth-headers
    
    1. Expose a service
    apiVersion: traefik.containo.us/v1alpha1
    kind: IngressRoute
    metadata:
      name: subpath-test
    spec:
      entryPoints:
      - websecure
      routes:
      - match: PathPrefix(`/foo/bar`)
        kind: Rule
        services:
        - name: bar
          port: 8080
        middlewares:
        - name: oauth-errors
          namespace: traefik-v2
        - name: oauth-auth
          namespace: traefik-v2
    
    1. Navigate to example.domain/foo/bar, follow login flow

    Context

    There seem to be quite a few issues related to Oauth2 Proxy and Traefik, however the closest I could find to my current issue is https://github.com/oauth2-proxy/oauth2-proxy/issues/397 which is over a year old. Besides the environment traefik is running in, the issue is very similar. https://github.com/oauth2-proxy/oauth2-proxy/issues/1255 seems somewhat similar as well, but I'm currently not using skip-provider-button.

    As there are several issues related to Traefik + Oauth2 Proxy both here and on Traefik's github page, I might have missed potential solutions, but from what I've read so far it seems like the only workaround at the moment is to create a middleware that attaches the X-Auth-Request-Redirect header manually. As Traefik is currently not offering dynamic headers, this has to be done per service. Both https://github.com/oauth2-proxy/oauth2-proxy/issues/397 and https://github.com/oauth2-proxy/oauth2-proxy/issues/46#issuecomment-687155032 seem to use custom middlewares for each service to solve the issue, which is far from ideal. https://github.com/traefik/traefik/issues/6839 might eventually provide a generic solution from Traefik's site, although I'm not completely sure if this is a surefire fix.

    An attempt was made at providing the correct functionality from Traefik's side: https://github.com/traefik/traefik/pull/6835 however developers did not like the oauth2-proxy specific approach.

    I've posted this here as oauth2-proxy seems more inclined to adopt Traefik specific fixes than the other way around.

    Your Environment

    • Version used: oauth-proxy2 v7.1.3 traefik v2.4.9 kubernetes v1.20

    Multiple services are hosted on the same domain, but under different subpaths.

  • 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.
  • 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.
  • Azure provider with v7.2.1 and ADAL stop working - Access token validation failure. Invalid audience

    Azure provider with v7.2.1 and ADAL stop working - Access token validation failure. Invalid audience

    After the update from v7.2.0 to v7.2.1 the integration with the AAD stops working. We analyzed the difference between the two versions and we understood our issue is this PR: #1433

    The pod produces these loglines:

    [2022/01/06 13:32:29] [internal_util.go:74] token validation request failed: status 401 - {"error":{"code":"InvalidAuthenticationToken","message":"Access token validation failure. Invalid audience.","innerError":{"date":"2022-01-06T13:32:29","request-id":"[REDACTED]","client-request-id":"[REDACTED]"}}}
    [2022/01/06 13:32:29] [internal_util.go:69] 401 GET https://graph.microsoft.com/v1.0/me {"error":{"code":"InvalidAuthenticationToken","message":"Access token validation failure. Invalid audience.","innerError":{"date":"2022-01-06T13:32:29","request-id":"[REDACTED]","client-request-id":"[REDACTED]"}}}
    10.5.1.44:59808 - [REDACTED] - [REDACTED] [2022/01/06 13:32:29] [AuthFailure] Session validation failed: Session{email:[REDACTED] user: PreferredUsername: token:true id_token:true created:2022-01-06 13:32:29.287771102 +0000 UTC m=+2927.613337671 expires:2022-01-06 14:44:17 +0000 UTC refresh_token:true}
    

    We analyzed the code. Here is the code involved:

    • https://github.com/oauth2-proxy/oauth2-proxy/blob/master/oauthproxy.go#L757-L762
    • https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/azure.go#L361-L363
    • https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/internal_util.go#L69
    • https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/internal_util.go#L74

    Our pod is running in this way:

    --http-address=0.0.0.0:4180
    --metrics-address=0.0.0.0:44180
    --azure-tenant=[REDACTED]
    --cookie-domain=[REDACTED]
    --cookie-expire=1h
    --cookie-refresh=59m
    --oidc-email-claim=sub
    --oidc-issuer-url=https://sts.windows.net/[REDACTED]/
    --pass-access-token=true
    --pass-user-headers=true
    --provider=azure
    --resource=6dae42f8-4368-4678-94ff-3960e28e3630
    --set-xauthrequest=true
    --whitelist-domain=.[REDACTED]
    --config=/etc/oauth2_proxy/oauth2_proxy.cfg
    

    We use Managed AAD with our AKS clusters. We configure OAuth2 Proxy to work with ADAL but the request for the validation is made to MSAL. We presume this problem is strictly connected to #1144 and #1231

    Expected Behavior

    We expect that the Azure provider is able to validate the token using the same Graph endpoint version or at least it must be able to work.

    Your Environment

    • Version used: AKS 1.21.2
  • More fields in `/oauth2/userinfo`

    More fields in `/oauth2/userinfo`

    Expected Behavior

    The /oauth2/userinfo endpoint returns the email address (and I think one other field). It would be nice to have this configurable in a way to return more data from the underlying token in a configurable way.

    Current Behavior

    The /oauth2/userinfo endpoint does not return much info apart from email.

    Possible Solution

    Make it configurable which fields from the token are passed into this endpoint.

    Context

    The use case for this would be front-ends where you want custom fields out of the token to be readable by JS. I use Louketo at the moment to protect some front-ends and would like to switch. One of the things I do is read the user's theme settings from their token (theme depends on the group they are in, in keycloak). I do this via a similar endpoint in Louketo where the entire decoded token is available. That might be a bit overkill, but having the ability to add fields to the userinfo endpoint would be useful.

    Your Environment

    • Version used: v6.1.1
  • [Alpha config] Default values are not set

    [Alpha config] Default values are not set

    Expected Behavior

    When I read the doc and tried to use --alpha-config option with my config file, I expected that OAuth2-proxy use the following default values:

    • Providers[].oidcConfig.emailClaim: "email"
    • Providers[].oidcConfig.groupsClaim: "groups"
    • Providers[].oidcConfig.userIDClaim: "email"
    • Providers[].oidcConfig.audienceClaims: ["aud"]

    Current Behavior

    These variables are empty, thus I failed to authenticate users using my OIDC provider (currently, I'm using Keycloak) I checked this behavior on both the master branch (build manually) and docker image v7.3.0.

    Possible Solution

    In loadAlphaOptions, we create an empty AlphaOptions struct then load the config yaml file, and finally, overwrite the old style options using the AlphaOptions. If we don't set such default variables in our config yaml file, the AlphaOptions does not contain default variables. I think we should define NewAlphaOptions function in order to initialize an AlphaOptions with default variables like an old style options

    If this solution is reasonable, I will work on this.

    Steps to Reproduce (for bugs)

    1. Clone this repository
    2. Add these lines after this line in order to check the options
    bs, _ = json.Marshal(opts)
    fmt.Println(string(bs))
    
    1. Prepare alpha-config yaml file. Currently, I'm using this alpha-config.yaml:
    server:
      BindAddress: '0.0.0.0:4180'
    metricsServer:
      BindAddress: '0.0.0.0:44180'
    providers:
    - clientID: testclient
      clientSecret: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
      id: keycloak
      oidcConfig:
        insecureAllowUnverifiedEmail: true
        insecureSkipIssuerVerification: true
        issuerURL: http://keycloak.keycloak.svc.cluster.local:8080/auth/realms/oauth2
      provider: keycloak-oidc
    upstreamConfig:
      proxyRawPath: true
      upstreams:
      - id: upstream
        path: ^/oauth2/(.*)$
        rewriteTarget: /$1
        uri: http://upstream.upstream.svc.cluster.local:5001
    
    1. Build and run the binary with options:
    go build
    ./oauth2-proxy --alpha-config=alpha-config.yaml --email-domain="*" --cookie-secret="XXXXXXXXXXXXXXXX"
    
    1. Check the print log (I omitted unnecessary lines)
    {
      "ProxyPrefix": "/oauth2",
      ...
      "Providers": [
        {
          "clientID": "testclient",
          ...
          "oidcConfig": {
            "issuerURL": "http://keycloak.keycloak.svc.cluster.local:8080/auth/realms/oauth2",
            "insecureAllowUnverifiedEmail": true,
            "insecureSkipIssuerVerification": true
          },
          ...
        }
      ],
      ...
    }
    

    Ideally, oidcConfig should be like this:

    "oidcConfig": {
        "insecureSkipNonce": true,
        "emailClaim": "email",
        "groupsClaim": "groups",
        "userIDClaim": "email",
        "audienceClaims": [
          "aud"
        ]
    },
    

    Context

    We have to set these default variables explicitly in our config file. But it does not match the document.

    Your Environment

    • Version used: master branch
  • Ignore ID token signature verification

    Ignore ID token signature verification

    Ignore ID token signature verification

    Description

    When using OIDC provider, add an option ('insecureSkipSignatureCheck') to ignore ID token signature verification. This option was added due to Azure issues. Warning: This option is only available in alpha configuration.

    Example: alpha-config.yml

    ...
    providers:
      - id: oidc
        clientID: xxxx
        clientSecret: xxxx
        provider: oidc
        oidcConfig:
          insecureSkipSignatureCheck: true
         ...
    

    Motivation and Context

    See issue #1908

    How Has This Been Tested?

    Needs to be tested.

    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.
  • Issue 1836: Fix expired OIDC tokens

    Issue 1836: Fix expired OIDC tokens

    Fix expired OIDC tokens

    Description

    Check IDToken expiration time, to see if token must be refreshed. Do not rely only in session age.

    Motivation and Context

    Fix issue #1836

    How Has This Been Tested?

    Needs testing.

    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.
  • Add Mastodon provider

    Add Mastodon provider

    Hello! This pull request adds a Mastodon provider. It was pretty straight forward to add - I was able to copy/paste the DigitalOcean provider and make some tweaks.

    The provider works and is in use in production already, but this pull request is not yet ready to merge as I have yet to write any tests and there's some creaky parts I'll note in review comments. I thought I'd open this PR to show my work early though :)

  • Issue 1878: Validate URL call does not correctly honor already set UR…

    Issue 1878: Validate URL call does not correctly honor already set UR…

    Fix validate URL - append query string marker (?) or a separator (&) depending on URL having or not query parameters

    Description

    If the validate URL already contains URL parameters like in

    https://my.provider.de/2.0/users/me?with_permissions=true&with_roles=true

    oauth2-proxy doesn't honor this circumstance and appends a new query string marker (?) instead of a separator (&) and the URL becomes

    https://my.provider.de/2.0/users/me?with_permissions=true&with_roles=true?access_token=eyJ0eXAiOiJKV1...

    which leads to problems depending on the upstream server implementation.

    Motivation and Context

    Fix issue 1878.

    How Has This Been Tested?

    Needs to be tested

    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.
  • COOKIE_REFRESH always on 1h

    COOKIE_REFRESH always on 1h

    COOKIE_REFRESH always on 1h

    Expected Behavior

    If I change the cookie-refresh value to for example "5m", I excpect that the expiration date will be 5min in the future.

    Current Behavior

    But the value change doesn't show any effect. Exp time is still one hour. The oauth2-proxy logs show that the config is made but it doesn't take any effect.

    Possible Solution

    ...

    Steps to Reproduce (for bugs)

    OAUTH2_PROXY_COOKIE_REFRESH: '5m' OAUTH2_PROXY_COOKIE_EXPIRE: '10m'

    Logs: [oauthproxy.go:168] Cookie settings: name:_oauth2_proxy secure(https):false httponly:true expiry:10m0s domains: path:/ samesite: refresh:after 5m0s

    Provider: OIDC

    I'm using alpha config.

    Context

    The refresh token will not be triggered after this hour past. Only if I reload the browser. Sincerely I'm not sure if this is a default behaviour?

    Your Environment

    • Version used: 7.3.0
A standalone reverse-proxy to enforce Webauthn authentication
A standalone reverse-proxy to enforce Webauthn authentication

A standalone reverse-proxy to enforce Webauthn authentication. It can be inserted in front of sensitive services or even chained with other proxies (e

Dec 24, 2022
An authentication proxy for Google Cloud managed databases
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

Dec 5, 2022
Go login handlers for authentication providers (OAuth1, OAuth2)
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

Dec 30, 2022
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

Mar 31, 2022
Authelia: an open-source authentication and authorization server providing two-factor authentication
Authelia: an open-source authentication and authorization server providing two-factor authentication

Authelia is an open-source authentication and authorization server providing two

Jan 5, 2022
Authentication Plugin for implementing Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0, SAML Authentication
Authentication Plugin for implementing Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0, SAML Authentication

Authentication Plugin for implementing Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0, SAML Authentication

Jan 8, 2023
A simple passwordless authentication middleware that uses only email as the authentication provider
A simple passwordless authentication middleware that uses only email as the authentication provider

email auth A simple passwordless authentication middleware that uses only email as the authentication provider. Motivation I wanted to restrict access

Jul 27, 2022
Authorization and authentication. Learning go by writing a simple authentication and authorization service.

Authorization and authentication. Learning go by writing a simple authentication and authorization service.

Aug 5, 2022
Oct 8, 2022
Server bridging Google's OAuth and service using Radius for authentication

Fringe Fringe is an easy workaround for Google Workplace users who need a Radius server to perform authentication on behalf of other services (e.g. 80

Mar 7, 2022
A very simple HTTP reverse proxy that checks that requests contain a valid secret as a bearer token

bearproxy -- Authorization enforcing HTTP reverse proxy Bearproxy is a very simple HTTP reverse proxy that checks that requests contain a valid secret

Nov 11, 2021
A simple passwordless proxy authentication middleware using email.
A simple passwordless proxy authentication middleware using email.

email proxy auth A simple passwordless proxy authentication middleware that uses only email as the authentication provider. Motivation I wanted to res

Jul 27, 2022
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

Dec 23, 2022
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

Dec 29, 2022
AuthService is a service that provides authentication with Minecraft Mojang.

AuthService AuthService is a service that provides authentication with Minecraft Mojang. Protobuf is managed by Buf. Command to pull Protobuf files wi

Aug 20, 2022
Demonstration of sharing secret data between an OAuth/OIDC client and an Identity Providers web client.

OAuth / OIDC Cubbyhole Share secret data between client applications. This is mostly a demonstration of some of the work I've been evaluating at Storj

Mar 21, 2022
Provides AWS STS credentials based on Google Apps SAML SSO auth with interactive GUI support
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

Sep 29, 2022
JWT login microservice with plugable backends such as OAuth2, Google, Github, htpasswd, osiam, ..
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

Dec 24, 2022
A Sample Integration of Google and GitHub OAuth2 in Golang (GoFiber) utilising MongoDB

Go Oauth Server This is sample OAuth integration written in GoLang that also uses MongoDB. This is a sample TODO Application where people can Create a

Dec 27, 2022