使用OAuth 2.0保护WebSocket APIs是否可行？

Question

我正在实现一个OAuth提供程序来保护不同的基于Web的API。最让我头疼的是如何通过OAuth来保护WebSockets。

在浏览器中设置的客户端中，它是否可以完全安全地完成？

如果与具有服务器的Web应用程序相比，它在浏览器中存在哪些风险？

我想使用2-legged OAuth来限制对websocket的连接，以便只有注册的客户端才能获取WebSocket连接到API而不会被拒绝。由于WebSocket连接始终（！）在客户端（从浏览器）建立，因此是否可能保护accessToken免受盗窃和误用？
此时，将基于浏览器的客户端与Web应用程序客户端区分开来的唯一事物是URL。

如果基于浏览器的应用程序不安全，那么我可以接受，但是我希望确保至少基于Web的应用程序可以安全地访问websocket。

但在这一点上，我自己问accessToken是否真的有必要，因为那样我只需使用origin-URI作为唯一的安全机制。

- JustGoscha

Answer 1

是的，您可以使用OAuth来保护WebSocket连接。Kaazing WebSocket Gateway拥有一种优雅的架构，可使用各种方法（基于令牌、基于HTTP或基于cookie）进行身份验证和授权。

此外，它以一种安全的方式完成，适用于Web上可能涉及不受信任客户端的情况。（或者至少，您应该始终假设您正在处理不受信任的客户端。）

当客户端尝试WebSocket连接时，网关将接收请求。如果已配置特定服务（即URL）受到保护，则会向客户端发出挑战。

在接收到挑战后，客户端需要提供一个令牌（假设在这种情况下已经进行了配置）。如果客户端已经拥有令牌——因为他们以前已经登录到其他系统或网页——那就太好了。如果没有，则必须获取一个。这完全取决于您选择的安全性。在这种情况下，它会联系OAuth令牌提供者以获取令牌。这可能意味着用户需要提供凭据。

一旦客户端获得令牌，它将其作为响应发送到网关以回应挑战。网关支持标准的JAAS体系结构，因此您可以插入登录模块以执行必要的身份验证。在这种情况下，它可能会将令牌发送到令牌提供程序，以确定它是否是有效的令牌。

如果是有效的，则WebSocket连接将打开并可以继续。如果不是，则请求将被拒绝，并关闭连接。

这样做的好处是保护您的后端应用程序 - 只有有效用户才能通过网关。此外，由于Kaazing WebSocket Gateway可以存在于DMZ中，未经身份验证的用户甚至不会进入您主要防火墙内的受信任网络。他们在外面快速失败。

这种体系结构很强大，因为无论您选择了什么安全框架，Kaazing的网关都将插入其中，而不是强加自己的安全机制。此外，在OAUth或OAuth2的情况下，它不需要理解或解码令牌。令牌提供程序是唯一需要理解它的人。但是，如果您的令牌提供程序想要指定会话的持续时间，则可以将其与令牌一起包含，网关将予以尊重。

如果基于浏览器的应用程序不安全，我可以接受，但我希望确保至少基于Web的应用程序有一种安全的方式来访问websocket。

通过正确的架构和实现，可以使基于Web和基于浏览器的应用程序变得安全。在Kaazing，我们始终假定您正在处理Web上的不受信任的客户端，并相应地构建我们的架构。

以下是文档的几个部分，具有高级描述：

- 身份验证期间发生了什么 - 网关如何处理身份验证和授权 问候， Robin Kaazing产品经理

- Robin Zimmermann

---

这是一个很好的解决方案，如果需要用户身份验证，但我不确定它是否适用于仅客户端需要进行身份验证的情况，例如在oauth-2草案http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.4中的客户端凭据授权。在那里，它还说它必须仅用于机密客户端。但即使您拥有机密客户端，然后将访问令牌发送到浏览器（以建立ws连接），它也会被暴露。因此，为了防止其被重复使用，您必须允许此accessToken仅在非常短的时间内使用或限制对其的访问。 - JustGoscha

Answer 2

一个凭证授权只有在发放访问令牌之前进行的身份验证足够安全。他们说这是规范之外的。因此，这取决于您决定在授予凭证授权后提供令牌之前放置在其前面的任何身份验证方案。

现在，假设您已经设置了一个不错的安全方式来获取您的凭证授权或通过常规OAuth2请求将访问令牌放入浏览器中。

根据OAuth2规范，您可以自由地对部分进行MAC摘要、加密部分或以任何数量的方式保护该令牌内的数据。浏览器中的访问令牌的安全性取决于它包含的信息 - 通常人们设计它包含最少的信息（用户ID、过期时间、版本、摘要），并通过您的服务器使其自我验证（因此是摘要）。令牌的内容几乎是任意的。一些系统甚至分配访问“代码”作为代理令牌。

现在假设您具有受保护的“安全格式”访问令牌，并带有时间限制。让我们考虑一个现实世界的例子：Facebook及其OAuth2实现。无论是完整的访问令牌还是用于服务器端凭据检索的访问代码（每个都有时间限制），您都可以将令牌（或代码）从浏览器发送到Kaazing网关，以安全地访问WebSocket。

我从使用Kaazing的网关中获得的经验之一是，OAUth2实际上并没有保护任何内容 - 您可以自由地分发任意形式的访问令牌。最好确保您的凭证身份验证方案、access_token格式和access_token生存期都是良好的策略决策 - 然后您就会获得安全性。

Kaazing网关将允许您将任意令牌发送到网关并使用JAAS登录模块进行验证。制度的安全性取决于您和政策决策。

此致，

Steven Atkinson

网关服务器开发人员，Kaazing

- nowucca