web认证机制

1、 HTTP Basic Authentication认证

Basic 认证是HTTP 中非常简单的认证方式,因为简单,所以不是很安全。

客户端向服务端请求时,如果没有进行认证,会返回401状态码,要求客户端输入用户名密码。

当用户输入完用户名和密码后,用户名和密码会经过BASE64加密附加到请求信息中再次请求HTTP服务器,HTTP服务器会根据请求头携带的认证信息,决定是否认证成功及做出相应的响应。

浏览器访问test.api.com/1.html,请求会pedding住,等待输入用户密码。成功后可以访问内容。

request头信息中可以看到Authorization: Basic cGFuZ291OjEyMzQ1Ng==base64解码后就是pangou:123456。、

参考:https://segmentfault.com/a/1190000004694935

2、Digest Authentication (摘要式身份认证)

摘要式身份认证解决了基础认证的明文传输问题。

实现方案主要通过服务端返回nonce,然后客户端混淆用户名密码进行加密。

服务端可以进行配置nonce的过期时间。

auth_digest模块需要额外安装。

参考:https://www.nginx.com/resources/wiki/modules/auth_digest/

3、OAuth2

oauth2其实是一个授权系统。不过他可以通过扩展openid connect进行认证。

oauth2主要有一下几种流程:

  • 授权码模式(authorization code)最为严谨,用于常见的第三方应用。
  • 简化模式(implicit)常用于单页应用
  • 密码模式(resource owner password credentials)因为需要用户提供账号密码敏感信息,通常用于客户端与服务端(授权系统)为同一公司的情况下。
  • 客户端模式(client credentials)可用于企业内部服务之间的授权。比如A服务是否有权限访问B服务

参考:https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

4、Cookie Auth

即传统cookie-session模式

5、Token Auth

Token Auth的优点

  • 支持跨域访问: Cookie是不允许垮域访问的,这一点对Token机制是不存在的,前提是传输的用户认证信息通过HTTP头传输.
  • 无状态:Token机制在服务端不需要存储session信息,因为Token 自身包含了所有登录用户的信息,只需要在客户端的cookie或本地介质存储状态信息.
  • 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料(如:javascript,HTML,图片等),而你的服务端只要提供API即可.
  • 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成,只要在你的API被调用的时候,你可以进行Token生成调用即可.
  • 更适用于移动应用: 当你的客户端是一个原生平台(iOS, Android,Windows 8等)时,Cookie是不被支持的(你需要通过Cookie容器进行处理),这时采用Token认证机制就会简单得多。
  • CSRF:因为不再依赖于Cookie,所以你就不需要考虑对CSRF(跨站请求伪造)的防范。
  • 性能: 一次网络往返时间(通过数据库查询session信息)总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
  • 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候,不再需要为登录页面做特殊处理.
  • 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库(.NET, Ruby, Java,Python, PHP)和多家公司的支持(如:Firebase,Google, Microsoft).

参考:https://juejin.im/entry/593522150ce463005728585a