随着云计算，docker，k8s等的发展，喊了很多的soa伴随着微服务的大发展，终于落地了。
从多年前的dubbo，gRPC，到作为目前最主流的“微服务框架”，Spring boot/spring Cloud发展速度很快，成为了最全面的微服务解决方案。不管什么软件体系，什么框架，安全永远是不可能绕开的话题。
和dubbo的tcp/ip 长连接不一样，spring cloud采用的是http协议，拥抱天然跨语言的RESTful方式。由于http的无状态性，那么如何采用一个简单而可行方式来保护Spring Cloud中服务的安全呢？
其实很简单，答案是：
建立统一的用户授权中心
统一的用户授权中心主要包含两块的功能：
1，Authentication（认证）
2，Authorization（鉴权）
认证关心你是谁，鉴权关心你能干什么。
认证 的作用在于认可你有权限访问系统，用于鉴别访问者是否是合法用户；而 授权 用于决定你有访问哪些资源的权限。
Authorization Server/Identity Provider(IdP) VS Service Provider(SP)/Resource Server
把负责认证的服务称为 Authorization Server 或者 Identity Provider，以下简称 IdP；而负责提供资源（API调用）的服务称为 Resource Server 或者 Service Provider，以下简称 SP
为了实现统一的用户授权中，可以采用OAuth 2和JWT(JSON Web Tokens)技术作为解决方案。
为了方便大家理解，需要我们先弄清楚一些概念
什么是Token
token 即使是在计算机领域中也有不同的定义，这里我们说的token，是指 访问资源的凭据 。例如当你调用Google API，需要带上有效 token 来表明你请求的合法性。这个 token 是 Google 给你的，这代表 Google 给你的授权使得你有能力访问 API 背后的资源。
请求 API 时携带 token 的方式也有很多种，通过 HTTP Header 或者 url 参数。
例如：
/ HTTP Header:
GET /drive/v2/files HTTP/1.1
Authorization: Bearer <token>
Host: open.taobao.com/// URL query string parameter
GET https://open.taobao.com/drive/v2/files?token=<token>
什么是OAuth 2.0
从获取 token 到使用 token 访问接口。这其实是标准的 OAuth 2.0 机制下访问 API 的流程。这一节我们聊一聊 OAuth 里外相关的概念，更深入的理解 token 的作用。
- 用户通过客户端（可以是浏览器也可以是手机应用）想要访问 SP 上的资源，但是 SP 告诉用户需要进行认证，将用户重定向至 IdP
- IdP 向用户询问 SP 是否可以访问用户信息，如果用户同意，IdP 向客户端返回 access code
- 客户端拿 code 向 IdP 换 access token，并拿着 access token 向 SP 请求资源
SP 接受到请求之后拿着附带 token 向 IdP 验证用户的身份
OAuth 的本意是一个应用允许另一个应用在用户授权的情况下访问自己的数据,OAuth 的设计本意更倾向于授权而非认证（当然授权用户信息就间接实现了认证） , 比如微信、QQ登录同时支持授权和认证。所以你在使用 微信 或者 QQ 账号登陆第三方站点时，会出授权对话框告诉你第三方站点可以访问你的哪些信息，需要征得你的同意：
什么是JWT
Json Web Token, 简称 JWT。
JWT 顾名思义，它是 JSON 结构的 token，由三部分组成：
- header
- payload
- signature
- header
header 用于描述元信息，例如产生 signature 的算法：
{
"typ": "JWT",
"alg": "HS256"
}
其中 alg 关键字就指定了使用哪一种哈希算法来创建 signature
- payload
payload 用于携带你希望向服务端传递的信息。你既可以往里添加官方字段（这里的“字段” (field) 也可以被称作“声明” claims），例如 iss (Issuer), sub (Subject), exp (Expiration time)，也可以塞入自定义的字段，比如 userId :
{
"userId": "b08f86af-35da-48f2-8fab-cef3904660bd"
}
- signature 译为「签名」
创建签名要分以下几个步骤：
你需要从接口服务端拿到密钥，假设为 secret
将 header 进行 base64 编码，假设结果为 headerStr
将 payload 进行 base64 编码，假设结果为 payloadStr
将 headerStr 和 payloadStr 用 . 字符串拼装起来成为字符 data
以 data 和 secret 作为参数，使用哈希算法计算出签名
如果上述描述还不直观，用伪代码表示就是：
// signature algorithm
data = base64urlEncode( header ) + “.” + base64urlEncode( payload )
signature = Hash( data, secret );
假设我们的原始 JSON 结构是这样的：
// Header
{
"typ": "JWT",
"alg": "HS256"
}
// Payload:
{
"userId": "b08f86af-35da-48f2-8fab-cef3904660bd"
}
如果密钥是字符串 secret 的话，那么最终 JWT 的结果就是这样的
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y
由此可见
JWT 的目的不是为了隐藏或者保密数据，而是为了确保数据确实来自被授权的人创建的（不被篡改）
