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,具体来说,隐式流中存在风险因素,也称为隐式授权流.这是因为授权服务器将访问令牌发送到您的用户代理/ Web浏览器.

为了尽量减少因此造成的任何损害,访问令牌是短暂的.此外,在此方案中,访问令牌只能用于用户提供授权的范围.此类型的流主要用于更简单的Web应用程序,它们没有服务器来支持它们.你在Facebook上看到的相当恼人的应用程序就是一个例子,每个其他开发人员都可以使用这个隐式流程,而不必担心安排服务器.

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

一个例子: -
假设有一些谷歌应用程序使用Facebook图形API.您可以打开谷歌应用程序网站并授权
i)浏览器接收令牌,谷歌应用程序制作的网页确保它访问API,获取数据并将其返回到服务器.
ii)或者,浏览器获取令牌并且网页将其返回到谷歌服务器.这确保了只有谷歌才能获得Facebook API(对大公司有一种解脱感).此外,还有一个管理所有请求的中央服务器,可以轻松生成任何类型的度量标准,用于监控请求/数量/模式.

此显式流程的另一个主要用途是脱机访问.在上面的场景中,您的应用服务器可以获取刷新令牌,即使您未登录也可以调用REST API.

如果你有一个服务器端应用程序,我个人会建议使用授权代码流/显式流程.