我在一家支持许多应用程序的公司工作，但是对于用户而言，有一个OAuth OIDC单签名（IdentityServer4），因此他们可以登录一次并访问我们的许多应用程序。使用返回的JWT/Access令牌配置此OAuth的授权，我没有问题。
但是，由于我们的支持足迹是如此之大，所以我们被告知要处理角色以及应用程序级别的用户权限。这是我要反馈的地方。我目前正在.NET Core 6（构建API的新手）中开发新的API，并且想知道连接基本第三方Oauth的最佳实践，但也利用了该应用程序特定的角色和权限。
Identity Server返回以承载形式传递给API的JWT/Access令牌，但是我需要在.NET Core后端上映射一个映射，以映射应用程序中的用户在JWT中包含的用户。然后，该应用程序可以为角色/权限提供单独的映射，并利用这些角色作为API内的限制，但是我不确定哪种最佳实践对此也可以保持最佳安全性，同时也可以实现最佳性能。我的想法是创建一种创造和覆盖用户识别的中间件，但是随之而来的每个呼叫似乎都是不必要的开销。另一个选项是与基于cookie的auth的双重验证，但不确定最好的方法或其他人成功的方法。我知道这一定是我过度思考的常见流程。任何洞察力都将不胜感激。
I work for a company that supports many applications, but for ease for users has an OAuth OIDC Single-Sign-On (IdentityServer4) so they can log in once and access many applications of ours. I have no problem configuring authorization to this OAuth with the returned JWT/Access Token.
But because our support footprint is so large, we have been told to handle roles, and user permissions at the application level. Here is where I am asking for feedback. I am currently developing a new API in .Net Core 6 (newbie to building APIs), and am wondering best practice for connecting a essentially third party OAuth, but also utilizing roles and permissions specific to the application.
The Identity Server returns a JWT/Access Token that is passed to API in form of bearer, but I need a mapping on the .net core backend to map the User contained in the JWT with a user within the application. Then the application can have separate mappings for roles/permissions, and utilize those roles as restrictions within the API, but I am not sure what best practice would be for this that also maintains the best security, while also achieving best performance. My thought was creating a middleware that creates and overrides userIdentity, but with that happening each call seems like unnecessary overhead. The other option is dual auth with cookie based auth that is set once, but am just unsure of best way, or what others have had success with. I know this must be a common flow that I am overthinking. Any insight is greatly appreciated.
发布评论
评论（1）
如您所描述的那样，在许多成熟的业务系统中很常见。有两种主要技术：
Identity System在发行时与业务数据联系起来，以获取自定义索赔，以包括在访问令牌中。此 purity actrict 解释了该方法。
API查找自定义索赔，例如，从数据库中，首次收到访问令牌时，然后使用相同访问令牌的后续请求进行缓存自定义索赔。参见我的一种方法。
在这两种情况下，最终结果都应该是API业务逻辑获得有用的索赔，该索赔能够获得正确的授权，例如此示例类别。
最后，从信息披露的角度来看，旨在避免将JWT中的详细索赔返回给互联网客户。通常使用 opaque访问代币，作为保留隐私模式。
It is common in many mature business systems to integrate identity and business data as you describe. There are two main techniques:
Identity system reaches out to business data at the time of token issuance, to get custom claims to include in access tokens. This Curity article explains the approach.
APIs look up custom claims, eg from a database, when an access token is first received, then cache custom claims for subsequent requests with the same access token. See this .NET code of mine for one way to do this.
In both cases the end result should be that the API business logic gets a useful ClaimsPrincipal that enables the correct authorization, as in this example class.
Finally, from an information disclosure viewpoint, aim to avoid returning detailed claims in JWTs to internet clients. It is common to use opaque access tokens instead, as a privacy preserving pattern.