微服务实战系列之Token

前言

什么是“Token”？ 它是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便返回给客户端；以后客户端只携带此Token请求数据即可。

简言之，Token其实就是用户身份的另一个标识而已，取代了繁琐的用户和密码校验，同时也减轻了服务器的压力，减少频繁的数据库交互，使服务器更加健壮。

那么我们在应用中如何使用token呢？且听博主分解。

---

流程原理

1. OAuth2.0

我们在熟悉Token之前，先了解一下“OAuth2.0”，各位盆友可能有疑问，这又是什么东东？能干嘛？

“OAuth（Open Authorization）”是一个关于授权（authorization）的开放网络标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。
目前已开放的标准是2.0，于是我们通常简称为“Oauth2.0”协议。

在这个协议或标准基础之上，提供了4种授权模式，今天我们重点讲其中一种：“授权码模式”。

授权码（authorization code）模式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

这种方式目前是最常用的模式，兼顾安全与性能。同时令牌存储在后端，在前后端分离场景下，可以避免令牌泄漏。

2. Token（令牌）

有了前面的背景知识，是不是大概也理解了OAuth的意义了？接下来我们看Token是怎么回事，它有哪些作用？

• Token完全由应用程序进行管理，所以它可以避开同源策略；
• Token可以避免CSRF（跨站请求访问）攻击；
• Token可以是无状态的，可以在多个服务器之间共享；
• 使用Token减轻服务器的压力，减少频繁的查询数据库。

所以，从以上作用来看，还是达到了“降本增效”的目的，这也正反映当代世界的一个主题：“节能减排，绿色环保”。

应用实践

到此为止，大家是否已学习了到关于Token的理论知识呢？接下来我们看在实际应用中，应该如何处理。

1. appKey/appSecret

首先看一组名词解释：

“appKey”：名为应用标识，通常代表客户身份，即客户端的唯一标识。
“appSecret”：名为应用密钥，通常与appK组合配对使用，用于客户身份认证。

通常appKey作为公钥存在，可以用于数据传输；而appSecret作为私钥存在，只能在服务端存储，禁止网络传输。

从发展趋势而言，以“appKey/appSecret”组合使用，可以灵活定义客户端使用权限，从而提高了用户管理能力，这也正是当前建设OpenAPI的基础。

2. 生成Token

当客户收到一组“appKey/appSecret”, 便可通过token服务获取授权。如果认证通过后，服务端即向客户端颁发令牌Token。因为Token具备时效性，需根据实际情况定义。
请看Token调用示例：

{
    "appKey": "c5fc1ce17ea311eb02628fce294",
    "appSecret": "f0310ba586bb0e73c375"
}
1
2
3
4

{
    "code": 200,
    "msg": "认证成功",
    "data": {
        "access_token": "eyJhbGciOiJIUzUxMiJ9.eyJ1c2VyX2lkIjoiRklOMSIsInVz",
        "expires_in": 120
    }
}
1
2
3
4
5
6
7
8

3. 使用Token

有了Token这块金字“腰牌”，我们可以一定程度上，掌握了主动，在有限的时间内，可以自由支配授权的资源。那如何支配呢？即需要的时候，主动出示Token即可。此时，我们把镜头转向如何出示的画面：

各位盆友，谜底已揭晓，学到了吧？通过Header传参实现Token的出示和后续的服务认证。此刻，我们已经一只脚踏入了客户的家门。

---

好了，夜深了，博主也该休息了。今天分享到这里，欢迎路过的、拿凳的、嗑瓜子的盆友们，分享与讨论。
咱们有空接着聊~