标签：基于 session应用 密码 就是 加密算法 一个 浏览器 关于 不同
最近在做公司的认证系统，总结了如下一番心得。
传统的认证方式一般采用cookie/session来实现，这是我们的出发点。
1.为什么选用token而不选用cookie/session？
本质上token和cookie/session都是字符串，然而token是自带加密算法和用户信息(比如用户id)，；而cookie本身不包含用户信息，它指向的是服务器上用户的 session，而由session保存用户信息。这点差别，决定token可以很容易的跨服务器，只要不同服务器实现相同解密算法即可；而cookie/session是存在于某一台服务器上，
要实现跨服务器比较困难，这是任何基于cookie/session应用天生的短板。
2.token需要过期时间吗？
token即是获取受保护资源的凭证，当然必须有过期时间。否则一次登录便可永久使用，认证功能就失去了其意义。非但必须有个过期时间，而且过期时间还不能太长，
参考各个主流网站的token过期时间，一般不超过1h.
3.token过期该怎么办？
token过期，就要重新获取。那么重新获取有两种方式，一是重复第一次获取token的过程(比如登录，扫描授权等)，这样做的缺点是用户体验不好，每一小时强制登录一次几乎是无法忍受的。那么还剩第二种方法，那就是主动去刷新token. 主动刷新token的凭证是refresh token，也是加密字符串，并且和token是相关联的。相比获取各种资源的token，refresh token的作用仅仅是获取新的token，因此其作用和安全性要求都大为降低，所以其过期时间也可以设置得长一些。
4.refresh token需要过期时间么？
客户端需要保存token和refresh token，以便下一次访问能继续。如果客户端是浏览器，那么两个token都需要设置过期时间；但是可以设置得长一点，可以以天为单位（例如7天、15天）；如果客户端是一个服务器，那么refresh token可以永久有效，直到下一次登录，refresh token本身被更新为止。
以上几个问题是层层递进的，虽说如此，也无法从逻辑上/理论上保证认证系统的绝对安全。但是，我觉得任何一种认证方式，都不能做到逻辑上的绝对安全和毫无漏洞。但是如果给攻击者造成了足够的麻烦，使其破解成本大大提升，那么我们就认为认证系统足够安全了。认证功能最后的落地实现，总是和现实想妥协的结果。.
安全的 session 是不能无限被刷新的，所以肯定有最终过期时间，可以设置为 token 的过期时间，这样就避免刷新 token 了。
一般移动端的过期时间以月为单位， web 端一般以天为单位。
api 的 token 复杂，在 auth 2.0 里，
普通 auth token 一个小时过期，
还有一种 fresh token 基本不过期，或半年过期，用 fresh token 可以领新的 auth token ，不用输入密码，
fresh token 的申请的权限多，
标签：基于 session应用 密码 就是 加密算法 一个 浏览器 关于 不同
原文地址：https://www.cnblogs.com/ExMan/p/10409282.html
