Proper design for th Keycloak auth with APIs and UI

Question

I’m developing the service with consist with two Web API apps (main and second), and two front apps (Web UI and Mobile app). I’m using the Keycloak for auth purposes (OAuth, OIDC, JWT Tokens). I wanted to define the roles in Keycloak that will be used by both front apps (Mobile app by only one role, so it has limited capabilities, but not sure if this is important). On the API side I wanted to use the API scopes and have defined mapping between roles and scopes somewhere. Also, I wanted to have 4 clients defined in Keycloak (main API-, second API-, Web UI-, Mobile-client).

Questions are:

1. Isn’t this an overkill?
2. Is that a correct way of designing auth processes?
3. Can I define the mappings between roles and API scopes in Keycloak?
4. Do I need to ask for user consent when using different Keycloak clients?
5. Should/Can API apps share the API scope? Can I have the API scope defined and this scope allow me to call endpoints form two different API apps (microservices)?

And bonus question: can you recommend me a good tutorial/book for designing the auth solutions like mentioned above?

Earlier I've read a book about the auth protocols, gone through the Keycloak documentation and bunch of different articles about auth with Keycloak but in most cases they are showing only a case with the only one client for all applications. And I'm still not sure what is the right direction.

Answer 1

Well here is the usual type of approach, to demonstrate the main relationships.

SCOPES

When getting started designing scopes, consider using them to represent business areas, eg sales. Then, use more fine grained scopes if you find a need for them, eg sales:history.

CLIENTS

By default you should only need to register 2 clients: for the web and mobile apps.

To begin with, you might register each of them with a sales scope to enable them to call sales-related APIs. If your web app supports extra areas to the mobile app, you might add extra scopes to it, eg sales:history.

ROLES

You should not try to map scopes to roles. Instead, a role is a claim within the access token that cannot be evaluated until the user authenticates. You configure each scope to contain one or more claims. Eg a sales scope could contain a role claim and result in the role value being issued to the access token.

API AUTHORIZATION

Every API endpoint should reject access tokens without its required scope. For example, one endpoint might require a sales:history scope and therefore deny access if called by the mobile client.

Ultimately, every API endpoint must enforce its authorization rules correctly. Usually this is primarily done based on the access token claims. Scopes and claims are building blocks for authorization and you can design solutions in multiple ways.