mirror of
https://github.com/oauth2-proxy/oauth2-proxy.git
synced 2026-09-30 03:31:27 +02:00
Migrate to oauth2-proxy/oauth2-proxy
This commit is contained in:
Joel Speed
+1
-1
@@ -14,7 +14,7 @@ to validate accounts by email, domain or group.
|
||||
Versions v3.0.0 and up are from this fork and will have diverged from any changes in the original fork.
|
||||
A list of changes can be seen in the [CHANGELOG]({{ site.gitweb }}/CHANGELOG.md).
|
||||
|
||||
[](http://travis-ci.org/pusher/oauth2_proxy)
|
||||
[](http://travis-ci.org/oauth2-proxy/oauth2-proxy)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -9,17 +9,17 @@ nav_order: 1
|
||||
|
||||
1. Choose how to deploy:
|
||||
|
||||
a. Download [Prebuilt Binary](https://github.com/pusher/oauth2_proxy/releases) (current release is `v4.0.0`)
|
||||
a. Download [Prebuilt Binary](https://github.com/oauth2-proxy/oauth2-proxy/releases) (current release is `v5.1.0`)
|
||||
|
||||
b. Build with `$ go get github.com/pusher/oauth2_proxy` which will put the binary in `$GOROOT/bin`
|
||||
b. Build with `$ go get github.com/oauth2-proxy/oauth2-proxy` which will put the binary in `$GOROOT/bin`
|
||||
|
||||
c. Using the prebuilt docker image [quay.io/pusher/oauth2_proxy](https://quay.io/pusher/oauth2_proxy) (AMD64, ARMv6 and ARM64 tags available)
|
||||
c. Using the prebuilt docker image [quay.io/oauth2-proxy/oauth2-proxy](https://quay.io/oauth2-proxy/oauth2-proxy) (AMD64, ARMv6 and ARM64 tags available)
|
||||
|
||||
Prebuilt binaries can be validated by extracting the file and verifying it against the `sha256sum.txt` checksum file provided for each release starting with version `v3.0.0`.
|
||||
|
||||
```
|
||||
$ sha256sum -c sha256sum.txt 2>&1 | grep OK
|
||||
oauth2_proxy-4.0.0.linux-amd64: OK
|
||||
oauth2-proxy-x.y.z.linux-amd64: OK
|
||||
```
|
||||
|
||||
2. [Select a Provider and Register an OAuth Application with a Provider](auth-configuration)
|
||||
|
||||
+13
-13
@@ -7,7 +7,7 @@ nav_order: 2
|
||||
|
||||
## 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.
|
||||
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 :
|
||||
|
||||
@@ -67,8 +67,8 @@ https://www.googleapis.com/auth/admin.directory.user.readonly
|
||||
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.
|
||||
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 ).
|
||||
|
||||
@@ -163,12 +163,12 @@ Take note of your `TenantId` if applicable for your situation. The `TenantId` ca
|
||||
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.
|
||||
|
||||
1. Launch a Dex instance using the [getting started guide](https://github.com/coreos/dex/blob/master/Documentation/getting-started.md).
|
||||
2. Setup oauth2_proxy with the correct provider and using the default ports and callbacks.
|
||||
3. Login with the fixture use in the dex guide and run the oauth2_proxy with the following args:
|
||||
2. Setup oauth2-proxy with the correct provider and using the default ports and callbacks.
|
||||
3. Login with the fixture use in the dex guide and run the oauth2-proxy with the following args:
|
||||
|
||||
-provider oidc
|
||||
-provider-display-name "My OIDC Provider"
|
||||
-client-id oauth2_proxy
|
||||
-client-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
|
||||
@@ -222,7 +222,7 @@ The `oidc_issuer_url` is based on URL from your **Authorization Server**'s **Iss
|
||||
The `client_id` and `client_secret` are configured in the application settings.
|
||||
Generate a unique `client_secret` to encrypt the cookie.
|
||||
|
||||
Then you can start the oauth2_proxy with `./oauth2_proxy -config /etc/example.cfg`
|
||||
Then you can start the oauth2-proxy with `./oauth2-proxy -config /etc/example.cfg`
|
||||
|
||||
|
||||
### login.gov Provider
|
||||
@@ -251,7 +251,7 @@ First, register your application in the dashboard. The important bits are:
|
||||
|
||||
Now start the proxy up with the following options:
|
||||
```
|
||||
./oauth2_proxy -provider login.gov \
|
||||
./oauth2-proxy -provider login.gov \
|
||||
-client-id=${LOGINGOV_ISSUER} \
|
||||
-redirect-url=http://localhost:4180/oauth2/callback \
|
||||
-oidc-issuer-url=https://idp.int.identitysandbox.gov/ \
|
||||
@@ -282,13 +282,13 @@ 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.
|
||||
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-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
|
||||
@@ -330,7 +330,7 @@ Note: in *all* cases the validate-url will *not* have the `index.php`.
|
||||
|
||||
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.
|
||||
* 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:
|
||||
@@ -346,7 +346,7 @@ To use the provider, pass the following options:
|
||||
### 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 "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
|
||||
@@ -372,5 +372,5 @@ To authorize by email domain use `--email-domain=yourcompany.com`. To authorize
|
||||
|
||||
Follow the examples in the [`providers` package]({{ site.gitweb }}/providers/) to define a new
|
||||
`Provider` instance. Add a new `case` to
|
||||
[`providers.New()`]({{ site.gitweb }}/providers/providers.go) to allow `oauth2_proxy` to use the
|
||||
[`providers.New()`]({{ site.gitweb }}/providers/providers.go) to allow `oauth2-proxy` to use the
|
||||
new `Provider`.
|
||||
|
||||
+7
-7
@@ -11,10 +11,10 @@ There are two recommended configurations.
|
||||
|
||||
1. Configure SSL Termination with OAuth2 Proxy by providing a `--tls-cert-file=/path/to/cert.pem` and `--tls-key-file=/path/to/cert.key`.
|
||||
|
||||
The command line to run `oauth2_proxy` in this configuration would look like this:
|
||||
The command line to run `oauth2-proxy` in this configuration would look like this:
|
||||
|
||||
```bash
|
||||
./oauth2_proxy \
|
||||
./oauth2-proxy \
|
||||
--email-domain="yourcompany.com" \
|
||||
--upstream=http://127.0.0.1:8080/ \
|
||||
--tls-cert-file=/path/to/cert.pem \
|
||||
@@ -28,12 +28,12 @@ There are two recommended configurations.
|
||||
|
||||
2. Configure SSL Termination with [Nginx](http://nginx.org/) (example config below), Amazon ELB, Google Cloud Platform Load Balancing, or ....
|
||||
|
||||
Because `oauth2_proxy` listens on `127.0.0.1:4180` by default, to listen on all interfaces (needed when using an
|
||||
Because `oauth2-proxy` listens on `127.0.0.1:4180` by default, to listen on all interfaces (needed when using an
|
||||
external load balancer like Amazon ELB or Google Platform Load Balancing) use `--http-address="0.0.0.0:4180"` or
|
||||
`--http-address="http://:4180"`.
|
||||
|
||||
Nginx will listen on port `443` and handle SSL connections while proxying to `oauth2_proxy` on port `4180`.
|
||||
`oauth2_proxy` will then authenticate requests for an upstream application. The external endpoint for this example
|
||||
Nginx will listen on port `443` and handle SSL connections while proxying to `oauth2-proxy` on port `4180`.
|
||||
`oauth2-proxy` will then authenticate requests for an upstream application. The external endpoint for this example
|
||||
would be `https://internal.yourcompany.com/`.
|
||||
|
||||
An example Nginx config follows. Note the use of `Strict-Transport-Security` header to pin requests to SSL
|
||||
@@ -59,10 +59,10 @@ There are two recommended configurations.
|
||||
}
|
||||
```
|
||||
|
||||
The command line to run `oauth2_proxy` in this configuration would look like this:
|
||||
The command line to run `oauth2-proxy` in this configuration would look like this:
|
||||
|
||||
```bash
|
||||
./oauth2_proxy \
|
||||
./oauth2-proxy \
|
||||
--email-domain="yourcompany.com" \
|
||||
--upstream=http://127.0.0.1:8080/ \
|
||||
--cookie-secret=... \
|
||||
|
||||
+2
-2
@@ -20,7 +20,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 afterwards 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
|
||||
@@ -33,7 +33,7 @@ GET /oauth2/sign_out HTTP/1.1
|
||||
X-Auth-Request-Redirect: https://my-oidc-provider/sign_out_page
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
(The "sign_out_page" should be the [`end_session_endpoint`](https://openid.net/specs/openid-connect-session-1_0.html#rfc.section.2.1) from [the metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) if your OIDC provider supports Session Management and Discovery.)
|
||||
|
||||
BEWARE that the domain you want to redirect to (`my-oidc-provider.example.com` in the example) must be added to the [`-whitelist-domain`](configuration) configuration option otherwise the redirect will be ignored.
|
||||
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
# Docs
|
||||
|
||||
This folder contains our Jekyll based docs site which is hosted at
|
||||
https://pusher.github.io/oauth2_proxy.
|
||||
https://oauth2-proxy.github.io/oauth2-proxy.
|
||||
|
||||
When making changes to this docs site, please test your changes locally:
|
||||
|
||||
|
||||
+7
-7
@@ -13,13 +13,13 @@
|
||||
# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
|
||||
# You can create any custom variable you would like, and they will be accessible
|
||||
# in the templates via {{ site.myvariable }}.
|
||||
title: OAuth2_Proxy
|
||||
title: OAuth2 Proxy
|
||||
logo: /logos/OAuth2_Proxy_horizontal.svg
|
||||
description: >- # this means to ignore newlines until "baseurl:"
|
||||
OAuth2_Proxy documentation site
|
||||
baseurl: "/oauth2_proxy" # the subpath of your site, e.g. /blog
|
||||
url: "https://pusher.github.io" # the base hostname & protocol for your site, e.g. http://example.com
|
||||
gitweb: "https://github.com/pusher/oauth2_proxy/blob/master"
|
||||
OAuth2-Proxy documentation site
|
||||
baseurl: "/oauth2-proxy" # the subpath of your site, e.g. /blog
|
||||
url: "https://oauth2-proxy.github.io" # the base hostname & protocol for your site, e.g. http://example.com
|
||||
gitweb: "https://github.com/oauth2-proxy/oauth2-proxy/blob/master"
|
||||
|
||||
# Build settings
|
||||
markdown: kramdown
|
||||
@@ -28,8 +28,8 @@ search_enabled: true
|
||||
|
||||
# Aux links for the upper right navigation
|
||||
aux_links:
|
||||
"OAuth2_Proxy on GitHub":
|
||||
- "https://github.com/pusher/oauth2_proxy"
|
||||
"OAuth2 Proxy on GitHub":
|
||||
- "https://github.com/oauth2-proxy/oauth2-proxy"
|
||||
|
||||
# Exclude from processing.
|
||||
# The following items will not be processed, by default. Create a custom list
|
||||
|
||||
@@ -8,7 +8,7 @@ nav_order: 3
|
||||
|
||||
## Configuration
|
||||
|
||||
`oauth2_proxy` can be configured via [config file](#config-file), [command line options](#command-line-options) or [environment variables](#environment-variables).
|
||||
`oauth2-proxy` can be configured via [config file](#config-file), [command line options](#command-line-options) or [environment variables](#environment-variables).
|
||||
|
||||
To generate a strong cookie secret use `python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(16)).decode())'`
|
||||
|
||||
@@ -16,7 +16,7 @@ To generate a strong cookie secret use `python -c 'import os,base64; print(base6
|
||||
|
||||
Every command line argument can be specified in a config file by replacing hypens (-) with underscores (\_). If the argument can be specified multiple times, the config option should be plural (trailing s).
|
||||
|
||||
An example [oauth2_proxy.cfg]({{ site.gitweb }}/contrib/oauth2_proxy.cfg.example) config file is in the contrib directory. It can be used by specifying `-config=/etc/oauth2_proxy.cfg`
|
||||
An example [oauth2-proxy.cfg]({{ site.gitweb }}/contrib/oauth2-proxy.cfg.example) config file is in the contrib directory. It can be used by specifying `-config=/etc/oauth2-proxy.cfg`
|
||||
|
||||
### Command Line Options
|
||||
|
||||
@@ -127,9 +127,9 @@ See below for provider specific options
|
||||
|
||||
### Upstreams Configuration
|
||||
|
||||
`oauth2_proxy` supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers or serve static files from the file system. HTTP and HTTPS upstreams are configured by providing a URL such as `http://127.0.0.1:8080/` for the upstream parameter, this will forward all authenticated requests to the upstream server. If you instead provide `http://127.0.0.1:8080/some/path/` then it will only be requests that start with `/some/path/` which are forwarded to the upstream.
|
||||
`oauth2-proxy` supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers or serve static files from the file system. HTTP and HTTPS upstreams are configured by providing a URL such as `http://127.0.0.1:8080/` for the upstream parameter, this will forward all authenticated requests to the upstream server. If you instead provide `http://127.0.0.1:8080/some/path/` then it will only be requests that start with `/some/path/` which are forwarded to the upstream.
|
||||
|
||||
Static file paths are configured as a file:// URL. `file:///var/www/static/` will serve the files from that directory at `http://[oauth2_proxy url]/var/www/static/`, which may not be what you want. You can provide the path to where the files should be available by adding a fragment to the configured URL. The value of the fragment will then be used to specify which path the files are available at. `file:///var/www/static/#/static/` will ie. make `/var/www/static/` available at `http://[oauth2_proxy url]/static/`.
|
||||
Static file paths are configured as a file:// URL. `file:///var/www/static/` will serve the files from that directory at `http://[oauth2-proxy url]/var/www/static/`, which may not be what you want. You can provide the path to where the files should be available by adding a fragment to the configured URL. The value of the fragment will then be used to specify which path the files are available at. `file:///var/www/static/#/static/` will ie. make `/var/www/static/` available at `http://[oauth2-proxy url]/static/`.
|
||||
|
||||
Multiple upstreams can either be configured by supplying a comma separated list to the `-upstream` parameter, supplying the parameter multiple times or provinding a list in the [config file](#config-file). When multiple upstreams are used routing to them will be based on the path they are set up with.
|
||||
|
||||
@@ -246,7 +246,7 @@ Available variables for standard logging:
|
||||
|
||||
## <a name="nginx-auth-request"></a>Configuring for use with the Nginx `auth_request` directive
|
||||
|
||||
The [Nginx `auth_request` directive](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) allows Nginx to authenticate requests via the oauth2_proxy's `/auth` endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example:
|
||||
The [Nginx `auth_request` directive](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) allows Nginx to authenticate requests via the oauth2-proxy's `/auth` endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example:
|
||||
|
||||
```nginx
|
||||
server {
|
||||
|
||||
Reference in New Issue
Block a user