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 is just a simple JSON...

Dealing with users logging out

Dealing with logout in a 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 through 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 have registered the logout...

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 of OAuth...

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

Limiting the access granted to access tokens

As access tokens get passed around from the application to services, it is important to limit the access granted. Otherwise, any access token could potentially be used to access any resource the user has access to.

There are a few different strategies that can be used to limit access for a specific access token. These include the following:

• Audience: Allows listing the resource providers that should accept an access token.
• Roles: By controlling what roles a client has access to, it is possible to control what roles an application can access on behalf of the user.
• Scope: In Keycloak, scopes are created through client scopes, and an application can only have access to a specific list of scopes. Furthermore, when applications require consent, the user must also grant access to the scope.

Let’s go through these one at a time and see exactly how this can be done with Keycloak, starting with the audience...

Validating access tokens

You have two choices to validate an access token, either by invoking the token introspection endpoint provided by Keycloak or by directly verifying the token.

Using the token introspection endpoint is the simplest approach, and it also makes your applications less tied to Keycloak being the authorization server. OAuth 2.0 does not define a standard format for access tokens and these should be considered opaque to the application. Instead, it defines a standard token introspection endpoint that can be used to query the authorization server for the state of a token as well as claims associated with the token. This also enables tokens to not be self-contained, meaning that not all relevant information about the token is encoded into the token, but rather the token only serves as a reference to the information.

One downside of using the token introspection endpoint is that it introduces extra latency in processing the request as well as additional load...

Summary

In this chapter, you experienced first-hand how to obtain access tokens using the OAuth 2.0 Authorization Code grant type. You learned how an admin can grant access to internal applications on behalf of a user, and how users themselves can grant access to third-party applications. You learned about various techniques for how you can limit the access provided by a specific access token. Finally, you learned how a service can directly read and understand the contents of an access token issued by Keycloak, as it is using JWT-based tokens. You also learned how the token introspection endpoint can be leveraged to validate and discover information about an access token in a more standard and portable way.

You should now have a basic understanding of OAuth 2.0 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 learn about...

Questions

1. How does an application invoke a protected REST API by leveraging OAuth 2.0?
2. What are the three different techniques you can use to limit the access provided by an access token?
3. How can a service validate an access token to decide whether permission should be granted?

Further reading

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

• OAuth 2.0 Authorization Code grant specification: https://oauth.net/2/grant-types/authorization-code/
• OAuth 2.0 token introspection specification: https://oauth.net/2/token-introspection/
• OAuth scopes: https://oauth.net/2/scope/

Join our community on Discord

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

https://packt.link/SecNet