go/oauth2-proxy
1
0
Fork 0
mirror of https://github.com/oauth2-proxy/oauth2-proxy.git synced 2025-04-23 12:18:50 +02:00
Code Issues Releases Activity

Refactored docs (#2284)

Browse Source 
* Refactored documentation for providers

* Lots of fixes
- Fixed grammar/typos
- Fixed sidebar config
- Enabled additional prism languages

* Removed useless spaces

* Fixed leftover typos

* Fixes for verify-generate

* Updated package-lock.json
This commit is contained in:
Koen van Zuijlen 2023-10-31 20:32:59 +01:00 committed by GitHub
parent a53da415c9
commit 76bc2cf73f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
30 changed files with 1484 additions and 1360 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/docs/configuration/alpha_config.md
View File

@ -23,13 +23,13 @@ When using alpha configuration, your config file will look something like below:
```yaml
upstreams:
- id: ...
...
...: ...
injectRequestHeaders:
- name: ...
...
...: ...
injectResponseHeaders:
- name: ...
...
...: ...
```
Please browse the [reference](#configuration-reference) below for the structure
@ -512,7 +512,7 @@ Requests will be proxied to this upstream if the path matches the request path.
| `path` | _string_ | Path is used to map requests to the upstream server.<br/>The closest match will take precedence and all Paths must be unique.<br/>Path can also take a pattern when used with RewriteTarget.<br/>Path segments can be captured and matched using regular experessions.<br/>Eg:<br/>- `^/foo$`: Match only the explicit path `/foo`<br/>- `^/bar/$`: Match any path prefixed with `/bar/`<br/>- `^/baz/(.*)$`: Match any path prefixed with `/baz` and capture the remaining path for use with RewriteTarget |
| `rewriteTarget` | _string_ | RewriteTarget allows users to rewrite the request path before it is sent to<br/>the upstream server.<br/>Use the Path to capture segments for reuse within the rewrite target.<br/>Eg: With a Path of `^/baz/(.*)`, a RewriteTarget of `/foo/$1` would rewrite<br/>the request `/baz/abc/123` to `/foo/abc/123` before proxying to the<br/>upstream server. |
| `uri` | _string_ | The URI of the upstream server. This may be an HTTP(S) server of a File<br/>based URL. It may include a path, in which case all requests will be served<br/>under that path.<br/>Eg:<br/>- http://localhost:8080<br/>- https://service.localhost<br/>- https://service.localhost/path<br/>- file://host/path<br/>If the URI's path is "/base" and the incoming request was for "/dir",<br/>the upstream request will be for "/base/dir". |
| `insecureSkipTLSVerify` | _bool_ | InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.<br/>This option is insecure and will allow potential Man-In-The-Middle attacks<br/>betweem OAuth2 Proxy and the usptream server.<br/>Defaults to false. |
| `insecureSkipTLSVerify` | _bool_ | InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.<br/>This option is insecure and will allow potential Man-In-The-Middle attacks<br/>between OAuth2 Proxy and the upstream server.<br/>Defaults to false. |
| `static` | _bool_ | Static will make all requests to this upstream have a static response.<br/>The response will have a body of "Authenticated" and a response code<br/>matching StaticCode.<br/>If StaticCode is not set, the response will return a 200 response. |
| `staticCode` | _int_ | StaticCode determines the response code for the Static response.<br/>This option can only be used with Static enabled. |
| `flushInterval` | _[Duration](#duration)_ | FlushInterval is the period between flushing the response buffer when<br/>streaming response from the upstream.<br/>Defaults to 1 second. |
@ -528,5 +528,5 @@ UpstreamConfig is a collection of definitions for upstream servers.
| Field | Type | Description |
| ----- | ---- | ----------- |
| `proxyRawPath` | _bool_ | ProxyRawPath will pass the raw url path to upstream allowing for url's<br/>like: "/%2F/" which would otherwise be redirected to "/" |
| `proxyRawPath` | _bool_ | ProxyRawPath will pass the raw url path to upstream allowing for urls<br/>like: "/%2F/" which would otherwise be redirected to "/" |
| `upstreams` | _[[]Upstream](#upstream)_ | Upstreams represents the configuration for the upstream servers.<br/>Requests will be proxied to this upstream if the path matches the request path. |

6
docs/docs/configuration/alpha_config.md.tmpl
View File

@ -23,13 +23,13 @@ When using alpha configuration, your config file will look something like below:
```yaml
upstreams:
- id: ...
...
...: ...
injectRequestHeaders:
- name: ...
...
...: ...
injectResponseHeaders:
- name: ...
...
...: ...
```
Please browse the [reference](#configuration-reference) below for the structure

692
docs/docs/configuration/auth.md
View File

@ -1,692 +0,0 @@
---
id: oauth_provider
title: 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](#google-auth-provider) _default_
- [Azure](#azure-auth-provider)
- [ADFS](#adfs-auth-provider)
- [Facebook](#facebook-auth-provider)
- [GitHub](#github-auth-provider)
- [Gitea](#gitea-auth-provider)
- [Keycloak](#keycloak-auth-provider)
- [GitLab](#gitlab-auth-provider)
- [LinkedIn](#linkedin-auth-provider)
- [Microsoft Azure AD](#microsoft-azure-ad-provider)
- [OpenID Connect](#openid-connect-provider)
- [login.gov](#logingov-provider)
- [Nextcloud](#nextcloud-provider)
- [DigitalOcean](#digitalocean-auth-provider)
- [Bitbucket](#bitbucket-auth-provider)
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:
1. Create a new project: https://console.developers.google.com/project
2. Choose the new project from the top right project dropdown (only if another project is selected)
3. In the project Dashboard center pane, choose **"APIs & Services"**
4. In the left Nav pane, choose **"Credentials"**
5. In the center pane, choose **"OAuth consent screen"** tab. Fill in **"Product name shown to users"** and hit save.
6. 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"**
7. 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)
1. Create a [service account](https://developers.google.com/identity/protocols/OAuth2ServiceAccount) and download the json
file if you're not using [Application Default Credentials / Workload Identity / Workload Identity Federation (recommended)](#using-application-default-credentials-adc--workload-identity--workload-identity-federation-recommended).
2. Make note of the Client ID for a future step.
3. Under "APIs & Auth", choose APIs.
4. Click on Admin SDK and then Enable API.
5. 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:
##### Using Application Default Credentials (ADC) / Workload Identity / Workload Identity Federation (recommended)
oauth2-proxy can make use of [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials).
When deployed within GCP, this means that it can automatically use the service account attached to the resource. When deployed to GKE, ADC
can be leveraged through a feature called Workload Identity. Follow Google's [guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
to set up Workload Identity.
When deployed outside of GCP, [Workload Identity Federation](https://cloud.google.com/docs/authentication/provide-credentials-adc#wlif) might be an option.
```
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.user.readonly
```
6. Follow the steps on https://support.google.com/a/answer/60757 to enable Admin API access.
7. 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.
8. 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.
9. 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.
10. 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
1. Add an application: go to [https://portal.azure.com](https://portal.azure.com), choose **Azure Active Directory**, select
**App registrations** and then click on **New registration**.
2. Pick a name, check the supported account type(single-tenant, multi-tenant, etc). In the **Redirect URI** section create a new
**Web** platform entry for each app that you want to protect by the oauth2 proxy(e.g.
https://internal.yourcompanycom/oauth2/callback). Click **Register**.
3. Next we need to add group read permissions for the app registration, on the **API Permissions** page of the app, click on
**Add a permission**, select **Microsoft Graph**, then select **Application permissions**, then click on **Group** and select
**Group.Read.All**. Hit **Add permissions** and then on **Grant admin consent** (you might need an admin to do this).
<br/>**IMPORTANT**: Even if this permission is listed with **"Admin consent required=No"** the consent might actually be required, due to AAD policies you won't be able to see. If you get a **"Need admin approval"** during login, most likely this is what you're missing!
4. Next, if you are planning to use v2.0 Azure Auth endpoint, go to the **Manifest** page and set `"accessTokenAcceptedVersion": 2`
in the App registration manifest file.
5. On the **Certificates & secrets** page of the app, add a new client secret and note down the value after hitting **Add**.
6. Configure the proxy with:
- for V1 Azure Auth endpoint (Azure Active Directory Endpoints - https://login.microsoftonline.com/common/oauth2/authorize)
```
--provider=azure
--client-id=<application ID from step 3>
--client-secret=<value from step 5>
--azure-tenant={tenant-id}
--oidc-issuer-url=https://sts.windows.net/{tenant-id}/
```
- for V2 Azure Auth endpoint (Microsoft Identity Platform Endpoints - https://login.microsoftonline.com/common/oauth2/v2.0/authorize)
```
--provider=azure
--client-id=<application ID from step 3>
--client-secret=<value from step 5>
--azure-tenant={tenant-id}
--oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0
```
***Notes***:
- When using v2.0 Azure Auth endpoint (`https://login.microsoftonline.com/{tenant-id}/v2.0`) as `--oidc_issuer_url`, in conjunction
with `--resource` flag, be sure to append `/.default` at the end of the resource name. See
https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details.
- 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](sessions.md#redis-storage)
should resolve this.
### ADFS Auth Provider
1. Open the ADFS administration console on your Windows Server and add a new Application Group
2. Provide a name for the integration, select Server Application from the Standalone applications section and click Next
3. Follow the wizard to get the client-id, client-secret and configure the application credentials
4. Configure the proxy with
```
--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](sessions.md#redis-storage) should resolve this.
### Facebook Auth Provider
1. Create a new FB App from <https://developers.facebook.com/>
2. Under FB Login, set your Valid OAuth redirect URIs to `https://internal.yourcompany.com/oauth2/callback`
### GitHub Auth Provider
1. Create a new project: https://github.com/settings/developers
2. 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](https://github.com/settings/tokens) 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"
### Gitea Auth Provider
1. Create a new application: `https://< your gitea host >/user/settings/applications`
2. Under `Redirect URI` enter the correct URL i.e. `https://<proxied host>/oauth2/callback`
3. Note the Client ID and Client Secret.
4. 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/user/emails"
```
### Keycloak Auth Provider
:::note
This is the legacy provider for Keycloak, use [Keycloak OIDC Auth Provider](#keycloak-oidc-auth-provider) if possible.
:::
1. Create new client in your Keycloak realm with **Access Type** 'confidental' and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'
2. Take note of the Secret in the credential tab of the client
3. 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.
### Keycloak OIDC Auth Provider
```
--provider=keycloak-oidc
--client-id=<your client's id>
--client-secret=<your client's secret>
--redirect-url=https://internal.yourcompany.com/oauth2/callback
--oidc-issuer-url=https://<keycloak host>/realms/<your realm> // For Keycloak versions <17: --oidc-issuer-url=https://<keycloak host>/auth/realms/<your realm>
--email-domain=<yourcompany.com> // Validate email domain for users, see option documentation
--allowed-role=<realm role name> // Optional, required realm role
--allowed-role=<client id>:<client role name> // Optional, required client role
--allowed-group=</group name> // Optional, requires group client scope
--code-challenge-method=S256 // PKCE
```
:::note
Keycloak has updated its admin console and as of version 19.0.0, the new admin console is enabled by default. The legacy admin console has been announced for removal with the release of version 21.0.0.
:::
**Keycloak legacy admin console**
1. Create new client in your Keycloak realm with **Access Type** 'confidential', **Client protocol** 'openid-connect' and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'
2. Take note of the Secret in the credential tab of the client
3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.
4. Create a mapper with **Mapper Type** 'Audience' and **Included Client Audience** and **Included Custom Audience** set to your client name.
**Keycloak new admin console (default as of v19.0.0)**
The following example shows how to create a simple OIDC client using the new Keycloak admin2 console. However, for best practices, it is recommended to consult the Keycloak documentation.
The OIDC client must be configured with an _audience mapper_ to include the client's name in the `aud` claim of the JWT token.
The `aud` claim specifies the intended recipient of the token, and OAuth2 Proxy expects a match against the values of either `--client-id` or `--oidc-extra-audience`.
_In Keycloak, claims are added to JWT tokens through the use of mappers at either the realm level using "client scopes" or through "dedicated" client mappers._
**Creating the client**
1. Create a new OIDC client in your Keycloak realm by navigating to:
**Clients** -> **Create client**
* **Client Type** 'OpenID Connect'
* **Client ID** `<your client's id>`, please complete the remaining fields as appropriate and click **Next**.
* **Client authentication** 'On'
* **Authentication flow**
* **Standard flow** 'selected'
* **Direct access grants** 'deselect'
* _Save the configuration._
* **Settings / Access settings**:
* **Valid redirect URIs** `https://internal.yourcompany.com/oauth2/callback`
* _Save the configuration._
* Under the **Credentials** tab you will now be able to locate `<your client's secret>`.
2. Configure a dedicated *audience mapper* for your client by navigating to **Clients** -> **<your client's id>** -> **Client scopes**.
* Access the dedicated mappers pane by clicking **<your client's id>-dedicated**, located under *Assigned client scope*.
_(It should have a description of "Dedicated scope and mappers for this client")_
* Click **Configure a new mapper** and select **Audience**
* **Name** 'aud-mapper-<your client's id>'
* **Included Client Audience** select `<your client's id>` from the dropdown.
* _OAuth2 proxy can be set up to pass both the access and ID JWT tokens to your upstream services.
If you require additional audience entries, you can use the **Included Custom Audience** field in addition to the "Included Client Audience" dropdown. Note that the "aud" claim of a JWT token should be limited and only specify its intended recipients._
* **Add to ID token** 'On'
* **Add to access token** 'On' - [#1916](https://github.com/oauth2-proxy/oauth2-proxy/pull/1916)
* _Save the configuration._
* Any subsequent dedicated client mappers can be defined by clicking **Dedicated scopes** -> **Add mapper** -> **By configuration** -> *Select mapper*
You should now be able to create a test user in Keycloak and get access to the OAuth2 Proxy instance, make sure to set an email address matching `<yourcompany.com>` and select _Email verified_.
**Authorization**
_OAuth2 Proxy will perform authorization by requiring a valid user, this authorization can be extended to take into account a user's membership in Keycloak `groups`, `realm roles`, and `client roles` using the keycloak-oidc provider options
`--allowed-role` or `--allowed-group`_
**Roles**
_A standard Keycloak installation comes with the required mappers for **realm roles** and **client roles** through the pre-defined client scope "roles".
This ensures that any roles assigned to a user are included in the `JWT` tokens when using an OIDC client that has the "Full scope allowed" feature activated, the feature is enabled by default._
_Creating a realm role_
* Navigate to **Realm roles** -> **Create role**
* **Role name**, *`<realm role name>`* -> **save**
_Creating a client role_
* Navigate to **Clients** -> `<your client's id>` -> **Roles** -> **Create role**
* **Role name**, *`<client role name>`* -> **save**
_Assign a role to a user_
**Users** -> _Username_ -> **Role mapping** -> **Assign role** -> _filter by roles or clients and select_ -> **Assign**.
Keycloak "realm roles" can be authorized using the `--allowed-role=<realm role name>` option, while "client roles" can be evaluated using `--allowed-role=<your client's id>:<client role name>`.
You may limit the _realm roles_ included in the JWT tokens for any given client by navigating to:
**Clients** -> `<your client's id>` -> **Client scopes** -> _<your client's id>-dedicated_ -> **Scope**
Disabling **Full scope allowed** activates the **Assign role** option, allowing you to select which roles, if assigned to a user, will be included in the user's JWT tokens. This can be useful when a user has many associated roles, and you want to reduce the size and impact of the JWT token.
**Groups**
You may also do authorization on group memberships by using the OAuth2 Proxy option `--allowed-group`.
We will only do a brief description of creating the required _client scope_ **groups** and refer you to read the Keycloak documentation.
To summarize, the steps required to authorize Keycloak group membership with OAuth2 Proxy are as follows:
* Create a new Client Scope with the name **groups** in Keycloak.
* Include a mapper of type **Group Membership**.
* Set the "Token Claim Name" to **groups** or customize by matching it to the `--oidc-groups-claim` option of OAuth2 Proxy.
* If the "Full group path" option is selected, you need to include a "/" separator in the group names defined in the `--allowed-group` option of OAuth2 Proxy. Example: "/groupname" or "/groupname/childgroup".
After creating the _Client Scope_ named _groups_ you will need to attach it to your client.
**Clients** -> `<your client's id>` -> **Client scopes** -> **Add client scope** -> Select **groups** and choose Optional and you should now have a client that maps group memberships into the JWT tokens so that Oauth2 Proxy may evaluate them.
Create a group by navigating to **Groups** -> **Create group** and _add_ your test user as a member.
The OAuth2 Proxy option `--allowed-group=/groupname` will now allow you to filter on group membership
Keycloak also has the option of attaching roles to groups, please refer to the Keycloak documentation for more information.
**Tip**
To check if roles or groups are added to JWT tokens, you can preview a users token in the Keycloak console by following these steps:
**Clients** -> `<your client's id>` -> **Client scopes** -> **Evaluate**.
Select a _realm user_ and optional _scope parameters_ such as groups, and generate the JSON representation of an access or id token to examine its contents.
### 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](https://github.com/oauth2-proxy/oauth2-proxy/issues/994)).
Whether you are using GitLab.com or self-hosting GitLab, follow [these steps to add an application](https://docs.gitlab.com/ce/integration/oauth_provider.html). 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](./overview.md#generating-a-cookie-secret)
```
--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.
### LinkedIn Auth Provider
For LinkedIn, the registration steps are:
1. Create a new project: https://www.linkedin.com/secure/developer
2. 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`
3. Fill in the remaining required fields and Save.
4. 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](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app).
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:
1. Download Dex:
```
go get github.com/dexidp/dex
```
See the [getting started guide](https://dexidp.io/docs/getting-started/) for more details.
2. 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
```
3. Launch Dex: from `$GOPATH/github.com/dexidp/dex`, run:
```
bin/dex serve examples/config-dev.yaml
```
4. 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/
```
5. 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](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/local-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:
1. Log in to Okta using an administrative account. It is suggested you try this in preview first, `example.oktapreview.com`
2. (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](https://developer.okta.com/docs/guides/customize-authz-server/overview/)
3. 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.
4. 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`
#### Okta - localhost
1. Signup for developer account: https://developer.okta.com/signup/
2. Create New `Web` Application: https://${your-okta-domain}/dev/console/apps/new
3. 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`
4. Make note of the `Client ID` and `Client secret`, they are needed in a future step
5. Make note of the **default** Authorization Server Issuer URI from: https://${your-okta-domain}/admin/oauth2/as
6. 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"
```
7. 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](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/oauth2.html)
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
1. [Create a new OAuth application](https://cloud.digitalocean.com/account/api/applications)
* 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.
2. 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
1. [Add a new OAuth consumer](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html)
* 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
2. 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>`.
## 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](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/) to define a new
`Provider` instance. Add a new `case` to
[`providers.New()`](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/providers.go) to allow `oauth2-proxy` to use the
new `Provider`.

219
docs/docs/configuration/overview.md
View File

@ -12,48 +12,40 @@ To generate a strong cookie secret use one of the below commands:
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs
defaultValue="python"
values={[
{label: 'Python', value: 'python'},
{label: 'Bash', value: 'bash'},
{label: 'OpenSSL', value: 'openssl'},
{label: 'PowerShell', value: 'powershell'},
{label: 'Terraform', value: 'terraform'},
]}>
<TabItem value="python">
<Tabs defaultValue="python">
<TabItem value="python" label="Python">
```shell
python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())'
```
</TabItem>
<TabItem value="bash">
<TabItem value="bash" label="Bash">
```shell
dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_'; echo
dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_' ; echo
```
</TabItem>
<TabItem value="openssl">
<TabItem value="openssl" label="OpenSSL">
```shell
openssl rand -base64 32 | tr -- '+/' '-_'
```
</TabItem>
<TabItem value="powershell">
<TabItem value="powershell" label="PowerShell">
```shell
```powershell
# Add System.Web assembly to session, just in case
Add-Type -AssemblyName System.Web
[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes([System.Web.Security.Membership]::GeneratePassword(32,4))).Replace("+","-").Replace("/","_")
```
</TabItem>
<TabItem value="terraform">
<TabItem value="terraform" label="Terraform">
```shell
```hcl
# Valid 32 Byte Base64 URL encoding set that will decode to 24 []byte AES-192 secret
resource "random_password" "cookie_secret" {
length = 32
@ -72,36 +64,36 @@ An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/
### Command Line Options
| Option | Type | Description | Default |
| ------ | ---- | ----------- |------------------------------------------------------------------|
| `--acr-values` | string | optional, see [docs](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html#acrValues) | `""` |
| `--api-route` | string \| list | return HTTP 401 instead of redirecting to authentication server if token is not valid. Format: path_regex | |
| `--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](#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 | |
| `--code-challenge-method` | string | use PKCE code challenges with the specified method. Either 'plain' or 'S256' (recommended) | |
| `--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. If set to 0, cookie becomes a session-cookie which will expire when the browser is closed. | 168h0m0s |
| `--cookie-httponly` | bool | set HttpOnly cookie flag | true |
| `--cookie-name` | string | the name of the cookie that the oauth_proxy creates. Should be changed to use a [cookie prefix](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes) (`__Host-` or `__Secure-`) if `--cookie-secure` is set. | `"_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&nbsp;\[[1](#footnote1)\] | |
| `--cookie-secret` | string | the seed string for secure cookies (optionally base64 encoded) | |
| `--cookie-secure` | bool | set [secure (HTTPS only) cookie flag](https://owasp.org/www-community/controls/SecureFlag) | true |
| `--cookie-samesite` | string | set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). | `""` |
| `--cookie-csrf-per-request` | bool | Enable having different CSRF cookies per request, making it possible to have parallel requests. | false |
| `--cookie-csrf-expire` | duration | expire timeframe for CSRF cookie | 15m |
| `--custom-templates-dir` | string | path to custom html templates | |
| Option | Type | Description | Default |
| ------ | ---- | ----------- | ------- |
| `--acr-values` | string | optional, see [docs](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html#acrValues) | `""` |
| `--api-route` | string \| list | return HTTP 401 instead of redirecting to authentication server if token is not valid. Format: path_regex | |
| `--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](#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 | |
| `--code-challenge-method` | string | use PKCE code challenges with the specified method. Either 'plain' or 'S256' (recommended) | |
| `--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. If set to 0, cookie becomes a session-cookie which will expire when the browser is closed. | 168h0m0s |
| `--cookie-httponly` | bool | set HttpOnly cookie flag | true |
| `--cookie-name` | string | the name of the cookie that the oauth_proxy creates. Should be changed to use a [cookie prefix](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes) (`__Host-` or `__Secure-`) if `--cookie-secure` is set. | `"_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&nbsp;\[[1](#footnote1)\] | |
| `--cookie-secret` | string | the seed string for secure cookies (optionally base64 encoded) | |
| `--cookie-secure` | bool | set [secure (HTTPS only) cookie flag](https://owasp.org/www-community/controls/SecureFlag) | true |
| `--cookie-samesite` | string | set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). | `""` |
| `--cookie-csrf-per-request` | bool | Enable having different CSRF cookies per request, making it possible to have parallel requests. | false |
| `--cookie-csrf-expire` | duration | expire timeframe for CSRF cookie | 15m |
| `--custom-templates-dir` | string | path to custom html templates | |
| `--custom-sign-in-logo` | string | path or a URL to an custom image for the sign_in page logo. Use `"-"` to disable default logo. |
| `--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 | |
| `--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 | false |
| `--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-path` | string | comma separated list of paths to exclude from logging, e.g. `"/ping,/path2"` |`""` (no paths excluded) |
@ -121,7 +113,7 @@ An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/
| `--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 | |
| `--google-use-application-default-credentials` | bool | use application default credentials instead of service account json (i.e. GKE Workload Identity) | |
| `--google-target-principal` | bool | the targetprincipal to impersonate when using ADC | defaults to the service account configured for ADC |
| `--google-target-principal` | bool | the target principal to impersonate when using ADC | defaults to the service account configured for ADC |
| `--htpasswd-file` | string | additionally authenticate against a htpasswd file. Entries must be created with `htpasswd -B` for bcrypt encryption | |
| `--htpasswd-user-group` | string \| list | the groups to be set on sessions for htpasswd users | |
| `--http-address` | string | `[http://]<addr>:<port>` or `unix://<path>` to listen on for HTTP clients. Square brackets are required for ipv6 address, e.g. `http://[::1]:4180` | `"127.0.0.1:4180"` |
@ -130,7 +122,7 @@ An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/
| `--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-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 | |
@ -153,71 +145,70 @@ An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/
| `--profile-url` | string | Profile access endpoint | |
| `--prompt` | string | [OIDC prompt](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest); 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-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. |
| `--use-system-trust-store` | bool | Determines if `provider-ca-file` files and the system trust store are used. If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. | false |
| `--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) |
| `--ready-path` | string | the ready endpoint that can be used for deep health checks | `"/ready"` |
| `--metrics-address` | string | the address prometheus metrics will be scraped from | `""` |
| `--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"` | |
| `--relative-redirect-url` | bool | allow relative OAuth Redirect URL.` | |
| `--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-insecure-skip-tls-verify` | bool | skip TLS verification when connecting to Redis | false |
| `--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 |
| `--redis-connection-idle-timeout` | int | Redis connection idle timeout seconds. If Redis [timeout](https://redis.io/docs/reference/clients/#client-timeouts) option is set to non-zero, the `--redis-connection-idle-timeout` must be less than Redis timeout option. Exmpale: if either redis.conf includes `timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14` | 0 |
| `--request-id-header` | string | Request header to use as the request ID in logging | X-Request-Id |
| `--request-logging` | bool | Log requests | true |
| `--request-logging-format` | string | Template for request log lines | see [Logging Configuration](#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 and allows X-Forwarded-{Proto,Host,Uri} headers to be used on redirect selection | 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](sessions.md); 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 |
| `--show-debug-on-error` | bool | show detailed error information on error pages (WARNING: this may contain sensitive information - do not use in production) | false |
| `--signature-key` | string | GAP-Signature request signature key (algorithm:secretkey) | |
| `--silence-ping-logging` | bool | disable logging of requests to ping & ready endpoints | 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 method!=path_regex. For all methods: path_regex OR !=path_regex | |
| `--skip-auth-strip-headers` | bool | strips `X-Forwarded-*` style authentication headers & `Authorization` header if they would be set by oauth2-proxy | true |
| `--skip-jwt-bearer-tokens` | bool | will skip requests that have verified JWT bearer tokens (the token must have [`aud`](https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields) 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](#logging-configuration) |
| `--tls-cert-file` | string | path to certificate file | |
| `--tls-cipher-suite` | string \| list | Restricts TLS cipher suites used by server to those listed (e.g. TLS_RSA_WITH_RC4_128_SHA) (may be given multiple times). If not specified, the default Go safe cipher list is used. List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). | |
| `--tls-key-file` | string | path to private key file | |
| `--tls-min-version` | string | minimum TLS version that is acceptable, either `"TLS1.2"` or `"TLS1.3"` | `"TLS1.2"` |
| `--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 | |
| `--upstream-timeout` | duration | maximum amount of time the server will wait for a response from the upstream | 30s |
| `--allowed-group` | string \| list | restrict logins to members of this group (may be given multiple times) | |
| `--allowed-role` | string \| list | restrict logins to users with this role (may be given multiple times). Only works with the keycloak-oidc provider. | |
| `--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 `.` or a `*.` to allow subdomains (e.g. `.example.com`, `*.example.com`)&nbsp;\[[2](#footnote2)\] | |
| `--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. | |
| `--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) |
| `--ready-path` | string | the ready endpoint that can be used for deep health checks | `"/ready"` |
| `--metrics-address` | string | the address prometheus metrics will be scraped from | `""` |
| `--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"` | |
| `--relative-redirect-url` | bool | allow relative OAuth Redirect URL.` | |
| `--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-insecure-skip-tls-verify` | bool | skip TLS verification when connecting to Redis | false |
| `--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 |
| `--redis-connection-idle-timeout` | int | Redis connection idle timeout seconds. If Redis [timeout](https://redis.io/docs/reference/clients/#client-timeouts) option is set to non-zero, the `--redis-connection-idle-timeout` must be less than Redis timeout option. Example: if either redis.conf includes `timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14` | 0 |
| `--request-id-header` | string | Request header to use as the request ID in logging | X-Request-Id |
| `--request-logging` | bool | Log requests | true |
| `--request-logging-format` | string | Template for request log lines | see [Logging Configuration](#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 and allows X-Forwarded-{Proto,Host,Uri} headers to be used on redirect selection | 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](sessions.md); 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 |
| `--show-debug-on-error` | bool | show detailed error information on error pages (WARNING: this may contain sensitive information - do not use in production) | false |
| `--signature-key` | string | GAP-Signature request signature key (algorithm:secretkey) | |
| `--silence-ping-logging` | bool | disable logging of requests to ping & ready endpoints | 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 method!=path_regex. For all methods: path_regex OR !=path_regex | |
| `--skip-auth-strip-headers` | bool | strips `X-Forwarded-*` style authentication headers & `Authorization` header if they would be set by oauth2-proxy | true |
| `--skip-jwt-bearer-tokens` | bool | will skip requests that have verified JWT bearer tokens (the token must have [`aud`](https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields) 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](#logging-configuration) |
| `--tls-cert-file` | string | path to certificate file | |
| `--tls-cipher-suite` | string \| list | Restricts TLS cipher suites used by server to those listed (e.g. TLS_RSA_WITH_RC4_128_SHA) (may be given multiple times). If not specified, the default Go safe cipher list is used. List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). | |
| `--tls-key-file` | string | path to private key file | |
| `--tls-min-version` | string | minimum TLS version that is acceptable, either `"TLS1.2"` or `"TLS1.3"` | `"TLS1.2"` |
| `--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 | |
| `--upstream-timeout` | duration | maximum amount of time the server will wait for a response from the upstream | 30s |
| `--allowed-group` | string \| list | restrict logins to members of this group (may be given multiple times) | |
| `--allowed-role` | string \| list | restrict logins to users with this role (may be given multiple times). Only works with the keycloak-oidc provider. | |
| `--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 `.` or a `*.` to allow subdomains (e.g. `.example.com`, `*.example.com`)&nbsp;\[[2](#footnote2)\] | |
| `--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. | |
\[<a name="footnote1">1</a>\]: Only these providers support `--cookie-refresh`: GitLab, Google and OIDC
\[<a name="footnote2">2</a>\]: When using the `whitelist-domain` option, any domain prefixed with a `.` or 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:*`.
> ###### 1. Only these providers support `--cookie-refresh`: GitLab, Google and OIDC {#footnote1}
> ###### 2. When using the `whitelist-domain` option, any domain prefixed with a `.` or 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 URLs 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:*`. {#footnote2}
See below for provider specific options
@ -240,7 +231,7 @@ 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
This is particularly useful for storing secrets outside a configuration file
or the command line.
For example, the `--cookie-secret` flag becomes `OAUTH2_PROXY_COOKIE_SECRET`,
@ -254,7 +245,7 @@ If logging to a file you can also configure the maximum file size (`--logging-ma
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.
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`) and the `/ready` endpoint can be disabled with `--silence-ping-logging` reducing log volume.

19
docs/docs/configuration/providers/adfs.md Normal file
View File

@ -0,0 +1,19 @@
---
id: adfs
title: ADFS
---
1. Open the ADFS administration console on your Windows Server and add a new Application Group
2. Provide a name for the integration, select Server Application from the Standalone applications section and click Next
3. Follow the wizard to get the client-id, client-secret and configure the application credentials
4. Configure the proxy with
```
--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](../sessions.md#redis-storage) should resolve this.

46
docs/docs/configuration/providers/azure.md Normal file
View File

@ -0,0 +1,46 @@
---
id: azure
title: Azure
---
1. Add an application: go to [https://portal.azure.com](https://portal.azure.com), choose **Azure Active Directory**, select
**App registrations** and then click on **New registration**.
2. Pick a name, check the supported account type(single-tenant, multi-tenant, etc). In the **Redirect URI** section create a new
**Web** platform entry for each app that you want to protect by the oauth2 proxy(e.g.
https://internal.yourcompanycom/oauth2/callback). Click **Register**.
3. Next we need to add group read permissions for the app registration, on the **API Permissions** page of the app, click on
**Add a permission**, select **Microsoft Graph**, then select **Application permissions**, then click on **Group** and select
**Group.Read.All**. Hit **Add permissions** and then on **Grant admin consent** (you might need an admin to do this).
<br/>**IMPORTANT**: Even if this permission is listed with **"Admin consent required=No"** the consent might actually
be required, due to AAD policies you won't be able to see. If you get a **"Need admin approval"** during login,
most likely this is what you're missing!
4. Next, if you are planning to use v2.0 Azure Auth endpoint, go to the **Manifest** page and set `"accessTokenAcceptedVersion": 2`
in the App registration manifest file.
5. On the **Certificates & secrets** page of the app, add a new client secret and note down the value after hitting **Add**.
6. Configure the proxy with:
- for V1 Azure Auth endpoint (Azure Active Directory Endpoints - https://login.microsoftonline.com/common/oauth2/authorize)
```
--provider=azure
--client-id=<application ID from step 3>
--client-secret=<value from step 5>
--azure-tenant={tenant-id}
--oidc-issuer-url=https://sts.windows.net/{tenant-id}/
```
- for V2 Azure Auth endpoint (Microsoft Identity Platform Endpoints - https://login.microsoftonline.com/common/oauth2/v2.0/authorize)
```
--provider=azure
--client-id=<application ID from step 3>
--client-secret=<value from step 5>
--azure-tenant={tenant-id}
--oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0
```
***Notes***:
- When using v2.0 Azure Auth endpoint (`https://login.microsoftonline.com/{tenant-id}/v2.0`) as `--oidc_issuer_url`, in conjunction
with `--resource` flag, be sure to append `/.default` at the end of the resource name. See
https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details.
- 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](../sessions.md#redis-storage) should resolve this.

9
docs/docs/configuration/providers/azure_ad.md Normal file
View File

@ -0,0 +1,9 @@
---
id: azure_ad
title: Microsoft Azure AD
---
For adding an application to the Microsoft Azure AD follow [these steps to add an application](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app).
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.

25
docs/docs/configuration/providers/bitbucket.md Normal file
View File

@ -0,0 +1,25 @@
---
id: bitbucket
title: BitBucket
---
1. [Add a new OAuth consumer](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html)
* 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
2. 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 have access to one selected repository use `--bitbucket-repository=<Repository name>`.

21
docs/docs/configuration/providers/digitalocean.md Normal file
View File

@ -0,0 +1,21 @@
---
id: digitalocean
title: DigitalOcean
---
1. [Create a new OAuth application](https://cloud.digitalocean.com/account/api/applications)
* 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.
2. 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.

7
docs/docs/configuration/providers/facebook.md Normal file
View File

@ -0,0 +1,7 @@
---
id: facebook
title: Facebook
---
1. Create a new FB App from <https://developers.facebook.com/>
2. Under FB Login, set your Valid OAuth redirect URIs to `https://internal.yourcompany.com/oauth2/callback`

20
docs/docs/configuration/providers/gitea.md Normal file
View File

@ -0,0 +1,20 @@
---
id: gitea
title: Gitea
---
1. Create a new application: `https://< your gitea host >/user/settings/applications`
2. Under `Redirect URI` enter the correct URL i.e. `https://<proxied host>/oauth2/callback`
3. Note the Client ID and Client Secret.
4. 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/user/emails"
```

43
docs/docs/configuration/providers/github.md Normal file
View File

@ -0,0 +1,43 @@
---
id: github
title: GitHub
---
1. Create a new project: https://github.com/settings/developers
2. 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 log in 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](https://github.com/settings/tokens) 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 log in 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"

36
docs/docs/configuration/providers/gitlab.md Normal file
View File

@ -0,0 +1,36 @@
---
id: gitlab
title: GitLab
---
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](https://github.com/oauth2-proxy/oauth2-proxy/issues/994)).
Whether you are using GitLab.com or self-hosting GitLab, follow
[these steps to add an application](https://docs.gitlab.com/ce/integration/oauth_provider.html). 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](../overview.md#generating-a-cookie-secret)
```
--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 subdirectory (e.g. domain.tld/gitlab), as opposed to its own subdomain
(e.g. gitlab.domain.tld), you may need to add a redirect from domain.tld/oauth pointing at e.g. domain.tld/gitlab/oauth.

63
docs/docs/configuration/providers/google.md Normal file
View File

@ -0,0 +1,63 @@
---
id: google
title: Google (default)
---
For Google, the registration steps are:
1. Create a new project: https://console.developers.google.com/project
2. Choose the new project from the top right project dropdown (only if another project is selected)
3. In the project Dashboard center pane, choose **"APIs & Services"**
4. In the left Nav pane, choose **"Credentials"**
5. In the center pane, choose **"OAuth consent screen"** tab. Fill in **"Product name shown to users"** and hit save.
6. 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"**
7. 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)
1. Create a [service account](https://developers.google.com/identity/protocols/OAuth2ServiceAccount) and configure it
to use [Application Default Credentials / Workload Identity / Workload Identity Federation (recommended)](#using-application-default-credentials-adc--workload-identity--workload-identity-federation-recommended) or,
alternatively download the JSON.
2. Make note of the Client ID for a future step.
3. Under "APIs & Auth", choose APIs.
4. Click on Admin SDK and then Enable API.
5. 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
```
6. Follow the steps on https://support.google.com/a/answer/60757 to enable Admin API access.
7. 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.
8. 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.
(Only if using a JSON file (see step 1))
9. 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.
10. 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 ).
##### Using Application Default Credentials (ADC) / Workload Identity / Workload Identity Federation (recommended)
oauth2-proxy can make use of [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials).
When deployed within GCP, this means that it can automatically use the service account attached to the resource. When deployed to GKE, ADC
can be leveraged through a feature called Workload Identity. Follow Google's [guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
to set up Workload Identity.
When deployed outside of GCP, [Workload Identity Federation](https://cloud.google.com/docs/authentication/provide-credentials-adc#wlif) might be an option.

42
docs/docs/configuration/providers/index.md Normal file
View File

@ -0,0 +1,42 @@
---
id: index
title: 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](google.md) _default_
- [Azure](azure.md)
- [ADFS](adfs.md)
- [Facebook](facebook.md)
- [GitHub](github.md)
- [Gitea](gitea.md)
- [Keycloak](keycloak.md)/[Keycloak OIDC](keycloak_oidc.md)
- [GitLab](gitlab.md)
- [LinkedIn](linkedin.md)
- [Microsoft Azure AD](azure_ad.md)
- [OpenID Connect](openid_connect.md)
- [login.gov](login_gov.md)
- [Nextcloud](nextcloud.md)
- [DigitalOcean](digitalocean.md)
- [Bitbucket](bitbucket.md)
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.
## Email Authentication
To authorize a specific 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](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/) to define a new
`Provider` instance. Add a new `case` to
[`providers.New()`](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/providers.go) to allow `oauth2-proxy` to use the
new `Provider`.

36
docs/docs/configuration/providers/keycloak.md Normal file
View File

@ -0,0 +1,36 @@
---
id: keycloak
title: Keycloak
---
:::note
This is the legacy provider for Keycloak, use [Keycloak OIDC Auth Provider](keycloak_oidc.md) if possible.
:::
1. Create new client in your Keycloak realm with **Access Type** 'confidential' and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'
2. Take note of the Secret in the credential tab of the client
3. 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.

143
docs/docs/configuration/providers/keycloak_oidc.md Normal file
View File

@ -0,0 +1,143 @@
---
id: keycloak_oidc
title: Keycloak OIDC
---
```
--provider=keycloak-oidc
--client-id=<your client's id>
--client-secret=<your client's secret>
--redirect-url=https://internal.yourcompany.com/oauth2/callback
--oidc-issuer-url=https://<keycloak host>/realms/<your realm> // For Keycloak versions <17: --oidc-issuer-url=https://<keycloak host>/auth/realms/<your realm>
--email-domain=<yourcompany.com> // Validate email domain for users, see option documentation
--allowed-role=<realm role name> // Optional, required realm role
--allowed-role=<client id>:<client role name> // Optional, required client role
--allowed-group=</group name> // Optional, requires group client scope
--code-challenge-method=S256 // PKCE
```
:::note
Keycloak has updated its admin console and as of version 19.0.0, the new admin console is enabled by default. The
legacy admin console has been announced for removal with the release of version 21.0.0.
:::
**Keycloak legacy admin console**
1. Create new client in your Keycloak realm with **Access Type** 'confidential', **Client protocol** 'openid-connect'
and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'
2. Take note of the Secret in the credential tab of the client
3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.
4. Create a mapper with **Mapper Type** 'Audience' and **Included Client Audience** and **Included Custom Audience** set
to your client name.
**Keycloak new admin console (default as of v19.0.0)**
The following example shows how to create a simple OIDC client using the new Keycloak admin2 console. However, for best
practices, it is recommended to consult the Keycloak documentation.
The OIDC client must be configured with an _audience mapper_ to include the client's name in the `aud` claim of the JWT token.
The `aud` claim specifies the intended recipient of the token, and OAuth2 Proxy expects a match against the values of
either `--client-id` or `--oidc-extra-audience`.
_In Keycloak, claims are added to JWT tokens through the use of mappers at either the realm level using "client scopes" or
through "dedicated" client mappers._
**Creating the client**
1. Create a new OIDC client in your Keycloak realm by navigating to:
**Clients** -> **Create client**
* **Client Type** 'OpenID Connect'
* **Client ID** `<your client's id>`, please complete the remaining fields as appropriate and click **Next**.
* **Client authentication** 'On'
* **Authentication flow**
* **Standard flow** 'selected'
* **Direct access grants** 'deselect'
* _Save the configuration._
* **Settings / Access settings**:
* **Valid redirect URIs** `https://internal.yourcompany.com/oauth2/callback`
* _Save the configuration._
* Under the **Credentials** tab you will now be able to locate `<your client's secret>`.
2. Configure a dedicated *audience mapper* for your client by navigating to **Clients** -> **<your client's id>** -> **Client scopes**.
* Access the dedicated mappers pane by clicking **<your client's id>-dedicated**, located under *Assigned client scope*.
_(It should have a description of "Dedicated scope and mappers for this client")_
* Click **Configure a new mapper** and select **Audience**
* **Name** 'aud-mapper-<your client's id>'
* **Included Client Audience** select `<your client's id>` from the dropdown.
* _OAuth2 proxy can be set up to pass both the access and ID JWT tokens to your upstream services.
If you require additional audience entries, you can use the **Included Custom Audience** field in addition
to the "Included Client Audience" dropdown. Note that the "aud" claim of a JWT token should be limited and
only specify its intended recipients._
* **Add to ID token** 'On'
* **Add to access token** 'On' - [#1916](https://github.com/oauth2-proxy/oauth2-proxy/pull/1916)
* _Save the configuration._
* Any subsequent dedicated client mappers can be defined by clicking **Dedicated scopes** -> **Add mapper** ->
**By configuration** -> *Select mapper*
You should now be able to create a test user in Keycloak and get access to the OAuth2 Proxy instance, make sure to set
an email address matching `<yourcompany.com>` and select _Email verified_.
**Authorization**
_OAuth2 Proxy will perform authorization by requiring a valid user, this authorization can be extended to take into
account a user's membership in Keycloak `groups`, `realm roles`, and `client roles` using the keycloak-oidc provider options
`--allowed-role` or `--allowed-group`_
**Roles**
_A standard Keycloak installation comes with the required mappers for **realm roles** and **client roles** through the
pre-defined client scope "roles". This ensures that any roles assigned to a user are included in the `JWT` tokens when
using an OIDC client that has the "Full scope allowed" feature activated, the feature is enabled by default._
_Creating a realm role_
* Navigate to **Realm roles** -> **Create role**
* **Role name**, *`<realm role name>`* -> **save**
_Creating a client role_
* Navigate to **Clients** -> `<your client's id>` -> **Roles** -> **Create role**
* **Role name**, *`<client role name>`* -> **save**
_Assign a role to a user_
**Users** -> _Username_ -> **Role mapping** -> **Assign role** -> _filter by roles or clients and select_ -> **Assign**.
Keycloak "realm roles" can be authorized using the `--allowed-role=<realm role name>` option, while "client roles" can be
evaluated using `--allowed-role=<your client's id>:<client role name>`.
You may limit the _realm roles_ included in the JWT tokens for any given client by navigating to:
**Clients** -> `<your client's id>` -> **Client scopes** -> _<your client's id>-dedicated_ -> **Scope**
Disabling **Full scope allowed** activates the **Assign role** option, allowing you to select which roles, if assigned
to a user, will be included in the user's JWT tokens. This can be useful when a user has many associated roles, and you
want to reduce the size and impact of the JWT token.
**Groups**
You may also do authorization on group memberships by using the OAuth2 Proxy option `--allowed-group`.
We will only do a brief description of creating the required _client scope_ **groups** and refer you to read the Keycloak
documentation.
To summarize, the steps required to authorize Keycloak group membership with OAuth2 Proxy are as follows:
* Create a new Client Scope with the name **groups** in Keycloak.
* Include a mapper of type **Group Membership**.
* Set the "Token Claim Name" to **groups** or customize by matching it to the `--oidc-groups-claim` option of OAuth2 Proxy.
* If the "Full group path" option is selected, you need to include a "/" separator in the group names defined in the
`--allowed-group` option of OAuth2 Proxy. Example: "/groupname" or "/groupname/child_group".
After creating the _Client Scope_ named _groups_ you will need to attach it to your client.
**Clients** -> `<your client's id>` -> **Client scopes** -> **Add client scope** -> Select **groups** and choose Optional
and you should now have a client that maps group memberships into the JWT tokens so that Oauth2 Proxy may evaluate them.
Create a group by navigating to **Groups** -> **Create group** and _add_ your test user as a member.
The OAuth2 Proxy option `--allowed-group=/groupname` will now allow you to filter on group membership
Keycloak also has the option of attaching roles to groups, please refer to the Keycloak documentation for more information.
**Tip**
To check if roles or groups are added to JWT tokens, you can preview a users token in the Keycloak console by following
these steps: **Clients** -> `<your client's id>` -> **Client scopes** -> **Evaluate**.
Select a _realm user_ and optional _scope parameters_ such as groups, and generate the JSON representation of an access
or id token to examine its contents.

13
docs/docs/configuration/providers/linkedin.md Normal file
View File

@ -0,0 +1,13 @@
---
id: linkedin
title: LinkedIn
---
For LinkedIn, the registration steps are:
1. Create a new project: https://www.linkedin.com/secure/developer
2. 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`
3. Fill in the remaining required fields and Save.
4. Take note of the **Consumer Key / API Key** and **Consumer Secret / Secret Key**

79
docs/docs/configuration/providers/login_gov.md Normal file
View File

@ -0,0 +1,79 @@
---
id: login_gov
title: Login.gov
---
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
```

28
docs/docs/configuration/providers/nextcloud.md Normal file
View File

@ -0,0 +1,28 @@
---
id: nextcloud
title: NextCloud
---
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](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/oauth2.html)
to set up 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`.

146
docs/docs/configuration/providers/openid_connect.md Normal file
View File

@ -0,0 +1,146 @@
---
id: openid_connect
title: OpenID Connect
---
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:
1. Download Dex:
```
go get github.com/dexidp/dex
```
See the [getting started guide](https://dexidp.io/docs/getting-started/) for more details.
2. 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
```
3. Launch Dex: from `$GOPATH/github.com/dexidp/dex`, run:
```
bin/dex serve examples/config-dev.yaml
```
4. 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 website under the `/static` endpoint, add:
```
-upstream file://$PWD/#/static/
```
5. 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](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/local-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:
1. Log in to Okta using an administrative account. It is suggested you try this in preview first, `example.oktapreview.com`
2. (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](https://developer.okta.com/docs/guides/customize-authz-server/overview/)
3. 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.
4. 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`
#### Okta - localhost
1. Signup for developer account: https://developer.okta.com/signup/
2. Create New `Web` Application: https://${your-okta-domain}/dev/console/apps/new
3. 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`
4. Make note of the `Client ID` and `Client secret`, they are needed in a future step
5. Make note of the **default** Authorization Server Issuer URI from: https://${your-okta-domain}/admin/oauth2/as
6. 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"
```
7. Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/localhost.cfg`

15
docs/docs/configuration/sessions.md
View File

@ -32,7 +32,7 @@ users to re-authenticate
### Redis Storage
The Redis Storage backend stores sessions, encrypted, in redis. Instead sending all the information
The Redis Storage backend stores encrypted sessions in redis. Instead of sending all the information
back the client for storage, as in the [Cookie storage](#cookie-storage), a ticket is sent back
to the user as the cookie value instead.
@ -43,16 +43,15 @@ A ticket is composed as the following:
Where:
- The `CookieName` is the OAuth2 cookie name (_oauth2_proxy by default)
- The `ticketID` is a 128 bit random number, hex-encoded
- The `secret` is a 128 bit random number, base64url encoded (no padding). The secret is unique for every session.
- The `ticketID` is a 128-bit random number, hex-encoded
- The `secret` is a 128-bit random number, base64url encoded (no padding). The secret is unique for every session.
- The pair of `{CookieName}-{ticketID}` comprises a ticket handle, and thus, the redis key
to which the session is stored. The encoded session is encrypted with the secret and stored
in redis via the `SETEX` command.
Encrypting every session uniquely protects the refresh/access/id tokens stored in the session from
disclosure.
Additionally the browser only has to send a short Cookie with every request and not the whole JWT, which can get quite big.
disclosure. Additionally, the browser only has to send a short Cookie with every request and not the whole JWT,
which can get quite big.
Two settings are used to configure the OAuth2 Proxy cookie lifetime:
@ -76,8 +75,8 @@ For this reason, it's advised to set the cookie-refresh a couple of seconds less
Recommended settings:
* cookie\_refresh := Access-Token lifespan - 1m
* cookie\_expire := Refresh-Token lifespan (i.e. Keycloak's client\_session\_idle)
* cookie_refresh := Access-Token lifespan - 1m
* cookie_expire := Refresh-Token lifespan (i.e. Keycloak client_session_idle)
#### Usage

8
docs/docs/features/endpoints.md
View File

@ -9,7 +9,7 @@ OAuth2 Proxy responds directly to the following endpoints. All other endpoints w
- /ping - returns a 200 OK response, which is intended for use with health checks
- /ready - returns a 200 OK response if all the underlying connections (e.g., Redis store) are connected
- /metrics - Metrics endpoint for Prometheus to scrape, serve on the address specified by `--metrics-address`, disabled by default
- /oauth2/sign_in - the login page, which also doubles as a sign out page (it clears cookies)
- /oauth2/sign_in - the login page, which also doubles as a sign-out page (it clears cookies)
- /oauth2/sign_out - this URL is used to clear the session cookie
- /oauth2/start - a URL that will redirect to start the OAuth cycle
- /oauth2/callback - the URL used at the end of the OAuth cycle. The oauth app will be configured with this as the callback url.
@ -19,7 +19,7 @@ OAuth2 Proxy responds directly to the following endpoints. All other endpoints w
### Sign out
To sign the user out, redirect them to `/oauth2/sign_out`. This endpoint only removes oauth2-proxy's own cookies, i.e. the user is still logged in with the authentication provider and may automatically re-login when accessing the application again. You will also need to redirect the user to the authentication provider's sign out page afterwards using the `rd` query parameter, i.e. redirect the user to something like (notice the url-encoding!):
To sign the user out, redirect them to `/oauth2/sign_out`. This endpoint only removes oauth2-proxy's own cookies, i.e. the user is still logged in with the authentication provider and may automatically re-login when accessing the application again. You will also need to redirect the user to the authentication provider's sign-out page afterward using the `rd` query parameter, i.e. redirect the user to something like (notice the url-encoding!):
```
/oauth2/sign_out?rd=https%3A%2F%2Fmy-oidc-provider.example.com%2Fsign_out_page
@ -41,7 +41,7 @@ BEWARE that the domain you want to redirect to (`my-oidc-provider.example.com` i
This endpoint returns 202 Accepted response or a 401 Unauthorized response.
It can be configured using the following query parameters query parameters:
It can be configured using the following query parameters:
- `allowed_groups`: comma separated list of allowed groups
- `allowed_email_domains`: comma separated list of allowed email domains
- `allowed_emails`: comma separated list of allowed emails
- `allowed_emails`: comma separated list of allowed emails

16
docs/docs/installation.md
View File

@ -14,13 +14,13 @@ slug: /
d. Using a [Kubernetes manifest](https://github.com/oauth2-proxy/manifests) (Helm)
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`.
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
oauth2-proxy-x.y.z.linux-amd64: OK
```
```
$ sha256sum -c sha256sum.txt
oauth2-proxy-x.y.z.linux-amd64: OK
```
2. [Select a Provider and Register an OAuth Application with a Provider](configuration/auth.md)
2. [Select a Provider and Register an OAuth Application with a Provider](configuration/providers/index.md)
3. [Configure OAuth2 Proxy using config file, command line options, or environment variables](configuration/overview.md)
4. [Configure SSL or Deploy behind a SSL endpoint](configuration/tls.md) (example provided for Nginx)
4. [Configure SSL or Deploy behind an SSL endpoint](configuration/tls.md) (example provided for Nginx)

3
docs/docusaurus.config.js
View File

@ -37,6 +37,9 @@ module.exports = {
style: 'dark',
copyright: `Copyright © ${new Date().getFullYear()} OAuth2 Proxy.`,
},
prism: {
additionalLanguages: ['hcl', 'powershell'],
},
},
presets: [
[

1044
docs/package-lock.json generated
View File

File diff suppressed because it is too large Load Diff

4
docs/package.json
View File

@ -12,8 +12,8 @@
"serve": "docusaurus serve"
},
"dependencies": {
"@docusaurus/core": "^2.0.0-beta.15",
"@docusaurus/preset-classic": "^2.0.0-beta.15",
"@docusaurus/core": "^2.4.3",
"@docusaurus/preset-classic": "^2.4.3",
"@easyops-cn/docusaurus-search-local": "^0.29.0",
"@mdx-js/react": "^1.6.22",
"clsx": "^1.1.1",

45
docs/sidebars.js
View File

@ -11,18 +11,61 @@ module.exports = {
{
type: 'category',
label: 'Configuration',
link: {
type: 'doc',
id: 'configuration/overview',
},
collapsed: false,
items: ['configuration/overview', 'configuration/oauth_provider', 'configuration/session_storage', 'configuration/tls', 'configuration/alpha-config'],
items: [
'configuration/overview',
{
type: 'category',
label: 'OAuth Provider Configuration',
link: {
type: 'doc',
id: 'configuration/providers/index',
},
items: [
'configuration/providers/google',
'configuration/providers/azure',
'configuration/providers/adfs',
'configuration/providers/facebook',
'configuration/providers/github',
'configuration/providers/gitea',
'configuration/providers/keycloak',
'configuration/providers/keycloak_oidc',
'configuration/providers/gitlab',
'configuration/providers/linkedin',
'configuration/providers/azure_ad',
'configuration/providers/openid_connect',
'configuration/providers/login_gov',
'configuration/providers/nextcloud',
'configuration/providers/digitalocean',
'configuration/providers/bitbucket',
],
},
'configuration/session_storage',
'configuration/tls',
'configuration/alpha-config',
],
},
{
type: 'category',
label: 'Features',
link: {
type: 'doc',
id: 'features/endpoints',
},
collapsed: false,
items: ['features/endpoints'],
},
{
type: 'category',
label: 'Community',
link: {
type: 'doc',
id: 'community/security',
},
collapsed: false,
items: ['community/security'],
},

2
pkg/apis/options/legacy_options.go
View File

@ -605,7 +605,7 @@ func legacyGoogleFlagSet() *pflag.FlagSet {
flagSet.String("google-admin-email", "", "the google admin to impersonate for api calls")
flagSet.String("google-service-account-json", "", "the path to the service account json credentials")
flagSet.String("google-use-application-default-credentials", "", "use application default credentials instead of service account json (i.e. GKE Workload Identity)")
flagSet.String("google-target-principal", "", "the targetprincipal to impersonate when using ADC")
flagSet.String("google-target-principal", "", "the target principal to impersonate when using ADC")
return flagSet
}

4
pkg/apis/options/upstreams.go
View File

@ -12,7 +12,7 @@ const (
// UpstreamConfig is a collection of definitions for upstream servers.
type UpstreamConfig struct {
// ProxyRawPath will pass the raw url path to upstream allowing for url's
// ProxyRawPath will pass the raw url path to upstream allowing for urls
// like: "/%2F/" which would otherwise be redirected to "/"
ProxyRawPath bool `json:"proxyRawPath,omitempty"`
@ -60,7 +60,7 @@ type Upstream struct {
// InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.
// This option is insecure and will allow potential Man-In-The-Middle attacks
// betweem OAuth2 Proxy and the usptream server.
// between OAuth2 Proxy and the upstream server.
// Defaults to false.
InsecureSkipTLSVerify bool `json:"insecureSkipTLSVerify,omitempty"`