个人网站建设的国外文献综述,新乡网站建设服务,自己公司设计一个网站,蜜芽免费网站域名传统身份验证的方法
HTTP 是一种没有状态的协议#xff0c;也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端#xff0c;客户端使用用户名还有密码通过了身份验证#xff0c;不过下回这个客户端再发送请求时候#xff0c;还得再验证一下。 解决的方法就是也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端客户端使用用户名还有密码通过了身份验证不过下回这个客户端再发送请求时候还得再验证一下。 解决的方法就是当用户请求登录的时候如果没有问题我们在服务端生成一条记录这个记录里可以说明一下登录的用户是谁然后把这条记录的 ID 号发送给客户端客户端收到以后把这个 ID 号存储在 Cookie 里下次这个用户再向服务端发送请求的时候可以带着这个 Cookie 这样服务端会验证一个这个 Cookie 里的信息看看能不能在服务端这里找到对应的记录如果可以说明用户已经通过了身份验证就把用户请求的数据返回给客户端。 上面说的就是 Session我们需要在服务端存储为登录的用户生成的 Session 这些 Session 可能会存储在内存磁盘或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。
前端退出的话就清cookie。后端强制前端重新认证的话就清或者修改session。 如果是分布式部署需要做多机共享session机制实现方法可将session存储到数据库中或者redis中
基于 cookie 的机制很容易被 CSRF
存储
session、cookie、sessionStorage、localstorage的区别
session: 主要存放在服务器端相对安全
cookie: 可设置有效时间默认是关闭浏览器后失效主要存放在客户端并且不是很安全可存储大小约为4kb
sessionStorage: 仅在当前会话下有效关闭页面或浏览器后被清除
localstorage: 除非被清除否则永久保存
基于 Token 的身份验证方法
使用基于 Token 的身份验证方法在服务端不需要存储用户的登录记录。大概的流程是这样的 客户端使用用户名跟密码请求登录服务端收到请求去验证用户名与密码验证成功后服务端会签发一个 Token再把这个 Token 发送给客户端客户端收到 Token 以后可以把它存储起来比如放在 Cookie 里或者 Local Storage 里客户端每次向服务端请求资源的时候需要带着服务端签发的 Token放入HTTP Header中的Authorization位服务端收到请求然后去验证客户端请求里面带着的 Token如果验证成功就向客户端返回请求的数据
JWT读作jot 表示JSON Web Tokens 。JWT 标准的 Token 有三个部分
header
payload
signature 中间用点分隔开并且都会使用 Base64 编码所以真正的 Token 看起来像这样
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc 标准
Header
header 部分主要是两部分内容一个是 Token 的类型另一个是使用的算法比如下面类型就是 JWT使用的算法是 HS256。
{ typ: JWT, alg: HS256
}
Payload有效载荷
Payload 里面是 Token 的具体内容这些内容里面有一些是标准字段你也可以添加其它需要的内容。下面是标准字段
issIssuer发行者
subSubject主题
audAudience观众
expExpiration time过期时间
nbfNot before
iatIssued at发行时间
jtiJWT ID
Signature
Signature 部分其实就是对我们前面的 Header 和 Payload 部分进行签名保证 Token 在传输的过程中没有被篡改或者损坏签名的算法也很简单但是为了加密所以除了 Header 和 Payload 之外还多了一个密钥字段完整算法为 Signature HMACSHA256( base64UrlEncode(header) . base64UrlEncode(payload), secret)
这部分内容有三个部分先是用 Base64 编码的 header.payload 再用加密算法加密一下加密的时候要放进去一个 Secret密钥这个密钥被存储在服务端。 使用注意
payload 中不要存放敏感信息因为可以被很容易地获取到Token 在服务器没有存储只能通过设置过期时间来让 Token 失效也就是没有办法让 Token 主动失效就没有办法做单点登录可以考虑服务器进行存储保护好secret私钥该私钥非常重要。如果可以请使用HTTPS协议不是务必使用HTTPS!
比较
可扩展性
随着应用程序的扩大和用户数量的增加你必将开始水平或垂直扩展。session数据通过文件或数据库存储在服务器的内存中。在水平扩展方案中你必须开始复制服务器数据你必须创建一个独立的中央session存储系统以便所有应用程序服务器都可以访问。否则由于session存储的缺陷你将无法扩展应用程序。解决这个挑战的另一种方法是使用 sticky session。你还可以将session存储在磁盘上使你的应用程序在云环境中轻松扩展。这类解决方法在现代大型应用中并没有真正发挥作用。建立和维护这种分布式系统涉及到深层次的技术知识并随之产生更高的财务成本。在这种情况下使用JWT是无缝的;由于基于token的身份验证是无状态的所以不需要在session中存储用户信息。我们的应用程序可以轻松扩展因为我们可以使用token从不同的服务器访问资源而不用担心用户是否真的登录到某台服务器上。你也可以节省成本因为你不需要专门的服务器来存储session。为什么因为没有session
注意如果你正在构建一个小型应用程序这个程序完全不需要在多台服务器上扩展并且不需要RESTful API的那么session机制是很棒的。 如果你使用专用服务器运行像Redis那样的工具来存储session那么session也可能会为你完美地运作
安全性
JWT签名旨在防止在客户端被篡改但也可以对其进行加密以确保token携带的claim 非常安全。JWT主要是直接存储在web存储本地/session存储或cookies中。 JavaScript可以访问同一个域上的Web存储。这意味着你的JWT可能容易受到XSS跨站脚本攻击。恶意JavaScript嵌入在页面上以读取和破坏Web存储的内容。事实上很多人主张由于XSS攻击一些非常敏感的数据不应该存放在Web存储中。一个非常典型的例子是确保你的JWT不将过于敏感/可信的数据进行编码例如用户的社会安全号码。
最初我提到JWT可以存储在cookie中。事实上JWT在许多情况下被存储为cookie并且cookies很容易受到CSRF跨站请求伪造攻击。预防CSRF攻击的许多方法之一是确保你的cookie只能由你的域访问。作为开发人员不管是否使用JWT确保必要的CSRF保护措施到位以避免这些攻击。
现在JWT和session ID也会暴露于未经防范的重放攻击。建立适合系统的重放防范技术完全取决于开发者。解决这个问题的一个方法是确保JWT具有短期过期时间。虽然这种技术并不能完全解决问题。然而解决这个挑战的其他替代方案是将JWT发布到特定的IP地址并使用浏览器指纹。
注意使用HTTPS / SSL确保你的Cookie和JWT在客户端和服务器传输期间默认加密。这有助于避免中间人攻击
RESTful API服务
现代应用程序的常见模式是从RESTful API查询使用JSON数据。目前大多数应用程序都有RESTful API供其他开发人员或应用程序使用。由API提供的数据具有几个明显的优点其中之一就是这些数据可以被多个应用程序使用。在这种情况下传统的使用session和Cookie的方法在用户认证方面效果不佳因为它们将状态引入到应用程序中。
RESTful API的原则之一是它应该是无状态的这意味着当发出请求时总会返回带有参数的响应不会产生附加影响。用户的认证状态引入这种附加影响这破坏了这一原则。保持API无状态不产生附加影响意味着维护和调试变得更加容易。
另一个挑战是由一个服务器提供API而实际应用程序从另一个服务器调用它的模式是很常见的。为了实现这一点我们需要启用跨域资源共享CORS。Cookie只能用于其发起的域相对于应用程序对不同域的API来说帮助不大。在这种情况下使用JWT进行身份验证可以确保RESTful API是无状态的你也不用担心API或应用程序由谁提供服务。
性能
当从客户端向服务器发出请求时如果大量数据在JWT内进行编码则每个HTTP请求都会产生大量的开销。编码时JWT的大小将是SESSION ID标识符的几倍从而在每个HTTP请求中JWT比SESSION ID增加更多的开销。 实效性
JWT是一种无状态身份验证机制因为用户状态永远不会保存在服务器内存中。 由于JWT是独立的所有必要的信息都在那里所以减少了多次查询数据库的需求。 此外无状态JWT的实效性相比session太差只有等到过期才可销毁而session则可手动销毁。
例如有个这种场景如果JWT中存储有权限相关信息比如当前角色为 admin但是由于JWT所有者滥用自身权利高级管理员将权利滥用者的角色降为 user。但是由于 JWT 无法实时刷新必需要等到 JWT 过期强制重新登录时高级管理员的设置才能生效。
或者是用户发现账号被异地登录然后修改密码此时token还未过期异地的账号一样可以进行操作包括修改密码。
但这种场景也不是没有办法解决解决办法就是将JWT生成的token存入到redis或者数据库中当用户登出或作出其他想要让token失效的举动可通过删除token在数据库或者redis里面的对应关系来解决这个问题。
