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

Question

我们有一个Web应用程序，它由两部分组成（其中包括）：a＆＃39; shell＆＃39;使用通过Waffle进行Windows身份验证在Jetty中运行的Java编写，它显示了一个＆＃39;组件＆＃39;使用Windows身份验证在IIS中运行的IIS中编写。这两个部分都来自同一台主机，但（当然）来自不同的端口。

目前，用户首先必须登录shell，然后在加载组件时，用户必须再次登录。 我们希望摆脱第二次登录步骤。

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

• 登录shell后，shell会构建一个＆＃39;令牌＆＃39;使用用户的Windows帐户名称，将其发送回浏览器。
• 该组件不使用Windows身份验证，而是浏览器向其发送令牌。
• 组件验证它是否信任该令牌，并使用该令牌中的标识。

（在我们的例子中，最简单的方法是将令牌放在cookie中，因为shell和组件都在同一台服务器上运行，HTTP cookies are not port-specific，所以浏览器会自动发送shell的令牌组件。）

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

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

我认为我更喜欢（b），因为（a）似乎过于“硬编码”，而且（c）更有可能提出缩放问题。此外，我们已经在shell中以SSL服务器证书的形式建立了私钥/公钥对，该证书受组件信任。

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

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

Answer 1

你走在正确的轨道上。

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

你是对的，令牌可能变得非常大。它不会变得那么大，以至于不可行（即比浏览器可以处理的大），但它可能成为性能问题。

通常，任何接受具有任何缓存身份验证的HTTP流量的组件都将具有该缓存身份验证的首选格式。在您当前的实现中，在用户登录组件（步骤中的第二个签名）之后，组件将发出某种cookie，其中包含将为后续请求接受的标识凭据。所以最好的办法是让shell准确创建这些凭据。

如果不这样做，您可以使用您的选项（b）创建一个签名的认证表单，该组件可以验证的shell然后替换为其首选的身份验证凭据。