英文:
How to include custom claims from my db into JWT issued by ADB2C?
问题
我们有一个情况，我们在我们的数据库中维护了访问控制列表。它是可配置的，并且经常更改。
我想在adb2c签入期间，将用户可以访问的内容包含在JWT中。
我看到有扩展可以在签入期间调用我的API端点以获取自定义声明，但是有两个问题我没有找到解决方案：
-
文档说声明必须在adb2c中先定义，这意味着我不能添加新的声明，除非我先将它们添加到adb2c中。
-
声明扩展API调用仅在初始签入时有效，而不适用于使用刷新令牌获取新的JWT。
我是否遗漏了什么，或者是否有其他方法可以实现这一点？
英文:
We have a situation where we have access control list maintained in our database. Its configurable and changes on a regular basis.
I want to include things that user can access into JWT issued by adb2c during the sign in.
I see there are extensions where adb2c can call my api endpoint for custom claims during the sign in, but there are 2 issues i dont see a solution for:
-
docs say that claims must be defined before in adb2c meaning i cannot add new claims unless i added them into adb2c first
-
claims extension api calls work only on initial sign in and not on getting new jwt using refresh token.
Am i missing something or is there some other way of achieving this?
答案1
得分: 1
> 1. 文档中提到，在 adb2c 中，声明必须在之前定义，这意味着我不能添加新的声明，除非我先将它们添加到 adb2c 中。
是的，如果你正在使用用户流程（user flows），声明必须是内置声明或者你已经添加的自定义属性，并且必须在用户流程的应用声明配置中选择它。
如果你正在使用自定义策略（custom policies），那么声明只需要在你的自定义策略中定义，不需要将其创建为自定义属性。
重要提示：这里讨论的是在令牌中保存值的声明，而不是声明中的个别值。所以，如果你有一个包含 admin 和 user 的 ACL，并且你想将其作为字符串包含在令牌中，你可以添加一个 acl 的自定义属性，并让你的 API 填充它；如果以后添加了另一个值（比如 superuser），你不需要在 B2C 中做任何更改，因为它只是映射到现有的 acl 声明的另一个值。
> 2. 声明扩展 API 调用只在初始登录时有效，而在使用刷新令牌获取新的 JWT 时无效。
对于用户流程来说，是的，它们只会提供原始令牌的刷新版本（即更新时间戳）。
然而，自定义策略支持自定义刷新令牌流程，因此每次刷新令牌时都可以重新读取 ACL，并在新的令牌中返回最新的值。
如果需要在刷新令牌时更新令牌内容，你将需要使用自定义策略。有关两者之间的区别，请参阅Microsoft 文档。
英文:
> 1. docs say that claims must be defined before in adb2c meaning i cannot add new claims unless i added them into adb2c first
That's right, if you're using user flows the claim must be either a built-in claim or a custom attribute you've added, and it must be selected in the Application claims configuration of the user flow.
If you're using custom policies then the claim must just be defined in your custom policy, you don't need to create it as a custom attribute as well.
Important this is talking about the claim that will hold your value in the token rather than individual values within the claim. So if you had an ACL that contained admin and user and you wanted to include that in the token as a string, you could add an acl custom attribute and have your API populate that; if you later added another value (say, superuser) you wouldn't need to change anything in B2C because it would just be another value mapped to your existing acl claim.
> 2. claims extension api calls work only on initial sign in and not on getting new jwt using refresh token.
For user flows that's right, they will only provide your with a refreshed version (i.e. timestamps updated) of the originally issued token.
Custom policies however support custom refresh token journeys so you can have the ACL re-read each time a token is refreshed and up-to-date values returned in the new token.
If you need the token contents to be updated when refreshed then you'll have to use custom policies. See the Microsoft docs for more info about the differences between the two.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论