How to do "faster acess" to user rights using stateless API and OIDC protocol

42 Views Asked by At

TL;DR

I don't know the best practise(s) to include user rights inside OIDC protocol to ensure that my REST API is stateless as much as possible.

Technologies context

A single page application (also called SPA) is communicating with REST API (Quarkus behind) via the OIDC protocol (Keycloak used). Keycloak is used for OIDC support but also for as Identity provider. Therefore, no user data (such as roles or rights) are stored within application database.

Project context

The project is Jira like, each user can administrate, edit, view from zero to infinite projects. Role is only used for application admin and application user. For the admin, project rights ar not checked as the application admin can administrate, edit, view all projects of the applications (same way as GitLab for example). But for user application, rights must be check for each resource calls to identify whether it can administrate, edit, view, belong to the requested project.

Actual issue

Although the user role(s) can be easily be set using Keycloak administration interface and append to access token, the right management is a little trickier. In mind of stateless, is it mandatary to transfer the rights using OIDC protocol (by extension Keycloak instance) or must be checked within the application database while accessing resource via REST API?

Points to be noted

  1. I already looked for custom mapper using Keycloak SDK to add dynamic custom claims (rights : ) but the cons are that if the user rights are changed, the access token may not reflecting it unless the token is refreshed (https://www.baeldung.com/keycloak-custom-protocol-mapper). Besides this try, I do not know if this approach is a bad or best practise.
  2. User rights could be cached, but terms of scalability and memory consumption it should be avoid for an application managing a big amount of user/rights
  3. I am trying to develop a REST API as much as possible stateless, therefore having the role and rights inside request (using OIDC protocol) will be a nice to have but this criteria can be neglected to use OIDC. So, the request will be done by an authenticated “who” and application will check (inside resource) whether the authenticated “who” has right to access further more to the resource by accessing rights within application database
  4. I was/am looking for a lot of documentation about OIDC flow and so on. None actually talk about this kind of scenario, which I think, may point that this is not the right approach.
0

There are 0 best solutions below