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
- GitHub
- Keycloak
- GitLab
- 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>
--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.
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 iehttps://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"
--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.
GitLab Auth Provider
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>"
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. The OpenID Connect Provider (OIDC) can also be used to connect to other Identity Providers such as Okta, an example can be found below.
Dex
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 ofexamples/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.troutTo 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.
Okta
To configure the OIDC provider for Okta, perform the following steps:
- 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
andRefresh Token
. - Leave the rest as default, taking note of the
Client ID
andClient 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
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
andRefresh Token
- Make note of the
Client ID
andClient 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