英文:
How to pass user Security Principal to backend REST APIs with using Client Credentials Flow?
问题
在我的设置中，有一个在浏览器上运行的JavaScript应用，由一个实现前端后端分离（BFF）模式的Spring WebMVC应用提供服务。用户访问令牌存储在BFF服务器的会话对象中。BFF通过客户端凭证流调用后端REST API服务器。用户由Auth0身份提供者进行身份验证。我们还使用Auth0提供客户端凭证流的凭据。当BFF启动时，它调用Auth0并获取访问令牌以在REST API中使用。每当BFF发出对REST服务器的REST调用时，它会传递访问令牌。一切都正常工作。
然而，REST API不使用安全主体，因此我们无法基于安全主体实现访问控制。我希望能够使用 @PreAuthorize 注解来确保正在更新的实体由安全主体拥有（假设我要保护的每个实体都有一个字段 "ownerid"）。
我希望BFF在其访问令牌一起传递有关经过身份验证的用户的一些信息。并且我希望为此执行上下文实例化一个安全主体，以便 @PreAuthorize 注解可以使用这些信息。
英文:
In my setup, there is a JavaScript app running on browser that is served by a Spring WebMVC application , which implements the backend for front end (BFF) pattern. The user access token is stored in the BFF server Session object. The BFF invokes REST APIs on the backed REST API servers using the client credentials flow . The user is authenticated by Auth0 iDP. We are also using Auth0 for providing credentials for client-credentials-flow. When the BFF starts up, it calls the Auth0 and gets access token to use with the REST API. Whenever the BFF makes an rest call into the REST Server, it passes the access token. Everything is working fine.
However, the REST APIs do not use Security Principal and hence we are not able to implement access control based on the security principal. I want to be able to use @PreAuthorize annotation to ensure that the entity that is being updated is owned by the Security principal. (assume every entity that I want to protect as a field "ownerid").
I want the BFF to pass some information about the authenticated user along with its access token. And I want to instantiate a Security principal for this execution context so that the @PreAuthorize annotations could use this information.
答案1
得分: 1
你的最好朋友应该将用户级令牌传递给 REST API。这样做可以安全、可验证和可审计地传递用户身份。
API 应以与当前相同的方式处理令牌。根据您的偏好，可以使用各种编码技术来提取主体。
如果 BFF 发送由客户端凭证流获得的单独令牌，则需要通过单独的普通 HTTP 标头传递用户 ID/主题。这不是一个好的安全实践，例如中间人可能会将其更改为不同的用户。
如果 API 拒绝令牌，也许可以回传拒绝的原因。例如，也许 API 基于其受众声明值拒绝访问令牌，或者缺少必需的范围。
OAuth UI 和 API 流程应以端到端的方式设计，客户端应被赋予提供对一个或多个 API 访问权限的范围，同时安全地传递用户身份。
客户端凭证流最适用于由机器启动的端到端流程。一个例子可能是每晚的批处理作业。
英文:
Your BFF should forward the user level token to the REST APIs. Doing so flows the user identity securely, and in a verifiable and auditable way.
The API should process the token in the same way as currently. Various coding techniques could be used to pull out the principal, according to your preferences.
If the BFF sends a separate token obtained by the client credentials flow, it would need to pass the user ID / subject in a separate plain HTTP header. This is not a good security practice, eg a man in the middle could potentially change it to a different user.
If the API rejects the token, perhaps post back on the reason why. Eg maybe the API is rejecting the access token based on its audience claim value, or a required scope is missing.
OAuth UI and API flows should be designed in an end-to-end manner, where the client is given scopes that provide access to one or more APIs, while flowing the user identity securely.
The client credentials flow is best used for machine initiated end-to-end processes. One example might be a nightly batch job.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论