想象一个桌面应用程序调用单点登录服务来登录当前用户的场景。该服务对用户进行身份验证并返回一个 token (Json Web token )，该 token 是用公共(public)/私有(private)的私有(private)部分签名的 key 对。此 token 对用户的身份有一些声明。
然后，应用程序希望为某些数据调用不同的服务，因此将 token 传递给该服务。该服务使用 token 中的声明(以及它由 SSO 服务签名的事实)来识别当前用户并确定要返回的数据。到目前为止一切顺利。
现在假设应用程序想要提供一些额外的信息，这些信息与用户的身份无关，而是关于用户在应用程序中使用的当前 session 的一些上下文(比如他们连接到的当前数据库)。
这些看起来像是可以与请求一起发送的附加声明的良好候选者，因此数据服务可以从 token 中提取声明并使用来自 SSO 的身份声明和来自桌面应用程序的应用程序特定声明来决定做什么和怎么做。 (比如要更新哪个数据库)
问题是我们无法向现有 token 添加声明，因为它已由 SSO 服务签署，应用程序无法知道用于签署新 token 的私钥。如果原始 token 不存在，则数据服务无法相信身份来自 SSO，因此根本不允许访问数据。
我能想到的选项:
- 身份验证后，应用程序再次调用 SSO 服务，提供一组声明(以某种方式得到保护，不是任何人都可以调用 SSO 来获得添加到 token 的额外声明)和 SSO token ，SSO 服务返回一个包含身份声明和应用程序要添加的附加声明的新 token
- 应用程序创建一个新 token 并对其进行签名，并且此 token 中的声明之一是对提供的 SSO 服务的原始 token 。
这两者各有利弊，但总的来说，我认为我更喜欢第一种选择。
更复杂的是，“应用程序”不只是一个，还有很多。所有人都将使用相同的 SSO 服务，并且所有人都希望添加一些额外的特定于应用程序的声明(即 app1 和 app2 的声明将不同)
这个问题是否已经有了开箱即用的解决方案？或者除了上述选项之外，还有其他方法可以处理此问题吗？
最佳答案
不确定我喜欢哪个选项。
After authentication the application calls the SSO service again providing a collection of claims and the SSO token, and the SSO service returns a new token which contains the identity claims and the additional claims the application wants to add
我认为任何 SSO 服务都不允许您这样做。 token 中的声明已签名，因为 SSO 服务保证它们是正确的。如果 SSO 服务开始签署任意数据，则该保证将不再有效。
The application creates a new token which it signs and one of the claims in this token is to original token the SSO service provided.
如果您让应用程序签署访问 token ，则必须分发 SSO 服务和应用程序的公钥。您的数据服务现在必须信任两者。
为什么不直接传递数据服务可能需要的额外信息作为服务调用中的参数？如果您通过 HTTPS 调用该服务，则可以保证您传递的任何内容的完整性。
关于authentication - 在对附加服务进行身份验证后向 token 添加附加声明，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34800304/