wwqdrh
☀️

认证模式


HTTP 协议提供验证机制来保护资源。当一个请求要求取得受保护的资源时，网页服务器回应一个 401 Unauthorized error 错误码。这个回应包含一个指定了验证方法和领域的 WWW-Authenticate 头信息。把这个领域想像成一个存储着用户名和密码的数据库，它将被用来标识受保护资源的有效的用户。比如，你试着去访问某个网站上标识为“Personal Files”的资源，服务器响应可能是：WWW-Authenticate: Basic realm="Personal Files" (假设验证方法是 Basic)。


最广泛使用的是基本验证 (Basic Authentication) 和摘要验证 (Digest Authentication)。 Cookie Auth，为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象，通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效


Basic模式：

Basic Auth是配合RESTful API 使用的最简单的认证方式，每次请求API时都提供用户的username和password。但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的RESTful API时，尽量避免采用HTTP Basic Auth。

  1. 浏览器发送http报文请求一个受保护的资源。

  2. 服务端的web容器将http响应报文的响应码设为401 ，响应头部加入WWW-Authenticate: Basic realm=”myTomcat”（可以通过realm划分为不同的域，每个域可以有自己的权限鉴别方案）。

  3. 浏览器弹出对话框让用户输入用户名和密码，并用Base64进行编码，实际是用户名+冒号+ 密码进行Base64编码，即Base64(username:password)，这次浏览器就会在 HTTP报文头部加入Authorization: Basic bXl0b21jYXQ=。

  4. 服务端web容器获取HTTP报文头部相关认证信息，匹配此用户名与密码是否正确，是否有相应资源的权限，如果认证成功则返回相关资源，否则再执行②，重新进行认证。 ⑤以后每次访问都要带上认证头部。


Digest模式

为弥补 BASIC 认证存在的弱点，从 HTTP/1.1 起就有了 DIGEST 认证。 DIGEST 认证同样使用质询 / 响应的方式（challenge/response），但不会像 BASIC 认证那样直接发送明文密码。所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。

  1. 浏览器发送http报文请求一个受保护的资源。
  2. 服务端的web容器将http响应报文的响应码设为401 ，响应头部比Basic模式复杂，WWW-Authenticate: Digest realm=”myTomcat”,qop="auth",nonce="xxxxxxxxxxx",opaque="xxxxxxxx" 。其中qop的auth表示鉴别方式；nonce 是随机字符串；opaque服务端指定的值，客户端需要原值返回。
  3. 浏览器弹出对话框让用户输入用户名和密码，浏览器对用户名、密码、nonce值、HTTP请求方法、被请求资源 URI等组合后进行MD5运算，把计算得到的摘要信息发送给服务端。请求头部类似如下，Authorization: Digest username="x xxxx",realm="myTomcat",qop="auth",nonce="xxxx x",uri="xxxx",cnonce="xxxxxx",nc=00000001,response="x xxxxxxxx",opaque="xxxxxxxxx" 。其中username 是用户名；cnonce是客户端生成的随机字符串；nc是运行认证的次数； response就是最终计算得到的摘要。
  4. 服务端web容器获取HTTP报文头部相关认证信息，从中获取到username ，根据username获取对应的密码，同样对用户名、密码、nonce值、 HTTP请求方法、被请求资源URI等组合进行MD5运算，计算结果和 response进行比较，如果匹配则认证成功并返回相关资源，否则再执行②，重新进行认证。
  5. 以后每次访问都要带上认证头部。

Form模式

比base、digest这些HTTP协议规范范畴好（规范使得很多东西无法自定义，例如登录窗口、错误展示页面）


TokenAuth

客户端使用用户名跟密码请求登录，服务端收到请求，去验证用户名与密码。验证成功后，服务端会签发一个Token，再把这个Token发送给客户端。


客户端收到Token以后可以把它存储起来，比如放在Cookie里，客户端每次向服务端请求资源的时候需要带着服务端签发的Token，服务端收到请求，然后去验证客户端请求里面带着的Token，如果验证成功，就向客户端返回请求的数据。

TokenAuth的好处

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

JWT

一个token分3部分，按顺序: • 头部（header)，类型与使用的加密算法 • 载荷（payload)，json对象，传递的信息，其中有7个官方定义的字段( iss (issuer)：签发人 exp (expiration time)：过期时间 sub (subject)：主题 aud (audience)：受众 nbf (Not Before)：生效时间 iat (Issued At)：签发时间 jti (JWT ID)：编号),使用 Base64URL 算法转成字符串。 • 签证（signature) 对象为一个很长的字符串(对前两部分的签名，防止数据篡改)，字符之间通过"."分隔符分为三个子串。注意JWT对象为一个长字串，各字串之间也没有换行符，一般格式为：xxxxx.yyyyy.zzzzz 。

JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。 HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) 算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就构成整个JWT对象TOKEN， 就可以返回给用户。

OAuth

OAuth(开放授权)是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源(如照片，视频，联系人列表)，而无需将用户名和密码提供给第三方应用。


OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统(例如，视频编辑网站)在特定的时段(例如，接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容 这种基于OAuth的认证机制适用于个人消费者类的互联网产品，如社交类APP等应用，但是不太适合拥有自有认证权限管理的企业应用。


OAuth2

"客户端"不能直接登录"服务端"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。


"客户端"登录授权层以后，"服务端"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。