Oauth2.0的客户端模式

 

1.由Authorization Server提供给各业务系统一个clientID和clientSecret；

2.通过clientID和clientSecret获取accessToken；

POST /token HTTP/1.1
Host: authorization-server.com
 
grant_type=client_credentials
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx

3. 如果验证通过，正常返回accessToken如下

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
 
{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}

　　如果验证不通过，返回的example如下

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
 
{
  "error": "invalid_request",
  "error_description": "Request was missing parameter."
}

4.关于token的选择包括以下几种

• 短期的accessToken和长期的refreshToken

这个是官方推荐做法，具有更大的安全性和灵活性;

这种场景下，可以让accessToken有效期从几个小时到几周，refreshToken是长期有效要求比acessToken有效期长;

当accessToken失效后，可以通过refresshToken获取新的accessToken;

这种方式多用在不打算提供数据库处理accessToken而是通过本地加解密方式从而提高系统响应时间、有效降低泄露accessToken的风险、考虑到refreshToken逻辑实现比较让人讨厌，所以需要服务方提供sdk封装refresh的操作。

•  短期的accessToken且不提供refreshToken

这种选择下accessToken有效性可以维持从当前session至几周，*选择；

但是规范是要求到期后，需要用户重新登录系统，之后重新通过认证获取accessToken，让用户参与到accessToken有效期的维护中。

• 永不过期的accessToken

这种是最简单也最容易让人接受的方式，但是必须做到能随时让某个accessToken失效；

如果token泄露了不会有大的风险、可以让调用方更容易的实现认证、有数据同步的需求优先考虑

 

5. 刷新accessToken

如果采取【短期的accessToken和长期的refreshToken】，那么就必须提供刷新的接口，刷新接口必须校验必输项，验证refreshtoken有效性，验证clientid和clientsecret匹配性，之后提供新的accessToken

POST /oauth/token HTTP/1.1
Host: authorization-server.com
 
grant_type=refresh_token
&refresh_token=xxxxxxxxxxx
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx