Securing Microservices with Keycloak
**Promotion** - Efficiently manage your coding bookmarks, aka #codingmarks, on www.codingmarks.org and share your hidden gems with the world. They will be published weekly on Github. Please help us build THE programming-resources location - Star
In a traditional multi-tiered architecture like the one shown in the picture below a server-side web tier deals with authenticating the user by calling out to a relational database or an LDAP server. An HTTP session is then created containing the required authentication and user details. The security context is propagated between the tiers within the application server so there’s no need to re-authenticate the user.
With a microservice architecture the server-side web application is gone, instead we have HTML5 and mobile applications on the client side. The applications invoke multiple services, which may in turn call other services. In this architecture there’s no longer a single layer that can deal with authentication and usually it’s stateless as well so there’s no HTTP session.
As microservices is all about having many smaller services each that deal with one distinct task the obvious solution to security is an authentication and authorization service. This is where Keycloak and OpenID Connect comes to the rescue. Keycloak provides the service you need to secure micro services.
In an HTML5 application you just need to add a login button and that’s pretty much it. When the user clicks the login button the users browser is redirected to the login screen on the Keycloak server. The user then authenticates with the Keycloak server. As the authentication is done by the Keycloak server and not your application it’s easy to add support for multi-factor authentication or social logins without having to change anything in your application.
Once the user is authenticated, Keycloak gives the application a token. The token contains details about the user as well as permissions the user has.
The second step in securing micro services is to secure them. Again, with Keycloak this is easy to do with our adapters. We’ve got JavaEE adapters, NodeJS adapters and are planning to adding more in the future. If we don’t have an adapter it’s also relatively easy to verify the tokens yourself. A token is basically just a signed JSON document and can be verified by the services itself or by invoking the Keycloak server.
If a service needs to invoke another service it can pass on the token it received, which will invoke the other service with the users permissions. Soon we’ll add support for services to authenticate directly with Keycloak to be able to invoke other services with their own permissions, not just on behalf of users.
For more details about OpenID Connect you can look at the OpenID Connect website, but the nice thing is with Keycloak you don’t really need to know the low level details so it’s completely optional. As an alternative just go straight to the Keycloak website, download the server and adapters, and check out our documentation and many examples.