ThetaDev/oidc-forward-auth
1
0
Fork 0
Code Issues Pull requests Projects Releases Activity
OpenID Connect ForwardAuth for containo.us Traefik 🔐
29 commits 2 branches 1 tag 106 KiB
Go 91.7%
Dockerfile 8.3%
Find a file
Stefan Kürzeder 9b3558f598 File refactor
2020-06-04 18:46:33 +02:00
.github Added .github 2020-06-03 13:48:42 +02:00
examples Fixed typos 2020-06-04 14:57:54 +02:00
pkg File refactor 2020-06-04 18:46:33 +02:00
.gitignore Progress 2020-05-22 12:56:48 +02:00
Dockerfile Add Docker labels 2020-06-03 13:58:16 +02:00
go.mod Initial commit 2020-05-20 13:15:38 +02:00
go.sum Initial commit 2020-05-20 13:15:38 +02:00
LICENSE Add license 2020-05-20 13:19:31 +02:00
main.go Made port and redirect optional settings 2020-06-04 16:44:18 +02:00
README.md Made port and redirect optional settings 2020-06-04 16:44:18 +02:00

README.md

OIDC ForwardAuth for Traefik

An OIDC compliant traefik forwardauth handler which follows the lifecycle of the token, also supports refreshing of tokens (WIP). Supports all OIDC compliant Identity Solutions, e.g. KeyCloak, GitHub, Google, ...
Code was also built with the Idea to be as simple and minimal as possible.

Configuration

Configuration is currently only via environmnet variables supported:

Environment Variable Type Description Example
ISSUER string OIDC Issuer (required) https://accounts.google.com
CLIENT_ID string OIDC Client Id (required) CLIENT_ID
CLIENT_SECRET string OIDC Client Secret (required) CLIENT_SECRET
AUTH_DOMAIN string Central auth domain (required) auth.example.com
COOKIE_DOMAIN string Root domain(s) of protected host(s) (required) example.com
PORT string Port on which the Application is running on 4181
REDIRECT_URL string Redirect URL /auth/resp

Usage

The authenticated user is set in the X-Forwarded-User header.
See more in the Examples section.

Examples

Following examples are currently available:
- Google Authentication

Future Features

  • Refresh Token support
  • Add option to only allow Users with verfied mails
  • Add mail whitelist
  • Your Idea here

Cookie Domains

You can supply a comma separated list of cookie domains, if the host of the original request is a subdomain of any given cookie domain, the authentication cookie will set with the given domain.

For example, if cookie domain is test.com and a request comes in on app1.test.com, the cookie will be set for the whole test.com domain. As such, if another request is forwarded for authentication from app2.test.com, the original cookie will be sent and so the request will be allowed without further authentication.

Operation Details

For example, you have a few applications: app1.test.com, app2.test.com, appN.test.com. To utilise an auth host, permit domain level cookies by setting the cookie domain to test.com then set the auth-host to: auth.test.com.

The user flow will then be:

  1. Request to app10.test.com/home/page
  2. User redirected to OIDC login
  3. After OIDC login, user is redirected to auth.test.com/auth/resp
  4. Token, user and CSRF cookie is validated, auth cookie is set to test.com
  5. User is redirected to app10.test.com/home/page
  6. Request is allowed

Two criteria must be met for an auth-host to be used:

  1. Request matches given cookie-domain
  2. auth-host is also subdomain of same cookie-domain