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

时间：2022-09-07 11:14

本文为大家介绍了五种常用的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。

（免费学习视频分享：php视频教程）

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。