Hi, we are currently struggling to find an elegant solution for the following problem. We have a system consisting of a bunch of microservices. The UI interacts with the system using an API Gateway. Authenticating the user is done via OAuth using the password grant and probably using the implicit grant in the future. While we initially planned to store user roles in each microservice, we changed that approach to go for the token based approach used by keycloak, i.e., we use the roles present in the access token to determine the role of the user for a request. So far so good, authentication works like a breeze and keycloak is also easy to use and looks great. However, besides the user facing processes (i.e. the user actually interacting with the system via the UI), we also have offline processes. E.g., a reporting service that needs to access data in other services in order to generate a report once a day or a week. In these offline service-to-service requests, we want to be able to enforce the same set of access rules as for normal requests directly triggered by the user. In other words, the reporting service would need an access token for the user that contains the roles of the user. In order to obtain that access token, however, either the user would need to be involved or we would need a refresh token. Involving the user in a process that takes place in the middle of the night is obviously not a viable solution, so I think we need to authorize the user once somehow. But we are actually not sure how to best do this. In an enterprise application it would be a bit uncommon to pop up a "Please authorize Service X to access Service Y" window, when the user doesn't really care about what services are involved. Furthermore, it's also not absolutely clear how to best integrate this into a UI anyway. So we are actually wondering, if this is right path anyway. How are such cases are usually handled using keycloak? Is there a pattern or any best practice? Am I completely on the wrong road and need to do something completely different? Are there any plans to extend keycloak with functionality that would ease such scenarios? One idea we had was to allow for direct token generation of backend services via some API and the means to configure what tokens and roles are allowed by a service. In our problem above, I could imagine that in keycloak there would be the possibility to allow the report service to generate tokens with the GUEST role for all users for the data service. Independently of the real role of the user, a token generated by that means would only allow access with GUEST rights. Furthermore, the report service would not be able to generate tokens for any other services on its own. That would obviously be outside of OAuth and probably it should be required to enable this feature explicitly, but I would greatly ease such scenarios. Specifically, it would help in setting up a system such that is secure without requiring the user to perform explicit grants for services he shouldn't even know about. Thanks and best regards Carsten -------------------------------------------------------------------------------------------------------------------------------------------- Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff(a)kisters.de | WWW: http://www.kisters.de -------------------------------------------------------------------------------------------------------------------------------------------- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.