Oauth2.0几种授权方式总结-详细内容

文章内容

2019/5/30 19:50:20,作者: 黄兵

Oauth2.0几种授权方式总结

OAuth2.0有如下几种授权方式：Implicit 授权方式、Authorization Code 授权、Resource Owner Password Credentials 授权和 Client Credentials 授权。

下面分别来讲一下这几种授权方式。

Implicit 授权方式：

Oauth2.0的核心机制已经总结完毕。除了核心机制，Oauth2.0 还提供了几种标准的授权流程，分别适用于不同的场景。其中一种叫做 Implicit 授权，适用于纯静态页面应用。所谓纯静态页面应用，也就是应用没有在服务器上执行代码的权限（通常是把代码托管在别人的服务器上），只有前端 Js 代码的控制权。

这种场景下，应用是没有持久化存储的能力的。因此，按照 Oauth2.0 的规定，这种应用是拿不到 refresh token 的。其整个授权流程是这样：

对于这种应用，access token 是容易泄露的，且不可刷新。

Authorization Code 授权

Authorization Code 方式适用于有自己的服务器的应用。之所以叫这个名字，是因为流程中引入了一个叫做 authorization code 的东西。这个东西是一个一次性的临时凭证，用来换取 access token 和 refresh token。

鉴权服务器提供了一个类似这样的接口：

https://www.xxx.com/exchange?code=&client_id=&client_secret=

需要传入 code、client_id 以及 client_secret。验证通过后，返回 access token 和 refresh token。一旦换取成功，code 立即作废，不能再使用第二次。

为什么要引入一个一次性的 code？

先看流程图：

这个 code 的作用是保护 token 的安全性。上一节说到，Implicit 方式下，token 是不安全的。这是因为在 4 这一步当中直接把 token 返回给应用。而这一步容易被拦截、窃听。引入了 code 之后，即使攻击者能够窃取到 code，但是由于他无法获得应用保存在服务器的 client_secret，因此也无法通过 code 换取 token。而 5 这一步，为什么不容易被拦截、窃听呢？这是因为，首先，这是一个从服务器到服务器的访问，黑客比较难捕捉到；其次，这个请求通常要求是 https 的实现。即使能窃听到数据包也无法解析出内容。

有了这个 code，token 的安全性大大提高。因此，Oauth2.0 鼓励使用这种方式进行授权，而 Implicit 方式则是在不得已情况下才会使用。

Resource Owner Password Credentials 授权和 Client Credentials 授权

这两种简称 Password 方式和 Client 方式吧，都只适用于应用是受信任的场景。一个典型的例子是同一个企业内部的不同产品要使用本企业的 Oauth2.0 体系。在有些情况下，产品希望能够定制化授权页面。由于是同个企业，不需要向用户展示“xxx将获取以下权限”等字样并询问用户的授权意向，而只需进行用户的身份认证即可。这个时候，由具体的产品团队开发定制化的授权界面，接收用户输入账号密码，并直接传递给鉴权服务器进行授权即可。