ASP.NET Identity与Duende Identity Server角色关联ApiScope存储方案咨询

你的自定义表方案可行，但存在明显的冗余问题：Permission列存储的内容（如api1.read）和ApiScope表中的Name字段完全重复，一旦ApiScope的名称需要修改，你必须同步更新这个表的Permission值，很容易引发数据不一致的问题。

更优方案一：简化关联表结构 #

直接去掉冗余的Permission列，只保留RoleId和ScopeId两个字段，通过ScopeId关联到ApiScope表获取对应的权限标识。表结构如下：

--------------------------------------
| RoleID | ScopeID |
--------------------------------------
|   1    |    1    |  -- 对应ApiScope表中ID=1的api1.read
|   1    |    2    |  -- 对应ApiScope表中ID=2的api2.write
|   2    |    1    |  -- 对应ApiScope表中ID=1的api1.read
|   2    |    3    |  -- 对应ApiScope表中ID=3的api3.write
--------------------------------------

这种方式既保留了角色与ApiScope的关联关系，又消除了数据冗余，降低了维护成本。

更优方案二：复用ASP.NET Identity的角色声明机制 #

不需要新建自定义表，直接利用ASP.NET Identity原生的AspNetRoleClaims表，给角色添加类型为scope的声明，值为对应的ApiScope名称（如api1.read）。Duende Identity Server可以直接识别这类声明，在颁发访问令牌时自动将其包含到令牌的scope字段中。

示例代码：

// 给指定角色添加ApiScope权限声明
var role = await _roleManager.FindByIdAsync("1");
await _roleManager.AddClaimAsync(role, new Claim("scope", "api1.read"));
await _roleManager.AddClaimAsync(role, new Claim("scope", "api2.write"));

这种方案的优势是完全贴合框架原生设计，不需要维护额外的表结构，后续扩展或修改权限时直接操作角色声明即可，更符合Identity和Duende的生态设计。

方案选择建议 #

• 如果需要在数据库层面直观展示角色与ApiScope的关联关系，优先选择简化后的关联表方案；
• 如果想减少自定义代码和表结构的维护工作，优先选择角色声明方案，这也是Duende Identity Server推荐的权限关联方式。

内容的提问来源于stack exchange，提问作者xxxyyy