4

TL;DR - 跳过标记为问题的部分,尽管某些上下文可能有用。

一些背景

因此,我一直在网上搜寻一些问题的答案,这些问题是关于将我们的内部 API 彻底翻转并开放给开发人员使用的。我们的 API 已经投入生产,目前在需要时使用标准会话进行保护。

现在我已经确信用你自己的 api 喂狗是一个好主意,所以我们可以跳过这一部分。我的问题与采用内部并使其安全成为外部有很大关系,请输入 OAuth2。

在前端,我们是一个 angular.js 应用程序,分布在网站的多个部分,我认为它很重要,我强调它不是单页应用程序。在后端,我们有 django 以及使用 django-rest-framework 构建的其余 api。我不认为后端的细节真的很重要,但绝对值得注意的是 django 渲染了其中一些页面。这意味着在某些情况下,Angular 会预先传递数据,而不是从 api 请求所有内容。这也有助于我们使网站的某些部分对 SEO 更加友好。一旦页面被渲染并且所需的任何初始数据都已传递给 angular,一切都是 angular.js --> api

在我真正进入问题的核心之前要提到的最后一个细节是,api 目前有一些公共端点,在前端公开可用的内容是根据定义从 api 公开可用的,尽管这可能是我们想要的改变。

一些推理

我已经从头到尾阅读了 OAuth2 规范(几乎)好几遍了,我已经阅读了我可以在网上找到的每一篇文章,我什至还买了一本关于该主题的书,但对我来说只缺少一个部分,一个重要的例子会有所帮助我了解用 OAuth 替换我们 Web 平台上当前身份验证的实现。

如果我们要将我们的 API 提供给第三方,那么 OAuth2 似乎是目前唯一合理的选择。狗食api只会改善它。所以我们自己需要访问令牌。这是我无法做出决定的地方。

我们已经开始将 API 与主要的 Django api(现在用烧瓶编写)分开,因此将 oauth 添加到 api 将是一个非常自然的步骤。我们显然不能给出 angular 键,那么我们还剩下什么?

问题

我们可以用 OAuth2 替换基于会话的身份验证吗?我们的内部 api 目前使用会话进行身份验证。如果我们将 API 提供给第三方,我们如何为主要的 Web 平台实现 OAuth?

我们默认是 HTTPS

  • 一旦用户登录(资源所有者密码流程),这将很好地复制我们网站的当前功能,直接使用该令牌是否安全。令牌可以保存在 django 中,并在需要时简单地传递给 angular js 应用程序。

  • 我们需要在 django 和 api 之间建立某种代理吗?这将使http请求加倍,尽管在本地网络上可能还不错?

  • 我们可以使用隐式授权流程完全用角度处理它吗?据我了解,用户令牌已过期,只要用户仍然使用身份验证服务器登录,角度就可以异步请求另一个令牌以发出请求

  • 当用户访问我们的站点时,整个 OAuth 流程对他们应该是透明的。这让客户凭证看起来很有吸引力?是否有这个流程和一些可以工作的 api 代理的组合,尽管这似乎有点安全风险,允许网站简单地使用 client_id 和 client_secret 访问所有内容?

  • 这是大佬们做的吗??脸书、推特等?

老实说,以上都不是一个很好的选择。它会全面产生可怕的影响,我无法想象在开发中使用这些选项会有多大的痛苦。我的意思是这甚至是个好主意吗?我刚刚忽略了一些更简单的方法。

该规范总是暗示您信任第一方应用程序(如移动客户端)的情况下的解决方案,但老实说,对于第一方实际上是网站的情况,我只是没有受到我所考虑的任何东西的启发。

我感谢任何花时间阅读本文的人。正如我所提到的,我已经阅读了关于这些主题的所有内容,并且大多数都基于 - 我应该使用自己的 api 还是我们如何使用单点登录?我正在寻找的是有关在实际意义上实际实施这些事情的信息,并希望为任何在生产中完成此任务的灵魂提供一些智慧的珍珠。

感谢您抽时间阅读。

4

1 回答 1

0

我一直在考虑这个问题——我目前正在构建一个 Angular 应用程序,该应用程序可以访问 Node.js 内置的 REST API。为了与 REST 保持一致,我不应该维护会话,而应该在每个请求中传递一些用户/密码详细信息。

现在很明显,很多 API 很乐意坚持使用某种基本授权或 api 密钥,从而避免 oauth2,但我想使用 google/facebook 登录,因此需要进行一定数量的令牌争吵。我正在使用的特定流程是这样的 -

  1. 用户访问 Angular 应用程序。由于他们没有登录,他们将获得一个登录页面,可以选择使用 google/facebook 登录。

  2. 假设他们单击以使用 google 登录 - 该链接向我的节点服务器发送请求,并通过将用户重定向到 google 登录页面来启动 google 授权流程。

  3. 他们授予对应用程序/登录的访问权限 - 然后重定向回节点服务器,该服务器从谷歌获取 oauth2 令牌。然后节点服务器为特定用户存储这个令牌。

  4. 最后,节点服务器连同标头中的令牌一起重定向回 Angular 应用程序。此令牌存储在浏览器会话中,并在应用发出 api 请求时使用。如果 api 请求收到一个有效的令牌,它会以实物形式响应,否则它会传递一个错误,并且 Angular 应用程序会注意到这一点并重定向到登录页面,并带有某种相关的错误通知。

如果您向第三方开放 API,您可能需要做更多的工作,但这不是我目前考虑太多的事情。

于 2013-10-08T10:22:20.580 回答