想象一下桌面应用程序调用Single Sign On服务来记录当前用户的情况。此服务对用户进行身份验证并返回一个令牌（Json Web令牌），该令牌使用公共/私有的私有部分进行签名密钥对。此令牌有一些关于用户身份的声明。
然后，应用程序希望为某些数据调用不同的服务，因此将令牌传递给服务。该服务使用令牌中的声明（以及它由SSO服务签名的事实）来标识当前用户并确定要返回的数据。到目前为止一切都很好。
现在说应用程序想要提供一些与用户身份无关的其他信息，但有关用户在应用程序中使用的当前会话的一些上下文（如他们所连接的当前数据库）。
这些似乎是可以随请求一起发送的其他声明的良好候选者，因此数据服务可以从令牌中提取声明并使用来自SSO的身份声明和来自桌面应用程序的特定于应用程序的声明来决定该怎么做以及如何做到这一点。 （比如要更新的数据库）
问题是我们无法向现有令牌添加声明，因为这已经由SSO服务签名，并且应用程序无法知道用于签署新令牌的私钥。如果原始令牌不存在，那么数据服务不能相信该身份来自SSO，因此根本无法访问数据。
我能想到的选项：
这两者都有利有弊，但总的来说，我认为我更喜欢第一种选择。
为了使事情复杂化，不仅有一个应用程序＆＃39;有几个。所有人都将使用相同的SSO服务，并且所有人都希望添加一些额外的应用程序特定声明（即app1和app2的声明将有所不同）
这个问题是否有开箱即用的解决方案？或者还有其他方法可以解决这个问题，然后是上面列出的选项吗？
答案 0 :(得分：0)
不确定我是否喜欢这两个选项。
认证后，应用程序再次调用SSO服务 提供索赔和SSO令牌以及SSO的集合 service返回一个包含身份声明和新标记的新标记 应用程序想要添加的其他声明
我认为任何SSO服务都不允许您这样做。令牌中的声明已签名，因为SSO服务保证它们是正确的。如果SSO服务将开始签署任意数据，则该保证不再成立。
应用程序会创建一个新签名，它会签名并且其中一个签名 此令牌中的声明是原始令牌提供的SSO服务。
如果您让应用程序签署访问令牌，您必须分发SSO服务和应用程序的公钥。您的数据服务现在必须同时信任。
为什么不将数据服务可能需要的额外信息作为服务调用中的参数传递？如果您通过HTTPS调用该服务，则保证您传递的任何内容的完整性。