Authentication with Keycloak using a OAuth 2 Proxy

In this example, keycloak is used as identity provider. For more details on keycloak read this introduction article. Keycloak can be deployed with variety of deployment options.

After keycloak is running go to the admin ui and configure a client. Make sure to follow the guide of OAuth 2 proxy to set up the group mapping properly.

Keycloak stores it’s data in a separate database. There is support for different database vendors. For production environments, file and in memory databases should not be used.

The task of the ingress is to redirect all requests to a specific host path to the OAuth 2 proxy and all requests to another host path to the keycloak service. It’s important to have the keycloak service accessible form outside the cluster to allow redirects to the oauth screen in the users browser.

Make sure to have a single ingress controller like nginx running in the cluster to allow the ingress to work properly.

The OAuth 2 proxy is running between the user and the application. If the user sends a request, the proxy will check the request for the proxy’s session cookie or a JWT. When the authentication is not provided, the user’s browser is redirected to the OAuth screen of a configured identity provider. If the request is authorized, the proxy will forward the request to a configured upstream.

The proxy can be configured to allow multiple groups access to multiple services. It is not possible to allow different groups to access different services. For a more fine grain access control, allow the services to use the authorization header/Token or use a different authentication system like istio.

Minimal configuration:

A detailed overview for all configuration option can be found here

Requests from outside the cluster can only access the application over the main ingress. Because of that, the application can be sure that every request has passed through the OAuth 2 proxy and got authenticated. This has the advantage that the application doesn’t have to implement security itself. The application can get access to the authentication header or token to allow a more fine grain authentication.

To get a FQDN for the ingress without changing the host file, the example is using the domain localtest.me, which will get resolve to 127.0.0.1 by a public DNS server.

This created some problems. When trying to access the keycloak server from the proxy, it’s necessary to use the kubernetes internal URL. Because using the localtest URL will always try to access the loopback device of the pod sending the request.

This increased the complexity of the configuration, because the login URL is different from the tokens issuer URL. To resolve this problem, you have to enable skip-oidc-discovery in the OAuth 2 proxy configuration and set all URLs manually.