以前的开发模式是以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 / "-" / "." / "_" / "~" / "+" / "https://www.jb51.net/" ) *"=" 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的时候是这样的吗？
那么除了前端有明确的使用规范，那么服务端又应该怎样有效的做好后端数据防护？在白皮书中同样也有提到过。
根据OAuth 2.0动态客户端注册协议该规范定义了向授权服务器动态注册OAuth 2.0客户端的机制。注册请求向授权服务器发送一组所需的客户端元数据值（token）。结果的注册响应返回要在授权服务器上使用的客户机标识符和为客户机注册的客户机元数据值。然后，客户机可以使用此注册信息使用OAuth 2.0协议与授权服务器通信。该规范还定义了一组通用客户端元数据字段和值，供客户端在注册期间使用。
为了让OAuth 2.0 [RFC6749]客户机利用OAuth 2.0授权服务器，客户机需要与服务器交互的特定信息，包括在该服务器上使用的OAuth 2.0客户端标识符。该规范描述了如何通过授权服务器动态注册OAuth 2.0客户端来获取此信息。
抽象的动态客户端注册流程