网站运营年度推广方案羊了个羊开发公司
news/
2025/9/23 9:28:16/
文章来源:
网站运营年度推广方案,羊了个羊开发公司,做微信充值网站,虾米播播支持wordpress吗一#xff0c;什么是JWT
JSON Web Token#xff08;缩写 JWT#xff09;是目前最流行的跨域认证解决方案
JWT总的来说是用来解决session的共享的问题的
1#xff0c;JWT的原理
JWT 的原理是#xff0c;服务器认证以后#xff0c;生成一个 JSON 对象#xff0c;发回给…一什么是JWT
JSON Web Token缩写 JWT是目前最流行的跨域认证解决方案
JWT总的来说是用来解决session的共享的问题的
1JWT的原理
JWT 的原理是服务器认证以后生成一个 JSON 对象发回给用户就像下面这样。 { 姓名: 张三, 角色: 管理员, 到期时间: 2018年7月1日0点0分 } 以后用户与服务端通信的时候都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据服务器在生成这个对象的时候会加上签名详见后文。
服务器就不保存任何 session 数据了也就是说服务器变成无状态了从而比较容易实现扩展。
2JWT的数据结构
一般来说JWT,是由三部分组成的
实际的 JWT 大概就像下面这样。 它是一个很长的字符串中间用点.分隔成三个部分。注意JWT 内部是没有换行的这里只是为了便于展示将它写成了几行。
JWT 的三个部分依次如下。 Header头部 明文 Payload负载 明文 Signature签名
写成一行就是下面的样子。 Header.Payload.Signature 第一部分Header
Header 部分是一个 JSON 对象描述 JWT 的元数据通常是下面的样子。 { alg: HS256, typ: JWT } 上面代码中
alg属性表示签名的算法algorithm默认是 HMAC SHA256写成 HS256
typ属性表示这个令牌token的类型typeJWT 令牌统一写为JWT。
最后将上面的 JSON 对象使用 Base64URL 算法详见后文转成字符串。
第二部分Payload
Payload 部分也是一个 JSON 对象用来存放实际需要传递的数据。JWT 规定了7个官方字段供选用。 iss (issuer)签发人 exp (expiration time)过期时间 sub (subject)主题 aud (audience)受众 nbf (Not Before)生效时间 iat (Issued At)签发时间 jti (JWT ID)编号 除了官方字段你还可以在这个部分定义私有字段下面就是一个例子。 { sub: 1234567890, name: John Doe, admin: true } 注意JWT 默认是不加密的任何人都可以读到所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。
第三部分Signature
我们主要学习的就是第三部分也是整个JWT的核心
签名利用“加密算法”对JWT进行签名保证没有被篡改过值得注意的是这里的数据都是明文的算法实际上执行的是最后的数据签名功能只能保证“不被篡改”而不是保证“不被解密”虽然不能保证不能被破解但是只要他改动我们就不认可他所以后面看到“加密、解密”其实都是为签名服务的。
首先需要指定一个密钥secret。这个密钥只有服务器才知道不能泄露给用户。然后使用 Header 里面指定的签名算法默认是 HMAC SHA256按照下面的公式产生签名。 HMACSHA256(base64UrlEncode(header) . base64UrlEncode(payload), secret) 算出签名以后把 Header、Payload、Signature 三个部分拼成一个字符串每个部分之间用点.分隔就可以返回给用户。
Base64URL
前面提到Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似但有一些小的不同。
JWT 作为一个令牌token有些场合可能会放到 URL比如 api.example.com/?tokenxxx。Base64 有三个字符、/和在 URL 里面有特殊含义所以要被替换掉被省略、替换成-/替换成_ 。这就是 Base64URL 算法。 二为什么要使用JTW
我们上面都说了主要是解决session的共享的问题而在一个节点的登录之后就自动会自动的登录其他的节点比如腾讯的网站在一个网站登录了之后在其他网站就会自动登录所以我们要解决这个问题
一跨域认证的问题
我们互联网服务离不开用户认证一般流程是下面这样 1、用户向服务器发送用户名和密码。 2、服务器验证通过后在当前对话session里面保存相关数据比如用户角色、登录时间等等。 3、服务器向用户返回一个 session_id写入用户的 Cookie。 4、用户随后的每一次请求都会通过 Cookie将 session_id 传回服务器。 5、服务器收到 session_id找到前期保存的数据由此得知用户的身份。 这种模式的问题在于扩展性不好。单机当然没有问题如果是服务器集群或者是跨域的服务导向架构就要求 session 数据共享每台服务器都能够读取 session。
我们解决的方法有几种
方法一就是session的数据持久化写入数据库的持久层或者其他的持久层各种的服务收到请求后都会向持久层请求数据这种优点是架构清晰缺点是工程量比较大还会增加数据库的压力数据库一挂就会失败
方法二是服务器中干脆不保存session(是一种用于记录用户状态的机制广泛应用于Web应用程序中尤其是在用户认证和授权方面。在一次用户会话期间服务器创建一个唯一的Session ID并将其发送给客户端通常通过Cookie或URL重写等方式。客户端在后续请求中将Session ID返回给服务器服务器根据Session ID找到对应的Session对象从而恢复用户的会话状态。) 数据了,所有的数据都保存在客户端中每次请求都发回服务器。
一共有四种解决方法
1粘贴会话
2会话复制
3session 数据集中存储
4基于Token 的认证如JWT
我们主要学习的就是基于Token 的认证
把用户的信息存储在客户中服务端的app就是无状态的微服务也是无状态的
三JWT的使用方法
客户端收到服务器返回的 JWT可以储存在 Cookie 里面也可以储存在 localStorage。
客户端收到服务器返回的 JWT可以储存在 Cookie 里面也可以储存在 localStorage。
此后客户端每次与服务器通信都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送但是这样不能跨域所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。 Authorization: Bearer token 另一种做法是跨域的时候JWT 就放在 POST 请求的数据体里面。
总的来说就是我们使用基于Token的认证如JWT或者自定义Token实现无状态认证,使用JWT 将用户的信息和权限编码存储到Token中 Token 由客户端存储如Cookie 和 LocalStorage 虽然某些意义上LocalStorage更具有优势每次请求时附加到HTTP Header头部 中 服务器无需维护Session 状态只需要解析Token 即可验证用户身份虽然签名可以被篡改但是只要动一下哪怕是一共空格与我们存在客户端的签名不一致就验证失败
总的来说实现Session 共享的关键在于选择一种既能满足业务需求又能适应分布式架构的技术方案同时考虑到性能可靠性安全性等因素目前在云原生和微服务架构中采用Token 认证或Session 数据集中存储的方式越来越普遍。
补充
Cookie 与 localStorage的区别与优势
Cookie:
区别
存储大小Cookie的存储空间是4kKBlocalStorage 存储空间是5MB
数据传输Cookie 在每次 HTTP 请求时自动附加到请求头中并发送到服务器端。这可能导致额外的网络开销特别是当Cookie数量多或体积较大时。而 LocalStorage 数据仅在本地存储不会自动随请求发送至服务器。
过期时间Cookie 可以设置过期时间过期后浏览器会自动删除。而 LocalStorage 数据除非手动清除否则永久存储即除非明确删除否则数据将持续存在。
隐私与安全因为Cookie经常在网络上传输所以需要关注安全问题比如可以通过设置 HttpOnly 标志防止JavaScript访问使用Secure标志要求在HTTPS连接下传输。Localstorage虽然也是在客户端存储但由于不随请求发送因此不存在在网络传输过程中的安全问题但本地存储的数据依然可能被恶意脚本访问。
优势
适用于保持用户状态Cookie 因其自动随请求发送的特点适合于维持用户登录状态、跟踪用户偏好等场景
LocalStorage 大容量存储LocalStorage 提供更大的存储空间适合存储大量客户端使用的数据如应用程序的配置信息、缓存数据等。 高效性相比CookieLocalStorage减少了不必要的网络流量尤其对于那些不需要服务器知道的客户端状态信息可以提高性能。 持久化存储LocalStorage提供一种简单易用的本地持久化存储方式数据在浏览器重启后仍然保留方便实现离线功能或持久化的用户界面状态。 更简单的APILocalStorage提供了简洁的API接口可以直接调用setItem(), getItem(), 和 removeItem() 进行数据的读写操作。
劣势
安全性与隐私虽然不自动发送给服务器但因存储在本地若网站遭受XSS攻击攻击者可能窃取或篡改LocalStorage中的数据。不支持自动清理没有过期机制可能导致存储空间被长期占用需要开发者自行管理数据的有效性。
综合来看选择使用Cookie还是LocalStorage主要取决于应用场景的需求例如是否需要服务器端共享数据、是否关心数据的生命周期、以及对存储空间的需求等。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/912052.shtml
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!