16 lines
1.6 KiB
Text
16 lines
1.6 KiB
Text
|
== How Does Security Work in Keycloak?
|
||
|
|
|
||
|
|
Keycloak uses _access tokens_ to secure web invocations.
|
||
|
|
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 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-14[JSON Web Token] specification.
|
||
|
|
Each realm has a private and public key pair which it uses to digitally sign the access token using the http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-19[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 http://tools.ietf.org/html/rfc6749[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 propagated 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.
|