异步认证与同步认证的分离史

这里不谈技术,只谈思想

文章来自我的公众号(WebHub)

异步认证与同步认证的分离史

*凭证取代浏览器Cookie

浏览器cookie是上世纪90年代用于在客户端和服务器间保持短连接的会话机制,但在本世纪的第18年,cookie退出了历史舞台,不信你看现在的http请求方法fetch默认都不带cookie了,如下图:

异步认证与同步认证的分离史

这里的cookie指的是浏览器自带的cookie机制,是一个狭义的概念。浏览器cookie被淘汰了,取而代之的是自定义会话凭证比如JWT。

cookie在互联网上的首次应用(非实验室应用)是在Netscape网站上判断用户是否是首次访问本站。

cookie被淘汰的理由很简单,cookie为各大浏览器服役了24年,最终臃肿而死。简单地说,cookie机制不够灵活,强制性发送/接受,无法按需定制,后来为了向下兼容又推出什么http-only的古怪功能,乱七八糟的扩展加剧了cookie的膨胀,沉重的历史包袱终于压垮了cookie,现代开发者更倾向于自制会话凭证,按需发送/接收/存储凭证,同时还能跨域。JWT就是这样一种*凭证的格式规范,而且非常简单,于是大部分“*凭证追随者”都愿意使用JWT,包括我。

 

一次性认证,无会话认证(假想没有同步认证的世界)

认证和会话保持是2个概念,认证是一次性的,首次认证之后通过客户端保存的凭证(某种随机数)形成长久性的会话,这是当今标准的认证体系。如果认证与会话不分离会是怎样一个世界呢?

我们来回忆一下认证的基本逻辑:假设有一个论坛网站,服务器对每一次的用户请求都要进行认证,要判断请求者是谁,“谁”的信息通常是保存在数据库中。想要实现用户可以*发帖,看帖,最简单暴力的方法就是每次请求的http包里都携带一份用户名和密码(不考虑网络安全问题,或者使用https),每次服务器都要对你进行认证(在数据库里匹配用户名和密码)。

这有点像我国古代用来调兵遣将的虎符。用青铜或者黄金做成伏虎形状的令牌,劈为两半,其中一半交给将帅,另一半由皇帝保存,只有两个虎符同时使用,才可以调兵遣将。虎符有点像现代银行给你的U盾(有的叫K宝,囧),反正就是一个小型USB令牌,相当于银行颁发给你的证书。

但是这种模型有一个致命的缺陷,它忽视了认证的复杂性。

 

认证应当是一种很耗时的过程(异步认证)

现在已经很少能看见那种只要输入用户名和密码就能登录的网站了,稍微有点安全意识的网站都会像腾讯系和阿里系那样通过各种各样的手段(微信登录,手机短信验证,新设备登录拦截,图片验证码,人脸识别。。。)来对你进行认证,确保万无一失才让你登录成功,这些认证过程至少消耗你10秒钟(有点像是异步任务的感觉)。

而古老的“用户名密码一键登录”的时代已经过去了,用户名密码在数据库中匹配一下都是毫秒级别的(有点像同步任务的感觉),这种古代认证体系必然是不安全的。

 

认证与会话保持的分离(异步与同步认证的分离)

于是,在互联网时代,出现了“会话(包括许多同义词:长连接,有状态...)”的概念。为了便于理解,请原谅我发明了2个新概念:异步认证和同步认证。异步认证指的是建立长连接之前的比较耗时的认证,比如手机扫码登录时等待的几秒钟你还可以喝一口咖啡,干点别的事情,遂称之异步。同步认证指的是异步认证完成并保存了一份凭证(JWT或cookie),服务器检验凭证是毫秒级别的速度,在此期间你没机会干别的事情,遂称之同步。

不像古代,包括原始互联网上所有的认证都是异步的,现在的互联网认证模型基本上就是以下的流程:首先进行异步认证,输入密码或者生物特征,然后服务器生成一个只有你们俩知道的随机凭证,在凭证的有效期内你无需再进行任何异步认证,取而代之的是简单的同步认证。凭证到期后,你和服务器将互删好友(删除过期凭证),会话结束,等待下一次异步认证。

当然,很多人都知道这个简单的原理,我只是把整个过程用另一种风格概述了一下。

 

shit,本来打算写一篇JWT的入门教程的,没想到为了介绍背景知识就写了1000多字,那本文索性就换了标题,将错就错!

哦对了,新年快乐!

(完)

 

 


异步认证与同步认证的分离史