微服务统⼀认证⽅案 OAuth2

微服务架构下统一认证思路

基于Session的认证方式

在分布式的环境下，基于session的认证会出现⼀个问题，每个应⽤服务都需要在session中存储⽤户身份信息，通过负载均衡将本地的请求分配到另⼀个应⽤服务需要将session信息带过去，否则会重新认证。我们可以使⽤Session共享、Session黏贴等⽅案。

Session⽅案也有缺点，⽐如基于cookie，移动端不能有效使⽤等。

基于token的认证方式

基于token的认证⽅式，服务端不⽤存储认证数据，易维护扩展性强， 客户端可以把token 存在任意地⽅，并且可以实现web和app统⼀认证机制。其缺点也很明显，token由于⾃包含信息，因此⼀般数据量较⼤，⽽且每次请求 都需要传递，因此⽐较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。

OAuth2开放授权协议/标准

OAuth2介绍

OAuth（开放授权）是⼀个开放协议/标准，允许⽤户授权第三⽅应⽤访问他们存储在另外的服务提供者上的信息，⽽不需要将⽤户名和密码提供给第三⽅应⽤或分享他们数据的所有内容。

允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。

OAuth2是OAuth协议的延续版本，但不向后兼容OAuth1即完全废⽌了OAuth1。

OAuth2协议角色和流程

• 资源所有者（Resource Owner）：可以理解为⽤户⾃⼰
• 客户端（Client）：我们想登陆的⽹站或应⽤，⽐如拉勾⽹
• 认证服务器（Authorization Server）：可以理解为微信或者QQ
• 资源服务器（Resource Server）：可以理解为微信或者QQ
  

OAuth协议基本流程

1. Client请求资源所有者的授权，请求中一般包含：要访问的资源路径，操作类型，Client的身份等信息。
2. 资源所有者批准授权，并将“授权证据”发送给Client。
3. Client向认证服务器请求“访问令牌(Access Token)”。此时，Client需向认证服务器提供资源所有者的“授权证据”，以及Client自己身份的凭证。
4. 认证服务器验证通过后，向Client返回“访问令牌”。访问令牌也有多种类型，若为bearer类型，那么谁持有访问令牌，谁就能访问资源。
   5.认证服务器携带“访问令牌”访问资源服务器上的资源。在令牌的有效期内，Client可以多次携带令牌去访问资源。
   6.资源服务器验证令牌的有效性，比如是否伪造、是否越权、是否过期，验证通过后，才能提供服务。

OAuth2应用场景

第三⽅授权登录的场景：⽐如，我们经常登录⼀些⽹站或者应⽤的时候，可以选择使⽤第三⽅授权登录的⽅式，⽐如：微信授权登录、QQ授权登录、微博授权登录等，这是典型的 OAuth2 使⽤场景。

单点登录的场景：如果项⽬中有很多微服务或者公司内部有很多服务，可以专⻔做⼀个认证中⼼（充当认证平台⻆⾊），所有的服务都要到这个认证中⼼做认证，只做⼀次登录，就可以在多个授权范围内的服务中⾃由串⾏。

OAuth2的颁发Token授权方式

1）授权码（authorization-code）
2）密码式（password）提供⽤户名+密码换取token令牌
3）隐藏式（implicit）
4）客户端凭证（client credentials）