微服务架构下的鉴权，怎么做更优雅？( 三 ) _微服务

文章插图
【微服务架构下的鉴权，怎么做更优雅？】
3. 签名（signature)创建签名需要使用 Base64 编码后的 header 和 payload 以及一个秘钥。将 base64 加密后的 header 和 base64 加密后的 payload 使用。连接组成的字符串，通过 header 中声明的加密方式进行加盐 secret 组合加密，然后就构成了 jwt 的第三部分。
比如：
HmacSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)JWT 的优点：

跨语言，JSON 的格式保证了跨语言的支撑
基于 Token，无状态
占用字节小，便于传输

关于 Token 注销：Token 的注销，由于 Token 不存储在服务端，由客户端存储，当用户注销时，Token 的有效时间还没有到，还是有效的。所以如何在用户注销登录时让 Token 注销是一个要关注的点。一般有如下几种方式：

Token 存储在 Cookie 中，这样客户端注销时，自然可以清空掉
注销时，将 Token 存放到分布式缓存中，每次校验 Token 时区检查下该 Token 是否已注销。不过这样也就失去了快速校验 Token 的优点。
多采用短期令牌，比如令牌有效期是 20 分钟，这样可以一定程度上降低注销后 Token 可用性的风险。

OAuth 2.0 介绍OAuth 的官网介绍：An open protocol to allow secure API authorization in a simple and standard method from desktop and web Applications 。
OAuth 是一种开放的协议，为桌面程序或者基于 BS 的 web 应用提供了一种简单的，标准的方式去访问需要用户授权的 API 服务。OAUTH 认证授权具有以下特点：

简单：不管是 OAuth 服务提供者还是应用开发者，都很容易于理解与使用；
安全：没有涉及到用户密钥等信息，更安全更灵活；
开放：任何服务提供商都可以实现 OAuth，任何软件开发商都可以使用 OAuth；

OAuth 2.0 是 OAuth 协议的下一版本，但不向后兼容 OAuth 1.0，即完全废止了 OAuth 1.0 。
OAuth 2.0 关注客户端开发者的简易性。要么通过组织在资源拥有者和 HTTP 服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为 Web 应用，桌面应用和手机，和起居室设备提供专门的认证流程。
2012 年 10 月，OAuth 2.0 协议正式发布为 RFC 6749 。
授权流程OAuth 2.0 的流程如下：

文章插图

（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。

四大角色由授权流程图中可以看到 OAuth 2.0 有四个角色：客户端、资源拥有者、资源服务器、授权服务器。

客户端：客户端是代表资源所有者对资源服务器发出访问受保护资源请求的应用程序。
资源拥有者：资源拥有者是对资源具有授权能力的人。
资源服务器：资源所在的服务器。
授权服务器：为客户端应用程序提供不同的 Token，可以和资源服务器在统一服务器上，也可以独立出去。

客户端的授权模式客户端必须得到用户的授权（Authorization Grant），才能获得令牌（access token）。OAuth 2.0 定义了四种授权方式：authorizationcode、implicit、resource owner password credentials、client credentials 。
1. 授权码模式（authorization code）授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与 "服务提供商" 的认证服务器进行互动。流程如下：