Security 构建和验证web应用程序访问令牌的模式是什么？

我们有一个web应用程序，它由两部分组成（除其他部分外）：一个用Java编写的“shell”，在Jetty中运行，通过Waffle使用Windows身份验证，它显示一个用ASP.NET编写的“组件”，在IIS中运行，使用Windows身份验证。这两个部分都来自同一个主机，但（当然）来自不同的端口

目前，用户必须首先登录shell，然后在加载组件时，用户必须再次登录。我们想一步一步摆脱第二个标志

根据我所看到和阅读的内容，例如关于基于声明的身份验证和OAuth，其标准模式如下：

• 登录到shell后，shell使用用户的Windows帐户名构造一个“令牌”，并将其发送回浏览器
• 该组件不使用Windows身份验证，而是由浏览器向其发送令牌
• 组件验证它是否信任该令牌，并使用该令牌中的标识

（在我们的例子中，最简单的技术是将令牌放在cookie中，因为shell和组件都在同一台服务器上运行，因此浏览器会自动将shell的令牌发送给组件。）

现在我看到了几种构造和验证令牌的方法，如：

• （a） 令牌包含Windows帐户名，使用对称密钥加密，该密钥硬编码到shell和组件中，或者在安装或启动时生成并同意
• （b） 令牌包含Windows帐户名，使用私钥签名，并使用相应的公钥进行验证。此密钥对在安装时生成
• （c） 令牌包含GUID，组件的服务器端调用shell的服务器端以验证其有效性并获取Windows帐户名

我想我更喜欢（b），因为（a）似乎太“硬编码”，而（c）更可能出现缩放问题。此外，我们已经在shell中以SSL服务器证书的形式准备了一个私有/公共密钥对，该证书由组件信任

我对（b）的主要关注是令牌将包含（X.509？）签名，这意味着令牌可能会变得相当大。（会吗？）另外，我还不熟悉用Java创建签名并在.NET中验证签名的技术

---

我的问题：这里使用的标准/推荐模式是什么？我忽略了哪些选择？我们在这里可以使用标准协议吗？

您的做法是正确的

是的，这个想法是让shell生成一个不能伪造的令牌（由shell以外的任何人生成），该令牌可以由组件验证

你是对的，代币可以变得相当大。它不会变得太大以至于无法工作（即，比浏览器可以处理的还要大），但它可能会成为一个性能问题

一般来说，任何接受具有任何缓存身份验证的HTTP通信的组件都将具有该缓存身份验证的首选格式。在您当前的实现中，在用户登录到组件（第二个登录步骤）后，组件将发出某种cookie，其中包含它将接受用于后续请求的标识凭据。因此，最好的办法是让shell准确地创建这些凭证

如果不能做到这一点，您可以使用选项（b）创建一个签名的认证表单，该表单是组件可以验证的shell，然后替换为首选形式的认证凭证