Open Source OAuth proxy

​OAuth2 Proxy is A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain or group..
You can deploy oauth2-proxy to secure your services in Release. This is handy if a service doesn't have it's own authentication mechanism.
Configuring your Application Template
Starting from our apache-php example directory, we get the following as our application template after import (irrelevant bits removed).
---
repo_name: awesome-release/apache-php
hostnames:
- web: web-${env_id}-${domain}
services:
- name: web
  has_repo: true
  static: false
  ports:
  - type: node_port
    target_port: '80'
    port: '80'
  build:
    context: app
To add oauth2-proxy to this, we add it in as a service alongside our web service.
- name: oauth2-proxy
  image: quay.io/oauth2-proxy/oauth2-proxy
  ports:
  - type: node_port
    port: 4180
    loadbalancer: false
We'll also want to replace the current hostname that points directly to the web service, and have it point at oauth2-proxy instead.
hostnames:
- web: web-${env_id}-${domain}
becomes
hostnames:
- oauth2-proxy: web-${env_id}-${domain}
Once those changes have been made, the template should look like this.
---
repo_name: awesome-release/apache-php
hostnames:
- oauth2-proxy: web-${env_id}-${domain}
services:
- name: web
  has_repo: true
  static: false
  ports:
  - type: node_port
    target_port: '80'
    port: '80'
  build:
    context: app
- name: oauth2-proxy
  image: quay.io/oauth2-proxy/oauth2-proxy
  ports:
  - type: node_port
    port: 4180
    loadbalancer: false
Configuring your Default Environment Variables
So now we need to configure the OAuth side of things. This takes the form of setting some environment variables.
All of the available settings can be found on the oauth2-proxy documentation.
Since we're going to be using Google as our OAuth2 provider, these examples will focus only on that, but any other service will be nearly the same.
services:
  oauth2-proxy:
  - key: OAUTH2_PROXY_PROVIDER
    value: google
  - key: OAUTH2_PROXY_OIDC_ISSUER_URL
    value: https://accounts.google.com
  - key: OAUTH2_PROXY_CLIENT_ID
    value: << YOUR_CLIENT_ID >>
  - key: OAUTH2_PROXY_CLIENT_SECRET
    value: << YOUR_CLIENT_SECRET >>
    secret: true
  - key: OAUTH2_PROXY_COOKIE_SECRET
    value: << YOUR_COOKIE_SECRET >>
    secret: true
  - key: OAUTH2_PROXY_COOKIE_DOMAINS
    value: ".release.com"
  - key: OAUTH2_PROXY_EMAIL_DOMAINS
    value: release.com
  - key: OAUTH2_PROXY_WHITELIST_DOMAINS
    value: ".release.com"
  - key: OAUTH2_PROXY_HTTP_ADDRESS
    value: 0.0.0.0:4180
  - key: OAUTH2_PROXY_UPSTREAMS
    value: http://web:80
  - key: OAUTH2_PROXY_SKIP_PROVIDER_BUTTON
    value: true
mapping:
  OAUTH2_PROXY_REDIRECT_URL: ${OAUTH2_PROXY_INGRESS_URL}/oauth2/callback
You can generate YOUR_COOKIE_SECRET by running python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(16)).decode())'.
Follow the docs for setting up Google OAuth2 credentials to get YOUR_CLIENT_ID and YOUR_CLIENT_SECRET.
You may notice when setting up your Google OAuth2 credentials that it asks for the Authorized Javascript origin as well as the redirect URI.
Authorized redirect URIs is the location of oauth2/callback ex: https://internal.yourcompany.com/oauth2/callback
In the case of Release environments, this might seem tricky due to each new environment generating it's own domain, but there are a few options to handle this.
Environment Handles
Release's Environment Handles is probably the best bet for truly ephemeral environments with OAuth2 support.
This let's you predefine a handful of environment names like dev1, dev2, dev3 or jupiter, mars, venus for example. Then you can predefine your OAuth2 credentials for each of these predefined environments, and your domains will match up correctly.
Updating Environment Variables
If you don't want to use environment handles, then you can deploy a new environment in Release as normal and once that new environment is created, you can plug the generated domain into your OAuth2 settings, then update the environment variables for that specific environment, and redeploy it.
This will restart the environment with the correct OAuth2 settings for that temporary domain, and will continue to work until that environment disappears.
Accessing your Service
Now that you have configured OAuth2, you can access the generated url, in our case it would be something like https://web-jupiter-mydomain.com/. Accessing this URL will automatically redirect you to the Google Login screen because we set OAUTH2_PROXY_SKIP_PROVIDER_BUTTON to true.
Login with an email that belongs to one of the domains that you configured your OAuth2 credentials for, and you should be redirected to your service.
Further Configuration
There are many configuration options available for OAuth2
ngrok and OAuth for private tunnels
Hybrid Docker and static site
Last modified 2mo ago