将OAuth令牌传递给javascript客户端的安全方式

Question

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

我试图了解这种安排的一些安全问题，特别是关于javascript客户端。我不希望这个客户端表现得像第三方客户端那样，有大量的重定向和弹出窗口和东西，这是大多数OAuth文档似乎关注的内容。由于它将从我自己的域提供，我认为webapp的服务器端可以是实际的客户端，并存储客户端机密和刷新令牌，而javascript在需要时从服务器检索新的auth令牌。

将其逐步形成：

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

这是否有意义，还是会在系统中留下大量漏洞？特别是，在网络上有一个基于正在设置的cookie发放身份验证令牌的资源是不是很疯狂？

Answer 1

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

• 现在大多数浏览器授权方案归结为在cookie中传递的会话令牌。 OAuth 2计划提前几步，因为a）令牌（可以是）愚蠢的令牌，里面没有危险的用户信息，b）它们到期。

• （只是将该评论放在上下文中：有一次我从网站上打开会话令牌，发现我的家庭住址和电话号码就在那里。确认！）

• 我见过代码在brower javascript中进行HMAC签名请求，但它附带了一个巨大的免责声明：不要在生产中使用它。签名方案要求客户端（javascript）知道“秘密”字符串，但浏览器/ javascript非常不安全，相当于将秘密字符串传递给世界。

但是如果你通过HTTPS保持所有的通信，那么你真的只是在将会话令牌传递为cookie的熟悉方案上加入OAuth。