Token 原理解读

前言

每种事物的产生,都有它的历史原因

上一篇文章我们了解了一下 cookie 与 session 的产生、作用与原理。尽管二者在历史中已经服役过很长一段时间,但不论什么技术,都会有后来的优秀者取而代之。

前面说到,cookie 因为是保存在客户端,所以有安全隐患,因而诞生了 session,session 保存在服务器端,相对安全很多。但 session 每次都要为用户开辟一个空间用于其身份校验,且每次浏览器的请求过来服务器都要进行校验请求,十分耗费服务器的空间与性能。

于是,另一种身份校验工具诞生了,这就是 token。

一、什么是 token

token,英语意为“令牌”

token

本质上还是用户身份验证的工具。但与 cookie、session 明文似的形式不同,token 是经过一系列加密手段加密过的,最后表现为一串“无意义”的字符串。但里面包含了许多信息,可能包括用户登录的终端的地址、用户身份 ID、时间戳以及一个签名。所谓签名就是信息发送者给这段信息进行签名,让信息接收方知道请求 token 是属于谁。可以理解为在你的身份证上签名字,证件加笔迹双重认证。

CSRF 攻击与同源策略

CSRF攻击,意为“跨站点请求伪造”

CSRF 攻击过程

  1. 用户 C 打开浏览器,访问受信任网站 A,输入用户名和密码请求登录网站 A;

  2. 在用户信息通过验证后,网站 A 产生 Cookie 信息并返回给浏览器,此时用户登录网站 A 成功,可以正常发送请求到网站 A;

  3. 用户未退出网站 A 之前,在同一浏览器中,打开一个 TAB 页访问网站 B;

  4. 网站 B 接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点 A;

  5. 浏览器在接收到这些攻击性代码后,根据网站 B 的请求,在用户不知情的情况下携带 Cookie 信息,向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的,所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求,导致来自网站 B 的恶意代码被执行。

同源策略

为了避免上述 CSRF 攻击,浏览器对网页资源的访问提出了限制,URL 请求必须是与页面一样来自同一协议域名端口才给予访问权限。这样三者相同的站点被认为是有相同的“源”,是一个独立的“域”。即使 “localhost” 与 “ip” 都指向了本机,但也会被认为是非同源。浏览器在某个“域”下不会执行其他“域”的脚本。因而这也产生了前端领域里一个重要的话题:跨域。

session 的产生来自于用户登录后服务器生成的一个 session 对象,保存在服务器端,这个 session 只适用于该“域”。但实际情况是,一个网站的请求大多数情况下都会跨域,每台服务器的端口不同,甚至是域名就不同,每当跨域时就会形成新的会话,生成新的 session,这是非常影响用户体验的,所以也会有许多保存、共享或中央存储 session 的方案。

但上述两种限制在 token 这里就不再是问题。

token 的优势

  1. 如果有恶意站点利用本地 cookie 对其他站点进行可以攻击,token 可以作为一种身份验证机制限制这种“攻击式的请求”,可以有效避免 CSRF 攻击
  2. token 因为保存在浏览器端,可以避开同源策略
  3. token 是随机生成的,具有不可预测性和防暴力拆解性
  4. 移动端没有 cookie 与 session,token 可以有效兼容移动端
  5. token 也可以设置过期时间,让其具有时效性,把控用户登录的状态与安全

二、token 验证流程

与 cookie 类似。

首先,用户输入账号密码,发起登录请求,服务器校验账号密码合法性,成功则返回 token 给客户端。

客户端收到响应后拿到 token,将其通过 localStorage 等本地存储方式进行保存。

当浏览器再次请求时,需要在请求头中添加 token,这样服务器在接收到请求后便可以识别该请求的身份是否合法,合法则返回响应数据。

在实际应用中,配合 axios 的请求拦截器使用起来会很方便:

request.interceptors.request.use(config => {
  const token = window.localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = token
  }
  return config
})

这样,就不用每次请求都手动添加 token,axios 会自动帮助我们完成添加,十分方便。

后记

其实前端程序员对 token 的涉及没有多深,只需要在需要授权的请求中携带 token 即可。token 的生成、加密等都是后端去处理。所以,这里也就不在赘述 token 的加密原理,以笔者的能力也很难去讲述清楚。

token 运用也不是上文中描述的那么简单,涉及到一些过期处理、refresh 等操作。这些日后有机会再详谈。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,588评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,456评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,146评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,387评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,481评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,510评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,522评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,296评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,745评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,039评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,202评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,901评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,538评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,165评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,415评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,081评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,085评论 2 352

推荐阅读更多精彩内容