一、定义

验证用户是否拥有访问系统的权利。

二、作用

用户鉴权:网络对用户进行鉴权,防止非法用户占用网络资源。
网络鉴权:用户对网络进行鉴权,防止用户接入了非法的网络,被骗取关键信息。

三、方式

1、HTTP基本认证 (Basic Authentication):

认证方式:

基本认证和摘要认证。(认证可以理解为对暗号)

基本认证原理:

鉴权 - 图1
客户端:你好服务器,请将我的用户信息发送给我

  1. GET /family/login_info HTTP/1.1

服务器:收到,但是你的登录信息在安全区中,给我暗号(认证)(账号密码)

  1. HTTP/1.1 401 Authorization Required
  2. www-Authenticate: Basic realm= "family"
  3. # Basic:说明需要基本认证
  4. # realm:说明客户端需要输入这个安全区的用户名和密码

客户端:好好好,你要的全都给你

  1. GET /family/son.jpg HTTP/1.1 Authorization: Basic
  2. U2h1c2hlbmcwMDcldUZGMUFzczAwNw==
  3. # Basic 内容为: 用户名:密码 的base64形式 。
  4. # 例如:用户名为LGQ123,密码为123456
  5. # 那么我的Basic的内容为 LGQ123:123456
  6. # :的unicode编码为 %uFF1A
  7. # 对应的base64编码内容TEdRMTIzJXVGRjFBMTIzNDU2ICA=

在线加密解密
服务端:暗号对了,东西传给你了

  1. HTTP/1.1 200 OK Content-type: .....

缺点:

在传输过程中没有加密,账号密码均为明文传输

2、session-cookie

定义
  1. cookie/cookies
  2. 在客户端存储数据,用于在多个网页/接口间共享数据
  3. 网页中“记住账号和密码”,很多都是使用了cookie
  4. session(会话)
  5. 在服务器存储数据,用于在多个网页/接口间共享数据
  6. 登录之后,一直保持在线状态,很多时候使用了session
  7. cookiesession也可以混合使用

举例说明:该小票中所有的选菜信息为cookie缓存,订单单号为session
image.pngimage.png

获取cookies:
  1. import requests
  2. session = requests.session()
  3. # province省份,creditcode统一社会信用代码,company市场主体(企业名字),cpmc地理标志(特产),
  4. url_search = 'https://dlbzsl.hizhuanli.cn:8888/Logo/Result?cpmc=' + '五常大米' + '&company=&creditcode='
  5. cookies = session.get(url_search).cookies.get_dict()
  6. cookie = 'ASP.NET_SessionId' + '=' + cookies['ASP.NET_SessionId']
  7. print(cookies) # {'ASP.NET_SessionId': 'xaj5ijc2m2fuwxxiujj2evoa'}
  8. print(cookie) # ASP.NET_SessionId=xaj5ijc2m2fuwxxiujj2evoa

获取session:
  1. import requests
  2. url = 'https://mail.163.com/'
  3. login_email = 'lgq2261041@163.com'
  4. login_password = '保密'
  5. # 创建session,自动保存cookie
  6. session = requests.session()
  7. data = {
  8. 'login_email': login_email,
  9. 'login_password': login_password
  10. }
  11. # 使用session发起post请求来获取登录后的cookie,cookie已经存在session中
  12. response = session.post(url=url, data=data)
  13. # 用session给个人主页发送请求,因为session中已经有cookie了
  14. index_url = 'https://mail.163.com/js6/main.jsp?sid=CCDPtSSKtUKAtkAhneKKhUVokRJgFcIK&df=mail163_letter#module=welcome.WelcomeModule%7C%7B%7D'
  15. index_page = session.get(url=index_url).text
  16. print(index_page)
  17. # 输出
  18. # <!doctype html><html lang="zh-cmn-Hans"><head>
  19. # <script id="serviceworker">
  20. # !function(){try{"serviceWorker"in navigator&&(navigator.serviceWorker.register("./sw.js",{}).then(function(e){console.log("serviceWorker registered")}).catch(function(e){console.log("serviceWorker register",e)}),addEventListener("error",function(r){if(r.target&&"preload"!==r.target.rel&&"prefetch"!==r.target.rel&......省略.....></script></body></html>

缺点:

cookies安全性低,入侵者可获取本地的cookies来模拟用户登录
cookies在多个域名下,会存在跨域问题
session的信息是保存在服务端上面的,当我们node.js在stke部署多台机器的时候,需要解决共享
session的时效性低

3、Token

定义:

服务器生成的字符串,用户请求的暗号
image.png

4、OAuth(开放授权)

定义:

OAUTH开放授权为用户资源的授权提供了一个安全的、开放而又简易的标准。OAUTH的授权不会使第三方触及到用户的帐号信息例如用户名与密码等,即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH授权是安全的,目前OAUTH的版本为2.0。

基本流程
  1. - 用户打开应用程序,应用程序要求用户给予授权。
  2. - 用户在服务提供商网站允许授权,返回应用程序授权信息。
  3. - 应用程序使用获得的授权,向认证服务器请求令牌Token
  4. - 认证服务器对于应用程序的授权码等信息进行确认,认证无误后发放令牌。
  5. - 应用程序使用令牌向资源服务器请求资源。
  6. - 资源服务器确认令牌无误后,同意向应用程序开放资源。

客户端授权模式

在基本流程的第二步应用程序需要获取用户的授权信息,进而才能获取令牌,OAuth 2.0定义了四种授权方式。

授权码模式

授权码模式authorization code是功能最完整、流程最严密的授权模式,也是最常用的授权模式,它的特点就是通过客户端的后台服务器与服务提供商的认证服务器进行互动,避免了令牌Token在前端传输,前端只传递一个授权码,而授权码需要结合Appid与AppSecret等信息在后端与认证服务器交换令牌Token,而AppSecret此类数据需要严格保密,所以仅由CODE不能直接获取到令牌,授权码模式安全性非常高。

  1. - 用户打开应用程序,点击第三方授权按钮,此时需要传递应用程序的APPID以及授权后跳转的URL地址,页面跳转到授权网站,或者打开一个新的窗口到授权网站,本例主要是以跳转到授权网站为例,但基本流程相同。
  2. - 用户在授权网站点击授权按钮,此时浏览器跳转到上一部传递的URL地址并且携带授权码CODE信息,这个授权码信息一般有效期比较短,一般为10分钟。
  3. - 应用程序收到授权码,将授权码CODE发送到后端,后端根据授权码CODE以及AppidAppSecret等信息在后端对认证服务器发起请求。
  4. - 认证服务器检查请求的数据是否正确,检查正确后返回令牌Token
  5. - 应用程序使用令牌向资源服务器请求资源,资源服务器确认令牌无误后,同意向应用程序开放资源。

简化模式

简化模式implicit grant type不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了授权码这个步骤。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证。

  1. - 用户打开应用程序,点击第三方授权按钮,此时需要传递应用程序的APPID以及授权后跳转的URL地址,页面跳转到授权网站,或者打开一个新的窗口到授权网站,本例主要是以跳转到授权网站为例,但基本流程相同。
  2. - 用户在授权网站点击授权按钮,此时浏览器跳转到上一部传递的URL地址并且携带一个HASH信息,其中包含了令牌。
  3. - 浏览器向资源服务器发起请求,此时不携带上一步请求的HASH信息,资源服务器返回一个解析脚本。
  4. - 浏览器解析上一步获取的脚本,然后通过脚本解析出HASH中的令牌,此时应用程序获取了令牌。
  5. - 应用程序使用令牌向资源服务器请求资源,资源服务器确认令牌无误后,同意向应用程序开放资源。

密码模式

密码模式Resource Owner Password Credentials Grant中,用户向客户端提供自己的用户名和密码,客户端使用这些信息,向服务商提供商索要授权。在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码,这通常用在用户对客户端高度信任的情况下,比如客户端是操作系统的一部分,而认证服务器只有在其他授权模式无法执行的情况下,才能考虑使用这种模式。

  1. - 用户向应用程序提供用户名与密码,应用程序使用账号与密码发给认证服务器,请求令牌。
  2. - 认证服务器确认信息无误后,返回令牌给应用程序。
  3. - 应用程序使用令牌向资源服务器请求资源,资源服务器确认令牌无误后,同意向应用程序开放资源。

客户端模式

客户端模式Client Credentials Grant指客户端以自己的名义,而不是以用户的名义,向服务提供商进行认证。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求服务提供商提供服务,严格来说这种模式其实并不存在授权问题。

  1. - 用户在应用程序中注册身份,应用程序向认证服务器进行[身份认证](https://cloud.tencent.com/solution/tb-digitalid?from=10680)并请求令牌。
  2. - 认证服务器确认身份无误后,返回令牌给应用程序。
  3. - 应用程序使用令牌向资源服务器请求资源,资源服务器确认令牌无误后,同意向应用程序开放资源。