Overview

Key Concepts in Keycloak The core concept in Keycloak is a Realm. A realm secures and manages security metadata for a set of users, applications, and registered oauth clients. Users can be created within a specific realm within the Administration console. Roles (permission types) can be defined at the realm level and you can also set up user role mappings to assign these permissions to specific users. An application is a service that is secured by a realm. When a user browses an application's web site, the application can redirect the user agent to the Keycloak Server and request a login. Once a user is logged in, they can visit any other application managed by the realm and not have to re-enter credentials. This also hold true for logging out. Roles can also be defined at the application level and assigned to specific users. Depending on the application type, you may also be able to view and manage user sessions from the administration console. An oauth client is similar to an application in that it can request something like a login when a user visits the site of the oauth client. The difference is that oauth clients are not immediately granted all permissions of the user. In addition to requesting the login credentials of the user, the Keycloak Server will also display a grant page asking the user if it is ok to grant allowed permissions to the oauth client.

How Does Security Work in Keycloak? Keycloak uses access tokens. Access tokens contains security metadata specifying the identity of the user as well as the role mappings for that user. The format of these tokens is a Keycloak extension to the JSON Web Token specification. Each realm has a private and public key pair which it uses to digitally sign the access token using the JSON Web Signature specification. Applications can verify the integrity of the digitally signed access token using the public key of the realm. The protocols used to obtain this token is defined by the OAuth 2.0 specification. The interesting thing about using these smart access tokens is that applications themselves are completely stateless as far as security metadata goes. All the information they need about the user is contained in the token and there's no need for them to store any security metadata locally other than the public key of the realm. Signed access tokens can also be proprogated by REST client requests within an Authorization header. This is great for distributed integration as applications can request a login from a client to obtain an access token, then invoke any aggregated REST invocations to other services using that access token. So, you have a distributed security model that is centrally managed, yet does not require a Keycloak Server hit per request, only for the initial login.

Permission Scopes Each application and oauth client are configured with a set of permission scopes. These are a set of roles that an application or oauth client is allowed to ask permission for. Access tokens are always granted at the request of a specific application or oauth client. This also holds true for SSO. As you visit different sites, the application will redirect back to the Keycloak Server via the OAuth 2.0 protocol to obtain an access token specific to that application. The role mappings contained within the token are the union between the set of user role mappings and the permission scope of the application/oauth client. So, access tokens are tailor made for each application/oauth client and contain only the information required for by them.