介绍几种常用的web安全认证方式

发布时间:2021-10-17 11:30 来源:博客园 阅读:0 作者:V 栏目: 网络安全

本文为大家介绍了五种常用的web安全认证方式,具有一定的参考价值,希望能对大家有所帮助。

1、Http Basic Auth

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

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

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

2、OAuth2

本人之前的博客介绍过OAuth2 以及使用Azure AD实现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官网解密看看,下面这是官网解密出来的数据,可以很清楚的看到它的三部分内容:

更多关于JWT的内容,可以前往这个博客:

https://www.cnblogs.com/cjsblog/p/9277677.html

参考:

https://www.jianshu.com/p/f8c43dcd8b69

https://blog.csdn.net/alan_liuyue/article/details/88183267

https://www.cnblogs.com/cjsblog/p/9277677.html

相关推荐:

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