前端鉴权知识学习

7,156 阅读8分钟

1、Cookie

指某些网站为了辨别用户身份而储存在用户本地终端(Client Side)上的数据(通常经过加密)。

HTTP是一种无状态传输协议,它不能以状态来区分和管理请求和响应。也就是说,服务器单从网络连接上无从知道客户身份。于是给客户端发布一个通行证—cookie来区分,这就是Cookie的工作原理。

服务器通过response的set-cookie告诉客户端去写入cookie,后面的请求都会携带该cookie。

image

cookie有以下重要参数:

image

2、Session

session 是另一种记录服务器和客户端会话状态的机制。session存储在服务器端,该会话对应的key即sessionId会被存储到客户端的cookie中。

image

根据以上流程可知,session通过cookie来传递sessionId,达到用户鉴权的目的。除此之外,sessionId也可以不通过cookie传递,比如通过response返回客户端,再当作请求的参数传递给服务器去验证。

Cookie 和 Session 对比
  • 安全性: Session 比 Cookie 安全,Session 是存储在服务器端的,Cookie 是存储在客户端的。
  • 存取值的类型:Cookie只支持存字符串数据,想要设置其他类型的数据,需要将其转换成字符串,Session 可以存任意数据类型。
  • 有效期: Cookie可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般失效时间较短,客户端关闭(默认情况下)或者 Session 超时都会失效。
  • 存储大小: 单个 Cookie 保存的数据不能超过 4K,Session 可存储数据远高于 Cookie,但是当访问量过多,会占用过多的服务器资源。
session缺点:
  • 占资源: 每个经过认证的用户都要存放session到内存中,而随着认证用户的增多,服务端的开销较大。
  • CSRF攻击:基于cookie来进行用户识别时,用户cookie如果被截获,就容易受到跨站请求伪造的攻击。

3、Token

token(令牌) 是一串字符串,通常作为鉴权凭据,最常用的使用场景是 API 鉴权。

一般来说 token 主要有三种:
  • 自定义的 token:开发者根据业务逻辑自定义的 token
  • JWT:JSON Web Token,定义在 RFC 7519 中的一种 token 规范
  • Oauth2.0:定义在 RFC 6750 中的一种授权规范,其实并不是一种 token,只是其中也有用到 token。
token特点:
  • 服务端无状态化、可扩展性好
  • 支持移动端设备
  • 安全性高
  • 支持跨程序调用
token鉴权流程:

image

Refresh Token

refresh token 是专用于刷新 access token 的 token。Access Token的有效期比较 短,当 Acesss Token 由于过期而失效时,使用 Refresh Token 就可以获取到新的 Token,如果 Refresh Token过期就只能重新登陆了。

image

Token 和 Session 的区别
  • Session 是一种记录服务器和客户端会话状态的机制,使服务端有状态化,可以记录会话信息。而 Token 是令牌,访问资源接口(API)时所需要的资源凭证。Token 使服务端无状态化,不会存储会话信息。
  • Session 和 Token 并不矛盾,作为身份认证 Token 安全性比 Session 好,因为每一个请求都有签名还能防止监听以及
  • 重放攻击
  • ,而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话,仍然可以增加 Session 来在服务器端保存一些状态。
  • 所谓 Session 认证只是简单的把 User 信息存储到 Session 里,因为 SessionID 的不可预测性,暂且认为是安全的。而 Token ,如果指的是 OAuth Token 或类似的机制的话,提供的是 认证 和 授权 ,认证是针对用户,授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。

4、JWT

JSON Web Token(简称JWT)是目前最流行的跨域认证解决方案,是一种认证授权机制,是一种基于 JSON 的开放标准。

JWT组成
一个 JWT token 是一个字符串,它由头部、载荷与签名三部分组成,中间用 . 分隔,形式如下:
base64(header).base64(json payload).signature

详细介绍参见:阮一峰JSON Web Token 入门教程

JWT 认证流程:
  1. 用户输入用户名/密码登录,服务端认证成功后,会返回给客户端一个 JWT。
  2. 客户端将 jwt 保存到本地,当用户希望访问一个受保护的路由或者资源的时候,需要请求头的 Authorization 字段中使用 Bearer 模式添加 JWT 。
  3. 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息,如果合法,则允许访问。因为 JWT 内部包含了一些用户信息,因此减少了需要查询数据库的需要。
JWT 的使用方式

1、存放在cookie中
当用户希望访问一个受保护的路由或者资源的时候,可以把它放在 Cookie 里面自动发送,但是这样不能跨域。

2、存放在localstorage中,添加到header中发送
请求时放在 HTTP 请求头信息的 Authorization 字段里,使用 Bearer 模式添加 JWT。

Authorization: Bearer <token>

3、通过接口参数
可以把 JWT 放在 POST 请求的数据体里,或者通过 URL 的 queryString 传输。

自定义Token 和 JWT 的关系

相同点: 都是访问资源的令牌,都可以记录用户的信息,都是使服务端无状态化,都是只有验证成功后,客户端才能访问服务端上受保护的资源

区别:服务端验证客户端发来的token信息要进行数据的查询操作;JWT验证客户端发来的token信息就不用, 在服务端使用密钥校验就可以,不用数据库的查询。

5、各种鉴权方式注意点

使用 cookie 注意点
  • 因为存储在客户端,容易被客户端篡改,使用前需要验证合法性
  • 不要存储敏感数据,比如用户密码,账户余额
  • 使用 httpOnly 在一定程度上提高安全性
  • 尽量减少 cookie 的体积,能存储的数据量不能超过 4kb
  • 设置正确的 domain 和 path,减少数据传输
  • cookie 无法跨域,子域名可以访问父域名
  • 一个浏览器针对一个网站最多存 20 个Cookie,浏览器一般只允许存放 300 个Cookie
  • 移动端对 cookie 的支持不是很好,而 session 一般基于 cookie 实现,所以移动端常用的是 token
使用 session 注意点
  • 用户同时在线量较多时,session 存储在服务器会占据较多内存,需要定期清理过期 的 session
  • 当网站采用集群部署的时候,会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session是由单个服务器创建的,处理用户请求的服务器不一定是 那个创建 session 的服务器,那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。
  • 当多个应用要共享 session时,因为不同的应用可能部署的主机不一样需要在各个应用做好 cookie 跨域的处理。
  • sessionId 是存储在 cookie 中的,假如浏览器禁止 cookie 或不支持 cookie ,一般会把 sessionId 跟在 url 参数后面即重写 url,所以 session 不一定非得需要靠 cookie 实现
使用 token 注意点
  • 如果你认为用数据库来存储 token会导致查询时间太长,可以选择放在 内存当中,比如 redis 很适合你对 token 查询的需求。
  • token 完全由应用管理,所以它可以避开同源策略
  • token 可以避免 CSRF 攻击(因为不需要 cookie 了)
  • 移动端对 cookie 的支持不是很好,而 session 需要基于 cookie 实现,所以移动端常用的是 token
使用 JWT 时需要考虑的问题
  • JWT 默认是不加密,但也是可以加密的。生成原始 Token 以后,可以用密钥再加密一次。
  • JWT 不加密的情况下,不能将秘密数据写入 JWT。
  • JWT 不仅可以用于认证,也可以用于交换信息。有效使用 JWT,可以降低服务器查询数据库的次数。
  • JWT 最大的优势是服务器不再需要存储Session,使得服务器认证鉴权业务可以方便扩展。但这也是 JWT 最大的缺点:由于服务器不需要存储 Session 状态,因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了,到期之前就会始终有效,除非服务器部署额外的逻辑。
  • JWT 本身包含了认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证。
  • JWT 适合一次性的命令认证,颁发一个有效期极短的JWT,即使暴露了危险也很小由 于每次操作都会生成新的 JWT,因此也没必要保存 JWT,真正实现无状态。
  • 为了减少盗用,JWT 不应该使用 HTTP 协议明码传输,要使用 HTTPS 协议传输。

参考资料: