Json Web Token 简介

1、Json Web Token是干什么
       简称JWT，在HTTP通信过程中，进行身份认证。
       我们知道HTTP通信是无状态的，因此客户端的请求到了服务端处理完之后是无法返回给原来的客户端。因此需要对访问的客户端进行识别，常用的做法是通过session机制：客户端在服务端登陆成功之后，服务端会生成一个sessionID，返回给客户端，客户端将sessionID保存到cookie中，再次发起请求的时候，携带cookie中的sessionID到服务端，服务端会缓存该session（会话），当客户端请求到来的时候，服务端就知道是哪个用户的请求，并将处理的结果返回给客户端，完成通信。
      通过上面的分析，可以知道session存在以下问题：
      1、session保存在服务端，当客户访问量增加时，服务端就需要存储大量的session会话，对服务器有很大的考验；
      2、当服务端为集群时，用户登陆其中一台服务器，会将session保存到该服务器的内存中，但是当用户的访问到其他服务器时，会无法访问，通常采用缓存一致性技术来保证可以共享，或者采用第三方缓存来保存session，不方便。

2、Json Web Token是怎么做的？
      1、客户端通过用户名和密码登录服务器；
      2、服务端对客户端身份进行验证；
      3、服务端对该用户生成Token，返回给客户端；
      4、客户端将Token保存到本地浏览器，一般保存到cookie中；
      5、客户端发起请求，需要携带该Token；
      6、服务端收到请求后，首先验证Token，之后返回数据。
      服务端不需要保存Token，只需要对Token中携带的信息进行验证即可；
      无论客户端访问后台的那台服务器，只要可以通过用户信息的验证即可。

3、Json Web Token长什么样子呢？
      通过名字就可以看出来，是一个json。
      由三部分内容组成：
      头(header)，一般很少改动直接使用默认的即可：
             {
                    'typ':'JWT',
                    'alg':'HS256'
             }
      肚子(playload),东西都装在肚子里，默认的内容有：
            {
                    'iss':'签发者',
                    'sub':'面向的用户',
                    'aud':'接收方',
                    'exp':  过期时间,
                    'iat':  创建时间,
                    'nbf':  在什么时间之前，该Token不可用,
                    'jti':'Token唯一标识'
             }
      根据需要用户可以自己定义，Token中传输的内容，一般会将用户名，角色等信息放到Token中。
      尾(signature),前面两部分转为字符串后，使用base64编码，然后进行加密得到一个字符串。
      Token = 头（base64）+ 肚子（base64）+ 尾；

4、Json Web Token怎么使用呢？
利用Java封装的JJWT实现，下载jar地址为：http://maven.outofmemory.cn/io.jsonwebtoken/jjwt/0.6.0/
还需要依赖包jackson-annotations-2.5.0.jar、jackson-core-2.5.0.jar、jackson-databind-2.5.0.jar，地址：http://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-core/2.5.0
[java] view plain copy
package com.yuxuejian.jwt.test;  
  
import java.security.Key;  
import java.util.Date;  
import java.util.HashMap;  
import java.util.Map;  
  
import javax.crypto.spec.SecretKeySpec;  
import javax.xml.bind.DatatypeConverter;  
  
import io.jsonwebtoken.Claims;  
import io.jsonwebtoken.ExpiredJwtException;  
import io.jsonwebtoken.InvalidClaimException;  
import io.jsonwebtoken.JwtBuilder;  
import io.jsonwebtoken.Jwts;  
import io.jsonwebtoken.SignatureAlgorithm;  
  
public class JwtManager {  
    /** 
     * 1、选择签名的算法 
     * 2、生成签名的密钥 
     * 3、构建Token信息 
     * 4、利用算法和密钥生成Token 
     */  
    public static String createToken() {  
        SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;  
          
        byte[] secretBytes = DatatypeConverter.parseBase64Binary("JWT-TOKEN");  
        Key signingKey = new SecretKeySpec(secretBytes, signatureAlgorithm.getJcaName());  
        Map<String, Object> claims = new HashMap<String, Object>();  
        claims.put("username", "token");  
        claims.put("role", "admin");  
        JwtBuilder builder = Jwts.builder().setClaims(claims)  
                .setId("tokenid")  
                .setIssuedAt(new Date())  
                .setExpiration(new Date(System.currentTimeMillis()+10*60*1000))  
                .signWith(signatureAlgorithm, signingKey);  
          
        return builder.compact();  
    }  
      
    public static Claims parseToken(String token) {  
        return Jwts.parser().setSigningKey(DatatypeConverter.parseBase64Binary("JWT-TOKEN"))  
                .parseClaimsJws(token).getBody();  
    }  
      
    public static void validateToken(String token) {  
        try{  
            Claims claims = parseToken(token);  
            String username = claims.get("username").toString();  
            String role = claims.get("role").toString();  
            String tokenid = claims.getId();  
            System.out.println("[username]:"+username);  
            System.out.println("[role]:"+role);  
            System.out.println("[tokenid]:"+tokenid);  
        } catch(ExpiredJwtException e) {  
            System.out.println("token expired");  
        } catch (InvalidClaimException e) {  
            System.out.println("token invalid");  
        } catch (Exception e) {  
            System.out.println("token error");  
        }  
    }  
      
    public static void main(String[] args) {  
        validateToken(createToken());  
    }  
  
}  
转载地址：https://blog.csdn.net/u014418064/article/details/78565992

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
java中Token验证用法 什么是Token
突然发现这篇 java博文的浏览器已经破三千了，我觉得还是有必要提一下，在实际的工作项目中，如果采用这种方法的话，
可能代码量会比较多，很繁琐，但优点是对于新人可能是更好的去理解吧(至少我最初是这么认为的)。
这里我推荐一篇博文吧，很简便：Spring MVC拦截器+注解方式实现防止表单重复提交
-----tag-----
什么是Token：它是一个令牌，随机不可预测的。
为什么需要使用Token： 1，防止表单的重复提交
2:，防止跨站点的请求伪造
Token的使用流程是：首先在服务器端生成一个随机的token值并在服务器端保存起来，然后向客户端请求的过程中把这个Token值传过去。之后页面操作完毕后向服务器提交数据的过程中又把这个Token值传回服务器端，同时比较这个Token值是否已经存在于服务器端，若存在，则此次访问是安全的，并在服务器端把这个Token值删除，若不存在，则此次访问无效。
好，了解Token的用法之后来看代码(项目中可直接粘贴使用)
---------------------------------------------------------------------以下为转载的代码：
(一)首先是Token工具类
[java]
package com.company.util;
import java.util.ArrayList;
import javax.servlet.http.HttpSession;
public class Token {
private static final String TOKEN_LIST_NAME = "tokenList";
public static final String TOKEN_STRING_NAME = "token";
private static ArrayList getTokenList(HttpSession session) {
Object obj = session.getAttribute(TOKEN_LIST_NAME);
if (obj != null) {
return (ArrayList) obj;
} else {
ArrayList tokenList = new ArrayList();
session.setAttribute(TOKEN_LIST_NAME, tokenList);
return tokenList;
}
}
private static void saveTokenString(String tokenStr, HttpSession session) {
ArrayList tokenList = getTokenList(session);
tokenList.add(tokenStr);
session.setAttribute(TOKEN_LIST_NAME, tokenList);
}
private static String generateTokenString(){
return new Long(System.currentTimeMillis()).toString();
}
/** *//**
* Generate a token string, and save the string in session, then return the token string.
* @param  HttpSession session
* @return  a token string used for enforcing a single request for a particular transaction.
*/
public static String getTokenString(HttpSession session) {
String tokenStr = generateTokenString();
saveTokenString(tokenStr, session);
return tokenStr;
}
/** *//**
* check whether token string is valid. if session contains the token string, return true.
* otherwise, return false.
* @param String tokenStr
* @param HttpSession session
* @return true: session contains tokenStr; false: session is null or tokenStr is id not in session
*/
public static boolean isTokenStringValid(String tokenStr, HttpSession session) {
boolean valid = false;
if(session != null){
ArrayList tokenList = getTokenList(session);
if (tokenList.contains(tokenStr)) {
valid = true;
tokenList.remove(tokenStr);
}
}
return valid;
}
}
(二)JSP页面中
1：先import该Token工具类
[java]
2：在表单中添加隐藏的Token值
[html]
(三)在服务器端Servlet中添加如下代码
[java]
if(Token.isTokenStringValid(request.getParameter(Token.TOKEN_STRING_NAME), request.getSession())){
//To Do 业务代码
}

为什么使用Token验证：

在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式。

以下几点特性会让你在程序中使用基于Token的身份验证

1.无状态、可扩展

2.支持移动设备

3.跨程序调用

4.安全

那些使用基于Token的身份验证的大佬们

大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。

Token的起源

在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。

　　基于服务器的验证

　  我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份

在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

随着Web，应用程序，已经移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。

基于服务器验证方式暴露的一些问题

1.Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。

2.可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。

3.CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。

4.CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

基于Token的验证原理

基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。

这种概念解决了在服务端存储信息时的许多问题

　　NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

基于Token的身份验证的过程如下:
1.用户通过用户名和密码发送请求。

2.程序验证。

3.程序返回一个签名的token 给客户端。

4.客户端储存token,并且每次用于每次发送请求。

5.服务端验证token并返回数据。
每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。
代码实例流程：
//用户第一次登录

username pwd client_type

//接口判断

if(token&uid){

查询token表

$token=where uid =uid 
    if($token==token){

登录成功！！

返回token 和 uid

}else{

登录失败！！

}

}
if(usename powd client_type){

检验用户名和密码

if（正确）{

得到uid 并 生成token（md5( uid.pwd.time() 自己定义规则 )）

if(uid不存在){

into token 表   id uid token

}else{

where uid=$uid 修改token

}

返回token 和 uid

}else{

返回错误信息；

}

}
客户端c进行文件存储uid 和token
下次再次登录时使用uid和token
实现了用户登录的互踢
当我们在程序中认证了信息并取得token之后，我们便能通过这个Token做许多的事情。
我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）
Tokens的优势
无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成
一些拥堵。
但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。
安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。
可扩展性（）
Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。
使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。
多平台跨域
我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

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

创建token的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在JSON Web Tokens体现。
最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。

链接：shotCathttps://juejin.im/post/5c6e6063f265da2da53ec8f3
什么是Token？
Token是用户身份的验证方式，通常叫它：令牌。当用户第一次登录后，服务器生成一个Token并将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
Token由哪几部分组成？
uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接Token请求服务器)。还可以把不变的参数也放进Token，避免多次查库。
Token就象一个护照。第一次需要在前台验证你的身份(通过你的用户名和密码)，如果你成功验证了自己，你就可以取得这个通行证。当你走进大楼的时候(试图从调用API获取资源)，你会被要求验证你的护照，而不是在前台重新验证。
验证流程
大概的流程是这样的：
1, 客户端使用用户名和密码请求登录；
2, 服务端收到请求，去验证用户名与密码；
3, 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端；
4, 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；
5, 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；
6, 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据；
总的来说就是客户端在首次登陆以后，服务端再次接收http请求的时候，就只认token了，请求只要每次把token带上就行了，服务器端会拦截所有的请求，然后校验token的合法性，合法就放行，不合法就返回401(鉴权失败)。
优点
1.Token 完全由应用管理，所以它可以避开同源策略. (Cookie是不允许垮域访问的,token不存在)
2.Token 可以避免 CSRF 攻击(也是因为不需要cookie了)
3.Token 可以是无状态的，可以在多个服务间共享
4.Token 支持手机端访问(Cookie不支持手机端访问)
服务器只需要对浏览器传来的Token值进行解密，解密完成后进行用户数据的查询，如果查询成功，则通过认证.所以，即时有了多台服务器，服务器也只是做了Token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息，这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，解决了session扩展性的弊端。
缺点
1.占带宽: 正常情况下token要比 session_id更大，需要消耗更多流量，挤占更多带宽.(不过几乎可以忽略)
2.性能问题: 相比于session-cookie来说，token需要服务端花费更多的时间和性能来对token进行解密验证.其实Token相比于session-cookie来说就是一个"时间换空间"的方案.