Token机制是sso单点登录的最主要实现机制，最常用的实现机制。

Token机制是sso单点登录的最主要实现机制，最常用的实现机制。传统身份认证，一般一个应用服务器，在客户端和服务器关联的时候，在应用服务器上做了一个HttpSession对象保持着客户端和服务器上状态信息存储。
1、传统身份认证。

 1 HTTP是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发
 2 送请求时候，还得再验证一下。
 3     解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 
 4 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 
 5 Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。
 6     上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session ，这些 Session 
 7 可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。
 8     这种认证中出现的问题是：
 9         Session：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
10         可扩展性：在服务端的内存中使用Session存储登录信息，伴随而来的是可扩展性问题。
11         CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止
12             请求的情况。
13         CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
14             在这些问题中，可扩展性是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

 2、Token身份认证。

 1 a、使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
 2         1）、客户端使用用户名、密码请求登录。
 3         2）、服务端收到请求，去验证用户名、密码。
 4         3）、验证成功后，服务端会签发一个 Token（令牌），再把这个 Token 发送给客户端。
 5         4）、客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 、Session Storage里。
 6         5）、客户端每次向服务端请求资源的时候需要带着服务端签发的 Token。
 7         6）、服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。
 8 b、使用Token验证的优势：
 9         无状态、可扩展
10         在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
11         安全性
12         请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息
13             存储在Session中，让我们少了对session操作。

 3、JSON Web Token（JWT）机制。

Token在Java中具体实现的方案，JWT（Json数据做web网络层的令牌机制），可以做加密扩展或者签名扩展。

 1     1）JSON Web Token（JWT）机制。
 2         a、JWT是一种紧凑（小而少，只要包含了用户信息即可）且自包含（json数据中包含本次访问简单记录，记录不敏感数据）的，用于在多方传递JSON对象的技术。传递的数据可以使用数字签名增加其安全行。可以使用HMAC加密算法或RSA公钥/私钥加密方式。
 3         b、紧凑：数据小，可以通过URL，POST参数，请求头发送。且数据小代表传输速度快。
 4         c、自包含：使用payload数据块记录用户必要且不隐私的数据，可以有效的减少数据库访问次数，提高代码性能。
 5         d、JWT一般用于处理用户身份验证或数据信息交换。
 6         e、用户身份验证：一旦用户登录，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由，服务和资源。单点登录是当今广泛使用JWT的一项功能，因为它的开销
 7             很小，并且能够轻松地跨不同域使用。
 8         f、数据信息交换：JWT是一种非常方便的多方传递数据的载体，因为其可以使用数据签名来保证数据的有效性和安全性。
 9         h、官网： jwt.io
10     2）、JWT数据结构
11         JWT的数据结构是 ： A.B.C。 由字符点‘.’来分隔三部分数据。
12         A - header 头信息
13             数据结构： {“alg”: “加密算法名称”, “typ” : “JWT”}
14             alg是加密算法定义内容，如：HMAC SHA256 或 RSA
15             typ是token类型，这里固定为JWT。
16         B - payload （有效荷载？）
17             在payload数据块中一般用于记录实体（通常为用户信息）或其他数据的。主要分为三个部分，分别是：已注册信息（registered     
18                 claims），公开数据（public claims），私有数据（private claims）。
19             payload中常用信息有：iss（发行者），exp（到期时间），sub（主题），aud（受众）等。前面列举的都是已注册信息。
20             公开数据部分一般都会在JWT注册表中增加定义。避免和已注册信息冲突。
21             公开数据和私有数据可以由程序员任意定义。
22             注意：即使JWT有签名加密机制，但是payload内容都是明文记录，除非记录的是加密数据，否则不排除泄露隐私数据的可能。不推荐在payload中记录任何敏感
23                 数据。
24         C - Signature 签名
25             签名信息。这是一个由开发者提供的信息。是服务器验证的传递的数据是否有效安全的标准。在生成JWT最终数据的之前。先使用header中定义的加密算法，将h
26             eader和payload进行加密，并使用点进行连接。如：加密后的head.加密后的payload。再使用相同的加密算法，对加密后的数据和签名信息进行加密。得到最终
27             结果。

 JWT（JSON Web Token）执行流程如下所示：

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

待续......