海宁建设局网站,微商怎么做网站,wordpress旅游社区,网站开发需要什么资料一、SessionCookie登录
传统的sessioncookie登录是一种有状态 的登录
1、传统的sessioncookie 流程 浏览器登录发送账号和密码#xff0c;服务端查找数据库验证用户验证成功后#xff0c;服务端把用户状态#xff08;登录状态#xff0c;角色#xff0c;权限等信息…一、SessionCookie登录
传统的sessioncookie登录是一种有状态 的登录
1、传统的sessioncookie 流程 浏览器登录发送账号和密码服务端查找数据库验证用户验证成功后服务端把用户状态登录状态角色权限等信息存为Session生成一个SessionId通过接口将SessionId返回到浏览器表示用户验证成功登录完成。浏览器将SessionId存在cookie中此后浏览器再请求业务接口服务端发送http请求并且会将cookie一起发送到服务端服务端从cookie中拿到SessionID如果没有SessionID就是第一次登录和session中的数据进行比对比对成功并且有访问权限就允许访问否则就访问失败。
2、cookie
cookie是前端存储的一种但相比于localStorage 等其他方式借助HTTP头、浏览器能力cookie可以做到前端无感知。一般过程是这样的
在提供标记的接口通过HTTP返回头的Set-Cookie字段直接“种”到浏览器上浏览器发起请求时会自动把cookie通过HTTP请求头的cookie字段带给接口
cookie是维持HTTP请求状态的基石是最便捷的维持HTTP请求状态 的方式。
3、Session
Session的具体内容都是存储在服务端只是给客户端一个SessionId存在cookie。Session的存储方式有
Redis推荐用Redis存储以key-value形式存刚好符号sessionId-sessionData的场景访问更快内存直接放到变量里一旦服务重启就没有了数据库存在磁盘里性能不高
Session的分布式问题
通常服务端是集群而用户请求会走负载均衡不一定就能请求到登录时的服务端。一旦用户后续接口请求到的机器和之前登录请求的机器不一致或者登录请求的机器宕机了session就没用了
解决方式
把所有用户的session集中存储我们可以用独立的Redis或者普通数据库推荐是Redis或者消息队列 这就是分布式session
当用户第一次访问应用时应用会为用户生成一个唯一的会话标识符session ID并将该标识符返回给用户当用户发送后续请求时会将会话标识符作为请求的一部分发送回服务器。服务器可以利用该会话标识符来识别用户并获取保存在分布式存储中的会话状态 。分布式存储可以是数据库、缓存、消息队列等它们可以在多个应用服务器之间共享数据。当一个应用服务器接收到请求时它可以根据会话标识符查询分布式存储获取用户的会话状态并进行相应的处理。
4、缺点 随着技术的发展分布式web应用的普及通过session管理用户登录状态成本越来越高 session存储在服务端如果用户很多的话服务端保存大量数据增加服务端的压力 服务从单服务到多服务会面临session共享问题要考虑分布式的问题
二、tokencookie 流程
用户登录用户使用用户名和密码发送登录请求到服务器。服务器验证用户的身份信息并验证成功后生成一个唯一的令牌token。令牌生成服务器生成一个包含用户身份验证信息的令牌并将其返回给客户端 。令牌通常是一个加密的字符串其中包含了用户的身份信息、授权信息和有效期 等。令牌存储服务器将生成的令牌存储在服务器端的缓存或数据库 中以便后续验证和访问控制。令牌传递客户端将接收到的令牌存储在本地通常可以使用Cookie或LocalStorage 等技术来存储。请求验证当客户端发送后续请求到服务器时需要将令牌放在请求中的请求头、参数或Cookie中以便服务器进行验证。令牌验证服务器接收到请求后从请求中获取令牌并与服务器存储的令牌进行比较和验证 。验证包括检查令牌的有效性、合法性以及是否过期等。授权访问如果令牌验证通过服务器会根据令牌中的身份信息进行授权验证以确定用户是否有权限进行请求的操作。响应返回服务器根据验证和授权结果返回相应的响应结果给客户端。
优点
可以隐藏真实数据避免明文传输。ie里存的是一个32位的uuid
使用于分布式/微服务解决session共享问题
安全系数高
缺点
存在redis必须依赖服务器会占用服务器的资源
效率较低不过比起传统的sessioncookie好多了
三、JWT实现无状态登录
JWT全程是 JSON WEB TOKENJWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息 也可以增加一些额外的其他业务逻辑所必须的声明信息该token也可以直接被用于认证也可被加密
JWT的组成部分
Header头记录令牌类型、签名算法等Payload有效载荷携带一些用户信息Signature签名防止token被篡权保证安全性。这个签名由头部和有效负载的Base64编码字符串以及使用指定算法加密的秘密密钥组成。
使用JWT登录过程 用户提供用户名和密码进行认证。在认证成功后服务器会生成一个JWT在其中包含用户的一些身份信息并使用秘钥 对其进行签名。 服务器将生成的JWT返回给客户端。客户端通常将JWT存储在本地例如在 localStorage 或者cookie中。 客户端在后续的请求中在请求的头部或者其他合适的位置添加JWT作为身份验证凭证。一般使用Authorization头部 服务器在接收到请求时会验证JWT的有效性以及签名。 在进行签名验证时需要使用之前生成JWT时使用的相同的秘钥 否则将无法正确验证签名导致JWT无效 服务端会检查JWT的各种声明和标准字段如签发人issuer、受众人audience、过期时间expiration time等。根据业务需求服务端可以自行定义额外的声明字段。 如果验证通过表示用户是合法的并且可以使用JWT中包含的信息来进行身份验证和授权。
优点
实现无状态的认证机制服务端不需要存储用户的会话信息只需要校验JWT的合法性即可减轻服务端的压力JWT可以带有自定义的信息使得身份验证非常灵活 可自行定制所需的信息JWT被签名后任何篡改都可以被检测到提供了一定的安全性
缺点
建议不要放敏感数据因为JWT是一种基于编码的token使用base64进行编码而不是加密 虽然JWT的签名可以确保token在传输过程中没有被篡改但是无法保证token的内容不被解码和泄露 敏感数据应该存储在安全的服务器端并仅在需要时通过安全的传输方式在服务端进行处理JWT一旦生成无法吊销令牌只能等待令牌自身过期 。所以需要注意的是JWT的有效期应该设置合理限制JWT的使用时间并在过期后重新认证获取新的令牌令牌长度与其包含用户信息多少正相关传输开销较大
JWT如何保证不被篡改
JWT使用签名 来防止被篡改。在生成JWT时使用一个密钥对JWT的头部和有效负载进行签名。当服务端接收到JWT时首先会对JWT进行解码然后使用相同的密钥对解码后的JWT的头部和有效负载重新进行签名 。然后将重新计算的签名与原始JWT中的签名进行比较。如果重新计算的签名与原始JWT中的签名不一致说明JWT已被篡改验证失败 。
通过使用签名来验证JWT的完整性可以有效地防止JWT被篡改。任何对JWT进行篡改的尝试都会被服务端检测到。同时由于JWT中包含了签名算法和秘密密钥攻击者无法伪造一个合法的签名。需要注意的是服务端验证JWT时必须使用与生成JWT时相同的秘密密钥来进行签名验证否则验证会失败。同时为了增强安全性应该选择足够强大的签名算法和秘密密钥以防止密钥泄露和暴力破解的攻击 。
四、单点登录
当业务线越来也多就会有更多业务系统分散到不同域名下不同的系统就需要一次登录全线通用的能力这就是单点登录。
1、“虚假的单点登录”使主域名相同
我们知道cookie是有限制的这个限制就是cookie的域通常对应网站的域名浏览器发送http请求时会自动携带与该域匹配的cookie而不是所有cookie 。
因此我们可以将web应用群中所有子系统的域名统一在一个顶级域名下采用同域名共享cookie的方式。这样也能实现一次登录全线通用。
但是共享cookie的方式存在众多局限 所有的子系统域名要统一 应用群各系统使用的技术要相同并且共享cookie的方式是无法实现跨语言技术平台登录的
2、“真实”的单点登录
当主域名不同时实现一次登录全线使用这才是真正的单点登录。在这种场景下我们需要独立的认证服务通常被称为 SSOSingle Sign On 当用户访问A系统没有登录凭证ticketA系统让它重定向到SSO用户没有在SSO登录SSO系统下就没有凭证这个和ticket不是一个东西用户输入账号和密码进行登录SSO校验账号密码成功通过接口返回做两件事一在SSO系统种下凭证记录用户的登录状态二是给用户下发一个ticket客户端拿到tikcet保存起来带着ticket再次访问系统ASSO校验ticket成功后正常处理业务请求此时用户第一次访问系统B没有ticketB系统让它重定向到SSO因为用户在SSO登录过SSO有凭证不用再次登录只需要下发ticket客户端拿到ticket保存起来带着ticket请求系统BSSO校验ticket成功后正常处理业务请求
只有SSO有登录账号密码的功能其他系统都没有。用户在SSO登录后SSO就会存储一个用户的登录凭证这个是全局会话然后根据重定向过来的地址颁发要访问的系统的ticket。比如用户是从A系统重定向过来的就颁发一个A系统的ticket局部会话客户端带着这个ticket就可以访问A系统了当用户要访问B系统时B系统将它重定向到SSO已经登录了所以SSO直接颁发可以访问B系统的ticket客户端带着这个ticket就可以访问B系统了。这样就实现了一处登录全线使用
但是这样有一个问题SSO放回的ticket浏览器要如何存因为有很多个域名下如何才能在下次访问A系统时带上这个ticket因为浏览器对跨域有严格限制所以我们需要在A域下保存这个A的ticket
在 SSO 域下SSO 不是通过接口把 ticket 直接返回而是通过一个带 code 的 URL 重定向到系统 A 的接口上 这个接口通常在 A 向 SSO 注册时约定浏览器被重定向到 A 域下带着 code 访问了 A 的 callback 接口callback 接口通过 code去SSO中 换取 ticket这个 code 不同于 ticketcode 是一次性的暴露在 URL 中只为了传一下换 ticket换完就失效callback 接口拿到 ticket 后在**自己的域下 set cookie ** 成功在后续请求中浏览器只需要把 cookie 中的 ticket 解析出来然后去SSO 中 验证就可以了
五、总结
1、HTTP 是无状态的为了维持前后请求需要前端存储标记-----cookie
2、cookie 是一种完善的标记方式通过 HTTP 头或 js 操作有对应的安全策略是大多数状态管理方案的基石
3、session 是一种状态管理方案前端通过 cookie 存储 id后端存储数据但后端要处理分布式问题
4、token 是另一种状态管理方案token 的编码技术通常基于 base64或增加加密算法防篡改jwt 是一种成熟的编码方案并且JWT实现了无状态登录相较于传统的有状态登录更加灵活解放服务端
5、session 和 token 的对比就是「用不用cookie」和「后端存不存」的对比
6、单点登录要求不同域下的系统「一次登录全线通用」通常由独立的 SSO 系统记录登录状态、下发 ticket各业务系统配合存储和认证 ticket
