应用的认证和受权(基本认证、session-cookie认证、token认证及OAuth2.0受权)

时间  2020-02-09 标签 应用 认证 受权 基本 session cookie token oauth2.0 oauth

前言:javascript

 认证受权是目前大多数系统都必需要实现的功能,认证就是验证用户的身份，受权就是验证身份后对受限资源的访问控制
 在先后端分离的应用中，后端主要做为Model层，为前端提供数据访问API。为了保证数据可靠地在用户和服务端之间传输，实现服务端的认证就显得很重要。
 常见的服务端认证方法有基于Cookie的认证,如session；以及Token(令牌)认证，如JWT.前者依赖于cookie而实现，在每次请求时都须要带上cookie,取出相应字段并与服务器端的进行对比，以实现身份的认证.然后者仅仅须要在HTTP的头部附上token，由服务端check signature便可实现，无须担忧cookie存在的cors问题.
 实战部分你们能够自行查找各类语言如何实现这些功能，其余博客都有，我这里只是汇总总结一下理论内功.前端

先后端常见鉴权方式:java

  • HTTP Basic Authentication基本认证
  • 基于cookie认证:
    1. cookie认证
    2. session认证
  • token(令牌)认证
    1. SAML(淘汰了)
    2. JWT(JSON Web Token)
  • 开放受权(OAuth)

注:
 Auth0,是一家identity-as-a-service提供商,Autho0将现有主流的受权协议都实现了一遍，还为多种主流语言提供了SDK。其中JWT与SAML(设计于2005年，是较早的格式，基于XML.JWT是基于JSON，并用于新的身份验证和受权协议，如OpenID Connect和OAutho2.0)都是其设计的.git

1. HTTP Basic Authentication

(1) 简介：github

参考文档: Basic Authentication
 这种受权方式是浏览器遵照http协议实现的基本受权方式，用于限制对网站资源的访问。这种方式不须要Cookie和Session,只须要客户端发起请求的时候，在头部header中提交用户名和密码就能够.若是没有附加，会弹出一个对话框,要求输入用户名和密码。但它不提供信息加密措施，一般都是以明文或者base64编码传输,因此基本验证方案并不安全。基本验证方案应与HTTPS/TLS协议搭配使用。(基本淘汰)web

(2) 认证过程:ajax

认证过程(服务端开启了www-authentication认证功能):
图解
 1. 客户端向服务端请求数据(http请求或者一个ajax异步请求).此时，假设客户端还没有被验证.
 2. 服务端收到请求后，首先解析发送来的数据是否包含有Authorization: Basic YWRtaW46YWRtaW4=这种格式的数据，若是没有这样的数据，则服务端会发送HTTP信息头WWW-Authenticate: Basic realm=“一串字符串”到客户端.响应客户端的状态码是401 Unauthorized。
 3. 当客户端(浏览器)收到带有相似带有相似WWW-Authenticate: Basic realm=“.”的信息后，会弹出登陆验证的对话框，要求用户输入验证信息.
 4. 用户输入用户名和密码后，浏览器用Base64编码，放在Authorization header(Authorization: Basic YWRtaW46YWRtaW4=经base64解密后，为admin:admin)中发送给服务端。
 5. 服务端收到带有用户验证信息的数据后，会将Authorization header中的用户名密码取出,进行验证，若是验证经过，将根据请求，发送资源给客户端.
 6. 认证以后将认证信息放在session,之后在sessin有效期内就不用再认证了.
 7. 许多客户端同时支持避免弹出登陆框，而是使用包含用户名和密码的通过编码的URL。(形如https://username:password@www.example.com/)此方法已经废弃.redis

2. 基于cookie的认证

(1) HTTP是一种无状态协议:算法

  HTTP的每一个请求都是彻底独立的，每一个请求包含了处理这个请求所需的完整的数据，发送请求不涉及到状态变动。
 用户第一次发起请求,与服务器创建链接并登录成功后，为了不每次打开一个页面都须要登录一下(注意独立含义)，就出现了cookie,session.cookie和session的做用是建立和维护多组独立的状态.数据库

HTTP无状态协议的优势:

 HTTP这样的无状态协议，使用元数据(如cookie头)来维护会话，使得会话与链接自己独立起来，这样即使链接断开了，会话状态也不会受到严重伤害，保持会话也不须要保持链接自己。另外，无状态的优势还在于对中间件友好，中间件无需彻底理解通讯双方的交互过程，只须要能正确分片消息便可，并且中间件能够很方便地将消息在不一样的链接上传输而不影响正确性，这就方便了负载均衡等组件的设计。

HTTP无状态协议的缺点:

 单个请求须要的全部信息都必需要包含在请求中(请求头大，浪费带宽)一次发送到服务端，这致使单个消息的结构须要比较复杂，必须可以支持大量元数据,所以HTTP消息的解析要比其余许多协议要复杂得多。
  相同的数据可能在多个请求上反复传输，下降了协议的效率

(2) cookie认证:
会话跟踪:

  会话(session)跟踪是web程序中经常使用的技术，用来跟踪用户的整个会话，经常使用的会话跟踪技术是Cookie和Session。Cookie经过在客户端记录信息肯定用户身份，Session经过在服务端记录信息肯定用户身份。

什么是Cookie:

参考文档: mdn cookie
 cookie意味"甜饼"，是由W3C组织提出，最先由Netscape社区发展的一种机制。目前Cookie已经成为标准,全部浏览器(IE/Firefox/Opera等)都支持Cookie.
 cookie是一小段的文本信息(key=value pairs)，客户端请求服务器，若是服务器须要记录该用户的状态，就使用response向客户端浏览器颁发一个Cookie(响应头中有多个set-cookie字段，每段对应一个cookie).客户端浏览器会把cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户状态。服务器还能够根据须要修改Cookie的内容

如何查看某个网站颁发的Cookie:
在这里插入图片描述

  在浏览器地址栏输javascript:alert(document.cookie),或者在浏览器开发者选项console中输入document.cookie就能够看到客户端对应该站点保存的cookie.也能够在开发者工具中的Application菜单中选择Storage下的Cookies(能够看到有多种存储，持久化存储或会话级别存储)查看全部该域下的cookie.
 在开发者工具-Application->Storage->Cookies能够看到不少name/value键值对存储形式,每一个cookie还有Domain、Path、Expires、Size、HTTP、Secure等属性。
 domain和path构成了URL,限制cookie能被哪些URL访问。即请求的URL是Domain或其子域、且URL的路径是Path或子路径，则均可以访问该cookie.Expires说明了cookie的Max Age(cookie的失效日期).Size表示cookie的大小.Sercure是设置cookie只在确保安全的请求中才会发送。当请求是HTTPS或者其余安全协议时，包含Secure选项的cookie才能被发送至服务器(默认下为空).httponly为真，在控制台经过document.cookie是获取不到的，也不能进行修改。假如合法用户的网页收到了xss攻击，有一段恶意的script脚本插到了网页中，这个script脚本，经过document.cookie读取了用户身份验证相关的cookie,那么只要原样转发cookie,就能够达到目的了.(你能够清除全部cookie销毁其做用)

cookie的不可跨域名性:

 cookie具备不可跨域名性。根据cookie规范，浏览器访问Google只会携带Google的cookie,而不会携带Baidu的Cookie.一样Google也只能操做Google的Cookie,而不能操做Baidu的Cookie，从而保证用户的隐私安全

跨域cors中如何传递cookie(前端没法向后端你传递cookie):

没有跨域:
 后端server只要在回应头部‘set-cookie’，那么就会有cookie产生并保存在客户端client。
 等到client再次向后端server发送请求时浏览器的机制就会自动携带cookie随着请求一并发送给后端.


跨域:
 浏览器默认状况下没法主动跨域向后端发送cookie,ajax跨源请求不提供凭据(cookie,HTTP认证及客户端SSL证实等).经过将设置ajax的withCredentials属性设置为true,能够指定某个请求应该发送凭据.若是服务端接受带凭据的请求，会用Access-Control-Allow-Credentials: trueHTTP头部来相应.若是没有设置，则浏览器不会把响应交给js.

等到client再次向后端server发送请求时浏览器的机制就会自动携带cookie随着请求一并发送给后端。

cookie的缺点:

 1. 每一个特定域名下的cookie数量有限,
 2. 存储容量大小只有4KB,因此建议配合LocalStorage/SessionStorage,不要滥用cookie.
 每次HTTP请求都会发送到服务端，影响获取资源的效率.(Request Headers中的Cookie字段传送客户端cookie(Cookie: key1=value1;key2=value2形式))
 一些web框架Django,flask等封装获取、设置、删除cookie的方法.

(3) session认证:
什么是session:

 Session是另外一种记录客户状态的机制，它是在服务端保存的一个数据结构(主要存储的SessionID和Session内容，同时也包含了不少自定义的内容如:用户基础信息、权限信息、用户机构信息、固定变量等)，这个数据能够保存在集群、数据库、文件中，用于跟踪用户的状态。

传统的session认证:

 用户第一次登录后,浏览器会将用户信息发送给服务器，服务器会为该用户建立一个SessionId,并在响应字段Set-Cookie中将该SessionId一并返回给浏览器，浏览器将这些数据保存在本地.当用户再次发送请求时，浏览器会自动的把上次请求存储的cookie数据自动的携带给服务器。服务器接收到请求信息后，会经过浏览器请求的数据中的SessionId判断当前是哪一个用户，而后根据SessionId在Session库中获取用户的Session数据返回给浏览器。(能够保持登陆状态等)

认证过程:
session-cookie

 1. 服务器在接受客户端首次访问时在服务端建立session,而后保存session(咱们能够将sessio保存在内存中,也能够保存在redis中，推荐使用后者),而后给这个session生成一个惟一的标识字符串，而后在响应报文Set-Cookie字段设置这个惟一的标识字符串.
 2. 在服务端签名.这一步只是对sid进行加密处理，服务端会根据这个secret密钥进行解密(非必须步骤)
 3. 浏览器收到请求响应的时候会解析响应头，而后将sid保存在本地cookie中.浏览器在下次http请求的请求头中会带上该域名下的cookie信息
 4. 服务器在接受客户端请求时会去解析请求头cookie中的sid,而后根据这个sid去找服务端保存的该客户端的session,而后判断该请求是否合法.

session-cookie认证的问题:
Session: 每一个用户通过应用认证以后，都要在服务端作一次记录，以方便用户下次请求的鉴别,一般而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大.
扩展性: 用户认证以后，服务端作认证记录，若是认证的记录被保存在内存中的话，这意味着用户下次请求还必需要请求在这台服务器上，这样才能拿到受权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
**CSRF:**由于是基于cookie来进行用户识别的，cookie若是被截获，用户就会很容易受到跨站点请求伪造的攻击

3. token(令牌)认证

(1) 简介：

 HTTP请求都是以无状态的形式对接，因此引入了Session,即服务端和客户端都保存一段文本，客户端每次发起请求都带上cookie,取出相应字段并与服务器端进行对比，以实现身份的认证。这样，致使客户端频繁向服务器发出请求数据，服务端开销大.这种状况下，Token应用而生.
 当先后端分离后，服务端的API设计通常是无状态的，所以不能使用Cookie+Session保持用户的登陆状态.基于token认证机制的应用不须要去考虑用户在那一台服务器登陆，这就为应用的扩展提供了遍历.

(2) Token认证过程:

  1. 客户端使用用户名跟密码请求登陆
  2. 服务端收到请求，去验证用户名与密码
  3. 验证成功后，服务端会签发一个Token(长的十六进制字符串),再把这个Token发送给客户端
  4. 客户端收到Token之后能够把它存储起来，好比放在Cookie里或者Local Storage或内存等介质中.
  5. 客户端每次向服务端请求资源的时候附送(HTTP头部)这个token值
  6. 服务端收到请求，而后去验证客户端请求里面带着的Token,若是验证成功，就向客户端返回请求的数据

(2) Token的优势:

  1. session认证中,sessionid是一个惟一表示的字符串，服务端是根据这个字符串，来查询在服务端保持的session.这里面才保存着用户的登陆状态.可是token自己就是一种登陆成功凭证，它是在登陆成功后根据某种规则生成的一种信息凭证，它里面自己保存着用户的登陆状态，服务端只须要根据定义的规则检验这个token是否合法就行.
  2. session-cookie认证是须要cookie配合的，那么在http代理客户端的选择上只有浏览器.由于只有浏览器才会去解析请求响应头里面的cookie,而后每次请求再默认带上该域名下的cookie.可是咱们知道http代理客户端不仅有浏览器，还有原生APP等等.token就不同，它是在登陆请求成功后再请求响应体中返回的信息，客户端在收到响应的时候，能够把它存在本地cookie,storage,或者内存中,而后在下一次的请求头部带上这个token就好了.
  3. 时效性.token是能够在一段时间内动态改变的.
  4. 能够扩展性.token验证自己是比较灵活的,一是token的解决方案有许多，经常使用的是JWT,二来咱们能够基于token验证机制，专门作一个鉴权服务，用它向多个服务的请求进行统一鉴权.

注：
 CORS(Cross-Origin Resource Sharing)是HTML5规范定义的如何跨域访问资源.Origin表示浏览器当前页面的域,当javascript向外域发起请求后，浏览器收到响应后，首先检查Access-Control-Allow-Origin是否包含本域，若是是，则这次跨域请求成功，若是不是，则请求失败,JavaScript将没法获取到响应的任何数据.
如: 在csdn.net域下访问github网站，响应头中包含Access-Control-Allow-Origin: *
Response headers
 这个token必需要在每次请求时传递给服务端，它应该保存在请求头里，另外服务端要支持CORS(跨域资源共享)策略,通常咱们在服务端设置Access-Control-Allow-Origin: *

(3) SAML和JWT:

简介:

官网文档:
SAML:
 Security Assertion Markup Language (SAML) is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider(xml太复杂了，淘汰了，本身看)
JWT:
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

什么是无状态?:

 微服务集群中的每一个服务(微服务架构),对外提供都是Restful分割的接口.而Rest风格的一个最重要的规范就是:服务的无状态性.

无状态的好处:

 客户端不依赖服务端的信息，任何屡次请求不须要访问到同一台服务
 服务端的集群和状态对客户端透明
 客户端能够任意的迁移和伸缩
 减少服务端存储压力

JWT:

 JWT(Json Web Token)是Auth0提出的经过对JSON进行加密签名来实现受权验证的方案，就是登陆成功后将相关信息组成json对象,而后对这个对象进行某种方式的加密,返回给客户端，客户端在下次请求时带上这个token,服务端再收到请求时校验token合法性.JWT可实现无状态、分布式的Web应用受权

JWT的优势:

  1. 体积小(一串十六进制字符串),于是传输速度快
  2. 传输方式多样. 能够经过HTTP头部(推荐)/URL/POST参数等方式传输
  3. 严谨的结构化.它自身(payload荷载)中就包含了全部与用户相关的验证信息，如用户可访问路由、访问有效期等信息，服务器无需再去链接数据库验证信息的有效性，而且payload支持应用定制
  4. 支持跨域验证，多应于单点登陆.
     单点登陆*Single Sign On): 在多个应用系统中，用户只需登陆一次，就能够访问全部相互信任的应用.

为何选择JWT:
 相比传统的服务端验证，JWT还有如下吸引点.

1, 充分依赖无状态API，契合Restful设计原则(无状态的HTTP)
 无状态是Restful架构设计的一个很是重要的原则。无状态API的每个请求都是独立的，它要求客户端保存全部须要的认证信息，每次发送请求都要带上本身的状态，以url的形式提交包含cookies等状态的数据.
2. 易于实现CDN，将静态资源分布式管理
  JWT依赖的是在客端本地保存验证信息，不须要利用服务器保存的信息来验证，因此任意一台服务器均可以应答，服务器的资源也能被较好地利用.
3. 验证解耦，随处生成
  无需使用特定的身份验证方案，只要拥有生成token所需的验证信息，在任何地方均可以调用相应接口生成token，无需繁琐的耦合的验证操做.
4. 比cookie更支持原生移动端应用
&emsp；原生的移动应用对cookie于session的支持不够好，而对token的方式支持较好(Node.js有express-jwt、koa-jwt等可供选用)

JWT认证构成:
图例:document
JWT
支持的库(我喜欢用Node.js或Python):
Python
Node.js
JWT的构成:
JWT是由三段信息构成的，将这三段信息文本用.连接在一块儿就构成了JWT字符串

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

能够看到是由Header(头部)、Payload(荷载)、Sigature(签证)三部分以.分隔构成

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

Header
Payload
Signature

Header:

 The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
 头部由两部分组成，token类型是JWT,运用的签名算法是 HMAC SHA256

{
  "alg": "HS256",
  "typ": "JWT"
}

而后将头部base64加密(该加密是能够对称解密的),构成了第一部分.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 (注意这里的JSON没有换行符，以下图解码以后没空格换行符.)
可使用在线工具验证: base64解码编码
base64
base64原理
注: 能够看到Header大小是很小的.


Payload:

 The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.
 payload包含三部分,标准中注册的声明、公共的声明、私有的声明


标准中注册的声明 (建议但不强制使用) ：

iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过时时间，这个过时时间必需要大于签发时间
nbf: 定义在什么时间以前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的惟一身份标识，主要用来做为一次性token,从而回避重放攻击。

公共的声明 ：

 公共的声明能够添加任何的信息，通常添加用户的相关信息或其余业务须要的必要信息.但不建议添加敏感信息，由于该部分在客户端可解密.


私有的声明 ：

 私有声明是提供者和消费者所共同定义的声明，通常不建议存放敏感信息，由于base64是对称解密的，意味着该部分信息能够归类为明文信息。

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

而后将其进行base64加密，获得Jwt的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
payload

Signature:

 To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that
 第三部分是一个签证信息，由header(Base64加密)、payload(Base64加密)、secret组成的.

 这个部分须要base64加密后的header和base64加密后的payload使用.链接组成的字符串，而后经过header中声明的加密方式进行加盐secret组合加密，而后就构成了jwt的第三部分。

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

将这三部分用.链接成一个完整的字符串,构成了最终的jwt:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注：

 secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，因此，它就是你服务端的私钥，在任何场景都不该该流露出去。一旦客户端得知这个secret, 那就意味着客户端是能够自我签发jwt了
 不该该在jwt的payload部分存放敏感信息，由于该部分是客户端可解密的部分。

如何应用

In authentication, when the user successfully logs in using their credentials, 
a JSON Web Token will be returned. Since tokens are credentials, great
care must be taken to prevent security issues. In general, you should not 
keep tokens longer than required.

Whenever the user wants to access a protected route or resource, the user
agent should send the JWT, typically in the Authorization header using the
Bearer schema. The content of the header should look like the following:

Authorization: Bearer <token>

通常是在请求头里加入Authorization，并加上Bearer标注：

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

服务端会验证token，若是验证经过就会返回相应的资源。


服务端验证:
服务端接受到token以后，会逆向构造过程,decode出JWT的三个部分.能够获得sign算法以及payload(都是base64加密，至关于明文),结合服务端配置的scecretKey,能够签名与发来的签名对比检查token是否有效，完成用户身份的认证

整个流程就是这样的:
picture

(4） OAuth2.0:

 OAuth2不是一个标准协议，而是一个安全的受权框架。它详细描述了系统中不一样角色、用户、服务前端应用（好比API），以及客户端（好比网站或移动App）之间怎么实现相互认证。
 OAuth 2.0容许第三方网站在用户受权的前提下访问用户在服务商那里存储的各类信息。这种受权无需将用户提供用户名与密码提供给该第三方网站。实际上，OAuth 2.0 容许用户提供一个令牌给第三方网站，一个令牌对应一个特定的第三方网站，同时该令牌只能在特定的时间内访问特定的资源，用户在客户端使用用户名和密码在用户中心得到受权，而后客户端在访问应用是附上 Token 令牌。此时，应用接收到客户端的 Token 令牌到用户中心进行认证。
picture
这里Autho2.0只作简单介绍，有兴趣能够继续学习.

总结：  但愿你们可以对认证有一个比较清晰的认识，谢谢你们.

联系我们 沪ICP备13005482号-10