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

Issues
  • 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
  • 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
    enhancement Stale 
    opened by mvalenzisi 49
  • 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.

    bug help wanted Stale 
    opened by YenTheFirst 43
  • 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
  • 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
  • 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
  • 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
    enhancement Stale 
    opened by gboor 31
  • Unable to set `username` when using Keycloak provider

    Unable to set `username` when using Keycloak provider

    I am setting up the following environment:

    User | Nginx | Oauth2 <---> Keycloak | Grafana

    This is the nginx configuration (following the example here):

    server {
            listen 443 ssl default_server;
            # listen [::]:443 ssl default_server;
    
            ssl_certificate /etc/nginx/ssl/nginx_vas_cz.crt;
            ssl_certificate_key /etc/nginx/ssl/nginx_vas_cz.key;
    
            root /var/www/html;
    
            # Add index.php to the list if you are using PHP
            index index.html index.htm index.nginx-debian.html;
    
            server_name _;
    
            location / {
                    # First attempt to serve request as file, then
                    # as directory, then fall back to displaying a 404.
                    try_files $uri $uri/ =404;
            }
    
            location /grafana/ {
                    auth_request /oauth2/auth;
                    error_page 401 = /oauth2/sign_in;
    
                    # pass information about the user to the backend
                    # requires oauth2-proxy to run with --set-xauthrequest flag
                    auth_request_set $user $upstream_http_x_auth_request_user;
                    auth_request_set $email $upstream_http_x_auth_request_email;
                    auth_request_set $name $upstream_http_x_auth_request_preferred_username;
                    proxy_set_header X-Username $user;
                    proxy_set_header X-Email $email;
                    proxy_set_header X-Name $name;
    
                    proxy_pass http://grafana.vas.cz:3000/;
            }
    
            location /oauth2/ {
                    proxy_pass http://oauth.vas.cz:4180;
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Scheme $scheme;
                    proxy_set_header X-Auth-Request-Redirect $request_uri;
            }
    
            location = /oauth2/auth {
                    proxy_pass http://oauth.vas.cz:4180;
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Scheme $scheme;
                    # nginx auth_request includes headers but not body
                    proxy_set_header Content-Length "";
                    proxy_pass_request_body off;
            }
    }
    

    When I access https://nginx.vas.cz/grafana/, I get redirected to Keycloak login page, perform the login and then sent to Grafana, but without login.

    If I change proxy_set_header X-Username $user; to proxy_set_header X-Username "<new user>"; (in other words I force the login user), the user gets created in Grafana with the following profile:

    • Name = <my email>
    • Email = <my email>
    • Username = <new user>

    which tells me that everything is correctly configured (or I will not be able to login).

    According to your documentation, the --set-xauthorequest option should enable the following headers: X-Auth-Request-User, X-Auth-Request-Email and X-Auth-Request-Preferred-Username, so apparently the X-Auth-Request-User is not resolved.

    This is the authentication result I get in the oauth2-proxy log:

    [2020/07/17 14:10:45] [requests.go:26] 200 GET http://keycloak.vas.cz:8080/auth/realms/tutorial01/protocol/openid-connect/userinfo {"sub":"f4bb8645-f16f-4237-a9e4-58dea9e046f7","email_verified":false,"name":"<name surname>","groups":["/admin"],"preferred_username":"<username>","given_name":"<name>","family_name":"<surname>","email":"<email>"}
    192.168.56.5:57446 - <email> [2020/07/17 14:10:45] [AuthSuccess] Authenticated via OAuth2: %!s(PANIC=String method: runtime error: invalid memory address or nil pointer dereference)
    [2020/07/17 14:10:45] [cookies.go:48] Warning: request host "nginx.vas.cz" did not match any of the specific cookie domains of ""
    

    Keycloak is returning all the expected information from the user.

    So, I tried a different test:

    proxy_set_header X-Username "newuser";
    proxy_set_header X-User-Email "email";
    proxy_set_header X-User-Name "name";
    

    and again the user gets created with

    • Name = "name"
    • Email = "email"
    • Username = "newuser"

    Putting together the two tests:

    $upstream_http_x_auth_request_email = <email in KC> OK

    $upstream_http_x_auth_request_preferred_username = <email in KC>, which is wrong. Note how the "preferred_username" in KC reply is the "", not the email.

    $upstream_http_x_auth_request_user is resolved to <email in KC> too. To verify this, I made the following test:

    proxy_set_header X-Username "new_user";
    proxy_set_header X-User-Email $email;
    proxy_set_header X-User-Name $user;
    

    and I got the user created with "Name" = "<email>".

    This is my configuration for oauth2:

    ./oauth2/oauth2-proxy --provider=keycloak --client-id=oauth2 --client-secret=<secret> --login-url="http://keycloak.vas.cz:8080/auth/realms/tutorial01/protocol/openid-connect/auth" --redeem-url="http://keycloak.vas.cz:8080/auth/realms/tutorial01/protocol/openid-connect/token" --validate-url="http://keycloak.vas.cz:8080/auth/realms/tutorial01/protocol/openid-connect/userinfo" --keycloak-group=/admin --email-domain=* --cookie-secret=<secret> --http-address="http://192.168.56.8:4180" --scope=openid --set-xauthrequest=true
    

    Expected Behavior

    $upstream_http_x_auth_request_email = <email in KC> OK

    $upstream_http_x_auth_request_preferred_username = <preferred username in KC> i.e. the shortname uid

    $upstream_http_x_auth_request_user = <name surname> i.e. the "name" filed in KC response.

    Current Behavior

    Everything is apparently mapped to the user's email

    Update: apparently, after further investigation, it seems that $upstream_http_x_auth_request_preferred_username and $upstream_http_x_auth_request_user are not returned at all.

    Possible Solution

    Steps to Reproduce (for bugs)

    The above should be enough. Let me know if you need something more.

    Context

    I'm setting authentication behind a authorization proxy.

    Your Environment

    • Version used: oauth2-proxy v6.0.0 (built with go1.14.2)
    bug help wanted Stale 
    opened by aizzi 30
  • Can I use this repo to work with Tiktok?

    Can I use this repo to work with Tiktok?

    Hello: I have Tiktok API key, but since I don't own any internet domain, I can't use Oauth2 to get access tokens from Tiktok. I believe the Oauth2 in Tiktok is the same as Google Oauth2, so I want to know if I can use this repo to get access tokens from Tiktok. You know that for all the people who don't own their own internet domains, it is nearly impossible to use Oauth2 in Tiktok directly. Please advise, Thanks,

    opened by zydjohnHotmail 0
  • Corrects request endpoint

    Corrects request endpoint

    Description

    The endpoint is repos, not repo, documentation

    Motivation and Context

    Don't see an open issue for this, but it is indeed broken, if checking if a user has a repo, the proxy just returns 500

    How Has This Been Tested?

    I double checked the endpoint is correct by making requests to it, if you really want me to test further I can, but I don't see the need

    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 adamsong 0
  • Change error type for redirect parsing errors

    Change error type for redirect parsing errors

    Description

    This changes the error type returned when the proxy fails to parse the redirect target to be a 400 error instead of a 500 error.

    As far as I can tell, the only way that this can fail is a failure to parse the properties of the request to identity the redirect target. This indicates that the user has sent a malformed request, and so should result in a 400 rather than a 500.

    I've added a test to exercise this, based on a real work example.

    Motivation and Context

    Closes #1516

    How Has This Been Tested?

    • Added a unit test for this

    • Tested locally by:

      1. Building a local docker image
      2. Updating the local environment config to set skip_provider_button="true"
      3. Updating the docker-compose config to use the local docker image
      4. Running make local-env-up
      5. Running curl 'localhost:4180/?q=%va' -v

      Using the default image in the local env, this returns a 500. Using the locally built image with this change, this returns a 400.

    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 Niksko 0
  • Go vet issue

    Go vet issue

    go vet ./... returns an issue when running

    Expected Behavior

    Pass go vet ./...

    go vet ./...

    github.com/oauth2-proxy/oauth2-proxy/v7/pkg/requests

    pkg/requests/result.go:18:2: method UnmarshalJSON() (*simplejson.Json, error) should have signature UnmarshalJSON([]byte) error pkg/requests/result.go:72:18: method UnmarshalJSON() (*simplejson.Json, error) should have signature UnmarshalJSON([]byte) error

    Current Behavior

    Possible Solution

    Steps to Reproduce (for bugs)

    go vet ./...

    github.com/oauth2-proxy/oauth2-proxy/v7/pkg/requests

    pkg/requests/result.go:18:2: method UnmarshalJSON() (*simplejson.Json, error) should have signature UnmarshalJSON([]byte) error pkg/requests/result.go:72:18: method UnmarshalJSON() (*simplejson.Json, error) should have signature UnmarshalJSON([]byte) error 3. <!--- Step 2 ---> 4. <!--- Step 3 ---> 5. <!--- Step 4 --->

    Context

    Your Environment

    • Version used:
    • go 1.1.7 1.18
    opened by joeybdub 0
  • [Question] Cookie Expiration Behaviour

    [Question] Cookie Expiration Behaviour

    Greetings! Sorry if it is wrong place to post a questions. While using cookies as a storage backend:

    1. Does --cookie-expire only affects standard way of cookies expiration time?
    2. Does OAuth2 Proxy stores expiration timestamp in the cookie body itself (besides the standard way)?
    3. Is cookie expiration date signed/checksummed anyhow in the cookie body?

    The questions I'm asking are for understanding whether I can leave 24h expiration time set in the config, take a cookie from my browser and use it in the third-party automation testing service and set the cookie to expire never there? The testing service needs a cookie to bypass OAuth Proxy with no expiration date. But all the rest (users, etc) need the limited timeframe.

    The general question: can I safely change the expiration date on client side without consequences? Thank you.

    opened by dmitriypavlov 0
Releases(v7.2.1)
Owner
OAuth2 Proxy
Independent organization for OAuth2 Proxy project
OAuth2 Proxy
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

Quiq Labs 63 May 8, 2022
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.5k May 4, 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

Paul Zietsman 1 Mar 31, 2022
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 24 Apr 6, 2022
Authelia: an open-source authentication and authorization server providing two-factor authentication

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

Streato 0 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

Paul Greenberg 372 May 15, 2022
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

Miroslav Šedivý 4 Jan 31, 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.

Dinesh Bhattarai 0 Jan 30, 2022
Herbert Fischer 196 Nov 17, 2021
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

Pierre-Luc Simard 5 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

Tv 1 Nov 11, 2021
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

Miroslav Šedivý 4 Jan 31, 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

Sanad Haj Yahya 366 May 14, 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

Mark Bates 3.7k May 16, 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

Layercraft 1 Mar 11, 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

mya 3 Mar 21, 2022
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 30 Apr 29, 2022
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.9k May 6, 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

Hemanth Krishna 8 Apr 25, 2022