网站如何做移动规则适配,北京住房与城乡建设部网站,南宁网站建设推广优化,wordpress国人cms标题 一、Cookie二、Session三、Token四、JWTSSO#xff08;单点登录#xff09; 五、OAuth2如何设计权限系统区别总结 Cookie、Token、Session 和 JWT 都是在 Web 开发中常用的身份验证和授权技术#xff0c;它们各有优缺点#xff0c;适用于不同的场景。
Cookie 简单易用… 标题 一、Cookie二、Session三、Token四、JWTSSO单点登录 五、OAuth2如何设计权限系统区别总结 Cookie、Token、Session 和 JWT 都是在 Web 开发中常用的身份验证和授权技术它们各有优缺点适用于不同的场景。
Cookie 简单易用但安全性较低 Session 相对安全但在分布式环境下存在问题 Token 和 JWT 实现了无状态的身份验证具有较好的安全性和可扩展性但需要合理管理有效期和存储敏感信息的风险。
一、Cookie
Cookie 是存储在用户浏览器中的一小段数据。当用户访问一个网站时服务器可以在响应中设置 Cookie浏览器会将其保存下来。在后续的请求中浏览器会自动将 Cookie 发送给服务器服务器可以通过读取 Cookie 来识别用户身份或存储一些特定的用户信息。
优点
简单易用Cookie 是一种被广泛支持的技术大多数浏览器都对其有良好的支持。可以存储少量的用户信息例如用户的登录状态、偏好设置等。
缺点 由于Http请求在Cookie是明文传递的所以存在安全问题(除非是Https基于TLS/SSL进行加密) 安全性较低Cookie 存储在用户的浏览器中容易被篡改或窃取。 容易受到XSS和CSRF攻击。需要在客户端存储可能被用户或恶意软件篡改。 存储容量有限通常只能存储几 KB 的数据。有大小限制通常为4KB。 受浏览器限制一些用户可能会禁用 Cookie这会影响网站的正常功能。 Cookie会被附加在后续每个Http请求中无形中增加了流量 cookie是不可以跨域的每个cookie都会绑定单一的域名无法在别的域名下获取使用一级域名和二级域名之间是允许共享使用的依靠的是domain。
使用场景 适用于需要持久化用户会话的场景如在线购物车或用户偏好设置。 由于cookie存储在浏览器端导致cookie是不够安全的后面就诞生了session。 session是依赖于cookie的session会把key通过cookie传送给浏览器浏览器再次发起请求时会携带session ID
二、Session
Session 是服务器端用于存储用户会话信息的一种机制。当用户登录成功后服务器会创建一个 Session并为其分配一个唯一的 Session ID。这个 Session ID 通常会存储在 Cookie 中或者通过 URL 参数传递给客户端。在后续的请求中客户端会将 Session ID 发送给服务器服务器通过 Session ID 来查找对应的 Session从而获取用户的会话信息。
优点
相对安全Session 信息存储在服务器端不容易被篡改或窃取。可以存储较多的用户信息相比 CookieSession 可以存储更多的数据。
缺点
服务器资源消耗每个用户的 Session 都需要占用服务器的内存资源当用户数量较多时可能 会对服务器性能造成一定的影响。分布式环境下的问题在分布式系统中需要考虑 Session 的同步和共享问题增加了系统的复杂性。因为依赖cookie依然存在安全性问题 session 认证流程
用户第一次请求服务器的时候服务器根据用户提交的相关信息创建对应的 Session
请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
浏览器接收到服务器返回的 SessionID 信息后会将此信息存入到 Cookie 中同时 Cookie 记录此 SessionID 属于哪个域名
当用户第二次访问服务器的时候请求会自动判断此域名下是否存在 Cookie 信息如果存在自动将 Cookie 信息也发送给服务端服务端会从 Cookie 中获取 SessionID再根据 SessionID 查找对应的 Session 信息如果没有找到说明用户没有登录或者登录失效如果找到 Session 证明用户已经登录可执行后面操作。
根据以上流程可知SessionID 是连接 Cookie 和 Session 的一道桥梁大部分系统也是根据此原理来验证用户登录状态。
使用场景 适用于需要存储大量用户数据的Web应用程序如在线游戏或复杂的企业管理系统。 三、Token
Token 是一种基于令牌的身份验证机制。当用户登录成功后服务器会生成一个 Token并将其返回给客户端。客户端在后续的请求中将 Token 包含在请求头或请求参数中发送给服务器服务器通过验证 Token 的有效性来识别用户身份。
优点
无状态Token 本身包含了用户的身份信息服务器不需要存储 Session因此可以轻松地实现水平扩展。(服务端无状态化、可扩展性好)安全性较高Token 可以使用加密算法进行签名确保其不被篡改。跨平台、跨设备Token 可以在不同的平台和设备上使用方便用户在多个设备上访问应用。(支持移动端设备)支持跨程序调用 token 的身份验证流程 客户端使用用户名跟密码请求登录服务端收到请求去验证用户名与密码验证成功后服务端会签发一个 token 并把这个 token 发送给客户端客户端收到 token 以后会把它存储起来比如放在 cookie 里或者 localStorage 里客户端每次向服务端请求资源的时候需要带着服务端签发的 token服务端收到请求然后去验证客户端请求里面带着的 token 如果验证成功就向客户端返回请求的数据
每一次请求都需要携带 token需要把 token 放到 HTTP 的 Header 里基于 token 的用户认证是一种服务端无状态的认证方式服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间从而减轻服务器的压力减少频繁的查询数据库token 完全由应用管理所以它可以避开同源策略
缺点
存储和传输开销Token 通常比 Cookie 或 Session ID 更大会增加网络传输的开销。有效期管理需要合理设置 Token 的有效期过期后需要用户重新登录。
使用场景
适用于RESTful API和单页应用程序SPA其中状态不需要存储在服务器上。 四、JWT
JWT 是一种基于 JSON 的开放标准RFC 7519用于在网络应用环境间传递声明。它由三部分组成头部Header、载荷Payload和签名Signature。头部和载荷部分都是 JSON 对象签名是使用特定的算法对头部和载荷进行签名得到的。
优点
自包含JWT 本身包含了用户的身份信息不需要服务器存储 Session实现了无状态的身份验证。可扩展性强可以在载荷中添加自定义的声明满足不同应用的需求。跨域支持由于 JWT 是基于标准的 JSON 格式可以轻松地在不同的域之间传递。
缺点
一旦签发无法撤销如果 JWT 被泄露在有效期内无法撤销只能等待其过期。存储敏感信息的风险如果在 JWT 的载荷中存储了敏感信息可能会存在安全风险。
使用场景
适用于需要跨域认证的微服务架构或需要在客户端和服务器之间安全传输大量数据的场景。 SSO单点登录 定义 SSO 是一种身份验证机制允许用户使用一组凭据如用户名和密码登录到多个相关但独立的应用程序或系统中。用户只需进行一次身份验证后续访问其他关联应用时无需再次输入凭据。 工作原理 通常有一个中央身份验证服务器CAS - Central Authentication Server。当用户尝试访问应用 A 时应用 A 将用户重定向到 CAS。用户在 CAS 进行登录认证后CAS 会生成一个票据Ticket并将用户重定向回应用 A同时将票据传递给应用 A。应用 A 拿着票据到 CAS 验证验证通过后允许用户访问。当用户再访问应用 B 时应用 B 发现用户未登录同样将用户重定向到 CASCAS 发现用户已经登录过了通过之前在用户浏览器中设置的 Cookie 等机制就直接给应用 B 生成票据应用 B 验证票据后允许用户访问。 应用场景 在企业内部多个相关系统中应用广泛。例如一家公司有内部的办公系统、邮件系统、项目管理系统等使用 SSO 可以让员工只登录一次就能访问这些系统提高工作效率减少用户记忆多个账号密码的负担。 优缺点 优点 1.用户体验好只需一次登录。 2.便于集中管理用户账号和权限企业的 IT 部门可以在中央服务器上统一管理用户的身份和访问权限。 缺点 1.对中央身份验证服务器的依赖度高如果 CAS 出现故障可能会影响所有关联应用的访问。 2.安全性方面一旦中央服务器被攻破可能导致所有相关系统的安全风险。
五、OAuth2
是一个行业标准授权协议主要用来授权第三方应用获取有限的权限它的最终目标是为第三方应用颁发一个有时效性的令牌token使得第三方应用能够通过该令牌获取相关资源比如第三方登录
官方解释
OAuth开放授权是一个开放标准允许用户让第三方应用网站/app访问该用户在另一网站
qq, 微博微信等等上存储的私密的资源如照片视频联系人列表
而无需将用户名和密码提供给第三方应用。4种模式 工作原理 主要涉及以下角色 资源所有者Resource Owner通常是用户拥有要被访问的资源如用户在某个网站上的照片、联系人等。 客户端Client即第三方应用程序想要访问资源所有者的资源。 授权服务器Authorization Server负责对客户端进行授权验证客户端的身份并颁发访问令牌。 资源服务器Resource Server存储资源所有者的资源在接收到客户端的访问请求并验证令牌后提供相应的资源。
典型流程如下 客户端请求资源所有者的授权资源所有者同意后客户端从授权服务器获取授权码Authorization Code。 客户端拿着授权码向授权服务器换取访问令牌Access Token。 客户端使用访问令牌向资源服务器请求资源资源服务器验证令牌后提供资源。
应用场景 在互联网应用中大量使用。例如用户可以使用微信账号登录第三方应用如某新闻客户端第三方应用通过 OAuth 2.0 从微信获取用户的基本信息如头像、昵称等来为用户创建账号而微信不会将用户的密码透露给第三方应用。
优缺点
优点 安全性高不暴露用户的登录凭据给第三方应用保护了用户隐私。 灵活性强可实现不同应用间的资源共享和授权访问适用于开放的互联网环境。缺点 实现相对复杂涉及多个角色和交互流程开发成本较高。 如果配置不当可能会出现安全漏洞例如授权码泄露可能导致非法获取访问令牌。
如何设计权限系统
首先有基本的4张表用户表、角色表、菜单表、资源表 他们之间关系多对多因此需要中间表作为关联 至少的需要 用户角色关系表、角色菜单关系表、菜单资源关系表 最好再来个日记记录表非必须 区别总结
Cookie 和 Session 的区别 安全性Session 比 Cookie 安全Session 是存储在服务器端的Cookie 是存储在客户端的。 存取值的类型不同Cookie 只支持存字符串数据想要设置其他类型的数据需要将其转换成字符串Session 可以存任意数据类型。 有效期不同Cookie 可设置为长时间保持比如我们经常使用的默认登录功能Session 一般失效时间较短客户端关闭默认情况下或者 Session 超时都会失效。 存储大小不同单个 Cookie 保存的数据不能超过 4KSession 可存储数据远高于 Cookie但是当访问量过多会占用过多的服务器资源。
Token 和 Session 的区别 Session 是一种记录服务器和客户端会话状态的机制使服务端有状态化可以记录会话信息。而 Token 是令牌访问资源接口API时所需要的资源凭证。Token 使服务端无状态化不会存储会话信息。 Session 和 Token 并不矛盾作为身份认证 Token 安全性比 Session 好因为每一个请求都有签名还能防止监听以及重放攻击而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话仍然可以增加 Session 来在服务器端保存一些状态。 所谓 Session 认证只是简单的把 User 信息存储到 Session 里因为 SessionID 的不可预测性暂且认为是安全的。而 Token 如果指的是 OAuth Token 或类似的机制的话提供的是 认证 和 授权 认证是针对用户授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上也不可以转到其它用户上。Session 只提供一种简单的认证即只要有此 SessionID 即认为有此 User 的全部权利。是需要严格保密的这个数据应该只保存在站方不应该共享给其它网站或者第三方 App。所以简单来说如果你的用户数据可能需要和第三方共享或者允许第三方调用 API 接口用 Token 。如果永远只是自己的网站自己的 App用什么就无所谓了。 一、存储位置 Session 服务器端存储Session 数据通常存储在服务器端。当用户登录成功后服务器会创建一个 Session 对象并为其分配一个唯一的标识符Session ID。这个 Session ID 会被发送到客户端通常是通过 Cookie 存储在客户端浏览器中。 示例在一个使用 PHP 开发的网站中当用户登录时服务器会在内存或数据库中创建一个 Session 数据结构用于存储用户的登录状态、权限等信息。 Token 客户端存储Token 通常存储在客户端。在用户认证成功后服务器会生成一个 Token 并将其发送给客户端。客户端可以将 Token 存储在本地存储如 Local Storage、Session Storage或 Cookie 中。 示例在一个基于 JavaScript 的单页应用SPA中用户登录后服务器返回的 JWTJSON Web Token会被存储在浏览器的 Local Storage 中供后续的 API 请求使用。 二、数据结构 Session 数据格式多样Session 数据可以是各种格式取决于服务器端的实现。它可以是简单的键值对、复杂的对象或序列化的数据。 示例在一个使用 Node.js 和 Express 框架的应用中Session 数据可能是一个包含用户 ID、用户名、登录时间等属性的 JavaScript 对象。 Token 标准化格式Token 通常有特定的格式如 JWTJSON Web Token是一种流行的 Token 格式它由三部分组成头部Header、载荷Payload和签名Signature。 示例一个 JWT Token 可能如下所示 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c 其中第一部分是头部Base64 编码第二部分是载荷Base64 编码第三部分是签名。 三、安全性 Session 依赖于 Session ID 的保护由于 Session 数据存储在服务器端其安全性主要依赖于对 Session ID 的保护。如果 Session ID 被窃取攻击者可能会获取用户的 Session 数据从而冒充用户身份。 示例如果用户的浏览器存在跨站脚本攻击XSS漏洞攻击者可能获取到存储在 Cookie 中的 Session ID进而劫持用户的 Session。 Token 基于签名机制Token 的安全性依赖于其签名机制。例如JWT Token 使用私钥进行签名在验证时服务器使用公钥来验证签名的有效性。如果 Token 被篡改签名验证将失败。 示例在一个基于微服务架构的系统中各个服务使用公钥验证从客户端传来的 JWT Token 的签名确保 Token 没有被篡改。 四、扩展性 Session 服务器负载问题在分布式系统或高负载场景下Session 的管理会变得复杂。因为 Session 数据存储在服务器端当用户请求在多个服务器之间负载均衡时需要解决 Session 共享的问题如使用分布式缓存如 Redis来存储 Session 数据。 示例在一个大型的电商网站中如果有多台 Web 服务器处理用户请求为了确保用户的 Session 数据在这些服务器之间的一致性需要采用专门的 Session 共享解决方案。 Token 无状态性利于扩展Token 是无状态的服务器不需要存储 Token 的相关数据。每个请求携带 Token服务器只需要验证 Token 的有效性即可。这使得在分布式系统和微服务架构中Token 更易于扩展和处理。 示例在一个由多个微服务组成的系统中每个微服务只需要验证传入请求中的 JWT Token而不需要与其他服务共享用户状态信息便于系统的水平扩展。 五、有效期管理 Session 服务器端控制Session 的有效期通常由服务器端控制。可以设置一个固定的过期时间或者根据用户的活动情况如一段时间内没有操作来决定 Session 是否过期。 示例在一个网站中可以设置 Session 的过期时间为 30 分钟即用户登录后 30 分钟内没有操作Session 就会自动失效。 Token 内置有效期或自定义控制Token 本身可以内置有效期信息。例如JWT Token 的载荷中可以包含一个expexpiration time字段来表示 Token 的过期时间。此外也可以在应用层自定义 Token 的有效期管理机制。 示例一个 JWT Token 的载荷中可能有exp: 1672531200表示这个 Token 在 2023 年 1 月 1 日 00:00:00 过期。
Token 和 JWT 的区别
相同 都是访问资源的令牌 都可以记录用户的信息 都是使服务端无状态化 都是只有验证成功后客户端才能访问服务端上受保护的资源
区别 Token服务端验证客户端发送过来的 Token 时还需要查询数据库获取用户信息然后验证 Token 是否有效。 JWT将 Token 和 Payload 载荷加密后存储于客户端服务端只需要使用密钥解密进行校验校验也是 JWT 自己实现的即可不需要查询或者减少查询数据库因为 JWT 自包含了用户信息和加密的数据 定义 Token令牌是一种用于身份验证和授权的机制。它是一个代表用户身份或权限的字符串。Token 可以由服务器生成并发送给客户端客户端在后续的请求中携带这个 Token 来证明自己的身份或权限。Token 的格式和生成方式可以多种多样没有固定的标准格式。 JWTJSON Web Token是一种特定格式的 Token。它遵循 RFC 7519 标准由三部分组成头部Header、载荷Payload和签名Signature。这三部分用点.分隔并连接成一个字符串。 结构 Token 结构不固定可能只是一个简单的随机字符串比如一个由服务器随机生成的 32 位十六进制字符串如a3b9c4d7e2f8g1h6i9j4k7l2m5n8o3p9。 也可能是具有一定格式但较为简单的字符串例如包含用户 ID 和时间戳的字符串“user123_1672531200”其中user123是用户 ID1672531200是时间戳。 JWT 头部Header是一个 JSON 对象通常包含令牌的类型如typ:“JWT”和所使用的签名算法如alg:“HS256”经过 Base64 编码后得到第一部分。 载荷Payload也是一个 JSON 对象包含了一些声明Claims如用户身份信息sub字段表示主题即用户 ID、过期时间exp字段、签发时间iat字段等经过 Base64 编码后得到第二部分。 签名Signature是对头部和载荷使用指定的签名算法和密钥进行签名得到的结果用于验证令牌的真实性和完整性是第三部分。例如一个 JWT 可能看起来像eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c。 生成与验证 Token 生成方式较为灵活。例如服务器可以使用随机数生成器生成一个随机字符串作为 Token或者基于用户的某些信息如用户名和密码的哈希值通过某种算法生成 Token。 验证时服务器通常需要在数据库或缓存中存储与 Token 相关的信息。例如当客户端携带 Token 请求时服务器要查找数据库中存储的对应 Token 记录来验证其有效性。 JWT 生成需要按照标准的流程。首先构建头部和载荷的 JSON 对象然后进行 Base64 编码最后使用签名算法和密钥生成签名。 验证时服务器接收 JWT先将其拆分为头部、载荷和签名三部分。对头部和载荷重新计算签名并与接收到的签名进行比较如果一致且载荷中的声明如过期时间有效则认为 JWT 有效无需查询数据库无状态性除非有额外的数据需求如查询用户权限的详细信息。 应用场景 Token 适用于简单的身份验证场景尤其是在小型应用或对安全性要求不是极高的场景中。例如一个公司内部的简单考勤系统可能只使用简单的 Token 来识别员工身份Token 可能只是基于员工工号生成的一个简单字符串。 JWT 广泛应用于分布式系统、微服务架构和跨域身份验证等场景。例如在一个由多个微服务组成的电商系统中用户登录后认证服务生成 JWT 并发送给客户端客户端在访问订单服务、商品服务等其他微服务时携带 JWT 进行身份验证各个微服务可以独立地验证 JWT 的有效性方便快捷且安全。 总的来说JWT 是一种标准化、结构化的 Token具有安全性高、无状态等优点适用于复杂的网络架构而 Token 是一个更宽泛的概念其实现方式更加灵活多样。
SSO 跟OAuth 2.0区别
目的 SSO 主要解决用户在多个相关应用中的重复登录问题侧重于身份验证的统一。 OAuth 2.0 侧重于授权即让第三方应用在用户授权的前提下获取特定的资源不涉及用户在第三方应用中的身份验证第三方应用可能通过其他方式验证用户身份但 OAuth 2.0 本身不处理。涉及角色 SSO 通常涉及用户和中央身份验证服务器以及多个应用程序。 OAuth 2.0 涉及资源所有者、客户端、授权服务器和资源服务器等多个角色。安全机制 SSO 依赖于中央服务器对用户身份的验证和票据的安全传递。 OAuth 2.0 通过授权码、访问令牌等机制来保障资源访问的安全性重点在授权流程的安全。应用场景 SSO 适用于企业内部或相互关联紧密的系统之间。 OAuth 2.0 适用于开放的互联网环境用于第三方应用获取用户资源的授权。
