您现在的位置是:群英 > 网络安全 > 安全技术
web安全认证有多少种方式,你了解多少?
Admin发表于 2021-12-15 18:02:001657 次浏览

    这篇文章我们来了解web安全认证的几种常见方式,下文给大家介绍了五种,都有很详细的介绍,有需要的朋友可以参考了解,感兴趣的朋友接下来就跟随小编来了解看看吧!

    1、Http Basic Auth

    这是一种最古老的安全认证方式,这种方式就是简单的访问API的时候,带上访问的username和password,由于信息会暴露出去,所以现在也越来越少用了,现在都用更加安全保密的认证方式,可能某些老的平台还在用。

    如下图所示,弹出一个框,让你填写用户名密码。这就是Tomcat自带的HTTPBasic认证。

    这就是你访问应用的凭据了,那段xxxXXX字符串是我写的表示这是一段密文,这是一段什么密文呢,就是讲用户名和密码进行一个Base64加密后得到的密文。所以你现在是不是也有同感了---这tm也太容易盗取了,所以现在新的应用几乎不怎么用这种方式了,虽然简单,但是安全级别太低了。

    2、OAuth2

https://blog.csdn.net/aHardDreamer/article/details/88650939

    OAuth 即:Open Authrization(开放授权), 它是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密资源,而无需将用户名和密码提供给第三方。比如我们熟知的通过qq/微信/微博等登录第三方平台。OAuth 1.0版本发布后有许多安全漏洞,所以在OAuth2.0里面完全废止了OAuth1.0,它关注客户端开发者的简易性,要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户,要么允许第三方应用代表用户获得访问的权限。读起来有点绕口,其实原理也非常简单,请看下面讲解。

    一、首先我们要了解在OAuth2 认证和授权的过程中有这三个角色:

    1. 服务提供方:顾名思义,提供受保护的服务和资源的,用户在这里面存了很多东西。

    2. 用户: 存了东西(照片,资料等)在服务提供方的人。

    3. 客户端:服务调用方,它要访问服务提供方的资源,需要在服务提供方进行注册,不然服务提供方不鸟它呀。

    二、OAuth2 认证和授权的过程:

    1)用户想操作存放在服务提供方的资源;

    2)用户登录客户端,客户端向服务提供方请求一个临时token;

    3)服务提供方验证客户端的身份后,给它一个临时token;

    4)客户端获得临时token之后,将用户引导至服务提供方的授权页面,并请求用户授权。(在这个过程中会将临时token和客户端的回调链接/接口 发送给服务提供方 ---很明显服务提供方到时会回来call这个接口在用户认证并授权之后)

    5)用户输入用户名密码登录,登录成功之后,可以授权客户端访问服务提供方的资源;

    6)授权成功后,服务提供方将用户引导至客户端的网页(call第4步里面的回调链接/接口);

    7)客户端根据临时token从服务提供方那里获取正式的access token;

    8)服务提供方根据临时token以及用户的授权情况授予客户端access token;

    9)客户端使用access token访问用户存放在服务提供方的受保护的资源。

    三、拿access token的方法(Grant Type)有下面四种,每一种都有适用的应用场景:

    1、Authorization Code (授权码模式)

    结合普通服务器端应用使用。

    1)用户访问客户端,后者将前者导向认证服务器,假设用户给予授权,认证服务器将用户导向客户端事先指定的"重定向URI"(redirection URI),同时附上一个授权码。

    2)客户端收到授权码,附上早先的"重定向URI",向认证服务器申请令牌:GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向页面链接。请求成功返回code授权码,一般有效时间是10分钟。

    3)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向页面链接。请求成功返回access Token和refresh Token。

    2、Implicit(简化模式)

    结合移动应用或 Web App 使用。

    Access Token直接从授权服务器返回(只有前端渠道)

    不支持refresh tokens

    假定资源所有者和公开客户应用在同一个设备上

    最容易受安全攻击

    3、Resource Owner Password Credentials

    适用于受信任客户端应用,例如同个组织的内部或外部应用。

    使用用户名密码登录的应用,例如桌面App

    使用用户名/密码作为授权方式从授权服务器上获取access token

    一般不支持refresh token

    假定资源拥有者和公开客户在相同设备上

    4、Client Credentials

    适用于客户端调用主服务API型应用(比如百度API Store,不同项目之间的微服务互相调用)

    只有后端渠道,使用客户凭证获取一个access token

    因为客户凭证可以使用对称或者非对称加密,该方式支持共享密码或者证书

    3、Cookie-Session Auth

    Cookie-Session 认证机制在我们初学J2EE的时候接触的比较多,就是为一次请求认证在服务端创建一个Session对象,同时在客户端的浏览器端创建了一个Cookie对象;通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的,当我们关闭浏览器的时候,cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效;

    但是这种基于cookie-session的认证使应用本身很难得到扩展,随着不同客户端用户的增加,独立的服务器已无法承载更多的用户,而这时候基于session认证应用的问题就会暴露出来。

    基于session认证所显露的问题:

    1)Session 增多会增加服务器开销

    每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。

    2)分布式或多服务器环境中适应性不好

    用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。不过,现在某些服务器可以通过设置粘性Session,来做到每台服务器之间的Session共享。

    3)容易遭到CSRF攻击

    因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击

    4、Token Auth

    基于token的鉴权机制类似于http协议也是无状态的,它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。

    流程:

    用户使用用户名密码来请求服务器

    服务器进行验证用户的信息

    服务器通过验证发送给用户一个token

    客户端存储token,并在每次请求时附送上这个token值

    服务端验证token值,并返回数据

    这个token必须要在每次请求时传递给服务端,它应该保存在请求头里, 另外,服务端要支持CORS(跨来源资源共享)策略,一般我们在服务端这么做就可以了Access-Control-Allow-Origin。

    5、JWT 认证机制(Json Web Token)

    JWT作为一个开放的标准(RFC 7519),定义了一种简洁的,自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在,这些信息是可信的,JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。

    简洁性

    可以通过URL,POST参数或者在HTTP header发送,因为数据量小,传输速度也很快

    自包含性

    负载中包含了所有用户所需要的信息,避免了多次查询数据库

    下列场景中使用JSON Web Token是很有用的:

    Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录,后续每个请求都将包含JWT,允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性,因为它的开销很小,并且可以轻松地跨域使用。

    Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言,JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名,例如,用公钥/私钥对,你可以确定发送人就是它们所说的那个人。另外,由于签名是使用头和有效负载计算的,您还可以验证内容没有被篡改。

    JWT的结构:

    通过这张图,很清晰看出JWT的结构分为三部分,他们之间用“.”连接:

    Header:

    header典型的由两部分组成:token的类型(“JWT”)和算法名称(比如:HMAC SHA256或者RSA等等)。

    例如:

    然后,用Base64对这个JSON编码就得到JWT的第一部分

    Payload:

    JWT的第二部分是payload,它包含声明(要求)。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。

    Registered claims : 这里有一组预定义的声明,它们不是强制的,但是推荐。比如:iss (issuer), exp (expiration time), sub (subject), aud (audience)等。

    Public claims : 可以随意定义。

    Private claims : 用于在同意使用它们的各方之间共享信息,并且不是注册的或公开的声明。

    下面是一个例子:

    对payload进行Base64编码就得到JWT的第二部分

    注意,不要在JWT的payload或header中放置敏感信息,除非它们是加密的。

    Signature:

    为了得到签名部分,你必须有编码过的header、编码过的payload、一个秘钥,签名算法是header中指定的那个,然对它们签名即可。

    例如:

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

    签名是用于验证消息在传递过程中有没有被更改,并且,对于使用私钥签名的token,它还可以验证JWT的发送方是否为它所称的发送方。

    碰到JWT token可以去JWT官网解密看看,下面这是官网解密出来的数据,可以很清楚的看到它的三部分内容:

    以上几种就是常见的web安全认证方式了,web安全的问题是一定的要重视,希望大家阅读完这篇文章能有所收获。最后,想要了解更多web安全的相关内容,可以及关注其他文章。

文本转载自PHP中文网

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:mmqy2019@163.com进行举报,并提供相关证据,查实之后,将立刻删除涉嫌侵权内容。

标签: web安全认证
相关信息推荐
2023-05-05 16:34:34 
摘要:Network Stumbler是WINDOWS平台下基于802.11的无线网络扫描工具,只要计算机安装了无线网络卡,使用这套软件就可以帮扫描出附近有没有可以使用的无线网络基地台,包括基地台强度、频道等数据都会显示出来。可自动识别出附近活动的无线设备的SSID、网络、MAC地址,以及信号强度。
2023-05-26 11:54:10 
摘要:MVC - 云服务器部署
2023-06-05 17:50:30 
摘要:百度 CDN公共库
群英网络助力开启安全的云计算之旅
立即注册,领取新人大礼包
  • 联系我们
  • 24小时售后:4006784567
  • 24小时TEL :0668-2555666
  • 售前咨询TEL:400-678-4567

  • 官方微信

    官方微信
Copyright  ©  QY  Network  Company  Ltd. All  Rights  Reserved. 2003-2019  群英网络  版权所有   茂名市群英网络有限公司
增值电信经营许可证 : B1.B2-20140078   粤ICP备09006778号
免费拨打  400-678-4567
免费拨打  400-678-4567 免费拨打 400-678-4567 或 0668-2555555
微信公众号
返回顶部
返回顶部 返回顶部