security - 构建和验证 Web 应用程序的访问 token 的模式是什么？

Question

我们有一个 Web 应用程序，它由两部分组成(除其他部分外):一个用 Java 编写的“外壳”，通过 Waffle 使用 Windows 身份验证在 Jetty 中运行，它显示了一个用 ASP.NET 编写的“组件”，在使用 Windows 的 IIS 中运行验证。两个部分都由同一主机提供服务，但(当然)来自不同的端口。

就目前情况而言，用户首先必须登录到 shell，然后在加载组件时，用户必须再次登录。 我们希望取消第二个登录步骤。

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

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

(在我们的例子中，最简单的技术是将 token 放入 cookie 中，因为 shell 和组件都在同一服务器上运行，并且 HTTP cookies are not port-specific ，因此浏览器会自动将 shell 的 token 发送到组件。)

现在我看到了几种构建和验证 token 的方法，例如:

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

我认为我更喜欢(b)，因为(a)似乎太“硬编码”，并且(c)更有可能出现缩放问题。此外，我们已经在 shell 中以 SSL 服务器证书的形式准备了私钥/公钥对，该 key 受到组件的信任。

我对 (b) 的主要担忧是 token 将包含(X.509？)签名，这意味着 token 可能会变得相当大。 (会吗？)而且我(还)还不熟悉在 Java 中创建签名并在 .NET 中验证它的技术。

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

Answer 1

你走在正确的道路上。

是的，这个想法是让 shell 生成一个无法伪造的 token (由除 shell 之外的任何东西/任何人生成)，并且可以由组件验证。

你说得对，代币可以变得相当大。它不会变得太大而无法工作(即大于浏览器可以处理的大小)，但它可能会成为性能问题。

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

如果做不到这一点，您可以使用选项 (b) 从 shell 中创建签名认证，组件可以验证该认证，然后用其首选形式的身份验证凭据替换。