我有一个 api，它使用 OAuth 1.0a 来验证使用它的应用程序。它正在取代旧的 API，旧的 API 使用了许多自定义构建和大杂烩调用，但这些调用已被弃用。
众所周知，OAuth 1.0a 在（客户端）Javascript 中并不安全，因为它依赖于对消费者秘密进行保密。这是不可能的，因为源代码始终可见。
我们有 Chrome、Firefox、IE 和 Safari 的浏览器扩展，将来需要使用此 api。这些扩展大部分或全部都是用 Javascript 编写的，因此存在安全问题。
这些扩展是内部的，因此可以使用自定义身份验证方法来获取其访问令牌。
我计划实施的内容如下：
- 用户在浏览器中登录网站。
- 该网站向他们发出一个带有会话密钥的 cookie。
- 然后我们的扩展获取该 cookie 并将其传递给 api。
- API 验证它是有效且活动的会话，并向扩展程序发出其访问令牌。
- 这些令牌在过期前最多持续一小时。
- javascript 发出的 cookie 的速率限制也将降低。
它在以下假设下运作：
- 如果其他应用程序可以访问您的 cookie，那么他们无论如何都可以在网站上冒充您，因此访问 api 也没有什么不同。
- 所有身份验证方法仍然受到我们的控制。
- 代币定期过期意味着如果它们被泄露，那么利用的时间是有限的。
我的问题是，这是一种限制 api 访问的安全方法吗？
还有更好的吗？
一些注释。我知道 Chrome 扩展程序可以请求访问给定站点的 cookie 的权限。我相信 Firefox 扩展也可以做到这一点。
显然，我们不希望通过任何页面上的 javascript 访问我们的 cookie，否则我们将面临 XSS 攻击，因此它们只需要通过扩展来访问。
我编写了一个网站，通过 OAuth 的 javascript 库进行 OAuth 登录。这是工作流程：
- OAuth 仅在具有 LocalStorage 的浏览器上受支持
- 登录表单将检查 LocalStorage 中的 OAuth 密钥，并在 OAuth 密钥存在时自动尝试 OAuth 登录。
- 登录表单上有一个“记住我”复选框，因此用户可以在登录时为其创建 OAuth 令牌。
- A successful login w/ remember me will:
- 查找或创建名称等于 User Agent 的 ClientApplication，并根据需要创建令牌
- 在 HTML 响应中使用 javascript 标记进行响应。 javascript 标签将使用作为参数传递的标记来调用 javascript 函数。此函数会将 OAuth 令牌保存到 LocalStorage。
- An unsuccessful OAuth login attempt will:
- 在 HTML 响应中使用 javascript 标记进行响应。 javascript 标记将调用 javascript 函数来清除 OAuth 令牌的 LocalStorage 设置。这将阻止额外的 OAuth 登录尝试
这个过程还有更多细节，如果您愿意，我可以告诉您更多相关信息。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
