1
0
mirror of https://github.com/oauth2-proxy/oauth2-proxy.git synced 2024-11-24 08:52:25 +02:00
oauth2-proxy/README.md

312 lines
16 KiB
Markdown
Raw Normal View History

2015-05-21 15:54:21 +02:00
oauth2_proxy
2012-12-11 04:34:58 +03:00
=================
2015-05-21 15:54:21 +02:00
<small>(This project was renamed from Google Auth Proxy - May 2015)</small>
2012-12-17 21:03:34 +03:00
A reverse proxy and static file server that provides authentication using Providers (Google, Github, and others)
2015-05-21 15:54:21 +02:00
to validate accounts by email, domain or group.
2012-12-11 04:34:58 +03:00
2015-05-21 08:50:21 +02:00
[![Build Status](https://secure.travis-ci.org/bitly/oauth2_proxy.png?branch=master)](http://travis-ci.org/bitly/oauth2_proxy)
2012-12-26 21:18:56 +03:00
2012-12-11 04:34:58 +03:00
2015-06-08 03:51:47 +02:00
![Sign In Page](https://cloud.githubusercontent.com/assets/45028/4970624/7feb7dd8-6886-11e4-93e0-c9904af44ea8.png)
2014-11-10 05:06:40 +02:00
2012-12-26 21:19:03 +03:00
## Architecture
2012-12-11 04:34:58 +03:00
2015-06-08 03:51:47 +02:00
![OAuth2 Proxy Architecture](https://cloud.githubusercontent.com/assets/45028/8027702/bd040b7a-0d6a-11e5-85b9-f8d953d04f39.png)
2012-12-26 21:19:03 +03:00
## Installation
2015-07-03 05:29:25 +02:00
1. Download [Prebuilt Binary](https://github.com/bitly/oauth2_proxy/releases) (current release is `v2.0.1`) or build with `$ go get github.com/bitly/oauth2_proxy` which will put the binary in `$GOROOT/bin`
2015-06-08 03:51:47 +02:00
2. Select a Provider and Register an OAuth Application with a Provider
3. Configure OAuth2 Proxy using config file, command line options, or environment variables
4. Configure SSL or Deploy behind a SSL endpoint (example provided for Nginx)
2012-12-26 21:19:03 +03:00
2015-05-21 15:54:21 +02:00
## 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*
* [GitHub](#github-auth-provider)
* [LinkedIn](#linkedin-auth-provider)
* [MyUSA](#myusa-auth-provider)
2012-12-26 21:19:03 +03:00
2015-05-21 15:54:21 +02:00
The provider can be selected using the `provider` configuration value.
### Google Auth Provider
2015-04-18 00:33:17 +02:00
For Google, the registration steps are:
1. Create a new project: https://console.developers.google.com/project
2. Under "APIs & Auth", choose "Credentials"
3. Now, choose "Create new Client ID"
* The Application Type should be **Web application** and click **Configure Consent Screen**
* Fill out the appropriate details on the Consent Screen page and hit **Save**
* On the next screen, leaving **Web Application** checked, enter your domain in the Authorized Javascript Origins `https://internal.yourcompany.com`
* Enter the correct Authorized Redirect URL `https://internal.yourcompany.com/oauth2/callback`
2015-05-21 08:50:21 +02:00
* NOTE: `oauth2_proxy` will _only_ callback on the path `/oauth2/callback`
4. Take note of the **Client ID** and **Client Secret**
2012-12-26 21:19:03 +03:00
2015-06-23 20:01:05 +02:00
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 make sure to download the json file.
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.
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 ).
2015-05-21 15:54:21 +02:00
### 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 parameters to restrict authentication to Organization or Team level access. Restricting by org and team is normally accompanied with `--email-domain=*`
2015-05-21 15:54:21 +02:00
-github-org="": restrict logins to members of this organisation
-github-team="": restrict logins to members of this team
### LinkedIn Auth Provider
2015-04-18 00:33:17 +02:00
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**
2012-12-11 04:34:58 +03:00
2015-05-21 15:54:21 +02:00
### MyUSA Auth Provider
The [MyUSA](https://alpha.my.usa.gov) authentication service ([GitHub](https://github.com/18F/myusa))
2015-06-08 03:51:47 +02:00
## 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 addresse use `--email-domain=*`.
2014-11-09 21:51:10 +02:00
## Configuration
2015-05-21 08:50:21 +02:00
`oauth2_proxy` can be configured via [config file](#config-file), [command line options](#command-line-options) or [environment variables](#environment-variables).
2014-11-09 21:51:10 +02:00
### Config File
2015-05-21 15:54:21 +02:00
An example [oauth2_proxy.cfg](contrib/oauth2_proxy.cfg.example) config file is in the contrib directory. It can be used by specifying `-config=/etc/oauth2_proxy.cfg`
2014-11-09 21:51:10 +02:00
### Command Line Options
2012-12-11 04:34:58 +03:00
```
2015-05-21 08:50:21 +02:00
Usage of oauth2_proxy:
-approval-prompt="force": Oauth approval_prompt
2012-12-11 04:59:23 +03:00
-authenticated-emails-file="": authenticate against emails via file (one per line)
-basic-auth-password="": the password to set when passing the HTTP Basic Auth header
2015-05-21 08:50:21 +02:00
-client-id="": the OAuth Client ID: ie: "123456.apps.googleusercontent.com"
-client-secret="": the OAuth Client Secret
2014-11-09 21:51:10 +02:00
-config="": path to config file
-cookie-domain="": an optional cookie domain to force cookies to (ie: .yourcompany.com)*
2014-11-09 21:51:10 +02:00
-cookie-expire=168h0m0s: expire timeframe for cookie
2015-03-18 05:13:45 +02:00
-cookie-httponly=true: set HttpOnly cookie flag
-cookie-name="_oauth2_proxy": the name of the cookie that the oauth_proxy creates
2015-06-23 20:01:05 +02:00
-cookie-refresh=0: refresh the cookie after this duration; 0 to disable
2012-12-11 04:59:23 +03:00
-cookie-secret="": the seed string for secure cookies
2015-03-18 05:13:45 +02:00
-cookie-secure=true: set secure (HTTPS) cookie flag
-custom-templates-dir="": path to custom html templates
-display-htpasswd-form=true: display username / password login form if an htpasswd file is provided
-email-domain=: authenticate emails with the specified domain (may be given multiple times). Use * to authenticate any email
-github-org="": restrict logins to members of this organisation
-github-team="": restrict logins to members of this team
-google-admin-email="": the google admin to impersonate for api calls
-google-group=: restrict logins to members of this google group (may be given multiple times).
-google-service-account-json="": the path to the service account json credentials
2012-12-11 04:59:23 +03:00
-htpasswd-file="": additionally authenticate against a htpasswd file. Entries must be created with "htpasswd -s" for SHA encryption
-http-address="127.0.0.1:4180": [http://]<addr>:<port> or unix://<path> to listen on for HTTP clients
2015-06-08 03:51:47 +02:00
-https-address=":443": <addr>:<port> to listen on for HTTPS clients
-login-url="": Authentication endpoint
-pass-access-token=false: pass OAuth access_token to upstream via X-Forwarded-Access-Token header
2014-11-09 21:51:10 +02:00
-pass-basic-auth=true: pass HTTP Basic Auth, X-Forwarded-User and X-Forwarded-Email information to upstream
2015-03-17 21:15:15 +02:00
-pass-host-header=true: pass the request Host Header to upstream
-profile-url="": Profile access endpoint
2015-06-08 03:51:47 +02:00
-provider="google": OAuth provider
-proxy-prefix="/oauth2": the url root path that this proxy should be nested under (e.g. /<oauth2>/sign_in)
-redeem-url="": Token redemption endpoint
2012-12-11 04:59:23 +03:00
-redirect-url="": the OAuth Redirect URL. ie: "https://internalapp.yourcompany.com/oauth2/callback"
-request-logging=true: Log requests to stdout
-scope="": Oauth scope specification
-signature-key="": GAP-Signature request signature key (algorithm:secretkey)
-skip-auth-regex=: bypass authentication for requests path's that match (may be given multiple times)
2015-06-08 03:51:47 +02:00
-tls-cert="": path to certificate file
-tls-key="": path to private key file
-upstream=: the http url(s) of the upstream endpoint or file:// paths for static files. Routing is based on the path
-validate-url="": Access token validation endpoint
2012-12-11 04:59:23 +03:00
-version=false: print version string
```
2015-05-21 05:23:48 +02:00
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, that will forward all authenticated requests to be forwarded 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/`.
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.
2014-11-09 21:51:10 +02:00
### Environment variables
2012-12-11 05:11:24 +03:00
2015-05-21 08:50:21 +02:00
The environment variables `OAUTH2_PROXY_CLIENT_ID`, `OAUTH2_PROXY_CLIENT_SECRET`, `OAUTH2_PROXY_COOKIE_SECRET`, `OAUTH2_PROXY_COOKIE_DOMAIN` and `OAUTH2_PROXY_COOKIE_EXPIRE` can be used in place of the corresponding command-line arguments.
2014-11-09 21:51:10 +02:00
2015-06-08 03:51:47 +02:00
## SSL Configuration
There are two recommended configurations.
2015-06-08 03:51:47 +02:00
1) Configure SSL Terminiation with OAuth2 Proxy by providing a `--tls-cert=/path/to/cert.pem` and `--tls-key=/path/to/cert.key`.
The command line to run `oauth2_proxy` in this configuration would look like this:
```bash
./oauth2_proxy \
--email-domain="yourcompany.com" \
--upstream=http://127.0.0.1:8080/ \
--tls-cert=/path/to/cert.pem \
--tls-key=/path/to/cert.key \
--cookie-secret=... \
--cookie-secure=true \
--provider=... \
--client-id=... \
--client-secret=...
```
2) Configure SSL Termination with [Nginx](http://nginx.org/) (example config below), Amazon ELB, Google Cloud Platform Load Balancing, or ....
2012-12-11 05:11:24 +03:00
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
would be `https://internal.yourcompany.com/`.
2012-12-11 05:11:24 +03:00
An example Nginx config follows. Note the use of `Strict-Transport-Security` header to pin requests to SSL
2012-12-27 00:53:02 +03:00
via [HSTS](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security):
2012-12-11 05:11:24 +03:00
```
server {
listen 443 default ssl;
server_name internal.yourcompany.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/cert.key;
add_header Strict-Transport-Security max-age=2592000;
2012-12-11 05:11:24 +03:00
location / {
proxy_pass http://127.0.0.1:4180;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 1;
proxy_send_timeout 30;
proxy_read_timeout 30;
}
}
```
2012-12-26 18:35:02 +03:00
2015-06-08 03:51:47 +02:00
The command line to run `oauth2_proxy` in this configuration would look like this:
2012-12-27 00:53:02 +03:00
```bash
2015-05-21 08:50:21 +02:00
./oauth2_proxy \
--email-domain="yourcompany.com" \
2012-12-27 00:53:02 +03:00
--upstream=http://127.0.0.1:8080/ \
--cookie-secret=... \
2015-03-18 05:13:45 +02:00
--cookie-secure=true \
2015-06-08 03:51:47 +02:00
--provider=... \
2012-12-27 00:53:02 +03:00
--client-id=... \
--client-secret=...
```
2012-12-26 21:19:03 +03:00
## Endpoint Documentation
2015-06-08 03:51:47 +02:00
OAuth2 Proxy responds directly to the following endpoints. All other endpoints will be proxied upstream when authenticated. The `/oauth2` prefix can be changed with the `--proxy-prefix` config variable.
2012-12-26 18:35:02 +03:00
* /robots.txt - returns a 200 OK response that disallows all User-agents from all paths; see [robotstxt.org](http://www.robotstxt.org/) for more info
2014-10-14 23:22:38 +03:00
* /ping - returns an 200 OK response
2012-12-26 18:35:02 +03:00
* /oauth2/sign_in - the login page, which also doubles as a sign out page (it clears cookies)
* /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.
* /oauth2/auth - only returns a 202 Accepted response or a 401 Unauthorized response; for use with the [Nginx `auth_request` directive](#nginx-auth-request)
## Request signatures
If `signature_key` is defined, proxied requests will be signed with the
`GAP-Signature` header, which is a [Hash-based Message Authentication Code
(HMAC)](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
of selected request information and the request body [see `SIGNATURE_HEADERS`
in `oauthproxy.go`](./oauthproxy.go).
`signature_key` must be of the form `algorithm:secretkey`, (ie: `signature_key = "sha1:secret0"`)
For more information about HMAC request signature validation, read the
following:
* [Amazon Web Services: Signing and Authenticating REST
Requests](https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html)
* [rc3.org: Using HMAC to authenticate Web service
requests](http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/)
## Logging Format
2015-06-06 20:15:43 +02:00
OAuth2 Proxy logs requests to stdout in a format similar to Apache Combined Log.
```
<REMOTE_ADDRESS> - <user@domain.com> [19/Mar/2015:17:20:19 -0400] <HOST_HEADER> GET <UPSTREAM_HOST> "/path/" HTTP/1.1 "<USER_AGENT>" <RESPONSE_CODE> <RESPONSE_BYTES> <REQUEST_DURATION>
```
## Adding a new Provider
Follow the examples in the [`providers` package](providers/) to define a new
`Provider` instance. Add a new `case` to
2015-05-21 15:54:21 +02:00
[`providers.New()`](providers/providers.go) to allow `oauth2_proxy` to use the
new `Provider`.
## <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:
```nginx
server {
listen 443 ssl spdy;
server_name ...;
include ssl/ssl.conf;
location = /auth {
internal;
proxy_pass http://127.0.0.1:4180;
}
location / {
auth_request /auth;
error_page 401 = ...;
root /path/to/the/site;
default_type text/html;
charset utf-8;
charset_types application/json utf-8;
}
}
```