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).