深入理解令牌认证机制（深入理解令牌认证机制（token））
主要介绍了深入理解令牌认证机制（token），文中通过示例代码介绍的非常详细，对大家的学习或者工作具有
一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
以前的开发模式是以MVC为主，但是随着互联网行业快速的发展逐渐的演变成了前后端分离，若项目中需要做登录的话，那
么token成为前后端唯一的一个凭证。
token即标志、记号的意思，在IT领域也叫作令牌。在计算机身份认证中是令牌（临时）的意思，在词法分析中是标记的意
思。一般作为邀请、登录系统使用。
token其实说的更通俗点可以叫暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据操作。例如
在USB1.1协议中定义了4类数据包：token包、data包、handshake包和special包。主机和USB设备之间连续数据的交换可以
分为三个阶段，第一个阶段由主机发送token包，不同的token包内容不一样（暗号不一样）可以告诉设备做不同的工作，第二
个阶段发送data包，第三个阶段由设备返回一个handshake包。
在HTTP请求中使用承载令牌来访问OAuth 2.0受保护的资源。拥有承载令牌的任何一方(“承载方”)都可以使用它访问相关资源
(无需证明拥有加密密钥)。为了防止误用，需要防止在存储和传输中泄露承载令牌。
OAuth允许客户端通过获取访问令牌，它在“OAuth 2.0授权”中定义框架“[RFC6749]作为”表示访问的字符串而不是使用资源直
接服务的凭证。
该令牌由服务端允许的情况下，由客户端通过某种方式向服务端发出请求，由服务端向客户端发出，客户机使用访问令牌访问
由资源服务器承载的受保护的资源。该规范描述了当OAuth访问令牌是承载令牌时，如何发出受保护的资源请求。
客户端只需要拥有token可以以任何一种方法传递token，客户端需要知道参数加密的密钥，只需要存储token即可。
OAuth为客户端提供了一种方法来代表资源所有者访问受保护的资源。在一般情况下，客户机在访问受保护的资源之前，必须
首先从资源所有者获得授权，然后将授权交换为访问令牌。访问令牌表示授权授予授予的范围、持续时间和其他属性。客户机
通过向资源服务器显示访问令牌来访问受保护的资源。在某些情况下，客户端可以直接向服务端显示的发送自己的凭证。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
此方案的Authorization头字段的语法遵循[RFC2617]第2节中定义的基本方案的用法。注意，与Basic一样，它不符合
[RFC2617]第1.2节中定义的通用语法，但与正在为HTTP 1.1 [HTTP- auth]开发的通用身份验证框架兼容，尽管它没有遵循其
中列出的反映现有部署的首选实践。承载凭证的语法如下
b64toke = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
客户端应该使用带有承载HTTP授权方案的Authorization请求头字段使用承载令牌发出经过身份验证的请求。资源服务器必须
支持此方法。
在Internet Engineering Task Force (IETF)的白皮书中介绍Bearer Token的使用方法，那么我们平时使用token的时候姿势是否
正确。应该如何正确使用token呢？
import axios from "axios";
axios.interceptors.request.use(config => {
if (store.state.token) {
config.headers.authorization = `Basic ${store.state.token}`;
}
return config;
});
照白皮书所说这样才是正确使用token的姿势。小伙伴们平时你们使用token的时候是这样的吗？
那么除了前端有明确的使用规范，那么服务端又应该怎样有效的做好后端数据防护？在白皮书中同样也有提到过。
评论0