Skip to main content

Keycloak Introduction

Keycloak is an open-source identity and access management server. It authenticates users, issues tokens that applications trust, brokers to identity providers you do not own, and centralises the user and permission model that would otherwise be duplicated in every service you run. It is governed by the Apache License 2.0 and backed by Red Hat.

This section explains Keycloak itself — the product, its model and the jobs it does — rather than how Phase Two runs it. If you are evaluating, start here; if you have already decided, Getting Started is the faster path.

Four concepts the rest of this section assumes​

Almost every Keycloak question turns out to be a question about one of these four, and the official documentation assumes you already have them.

ConceptWhat it isWhy it matters
RealmAn isolated tenant: its own users, roles, clients, login pages and signing keysNothing crosses a realm boundary. Two realms share a server and nothing else
ClientAn application that asks Keycloak to authenticate someoneToken lifetimes, redirect URIs, scopes and protocol are all per client
User, group, roleThe account, the organisational unit it sits in, and the permission an application checks forGroups carry roles; users join groups. Modelling it the other way round is the usual first mistake
Identity providerAn external system Keycloak delegates authentication toHow Google, an enterprise SAML IdP or another Keycloak becomes a login button

A realm is not an abstraction — it is a URL prefix, and everything an application needs to integrate hangs off it:

curl -s http://localhost:8080/realms/demo/.well-known/openid-configuration
{
  "issuer": "http://localhost:8080/realms/demo",
  "authorization_endpoint": "http://localhost:8080/realms/demo/protocol/openid-connect/auth",
  "token_endpoint": "http://localhost:8080/realms/demo/protocol/openid-connect/token",
  "jwks_uri": "http://localhost:8080/realms/demo/protocol/openid-connect/certs",
  "end_session_endpoint": "http://localhost:8080/realms/demo/protocol/openid-connect/logout"
}

Every server ships with a master realm. It exists to administer the other realms — put your applications and users in a realm of their own, not in master.

Which job are you doing?​

Keycloak covers three jobs that look similar and configure very differently. Picking the wrong one is recoverable but expensive, because self-registration, password policy, session length and login-page design all follow from it.

Your users areRead
Employees, contractors, internal staffKeycloak as an IAM system — groups, roles, delegated administration, directory federation, joiner/mover/leaver
Customers of your productKeycloak for CIAM — self-registration, social login, consent, branded login at consumer volume
Partners or tenants bringing their own identity providerKeycloak as an IdP broker — protocol translation, home-realm discovery, account linking

Most deployments do more than one, usually in separate realms.

The rest of this section​

Keycloak overview is the full feature tour — SSO, identity brokering, MFA, token-based authentication, federation, RBAC, the admin and account consoles, and theming. Keycloak account console covers the end-user self-service UI and, more usefully, how to switch it off when your product should not expose it.

Then what?​

The pages above are concepts. When you want to make something work, the Keycloak tutorials are task-level and vendor-neutral — they run on any Keycloak, including one you installed yourself five minutes ago. Start with running Keycloak locally and your first realm, client and user.

When the question becomes who operates it, managed Keycloak is what we do, and hosting covers running our images on your own infrastructure instead.