Keycloak with Microfrontends

Question

Given the shown architecture:

• MFE = Microfrontend
• SPA = Javascript browser app
• API-Gateway = Session to Token translation

Is it possible via Oauth2, that the user grants consent for the pizza ordering to send him notifications, but not for the kebap ordering?

My thoughts so far, solving the problem in "Oauth" space: Register a keycloak confidential client for each microservice (=oauth2 client) and allow the user (resource owner) to give consent accessing the notification service (scope / resource server) to each client individually.

But registering multiple clients for a single SPA seems very odd to me... Also, the backend would need to persist if the user gave consent and if so, attach optional scopes when requesting the token.

Is this the solution to go or are there better ways to accomplish the requirement?

EDIT: Additional note: The pizza ordering and kebap ordering system might be provided by external companies, so we prefer not to "trust them that they behave properly", but to technically enforce that they only send notifications if the user agreed.

(Please let's forget the situation that the kebap client could call the pizza-api ... ;)

Answer 1

CONSENT

The user should only consent when their personal assets are involved. Eg the app can use my email but not my home address. Permissions to send notifications are just preferences - manage them within the app - eg via a complete your profile workflow after the initial login.

SCOPE

Permissions to your app's own data are a different concept. The best practice is to manage them via scopes and claims rather than consent.

The scope best practices article may be useful to you here. It explains how a single client can use multiple types of data.

It also describes how microservices can call each other if needed, while securely maintaining the user identity. UIs and APIs will not always have a 1 to 1 mapping.

YOUR EXAMPLE

I think the user could consent to use of the email scope, to grant access to their email inbox. Then manage finer details via some kind of settings screen within the app.

Then it is your backend's responsibility to manage data connections and access. Scopes are useful for cross component calls, though I would avoid a scope for each type of food. Partner connections will each use their own mechanism, but you don't need to involve the user in that.