我目前正在设计一个以 REST API 为中心的多平台应用程序(客户端将包括内部开发的移动应用程序，以及一个 AJAX 重型 javascript 客户端)。由于将来 API 可能会向第三方开放，因此我正在考虑使用 OAuth 2.0 对 API 进行身份验证和授权。
我正试图解决这种安排的一些安全问题，尤其是与 javascript 客户端有关的问题。我不希望这个客户端表现得像第三方客户端那样，有一大堆重定向和弹出窗口之类的东西，这是大多数 OAuth 文档似乎关注的重点。由于它将从我自己的域交付，我认为 webapp 的服务器端可以是实际的客户端，并存储客户端 secret 和刷新 token ，而 javascript 在需要时从服务器检索新的身份验证 token 。
一步一步的形式:
- 用户使用非 ajax html 表单登录，生成存储在服务器端的身份验证和刷新 token 。这会设置一个仅限 HTTP 的登录 session cookie。
- javascript 客户端代码在登录后发送到用户的浏览器。
- javascript 客户端向作为其自身应用程序一部分(而非 REST api 的一部分)的资源发出请求以检索 token 。 session cookie 确保客户端是真实的，也会检查引用者。返回授权 token 。
- javascript 客户端使用 REST API 验证 token 。
- 客户端现在可以使用 token 向 REST API 发出请求，直到它过期。
- 如果授权 token 过期或页面关闭并重新打开，javascript 客户端可以请求一个新 token 。只要登录 session cookie 仍然有效，Web 应用程序的服务器端就会负责刷新 token 并发送新 token 。
这是否有意义，还是会在系统中留下巨大漏洞？特别是，在 Web 上拥有一种根据设置的 cookie 分发身份验证 token 的资源是不是很疯狂？
最佳答案
只需确保与浏览器的任何通信都是 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 调整。
关于javascript - 将 OAuth token 传递给 JavaScript 客户端的安全方式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15069151/