6

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

我正试图解决这种安排的一些安全问题，特别是关于 javascript 客户端的问题。我不希望这个客户端表现得像第三方客户端一样，带有一大堆重定向和弹出窗口等，这是大多数 OAuth 文档似乎关注的内容。由于它将从我自己的域交付，我认为 webapp 的服务器端可以是实际的客户端，并存储客户端机密和刷新令牌，而 javascript 根据需要从服务器检索新的身份验证令牌。

把它一步一步的形式：

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

这有意义吗，还是会在系统中留下巨大的漏洞？特别是，在 Web 上拥有一个基于设置的 cookie 分发身份验证令牌的资源是不是很疯狂？

4

1 回答 1

5

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

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

  • （只是把这个评论放在上下文中：有一次我从一个站点弹出一个会话令牌，发现我的家庭地址和电话号码在那里。Ack！）

  • 我已经看到在浏览器 javascript 中对请求进行 HMAC 签名的代码，但它带有一个巨大的免责声明：不要在生产中使用它。签名方案要求客户端 (javascript) 知道“秘密”字符串，但浏览器/javascript 是如此不安全，以至于将您的秘密字符串交给世界​​。

但是，如果您通过 HTTPS 进行所有通信，那么您实际上只是对熟悉的将会话令牌作为 cookie 传递的方案进行了 OAuth 扭曲。

于 2013-02-26T04:50:21.070 回答