OAuth Provider Configuration

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 :

Google default
Azure
Facebook
GitHub
Keycloak
GitLab
LinkedIn
Microsoft Azure AD
OpenID Connect
login.gov
Nextcloud
DigitalOcean
Bitbucket
Gitea

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.

Google Auth Provider

For Google, the registration steps are:

Create a new project: https://console.developers.google.com/project
Choose the new project from the top right project dropdown (only if another project is selected)
In the project Dashboard center pane, choose "API Manager"
In the left Nav pane, choose "Credentials"
In the center pane, choose "OAuth consent screen" tab. Fill in "Product name shown to users" and hit save.
In the center pane, choose "Credentials" tab.
- Open the "New credentials" drop down
- Choose "OAuth client ID"
- Choose "Web application"
- Application name is freeform, choose something appropriate
- Authorized JavaScript origins is your domain ex: https://internal.yourcompany.com
- Authorized redirect URIs is the location of oauth2/callback ex: https://internal.yourcompany.com/oauth2/callback
- Choose "Create"
Take note of the Client ID and Client Secret

It's recommended to refresh sessions on a short interval (1h) with cookie-refresh setting which validates that the account is still authorized.

Restrict auth to specific Google groups on your domain. (optional)

Create a service account: https://developers.google.com/identity/protocols/OAuth2ServiceAccount and make sure to download the json file.
Make note of the Client ID for a future step.
Under "APIs & Auth", choose APIs.
Click on Admin SDK and then Enable API.
Follow the steps on https://developers.google.com/admin-sdk/directory/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account and give the client id from step 2 the following oauth scopes:

https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.user.readonly

Follow the steps on https://support.google.com/a/answer/60757 to enable Admin API access.
Create or choose an existing administrative email address on the Gmail domain to assign to the 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.
Create or choose an existing email group and set that email to the 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.
Lock down the permissions on the json file downloaded from step 1 so only oauth2-proxy is able to read the file and set the path to the file in the google-service-account-json flag.
Restart oauth2-proxy.

Note: The user is checked against the group members list on initial authentication and every time the token is refreshed ( about once an hour ).

Azure Auth Provider

Add an application: go to https://portal.azure.com, choose "Azure Active Directory" in the left menu, select "App registrations" and then click on "New app registration".
Pick a name and choose "Webapp / API" as application type. Use https://internal.yourcompany.com as Sign-on URL. Click "Create".
On the "Settings" / "Properties" page of the app, pick a logo and select "Multi-tenanted" if you want to allow users from multiple organizations to access your app. Note down the application ID. Click "Save".
On the "Settings" / "Required Permissions" page of the app, click on "Windows Azure Active Directory" and then on "Access the directory as the signed in user". Hit "Save" and then then on "Grant permissions" (you might need another admin to do this).
On the "Settings" / "Reply URLs" page of the app, add https://internal.yourcompanycom/oauth2/callback for each host that you want to protect by the oauth2 proxy. Click "Save".
On the "Settings" / "Keys" page of the app, add a new key and note down the value after hitting "Save".
Configure the proxy with

   --provider=azure
   --client-id=<application ID from step 3>
   --client-secret=<value from step 6>

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.

Facebook Auth Provider

Create a new FB App from https://developers.facebook.com/
Under FB Login, set your Valid OAuth redirect URIs to https://internal.yourcompany.com/oauth2/callback

GitHub Auth Provider

Create a new project: https://github.com/settings/developers
Under Authorization callback URL enter the correct url ie https://internal.yourcompany.com/oauth2/callback

The 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"

Keycloak Auth Provider

Create new client in your Keycloak with Access Type 'confidental' and Valid Redirect URIs 'https://internal.yourcompany.com/oauth2/callback'
Take note of the Secret in the credential tab of the client
Create a mapper with Mapper Type 'Group Membership' and Token Claim Name 'groups'.

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"
-validate-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"
-keycloak-group=<user_group>

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.

GitLab Auth Provider

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.

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

LinkedIn Auth Provider

For LinkedIn, the registration steps are:

Create a new project: https://www.linkedin.com/secure/developer
In the OAuth User Agreement section:
- In default scope, select r_basicprofile and r_emailaddress.
- In "OAuth 2.0 Redirect URLs", enter https://internal.yourcompany.com/oauth2/callback
Fill in the remaining required fields and Save.
Take note of the Consumer Key / API Key and Consumer Secret / Secret Key

Microsoft Azure AD Provider

For 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 Provider

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.

Launch a Dex instance using the getting started guide.
Setup oauth2-proxy with the correct provider and using the default ports and callbacks.
Login with the fixture use in the dex guide and 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
    -cookie-secure=false
    -email-domain example.com

The OpenID Connect Provider (OIDC) can also be used to connect to other Identity Providers such as Okta. To configure the OIDC provider for Okta, perform +the following steps:

Configuring the OIDC Provider with Okta

Log in to Okta using an administrative account. It is suggested you try this in preview first, example.oktapreview.com
(OPTIONAL) If you want to configure authorization scopes and claims to be passed on to multiple applications, +you may wish to configure an authorization server for each application. Otherwise, the provided default will work.

Navigate to Security then select API
Click Add Authorization Server, if this option is not available you may require an additional license for a custom authorization server.
Fill out the Name with something to describe the application you are protecting. e.g. 'Example App'.
For Audience, pick the URL of the application you wish to protect: https://example.corp.com
Fill out a Description
Add any Access Policies you wish to configure to limit application access.
The default settings will work for other options. +See Okta documentation for more information on Authorization Servers

Navigate to Applications then select Add Application.

Select Web for the Platform setting.
Select OpenID Connect and click Create
Pick an Application Name such as Example App.
Set the Login redirect URI to https://example.corp.com.
Under General set the Allowed grant types to Authorization Code and Refresh Token.
Leave the rest as default, taking note of the Client ID and Client Secret.
Under Assignments select the users or groups you wish to access your application.

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 client_secret to encrypt the cookie.

Then you can start the oauth2-proxy with ./oauth2-proxy --config /etc/example.cfg

Configuring the OIDC Provider with Okta - localhost

Signup for developer account: https://developer.okta.com/signup/
Create New Web Application: https://${your-okta-domain}/dev/console/apps/new
Example Application Settings for localhost:
- Name: My Web App
- Base URIs: http://localhost:4180/
- Login redirect URIs: http://localhost:4180/oauth2/callback
- Logout redirect URIs: http://localhost:4180/
- Group assignments: Everyone
- Grant type allowed: Authorization Code and Refresh Token
Make note of the Client ID and Client secret, they are needed in a future step
Make note of the default Authorization Server Issuer URI from: https://${your-okta-domain}/admin/oauth2/as
Example config file /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"
Then you can start the oauth2-proxy with ./oauth2-proxy --config /etc/localhost.cfg

login.gov Provider

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

Identity protocol: make this Openid connect
Issuer: do what they say for OpenID Connect. We will refer to this string as ${LOGINGOV_ISSUER}.
Public key: This is a self-signed certificate in .pem format generated from a 2048 bit RSA private key. +A quick way to do this is 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}.
Return to App URL: Make this be http://localhost:4180/
Redirect URIs: Make this be http://localhost:4180/oauth2/callback.
Attribute Bundle: Make sure that email is selected.

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.

Skip OIDC discovery

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

Nextcloud Provider

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.

DigitalOcean Auth Provider

Create a new OAuth application
- You can fill in the name, homepage, and description however you wish.
- In the "Application callback URL" field, enter: 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.
Note the Client ID and Client Secret.

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.

Bitbucket Auth Provider

Add a new OAuth consumer
- In "Callback URL" use https://<oauth2-proxy>/oauth2/callback, substituting <oauth2-proxy> with the actual hostname that oauth2-proxy is running on.
- In Permissions section select:
  - Account -> Email
  - Team membership -> Read
  - Repositories -> Read
Note the Client ID and Client Secret.

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

Gitea Auth Provider

Create a new application: https://< your gitea host >/user/settings/applications
Under Redirect URI enter the correct URL i.e. https://<proxied host>/oauth2/callback
Note the Client ID and Client Secret.
Pass the following options to the proxy:

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

Email Authentication

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

Adding a new Provider

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.

Overview

oauth2-proxy can be configured via config file, command line options or environment variables.

To generate a strong cookie secret use python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(16)).decode())'

Config File

Every command line argument can be specified in a config file by replacing hyphens (-) with underscores (_). If the argument can be specified multiple times, the config option should be plural (trailing s).

An example oauth2-proxy.cfg config file is in the contrib directory. It can be used by specifying --config=/etc/oauth2-proxy.cfg

Command Line Options

Option	Type	Description	Default
`--acr-values`	string	optional, see docs	`""`
`--approval-prompt`	string	OAuth approval_prompt	`"force"`
`--auth-logging`	bool	Log authentication attempts	true
`--auth-logging-format`	string	Template for authentication log lines	see Logging Configuration
`--authenticated-emails-file`	string	authenticate against emails via file (one per line)
`--azure-tenant`	string	go to a tenant-specific or common (tenant-independent) endpoint.	`"common"`
`--basic-auth-password`	string	the password to set when passing the HTTP Basic Auth header
`--client-id`	string	the OAuth Client ID, e.g. `"123456.apps.googleusercontent.com"`
`--client-secret`	string	the OAuth Client Secret
`--client-secret-file`	string	the file with OAuth Client Secret
`--config`	string	path to config file
`--cookie-domain`	string \| list	Optional cookie domains to force cookies to (e.g. `.yourcompany.com`). The longest domain matching the request's host will be used (or the shortest cookie domain if there is no match).
`--cookie-expire`	duration	expire timeframe for cookie	168h0m0s
`--cookie-httponly`	bool	set HttpOnly cookie flag	true
`--cookie-name`	string	the name of the cookie that the oauth_proxy creates	`"_oauth2_proxy"`
`--cookie-path`	string	an optional cookie path to force cookies to (e.g. `/poc/`)	`"/"`
`--cookie-refresh`	duration	refresh the cookie after this duration; `0` to disable; not supported by all providers [1]
`--cookie-secret`	string	the seed string for secure cookies (optionally base64 encoded)
`--cookie-secure`	bool	set secure (HTTPS only) cookie flag	true
`--cookie-samesite`	string	set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`).	`""`
`--custom-templates-dir`	string	path to custom html templates
`--display-htpasswd-form`	bool	display username / password login form if an htpasswd file is provided	true
`--email-domain`	string \| list	authenticate emails with the specified domain (may be given multiple times). Use `*` to authenticate any email
`--errors-to-info-log`	bool	redirects error-level logging to default log channel instead of stderr
`--extra-jwt-issuers`	string	if `--skip-jwt-bearer-tokens` is set, a list of extra JWT `issuer=audience` (see a token's `iss`, `aud` fields) pairs (where the issuer URL has a `.well-known/openid-configuration` or a `.well-known/jwks.json`)
`--exclude-logging-paths`	string	comma separated list of paths to exclude from logging, e.g. `"/ping,/path2"`	`""` (no paths excluded)
`--flush-interval`	duration	period between flushing response buffers when streaming responses	`"1s"`
`--force-https`	bool	enforce https redirect	`false`
`--banner`	string	custom (html) banner string. Use `"-"` to disable default banner.
`--footer`	string	custom (html) footer string. Use `"-"` to disable default footer.
`--gcp-healthchecks`	bool	will enable `/liveness_check`, `/readiness_check`, and `/` (with the proper user-agent) endpoints that will make it work well with GCP App Engine and GKE Ingresses	false
`--github-org`	string	restrict logins to members of this organisation
`--github-team`	string	restrict logins to members of any of these teams (slug), separated by a comma
`--github-repo`	string	restrict logins to collaborators of this repository formatted as `orgname/repo`
`--github-token`	string	the token to use when verifying repository collaborators (must have push access to the repository)
`--github-user`	string \| list	To allow users to login by username even if they do not belong to the specified org and team or collaborators
`--gitlab-group`	string \| list	restrict logins to members of any of these groups (slug), separated by a comma
`--google-admin-email`	string	the google admin to impersonate for api calls
`--google-group`	string	restrict logins to members of this google group (may be given multiple times).
`--google-service-account-json`	string	the path to the service account json credentials
`--htpasswd-file`	string	additionally authenticate against a htpasswd file. Entries must be created with `htpasswd -B` for bcrypt encryption
`--http-address`	string	`[http://]<addr>:<port>` or `unix://<path>` to listen on for HTTP clients	`"127.0.0.1:4180"`
`--https-address`	string	`<addr>:<port>` to listen on for HTTPS clients	`":443"`
`--logging-compress`	bool	Should rotated log files be compressed using gzip	false
`--logging-filename`	string	File to log requests to, empty for `stdout`	`""` (stdout)
`--logging-local-time`	bool	Use local time in log files and backup filenames instead of UTC	true (local time)
`--logging-max-age`	int	Maximum number of days to retain old log files	7
`--logging-max-backups`	int	Maximum number of old log files to retain; 0 to disable	0
`--logging-max-size`	int	Maximum size in megabytes of the log file before rotation	100
`--jwt-key`	string	private key in PEM format used to sign JWT, so that you can say something like `--jwt-key="${OAUTH2_PROXY_JWT_KEY}"`: required by login.gov
`--jwt-key-file`	string	path to the private key file in PEM format used to sign the JWT so that you can say something like `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem`: required by login.gov
`--login-url`	string	Authentication endpoint
`--insecure-oidc-allow-unverified-email`	bool	don't fail if an email address in an id_token is not verified	false
`--insecure-oidc-skip-issuer-verification`	bool	allow the OIDC issuer URL to differ from the expected (currently required for Azure multi-tenant compatibility)	false
`--oidc-issuer-url`	string	the OpenID Connect issuer URL, e.g. `"https://accounts.google.com"`
`--oidc-jwks-url`	string	OIDC JWKS URI for token verification; required if OIDC discovery is disabled
`--oidc-groups-claim`	string	which claim contains the user groups	`"groups"`
`--pass-access-token`	bool	pass OAuth access_token to upstream via X-Forwarded-Access-Token header. When used with `--set-xauthrequest` this adds the X-Auth-Request-Access-Token header to the response	false
`--pass-authorization-header`	bool	pass OIDC IDToken to upstream via Authorization Bearer header	false
`--pass-basic-auth`	bool	pass HTTP Basic Auth, X-Forwarded-User, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream	true
`--prefer-email-to-user`	bool	Prefer to use the Email address as the Username when passing information to upstream. Will only use Username if Email is unavailable, e.g. htaccess authentication. Used in conjunction with `--pass-basic-auth` and `--pass-user-headers`	false
`--pass-host-header`	bool	pass the request Host Header to upstream	true
`--pass-user-headers`	bool	pass X-Forwarded-User, X-Forwarded-Groups, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream	true
`--profile-url`	string	Profile access endpoint
`--prompt`	string	OIDC prompt; if present, `approval-prompt` is ignored	`""`
`--provider`	string	OAuth provider	google
`--provider-ca-file`	string \| list	Paths to CA certificates that should be used when connecting to the provider. If not specified, the default Go trust sources are used instead.
`--provider-display-name`	string	Override the provider's name with the given string; used for the sign-in page	(depends on provider)
`--ping-path`	string	the ping endpoint that can be used for basic health checks	`"/ping"`
`--ping-user-agent`	string	a User-Agent that can be used for basic health checks	`""` (don't check user agent)
`--proxy-prefix`	string	the url root path that this proxy should be nested under (e.g. /`<oauth2>/sign_in`)	`"/oauth2"`
`--proxy-websockets`	bool	enables WebSocket proxying	true
`--pubjwk-url`	string	JWK pubkey access endpoint: required by login.gov
`--real-client-ip-header`	string	Header used to determine the real IP of the client, requires `--reverse-proxy` to be set (one of: X-Forwarded-For, X-Real-IP, or X-ProxyUser-IP)	X-Real-IP
`--redeem-url`	string	Token redemption endpoint
`--redirect-url`	string	the OAuth Redirect URL, e.g. `"https://internalapp.yourcompany.com/oauth2/callback"`
`--redis-cluster-connection-urls`	string \| list	List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster`
`--redis-connection-url`	string	URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`)
`--redis-password`	string	Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url`
`--redis-sentinel-password`	string	Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password`
`--redis-sentinel-master-name`	string	Redis sentinel master name. Used in conjunction with `--redis-use-sentinel`
`--redis-sentinel-connection-urls`	string \| list	List of Redis sentinel connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-sentinel`
`--redis-use-cluster`	bool	Connect to redis cluster. Must set `--redis-cluster-connection-urls` to use this feature	false
`--redis-use-sentinel`	bool	Connect to redis via sentinels. Must set `--redis-sentinel-master-name` and `--redis-sentinel-connection-urls` to use this feature	false
`--request-logging`	bool	Log requests	true
`--request-logging-format`	string	Template for request log lines	see Logging Configuration
`--resource`	string	The resource that is protected (Azure AD only)
`--reverse-proxy`	bool	are we running behind a reverse proxy, controls whether headers like X-Real-IP are accepted	false
`--scope`	string	OAuth scope specification
`--session-cookie-minimal`	bool	strip OAuth tokens from cookie session stores if they aren't needed (cookie session store only)	false
`--session-store-type`	string	Session data storage backend; redis or cookie	cookie
`--set-xauthrequest`	bool	set X-Auth-Request-User, X-Auth-Request-Groups, X-Auth-Request-Email and X-Auth-Request-Preferred-Username response headers (useful in Nginx auth_request mode). When used with `--pass-access-token`, X-Auth-Request-Access-Token is added to response headers.	false
`--set-authorization-header`	bool	set Authorization Bearer response header (useful in Nginx auth_request mode)	false
`--set-basic-auth`	bool	set HTTP Basic Auth information in response (useful in Nginx auth_request mode)	false
`--signature-key`	string	GAP-Signature request signature key (algorithm:secretkey)
`--silence-ping-logging`	bool	disable logging of requests to ping endpoint	false
`--skip-auth-preflight`	bool	will skip authentication for OPTIONS requests	false
`--skip-auth-regex`	string \| list	(DEPRECATED for `--skip-auth-route`) bypass authentication for requests paths that match (may be given multiple times)
`--skip-auth-route`	string \| list	bypass authentication for requests that match the method & path. Format: method=path_regex OR path_regex alone for all methods
`--skip-auth-strip-headers`	bool	strips `X-Forwarded-*` style authentication headers & `Authorization` header if they would be set by oauth2-proxy for allowlisted requests (`--skip-auth-route`, `--skip-auth-regex`, `--skip-auth-preflight`, `--trusted-ip`)	false
`--skip-jwt-bearer-tokens`	bool	will skip requests that have verified JWT bearer tokens (the token must have `aud` that matches this client id or one of the extras from `extra-jwt-issuers`)	false
`--skip-oidc-discovery`	bool	bypass OIDC endpoint discovery. `--login-url`, `--redeem-url` and `--oidc-jwks-url` must be configured in this case	false
`--skip-provider-button`	bool	will skip sign-in-page to directly reach the next step: oauth/start	false
`--ssl-insecure-skip-verify`	bool	skip validation of certificates presented when using HTTPS providers	false
`--ssl-upstream-insecure-skip-verify`	bool	skip validation of certificates presented when using HTTPS upstreams	false
`--standard-logging`	bool	Log standard runtime information	true
`--standard-logging-format`	string	Template for standard log lines	see Logging Configuration
`--tls-cert-file`	string	path to certificate file
`--tls-key-file`	string	path to private key file
`--upstream`	string \| list	the http url(s) of the upstream endpoint, file:// paths for static files or `static://<status_code>` for static response. Routing is based on the path
`--user-id-claim`	string	which claim contains the user ID	["email"]
`--allowed-group`	string \| list	restrict logins to members of this group (may be given multiple times)
`--validate-url`	string	Access token validation endpoint
`--version`	n/a	print version string
`--whitelist-domain`	string \| list	allowed domains for redirection after authentication. Prefix domain with a `.` to allow subdomains (e.g. `.example.com`) [2]
`--trusted-ip`	string \| list	list of IPs or CIDR ranges to allow to bypass authentication (may be given multiple times). When combined with `--reverse-proxy` and optionally `--real-client-ip-header` this will evaluate the trust of the IP stored in an HTTP header by a reverse proxy rather than the layer-3/4 remote address. WARNING: trusting IPs has inherent security flaws, especially when obtaining the IP address from an HTTP header (reverse-proxy mode). Use this option only if you understand the risks and how to manage them.

[1]: Only these providers support --cookie-refresh: GitLab, Google and OIDC

[2]: When using the whitelist-domain option, any domain prefixed with a . will allow any subdomain of the specified domain as a valid redirect URL. By default, only empty ports are allowed. This translates to allowing the default port of the URL's protocol (80 for HTTP, 443 for HTTPS, etc.) since browsers omit them. To allow only a specific port, add it to the whitelisted domain: example.com:8080. To allow any port, use *: example.com:*.

See below for provider specific options

Upstreams Configuration

oauth2-proxy supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers or serve static files from the file system. HTTP and HTTPS upstreams are configured by providing a URL such as http://127.0.0.1:8080/ for the upstream parameter. This will forward all authenticated requests to the upstream server. If you instead provide http://127.0.0.1:8080/some/path/ then it will only be requests that start with /some/path/ which are forwarded to the upstream.

Static file paths are configured as a file:// URL. file:///var/www/static/ will serve the files from that directory at http://[oauth2-proxy url]/var/www/static/, which may not be what you want. You can provide the path to where the files should be available by adding a fragment to the configured URL. The value of the fragment will then be used to specify which path the files are available at, e.g. file:///var/www/static/#/static/ will make /var/www/static/ available at http://[oauth2-proxy url]/static/.

Multiple upstreams can either be configured by supplying a comma separated list to the --upstream parameter, supplying the parameter multiple times or providing a list in the config file. When multiple upstreams are used routing to them will be based on the path they are set up with.

Environment variables

Every command line argument can be specified as an environment variable by +prefixing it with OAUTH2_PROXY_, capitalising it, and replacing hyphens (-) +with underscores (_). If the argument can be specified multiple times, the +environment variable should be plural (trailing S).

This is particularly useful for storing secrets outside of a configuration file +or the command line.

For example, the --cookie-secret flag becomes OAUTH2_PROXY_COOKIE_SECRET, +and the --email-domain flag becomes OAUTH2_PROXY_EMAIL_DOMAINS.

Logging Configuration

By default, OAuth2 Proxy logs all output to stdout. Logging can be configured to output to a rotating log file using the --logging-filename command.

If logging to a file you can also configure the maximum file size (--logging-max-size), age (--logging-max-age), max backup logs (--logging-max-backups), and if backup logs should be compressed (--logging-compress).

There are three different types of logging: standard, authentication, and HTTP requests. These can each be enabled or disabled with --standard-logging, --auth-logging, and --request-logging.

Each type of logging has its own configurable format and variables. By default these formats are similar to the Apache Combined Log.

Logging of requests to the /ping endpoint (or using --ping-user-agent) can be disabled with --silence-ping-logging reducing log volume. This flag appends the --ping-path to --exclude-logging-paths.

Auth Log Format

Authentication logs are logs which are guaranteed to contain a username or email address of a user attempting to authenticate. These logs are output by default in the below format:

<REMOTE_ADDRESS> - <user@domain.com> [19/Mar/2015:17:20:19 -0400] [<STATUS>] <MESSAGE>

The status block will contain one of the below strings:

AuthSuccess If a user has authenticated successfully by any method
AuthFailure If the user failed to authenticate explicitly
AuthError If there was an unexpected error during authentication

If you require a different format than that, you can configure it with the --auth-logging-format flag. +The default format is configured as follows:

{{.Client}} - {{.Username}} [{{.Timestamp}}] [{{.Status}}] {{.Message}}

Available variables for auth logging:

Variable	Example	Description
Client	74.125.224.72	The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true.
Host	domain.com	The value of the Host header.
Protocol	HTTP/1.0	The request protocol.
RequestMethod	GET	The request method.
Timestamp	19/Mar/2015:17:20:19 -0400	The date and time of the logging event.
UserAgent	-	The full user agent as reported by the requesting client.
Username	username@email.com	The email or username of the auth request.
Status	AuthSuccess	The status of the auth request. See above for details.
Message	Authenticated via OAuth2	The details of the auth attempt.

Request Log Format

HTTP request logs will output by default in the below format:

<REMOTE_ADDRESS> - <user@domain.com> [19/Mar/2015:17:20:19 -0400] <HOST_HEADER> GET <UPSTREAM_HOST> "/path/" HTTP/1.1 "<USER_AGENT>" <RESPONSE_CODE> <RESPONSE_BYTES> <REQUEST_DURATION>

If you require a different format than that, you can configure it with the --request-logging-format flag. +The default format is configured as follows:

{{.Client}} - {{.Username}} [{{.Timestamp}}] {{.Host}} {{.RequestMethod}} {{.Upstream}} {{.RequestURI}} {{.Protocol}} {{.UserAgent}} {{.StatusCode}} {{.ResponseSize}} {{.RequestDuration}}

Available variables for request logging:

Variable	Example	Description
Client	74.125.224.72	The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true.
Host	domain.com	The value of the Host header.
Protocol	HTTP/1.0	The request protocol.
RequestDuration	0.001	The time in seconds that a request took to process.
RequestMethod	GET	The request method.
RequestURI	"/oauth2/auth"	The URI path of the request.
ResponseSize	12	The size in bytes of the response.
StatusCode	200	The HTTP status code of the response.
Timestamp	19/Mar/2015:17:20:19 -0400	The date and time of the logging event.
Upstream	-	The upstream data of the HTTP request.
UserAgent	-	The full user agent as reported by the requesting client.
Username	username@email.com	The email or username of the auth request.

Standard Log Format

All other logging that is not covered by the above two types of logging will be output in this standard logging format. This includes configuration information at startup and errors that occur outside of a session. The default format is below:

[19/Mar/2015:17:20:19 -0400] [main.go:40] <MESSAGE>

If you require a different format than that, you can configure it with the --standard-logging-format flag. The default format is configured as follows:

[{{.Timestamp}}] [{{.File}}] {{.Message}}

Available variables for standard logging:

Variable	Example	Description
Timestamp	19/Mar/2015:17:20:19 -0400	The date and time of the logging event.
File	main.go:40	The file and line number of the logging statement.
Message	HTTP: listening on 127.0.0.1:4180	The details of the log statement.

Configuring for use with the Nginx `auth_request` directive

The Nginx auth_request directive allows Nginx to authenticate requests via the oauth2-proxy's /auth endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example:

server {
  listen 443 ssl;
  server_name ...;
  include ssl/ssl.conf;

+
  location /oauth2/ {
    proxy_pass       http://127.0.0.1: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;
    # or, if you are handling multiple domains:
    # proxy_set_header X-Auth-Request-Redirect $scheme://$host$request_uri;
  }
  location = /oauth2/auth {
    proxy_pass       http://127.0.0.1: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;
  }

+
  location / {
    auth_request /oauth2/auth;
    error_page 401 = /oauth2/sign_in;

+
    # pass information via X-User and X-Email headers to backend,
    # requires running with --set-xauthrequest flag
    auth_request_set $user   $upstream_http_x_auth_request_user;
    auth_request_set $email  $upstream_http_x_auth_request_email;
    proxy_set_header X-User  $user;
    proxy_set_header X-Email $email;

+
    # if you enabled --pass-access-token, this will pass the token to the backend
    auth_request_set $token  $upstream_http_x_auth_request_access_token;
    proxy_set_header X-Access-Token $token;

+
    # if you enabled --cookie-refresh, this is needed for it to work with auth_request
    auth_request_set $auth_cookie $upstream_http_set_cookie;
    add_header Set-Cookie $auth_cookie;

+
    # When using the --set-authorization-header flag, some provider's cookies can exceed the 4kb
    # limit and so the OAuth2 Proxy splits these into multiple parts.
    # Nginx normally only copies the first `Set-Cookie` header from the auth_request to the response,
    # so if your cookies are larger than 4kb, you will need to extract additional cookies manually.
    auth_request_set $auth_cookie_name_upstream_1 $upstream_cookie_auth_cookie_name_1;

+
    # Extract the Cookie attributes from the first Set-Cookie header and append them
    # to the second part ($upstream_cookie_* variables only contain the raw cookie content)
    if ($auth_cookie ~* "(; .*)") {
        set $auth_cookie_name_0 $auth_cookie;
        set $auth_cookie_name_1 "auth_cookie_name_1=$auth_cookie_name_upstream_1$1";
    }

+
    # Send both Set-Cookie headers now if there was a second part
    if ($auth_cookie_name_upstream_1) {
        add_header Set-Cookie $auth_cookie_name_0;
        add_header Set-Cookie $auth_cookie_name_1;
    }

+
    proxy_pass http://backend/;
    # or "root /path/to/site;" or "fastcgi_pass ..." etc
  }
}

When you use ingress-nginx in Kubernetes, you MUST use kubernetes/ingress-nginx (which includes the Lua module) and the following configuration snippet for your Ingress. +Variables set with auth_request_set are not set-able in plain nginx config when the location is processed via proxy_pass and then may only be processed by Lua. +Note that nginxinc/kubernetes-ingress does not include the Lua module.

nginx.ingress.kubernetes.io/auth-response-headers: Authorization
nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$escaped_request_uri
nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth
nginx.ingress.kubernetes.io/configuration-snippet: |
  auth_request_set $name_upstream_1 $upstream_cookie_name_1;

+
  access_by_lua_block {
    if ngx.var.name_upstream_1 ~= "" then
      ngx.header["Set-Cookie"] = "name_1=" .. ngx.var.name_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
    end
  }

It is recommended to use --session-store-type=redis when expecting large sessions/OIDC tokens (e.g. with MS Azure).

You have to substitute name with the actual cookie name you configured via --cookie-name parameter. If you don't set a custom cookie name the variable should be "$upstream_cookie__oauth2_proxy_1" instead of "$upstream_cookie_name_1" and the new cookie-name should be "_oauth2_proxy_1=" instead of "name_1=".

note

If you set up your OAuth2 provider to rotate your client secret, you can use the client-secret-file option to reload the secret when it is updated.

Page Not Found

Google Auth Provider#

Restrict auth to specific Google groups on your domain. (optional)#

Azure Auth Provider#

Facebook Auth Provider#

GitHub Auth Provider#

Keycloak Auth Provider#

GitLab Auth Provider#

LinkedIn Auth Provider#

Microsoft Azure AD Provider#

OpenID Connect Provider#

Configuring the OIDC Provider with Okta#

Configuring the OIDC Provider with Okta - localhost#

login.gov Provider#

Skip OIDC discovery#

Nextcloud Provider#

DigitalOcean Auth Provider#

Bitbucket Auth Provider#

Gitea Auth Provider#

Email Authentication#

Adding a new Provider#

Config File#

Command Line Options#

Upstreams Configuration#

Environment variables#

Logging Configuration#

Auth Log Format#

Request Log Format#

Standard Log Format#

Configuring for use with the Nginx auth_request directive#

note

Cookie Storage#

Redis Storage#

Usage#

Sign out#

note

Architecture#

Google Auth Provider

Restrict auth to specific Google groups on your domain. (optional)

Azure Auth Provider

Facebook Auth Provider

GitHub Auth Provider

Keycloak Auth Provider

GitLab Auth Provider

LinkedIn Auth Provider

Microsoft Azure AD Provider

OpenID Connect Provider

Configuring the OIDC Provider with Okta

Configuring the OIDC Provider with Okta - localhost

login.gov Provider

Skip OIDC discovery

Nextcloud Provider

DigitalOcean Auth Provider

Bitbucket Auth Provider

Gitea Auth Provider

Email Authentication

Adding a new Provider

Config File

Command Line Options

Upstreams Configuration

Environment variables

Logging Configuration

Auth Log Format

Request Log Format

Standard Log Format

Configuring for use with the Nginx `auth_request` directive

Cookie Storage

Redis Storage

Usage

Sign out

Architecture