4种常见的鉴权方式及说明

一、什么是鉴权

鉴权(authentication)是指验证用户是否拥有访问系统的权利。传统的鉴权是通过密码来验证的。这种方式的前提是,每个获得密码的用户都已经被授权。在建立用户时,就为此用户分配一个密码,用户的密码可以由管理员指定,也可以由用户自行申请。这种方式的弱点十分明显:一旦密码被偷或用户遗失密码,情况就会十分麻烦,需要管理员对用户密码进行重新修改,而修改密码之前还要人工验证用户的合法身份。

为了克服这种鉴权方式的缺点,需要一个更加可靠的鉴权方式。目前的主流鉴权方式是利用认证授权来验证数字签名的正确与否。

逻辑上,授权发生在鉴权之后,而实际上,这两者常常是一个过程。

二、 鉴权分类

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

这种双向的认证机制,就是AKA(Authentication and Key Agreement,鉴权和密钥协商)鉴权。

除了AKA鉴权,也可以使用其它鉴权方式。在IMS AKA鉴权广泛实施之前,或在特定的条件下(例如通过固定网络ADSL连接方式接入IMS),可以使用HTTP摘要鉴权等其他鉴权方式。

3G UMTS(Universal Mobile Telecommunication System,通用移动通讯系统)、EPS(Evolved Packet System,演进的分组系统)、IMS(IP Multimedia Subsystem,IP多媒体子系统)网络都采用了AKA双向鉴权机制,鉴权原理也大致相同。而2G网络,只有用户鉴权,无网络鉴权。

三、鉴权时机

移动网络对鉴权时机的要求为:

  • 2G、3G网络中,鉴权发生在开机、呼叫、位置更新以及在补充业务的激活、去活、登记或删除操作之前。
  • 2G网络中,运营商都是启用的“按比例鉴权”方案。
  • 3G网络中,用户首次接入网络必须鉴权,此后启用“按比例鉴权”方案。
  • IMS网络中,网络可以通过注册或重注册过程,在任何时候对用户进行鉴权。

四、鉴权方式

我们常用的鉴权有四种:

1、HTTP Basic Authentication

2、session-cookie

3、Token 验证

4、OAuth(开放授权)

4.1 HTTP Basic Authentication

这种授权方式是浏览器遵守http协议实现的基本授权方式,HTTP协议进行通信的过程中,HTTP协议定义了基本认证认证允许HTTP服务器对客户端进行用户身份证的方法。

认证过程:

1. 客户端向服务器请求数据,请求的内容可能是一个网页或者是一个ajax异步请求,此时,假设客户端尚未被验证,则客户端提供如下请求至服务器:

Get /index.html HTTP/1.0
Host:www.google.com

2. 服务器向客户端发送验证请求代码401,(WWW-Authenticate: Basic realm=”google.com”这句话是关键,如果没有客户端不会弹出用户名和密码输入界面)服务器返回的数据大抵如下:

HTTP/1.0 401 Unauthorised
Server: SokEvo/1.0
WWW-Authenticate: Basic realm=”google.com”
Content-Type: text/html
Content-Length: xxx

3. 当符合http1.0或1.1规范的客户端(如IE,FIREFOX)收到401返回值时,将自动弹出一个登录窗口,要求用户输入用户名和密码。

4. 用户输入用户名和密码后,将用户名及密码以BASE64加密方式加密,并将密文放入前一条请求信息中,则客户端发送的第一条请求信息则变成如下内容:

Get /index.html HTTP/1.0
Host:www.google.com
Authorization: Basic d2FuZzp3YW5n

注:d2FuZzp3YW5n表示加密后的用户名及密码(用户名:密码 然后通过base64加密,加密过程是浏览器默认的行为,不需要我们人为加密,我们只需要输入用户名密码即可)

5. 服务器收到上述请求信息后,将Authorization字段后的用户信息取出、解密,将解密后的用户名及密码与用户数据库进行比较验证,如用户名及密码正确,服务器则根据请求,将所请求资源发送给客户端。

效果:
客户端未未认证的时候,会弹出用户名密码输入框,这个时候请求时属于pending状态,这个时候其实服务当用户输入用户名密码的时候客户端会再次发送带Authentication头的请求。

4.2 session-cookie

HTTP Cookie(也叫Web Cookie或浏览器Cookie)是服务器发送到用户浏览器并保存在本地的一小块数据,它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常,它用于告知服务端两个请求是否来自同一浏览器,如保持用户的登录状态。Cookie使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

Cookie主要用于以下三个方面:

  • 会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
  • 个性化设置(如用户自定义设置、主题等)
  • 浏览器行为跟踪(如跟踪分析用户行为等)

认证过程

  1. 服务器在接受客户端首次访问时在服务器端创建seesion,然后保存seesion(我们可以将seesion保存在内存中,也可以保存在redis中,推荐使用后者),然后给这个session生成一个唯一的标识字符串,然后在响应头中种下这个唯一标识字符串。

  2. 签名。这一步只是对sid进行加密处理,服务端会根据这个secret密钥进行解密。(非必需步骤)

  3. 浏览器中收到请求响应的时候会解析响应头,然后将sid保存在本地cookie中,浏览器在下次http请求de 请求头中会带上该域名下的cookie信息。

  4. 服务器在接受客户端请求时会去解析请求头cookie中的sid,然后根据这个sid去找服务器端保存的该客户端的session,然后判断该请求是否合法。

  5. 一旦用户登出,服务端和客户端同时销毁该会话在后续请求中,服务器会根据数据库验证会话id,如果验证通过,则继续处理;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NEyuKS3h-1578623143129)(/Users/mxj/百度云同步盘/学习笔记/前端全栈/网络及工具/img/image-20200110092849020.png)]

4.3 Token 验证

认证过程

  1. 用户输入登陆凭据;
  2. 服务器验证凭据是否正确,然后返回一个经过签名的token;
  3. 客户端负责存储token,可以存在localstorage,或者cookie中
  4. 对服务器的请求带上这个token;
  5. 服务器对JWT进行解码,如果token有效,则处理该请求;
  6. 一旦用户登出,客户端销毁token。

cookie与taken看上去很像,那么他们到底有什么区别呢?

cookie与taken性能对比

  1. sessionid 他只是一个唯一标识的字符串,服务端是根据这个字符串,来查询在服务器端保持的seesion,这里面才保存着用户的登陆状态。但是token本身就是一种登陆成功凭证,他是在登陆成功后根据某种规则生成的一种信息凭证,他里面本身就保存着用户的登陆状态。服务器端只需要根据定义的规则校验这个token是否合法就行。
  2. session-cookie是需要cookie配合的,居然要cookie,那么在http代理客户端的选择上就是只有浏览器了,因为只有浏览器才会去解析请求响应头里面的cookie,然后每次请求再默认带上该域名下的cookie。但是我们知道http代理客户端不只有浏览器,还有原生APP等等,这个时候cookie是不起作用的,或者浏览器端是可以禁止cookie的,但是token就不一样,他是登陆请求在登陆成功后再请求响应体中返回的信息,客户端在收到响应的时候,可以把他存在本地的cookie,storage,或者内存中,然后再下一次请求的请求头重带上这个token就行了。简单点来说cookie-session机制他限制了客户端的类型,而token验证机制丰富了客户端类型。
  3. 时效性。session-cookie的sessionid实在登陆的时候生成的而且在登出事时一直不变的,在一定程度上安全就会低,而token是可以在一段时间内动态改变的。
  4. 可扩展性。token验证本身是比较灵活的,一是token的解决方案有许多,常用的是JWT,二来我们可以基于token验证机制,专门做一个鉴权服务,用它向多个服务的请求进行统一鉴权。

4.4 OAuth(开放授权)

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH是安全的。同时,任何第三方都可以使用OAUTH认证服务,任何服务提供商都可以实现自身的OAUTH认证服务,因而OAUTH是开放的。

我们常见的提供OAuth认证服务的厂商有支付宝,QQ,微信。

OAuth协议又有1.0和2.0两个版本。相比较1.0版,2.0版整个授权验证流程更简单更安全,也是目前最主要的用户身份验证和授权方式。

典型案例

果一个用户拥有两项服务:一项服务是图片在线存储服务A,另一个是图片在线打印服务B。由于服务A与服务B是由两家不同的服务提供商提供的,所以用户在这两家服务提供商的网站上各自注册了用户,假设这两个用户名各不相同,密码也各不相同。

当用户要使用服务B打印存储在服务A上的图片时,用户该如何处理?

方法一:用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印,这种方式安全但处理比较繁琐,效率低下;

方法二:用户将在服务A上注册的用户名与密码提供给服务B,服务B使用用户的帐号再去服务A处下载待打印的图片,这种方式效率是提高了,但是安全性大大降低了,服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。

方法三:当服务B(打印服务)要访问用户的服务A(图片服务)时,通过OAUTH机制,服务B向服务A请求未经用户授权的RequestToken后,服务A将引导用户在服务A的网站上登录,并询问用户是否将图片服务授权给服务B。用户同意后,服务B就可以访问用户在服务A上的图片服务。整个过程服务B没有触及到用户在服务A的帐号信息。

OAuth相关术语

在认证和授权的过程中涉及的三方包括:

服务提供方(ServiceProvider),用户使用服务提供方来存储受保护的资源,如照片,视频,联系人列表。

用户(User),存放在服务提供方的受保护的资源的拥有者

客户端(Consumer),要访问服务提供方资源的第三方应用,通常是网站,如提供照片打印服务的网站也可以是桌面或移动应用程序。在认证过程之前,客户端要向服务提供者申请客户端标识。

OAuth相关的三个URL:

RequestToken URL:获取未授权的RequestToken服务地址;

UserAuthorization URL:获取用户授权的RequestToken服务地址;

AccessToken URL:用授权的RequestToken换取AccessToken的服务地址。

OAuth认证和授权过程

  1. 客户端(第三方软件)向OAUTH服务提供商请求未授权的RequestToken。即向RequestToken URL发起请求;
  2. OAUTH服务提供商同意使用者的请求,并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret,并返回给使用者;
  3. 使用者向OAUTH服务提供商请求用户授权的RequestToken。即向UserAuthorization URL发起请求并在请求中携带上一步服务提供商颁发的未授权的token与其密钥;
  4. OAUTH服务提供商通过网页要求用户登录并引导用户完成授权;
  5. RequestToken授权后,使用者将向AccessToken URL发起请求,将上步授权的RequestToken换取成AccessToken。请求的参数见上图,这个比第一步多了一个参数就是RequestToken;
  6. OAUTH服务提供商同意使用者的请求,并向其颁发AccessToken与对应的密钥,并返回给使用者;
  7. 使用者以后就可以使用上步返回的AccessToken访问用户授权的资源。

简单整理就三个步骤

  1. 获取未授权的RequestToken
  2. 获取用户授权的RequestToken
  3. 用授权的RequestToken换取AccessToken
  • 49
    点赞
  • 285
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
### 回答1: 详细设计说明书是软件开发过程中的重要文档之一,它是从概要设计说明书中继承下来的,主要包括系统的结构、组成、模块的具体实现、关注点等内容,是实现系统的重要依据。 首先,详细设计说明书需要明确系统的结构和组成,如系统的层次结构、模块的划分等,并对各个模块之间的关系、相互调用关系进行详细说明。此外,还需要对系统的运行环境、实现和使用的技术、所需资源等进行详细阐述,以确保系统的稳定性和可靠性。 接着,详细设计说明书需要对每个模块进行具体实现的说明,包括模块的接口、实现方法、算法、数据结构等,以及对异常情况的处理方法和日志记录等细节进行说明,以保证系统的高效性、可维护性和可扩展性。 最后,详细设计说明书需要关注一些关键技术和功能实现,如安全措施、性能优化、数据备份恢复等,对这些功能进行详细的技术说明和设计思路,以确保系统的安全性和可用性。 总之,详细设计说明书是确保软件开发过程中系统实现和维护的关键文档,对软件开发过程中的设计实现和功能实现提供重要支持和保障。 ### 回答2: 详细设计说明书是软件开发过程中的一个重要文档,它通常用来描述软件系统的结构、功能、算法、模块、接口等方面的细节信息,以便开发人员按照设计完成代码实现。在csdn上,详细设计说明书也是一常见的软件开发文档,经常出现在各技术博客和论坛上。 一份优秀的详细设计说明书应当包括以下要素: 1. 系统概述:对该软件系统的高层次概述,包括系统的目标、用户需求、技术架构、开发环境等。 2. 功能模块:对系统各个重要功能模块的设计方案进行详细描述,包括模块的输入输出、业务逻辑、数据结构和算法等。 3. 数据模型:对系统中涉及到的数据模型进行详细设计,包括数据结构、数据流向、敏感信息保护等。 4. 接口设计:对系统内部和外部接口进行规划和设计,包括协议、数据格式、接入方式、认证鉴权等。 5. 性能优化:通过对系统设计的各个环节进行优化,提高系统性能表现,包括时间复杂度、内存占用、磁盘IO读写等。 6. 安全保障:对系统安全性进行考虑和规划,包括数据加密、权限控制、访问日志、漏洞修复等。 总之,详细设计说明书是研发团队进行软件开发时的重要文档之一。一份好的详细设计说明书应当能够清晰明确地描述系统的各个方面,有利于团队成员之间的合作,提高开发效率和软件质量。 ### 回答3: 详细设计说明书是一重要的文档,用于描述软件系统的详细设计。它详尽地描述了系统的各个模块、数据结构、算法、界面和逻辑流程等。CSND是一个专业的技术社区,它提供了很多关于详细设计说明书的范例和教程,下面是一些主要的要点: 1. 详细设计说明书必须清楚地表达系统设计的目标和需求,包括用户需求、功能需求、性能要求、系统约束和系统安全等。 2. 详细设计说明书应该包含系统的整体架构和各个模块之间的关系,具体包括模块的接口、输入输出等等。 3. 数据结构和算法是系统设计的核心,详细设计说明书应该详细描述系统所使用的数据结构和算法,包括它们的作用、设计思路和实现方法。 4. 界面设计也是一个重要的部分,详细设计说明书应该包括界面设计的原则和规范,界面元素的功能和布局等。 5. 详细设计说明书应该清楚地描述系统的逻辑流程和业务流程,包括工作流、状态流和数据流等。 6. 最后,详细设计说明书应该包括测试计划和测试方法,以确保系统能够满足用户需求和性能要求。 总之,详细设计说明书是软件开发过程中不可或缺的一部分,它对软件的开发、测试和维护都有重要作用。对于开发者来说,编写详细设计说明书能够帮助他们更好地理解需求和系统设计,同时也有助于团队协作,提高软件开发效率和质量。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

代码搬运媛

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值