Re: [keycloak-user] Keycloak suitability in microservice-based platform

Hi, We are evaluating Keycloak for possible use in a microservices-based SaaS platform that we are building, and I have a few questions around the suitability of Keycloak within the architecture that we are planning on using. Briefly, we will have a handful of end-user applications with their own UIs and a large number of backend services with which those UIs will speak. Some of those services will act as aggregating/gateway services which will delegate to other services further downstream, so there will be a lot of service-to-service comms. Our design currently calls for each logical application (i.e. a UI plus a handful of supporting services) to have its own set of roles that make sense within the context of that application. Because many/most roles will only make sense in that one context, it does not make sense for a user's token to contain all possible roles across the entire realm (the tokens would be insanely large). We came up with the idea of having an authentication/identity token (containing no application-specific roles) to represent the logged in user, and then passing this token to downstream services which would then (e.g. via a filter in front of that service) retrieve and cache application-specific tokens (with roles) from the SSO service for that combination of authenticated identity and application/client (relying on the fact that the identity token is valid and not expired as proof of an active session).

Firstly, does this seem like a reasonable approach? Secondly, how much support is there in Keycloak to support something like this? We are not using an app server, so it doesn't appear to be a simple case of leveraging one of the existing adapters. We have a custom Java(-SE)-based framework (happens to use Undertow for HTTP, but only undertow-core). What support exists for custom, programmatic authentication and JWT retrieval outside of the set of adapters provided in the Keycloak distribution? Are there any examples along these lines? Is it a case of us needing to trawl through all the REST endpoints exposed via keycloak-services to figure out what is do-able, or are the non-admin endpoints documented somewhere in the same way that the admin endpoints have been documented?

I noticed this on the Keycloak blog about a month ago: 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.