身份验证

网友投稿 794 2022-05-29

传统身份验证的方法

HTTP 是一种没有状态的协议,也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下回这个客户端再发送请求时候,还得再验证一下。

解决的方法就是,当用户请求登录的时候,如果没有问题,我们在服务端生成一条记录,这个记录里可以说明一下登录的用户是谁,然后把这条记录的 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 的具体内容,这些内容里面有一些是标准字段,你也可以添加其它需要的内容。下面是标准字段:

iss:Issuer,发行者

sub:Subject,主题

aud:Audience,观众

exp:Expiration time,过期时间

nbf:Not before

iat:Issued at,发行时间

jti:JWT 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里面的对应关系来解决这个问题。

API 数据库

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:表空间及分区表的概念
下一篇:USB通信基础知识
相关文章