1，前言

在这里总结一下工作中遇到的鉴权和授权的方法

① 固定token的方案

通过在nginx或者代码中写死token，或者通过在限制外网访问的方式已来达到安全授权的方式

② session方案

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中。当用户访问微服务时，用户数据可以从共享存储中获取。

③ 客户端token方案

例如JWT，令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。

④ 第三方授权的方案

遵循OAuth2.0的一种第三方授权，可分为4种模式

⑤ API请求签名

API签名主要使用在系统间进行交互时。采用API签名，第一是保证请求的数据正确性、保证接口安全；第二是识别API调用者的身份。

 

2，固定token

这是一种偷工减料的方案，在发送请求时，在cookie中带入固定值，在nginx中判断cookie中的值是否正确，如果正确则允许访问服务器，当然这种方案很不安全，在生产环境中不推荐使用。

 

3，Session认证

用户登录认证成功后，将用户相关数据存储到 Session 中，单体应用架构中，默认 Session 会存储在应用服务器中，并且将 Session ID 返回到客户端，存储在浏览器的 Cookie 中。

如果是在分布式集群中，可以用DB或者类似于Redis的缓存来存储。

 

4，客户端Token

Token 和 Session ID 不同，并非只是一个 key。Token 一般会包含用户的相关信息，通过验证 Token 就可以完成身份校验。

①，用户输入登录信息，发送身份信息到身份认证服务进行认证

②，在身份认证服务处通过认证，身份认证服务选择用户储存的且自己需要的信息（比如用户id），使用哈希算法通过一个秘钥生成token

③，用户将Token放在HTTP请求头中，发起相关API调用

④，被调用的服务通过调取身份认证服务，验证token权限（认证服务器会通过secret和哈希算法解出信息）

⑤，服务器返回相关资源和数据

 

在这里我们主要介绍JWT，参考：jwt.io

 

5，第三方授权

在这里讲的授权遵守OAuth2.0协议，OAuth 是一种开放的协议，为桌面程序或者基于 BS 的 web 应用提供了一种简单的，标准的方式去访问需要用户授权的 API 服务。

OAuth2.0的流程：

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

客户端的授权模式

（1）授权码模式

通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。例：微信平台

· 用户访问客户端，后者将前者导向认证服务器。
· 用户选择是否给予客户端授权。
· 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向 URI"（redirection URI），同时附上一个授权码。
· 客户端收到授权码，附上早先的"重定向 URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
· 认证服务器核对了授权码和重定向 URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

（2）简化模式

不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤

· 客户端将用户导向认证服务器。
· 用户决定是否给于客户端授权。
· 假设用户给予授权，认证服务器将用户导向客户端指定的"重定向 URI"，并在 URI 的 Hash 部分包含了访问令牌。
· 浏览器向资源服务器发出请求，其中不包括上一步收到的 Hash 值。
· 资源服务器返回一个网页，其中包含的代码可以获取 Hash 值中的令牌。
· 浏览器执行上一步获得的脚本，提取出令牌。

· 浏览器将令牌发给客户端。

（3）密码模式

用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

· 用户向客户端提供用户名和密码。
· 客户端将用户名和密码发给认证服务器，向后者请求令牌。

· 认证服务器确认无误后，向客户端提供访问令牌。

（4）客户端模式

· 客户端向认证服务器进行身份认证，并要求一个访问令牌。

· 认证服务器确认无误后，向客户端提供访问令牌。

 

6，API请求签名

签名过程如下：

· 调用方申请App Key 和 App Secret

· 在生成请求时，使用所有字母顺序排序后拼接的字符串 + App Secret 拼接后进行MD5加密，然后将 App Key， 加密结果追加到请求上。

· 服务收到请求后，根据App Key识别出调用方，然后从字典中查询到对应的App Secret，与请求参数拼接、加密，与请求中的签名进行对比，签名结果相同的为合法请求。

这种签名方式符合上一节提到的使用签名的目的：由于请求的参数会作为签名的一部分，所以请求参数变化后，签名结果一定会随之发生变化，否则将无法认证通过；通过App Key 可以快速识别出API 调用者的身份，而无需与实际业务逻辑掺杂起来