Leveraging JWT for tokens

Keycloak has leveraged JWT as the format for access tokens from the very beginning of the project. This was a very conscious decision for interoperability as well as performance reasons.

Using a standard format, which is relatively easily consumable, makes it easier to integrate with Keycloak. As JWT is based on JSON, it can also easily be parsed and understood in any programming language.

In addition, as the resource servers are now able to directly read the value of the access token, they do not always have to make a request to the OAuth 2.0 token introspection endpoint, or the OpenID Connect UserInfo endpoint. This potentially eliminates two additional requests to Keycloak for a request to the resource server, reducing latency as well as significantly reducing the number of requests to Keycloak.

JWT comes from a family of specifications known as JOSE, which stands for JavaScript Object Signing and Encryption. The related specifications are as follows:

• JSON...

3 Brief Introduction to Standards

Join our book community on Discord

https://packt.link/SecNet

In this chapter, you will get a brief introduction to the standards that enable you to integrate your applications securely and easily with Keycloak. We very briefly cover OAuth 2.0, OpenID Connect, JSON Web Tokens (JWT), and SAML 2.0. If you are new to these standards, this chapter will give you a gentle introduction without going too much into detail. Even if you are fairly familiar with these standards, you may still want to skim through this chapter.

By the end of this chapter, you will have a basic understanding of OAuth 2.0, OpenID Connect, JWT, and SAML 2.0, along with a decent understanding of what these standards can offer you.

In this chapter, we're going to cover the following main topics:

• Authorizing application access with OAuth 2.0
• Authenticating users with OpenID Connect
• Leveraging JWT for tokens
• Understanding why SAML 2.0 is still relevant

Authorizing application...

Summary

In this chapter, you learned how to use OAuth 2.0 to provide your applications, as well as third-party applications, with access to services without exposing credentials, as well as only giving applications exactly what access they need. You also learned how OpenID Connect can be leveraged for single sign-on to your applications, as well as allowing external users to access your applications. Finally, you learned how SAML 2.0 is still an important standard that you should be aware of, even though you may not want to choose it for your own applications.

In the next chapter, you will get a deeper understanding of OAuth 2.0 with a practical guide on how you can use Keycloak to leverage this standard in your applications.

Questions

1. How does OAuth 2.0 allow an application to access resources provided by a different application without asking for the user's username and password?
2. What does OpenID Connect add to OAuth 2.0?
3. What does JWT add to OAuth 2.0?

Authenticating a user

The most common way to authenticate a user with Keycloak is through the OpenID Connect authorization code flow.

In summary, to authenticate a user with this flow, an application redirects to Keycloak, which displays a login page to authenticate the user. After the user has authenticated, the application receives an ID token, which contains information about the user.

In the following diagram, the authorization code flow is shown in more detail:

Figure 4.3: The authorization code flow

The steps from the diagram are explained in more detail as follows:

1. The user clicks on a login button in the application.
2. The application generates an authentication request.
3. The authentication request is sent to the user in form of a 302 redirect, instructing the user-agent to redirect to the authorization endpoint provided by Keycloak.
4. The user-agent opens the authorization endpoint with the query parameters specified by the application...

Understanding the ID token

In the previous section, you received a token response, including an ID token from Keycloak, but we didn’t take a good look at what’s inside the ID token.

The ID token is by default a signed JSON Web Token (JWT), which follows this format:

<Header>.<Payload>.<Signature>

The header and the payload are Base64 URL-encoded JSON documents.

If you take a look at the Token Response in the playground application, you can see the ID token in its encoded format. An example of the encoded ID token is also shown in the following screenshot from the playground application:

Figure 4.7: Encoded ID token

Under the ID Token section, you will see the decoded token broken into three parts. The header tells you what algorithm is used, the type of the payload, and the key ID of the key that was used to sign the token.

An example of a decoded ID Token is shown in the following screenshot from the playground application...

Invoking the UserInfo endpoint

In addition to being able to find information about the authenticated user from the ID token, it is also possible to invoke the UserInfo endpoint with an access token obtained through an OIDC flow.

Let’s try this out by opening the playground application. You may at this point have to send new authentication and token requests, as it may be that your SSO session has expired.

If you’re a quick reader (or you obtained new tokens), then click on 5 – UserInfo. Under UserInfo Request, you will see that the playground application is sending a request to the Keycloak UserInfo endpoint, including the access token in the authorization header.

The following screenshot from the playground application shows an example UserInfo Request:

Figure 4.11: UserInfo request

Under UserInfo Response you will see the response Keycloak sent. You may notice that this does not have all the additional fields in the ID token, but rather...

Dealing with users logging out

Dealing with logout in an SSO experience can actually be a quite difficult task, especially if you want an instant logout of all applications a user is using.

Initiating the logout

A logout can, for example, be initiated by the user by clicking on a logout button in the application. When the logout button is clicked, the application would send a request to the OpenID Connect RP-Initiated logout.

The application redirects the user to the Keycloak End Session endpoint, which is registered in the OpenID Provider Metadata as end_session_endpoint. The endpoint takes the following parameters:

• id_token_hint: A previously issued ID token. This token is used by Keycloak to identify the client that is logging out, the user, as well as the session that the client wants to log out of.
• post_logout_redirect_uri: If the client wants Keycloak to redirect back to it after the logout, it can pass the URL to Keycloak. The client has to previously...

Summary

In this chapter, you experienced first-hand the interactions in an OIDC authentication flow. You learned how the application prepares an authentication request and then redirects the user-agent to the Keycloak authorization endpoint for authentication. Then you learned how the application obtains an authorization code, which it exchanges for an ID token. By inspecting the ID token, you then learned how an application can find out information about the authenticated users. You also learned how to leverage client scopes and protocol mappers in Keycloak to add additional information about users. Finally, you learned how to deal with not only single sign-on, but also single sign-out.

You should now have a basic understanding of OpenID Connect and how it can be used to secure your own applications. We will build on this knowledge later in the book to get you ready to start securing all your applications with Keycloak.

In the next chapter, you will get a deeper understanding...

Questions

1. How does the OpenID Connect Discovery specification make it easier for you to switch between different OpenID Providers?
2. How does an application discover information about the authenticated user?
3. How do you add additional information about the authenticated user?

Further reading

Refer to the following links for more information on topics covered in this chapter:

• OpenID Connect Core specification: https://openid.net/specs/openid-connect-core-1_0.html
• OpenID Connect Discovery specification: https://openid.net/specs/openid-connect-discovery-1_0.html
• OpenID Connect Session Management specification: https://openid.net/specs/openid-connect-session-1_0.html
• OpenID Connect Back-Channel Logout specification: https://openid.net/specs/openid-connect-backchannel-1_0.html

Join our community on Discord

Join our community’s Discord space for discussions with the authors and other readers:

https://packt.link/SecNet