senn-techSingle Sign-On & IAM: Keycloak Secures Internal Services
Every internal service has its own login — it’s not just annoying, it’s a security problem. Passwords get reused, accounts forgotten, and permissions linger after employees leave. Keycloak fixes that.
What Keycloak Is
An identity and access management server under the Apache-2.0 license. It speaks OIDC, SAML, and can integrate external identity sources (LDAP, Active Directory, social logins).
The logical unit is the realm — a closed identity domain. Customers get a realm; internal services get another. This cleanly separates them without requiring multiple installations.
Central Security for Internal Services
We run Keycloak behind the same reverse proxy as the services it protects. The flow is:
- Service X forwards unauthenticated requests to Keycloak
- Login with username/password or an additional MFA factor
- Keycloak issues access and refresh tokens
- Service X validates the token, and the user is in
No service needs to manage credentials itself. This greatly simplifies the security architecture.
Even for Services Without OIDC: Forward-Auth
Not every application speaks OIDC or SAML. For these cases, you place a forward-auth proxy in front (such as oauth2-proxy or Caddy’s forward_auth directive): the proxy enforces the Keycloak login before the request even reaches the application. This lets you centrally secure even an old admin interface that lacks its own login system.
MFA and Passkeys
Keycloak includes multiple second factors — TOTP (authenticator app) and also WebAuthn/passkeys. Especially for administrative realms, phishing-resistant passkey login is the step that largely neutralizes brute-force and credential-phishing attacks.
Identity Brokering
Keycloak can delegate to an external IDP — say, a customer’s Azure AD or Google Workspace. The user logs in with their familiar provider, and Keycloak translates the identity into its own realm. Federated identity management without wrestling with raw SAML.
What Keycloak Is Not
Not a directory service. Keycloak does not replace AD or LDAP — it uses them as sources. And: the UI is functional, but not something end users can use without training.
Conclusion
For anyone running more than three internal web applications, a central SSO service is no longer optional — it’s a necessity. Keycloak delivers it with everything that entails — right down to Git services like Gitea, which can be directly integrated.
How many internal web apps justify a central SSO service?+
Anyone running more than three internal web applications needs a central single sign-on service, not as an option but as a necessity. Separate logins lead to reused passwords, forgotten accounts, and permissions that linger after employees leave. Keycloak eliminates this as a license-free identity and access management server under the Apache-2.0 license, speaking both OIDC and SAML.
How do we secure apps that lack OIDC or SAML support?+
For applications without their own OIDC or SAML login, place a forward-auth proxy in front – such as oauth2-proxy or Caddy's forward_auth directive. The proxy enforces the Keycloak login before the request even reaches the application. This centrally secures even an old admin interface with no login system of its own, without modifying the application itself.
Does Keycloak replace our Active Directory or LDAP?+
No. Keycloak is not a directory service and replaces neither AD nor LDAP; it uses them as identity sources. It can integrate LDAP, Active Directory, and social logins, and via identity brokering delegate to an external IDP like an Azure AD. The UI is functional but not for end users without training – Keycloak remains a tool for IT.