facebook - Stackexchange API 隐式与显式

Question

这个问题的灵感来自于 stackexchange 和 facebook API ( http://api.stackexchange.com/docs/authentication ) 上的文档，但通常可能更广泛地适用于 OAUTH 2.0。

我的问题是，当隐式模型看起来更简单时，为什么要使用显式身份验证模型来进行身份验证和访问内容？

隐式方法是否存在隐含的限制，以及哪种方法最适合 Node.js 应用程序，该应用程序在技术上是服务器端应用程序，但似乎适合使用客户端 javascript 库。

编辑

经过一番阅读后发现，Web 客户端流程的“隐式”本质源于资源所有者(用户)隐式信任客户端(Web 浏览器)这一事实。这意味着考虑到这种隐含的信任是给定的，简化的流程是合适的。

这仍然会导致一个问题，即在通过 OAUTH 2.0 执行身份验证时，资源所有者(用户)必须警惕他们是否隐式信任客户端。这似乎是一种潜在的危险立场，因为它代表用户假设了意识和知识，并且似乎可能会导致安全问题。

Answer 1

就 OAuth 2.0 而不是 stackexchange API 而言，隐式流程(也称为隐式授权流程)中存在风险因素。这是因为授权服务器将访问 token 发送到您的用户代理/Web 浏览器。

为了最大限度地减少由此可能造成的任何损害，访问 token 的生命周期很短。此外，在这种情况下，访问 token 只能用于用户提供授权的范围。这种类型的流程主要用于更简单的 Web 应用程序，这些应用程序没有服务器支持。您在 Facebook 上看到的相当烦人的应用程序可能就是一个例子，其他每个开发人员都可以使用这种隐式流程，而不必担心安排服务器。

称为授权代码流的显式流程要安全得多。这涉及用户代理从服务器接收授权代码。此代码只能由注册的应用程序使用 - 您将在后端维护的具有有效凭据的服务器。

示例:-
假设有一些 Google 应用程序使用 Facebook 图形 API。您可以打开google app网站并授权
i) 浏览器接收 token ，谷歌应用程序制作的网页确保它命中 API，获取数据并将其返回到服务器。
ii) 或者，浏览器获取 token 并且网页将其返回到谷歌服务器。这确保了只有 Google 可以访问 Facebook API(对于大公司来说这是一种解脱)。此外，还有一个中央服务器可以管理所有请求，并可以轻松生成任何类型的指标来监控请求/数字/模式。

这种显式流程的另一个主要用途是离线访问。在上述场景中，即使您未登录，您的应用服务器也可以获取刷新 token 并调用 REST API。

如果您确实有服务器端应用程序，我个人建议使用授权代码流程/显式流程。