Jwt Note

2024-04-04 约 5306 字预计阅读 11 分钟

Jwt

json web token

跨域认证的问题

跨域认证指的是在不同域名下的应用程序之间进行身份验证和授权的过程。由于浏览器的同源策略，不同域名下的应用程序不能直接访问对方的信息，因此在进行跨域认证时需要使用特定的技术手段来实现。

浏览器的同源策略（Same Origin Policy）是一种安全机制，用于限制一个源（域名、协议和端口号的组合）的文档或脚本如何与其他源的资源进行交互。同源策略的目的是防止恶意网站通过脚本等方式获取用户的敏感信息或进行恶意操作。

同源策略的限制包括以下几个方面：

Cookie、LocalStorage和IndexDB等存储机制的限制：同源的文档可以共享这些存储机制，但不同源的文档无法访问彼此的存储数据。

DOM操作的限制：同源的文档可以通过JavaScript等脚本访问彼此的DOM元素，但不同源的文档无法访问彼此的DOM元素。

AJAX请求的限制：同源的文档可以通过XMLHttpRequest等方式进行AJAX请求，但不同源的文档无法进行跨域AJAX请求。

需要注意的是，同源策略只限制浏览器端的交互，服务器端不存在同源策略的限制。如果需要进行跨域交互，可以使用一些特殊的技术手段，如JSONP、CORS、代理服务器等。

常用的跨域认证技术

CORS（跨域资源共享）：CORS是一种浏览器技术，通过在服务器端设置响应头信息，允许跨域的请求进行访问。在进行跨域认证时，可以在服务器端设置CORS响应头，允许来自其他域名的请求访问。
JSONP（跨域JSON请求）：JSONP是一种利用script标签进行跨域请求的技术，它通过在请求中添加一个回调函数名参数，让服务器将数据包装成一个函数调用返回给客户端，从而实现跨域请求。
代理服务器：代理服务器是一种在服务器端进行跨域请求的技术，它通过在服务器端设置代理服务器，将跨域请求转发到目标服务器上进行处理，再将结果返回给客户端。
OAuth2.0：OAuth2.0是一种开放标准，用于授权第三方应用程序访问用户资源的过程。在进行跨域认证时，可以使用OAuth2.0协议来进行身份验证和授权，让第三方应用程序获得访问用户资源的权限。

session 和 jwt

Session模式和JWT模式都是常见的身份验证和授权机制，二者有以下几点不同：

存储方式不同：Session模式将用户身份信息存储在服务端的内存或者数据库中，而JWT模式将用户身份信息存储在客户端的浏览器中。
状态管理方式不同：Session模式需要服务端在每次请求中校验用户的身份信息，而JWT模式则不需要服务端校验，只需要在客户端解密和校验即可。
扩展性不同：Session模式需要在服务端存储用户身份信息，因此需要考虑存储容量和扩展性等问题，而JWT模式不需要存储用户身份信息，因此具有更好的扩展性。
跨语言支持不同：Session模式需要服务端和客户端使用相同的编程语言实现，而JWT模式可以跨越多种编程语言和平台。
安全性不同：Session模式存在一定的安全风险，如会话劫持、会话固定等问题，而JWT模式可以通过加密和签名等方式提高安全性。

总的来说，Session模式适用于单一的应用程序，而JWT模式适用于多个应用程序或者服务之间的信息传输。

Token 的使用

用户信息加密填入 token 中，服务器不保存任何用户信息，保存密钥信息，通过使用特定加密算法验证 token。

client – uid+passwd 请求
sever – 收到并验证
sever – 验证成功后签发 token 并将 token 返回客户端
client – 请求服务器资源需要附带 token （在 cookie 或 header 中携带）
sever – 收到请求核验 token，成功则返回所请求数据

基于token的认证方式相对于session认证方式更加节约服务器资源，对移动端和分布式更友好。

支持跨域访问。token不使用cookie而直接放入请求头中，跨域后不存储信息丢失。
无状态：token机制在服务端不储存session信息，token自身携带登录用户的信息。
更加适用CDN: 可以通过分发网络请求服务端的所有资料。
更适用于移动端：当客户端时非浏览器平台时，cookie不被支持，而token可以实现。
无需考虑CSRF: 由于不再依赖cookie,token认证不会发生CSRF无需考虑CSRF的防御。

CRSF（Cross-Site Request Forgery）是一种网络攻击方式，攻击者通过伪造用户已经授权过的请求来执行恶意操作。攻击者通常会通过诱骗用户点击链接或访问网站来实现攻击。CRSF攻击可以导致用户的账户被盗、信息泄露等安全问题。

CDN（Content Delivery Network）是一种分布式网络架构，通过在全球各地部署服务器节点，将静态资源（如图片、视频、脚本等）缓存在离用户最近的服务器上，从而提高资源访问速度和用户体验。CDN的主要功能包括：加速访问速度、提高网站可用性、降低服务器负载、保障安全性等。通过使用CDN，网站可以更快地响应用户请求，减少带宽消耗和服务器压力，提高网站的稳定性和安全性。

Json Web Token

JWT的本质是一个字符串。它将用户信息保存到一个Json字符串中，然后进行编码后得到一个JWT token，并且这个JWT token带有签名信息，接收后可以校验是否被篡改，所以可以用于在各方之间安全地将信息作为Json对象传输。

JWT的认证流程如下：

Session

Session 的抽象概念是会话，是无状态协议通信过程中，为了实现中断/继续操作，将用户和服务器之间的交互进行的一种抽象；具体来说，是服务器生成的一种 Session 结构，可以通过多种方式保存，如内存、数据库、文件等，大型网站一般有专门的 Session 服务器集群来保存用户会话。

session 是另一种记录服务器和客户端会话的机制。 session 是基于cookie 实现的，session 存储在服务器端，session ID 会被 cookie 保存到客户端的 cookie 中。服务器执行 session 机制时，生成 session ID 发送客户端，客户端请求将 ID 加入 http 发送服务端，ID 本地保存，容器为 cookie，因此 ban 掉 cookie 时，session 不能正确使用。 session ID 在服务端进行匹配。

客户端保存用户信息的一种机制，用来记录用户信息。服务器存储在本地机器上的一小段文本，会被下一次请求携带发往服务器。 cookie 不可跨越，每个 cookie 绑定单一域名，无法在别的域名下使用，一级域名和二级域名互通，（凭借 domain） cookie 会根据上 http 响应报文中的的 set-cookie 的首部字段信息，通知客户端保存 cookie。当下客户端再向服务端发起请求时，cookie 自动加入。

属性：

Http协议是一种无状态的协议

http 无状态的协议（对于事务处理无记忆功能，对话完成后，服务端不保存任何会话信息。）每一个 http 完全独立服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的是否相同。下一次请求时，仍然需要认证。为了解决这个问题，提出了cookie的解决方案：

Session的一些问题

每个用户的登录信息都会保存到服务器的session中，随着用户的增多，服务器开销会明显增大
由于session是存在与服务器的物理内存中，所以在分布式系统中，这种方式将会失效。虽然可以将session统一保存到Redis中，但是这样做无疑增加了系统的复杂性，对于不需要redis的应用也会白白多引入一个缓存中间件
无cookie时失效，例如非浏览器的移动端、手机移动端等等。
cookie截获导致的CSRF
中间件的存在导致消息可能转发多次
后端部署复杂
由于cookie的不可跨域性，session的认证也无法跨域，不适用于单点登录（SSO）

单点登录（Single Sign-On，简称SSO）是一种身份认证机制，允许用户使用一组凭据（如用户名和密码）登录到多个应用程序或系统中，而无需为每个应用程序单独进行身份验证。在SSO中，用户只需进行一次登录，就可以访问多个应用程序，从而提高用户体验和工作效率。SSO通常使用集中式认证服务来管理用户身份信息和授权访问权限，例如OAuth、OpenID Connect等。SSO的优势包括降低密码管理成本、提高安全性、增强用户体验等。

跨域认证（Cross-Origin Authentication）是指在不同域之间进行身份认证的过程。由于同源策略的限制，不同域之间的页面无法直接访问彼此的Cookie信息，因此跨域认证需要使用特殊的技术手段来实现。常见的跨域认证方式包括OAuth、OpenID Connect等。OAuth是一种基于令牌的授权机制，允许用户授权第三方应用程序访问其资源，而无需将用户名和密码直接提供给第三方应用程序。OpenID Connect是基于OAuth 2.0的身份验证协议，提供了一种标准化的方式来验证用户身份和授权访问权限。通过使用这些跨域认证技术，应用程序可以安全地进行跨域身份认证，提高用户体验和安全性。

Jwt认证的一些优势

数据量小，传输迅速
Json加密形式保存在客户端，可跨语言，原则上支持各种web形式。
无需在服务器保存会话信息。
适用于分布式、移动端
SSO友好

故常见的分布式应用和单点式应用更加适合JWT。

Zero Turst

传统的Session和JWT权限管理方式都是基于令牌的方式，而零信任权限管理则更加注重身份验证和访问控制。在零信任模型中，每个用户和设备都需要进行身份验证，并且需要对其进行访问控制，以确保只有经过授权的用户和设备可以访问受保护的资源。与传统的Session和JWT相比，零信任权限管理更加安全和可靠，因为它采用了多层次的安全防护措施，包括身份验证、访问控制、数据加密等。同时，零信任权限管理还可以实现更细粒度的访问控制，以确保每个用户和设备只能访问其需要的资源，从而提高了系统的安全性和可靠性。

Jwt的结构

JWT由三部分构成：Header+Payload+Signature.

传输时，各部分分别base64编码后以.连接，形成最终传输字符串。

每部分对应作用：

header和payload可以可解码出原文，获得哈希签名和有效数据。此处有效数据可以另行加密。
signature使用散列函数，无法解码，用于校验token是否有所修改：

校验过程：

header中获取加密算法，利用算法加上SecretKey对header、payload进行加密，比对加密后的数据和客户端发送来的是否一致。主一般对于md5系列，SecretKey代表盐值。

1
2
3
4


{
  "alg": "HS256",
  "typ": "JWT"
}

alg即algorithm，默认HS256（HMAC SHA256)

typ即这个token的type，jwt类型写为 “JWT”

Payload

官方给出七个字段：

1
2
3
4
5
6
7


iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号

也可自定义私有字段

1
2
3
4
5


{
  "sub": "Test Text",
  "name": "HaLois",
  "admin": true
}

注意，JWT 默认是不加密的

Signature

Signature 部分是对前两部分的签名，防止数据篡改。

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256）

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。

Jwt的分类

nosecure JWT:未经signature，不安全。
JWS:经过签名。
JWE:payload部分经过加密。

Nosecure Jwt

header部分无指定签名算法。

1
2
3
4
5


{
  "alg": "none",
  "typ": "JWT"
}

Jws

JWT Signature,结构为 Nosecure Jwt基础上增加头部算法声明，并在最后添加签名。

完成签名需要的SecretKey:

对称加密：可用于生成签名于验证签名。
非堆成加密：SecretKey指私钥，只能用于生成签名，公钥用于验证签名。

JWT的密钥或密钥对统称为JSON Web Key

JWT签名算法：

HMAC 【哈希消息验证码（对称）】：HS256/HS384/HS512
RSASSA【RSA签名算法（非对称）】：RS256/RS384/RS512
ECDSA 【ECC签名算法（非对称）】：ES256/ES384/ES512

在实际开发中需要用下列手段来增加JWT的安全性：

JWT在请求头中传递的，故为避免网络劫持，推荐使用HTTPS来传输，更加安全
JWT的哈希签名的密钥是存放在服务端的，所以只要服务器不被攻破，理论上JWT是安全的。因此要保证服务器的安全
JWT可以使用暴力穷举来破解，所以为了应对这种破解方式，哈希签名密钥(盐值)需要添加生命周期。

Jwt的特点

JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
JWT 不加密的情况下，不能将秘密数据写入 JWT。
JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

目录