KeyCloak带有微额定
给定显示的架构：
- mfe = microfrontend
- spa = javaScript浏览器app
- api-gateway = session tor to token translation
是否可以通过oauth2，用户授予披萨订购的用户同意，但要向他发送通知，但是 不是为了解决“ oauth”空间中的问题：
到目前为止，我的想法 我的想法： 为每个微服务（= oauth2客户端）注册一个KeyCloak机密客户端，并允许用户（资源所有者）单独访问通知服务（范围 /资源服务器）的同意。
但是为我注册多个客户端对我来说似乎很奇怪。 另外，如果用户同意并在请求令牌时附加可选示波器，则后端将需要持续存在。
这是要解决的解决方案，还是有更好的方法来满足要求？
编辑： 附加注意：外部公司可能会提供披萨订购和kebap订购系统，因此我们不希望“相信他们的行为正确”，而是从技术上讲，只有在用户同意的情况下，他们才会发送通知。
（请忘记kebap客户端可以致电Pizza-api的情况...;）
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 ... ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
同意
用户只有在涉及个人资产时才应同意。例如，该应用程序可以使用我的电子邮件，但不能使用我的家庭地址。发送通知的权限只是首选项 - 在应用程序中通过
在初始登录后完成您的个人资料工作流程。范围
对应用程序自己的数据的权限是一个不同的概念。最好的做法是通过范围和索赔而不是同意来管理它们。
范围最佳实践文章在这里可能对您有用。它解释了一个客户如何使用多种类型的数据。
它还描述了微服务在需要时如何相互调用，同时安全地维护用户身份。 UIS和API并不总是具有1到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 profileworkflow 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.