【问题标题】:IdentityServer3 - Add token inside token for custom grant type (act-as schema)IdentityServer3 - 在自定义授权类型的令牌内添加令牌(充当模式)
【发布时间】:2017-03-09 12:46:02
【问题描述】:

我需要在 IdentityServer3 中的自定义授权类型的“充当”模式的令牌内添加一个令牌。 我尝试使用PreserveAccessToken,但它只是将令牌作为声明添加到当前的 ClaimsPrincipal 中,但是当获取另一个令牌传递给链中的下一个服务/api 时,找不到将其嵌套为声明的方法。

这背后的想法是能够对从最终用户到调用链中最后一个服务/api的所有跃点进行审计。

【问题讨论】:

  • 你为什么不创建一个correlationId,然后把它作为一些标题的一部分呢?
  • 因为调用链中的最后一个链接——例如一个 api——对数据库进行实际调用并尝试记录对此类操作的审核,因此应该能够提取操作starter(比如最终用户)和中间的所有服务/api,它们是操作的一部分。如果我能够让 IdSrvr 将一个令牌嵌套在另一个令牌中,那么它应该可以解决所有问题,而无需做太多额外的工作。

标签: oauth-2.0 access-token identityserver3 openid-connect


【解决方案1】:

这可以使用自定义授权来实现。这允许使用自定义“操作”扩展令牌端点 - 例如发出包含委托声明的令牌 - 例如一个令牌。

文档在这里:https://identityserver.github.io/Documentation/docsv2/advanced/customGrantTypes.html

这里还有一个与您的场景相近的示例:https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Multi%20Hop%20Delegation%20(ActAsCustomGrant)

也就是说 - 这可能是通过多个跃点传递用户 ID 的最昂贵的方式。

如果后端系统之间存在受信任的子系统,则只需将所需数据作为有效负载传输就更简单、更快捷。

【讨论】:

  • 是的,我已经用多跳样本试验了一段时间。我在尝试调用链中的第三个 API 时出现了问题,因为当我到达第三个 API 时,我会失去对第一个 API 的跟踪,因为它只跟踪前一个客户端。我对在有效负载上传输数据的担忧是,我应该将我认为应该由授权/令牌逻辑处理的职责委托给 API 的业务逻辑。
  • 也许我想要实现的与此更相关:tools.ietf.org/html/draft-hunt-oauth-chain-01
  • 是否有可能以某种方式使用 acr 值来实现这一点?
猜你喜欢
  • 2021-10-05
  • 2016-10-23
  • 2015-05-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-06-20
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多