鉴权必须了解的5个兄弟cookiesessiontokenj

　　本文你将看到：基于HTTP的前端鉴权背景cookie为什么是最方便的存储方案，有哪些操作cookie的方式session方案是如何实现的，存在哪些问题token方案是如何实现的，如何进行编码和防篡改？jwt是做什么的？refreshtoken的实现和意义session和token有什么异同和优缺点单点登录是什么？实现思路和在浏览器下的处理从状态说起
　　HTTP无状态我们知道，HTTP是无状态的。也就是说，HTTP请求方和响应方间无法维护状态，都是一次性的，它不知道前后的请求都发生了什么。但有的场景下，我们需要维护状态。最典型的，一个用户登陆微博，发布、关注、评论，都应是在登录后的用户状态下的。标记那解决办法是什么呢？：：标记：：。
　　在学校或公司，入学入职那一天起，会录入你的身份、账户信息，然后给你发个卡，今后在园区内，你的门禁、打卡、消费都只需要刷这张卡。
　　前端存储这就涉及到一发、一存、一带，发好办，登陆接口直接返回给前端，存储就需要前端想办法了。
　　前提是，你要把卡带在身上。
　　前端的存储方式有很多。最矬的，挂到全局变量上，但这是个体验卡，一次刷新页面就没了高端点的，存到cookie、localStorage等里，这属于会员卡，无论怎么刷新，只要浏览器没清掉或者过期，就一直拿着这个状态。前端存储这里不展开了。有地方存了，请求的时候就可以拼到参数里带给接口了。基石：cookie
　　可是前端好麻烦啊，又要自己存，又要想办法带出去，有没有不用操心的？
　　有，cookie。cookie也是前端存储的一种，但相比于localStorage等其他方式，借助HTTP头、浏览器能力，cookie可以做到前端无感知。一般过程是这样的：在提供标记的接口，通过HTTP返回头的SetCookie字段，直接种到浏览器上浏览器发起请求时，会自动把cookie通过HTTP请求头的Cookie字段，带给接口
　　配置：DomainPath
　　你不能拿清华的校园卡进北大。
　　cookie是要限制：：空间范围：：的，通过Domain（域）Path（路径）两级。
　　Domain属性指定浏览器发出HTTP请求时，哪些域名要附带这个Cookie。如果没有指定该属性，浏览器会默认将其设为当前URL的一级域名，比如www。example。com会设为example。com，而且以后如果访问example。com的任何子域名，HTTP请求也会带上这个Cookie。如果服务器在SetCookie字段指定的域名，不属于当前域名，浏览器会拒绝这个Cookie。Path属性指定浏览器发出HTTP请求时，哪些路径要附带这个Cookie。只要浏览器发现，Path属性是HTTP请求路径的开头一部分，就会在头信息里面带上这个Cookie。比如，PATH属性是，那么请求docs路径也会包含该Cookie。当然，前提是域名必须一致。CookieJavaScript标准参考教程（alpha）
　　配置：ExpiresMaxAge
　　你毕业了卡就不好使了。
　　cookie还可以限制：：时间范围：：，通过Expires、MaxAge中的一种。
　　Expires属性指定一个具体的到期时间，到了指定时间以后，浏览器就不再保留这个Cookie。它的值是UTC格式。如果不设置该属性，或者设为null，Cookie只在当前会话（session）有效，浏览器窗口一旦关闭，当前Session结束，该Cookie就会被删除。另外，浏览器根据本地时间，决定Cookie是否过期，由于本地时间是不精确的，所以没有办法保证Cookie一定会在服务器指定的时间过期。MaxAge属性指定从现在开始Cookie存在的秒数，比如606024365（即一年）。过了这个时间以后，浏览器就不再保留这个Cookie。如果同时指定了Expires和MaxAge，那么MaxAge的值将优先生效。如果SetCookie字段没有指定Expires或MaxAge属性，那么这个Cookie就是SessionCookie，即它只在本次对话存在，一旦用户关闭浏览器，浏览器就不会再保留这个Cookie。CookieJavaScript标准参考教程（alpha）
　　配置：SecureHttpOnly
　　有的学校规定，不带卡套不让刷（什么奇葩学校，假设）；有的学校不让自己给卡贴贴纸。
　　cookie可以限制：：使用方式：：。
　　Secure属性指定浏览器只有在加密协议HTTPS下，才能将这个Cookie发送到服务器。另一方面，如果当前协议是HTTP，浏览器会自动忽略服务器发来的Secure属性。该属性只是一个开关，不需要指定值。如果通信是HTTPS协议，该开关自动打开。HttpOnly属性指定该Cookie无法通过JavaScript脚本拿到，主要是Document。cookie属性、XMLHttpRequest对象和RequestAPI都拿不到该属性。这样就防止了该Cookie被脚本读到，只有浏览器发出HTTP请求时，才会带上该Cookie。CookieJavaScript标准参考教程（alpha）
　　HTTP头对cookie的读写回过头来，HTTP是如何写入和传递cookie及其配置的呢？HTTP返回的一个SetCookie头用于向浏览器写入一条（且只能是一条）cookie，格式为cookie键值配置键值。例如：SetCookie：usernamejimu；domainjimu。com；pathblog；ExpiresWed，21Oct201507：28：00GMT；Secure；HttpOnly
　　那我想一次多set几个cookie怎么办？多给几个SetCookie头（一次HTTP请求中允许重复）SetCookie：usernamejimu；domainjimu。comSetCookie：height180；domainme。jimu。comSetCookie：weight80；domainme。jimu。com
　　HTTP请求的Cookie头用于浏览器把符合当前空间、时间、使用方式配置的所有cookie一并发给服务端。因为由浏览器做了筛选判断，就不需要归还配置内容了，只要发送键值就可以。Cookie：usernamejimu；height180；weight80
　　前端对cookie的读写前端可以自己创建cookie，如果服务端创建的cookie没加HttpOnly，那恭喜你也可以修改他给的cookie。调用document。cookie可以创建、修改cookie，和HTTP一样，一次document。cookie能且只能操作一个cookie。document。cookieusernamejimu；domainjimu。com；pathblog；ExpiresWed，21Oct201507：28：00GMT；Secure；HttpOnly；
　　调用document。cookie也可以读到cookie，也和HTTP一样，能读到所有的非HttpOnlycookie。console。log（document。cookie）；usernamejimu；height180；weight80（就一个cookie属性，为什么读写行为不一样？getset了解下）cookie是维持HTTP请求状态的基石了解了cookie后，我们知道cookie是最便捷的维持HTTP请求状态的方式，大多数前端鉴权问题都是靠cookie解决的。当然也可以选用别的存储方式（后面也会多多少少提到）。那有了存储工具，接下来怎么做呢？应用方案：服务端session
　　现在回想下，你刷卡的时候发生了什么？
　　其实你的卡上只存了一个id（可能是你的学号），刷的时候物业系统去查你的信息、账户，再决定这个门你能不能进这个鸡腿去哪个账户扣钱。
　　这种操作，在前后端鉴权系统中，叫session。典型的session登陆验证流程：
　　浏览器登录发送账号密码，服务端查用户库，校验用户服务端把用户登录状态存为Session，生成一个sessionId通过登录接口返回，把sessionIdset到cookie上此后浏览器再请求业务接口，sessionId随cookie带上服务端查sessionId校验session成功后正常做业务处理，返回结果
　　Session的存储方式显然，服务端只是给cookie一个sessionId，而session的具体内容（可能包含用户信息、session状态等），要自己存一下。存储的方式有几种：Redis（推荐）：内存型数据库，redis中文官方网站。以keyvalue的形式存，正合sessionIdsessionData的场景；且访问快。内存：直接放到变量里。一旦服务重启就没了数据库：普通数据库。性能不高。
　　Session的过期和销毁很简单，只要把存储的session数据销毁就可以。Session的分布式问题通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session不就失效了吗？这个问题现在有几种解决方式。一是从存储角度，把session集中存储。如果我们用独立的Redis或普通数据库，就可以把session都存到一个库里。二是从分布角度，让相同IP的请求在负载均衡时都打到同一台机器上。以nginx为例，可以配置iphash来实现。
　　但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决用户请求的机器宕机的问题。node。js下的session处理前面的图很清楚了，服务端要实现对cookie和session的存取，实现起来要做的事还是很多的。在npm中，已经有封装好的中间件，比如expresssessionnpm，用法就不贴了。这是它种的cookie：
　　expresssessionnpm主要实现了：封装了对cookie的读写操作，并提供配置项配置字段、加密方式、过期时间等。封装了对session的存取操作，并提供配置项配置session存储方式（内存redis）、存储规则等。给req提供了session属性，控制属性的setget并响应到cookie和session存取上，并给req。session提供了一些方法。应用方案：token
　　session的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套Redis集群。有没有更好的办法？
　　我又想到学校，在没有校园卡技术以前，我们都靠学生证。门卫小哥直接对照我和学生证上的脸，确认学生证有效期、年级等信息，就可以放行了。
　　回过头来想想，一个登录场景，也不必往session存太多东西，那为什么不直接打包到cookie中呢？这样服务端不用存了，每次只要核验cookie带的证件有效性就可以了，也可以携带一些轻量的信息。这种方式通常被叫做token。
　　token的流程是这样的：用户登录，服务端校验账号密码，获得用户信息把用户信息、token配置编码成token，通过cookieset到浏览器此后用户请求业务接口，通过cookie携带token接口校验token有效性，进行正常业务接口处理
　　客户端token的存储方式在前面cookie说过，cookie并不是客户端存储凭证的唯一方式。token因为它的无状态性，有效期、使用限制都包在token内容里，对cookie的管理能力依赖较小，客户端存起来就显得更自由。但web应用的主流方式仍是放在cookie里，毕竟少操心。token的过期那我们如何控制token的有效期呢？很简单，把过期时间和数据一起塞进去，验证时判断就好。token的编码
　　编码的方式丰俭由人。base64比如node端的cookiesessionnpm库
　　不要纠结名字，其实是个token库，但保持了和expresssessionnpm高度一致的用法，把要存的数据挂在session上
　　默认配置下，当我给他一个userid，他会存成这样：
　　这里的eyJ1c2VyaWQiOiJhIn0，就是｛userid：abb｝的base64而已。防篡改
　　那问题来了，如果用户cdd拿｛userid：abb｝转了个base64，再手动修改了自己的token为eyJ1c2VyaWQiOiJhIn0，是不是就能直接访问到abb的数据了？
　　是的。所以看情况，如果token涉及到敏感权限，就要想办法避免token被篡改。解决方案就是给token加签名，来识别token是否被篡改过。例如在cookiesessionnpm库中，增加两项配置：secret：iAmSecret，signed：true，
　　这样会多种一个。sigcookie，里面的值就是｛userid：abb｝和iAmSecret通过加密算法计算出来的，常见的比如HMACSHA256类（System。Security。Cryptography）MicrosoftDocs。
　　好了，现在cdd虽然能伪造出eyJ1c2VyaWQiOiJhIn0，但伪造不出sig的内容，因为他不知道secret。JWT但上面的做法额外增加了cookie数量，数据本身也没有规范的格式，所以JSONWebTokenIntroductionjwt。io横空出世了。
　　JSONWebToken（JWT）是一个开放标准，定义了一种传递JSON信息的方式。这些信息通过数字签名确保可信。
　　它是一种成熟的token字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个JWTtoken长什么样：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。eyJ1c2VyaWQiOiJhIiwiaWF0IjoxNTUxOTUxOTk4fQ。2jf3kluKWRkwjOP6uQRJFqMlwSABcgqqcJofFH5XCo
　　这串东西是怎么生成的呢？看图：
　　类型、加密算法的选项，以及JWT标准数据字段，可以参考RFC7519JSONWebToken（JWT）node上同样有相关的库实现：expressjwtnpmkoajwtnpmrefreshtoken
　　token，作为权限守护者，最重要的就是安全。业务接口用来鉴权的token，我们称之为accesstoken。越是权限敏感的业务，我们越希望accesstoken有效期足够短，以避免被盗用。但过短的有效期会造成accesstoken经常过期，过期后怎么办呢？一种办法是，让用户重新登录获取新token，显然不够友好，要知道有的accesstoken过期时间可能只有几分钟。另外一种办法是，再来一个token，一个专门生成accesstoken的token，我们称为refreshtoken。accesstoken用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活refreshtoken用来获取accesstoken，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的session一样处理
　　有了refreshtoken后，几种情况的请求流程变成这样：
　　如果refreshtoken也过期了，就只能重新登录了。session和token
　　session和token都是边界很模糊的概念，就像前面说的，refreshtoken也可能以session的形式组织维护。狭义上，我们通常认为session是种在cookie上、数据存在服务端的认证方案，token是客户端存哪都行、数据存在token里的认证方案。对session和token的对比本质上是客户端存cookie存别地儿、服务端存数据不存数据的对比。客户端存cookie存别地儿存cookie固然方便不操心，但问题也很明显：在浏览器端，可以用cookie（实际上token就常用cookie），但出了浏览器端，没有cookie怎么办？cookie是浏览器在域下自动携带的，这就容易引发CSRF攻击（前端安全系列（二）：如何防止CSRF攻击？美团技术团队）
　　存别的地方，可以解决没有cookie的场景；通过参数等方式手动带，可以避免CSRF攻击。服务端存数据不存数据存数据：请求只需携带id，可以大幅缩短认证字符串长度，减小请求体积不存数据：不需要服务端整套的解决方案和分布式处理，降低硬件成本；避免查库带来的验证延迟单点登录
　　前面我们已经知道了，在同域下的客户端服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要一次登录，全线通用的能力，叫做单点登录。虚假的单点登录（主域名相同）
　　简单的，如果业务系统都在同一主域名下，比如wenku。baidu。comtieba。baidu。com，就好办了。可以直接把cookiedomain设置为主域名baidu。com，百度也就是这么干的。
　　真实的单点登录（主域名不同）
　　比如滴滴这么潮的公司，同时拥有didichuxing。comxiaojukeji。comdidiglobal。com等域名，种cookie是完全绕不开的。这要能实现一次登录，全线通用，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为SSO。一次从A系统引发登录，到B系统不用登录的完整流程
　　用户进入A系统，没有登录凭证（ticket），A系统给他跳到SSOSSO没登录过，也就没有sso系统下没有凭证（注意这个和前面Aticket是两回事），输入账号密码登录SSO账号密码验证成功，通过接口返回做两件事：一是种下sso系统下凭证（记录用户在SSO登录状态）；二是下发一个ticket客户端拿到ticket，保存起来，带着请求系统A接口系统A校验ticket，成功后正常处理业务请求此时用户第一次进入系统B，没有登录凭证（ticket），B系统给他跳到SSOSSO登录过，系统下有凭证，不用再次登录，只需要下发ticket客户端拿到ticket，保存起来，带着请求系统B接口
　　完整版本：考虑浏览器的场景上面的过程看起来没问题，实际上很多APP等端上这样就够了。但在浏览器下不见得好用。看这里：
　　对浏览器来说，SSO域下返回的数据要怎么存，才能在访问A的时候带上？浏览器对跨域有严格限制，cookie、localStorage等方式都是有域限制的。这就需要也只能由A提供A域下存储凭证的能力。一般我们是这么做的：
　　图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。在SSO域下，SSO不是通过接口把ticket直接返回，而是通过一个带code的URL重定向到系统A的接口上，这个接口通常在A向SSO注册时约定浏览器被重定向到A域下，带着code访问了A的callback接口，callback接口通过code换取ticket这个code不同于ticket，code是一次性的，暴露在URL中，只为了传一下换ticket，换完就失效。callback接口拿到ticket后，在自己的域下setcookie成功在后续请求中，只需要把cookie中的ticket解析出来，去SSO验证就好访问B系统也是一样总结HTTP是无状态的，为了维持前后请求，需要前端存储标记cookie是一种完善的标记方式，通过HTTP头或js操作，有对应的安全策略，是大多数状态管理方案的基石session是一种状态管理方案，前端通过cookie存储id，后端存储数据，但后端要处理分布式问题token是另一种状态管理方案，相比于session不需要后端存储，数据全部存在前端，解放后端，释放灵活性token的编码技术，通常基于base64，或增加加密算法防篡改，jwt是一种成熟的编码方案在复杂系统中，token可通过servicetoken、refreshtoken的分权，同时满足安全性和用户体验session和token的对比就是用不用cookie和后端存不存的对比单点登录要求不同域下的系统一次登录，全线通用，通常由独立的SSO系统记录登录状态、下发ticket，各业务系统配合存储和认证ticket
　　谢谢大家哦
　　如果觉得这篇文章还不错，来个【分享、点赞、在看】三连吧，让更多的人也看到来源：HenryLulu几木
　　链接：juejin。cnpost6898630134530752520