<div dir="ltr">Hi,<div><br><div>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.</div><div><br></div><div>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&#39;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).</div></div><div><br></div><div>Firstly, does this seem like a reasonable approach?</div><div><br></div><div>Secondly, how much support is there in Keycloak to support something like this? We are not using an app server, so it doesn&#39;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?</div><div><br></div><div>I noticed this on the Keycloak blog about a month ago:</div><div><br></div><div>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&#39;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.<br></div><div><br></div><div>Is there any news on these plans? It sounds like the sort of thing that we would require.</div><div><br></div><div>Cheers,</div><div>Shannon</div><div><br></div><div><br></div></div>