In modern enterprise applications, the login is far more than just an access point – it is the core element for security, user-friendliness and integration capability.
Our internal tool “Tedras”, which was developed for conducting and documenting evaluation drives, has so far only been used Microsoft Access ID (formerly Azure Active Directory) for login. As the system increasingly attracted interest from external partners and customers, we had to expand our authentication concept: A second, multi-tenant login was required without compromising security or ease of use.
Our choice fell on keycloak, an open-source solution for Identity & Access Management that stands out for its flexibility, standards compliance and easy integration.
Our architecture at a glance
The system consists of three central components:
– iOS app (Swift, SwiftUI): Recording of evaluation drives with video, voice commentary and GPS data
– Backend (Golang, REST, PostgreSQL): Storage and management of all sessions, photos and videos
– Frontend (React, nginx): Visualization and analysis of the recorded driving data
The services run in containerized Docker and are orchestrated via Kubernetes.
Keycloak was integrated as the central identity provider for authentication.
Key technical aspects of the integration:
– OIDC flows: Both authentication methods – Entra ID and Keycloak – are based on the OpenID Connect standard, which allows for a clean separation and easy extensibility.
– Role and rights management: Keycloak allows for granular definition of user groups, roles, and scopes.
– Token validation in the backend: The Go backend checks access tokens via the Keycloak JWKS interface and grants access only to approved resources.
– Multi-tenancy: A separate realm can be set up in Keycloak for each customer, allowing for separate user management and branding.
Why Keycloak?
We didn't want an in-house development or a makeshift solution. Developing our own OIDC-based authentication service is anything but trivial – especially when enterprise-level security requirements have to be met.
Such a service must correctly implement token flows, securely handle refresh mechanisms, regularly rotate certificates, support multi-realm structures, and remain GDPR-compliant. Errors in these areas can quickly lead to critical security vulnerabilities.
Instead of taking this complex path ourselves, we deliberately opted for Keycloak – a proven open-source platform that:
– standards-based (OIDC, SAML, OAuth2) works
– proven in large companies and projects
– remains easy to configure and deploy
– no license costs incurred
– integrates seamlessly into existing DevOps pipelines
This allowed us to concentrate on the actual product development and not have to reinvent the wheel.
How-To: Deploy Keycloak in Kubernetes
A major advantage of Keycloak is its straightforward deployment. The only requirements are a Kubernetes cluster with kubectl access, Helm (at least v3), and an Ingress controller (e.g., Traefik or NGINX).
Step 1: Add Helm repository
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
Step 2: Create a template for Values.yaml
To see all configurable values, you can export the chart's default configuration:
helm show values bitnami/keycloak > values.yaml
This file contains all the parameters that you can adjust to your environment – from database credentials to Ingress settings and resource limits.
Step 3: Important adjustments in the values.yaml file
For a simple, yet production-like basic installation, the following areas in particular should be adapted:
auth:
adminUser: admin
adminPassword: "SuperSecret123"
service:
type: ClusterIP
port: 8080
ingress:
enabled: true
ingressClassName: traefik
hostname: keycloak.example.com
path: /auth
pathType: Prefix
tls: false
postgresql:
enabled: true
auth:
username: bn_keycloak
password: "PostgresPass123"
database: bitnami_keycloak
Step 4: Start deployment
Once the values are adjusted, a single command is sufficient:
helm install keycloak bitnami/keycloak -f values.yaml --namespace keycloak --create-namespace
After a few minutes, a complete Keycloak instance is running – including database, Ingress configuration and optional TLS support.
Step 5: First registration
You can now open your Keycloak instance in your browser:
http://keycloak.example.com/auth
Next, you log in with the configured admin user, replace the default administrator, and create your first realms, clients, and user groups.
Step 6: Extensions & Automation
Optional extensions such as:
– Identity Brokering
– Custom Themes
– Realm Templates
– automated backups
Configure directly via Helm parameters or the REST API. This quickly transforms a simple basic installation into a productive IAM system that can be fully integrated into modern CI/CD pipelines.
Our Conclusion
By integrating Keycloak, we have created an authentication architecture that combines both internal security and external scalability. This allows our "Tedras" system to be used efficiently not only internally but also at customer sites, without requiring new user management or complex IT approvals.
The experience gained from this project shows that open-source solutions like Keycloak can be excellently integrated into existing cloud and DevOps landscapes.
Are you planning to securely integrate external partners or customers into your system? Or are you considering how to combine multiple login providers within an existing architecture?
Talk to us – we are happy to share our experiences from integrating Keycloak, Entra ID & Co.
