这个问题的灵感来自 stackexchange 和 facebook API ( http://api.stackexchange.com/docs/authentication ) 上的文档，但通常可能更广泛地适用于 OAUTH 2.0。
我的问题是，当隐式模型看起来要简单得多时，为什么要使用显式身份验证模型，为什么要进行身份验证和访问内容？
隐式方法是否存在限制，并且对于 node.js 应用程序来说是最合适的方法，该应用程序在技术上是服务器端应用程序，但似乎适合使用客户端 javascript 库。
编辑
在做了一些阅读之后，似乎 Web 客户端流程的“隐式”性质源于资源所有者（用户）隐式信任客户端（Web 浏览器）这一事实。这意味着简化流程是合适的，因为这种隐含的信任是给定的。
这仍然会导致一个问题，即在通过 OAUTH 2.0 执行身份验证时，资源所有者（用户）必须警惕他们是否隐式信任客户端。这似乎是一种潜在的危险立场，因为它代表用户假设意识和知识，并且似乎可能导致安全问题。
谈到 OAuth 2.0 而不是 stackexchange API，隐式流程中存在风险因素，也称为隐式授权流程。这是因为授权服务器将访问令牌发送到您的用户代理/Web 浏览器。
为了尽量减少可能由此造成的任何损害，访问令牌被设置为短暂的。此外，在这种情况下，访问令牌只能用于用户为其提供授权的范围。这种类型的流程主要用于更简单的 Web 应用程序，它们没有服务器来支持它们。您在 Facebook 上看到的相当烦人的应用程序可能就是一个例子，每个其他开发人员都可以使用这种隐式流程，而不必担心安排服务器。
称为授权代码流的显式流程要安全得多。这涉及到用户代理从服务器接收授权码。此代码只能由注册的应用程序使用 - 您将在后端维护的具有有效凭据的服务器。
一个例子：-
假设有一些谷歌应用程序使用 Facebook 图形 API。您可以打开谷歌应用程序网站并授权
i) 浏览器接收令牌，谷歌应用程序制作的网页确保它访问 API，获取数据并将其返回给服务器。
ii) 或者，浏览器获得一个令牌，网页将其返回给谷歌服务器。这确保了只有 Google 可以访问 Facebook API（对于一家大公司来说是一种解脱感）。此外，还有一个管理所有请求的中央服务器，并且可以轻松生成任何类型的指标来监控请求/数量/模式。
这种显式流的另一个主要用途是离线访问。在上述场景中，即使您未登录，您的应用服务器也可以获取 Refresh 令牌并调用 REST API。
如果您确实有服务器端应用程序，我个人建议使用授权代码流/显式流。