javascript - 将 OAuth token 传递给 JavaScript 客户端的安全方式

Question

我目前正在设计一个以 REST API 为中心的多平台应用程序(客户端将包括内部开发的移动应用程序，以及一个 AJAX 重型 javascript 客户端)。由于将来 API 可能会向第三方开放，因此我正在考虑使用 OAuth 2.0 对 API 进行身份验证和授权。

我正试图解决这种安排的一些安全问题，尤其是与 javascript 客户端有关的问题。我不希望这个客户端表现得像第三方客户端那样，有一大堆重定向和弹出窗口之类的东西，这是大多数 OAuth 文档似乎关注的重点。由于它将从我自己的域交付，我认为 webapp 的服务器端可以是实际的客户端，并存储客户端 secret 和刷新 token ，而 javascript 在需要时从服务器检索新的身份验证 token 。

一步一步的形式:

1. 用户使用非 ajax html 表单登录，生成存储在服务器端的身份验证和刷新 token 。这会设置一个仅限 HTTP 的登录 session cookie。
2. javascript 客户端代码在登录后发送到用户的浏览器。
3. javascript 客户端向作为其自身应用程序一部分(而非 REST api 的一部分)的资源发出请求以检索 token 。 session cookie 确保客户端是真实的，也会检查引用者。返回授权 token 。
4. javascript 客户端使用 REST API 验证 token 。
5. 客户端现在可以使用 token 向 REST API 发出请求，直到它过期。
6. 如果授权 token 过期或页面关闭并重新打开，javascript 客户端可以请求一个新 token 。只要登录 session cookie 仍然有效，Web 应用程序的服务器端就会负责刷新 token 并发送新 token 。

这是否有意义，还是会在系统中留下巨大漏洞？特别是，在 Web 上拥有一种根据设置的 cookie 分发身份验证 token 的资源是不是很疯狂？

Answer 1

只需确保与浏览器的任何通信都是 HTTPS，这样中间的任何人都无法窃取您的 token 。并在您的身份验证 cookie 上设置“安全”标志。

• 现在大多数浏览器授权方案都归结为在 cookie 中传递的 session token 。 OAuth 2 方案领先几步，因为 a) token (可以是)内部没有危险用户信息的哑 token ，以及 b) 它们会过期。

• (只是把评论放在上下文中:有一次我从一个网站弹出一个 session token ，发现里面有我的家庭住址和电话号码。确认!)

• 我见过在浏览器 javascript 中对请求进行 HMAC 签名的代码，但它带有一个巨大的免责声明:不要在生产中使用它。签名方案要求客户端 (javascript) 知道一个“ secret ”字符串，但浏览器/javascript 非常不安全，相当于将您的 secret 字符串交给全世界。

但是，如果您将所有通信都保留在 HTTPS 上，那么您实际上只是对熟悉的将 session token 作为 cookie 传递的方案进行了 OAuth 调整。