「javatoken算法」token生成算法

今天给各位分享javatoken算法的知识，其中也会对token生成算法进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、java中 TOKEN的概念
• 2、Token是什么？和session、cookie相比，使用场景有什么区别？
• 3、java里边防止重复提交的token机制不太会搞，使用token需要什么工具吗？急等
• 4、请教Java 登录token的用法
• 5、java token是什么意思

java中 TOKEN的概念

token 你可以把他当做一个令牌，当第一次访问时设置一个令牌保存,一般我们保存在session中，当启动令牌时，那么就去检测令牌是否一致，然后销毁令牌或者重置令牌，这样第二次再用次令牌访问时，就会不一致了，直接提示重复提交了

Token是什么？和session、cookie相比，使用场景有什么区别？

在Web开发领域，相信大家对于Cookie和Session都很熟悉，Cookie和Session都是会话保持技术的解决方案。随着技术的发展，Token机制出现在我们面前，不过很多开发者对于Token和Cookie、Session的区别及使用场景分辨不清。

Cookie和Session的用途

要知道我们访问网站都是通过HTTP协议或HTTPS协议来完成的， HTTP协议它本身是无状态的协议 （即：服务器无法分辨哪些请求是来源于同个客户）。而业务层面会涉及到客户端与服务器端的交互（同网站下多个页面间能共享数据），此时服务器端必须要保持会话状态，这样才能进行用户身份的鉴别。

由于HTTP无状态的特性，如果要实话客户端和服务器端的会话保持，那就需要其它机制来实现，于是Cookie和Session应运而生。

通常情况下， Session和Cookie是搭配在一起使用的 。

Token是什么

上面说到的Session和Cookie机制来保持会话，会存在一个问题：客户端浏览器只要保存自己的SessionID即可，而 服务器却要保存所有用户的Session信息，这对于服务器来说开销较大，而且不利用服务器的扩展 （比如服务器集群时，Session如何同步存储就是个问题）！

于是有人思考，如果把Session信息让客户端来保管而且无法伪造不就可以解决这个问题了？进而有了Token机制。

Token俗称为“令牌” ，它的构成是：

Token机制下的认证流程

Token机制其实和Cookie机制极其相似 ，主要有以下流程：

1、用户登录进行身份认证，认证成功后服务器端生成Token返回给客户端；

2、客户端接收到Token后保存在客户端（可保存在Cookie、LocalStorage、SessionStorage中）；

3、客户端再次请求服务器端时，将Token作为请求头放入Headers中；

4、服务器端接收请求头中的Token，将用户参数按照既定规则再进行一次签名，两次签名若一致则认为成功，反之数据存在篡改请求失败。

（生成签名示例图）

（验证签名示例图）

Token与Cookie+Session的区别

Cookie其实也充当的是令牌作用，但它是“有状态”的； 而Token令牌是无状态的，更利于分布式部署。

session和cookie

在讲Token之前，先简单说说什么是session和cookie。

Token

但是这里会有个问题， 服务器要保存所有用户的session信息，开销会很大，如果在分布式的架构下，就需要考虑session共享的问题，需要做额外的设计和开发 ，例如把session中的信息保存到Redis中进行共享；所以因为这个原因，有人考虑这些信息是否可以让客户端保存，可以保存到任何地方，并且保证其安全性，于是就有了Token。

Token是服务端生成的一串字符串，可以看做客户端进行请求的一个令牌。

基于Token的认证流程

整体的流程是这样的：

总结 希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

Token顾名思义就是令牌、凭证、钥匙 。只有这把钥匙，你才能打开门。token一般都是服务端生成，比如一个web系统，用户登录的时候，服务端校验用户名密码通过以后，会生成一个token，同时会生成refreshToken和一个过期时间。然后将refreshToken和token返回给客户端。客户端会将token保存下来。后续所有的请求都会携带这个token。服务端会判断当前token是否存在已经是否过期。如果token不存在或者过期就会拒绝本次请求。如果token过期怎么办，就用refreshToken刷新时间。当然这里可能还有别的方案。比如只生成token，每次请求的时候都刷新过期时间。如果长时间没有刷新过期时间，那token就会过期。

session就是回话，这是服务端的一种操作。当你第一次访问一个web网站的时候，服务端会生成一个session，并有一个sessionid和他对应。这个session是存储到内存中的，你可以向这个session中写入信息，比如当前登录用户的信息。sessionid会被返回到客户端，客户端一般采用cookie来保存。当然这个cookie不用人为写入。用tomcat容器来举个例子。 当后端调用HttpServletRequest对象的getSession的方法的时候，tomcat内部会生成一个jsessonid（tomcat sessionid的叫法）。这个jsessonid会随本次请求返回给客户端。响应头信息

这个jessionid就会写到cookie中。之后jessionid就会通过cookie传递到服务端。

这里我们就会很清楚了， session的数据是存储到内存中。那问题就来了，如果我们的服务是分布式部署，有多台机器的话，可能我们第一次登陆的时候，我们把用户的信息存储到了session，但是后面的请求到了B机器上，那B机器是获取不到用户的session的。另外就是session存储在内存中，那服务器重启，session就丢失了，这就是他的弊端。现在有一些技术，例如session共享、iphash、session持久等也可以解决上述问题 。

cookie是浏览器的一种策略。上述讲到了sessionid就是存储在cookie中的。我们知道http协议是无状态的，cookie就是用来解决这个问题的。cookie中可以用来保存服务端返回的一些用户信息的，例如前文提到的token、sessionid。每一次的请求，都会携带这些cookie。服务端从请求头中取到cookie中的信息，就可以识别本次请求的来源，这样，http是不是就变成有状态的了。

这里说几点cookie注意事项。

1、cookie存放在客户端，所以是不安全的。人为可以清除

2、cookie有过期时间设定。如果不设置过期时间，说明这个cookie就是当前浏览器的会话时间，浏览器关了，cookie 就存在了。如果有过期时间，cookie就会存储到硬盘上，浏览器关闭不影响cookie。下次打开浏览器，cookie还存在

3、cookie有大小的限制，4KB。

这个问题，网上有很多的答案，相信都看过了，估计也没有看明白。所以我就不去网上复制了，用自己的话，尽量说通俗，说重点。

cookie和session实际上是同一套认证流程，相辅相成。session保存在服务器，cookie保存在客户端。最常见的做法就是客户端的cookie仅仅保存一个sessionID，这个sessionID是一个毫无规则的随机数，由服务器在客户端登录通过后随机生产的。往后，客户端每次访问该网站都要带上这个由sessionID组成的cookie。服务器收到请求，首先拿到客户端的sessionID，然后从服务器内存中查询它所代表的客户端(用户名，用户组，有哪些权限等)。

与token相比，这里的重点是，服务器必须保存sessionID以及该ID所代表的客户端信息。这些内容可以保存在内存，也可以保存到数据库(通常是内存数据库)。

而token则可以服务器完全不用保存任何登录信息。

token的流程是这样的。客户端登录通过后，服务器生成一堆客户端身份信息，包括用户名、用户组、有那些权限、过期时间等等。另外再对这些信息进行签名。之后把身份信息和签名作为一个整体传给客户端。这个整体就叫做token。之后，客户端负责保存该token，而服务器不再保存。客户端每次访问该网站都要带上这个token。服务器收到请求后，把它分割成身份信息和签名，然后验证签名，若验证成功，就直接使用身份信息(用户名、用户组、有哪些权限等等)。

可以看出，相对于cookie/session机制，token机制中，服务器根本不需要保存用户的身份信息(用户名、用户组、权限等等)。这样就减轻了服务器的负担。

我们举个例来说，假如目前有一千万个用户登录了，在访问不同的网页。如果用cookie/session，则服务器内存(或内存数据库)中要同时记录1千万个用户的信息。每次客户端访问一个页面，服务器都要从内存中查询出他的登录信息。而如果用token，则服务器内存中不记录用户登录信息。它只需要在收到请求后，直接使用客户端发过来的登录身份信息。

可以这么说， cookie/session是服务器说客户端是谁，客户端才是谁。而token是客户端说我(客户端)是谁，我就是谁 。当然了，token是有签名机制的。要是客户端伪造身份，签名通不过。这个签名算法很简单，就是将客户端的身份信息加上一个只有服务器知道的盐值(不能泄露)，然后进行md5散列算法(这里只是简化，方便理解，实际细节要稍复杂一些)。

cookie/session在单服务器，单域名时比较简单，否则的话，就要考虑如何将客户端的session保存或同步到多个服务器。还要考虑一旦宕机，内存中的这些信息是否会丢失。token因为服务器不保存用户身份，就不存在这个问题。这是token的优点。

token因为服务器不保存用户身份信息，一切都依赖当初那个签名。所以存在被盗用的风险。也就是说一旦盗用，服务器可能毫无办法，因为它只认签名算法。而session机制，服务器看谁不爽，可以随时把他踢出(从内存中删掉)。正是因为如此，token高度依赖过期时间。过期时间不能太长。过期短，可以减少被盗用的风险。

除了上面所说的，我个人认为，如果开发的系统足够小，倾向于使用cookie/session。如果系统同时登录用户多，集群服务器多，有单点登录需求，则倾向于使用token。

万维网的发展 历史

Token, 令牌，代表执行某些操作的权利的对象。

token主要用于鉴权使用，主要有以下几类：

cookie主要是网站用于在浏览器临时存放的数据，包括浏览器缓存数据以及服务器设定的一些数据，主要存放在浏览器端。

session主要用于保存会话数据，一般存储在服务器端，同时每一条session对用一个sessionID，sessionID是存放在浏览器的cookie中。

传统上的会话登陆和鉴权主要用session加cookie实现，随着分布式系统的快速演进，尤其是微服务的应用，token+cookie的授权访问机制得到亲睐，通常在用户登录后，服务器生成访问令牌(Access token)，浏览器存储cookie中，在每次请求资源时都会在请求头中带上token，用于服务器授权访问使用。

Token和session都是web网站的会话保持、认证的解决方案；

既然都一样为什么还有token的说法。

从token产生的背景说起

1.移动端应用使得服务器端Session失效

2.分布式系统中Session无法共享

所以说session对于以上两种情况无效了，所以有了Token的说法

那么什么是token,token长什么样子？

先给大家一个直观的感受

token:PC-3066014fa0b10792e4a762-23-20170531133947-4f6496

说白了token保存就是用户的信息（不能保存密码等敏感信息）

token的组成：

客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]

USERCODE，RONDEM[6位]经过MD5加密就变成了以上字符串

token的请求流程

请求流程解析

1.前端用户发送登录信息至认证系统

2.验证用户登录信息，判断用户是否存在

3.如果用户存在，生成token信息（客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]），并存储在redis中

4.并将该token返回前端，附加至header

验证token

客户端

将token附加至header

服务端

最后总结一下

一般的垂直架构项目使用Session没有任何问题，但是分布式项目或涉及到移动端则考虑使用token。

session

session的中文翻译是“会话”，当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

cookie

cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

cookie的组成有：名称(key)、值(value)、有效域(domain)、路径(域的路径，一般设置为全局:"")、失效时间、安全标志(指定后，cookie只有在使用SSL连接时才发送到服务器(https))。下面是一个简单的js使用cookie的例子:

用户登录时产生cookie:

document.cookie = "id="+result.data['id']+"; path=/";

document.cookie = "name="+result.data['name']+"; path=/";

document.cookie = "avatar="+result.data['avatar']+"; path=/";

使用到cookie时做如下解析：

var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i cookieArr.length; i++) {

user_info[cookieArr[i].split("=")[0]] = cookieArr[i].split("=")[1];

}

$('#user_name').text(user_info[' name']);

$('#user_avatar').attr("src", user_info[' avatar']);

$('#user_id').val(user_info[' id']);

token

token的意思是“令牌”，是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库

cookie 和session的区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗

考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能

考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5、所以个人建议：

将登陆信息等重要信息存放为SESSION

其他信息如果需要保留，可以放在COOKIE中

token 和session 的区别

session 和 oauth token并不矛盾，作为身份认证 token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全了。如上所说，如果你需要实现有状态的会话，仍然可以增加session来在服务器端保存一些状态

App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那样用cookie来保存session,因此用session token来标示自己就够了，session/state由api server的逻辑处理。 如果你的后端不是stateless的rest api, 那么你可能需要在app里保存session.可以在app里嵌入webkit,用一个隐藏的browser来管理cookie session.

Session 是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。这里的 Token是唯一的。不可以转移到其它 App上，也不可以转到其它 用户 上。 转过来说Session 。Session只提供一种简单的认证，即有此 SID，即认为有此 User的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。 所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

想要全面深入地掌握Token，我们需要先了解这些：Token的概念、身份验证过程、实现思路、使用场景，以及Cookie、Session、Token的区别。

内容纲要

Token的定义

Token是验证用户身份的一种方式，简称做“令牌”。最简单的token组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐，以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库。

Token的身份验证过程

每一次请求都需要Token,Token应该在HTTP的头部发送，从而保证Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。

需要注意的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。

Token的实现思路

当我们在程序中认证了信息，并取得Token之后，我们便能通过这个Token做许多的事情。我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）。

Token的应用场景

Cookie和Session的区别

综合以上考量，建议方案：

Session和Cookie取长补短、配合使用，将登陆信息等重要信息存放为Session，其他信息如果需要保留，可以放在Cookie中。

Token 和 Session 的区别

Session和Token并不矛盾，作为身份认证，Token安全性比Session高，因为Token发送的每个请求都带有签名，能防止监听，以及重放攻击。而session就必须靠链路层来保障通讯安全。如上所说，如果需要实现有状态的会话，可以通过增加session，在服务器端保存一些状态。

App通常用Restful API跟server打交道。Rest是Stateless的，也就是App不需要像Browser那样用Cookie来保存Session，因此使用Session Token来标示就足够了。Session/state由API Server的逻辑处理。如果后端不是Stateless的rest API，那么可能需要在App里保存Session，可以在App里嵌入webkit，用一个隐藏的Browser来管理Cookie Session.

Session是一种HTTP存储机制，目的是为无状态的HTTP提供持久机制。 所谓的Session认证，只是简单的把User信息存储到Session里，因为SID的不可预测性，暂且认为是安全的，这是一种认证手段。

Session只提供一种简单的认证，即有此SID，以及User的全部权利。是需要严格保密的，这个数据只在使用站点保存，不可共享给其它网站或者第三方App。所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用API接口，则使用Token，如果只是自己的网站或App应用，使用什么都OK。

Token，指的是OAuth Token或类似的机制的话，提供的是认证和授权 ，认证是针对用户，授权是针对App。其目的是让某App有权利访问某用户的信息，这里的Token是唯一的，不可以转移到其它App上，也不可以转到其它用户上。

Token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件。Cookie就是写在客户端的一个txt文件，记录下用户的访问、登录等信息，下次用户再登录某个网站时，服务器接收到请求，就会自动调用Cookie，自动登录用户名。

Session和Cookie差不多，只是Session是写在服务器端的文件，也需要在客户端写入Cookie文件，但是文件里是用户的浏览器编号.Session的状态是存储在服务器端，客户端只有session id，而Token的状态是存储在客户端的。

以上，是关于Token、Session、Cookie的知识点介绍，更加深入的详解，感兴趣的童鞋，可查看我持续分享的【BAT架构技术专题合集500+】，回复【架构】，即可领取。

Token是什么？

Token是令牌、凭证、钥匙，在Web领域中进行 身份验证 ，关键点在验证！！，说验证就必须了解一下Web领域的发展史呢。

2. 随着人们需求的改变，比如在线购物系统，需要登陆的网站等，这时候需要进行 交互 性，服务器接收到请求的时候，要根据你是否登陆，以及判断你是谁，来给你响应，这时候问题就来了，怎么知道每次请求的谁呢，所以就出来了一个 会话标识（session id），就是一个随机的字符串 ，每个人登陆的时候，服务器都会返回一个会话标识，这是再请求的时候，只要带上会话标识，服务器就知道请求的是谁。

3. 这样子每个人只要保存自己的session id就可以啦，服务器要保存 所有人 的session id！！！如果有成千上万的人访问服务器，那对服务器是巨大的开销，严重限制了服务器端的扩展能力，比如机器A跟机器B组成了服务器集群，那么访问了机器A，会话标识在机器A上，如果转到机器B，就不能访问了，也许会说，那复制呢，机器A搬到机器B，也有说统一把标识放在一个机器上，但是万一这个机器挂了呢，那体验就很差了。

4. 这个时候就有人想，用户自己保存自己的标识，就是Token，访问的时候带上这个Token，这个 Token是用户id+签名 ，验证时，服务器只要相同的算法和服务器才知道的密钥进行签名，如果结果跟Token中的签名一样，那就可以证明是登陆过的用户。

这样一来，服务器不保存session id，只要生成Token，访问时，只要对Token进行判断，Token也是有有效期的，所以也要进行refreshToken的。

Token,Cookie,Session三者使用场景的区别？

Token主要是Web领域的身份认证 ，最常见的就是Web API这个功能：

Cookie 就是饼干， 它是服务器生产，永久保存在浏览器的数据，以kv的形式 ，你可以打开你的浏览器（这里以win10 edge为例），点击上方的三个点的按钮，再点击更多工具，再点击开发人员工具，再点击网络，此时内容选择文档，然后刷新页面，找Cookie即可。

Session是会话标识，是服务器用来判断正在会话的用户是谁，服务器生产的随机数 ，保存在服务器中，用户端也要进行保存，虽然能实现会话的共能，但对服务器的扩展能力限制，同时当服务器是两台机器组成以上的时候，会导致两台机器以上保存的session同步问题，会导致用户体验极差。

Token跟Session最大的区别就是Token服务端不用保存，同时是通过签名等技术实现的，Session因为是随机数，导致服务器要进行保存。

java里边防止重复提交的token机制不太会搞，使用token需要什么工具吗？急等

1.在Struts中，如何实现防止表单的重复提交操作？

Struts的Token（令牌）机制能够很好的解决表单重复提交的问题，

基本原理是：

1) 服务器端在处理请求到达之前，会将 请求 中包含的令牌值与保存在当前 用户会话 中的令牌值进行比较，看是否匹配。

2) 在处理完该请求后，且在答复客户端之前，会产生一个新的令牌值，该令牌值除传给客户端以外，也会将 用户会话 中保存的旧的令牌值进行替换。

3) 这样如果用户回退到刚才的提交页面并再次提交的话，客户端传过来的令牌值就和服务器端的令牌值不一致，从而有效地防止了重复提交的发生。

2.Struts使用Token机制，来防止恶意的破坏和重复提交问题，也就是点击后退后在再提交，这是Struts无法发现的

3.在form中生成一个token码，在session中也保存有一个同样的token码，

当表单提交后，判断两个token码相等后，就会改变session中的这个token码，

当然在用回退后，form的token码是不会变的，在提交，还会判断两个token码是否相等，如果不等就会抛出异常，证明这是过时的垃圾数据。

作用：Token机制可以解决表单的重复提交；

产生token的两种方式： 

1. form表单的post请求,使用隐藏域input type="hidden" name="token" value="${token}"；

2. 直接使用超级链接html:link action="" trasantion="true"，可以直接在链接后面添加token值。

请教Java 登录token的用法

jsp生成表单时，

1 在表单中插入一个隐藏input字段，该字段就是保存在页面端的token字符串，同时把该字符串存入session中。

2 用户提交表单时，会一并提交该隐藏的token字符串。

3 在服务器端，查看下是否在session中含有与该token字符串相等的字符串。

3 .1 如果有，那么表明是第一次提交该表单，然后删除存放于session端的token字符串，再做正常业务逻辑流程；(注意此处已经将session端的token字符串 删除)

3.2 如果没有，那么表示该表单被重复提交，做非正常流程处理，可以警告提示也可以什么也不做（第一次提交后session端的token字符串已删除）

java token是什么意思

token

读音：英 ['təʊk(ə)n]  美 ['tokən]

n. 表征；代币；记号

adj. 象征的；表意的；作为对某事的保证的

vt. 象征；代表

词组短语

by the same token 同样地；出于同样原因

as a token of 作为?的标志

token ring 令牌环（一个环状的区域网路）

in token of 表示；作为?的标志

by this token 由此看来

拓展资料

双语例句

1，Later on we will combine token sequences into parse trees.

稍后我们会将记号序列组合成解析树。

2，After normalization of attributes, you can count on every token in an attribute being separated from its neighbors by whitespace.

在属性规范化后，可以依靠的属性中的每个记号是通过空白来与其邻居区分开来。

3，This little gift is a token of our regard.

这点礼物是我们大家的一点心意。

关于javatoken算法和token生成算法的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。