鉴权与身份认证

这篇具有很好参考价值的文章主要介绍了鉴权与身份认证。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

鉴权和身份认证

​ 所谓鉴权就是身份认证,就是验证您是否有权限从服务器访问或操作相关数据。通俗的讲就是一个门禁,您想要进入室内,必须通过门禁验证身份,这就是鉴权,如打开一个网站必须要输入用户名和密码才可以登录进入,这种就是鉴权,还有一些业务需要登录以后才可以进行,因为需要token值,则就可以把token添加到鉴权中,这种也是鉴权。

常用的鉴权方式

  • Basic 认证:户籍部门已给你签发了一张身份证。你每次去办事,都要带上身份证证,后台要拿你的身份证去系统上查一下。
  • Session 认证:户籍部门已给你签发了一张身份证,但只告诉你身份证号码。你每次去办事,只要报出你的身份证号码,后台要查一个即否有效。
  • Token 认证:户籍部门已给你签发了一张有防伪功能的身份证。你每次去办事,只要出示这张卡片,它就知道你一定是自己人。

1、Basic

HTTP Basic Authentication

在这种认证方法下,用户每次发送请求时,请求头中都必须携带能通过认证的身份信息。

其交互过程如下:

  1. 开始时,客户端发送未携带身份信息的请求。

  2. 服务端返回 401 Unauthorized 状态,并在返回头中说明要用 Basic 方法进行认证:WWW-Authenticate: Basic

  3. 客户端重新发送请求,并将身份信息包含在请求头中: Authorization: Basic aHk6bXlwYXNzd29yZA==

  4. 服务端验证请求头中的身份信息,并相应返回 200 OK 或 403 Forbidden 状态。

  5. 之后,客户端每次发送请求都在请求头中携带该身份信息

其中传送的身份信息是 <username>:<password> 经 base64 编码后的字串。如本例中的 aHk6bXlwYXNzd29yZA==, 经 base64 解码后为 hy:mypassword

这种认证方法的优点是简单,容易理解。

缺点有:

  • 不安全:认证身份信息用明文传送,因此需结合 https 使用。
  • 效率低:服务端处理请求时,每次都需要验证身份信息,如用户名和密码。

2、session

这种认证方法结合了 Session 和 Cookie。服务端将本次会话信息以 Session 对象的形式保存在服务端的内存、数据库或文件系统中,并将对应的 Session 对象 ID 值 SessionID 以 Cookie 形式返回给客户端,SessionID 保存在客户端的 Cookie 中。

这是一种有状态的认证方法:服务端保存 Session 对象,客户端以 Cookie 形式保存 SessionID。

其交互过程如下:

  1. 客户端在登录页面输入身份信息,如用户名/密码。
  2. 服务端验证身份信息,通过后生成一个 Session 对象,保存到服务端,并将 SessionID 值以 Cookie 形式返回给客户端。
  3. 客户端将接收到的 SessionID 保存到 Cookie 中,并且之后每次请求都在请求头中携带 SessionID Cookie。
  4. 服务端从请求的 Cookie 中获取 SessionID,并查询其对应的 Session 对象,从而获得身份信息。
  5. 客户端退出本次会话后,客户端删除 SessionID 的 Cookie,服务端删除 Session 对象。
  6. 如果客户端之后要重新登录,需重新生成 Session 对象和 SessionID。

优点:

  • 较安全:客户端每次请求时无需发送身份信息,只需发送 SessionID。
  • 较高效:服务端无需每次处理请求时都要验证身份信息,只需通过 SessionID 查询 Session 对象。

缺点:

  • 扩展性差,Session 对象保存在服务端,如果是保存在多个服务器上,有一致性问题,如果保存在单个服务器上,无法适应用户增长。
  • 基于 Cookie 的 SessionID 不能跨域共享,同一用户的多个客户端(如浏览器客户端和 APP)不能共享 SessionId。
  • 基于 Cookie 的 SessionID 易被截获生成 CSRF 攻击。

3、Token

Token验证(包括JWT,SSO)

这是一种 SPA 应用(单页Web应用single page web application)和 APP 经常使用的认证方法。它是一种无状态的认证方法。

客户端首先将用户信息发送给服务端,服务端根据用户信息+私钥生成一个唯一的 Token 并返回给客户端。Token 只保存在客户端,之后客户端的每个请求头中都携带 Token,而服务端只通过运算(无需查询)来验证用户。

  1. 客户端使用用户名和密码请求登录
  2. 服务端收到请求,验证用户名和密码
  3. 验证成功后,服务端会签发一个token,再把这个token返回给客户端
  4. 客户端收到token后可以把它存储起来,比如放到cookie中
  5. 客户端每次向服务端请求资源时需要携带服务端签发的token,可以在cookie或者header中携带
  6. 服务端收到请求,然后去验证客户端请求里面带着的token,如果验证成功,就向客户端返回请求数据

优点:

  • Token 只保存在客户端,因此不影响服务端扩展性。
  • 为用户生成的 Token 可以在多个客户端共用。
  • 支持跨域访问:cookie是无法跨域的,而token由于没有用到cookie(前提是将token放到请求头中),所以跨域后不会存在信息丢失问题
  • 无状态:token机制在服务端不需要存储session信息,因为token自身包含了所有登录用户的信息,所以可以减轻服务端压力
  • 更适用CDN:可以通过内容分发网络请求服务端的所有资料
  • 更适用于移动端:当客户端是非浏览器平台时,cookie是不被支持的,此时采用token认证方式会简单很多
  • 无需考虑CSRF:由于不再依赖cookie,所以采用token认证方式不会发生CSRF,所以也就无需考虑CSRF的防御

缺点:

  • Token 包含了用户的全部信息,不只是如 SessionID 类似的一个 ID 值,因此会增加每次请求包的大小。

目前使用较多的是基于JWT(JSON Web Tokens) 的 Token 认证法。

JWT

token认证的一种实现方式。特别适用于分布式站点的单点登录(SSO)场景,是目前最流行的跨域认证解决方案。

https://jwt.io/

​ 通俗地说,JWT的本质就是一个字符串,它是将用户信息保存到一个Json字符串中,然后进行编码后得到一个JWT token并且这个JWT token带有签名信息,接收后可以校验是否被篡改,所以可以用于在各方之间安全地将信息作为Json对象传输。

JWT的认证流程
  1. 首先,前端通过Web表单将自己的用户名密码发送到后端的接口,这个过程一般是一个POST请求。建议的方式是通过SSL加密的传输(HTTPS),从而避免敏感信息被嗅探。
  2. 后端核对用户名和密码成功后,将包含用户信息的数据作为JWT的Payload,将其与JWT Header分别进行Base64编码拼接后签名,形成一个JWT Token,形成的JWT Token就是一个如同lll.zzz.xxx的字符串
  3. 后端将JWT Token字符串作为登录成功的结果返回给前端。前端可以将返回的结果保存在浏览器中,退出登录时删除保存的JWT Token即可
  4. 前端在每次请求时将JWT Token放入HTTP请求头中的Authorization属性中(解决XSS和XSRF问题)
  5. 后端检查前端传过来的JWT Token,验证其有效性,比如检查签名是否正确、是否过期、token的接收方是否是自己等等
  6. 验证通过后,后端解析出JWT Token中包含的用户信息,进行其他逻辑操作(一般是根据用户信息得到权限等),返回结果
JWT结构

​ JWT由3部分组成:标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候,会将JWT的3部分分别进行Base64编码后用.进行连接形成最终传输的字符串。

JWTString=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)
1.Header

​ JWT头是一个描述JWT元数据的JSON对象,alg属性表示签名使用的算法,默认为HMAC SHA256(写为HS256);typ属性表示令牌的类型,JWT令牌统一写为JWT。最后,使用Base64 URL算法将上述JSON对象转换为字符串保存

{
  "alg": "HS256",
  "typ": "JWT"
}
2.Payload

​ 有效载荷部分,是JWT的主体内容部分,也是一个JSON对象,包含需要传递的数据。 JWT指定七个默认字段供选择

- iss (issuer):签发人
- exp (expiration time):过期时间
- sub (subject):主题
- aud (audience):受众
- nbf (Not Before):生效时间
- iat (Issued At):签发时间
- jti (JWT ID):编号

​ 这些预定义的字段并不要求强制使用。除以上默认字段外,我们还可以自定义私有字段,一般会把包含用户信息的数据放到payload中,如下例:

{
  "sub": "1234567890",
  "name": "Helen",
  "admin": true
}

​ 请注意!默认情况下JWT是未加密的,因为只是采用base64算法,拿到JWT字符串后可以转换回原本的JSON数据,任何人都可以解读其内容,因此不要构建隐私信息字段,比如用户的密码一定不能保存到JWT中,以防止信息泄露。JWT只是适合在网络中传输一些非敏感的信息

3.Signature

​ 签名哈希部分是对上面两部分数据签名,需要使用base64编码后的header和payload数据,通过指定的算法生成哈希,以确保数据不会被篡改。首先,需要指定一个密钥(secret)。该密码仅仅保存在服务器中,并且不能向用户公开。然后,使用header中指定的签名算法(默认情况下为HMAC SHA256)根据以下公式生成签名。

HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)

在计算出签名哈希后,JWT头,有效载荷和签名哈希的三个部分组合成一个字符串,每个部分用.分隔,就构成整个JWT对象

注意JWT每部分的作用,在服务端接收到客户端发送过来的JWT token之后:

  • header和payload可以直接利用base64解码出原文,从header中获取哈希签名的算法,从payload中获取有效数据
  • signature由于使用了不可逆的加密算法,无法解码出原文,它的作用是校验token有没有被篡改。服务端获取header中的加密算法之后,利用该算法加上secretKey对header、payload进行加密,比对加密后的数据和客户端发送过来的是否一致。注意secretKey只能保存在服务端,而且对于不同的加密算法其含义有所不同,一般对于MD5类型的摘要加密算法,secretKey实际上代表的是盐值
增加JWT的安全性
  • 因为JWT是在请求头中传递的,所以为了避免网络劫持,推荐使用HTTPS来传输,更加安全
  • JWT的哈希签名的密钥是存放在服务端的,所以只要服务器不被攻破,理论上JWT是安全的。因此要保证服务器的安全
  • JWT可以使用暴力穷举来破解,所以为了应对这种破解方式,可以定期更换服务端的哈希签名密钥(相当于盐值)。这样可以保证等破解结果出来了,你的密钥也已经换了

4、OAuth(开放授权)

​ OAuth是Open Authority的缩写。OAuth 就是一种授权机制。用来授权第三方应用,获取用户数据。通过数据的所有者授权第三方应用进入系统,系统从而产生一个临时的令牌,代替密码,授权第三方应用使用权限。

​ OAuth开放授权为用户资源的授权提供了一个安全的、开放而又简易的标准。OAUTH的授权不会使第三方触及到用户的帐号信息例如用户名与密码等,即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH授权是安全的,目前OAUTH的版本为2.0

优点
可控姓: 保证了令牌既可以让第三方应用获得权限,同时又随时可控,不会危及系统安全;
方便性: 只要知道了令牌,就能进入系统;
重要性: 系统一般不会再次确认身份,所以令牌必须保密,泄漏令牌与泄漏密码的后果是一样的,这也是为什么令牌的有效期,一般都设置得很短的原因。

SSO 与 Oauth

SSO

SSO是Single Sign On的缩写。SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。

区别

两者都是使用令牌的方式来代替用户密码访问应用。

SSO :一次登陆

Oauth:一次授权

OAuth解决的是服务提供方(微信等)给第三方应用授权的问题;

SSO解决的是大型系统中各个子系统如何共享登陆状态的问题。(比如你登录了百度首页,那么你进入百度百科,百度贴吧,百度音乐等服务的时候都不需要重新登录。)

两者都是基于分布式系统,涉及到多个角色,但是不同的是,OAuth是一种具体的协议,SSO可以说是一种技术,可以用cookie实现,甚至也可以用OAuth实现(虽然不是很好),比如OAuth中的服务提供方可以充当SSO认证中心,OAuth中的第三方应用也可以是SSO中的子系统。

参考1 参考2 参考3文章来源地址https://www.toymoban.com/news/detail-839528.html

到了这里,关于鉴权与身份认证的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • HTTP身份认证401不同情况下弱口令枚举方法及java代码实现

    大家好,我是ABC_123 。在日常的渗透测试及红队评估项目中,经常遇到http 401身份认证的情况,具体就是访问一个特定目录的时候,会弹出一个要求输入用户名密码的框框。很多朋友会误以为是与tomcat的http basic认证一样,就是把用户名及密码进行了简单的base64加密,然后使用

    2024年01月15日
    浏览(48)
  • 云计算|OpenStack|社区版OpenStack安装部署文档(三 --- 身份认证服务keystone安装部署---Rocky版)

    keystone是openstack的关键必选组件之一,其作用是提供身份认证服务,所有的身份认证信息都是存储在controller节点的数据库内。 具体的关于keystone的介绍可以参见官方文档: OpenStack Docs: Identity service overview 社区版openstack 服务组件的安装顺序: 以上图的文档顺序安装,第一个是

    2024年02月06日
    浏览(45)
  • 第83篇:HTTP身份认证401不同情况下弱口令枚举方法及java代码实现(上篇)

    大家好,我是ABC_123 。在日常的渗透测试及红队评估项目中,经常遇到http 401身份认证的情况,具体就是访问一个特定目录的时候,会弹出一个要求输入用户名密码的框框。很多朋友会误以为是与tomcat的http basic认证一样,就是把用户名及密码进行了简单的base64加密,然后使用

    2024年02月04日
    浏览(43)
  • 统一身份认证,构建数字时代的安全壁垒——统一身份认证介绍、原理和实现方法

    随着数字化时代的来临,个人和机构在互联网上的活动越来越频繁,对于身份认证的需求也愈发迫切。为了有效应对身份欺诈、数据泄露等问题,统一身份认证(Unified Identity Authentication)应运而生。 在本文博主将介绍统一身份认证的概念、原理以及其具体的实现方案。 统一

    2024年02月03日
    浏览(45)
  • 身份认证——802.1x认证和MAC认证讲解

    目录 802.1x基础 EAP(Extensible Authentication Protocol)可扩展认证协议 EAPoL(EAP over LAN)局域网可扩展认证协议 802.1x体系架构 受控端口的受控方式 802.1x认证 802.1x认证触发方式 客户端退出认证 802.1x认证方式 MAC认证 802.1x认证又称为EAPOE(Extensible Authentication Protocol Over Ethernet)认证

    2024年02月03日
    浏览(43)
  • 【认证绕过】NACOS身份认证绕过漏洞分析

    前言 工作中遇到一个nacos服务认证绕过的问题,在此总结一下漏洞原因。 官方文档描述: Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。 Nacos 帮助您更敏捷和容易地构建、

    2023年04月13日
    浏览(52)
  • uniapp - 安卓|苹果App软件实现调用百度人脸识别接口服务及人脸活体认证功能,uniapp苹果ios、安卓Android手机app平台,人脸认证、活体检测、身份证与人脸验证(示例代码,一键复制

    在uniapp手机App开发中(安卓Android|苹果ios系统),利用百度人脸识别api接口对接uniapp APP进行人脸识别、人脸检测、活体验证、人脸对比、人脸搜索、身份证信息是否与人脸匹配,支持离线SDK集成、离线无网络正常使用功能、自定义人脸识别框附近的页面样式和大小等。 提供详

    2024年04月11日
    浏览(68)
  • 常见的身份认证技术

    (1)   口令认证技术(用户名/密码) 这是最简单也是最传统的身份认证方法,通过口令来验证用户的合法有效性。 通过用户名  ID  和用户密码  PW  来认证用户。 只要能够正确验证密码,系统就判定操作者是合法用户。 口令认证主要适用于小型封闭型系统。 存在的问题

    2024年02月06日
    浏览(54)
  • NACOS身份认证绕过

    一、漏洞描述 Nacos是Alibaba的一个动态服务发现、配置和服务管理平台。攻击者通过添加Nacos-Server的User-Agent头部将可绕过(nacos.core.auth.enabled=true)鉴权认证,从而进行API操作。 二、漏洞利用 访问 http://xxxxx/nacos/v1/auth/users?username=testpassword=test ,并使用burpsuite进行抓包,将方法

    2024年02月16日
    浏览(46)
  • Nacos身份认证漏洞

    公司Nacos版本有用的2.0.1和2.0.3的都复现了身份认证的漏洞,无需认证身份就可以查看用户列表以及注册新用户,并且注册上来的新用户可以查看所有public命名空间下的配置资源! 1、查看用户列表 URL: http://ip:8848/nacos/v1/auth/users?pageNo=1pageSize=1 方法类型:GET 返回结果: 如图示

    2023年04月10日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包