docs/versioned_docs/version-7.3.x/configuration/auth.md
You will need to register an OAuth application with a Provider (Google, GitHub or another provider), and configure it with Redirect URI(s) for the domain you intend to run oauth2-proxy on.
Valid providers are :
The provider can be selected using the provider configuration value.
Please note that not all providers support all claims. The preferred_username claim is currently only supported by the OpenID Connect provider.
For Google, the registration steps are:
https://internal.yourcompany.comhttps://internal.yourcompany.com/oauth2/callbackIt's recommended to refresh sessions on a short interval (1h) with cookie-refresh setting which validates that the account is still authorized.
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.user.readonly
google-admin-email flag. This email will be impersonated by this client to make calls to the Admin SDK. See the note on the link from step 5 for the reason why.google-group flag. You can pass multiple instances of this flag with different groups
and the user will be checked against all the provided groups.google-service-account-json flag.Note: The user is checked against the group members list on initial authentication and every time the token is refreshed ( about once an hour ).
https://internal.yourcompany.com as Sign-on URL. Click "Create".https://internal.yourcompanycom/oauth2/callback for each host that you want to protect by the oauth2 proxy. Click "Save". --provider=azure
--client-id=<application ID from step 3>
--client-secret=<value from step 6>
--oidc-issuer-url=https://sts.windows.net/{tenant-id}/
Note: When using the Azure Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the redis session storage should resolve this.
--provider=adfs
--client-id=<application ID from step 3>
--client-secret=<value from step 3>
Note: When using the ADFS Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the redis session storage should resolve this.
https://internal.yourcompany.com/oauth2/callbackAuthorization callback URL enter the correct url ie https://internal.yourcompany.com/oauth2/callbackThe GitHub auth provider supports two additional ways to restrict authentication to either organization and optional team level access, or to collaborators of a repository. Restricting by these options is normally accompanied with --email-domain=*
NOTE: When --github-user is set, the specified users are allowed to login even if they do not belong to the specified org and team or collaborators.
To restrict by organization only, include the following flag:
--github-org="": restrict logins to members of this organisation
To restrict within an organization to specific teams, include the following flag in addition to -github-org:
--github-team="": restrict logins to members of any of these teams (slug), separated by a comma
If you would rather restrict access to collaborators of a repository, those users must either have push access to a public repository or any access to a private repository:
--github-repo="": restrict logins to collaborators of this repository formatted as orgname/repo
If you'd like to allow access to users with read only access to a public repository you will need to provide a token for a user that has write access to the repository. The token must be created with at least the public_repo scope:
--github-token="": the token to use when verifying repository collaborators
To allow a user to login with their username even if they do not belong to the specified org and team or collaborators, separated by a comma
--github-user="": allow logins by username, separated by a comma
If you are using GitHub enterprise, make sure you set the following to the appropriate url:
--login-url="http(s)://<enterprise github host>/login/oauth/authorize"
--redeem-url="http(s)://<enterprise github host>/login/oauth/access_token"
--validate-url="http(s)://<enterprise github host>/api/v3"
:::note This is the legacy provider for Keycloak, use Keycloak OIDC Auth Provider if possible. :::
Make sure you set the following to the appropriate url:
--provider=keycloak
--client-id=<client you have created>
--client-secret=<your client's secret>
--login-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/auth"
--redeem-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/token"
--profile-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"
--validate-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"
--keycloak-group=<first_allowed_user_group>
--keycloak-group=<second_allowed_user_group>
For group based authorization, the optional --keycloak-group (legacy) or --allowed-group (global standard)
flags can be used to specify which groups to limit access to.
If these are unset but a groups mapper is set up above in step (3), the provider will still
populate the X-Forwarded-Groups header to your upstream server with the groups data in the
Keycloak userinfo endpoint response.
The group management in keycloak is using a tree. If you create a group named admin in keycloak you should define the 'keycloak-group' value to /admin.
Make sure you set the following to the appropriate url:
--provider=keycloak-oidc
--client-id=<your client's id>
--client-secret=<your client's secret>
--redirect-url=https://myapp.com/oauth2/callback
--oidc-issuer-url=https://<keycloak host>/realms/<your realm>
--allowed-role=<realm role name> // Optional, required realm role
--allowed-role=<client id>:<client role name> // Optional, required client role
This auth provider has been tested against Gitlab version 12.X. Due to Gitlab API changes, it may not work for version prior to 12.X (see 994).
Whether you are using GitLab.com or self-hosting GitLab, follow these steps to add an application. Make sure to enable at least the openid, profile and email scopes, and set the redirect url to your application url e.g. https://myapp.com/oauth2/callback.
If you need projects filtering, add the extra read_api scope to your application.
The following config should be set to ensure that the oauth will work properly. To get a cookie secret follow these steps
--provider="gitlab"
--redirect-url="https://myapp.com/oauth2/callback" // Should be the same as the redirect url for the application in gitlab
--client-id=GITLAB_CLIENT_ID
--client-secret=GITLAB_CLIENT_SECRET
--cookie-secret=COOKIE_SECRET
Restricting by group membership is possible with the following option:
--gitlab-group="mygroup,myothergroup": restrict logins to members of any of these groups (slug), separated by a comma
If you are using self-hosted GitLab, make sure you set the following to the appropriate URL:
--oidc-issuer-url="<your gitlab url>"
If your self-hosted GitLab is on a sub-directory (e.g. domain.tld/gitlab), as opposed to its own sub-domain (e.g. gitlab.domain.tld), you may need to add a redirect from domain.tld/oauth pointing at e.g. domain.tld/gitlab/oauth.
For LinkedIn, the registration steps are:
https://internal.yourcompany.com/oauth2/callbackFor adding an application to the Microsoft Azure AD follow these steps to add an application.
Take note of your TenantId if applicable for your situation. The TenantId can be used to override the default common authorization server with a tenant specific server.
OpenID Connect is a spec for OAUTH 2.0 + identity that is implemented by many major providers and several open source projects.
This provider was originally built against CoreOS Dex and we will use it as an example. The OpenID Connect Provider (OIDC) can also be used to connect to other Identity Providers such as Okta, an example can be found below.
To configure the OIDC provider for Dex, perform the following steps:
Download Dex:
go get github.com/dexidp/dex
See the getting started guide for more details.
Setup oauth2-proxy with the correct provider and using the default ports and callbacks. Add a configuration block to the staticClients section of examples/config-dev.yaml:
- id: oauth2-proxy
redirectURIs:
- 'http://127.0.0.1:4180/oauth2/callback'
name: 'oauth2-proxy'
secret: proxy
Launch Dex: from $GOPATH/github.com/dexidp/dex, run:
bin/dex serve examples/config-dev.yaml
In a second terminal, run the oauth2-proxy with the following args:
-provider oidc
-provider-display-name "My OIDC Provider"
-client-id oauth2-proxy
-client-secret proxy
-redirect-url http://127.0.0.1:4180/oauth2/callback
-oidc-issuer-url http://127.0.0.1:5556/dex
-cookie-secure=false
-cookie-secret=secret
-email-domain kilgore.trout
To serve the current working directory as a web site under the /static endpoint, add:
-upstream file://$PWD/#/static/
Test the setup by visiting http://127.0.0.1:4180 or http://127.0.0.1:4180/static .
See also our local testing environment for a self-contained example using Docker and etcd as storage for Dex.
To configure the OIDC provider for Okta, perform the following steps:
example.oktapreview.comdefault will work.Example App.https://example.corp.com.Authorization Code and Refresh Token.Client ID and Client Secret.Create a configuration file like the following:
provider = "oidc"
redirect_url = "https://example.corp.com/oauth2/callback"
oidc_issuer_url = "https://corp.okta.com/oauth2/abCd1234"
upstreams = [
"https://example.corp.com"
]
email_domains = [
"corp.com"
]
client_id = "XXXXX"
client_secret = "YYYYY"
pass_access_token = true
cookie_secret = "ZZZZZ"
skip_provider_button = true
The oidc_issuer_url is based on URL from your Authorization Server's Issuer field in step 2, or simply https://corp.okta.com .
The client_id and client_secret are configured in the application settings.
Generate a unique cookie_secret to encrypt the cookie.
Then you can start the oauth2-proxy with ./oauth2-proxy --config /etc/example.cfg
Web Application: https://${your-okta-domain}/dev/console/apps/newEveryoneAuthorization Code and Refresh TokenClient ID and Client secret, they are needed in a future step/etc/localhost.cfg
provider = "oidc"
redirect_url = "http://localhost:4180/oauth2/callback"
oidc_issuer_url = "https://$\{your-okta-domain\}/oauth2/default"
upstreams = [
"http://0.0.0.0:8080"
]
email_domains = [
"*"
]
client_id = "XXX"
client_secret = "YYY"
pass_access_token = true
cookie_secret = "ZZZ"
cookie_secure = false
skip_provider_button = true
# Note: use the following for testing within a container
# http_address = "0.0.0.0:4180"
./oauth2-proxy --config /etc/localhost.cfglogin.gov is an OIDC provider for the US Government. If you are a US Government agency, you can contact the login.gov team through the contact information that you can find on https://login.gov/developers/ and work with them to understand how to get login.gov accounts for integration/test and production access.
A developer guide is available here: https://developers.login.gov/, though this proxy handles everything but the data you need to create to register your application in the login.gov dashboard.
As a demo, we will assume that you are running your application that you want to secure locally on http://localhost:3000/, that you will be starting your proxy up on http://localhost:4180/, and that you have an agency integration account for testing.
First, register your application in the dashboard. The important bits are:
Openid connect${LOGINGOV_ISSUER}.openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 3650 -nodes -subj '/C=US/ST=Washington/L=DC/O=GSA/OU=18F/CN=localhost',
The contents of the key.pem shall be referred to as ${OAUTH2_PROXY_JWT_KEY}.http://localhost:4180/http://localhost:4180/oauth2/callback.Now start the proxy up with the following options:
./oauth2-proxy -provider login.gov \
-client-id=${LOGINGOV_ISSUER} \
-redirect-url=http://localhost:4180/oauth2/callback \
-oidc-issuer-url=https://idp.int.identitysandbox.gov/ \
-cookie-secure=false \
-email-domain=gsa.gov \
-upstream=http://localhost:3000/ \
-cookie-secret=somerandomstring12341234567890AB \
-cookie-domain=localhost \
-skip-provider-button=true \
-pubjwk-url=https://idp.int.identitysandbox.gov/api/openid_connect/certs \
-profile-url=https://idp.int.identitysandbox.gov/api/openid_connect/userinfo \
-jwt-key="${OAUTH2_PROXY_JWT_KEY}"
You can also set all these options with environment variables, for use in cloud/docker environments.
One tricky thing that you may encounter is that some cloud environments will pass in environment
variables in a docker env-file, which does not allow multiline variables like a PEM file.
If you encounter this, then you can create a jwt_signing_key.pem file in the top level
directory of the repo which contains the key in PEM format and then do your docker build.
The docker build process will copy that file into your image which you can then access by
setting the OAUTH2_PROXY_JWT_KEY_FILE=/etc/ssl/private/jwt_signing_key.pem
environment variable, or by setting --jwt-key-file=/etc/ssl/private/jwt_signing_key.pem on the commandline.
Once it is running, you should be able to go to http://localhost:4180/ in your browser,
get authenticated by the login.gov integration server, and then get proxied on to your
application running on http://localhost:3000/. In a real deployment, you would secure
your application with a firewall or something so that it was only accessible from the
proxy, and you would use real hostnames everywhere.
Some providers do not support OIDC discovery via their issuer URL, so oauth2-proxy cannot simply grab the authorization, token and jwks URI endpoints from the provider's metadata.
In this case, you can set the --skip-oidc-discovery option, and supply those required endpoints manually:
-provider oidc
-client-id oauth2-proxy
-client-secret proxy
-redirect-url http://127.0.0.1:4180/oauth2/callback
-oidc-issuer-url http://127.0.0.1:5556
-skip-oidc-discovery
-login-url http://127.0.0.1:5556/authorize
-redeem-url http://127.0.0.1:5556/token
-oidc-jwks-url http://127.0.0.1:5556/keys
-cookie-secure=false
-email-domain example.com
The Nextcloud provider allows you to authenticate against users in your Nextcloud instance.
When you are using the Nextcloud provider, you must specify the urls via
configuration, environment variable, or command line argument. Depending
on whether your Nextcloud instance is using pretty urls your urls may be of the
form /index.php/apps/oauth2/* or /apps/oauth2/*.
Refer to the OAuth2
documentation
to setup the client id and client secret. Your "Redirection URI" will be
https://internalapp.yourcompany.com/oauth2/callback.
-provider nextcloud
-client-id <from nextcloud admin>
-client-secret <from nextcloud admin>
-login-url="<your nextcloud url>/index.php/apps/oauth2/authorize"
-redeem-url="<your nextcloud url>/index.php/apps/oauth2/api/v1/token"
-validate-url="<your nextcloud url>/ocs/v2.php/cloud/user?format=json"
Note: in all cases the validate-url will not have the index.php.
https://oauth-proxy/oauth2/callback, substituting oauth2-proxy with the actual hostname that oauth2-proxy is running on. The URL must match oauth2-proxy's configured redirect URL.To use the provider, pass the following options:
--provider=digitalocean
--client-id=<Client ID>
--client-secret=<Client Secret>
Alternatively, set the equivalent options in the config file. The redirect URL defaults to https://<requested host header>/oauth2/callback. If you need to change it, you can use the --redirect-url command-line option.
https://<oauth2-proxy>/oauth2/callback, substituting <oauth2-proxy> with the actual hostname that oauth2-proxy is running on.To use the provider, pass the following options:
--provider=bitbucket
--client-id=<Client ID>
--client-secret=<Client Secret>
The default configuration allows everyone with Bitbucket account to authenticate. To restrict the access to the team members use additional configuration option: --bitbucket-team=<Team name>. To restrict the access to only these users who has access to one selected repository use --bitbucket-repository=<Repository name>.
https://< your gitea host >/user/settings/applicationsRedirect URI enter the correct URL i.e. https://<proxied host>/oauth2/callback --provider="github"
--redirect-url="https://<proxied host>/oauth2/callback"
--provider-display-name="Gitea"
--client-id="< client_id as generated by Gitea >"
--client-secret="< client_secret as generated by Gitea >"
--login-url="https://< your gitea host >/login/oauth/authorize"
--redeem-url="https://< your gitea host >/login/oauth/access_token"
--validate-url="https://< your gitea host >/api/v1"
To authorize by email domain use --email-domain=yourcompany.com. To authorize individual email addresses use --authenticated-emails-file=/path/to/file with one email per line. To authorize all email addresses use --email-domain=*.
Follow the examples in the providers package to define a new
Provider instance. Add a new case to
providers.New() to allow oauth2-proxy to use the
new Provider.