JWT与Session比较和作用

1. JSON Web Token是什么

JSON Web Token (JWT)是一个开放标准(RFC 7519),它定义了一种紧凑的、自包含的方式,用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任,因为它是数字签名的。

2. 什么时候你应该用JSON Web Tokens

下列场景中使用JSON Web Token是很有用的:

Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录,后续每个请求都将包含JWT,允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性,因为它的开销很小,并且可以轻松地跨域使用。

Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言,JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名,例如,用公钥/私钥对,你可以确定发送人就是它们所说的那个人。另外,由于签名是使用头和有效负载计算的,您还可以验证内容没有被篡改。

3. JSON Web Token的结构是什么样的

JSON Web Token由三部分组成,它们之间用圆点(.)连接。这三部分分别是:

  • Header
  • Payload
  • Signature

因此,一个典型的JWT看起来是这个样子的:

xxxxx.yyyyy.zzzzz

接下来,具体看一下每一部分:

Header

header典型的由两部分组成:token的类型(“JWT”)和算法名称(比如:HMAC SHA256或者RSA等等)。

例如:

然后,用Base64对这个JSON编码就得到JWT的第一部分

Payload

JWT的第二部分是payload,它包含声明(要求)。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。

Registered claims : 这里有一组预定义的声明,它们不是强制的,但是推荐。比如:iss (issuer), exp (expiration time), sub (subject), aud (audience)等。

Public claims : 可以随意定义。

Private claims : 用于在同意使用它们的各方之间共享信息,并且不是注册的或公开的声明。

下面是一个例子:

对payload进行Base64编码就得到JWT的第二部分

注意,不要在JWT的payload或header中放置敏感信息,除非它们是加密的。

Signature

为了得到签名部分,你必须有编码过的header、编码过的payload、一个秘钥,签名算法是header中指定的那个,然对它们签名即可。

例如:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

签名是用于验证消息在传递过程中有没有被更改,并且,对于使用私钥签名的token,它还可以验证JWT的发送方是否为它所称的发送方。

看一张官网的图就明白了:

4. JSON Web Tokens是如何工作的

在认证的时候,当用户用他们的凭证成功登录以后,一个JSON Web Token将会被返回。此后,token就是用户凭证了,你必须非常小心以防止出现安全问题。一般而言,你保存令牌的时候不应该超过你所需要它的时间。

无论何时用户想要访问受保护的路由或者资源的时候,用户代理(通常是浏览器)都应该带上JWT,典型的,通常放在Authorization header中,用Bearer schema。

header应该看起来是这样的:

Authorization: Bearer

服务器上的受保护的路由将会检查Authorization header中的JWT是否有效,如果有效,则用户可以访问受保护的资源。如果JWT包含足够多的必需的数据,那么就可以减少对某些操作的数据库查询的需要,尽管可能并不总是如此。

如果token是在授权头(Authorization header)中发送的,那么跨源资源共享(CORS)将不会成为问题,因为它不使用cookie。

下面这张图显示了如何获取JWT以及使用它来访问APIs或者资源:

  • 应用(或者客户端)想授权服务器请求授权。例如,如果用授权码流程的话,就是/oauth/authorize
  • 当授权被许可以后,授权服务器返回一个access token给应用
  • 应用使用access token访问受保护的资源(比如:API)

5. 基于Token的身份认证 与 基于服务器的身份认证

5.1. 基于服务器的身份认证

在讨论基于Token的身份认证是如何工作的以及它的好处之前,我们先来看一下以前我们是怎么做的:

HTTP协议是无状态的,也就是说,如果我们已经认证了一个用户,那么他下一次请求的时候,服务器不知道我是谁,我们必须再次认证

传统的做法是将已经认证过的用户信息存储在服务器上,比如Session。用户下次请求的时候带着Session ID,然后服务器以此检查用户是否认证过。

这种基于服务器的身份认证方式存在一些问题:

Sessions : 每次用户认证通过以后,服务器需要创建一条记录保存用户信息,通常是在内存中,随着认证通过的用户越来越多,服务器的在这里的开销就会越来越大。

Scalability : 由于Session是在内存中的,这就带来一些扩展性的问题。

CORS : 当我们想要扩展我们的应用,让我们的数据被多个移动设备使用时,我们必须考虑跨资源共享问题。当使用AJAX调用从另一个域名下获取资源时,我们可能会遇到禁止请求的问题。

CSRF : 用户很容易受到CSRF攻击。

5.2. JWT与Session的差异

相同点是,它们都是存储用户信息;然而,Session是在服务器端的,而JWT是在客户端的。

Session方式存储用户信息的最大问题在于要占用大量服务器内存,增加服务器的开销。

而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。

Session的状态是存储在服务器端,客户端只有session id;而Token的状态是存储在客户端。

5.3. 基于Token的身份认证是如何工作的

基于Token的身份认证是无状态的,服务器或者Session中不会存储任何用户信息。

没有会话信息意味着应用程序可以根据需要扩展和添加更多的机器,而不必担心用户登录的位置。

虽然这一实现可能会有所不同,但其主要流程如下:

  • 用户携带用户名和密码请求访问
  • 服务器校验用户凭据
  • 应用提供一个token给客户端
  • 客户端存储token,并且在随后的每一次请求中都带着它
  • 服务器校验token并返回数据

注意:

  • 每一次请求都需要token
  • Token应该放在请求header中
  • 我们还需要将服务器设置为接受来自所有域的请求,用Access-Control-Allow-Origin: *

5.4. 用Token的好处

无状态和可扩展性:Tokens存储在客户端。完全无状态,可扩展。我们的负载均衡器可以将用户传递到任意服务器,因为在任何地方都没有状态或会话信息。

安全:Token不是Cookie。(The token, not a cookie.)每次请求的时候Token都会被发送。而且,由于没有Cookie被发送,还有助于防止CSRF攻击。即使在你的实现中将token存储到客户端的Cookie中,这个Cookie也只是一种存储机制,而非身份认证机制。没有基于会话的信息可以操作,因为我们没有会话!

还有一点,token在一段时间以后会过期,这个时候用户需要重新登录。这有助于我们保持安全。还有一个概念叫token撤销,它允许我们根据相同的授权许可使特定的token甚至一组token无效。

5.5. JWT与OAuth的区别

  • OAuth2是一种授权框架 ,JWT是一种认证协议
  • 无论使用哪种方式切记用HTTPS来保证数据的安全性
  • OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app),而JWT是用在前后端分离, 需要简单的对后台API进行保护时使用。

原文地址:https://www.cnblogs.com/hellohorld/p/11022967.html

时间: 2024-10-19 05:21:37

JWT与Session比较和作用的相关文章

ASP.NET Core Web Api之JWT VS Session VS Cookie(二)

前言 本文我们来探讨下JWT VS Session的问题,这个问题本没有过多的去思考,看到评论讨论太激烈,就花了一点时间去研究和总结,顺便说一句,这就是写博客的好处,一篇博客写出有的可能是经验积累,有的可能是学习分享,但都逃不过看到文章的你有更多或更好的想法,往返交流自身能收获更多,何乐而不为呢?希望本文能解惑或者能得到更多的交流.我们可直接抛出问题:使用客户端存储的JWT比服务端维持Session更好吗? 基于JWT和Session认证共同点 既然要比较JWT VS Session,那我们就得

认证 协议 JWT OAuth Session Cookie

本文翻译自Auth-Boss. 如果有翻译的不恰当或不对的地方, 欢迎指出. 成为一个认证老司机, 了解网络上不同的身份认证方法. 本文档的目的是记录和编目Web上的身份验证方法.认证指的是创建一个系统的过程,用户可以通过该系统"登录"在线服务,并授予对受保护资源的访问权限.以下引用可能更好地总结我想要解释的内容: 客户端认证涉及向Web上的服务器证明客户端(或用户)的身份.[1] How 我写作风格简洁,会用到一些技术词. 免责声明:本文档不作为包含所有认证方法的网络的目录;本文档也

jwt vs session

https://cnodejs.org/topic/5b568ec12860af042a217822 https://juejin.im/post/5a437441f265da43294e54c3 1.可扩展性 session是有状态的,token是无状态的,所以如果多台服务器上的应用,单点登录,基于token 的验证是有优势的. 构建但服务器应用,不需要RESTful API的,那么session也不错. 2.安全性 jwt最好使用https 3.RESTful 无状态,token更契合RES

用户认证:基于jwt和session的区别和优缺点

背景知识: Authentication和Authorization的区别: Authentication:用户认证,指的是验证用户的身份,例如你希望以小A的身份登录,那么应用程序需要通过用户名和密码确认你真的是小A. Authorization:授权,指的是确认你的身份之后提供给你权限,例如用户小A可以修改数据,而用户小B只能阅读数据. 由于http协议是无状态的,每一次请求都无状态.当一个用户通过用户名和密码登录了之后,他的下一个请求不会携带任何状态,应用程序无法知道他的身份,那就必须重新认

Linux下,PHP的SESSION不起作用的问题

改动SESSION目录的权限就能够了. 先找到SESSION目录, 然后 chmod -R 777 /var/lib/php/session 假设没有此目录,则新建此目录 mkdir -R 777 /var/lib/php/session

你在用 JWT 代替 Session?

现在,JSON Web Tokens (JWT) 是非常流行的.尤其是 Web 开发领域. 流行 安全 稳定 易用 支持 JSON 所有这些因素,令 JWT 名声大振. 但是,今天我要来说说使用 JWT 的缺点.也就是为什么说将 JWT 用于会话控制是多么的糟糕. 为什么使用 JWT? 如果你不了解 JWT,不要紧张,它并不可怕. JWT 只是用于网络间传递声明而执行一种基于 JSON 的标准. 例如,我是个盲人,而且听力也不好.你上周帮我买了午餐,现在我需要你的收款账号,把钱还给你.如果我询问

Cookie和Session的作用和工作原理

本文链接:https://blog.csdn.net/guoweimelon/article/details/50886092 一.Cookie详解 (1)简介 因为HTTP协议是无状态的,即服务器不知道用户上一次做了什么,这严重阻碍了交互式Web应用程序的实现.在典型的网上购物场景中,用户浏览了几个页面,买了一盒饼干和两饮料.最后结帐时,由于HTTP的无状态性,不通过额外的手段,服务器并不知道用户到底买了什么.为了做到这点,就需要使用到Cookie了.服务器可以设置或读取Cookies中包含信

权限认证基础:区分Authentication,Authorization以及Cookie、Session、Token

1. 认证 (Authentication) 和授权 (Authorization)的区别是什么? 这是一个绝大多数人都会混淆的问题.首先先从读音上来认识这两个名词,很多人都会把它俩的读音搞混,所以我建议你先先去查一查这两个单词到底该怎么读,他们的具体含义是什么. 说简单点就是: 认证 (Authentication): 你是谁. 授权 (Authorization): 你有权限干什么. 稍微正式点(啰嗦点)的说法就是: Authentication(认证) 是验证您的身份的凭据(例如用户名/用

看完这篇 Session、Cookie、Token,和面试官扯皮就没问题了

Cookie 和 Session HTTP 协议是一种无状态协议,即每次服务端接收到客户端的请求时,都是一个全新的请求,服务器并不知道客户端的历史请求记录:Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性. Session 是什么 客户端请求服务端,服务端会为这次请求开辟一块内存空间,这个对象便是 Session 对象,存储结构为 ConcurrentHashMap.Session 弥补了 HTTP 无状态特性,服务器可以利用 Session 存储客户端在同一个会