将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)它们到期.

• (只是将该评论放在上下文中:有一次我从一个站点弹出一个会话令牌,发现我的家庭地址和电话号码就在那里.等等!)

• 我已经看到代码在浏览器javascript中进行HMAC签名请求,但它附带了一个巨大的免责声明:不要在生产中使用它.签名方案要求客户端(javascript)知道"秘密"字符串,但浏览器/ javascript是如此不安全,相当于将您的秘密字符串交给世界​​.

但是,如果你通过HTTPS保持所有的通信,那么你真的只是将OAuth转变为熟悉的将会话令牌作为cookie传递的方案.