1.几种常见的认证机制
1.1、HTTP Basic Auth:
Basic Auth是http协议提供的一个简单的认证机制,当用户以GET方式请求相应的接口时,服务端会返回401的响应码,提示Authorization Required,此时浏览器会弹出用户名和密码的输入框,让用户提供凭证,浏览器得到数据后进行验证,验证成功后返回200响应。当用户输入的凭证信息不匹配时,服务端会再次返回401,直到输入正确凭证信息。

  • 优点:传输简单,不需要采用cookie/session,或是其他复杂的认证协商机制
  • 缺点:这种方式仅使用了base64进行重编码,并未使用任何加密算法,所以基本上等于明文传输。
  • 适用场景:因为Basic Auth的低安全高性能的特性,其通常应用于内网环境下,搭配https进行加密使用(低安全考虑)

实例:CODING...
1.2、OAuth:
OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版。OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权
OAuth在通信的过程中给客户端和服务端设置了一个验证层(身份验证服务器),客户端在通信过程中,首先会向用户需求授权,之后授权客户端会向身份验证服务器申请令牌,认证服务器验证通过后向用户发放token(令牌),用户通过这个token向服务器发送请求,服务器确认令牌无误后向用户发放资源。
OAuth认证方式下客户端的授权模式:
授权码模式:授权码模式时OAuth认证方式下最严密完善的授权模式,在这种认证方式下,用户首先对客户端进行授权操作,如果用户同意向认证服务器进行授权操作,客户端重定向到重定向的路径,并得到一个授权码,之后再通过post请求向资源服务器附加重定向路径与授权码,得到token,再向资源服务器的指定接口进行访问时附加token,这样才能得到受到保护的资源。
实例:CODING...
优点:

  • 因为客户端不接触用户密码,服务器端更易于集中保护
  • 广泛传播并被持续使用
  • 短寿命和封装的token
  • 资源服务器和授权服务器解耦
  • 集中式授权,简化客户端
  • HTTP/JSON友好,易于请求和传递token
  • 考虑多种客户端架构场景
  • 客户可以具有有不同的信任级别

缺点:

  • 协议框架太宽泛,造成各种实现的兼容性和相互操作性差
  • 和OAuth1.0不兼容
  • OAuth2.0不是一个认证协议(是授权协议),OAuth2.0本身并不能告诉你任何用户信息

适用场景:第三方授权登录,第三方拿不到用户的用户账号密码,只能通过token来访问用户信息,保证了数据共享时的安全性。

优缺点摘自https://www.cnblogs.com/wadmwz/p/10318656.html
实例:CODING...
1.3、Cookie Auth
使用Cookie Auth的用户向服务器请求需要认证的资源时,服务器先询问是否提供了认证Cookie,如果没有则将用户重定向到登录界面,登陆成功后服务器产生Cookie并通过HTTP响应中的Set-Cookie头发送给客户端,在之后用户需要访问资源时,客户端浏览器检索Path和Domain等属性与用户请求资源相匹配的Cookie,并将找到的Cookie通过HTTP请求中的Cookie头提交给Web服务器,服务器验证其中的值,验证Cookie的服务器服务器提取客户端浏览器递交的Cookie,验证其中的访问令牌。若合法,则将访问请求的资源发送给客户端浏览器;反之则拒绝用户的访问请求。
优点:在 Web认证中 ,因为HTTP协议本身的局限,必须采用其他技术将相关认证标记以某种方式持续传送,以免客户从一个页面跳转至另一个页面时重新输入认证信息,Cookie正为此提供了便利。
缺点:
  • Cookie被用户非法篡改,如篡改其中的expire项,可将Cookie的有效期延长;篡改path项可使用户能够访问服务器上不被授权的内容;或修改domain项,使用户能够访问不被授权的服务器从而获得合法用户的信息等;
  • 被非法用户非法截获,然后在有限期内重放,则非法用户将享有合法用户的合法权益,可能会损害网站方的利益;
  • 若Cookie被服务器加密,而非法用户通过强力攻击或其他手段获得了相应的加密密钥,则非法用户可以伪造任何合法Cookie,从而可以访问合法用户的所有个性化信息,甚至是账户信息等

适用场景:多页面(同域)共同使用同一身份信息的情况
实例:CODING...
1.4、Token Auth
Token Auth使用基于Token的身份验证方法,在请求时用户需要提供自己的账户和密码,服务器验证成功后向用户签发token,客户端接收到token之后将其储存在cookie中(也可以以其他方式发送),客户端每次请求受保护的资源时都要带着这个token,服务器在验证成功之后就向客户端返回请求的资源。另外为确保安全问题,
优点:

  • 无需服务器储存session信息
  • 去耦,token的生成只需要调用相应的api
  • 适用于当客户端非浏览器的情况(当不适用cookie的情况下)
  • 不存在CSRF的安全问题
  • 适用于资源适用CDN的情况,在这种情况下我们仅需提供一个api

缺点:在不使用https的情况下,存在MITM、XSS风险
适用场景:跨域访问、非浏览器客户端
实例:CODING

Last modification:April 9th, 2020 at 11:28 am
If you think my article is useful to you, please feel free to appreciate