token一直验证失败，不知道为什么

“token”验证一直失败是因为：

1、服务器没有正确响应Token验证，请阅读消息接口使用指南。

这样回头检查一下各项配置是否正确。

2、请求URL超时

如果服务器在国外，或者服务器网速不给力，一般多试几次就可以了。如果经常这样，就需要考虑更换服务器。

令牌是一种能够控制站点占有媒体的特殊帧，以区别数据帧及其他控制帧。token其实说的更通俗点可以叫暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据 *** 作。

例如在USB11协议中定义了4类数据包：token包、data包、handshake包和special包。主机和USB设备之间连续数据的交换可以分为三个阶段，第一个阶段由主机发送token包，不同的token包内容不一样（暗号不一样）可以告诉设备做不同的工作，第二个阶段发送data包，第三个阶段由设备返回一个handshake包。

和token相关的计算机术语很多，例如Token Passing、Token Ring、Token Bus等，具体参考一些计算机令牌方面的资料。

可以，不用存储
服务端不用存储认证数据,易维护扩展性强 客户端可以把token存在任意地方、 适合统一认证的机制,客户端、一方应用、三方应用都遵循一致的认证机制 token认证方式对第三方应用接入更适合,因为它更开放,可使用当前有流行的开放协议

随着信息化进程的加快，现在的网站和APP应用很常见，对于普通用户而言我们只能看到表现层（界面视图层），而内部的的数据交互及处理靠的是一个个API来实现的。所谓的API是指应用程序接口，也就是将特定的业务功能封装起来供第三方调用，现在的API有很多种形式，而WebAPI是最常见和便捷的。

既然API是提供给第三方调用的，这就存在一个问题：很多时候我们希望API只能由自家的产品去调用，防止他人调用，这该如何实现呢？这就得靠接口鉴权了。

什么是接口（API）鉴权？

正如上面所说，如果把API接口直接暴露在互联网上是存在安全风险的，所以我们需要对API进行权限划分，对接口调用方做一个用户鉴权，如果鉴权通过则允许此用户进行API调用，反之则拒绝。

根据不同的业务场景，接口鉴权方案也有很多种，下面详细给大家介绍。

Cookie+Session机制实现WebAPI的鉴权

这种机制是最为传统的，特别是在网站中的登录模块靠的就是Cookie+Session来实现会话管理的。

1、实现原理

后台为了标识请求是哪个客户端发现的，会在服务端生成一个Session来保存会话状态，各个Session是靠具有唯一性的SessionID来标识的，SessionID存储在客户端的Cookie中；后续所有请求都会把Cookie传到服务器端，服务器端解析Cookie后找到对应的Session进行判断。

2、优点

技术实现方便。

3、缺点弊端

不适合分布式应用，跨平台性差

Cookie传输会影响通信性能

>

存在安全风险：因为Cookie是存储在客户端的，客户端可以随意更改Cookie，存在伪造请求的风险

Token机制实现WebAPI的鉴权

Token（令牌）是用来替代Session的新兴鉴权方案，现在的WebAPI基本上离不开Token令牌。

1、实现原理

Token是服务器端生成的一串加密串发放给客户端，客户端请求服务器端所有资源时会带上这个Token（通过GET/POST/Header来传递），由服务器端来校验这个Token的合法性。

2、优点

真正的无状态，适合分布式，扩展性好

性能高，安全性好

3、Token的实现形式

Token令牌技术是一种技术方案统称，具体的实现方案是有所差别的，最常见的Token种类有以下几种：

自定义实现Token：应用开发者根据Token机制原理自行实现

JWT：JsonWebToken，是一种主流的Token规范

Oauth：Oauth本质上是授权规范，其中也用到了Token

>

WebAPI是基于>

>

基本认证

摘要认证

但是这种机制日常很少使用，因为>区别在于：
登出是指客户端主动退出登录状态。容易想到的方案是，客户端登录成功后， 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。
服务器判断用户是否登录， 完全依赖于sessionId, 一旦其被截获， 黑客就能够模拟出用户的请求。于是我们需要引入token的概念： 用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。
客户端向服务器第一次发起登录请求（不传输用户名和密码）。
服务器利用RSA算法产生一对公钥和私钥。并保留私钥， 将公钥发送给客户端。
客户端收到公钥后， 加密用户密码，向服务器发送用户名和加密后的用户密码； 同时另外产生一对公钥和私钥，自己保留私钥, 向服务器发送公钥； 于是第二次登录请求传输了用户名和加密后的密码以及客户端生成的公钥。
服务器利用保留的私钥对密文进行解密，得到真正的密码。 经过判断， 确定用户可以登录后，生成sessionId和token， 同时利用客户端发送的公钥，对token进行加密。最后将sessionId和加密后的token返还给客户端。
客户端利用自己生成的私钥对token密文解密， 得到真正的token。

---