Spring Security Oauth2

本博文出自： https://www.jianshu.com/p/6ebd04bc000c

一. Oauth2.0

​ 是开放授权的一个标准，旨在让用户允许第三方应用去访问用户在某服务器中的特定私有资源，而可以不提供其在某服务器的账号密码给到第三方应用。通俗的话可以这样去理解，假如你们公司正在开发一个 第三方应用XXX，该应用会需要在微信中分享出来一个活动页，该活动需要让微信用户去参与，你们的应用需要收集到用户的姓名，头像，地域等信息，那么问题来了？你的应用如何才能拿到所有参与活动的微信用户的基本信息呢?

​ 根据如上的描述，我们可以将OAuth2分为四个角色：

• Resource Owner：资源所有者 即上述中的微信用户
• Resource Server：资源服务器 即上述中的微信服务器，提供微信用户基本信息给到第三方应用
• Client：第三方应用客户端 即上述中你公司正在开发的第三方应用
• Authorication Server：授权服务器 该角色可以理解为管理其余三者关系的中间层

其具体的执行流程如下图所示：

[图片上传失败...(image-cd3d38-1589169864698)]

1.1 OAuth2的四种授权方式

1.1.1 授权码(authorization-code)

​ 这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

<font color="red">第一步</font>，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL

上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）。

<font color="red">第二步</font>，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

https://a.com/callback?code=AUTHORIZATION_CODE

<font color="red">第三步</font>，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。

<font color="red">第四步</font>，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}
access_token

1.1.2 隐藏式(implicit)

​ 有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。

<font color="red">第一步</font>，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL

上面 URL 中，response_type参数为token，表示要求直接返回令牌。

<font color="red">第二步</font>，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

https://a.com/callback?token=ACCESS_TOKEN

 

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了

1.1.3 密码式(password)

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

<font color="red">第一步</font>，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。

ttps://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

<font color="red">第二步</font>，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

1.1.4 客户端凭证(client credentials)

​ 最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

<font color="red">第一步</font>，A 应用在命令行向 B 发出请求。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

​ 上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。

<font color="red">第二步</font>，B 网站验证通过以后，直接返回令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌

作者：LANSHENGYANG
链接：https://www.jianshu.com/p/6ebd04bc000c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。