OpenID Connect and OAuth Support behind reverse proxies

[Vad1mo]

This proposal is related to #240 but takes another approach that is simpler to implement and maintain.

Request Header Authentication is a common concept the frees the application authorizaiton and authenticaion complexity.

1. External traffic is directed to the auth proxy.
2. The Auth Proxy interacts with the IAM (Redirects the user to the IAM add trusted header).
3. After a successful login the proxy forwards the user to the protected content. Checking if the user is allowed to access the path.
4. The Auth Proxy is adding upstream trusted headers with eg. the user id/email. The upstream service can read the header and trust the header as it trust the proxy becuase there is no one that could set that header except the proxy.

There are many auth proxy implementations that people can choose, Eg. SAML, Active Directory, Open ID Connect, OAuth etc...

An implementation could look like this:

Read Header:
X-Forwarded-User
X-Forwarded-Email

If "Request Header Authentication" is enabled in Config Fathom will evaluate the HTTP header values. If set the user/email is authenticated. If user does not exist create a new user with that id.

A good reference for possible header might be:

• https://docs.konghq.com/hub/kong-inc/basic-auth/#upstream-headers
• https://www.keycloak.org/docs/latest/securing_apps/index.html#forward-signing-proxy
• https://github.com/vouch/vouch-proxy
• https://github.com/pusher/oauth2_proxy

Would "Request Header Authentication" be something that we could implement and provide to fathom?

[JackEllis]

@Vad1mo You’re the only person after this and it’s not something I personally want to include. If 95% of users were asking for it, I’d consider it, but it’s just you. So with that said, I think you should do a pull of the repository, code this in yourself and deploy it how you want it. That way you’ll get it exactly the way you need :)