Assessments

Chapter 1

1. Yes. Keycloak distributes container images for Docker, which runs on Kubernetes. There is also a Kubernetes Operator for Keycloak that makes it easier to install and manage Keycloak on Kubernetes.
2. The Keycloak admin console provides an extensive console to allow you to configure and manage Keycloak, including managing applications and users.
3. The Keycloak account console provides a self-service console for end users of your applications to manage their own accounts, including updating their profile and changing their password.

Chapter 2

1. The application redirects the user to the login pages provided by Keycloak. Following authentication, the user is redirected back to the application and the application obtains an ID token from Keycloak that it can use to discover information about the authenticated user.
2. For an application to be permitted to authenticate users with Keycloak, it must first be registered as a client with Keycloak.
3. The application includes an access token in the request, which the backend service can verify to decide whether access should be granted.

Chapter 3

1. OAuth 2.0 enables an application to obtain an access token that grants access to a set of resources provided by a different application on behalf of the user.
2. OpenID Connect adds an authentication layer on top of OAuth 2.0.
3. OAuth 2.0 does not define a standard format for tokens. By leveraging JWT as the token format, applications are able to directly verify and understand the contents of the token.

Chapter 4

1. Through the Discovery endpoint, an application can find out a lot of useful information about an OpenID Provider, which allows it to automatically configure itself to a specific provider.
2. The application retrieves an ID token, a signed JWT, from the OpenID Provider, which contains information about the authenticated user.
3. By adding a protocol mapper, or a client scope, to a client you can control exactly what information is included in the ID token that is made available to an application.

Chapter 5

1. An application can leverage the OAuth 2.0 Authorization Code grant type to obtain an access token from the authorization server. The application then includes the access token in the request sent to the REST API.
2. An access token can be limited through the use of the audience, roles, or scopes.
3. A service can either invoke the token introspection endpoint to verify the access token, or if the token is a JWT, it can verify and read the contents of the token directly.

Chapter 6

1. As an SPA is running in the browser, it cannot use a confidential client directly, which results in a greater risk if a refresh token is leaked. For this reason, it is more secure to have a backend running in a web server that can use a confidential client and store tokens on the server side.
2. No, any type of application can use OAuth 2.0 through an external user agent to obtain an access token, and many different types of services have support for bearer tokens.
3. An application should never collect user credentials directly as this increases the chance of credentials being leaked, and provides the application with full access to the user account. For this reason, native and mobile applications should use an external user agent to authenticate with Keycloak.

Chapter 7

1. In this chapter, you were presented with different integration options for different programming languages and platforms. If the programming language you are using already supports OpenID Connect, even if this is being done through a library or framework, you should consider using it.

   Alternatively, you can also use a reverse proxy such as Apache HTTP Server.

2. No, the Keycloak adapters were created when there were not many trusted client libraries. Nowadays, programming languages, and the frameworks built on top of these languages, already provide support for OpenID Connect.

   As a rule of thumb, do the opposite: only consider using any of the Keycloak adapters if you are left with no other option.

3. If you are using Reactive Native, you might want to look at https://github.com/FormidableLabs/react-native-app-auth/blob/main/docs/config-examples/keycloak.md.

   There you should find examples on how to use it with Keycloak.

   Remember that Keycloak is a fully compliant OpenID Connect Provider implementation, and you should be able to use any other library too.

4. For applications running on Kubernetes or OpenShift, both integration architecture styles would fit. Depending on the service mesh you are using (for instance, Istio), you should be able to leverage its capabilities.

   But still, you can use the embedded architectural style. This makes a lot of sense if you are already familiar with the options you have from the technology stack your application is using.

Chapter 8

1. When you put data into tokens, they actually grow disproportionately in size. One option to help here is to include only the minimum information that your application needs, and for additional information, to use the token introspection endpoint. The drawback is that your application will need an additional request to Keycloak when serving requests.

   You should also consider disabling the Full Scope Allowed setting in your client settings, so that only information relevant to your client is included in tokens.

2. Realm roles should be used to represent the user's role within an organization. These roles have the same semantics regardless of the clients created in a realm.
3. On the other hand, the semantics for a client role are specific to the client they belong to.
4. In this chapter, we created a realm role and a client role using the same name: manager. While the realm role could represent users with the role of manager in an organization, the manager client role could represent the permissions to manage resources in the application.

   It is up to you to choose what best fits your case; just keep in mind this conceptual difference so that you do not overuse one or the other.

5. Yes; for that, you would need to customize Keycloak through the Authentication SPI.

   It should be possible to have, for instance, additional pages in your flows to gather user information, or just use a custom authenticator to push contextual information as a session note, so that later you can map information from these session notes to tokens using a protocol mapper.

6. Yes, and this is a common task when your application is expecting to obtain roles from a claim other than the realm_access or resource_access claims. You can always change the protocol mappers to better suit your application's needs.
7. No. Applications can use different strategies depending on their security requirements. It is perfectly fine to use RBAC or groups, for instance, at the same application, or even to use ABAC or Keycloak Authorization Services, if you need fine-grained access to protected resources.

Chapter 9

1. Yes. It is recommended that you have an active-passive or active-active database so that in the event of failures, you can easily switch database instances. Note, however, that Keycloak keeps as much data as possible in caches, where reads should not be impacted at all depending on how hot the caches are (how much data is cached). Writes, however, will fail until the connection is re-established.

   Keycloak also supports setting some useful configuration options to improve failover in the event of network failures. You might want to enable background validation of connections to make sure available connections are usable, validate connections prior to obtaining them from the connection pool, or even configure the pool to fail fast when a connection is terminated to avoid validating and iterating over all connections in the pool.

2. No. The default configuration by default uses IP multicast to broadcast messages across nodes and form a cluster. The proper configuration depends on where Keycloak is being deployed. If you are deploying on bare metal or in a VM, you should consider using a different JGroups stack using either TCPPING or JDBC_PING for discovery.
3. Keycloak provides an operator that takes care of setting up most of the things we discussed in this chapter. We highly recommend using it to run Keycloak on any of these platforms. In terms of clustering, when running on OpenShift and Kubernetes DNS_PING is recommended for discovery.
4. By default, there is no security in this communication so that any instance listening on the same multicast address can join the cluster. To prevent unexpected nodes from joining a cluster, you can configure your JGroups stack to rely on X.509 certificates to authenticate nodes. You should also be able to enable encryption to prevent data from being intercepted and transferred in cleartext. For more details, look at the recommendations from Chapter 14, Securing Keycloak.
5. Ideally, yes. The reason being that, even though your instances are running within a private network, Keycloak is constantly exchanging sensitive data about users (privacy) and tokens issued by the server to applications. It is recommended to use end-to-end encryption.
6. Yes. Keycloak is CPU intensive due password hashing, token issuance, and verification using signatures and encryption. Depending on your load and how many concurrent requests you should handle, you might want to allocate two or more CPUs for each node in the cluster.

   High CPU usage can also be caused by frequent GC runs. Common causes might be related to a small metaspace size, small young generation size, or the JVM reaching the overall heap size. You should constantly be monitoring and adjusting GC runs until you get as few pauses and counts as possible.

   Keep in mind that TLS demands CPU. Depending on your requirements you might want to configure your reverse proxy with TLS termination and save some CPU on Keycloak nodes.

7. It depends on the use case. You should start small, using the default settings, and adjust accordingly to your load and performance tests.
8. Yes. Check the Keycloak Benchmark tool at https://github.com/keycloak/keycloak-benchmark.

Chapter 10

1. Yes. As we will see in the following chapters, Keycloak provides a Service Provider Interface (SPI) that allows you to integrate not only with databases but with any other form of identity store.
2. No. In addition to storing information from LDAP in its own database, Keycloak also caches data for entries that have been imported from LDAP. You have complete control over how information is cached and when it expires. Here, together with the synchronization settings, information from the LDAP directory is periodically updated without it impacting the overall performance of the server.
3. Keycloak allows you to configure mappers for identity providers. Through these mappers, you can customize how users are created by setting a specific user attribute or setting a specific role when the user authenticates for the very first time.

Chapter 11

1. Keycloak allows you to customize its look and feel entirely, not just for the pages that were presented in this chapter. As we are going to see in Chapter 13, Extending Keycloak, you should be able to change the look and feel of pages by changing the different themes provided by Keycloak. You can find more details in the documentation at https://www.keycloak.org/docs/latest/server_development/#_themes.
2. WebAuthn requires you to use a FIDO or FIDO2 compliant security device. You should also consider accessing Keycloak using HTTPS and using a valid domain name. WebAuthn is strict about domain names and secure connections if the server is accessed from a different domain than the client. You should also make sure the browser you are using has support for the WebAuthn API. You should also consider looking at the demo on the WebAuthn site to check how your security device works there.

Chapter 12

1. It depends on the type of session. User and client sessions are kept in memory but there is a special type of session called offline sessions that are stored in the database.
2. An offline session is a special type of session that solves a specific problem when using offline tokens, as per the OpenID Connect specification. The purpose of offline tokens is to allow clients to act on behalf of users even though the user is offline, such as when performing background tasks to access or process user information. Some people, though, use offline tokens to work around the complexities – or possible constraints – when dealing with refresh tokens, as they never expire under certain circumstances. For more details, look at the documentation at https://www.keycloak.org/docs/latest/server_admin/#_offline-access.
3. When running in production, you are probably running multiple Keycloak instances in a cluster. As such, you should restart nodes sequentially to avoid any data loss. Session state is distributed across a well-defined number of nodes and if all these nodes are abruptly killed, then sessions might be lost. Keycloak also allows you to keep session state outside the cluster by using a separate Infinispan server. However, this capability was originally designed for enabling clustering across multiple data centers but can be extended accordingly to support a single data center.
4. Whenever the user is authenticating using a client, a session is created. The only scenario that sessions are not created is when clients are obtaining tokens on their own behalf using the client credentials grant. In this case, there is no refresh token – therefore no user and client session – but the possibility to obtain fresh tokens through re-authentication.

Chapter 13

1. In Keycloak's code base, SPIs are organized into two main modules, the keycloak-server-spi and keycloak-server-spi-private modules. Public SPIs are located at the keycloak-server-spi module and Keycloak does its best to keep their interfaces backward compatible between releases. These SPIs are also usually documented. On the other hand, private SPIs are not supported in terms of backward compatibility and they usually lack documentation. As a rule of thumb, consider first looking at the SPIs available from the documentation, as they are usually what Keycloak expects people to use for extending the server.
2. There is no specific documentation for these two interfaces, just their Javadoc. The Keycloak team is working to improve this area.
3. This depends on the SPI you need to extend. As you learned from this chapter, in order to extend Keycloak themes, a basic CSS, JavaScript, and HTML background is more than enough. Other SPIs allow their capabilities to be customized through JavaScript. This is especially true for authenticators and protocol mappers. For further details, review the documentation at https://www.keycloak.org/docs/latest/server_development/#_script_providers. However, for other forms of customization, you will require a basic background in Java.

Chapter 14

1. There is no such thing as perfectly secure software, and mistakes are frequently made. Luckily, both the Keycloak team and its community are continuously looking for vulnerabilities and are continuously fixing any issues they find. If you don't update Keycloak, you will not receive these fixes, but anyone wanting to attack your Keycloak server will.
2. Keycloak stores a lot of sensitive data in the database, which is valuable information to an attacker. If an attacker gains write access to the database, the attacker can make changes that could allow the attacker to gain access to any application secured by Keycloak.
3. No; only relying on a web application firewall is not a good idea. You will want to enable strong authentication, as well as provide a good level of security within the application itself.