Understanding internal and external applications

When securing an application, the first thing to consider is whether the application is an internal application or an external application.

Internal applications, sometimes referred to as first-party applications, are applications owned by the enterprise. It does not matter who developed the application, nor does it matter how it is hosted. The application could be an off-the-shelf application, and it can also be a Software as a Service (SaaS)-hosted application, while still being considered an internal application.

For an internal application, there is no need to ask the user to grant access to the application when authenticating to the user, as this application is trusted and the administrator that registered the application with Keycloak can pre-approve the access on behalf of the user. In Keycloak, this is done by turning off the Consent Required option for the client, as shown in the following screenshot:

Figure 6.1 – Internal...

Securing web applications

When securing a web application with Keycloak, the first thing you should consider is the architecture of the application as there are multiple approaches:

• First and foremost, is your web application a traditional web application running on the server side or a modern single-page application (SPA) running in the browser?
• The second thing to consider is whether the application is accessing any REST APIs, and if so, are the REST APIs a part of the application or external?

If it is a SPA-type application invoking external APIs, then there are two further options to consider. Does the application invoke the external REST API directly, or through a dedicated REST API hosted alongside the application?

Based on this, you should determine which of the following matches the architecture of the application you are securing:

• Server side: If the web application is running inside a web server or an application server.
• SPA with dedicated REST API: If the application is...

Securing native and mobile applications

Securing a web application with Keycloak is more straightforward than securing a native or mobile application. Keycloak login pages are essentially a web application and it is more natural to redirect a user to a different web application when they are already within the browser.

You may be tempted to implement login pages within the application itself to collect the username and password, then leverage the OAuth 2.0 Resource Owner Password Credential grant to obtain tokens. However, this is simply something that you should not be tempted to do. As mentioned in the previous section, applications should never have direct access to the user credentials, and this approach also means you miss out on a lot of features provided by Keycloak.

To secure a native or mobile application, you should use the Authorization Code flow with the PKCE extension instead. This is more secure, and at the same time gives you the full benefits of using Keycloak.

Effectively...

Securing REST APIs and services

When an application wants to invoke a REST API protected by Keycloak, it first obtains an access token from Keycloak, then includes the access token in the authorization header in requests it sends to the REST API:

Authorization: bearer eyJhbGciOiJSUzI1NiIsInR5c…

The REST API can then verify the access token to decide whether access should be granted.

This approach makes it easy to provide a REST API that can be leveraged by many applications, even making the REST API available as a public API on the internet for third-party applications to consume.

In Chapter 5, Authorizing Access with OAuth 2.0, we covered how the application obtains an access token from Keycloak, then includes the access token in requests it makes to REST APIs so that the REST API can verify whether access should be granted. We also covered various strategies for limiting the access provided by a specific access token, as well as how an access token is verified by the REST API...

Summary

In this chapter, you learned the difference between an internal and an external application, where external applications require asking the user for consent to grant access, while internal applications do not. You then learned how different web application architectures are secured with Keycloak, and why it is more secure to have a backend for a SPA that obtains tokens from Keycloak, instead of directly obtaining tokens in the SPA itself. You then learned how Keycloak can be used to secure other types of applications, such as native and mobile applications. Finally, you learned that bearer tokens can be used to secure a range of different services, including REST APIs, microservices, gRPC, WebSockets, and a range of other protocols.

You should now have a good understanding of the principles and best practices for securing your application with Keycloak. In the next chapter, we will look at what options are available to integrate all your applications with Keycloak.

Questions

1. What is the best way to secure the invocations from a SPA to a REST API?
2. Can OAuth 2.0 and bearer tokens only be used to secure web applications and REST APIs?
3. How should you secure a native or mobile application with Keycloak?

Further reading

For more information on the topics covered in this chapter, refer to the following links:

• OAuth 2.0 for browser-based apps: https://oauth.net/2/browser-based-apps/
• OAuth 2.0 for mobile and native apps: https://oauth.net/2/native-apps/
• AppAuth: https://appauth.io/

Integrating with Node.js applications

For Node.js applications, Keycloak provides a specific adapter called the Keycloak Node.js adapter. Like other adapters, it is targeted to integrate with Keycloak rather than a generic OpenID Connect client implementation.

The Keycloak Node.js adapter hides most of the internals from your application through a simple API that you can use to protect your application resources. The adapter is available as an npm package and can be installed into your project as follows:

$ npm install keycloak-connect

The code examples for this section are available from the following GitHub repository:

$ cd Keycloak---Identity-and-Access-Management-for-Modern-Applications-2nd-Edition/ch7/nodejs

In the preceding directory, you will find a frontend directory and a backend directory, which contain all the code you’ll need to follow and run the following examples.

Now that you have installed the keycloak-connect dependency in your application...

Using a reverse proxy

By running Keycloak in front of your application, you can use reverse proxies to add additional capabilities to your application. The most common proxies provide support for OpenID Connect where enabling authentication is a matter of changing the proxy configuration.

Whether using a proxy is better than having the integration code and configuration within your application really depends on the use case and, depending on the circumstances, it might be your only option or the option that will save you precious time from implementing your own integration code, even if you have a library available for the technology stack your application is using.

Nowadays, OpenID Connect and OAuth2 support is a mandatory capability for proxies, and you find support for these protocols in most of them, regardless of whether they’re open source or proprietary. As an example, two of the most popular proxies, Apache HTTP Server and Nginx, provide the necessary extensions...

Try not to implement your own integration

OAuth2 and OpenID Connect are simple protocols, and their simplicity is, in part, due to the effort that’s been made to make the protocol easier to use by client applications, but not necessarily to implement them from scratch. You may feel tempted to write your own code to integrate with Keycloak, but this is usually a bad choice.

You should rely on well-known and widely used libraries, frameworks, or capabilities provided by the platform where your application is deployed.

By doing that, you can focus on your business and, most importantly, delegate to people who are specialized and focused on these standards to keep their implementations always up to date with the latest versions of the specifications, as well as with any fixes for security vulnerabilities and security best practices.

Also, remember that the more people there are using an implementation, the less likely it is that you will face bugs and security vulnerabilities...

Summary

In this chapter, you learned how to integrate Keycloak with different types of applications, depending on the technology stack they are using, as well as the platform they are running. You also learned about the importance of using well-known and established open standards and what that means in terms of interoperability. This means you are free to choose the OpenID Connect client implementation that best serves your needs, while still respecting compliance and keeping your applications up to date with the OAuth2 and OpenID Connect best practices and security fixes.

Finally, you learned why you should avoid implementing your own integration, as well as the things you should consider when you’re looking for alternatives if none of the other options work for you.

In the next chapter, you will learn about the different authorization strategies you can use to protect your application resources.

Questions

1. What is the best way to integrate with Keycloak?
2. Should I always consider using the Keycloak adapters if they fit into my technology stack?
3. How should you secure a native or mobile application with Keycloak?
4. What is the best integration option for cloud-native applications?

Further reading

For more information on the topics that were covered in this chapter, please refer to the following links:

• Certified OpenID Connect Implementations: https://openid.net/developers/certified
• OAuth 2.0 for Browser-Based Apps: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07
• OAuth 2.0 Security Best Current Practice: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16
• Keycloak Quickstarts: https://github.com/keycloak/keycloak-quickstarts
• Securing Applications and Services Guide: https://www.keycloak.org/docs/latest/securing_apps

Join our community on Discord

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

https://packt.link/SecNet