一：token的优势（此部分引自http://www.sumahe.cn/）


    1.无状态、可扩展


        在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服  务   传到其他服务器上。


    如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成  一些拥堵。但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。



    2.安全性



    请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。


    token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。



          
 3.可扩展性

Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。


4.多平台跨域

我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用户有一个通过了验证的token，数据和资源就能够在任何域上被请求到。
          Access-Control-Allow-Origin: *       


5.基于标准

创建token的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在JSON Web Tokens体现。

最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。




二.Token的原理










1.将荷载payload，以及Header信息进行Base64加密，形成密文payload密文，header密文。



2.将形成的密文用句号链接起来，用服务端秘钥进行HS256加密，生成签名.



3.将前面的两个密文后面用句号链接签名形成最终的token返回给服务端

注：

（1）用户请求时携带此token（分为三部分，header密文，payload密文，签名）到服务端，服务端解析第一部分（header密文），用Base64解密，可以知道用了什么算法进行签名，此处解析发现是HS256。


（2）服务端使用原来的秘钥与密文(header密文+"."+payload密文)同样进行HS256运算，然后用生成的签名与token携带的签名进行对比，若一致说明token合法，不一致说明原文被修改。

 （3）判断是否过期，客户端通过用Base64解密第二部分（payload密文），可以知道荷载中授权时间，以及有效期。通过这个与当前时间对比发现token是否过期。

三，实现思路






1.用户登录校验，校验成功后就返回Token给客户端。

2.客户端收到数据后保存在客户端

3.客户端每次访问API是携带Token到服务器端。

4.服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

注：如果其中有错误请大家指出，希望大家共同进步

以往我们讲到CSRF，谈及都是CSRF的攻击原理，这次讲一下预防CSRF，生成Token背后的加密原理和具体实现例示。

1.Token构成。

从需求功能上来讲，为了防止CSRF工具，token需要具有不重复，另外，还含有特定的功能信息，比如过期时间戳。

下面的图描述了一个token的数据构成：

Token的数据结构。
----------------------------------------------------------------------------- |             msg                  |        separator       |           signature                    | ----------------------------------------------------------------------------- |     key     |   timestamp  |              .               |    Base64(sha256(msg))        | -----------------------------------------------------------------------------

token由三部分组成：a).msg b). separator c).signature。

a). msg部分：而msg本身也有两部分组成：一部分，随机字符的主体，另一部分是过期时间戳。

b). 分隔符号：用符号分隔msg部分，和加密后生成的signature签名部分，这里用的是”.“

c). 签名signature。

signature签名，是对上面提到的msg，按照msg中提到的msg的信息部分，按照特定的秘锁进行加密。
token = base64(msg)格式化..base64(sha256("秘锁", msg))

 
2.Token的加密。首先，是按照合适得加密方法对数据进行加密。这里我们通用的就使用了sha256散列算法，然后进行BASE64的格式转换。然后，我们需要在token串中隐含过期时间的设定，从需求上讲，每条与服务器交互的token有是有过期时间的，超过这个时间范围，就无效了，需要重新从服务器中取得。

 

3.Token的验证。

当用户从客户端，得到了token,再次提交给服务器的时候，服务器需要判断token的有效性，否则不加判断直接处理数据，token的生成就无意义了。

验证的过程是:

a). token解包。

先把接受到的token，进行分解。“.”为分隔符，分为msg部分+signature签名部分。

b). 比对签名。

对msg部分进行base64解码, decode_base64(msg)然后在对解码后的msg明文，进行同样的encode_base64(sha256(msg))加密。秘锁相同，然后，判断加密后的数据和客户端传过来的token.signature的部分是否一致。如果一致，说明这个token是有效的。

c). 判断时间过期。如果是有效的,取出msg.timestamp，和当前系统时间进行比较，如果过期时间小于当前时间，那这个token是过期的，需要重新的取得token。

原理都通用，此处使用lua对上处理过程进行描述。



?





1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52




local
 gen_token = function(key, expires)

    --做成一个过期时间戳。

    ifexpires
 == nil then

     expires
 = os.time() + 60+
60*
8

    end

    

    --对msg部分进行base64编码。

    local
 msg = encode_base64(

     json.encode({

         key
 = key,

         expires
 = expires

     }))

      

   --进行sha256哈希。

    local
 signature = encode_base64(hmac_sha256('testkey',
 msg))

     

    --拼接成一条token。

    returnmsg
 .. "."..signature

end

 

 

local 
 val_token = function(key,token)

    --对输入数据的判空操作

    ifnot
 (token) then

     returnnil,
'mssing
 csrf token'

    end

     

    --对token的msg部分，signature签名部分进行拆分。

    local
 msg, sig = token:match("^(.*)%.(.*)$")

    ifnot
 (msg) then

         returnnil,
"malformed
 csrf token"

    end

 

    --对解包后msg，按照相同的加密key:"testkey"，重新进行sha256哈希，比对signature，

    --如果不一致，说明这个token中的数据有问题，无效的token。

    ifnot
 (sig == hmac_sha256('testkey',
 msg)) then

         returnnil,
"invalid
 csrf token(bad sig)"

    end

 

 

    --对msg进行base64解码，判断其中的key和传入的key是否一致。

    --如果不一致说明token也是无效的。

    msg
 =json.decode(decode_base64(msg))

    ifnot
 (msg.key == key) then

     returnnil,
"invalid
 csrf token (bad key)"   

    end

     

    --取出msg部分的时间戳，判断是否大于当前时间，如果大于，说明token过期无效了。

    ifnot
 (not msg.expires or msg.expires > os.time()) then

         returnnil,
"csrf
 token expired"

    end

end








 

下面是关于Lua语言加密库，lua语言有别于其他语言，没有同意的官方指定加密库，为了便于读者，看后实践，下面对lua的加密库进行了补充描述。lua语言是一种弱类型的语言，简单明了，对于描述某些课题，便于表述，类似于伪语言，操作起来也很轻便，便于实践推敲算法。即使之后不适用lua，也可以很方面的迁移到其他语言。

我们在开发的工作中，难免要对一些数据进行加密处理，而加密模块的使用有是就必不可少。在lua官方的WIKI列表中就列出了，很多lua程序写的加密库，这写加密库有的是用纯lua写的，也有用lua调用C的程序实现加密。不过有些时候甄选这些库还是需要花一些时间精力，只是需要测试一下这是加密算是否是好用的。这是lua组织列出的一览列表。
 http://lua-users.org/wiki/CryptographyStuff

说一下为什么要加密，我们面临的任务是什么！我们现在面临的任务是，要对一段字符串进行sha256算法加密。

我们从列表中选出了几个支持sha256加密的包，并说明一下这几个工具包。

1.SecureHashAlgorithm和SecureHashAlgorithmBW

这个工具包是支持sha256加密的，而且是纯lua方法的实现，问题是，这两个包分别依赖lua5.2和lua5.3。

而我们系统的运行环境是lua5.1，因为大部分的生产环境都是lua5.1，因为历史原因暂时没法改变。如果要把5.2的程序移植到5.1下运行，还需要移植一个lua5.2才独有的包，这是lua5.2升级之后才有的部件：bit32,而在lua5.3中又将这个部件去掉了,移植的动力不大，暂时不使用这个包。

2.Lcrypt

这个包不是纯lua的实现，底层加密用的是C语言，而且额外还有依赖另外另个工具包 libTomCrypt和libTomMath，这两个包的官网已经被和谐了，github上有源码，所以要想让这个包正常运行需要手动make安装3个源码工程，还是算了，有时间的时候再装好测试一下，先暂时不用。

网站：
http://www.eder.us/projects/lcrypt/

 

3.LuaCrypto

这个包的安装用的是luarocks，就比较简单了
 luarocks install luacrypto  

我们选用这个包进行加密处理。

LuaCrypto其实是openssl库的前端lua调用，依赖openssl，openssl库显然会支持sha256加密，相对也比一般的第三方实现更可靠。

写一个简单的加密程序：



?





1

2

3

4




local
 crypto = require("crypto")

local
 hmac = require("crypto.hmac")

local
 ret = hmac.digest("sha256","abcdefg","hmackey")

print(ret)








ret的返回结果是，如下这个字符串。
 704d25d116a700656bfa5a6a7b0f462efdc7df828cdbafa6fbf8b39a12e83f24 

我们需要改造一下代码，在调用digest的时候指定输出的形式是raw二进制数据形式，然后在编码成base64的数据形式。
local ret = hmac.digest("sha256", "abcdefg", "hmackey",rawequal) print(ret) 

 

这时候的输出结果是：
 cE0l0RanAGVr+lpqew9GLv3H34KM26+m+/izmhLoPyQ= lua-base64 

使用的是下面的库，lua库就是这样，有很多功能程序有很多的实现，并且很多非官方的第三方实现。
 https://github.com/toastdriven/lua-base64

本文实例讲述了PHP token验证生成原理。分享给大家供大家参考，具体如下：
/**
* @Author: Ding Jianlong
* @Date:  2019-03-20 00:38:01
* @Last Modified by:  Ding Jianlong
* @Last Modified time: 2019-03-22 17:50:59
*/
//生成发送请求的验证 token
//这里的key可以是包含用户信息的内容，不用用户+不同的权限
function makeToken($key){
//100秒内有效，不变，时间根据实际需要调整。第三方登录授权15天。
return $token = md5($key.sha1(substr(time(),3,7)));
}
//后台同理验证，
function checkToken($key,$token){
$true = md5($key.sha1(substr(time(),3,7)));
if($token == $true){
return true;  //token正确
}else{
return false;
}
}
$key = 'https://github.com/idjl/';
echo $t = makeToken($key);
var_dump(checkToken($key,'259521122'));
var_dump(checkToken($key,$t));
var_dump(checkToken($key,'259521122'));
运行结果：
e4ce1a6c66246eee048f11a540bf197ebool(false)
bool(true)
bool(false)
希望本文所述对大家PHP程序设计有所帮助。

什么是token?
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
基于 Token 的身份验证
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。流程是这样的：
1.客户端使用用户名跟密码请求登录
2.服务端收到请求，去验证用户名与密码
3.验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
4.客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
5.APP登录的时候发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果成功，以某种方式比如随机生成32位的字符串作为token，存储到服务器中，并返回token到APP，以后APP请求时，
凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让他重新登录。其中服务器上token设置一个有效期，每次APP请求的时候都验证token和有效期。
token的优势
1.无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成 一些拥堵。但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。
2.安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。
3.可扩展性
Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。
4.多平台跨域
我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.只要用户有一个通过了验证的token，数据和资源就能够在任何域上被请求到。Access-Control-Allow-Origin: *
5.基于标准
创建token的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在JSON Web Tokens体现。最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。
token原理
1.将荷载payload，以及Header信息进行Base64加密，形成密文payload密文，header密文。
2.将形成的密文用句号链接起来，用服务端秘钥进行HS256加密，生成签名.
3.将前面的两个密文后面用句号链接签名形成最终的token返回给服务端
注：
(1)用户请求时携带此token(分为三部分，header密文，payload密文，签名)到服务端，服务端解析第一部分(header密文)，用Base64解密，可以知道用了什么算法进行签名，此处解析发现是HS256。
(2)服务端使用原来的秘钥与密文(header密文+"."+payload密文)同样进行HS256运算，然后用生成的签名与token携带的签名进行对比，若一致说明token合法，不一致说明原文被修改。
(3)判断是否过期，客户端通过用Base64解密第二部分(payload密文)，可以知道荷载中授权时间，以及有效期。通过这个与当前时间对比发现token是否过期。
token实现思路
1.用户登录校验，校验成功后就返回Token给客户端。
2.客户端收到数据后保存在客户端
3.客户端每次访问API是携带Token到服务器端。
4.服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
token代码生成工具类demo
package com.frank.common.utils;
import com.alibaba.fastjson.JSON;
import com.frank.common.entity.TokenHeader;
import com.frank.common.entity.TokenPlayload;
import com.frank.common.entity.User;
import java.rmi.server.UID;
import java.util.UUID;
/**
Description:Token生成工具
第一部分我们称它为头部(header),第二部分我们称其为载荷(payload, 类似于飞机上承载的物品)，第三部分是签证(signature).
Auth: Frank
Date: 2020-11-05
Time: 下午 5:05
*/
public class TokenUtil {
public static final String TOKEN_AES_KEY = "xiangli8Token";
public static final String REFREH_TOKEN_AES_KEY = "xiangli8RefreshToken";
public static final String JWT_TYP = "JWT";
public static final String JWT_ALG = "AES";
public static final String JWT_EXP = "30";
public static final String JWT_ISS = "xiangli8";
/**
* 获得token
* @param data 自定义数据
* @param  自定义数据
* @return
* @throws Exception
*/
public static  String getToken(T data) throws Exception {
TokenPlayload userTokenPlayload = new TokenPlayload<>();
userTokenPlayload.setExpData(data);
String jwt = createJWT(userTokenPlayload);
return jwt;
}
/**
* 生成jwt的header部分内容
* @return
* @throws Exception
*/
private static String tokenHeaderBase64() throws Exception {
TokenHeader tokenHeader = new TokenHeader();
tokenHeader.setTyp(JWT_TYP);
tokenHeader.setAlg(JWT_ALG);
String headerJson = JSON.toJSONString(tokenHeader);
String headerBase64 = Base64Util.encryptBASE64(headerJson.getBytes());
return headerBase64;
}
/**
* 生成jwt的payload部分内容
* @param tokenPlayload
* @param 自定义的数据块
* @return
* @throws Exception
*/
private static  String tokenPayloadBase64(TokenPlayload tokenPlayload) throws Exception {
tokenPlayload.setIss(JWT_ISS);
tokenPlayload.setExp(JWT_EXP);
tokenPlayload.setIat(String.valueOf(System.currentTimeMillis()));
String headerJson =JSON.toJSONString(tokenPlayload);
String headerBase64 = Base64Util.encryptBASE64(headerJson.getBytes());
return headerBase64;
}
/**
生成JWT
@return
*/
public static  String createJWT(TokenPlayload tokenPlayload) throws Exception {
StringBuilder jwtSb = new StringBuilder();
StringBuilder headerPlayloadSb = new StringBuilder();
String tokenHeaderBase64 = tokenHeaderBase64();
String tokenPayloadBase64 = tokenPayloadBase64(tokenPlayload);
jwtSb.append(tokenHeaderBase64);
jwtSb.append(".");
jwtSb.append(tokenPayloadBase64);
jwtSb.append(".");
headerPlayloadSb.append(tokenHeaderBase64);
headerPlayloadSb.append(tokenPayloadBase64);
String headerPlayloadSalt = SaltUtil.addSalt(headerPlayloadSb.toString());
String key = AesUtil.initKey(TOKEN_AES_KEY+tokenPlayload.getIat());
String signature = Base64Util.encryptBASE64(AesUtil.encrypt(headerPlayloadSalt.getBytes(),key));
jwtSb.append(signature);
return Base64Util.encryptBASE64(jwtSb.toString().getBytes());
}
/**
* 校验token是否是服务器生成的，以防token被修改
* @param jwtBase64
* @return
* @throws Exception
*/
public static  boolean verifyJWT(String jwtBase64) throws Exception {
String jwt = new String (Base64Util.decryptBASE64(jwtBase64));
if(!jwt.contains(".")){
return false;
}
String[] jwts = jwt.split("\\.");
if(jwts.length<3){
return false;
}
TokenPlayload tTokenPlayload = JSON.parseObject(new String(Base64Util.decryptBASE64(jwts[1])),TokenPlayload.class);
String key = AesUtil.initKey(TOKEN_AES_KEY+tTokenPlayload.getIat());
//解析出header跟playload
StringBuilder headerPlayloadSb = new StringBuilder();
headerPlayloadSb.append(jwts[0]);
headerPlayloadSb.append(jwts[1]);
//解析signature
String headerPlayloadSalt = new String (AesUtil.decrypt(Base64Util.decryptBASE64(jwts[2]),key));
return SaltUtil.verifyPwd(headerPlayloadSb.toString(),headerPlayloadSalt);
}
public static void main(String[] args) throws Exception {
String jwt = getToken(new User(1L,"你是逗逼"));
System.out.println("jwt:"+jwt);
System.out.println("verifyJWT:"+verifyJWT(jwt));
}
}
使用说明
1，根据上面生成一个由base64编码的token，该token由Header，Payload，Signature组成。
2，token作为用户请求的标识，客户端保存这token的全部信息。服务端只需要保存token的Signature部分。
3，服务端把token的Signature存于redis和服务器的数据库中。
4，客户端请求的数据附带token，服务端拿到token，首先校验token，以防token伪造。校验规则如下：
4.1，拆分出token的Header，Payload，Signature。
4.2，校验Signature，通过token的header和payload生成Signature，看看生成的Signature是否和客户端附带上来的Signature一致。如果一致继续请求操作，不一致则打回操作
4.3，查看Signature是否存在服务器的redis和数据库中。如果不存在则打回请求操作
差不多也是这些东西