zoukankan      html  css  js  c++  java
  • OAuth2.0的原理介绍

    OAuth2.0是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版。

    • OAuth2.0(开放授权)是一个正式的互联网标准协议。
    • 允许第三方网站在用户授权的前提下访问在用户在服务商那里存储的各种信息。而这种授权无需将用户提供用户名和密码提供绐该第三方网站。
    • OAuth2.0允许用户提供一个令牌绐第三方网站,一个令牌对应一个特定的第三方网站,同时该令牌只能在特定的时间内访问特定的资源。

    1. 授权码模式(authorization code)
    2. 简化模式 (implicit)
    3. 密码模式(resource owner password credentials)
    4. 客户端模式(client credentials)
    • 授杈码模式是功能最完整、流程最严密的授权模式
    • 简化模式不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了''授权码"这个步骤
    • 密码模式需要用户向客户端提供自己的用户名和密码
    • 客户端模式指客户端以自己的名义,而不是以用户的名义,向''服务提供商"进行认证

    授权码模式详解

     实现OAuth2.0协议中的必选方法

    • 实现重定向的机制
    • 实现授权码的机制
    • 实现token发放的机制

     简介:OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用(典型:第三方登录),目前的版本是2.0版。
    没有OAuth的时代:
    假设我们有这么一个场景:有三个角色,分别是“用户”,“第三方应用”,“服务提供商,比如google”
    用户有很多照片都存放在google服务器,这时候,用户需要借助第三方应用“云冲印”,将存放在google服务器的照片打印出来,那么此时我们正处于没有OAuth的时代,这时候,用户登录第三方应用“云冲印”之后,就得需要将用户在google的帐号和密码提供给“云冲印”,这时候“云冲印”拿着用户提供的google帐号和密码,登录到google服务器,再而获取用户的照片,接着后续的打印工作。
    那么上面是一个模拟的场景,在没有OAuth的时代,我们也只能这么做,那么会导致什么样的问题发生,缺陷如下:

    严重缺点: 

    (1)云冲印完全保存用户密码,导致用户的google帐号不安全; 

    (2)客户端获取用户存储在google服务器的所有资料,用户没法限制第三方应用“云冲印”的授权范围和有效期; 

    (3)用户只有修改密码,才能收回赋予第三方应用“云冲印”的权利; 

    (4)最为严重:“云冲印”站点遭遇攻击,用户密码泄露,意味着用户在google的信息泄露;

    基于以上几个缺陷,OAuth诞生了。
    OAuth作用:就是让"客户端(第三方应用:上文的云冲印)安全可控地获取"用户"的授权,与"服务提供商"进行互动。
    目前OAuth有三个版本:OAuth1.0,OAuth1.0a,OAuth2.0
    OAuth1.0

    用一副图来解释OAuth1.0的整个运行流程如图1所示:


     图1:OAuth1.0流程图

    这是相关“雅虎”站点进行OAuth认证的整个运行流程:
    参与者:Application,YAHOO!,User
    (1)客户端在自己站点实现YAHOO!的第三方认证之前,需要到YAHOO!服务提供商申请帐号Consumer Key,YAHOO!通过申请之后,并发放Consumer Key已经对应的Consumer Secret的一套认证帐号,这时候说明该客户端已经加入了YAHOO服务提供商的认证服务。
    (2)获取Request Token,需要传递参数:
              oauth_consumer_key:应用ID
              oauth_nonce:客户端生成的随机数
              oauth_signature_method:签名方式(目前有:HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种
              oauth_timestamp:时间戳
              oauth_version:OAuth版本号
              xoauth_lang_pref(optional):
              oauth_callback:
         YAHOO!验证用户参数合法,通过验证,同意发放Request_Token,返回客户端参数:
              oauth_token:请求令牌
              oauth_token_secret:令牌对应的密钥
              oauth_expires_in:令牌过期时间
              xoauth_request_auth_url:
              oauth_callback_confirmed=true
    (3)客户端接收到Request_Token,此时将用户导向YAHOO!认证页面,并传递参数:Request_Token
              oauth_token:请求令牌
              此时服务提供商接下来“询问用户是否给予授权”,用户同意授权,服务提供商将用户重定向客户端事先传递的oauth_callback(重定向URI)地址,并以GET方式传递授权码(oauth_verifier)
    (4)客户端使用Request_Token以及OAuth_Verifier向服务提供商交换Access_Token:传递参数:
              oauth_consumer_key:应用ID          
              oauth_signature_method:签名方式(目前有:HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种
              oauth_signature:签名(注意,这一步骤用到了签名,OAuth签名的生成,详看服务提供商OAuth签名生成文档,此处提供金山快盘签名生成
              oauth_timestamp:时间戳
              oauth_version:OAuth版本号
              oauth_token:Request_Token请求令牌
              oauth_nonce:客户端生成的随机数
              oauth_verifier:授权码
          服务提供商确认签名匹配,参数准确无误,授予Access_Token以及Access_Secret,返回客户端参数:
              oauth_token:Access_Token访问令牌
              oauth_token_secret:令牌对应密钥
              oauth_session_handle:用于刷新过期访问令牌
              oauth_expires_in:令牌过期时间

    (5)令牌过期,重新刷新令牌
              与(4)区别唯一参数:oauth_session_handle,不需要传递授权码:oauth_verifier,YAHOO!重新返回Access_Token以及密钥Access_Token_Secret
         注意:这里的oauth_timestamp和oauth_nonce是为防止重放攻击而设置的。具体的来讲:请求者不能在一段时间(服务器允许的客户端和服务端的时间差)内发送同样的请求两次或以上,如果在这个时间段之后再次发生这个请求,则会因为超出服务端允许的时间差而被拒绝。
    2009 年 4 月 23 日, OAuth 宣告了一个 1.0 协议的安全漏洞。该漏洞影响了 OAuth 1.0 核心规范第 6 节的OAuth 的认证流程(也称作 3 阶段 OAuth ), OAuth Core 协议 1.0a 版本解决了这一问题。
    OAuth 1.0可能发布地太快了,因此广受批评。之后很快就出现了与之竞争的WRAP(Web资源授权协议),它很快地进行了标准化,成为OAuth的对手。从那时开始,OAuth工作小组就开始着手创建OAuth 2.0。
    OAuth2.0:

    腾讯,百度,新浪等开放平台都广泛使用了OAuth2.0

    关于OAuth2.0的术语:
    (1) Third-party application:第三方应用程序,又称”客户端”(client); 

    (2)HTTP service:HTTP服务提供商,简称”服务提供商”,; 

    (3)Resource Owner:资源所有者,又称”用户"(user); 

    (4)User Agent:用户代理,指浏览器; 

    (5)Authorization server:认证服务器,服务提供商专门用来处理认证的服务器; 

    (6)Resource server:资源服务器,服务提供商存放用户资源的服务器。它与认证服务器可以是同一台服务器,也可以是不同的服务器;

    运行流程: (如下图2所示)

    (A)用户打开客户端以后,客户端要求用户给予授权。 

    (B)用户同意给予客户端授权。 

    (C)客户端使用上一步获得的授权,向认证服务器申请令牌。 

    (D)认证服务器对客户端进行认证以后,确认无误,同意发放令牌。 

    (E)客户端使用令牌,向资源服务器申请获取资源。 

    (F)资源服务器确认令牌无误,同意向客户端开放资源。


    图2:OAuth2.0运行简易流程

    B(授权)为最关键的步骤!
    客户端的授权模式(4种): 

    (1)授权码模式(authorization code) 

    (2)简化模式(implicit) 

    (3)密码模式(resource owner password credentials) 

    (4)客户端模式(client credentials)
    其中:
    授权码模式(authorization code)是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与"服务提供商"的认证服务器进行互动。
    当然,并不是所有人对OAuth2.0都投赞成票,有兴趣可以看看:OAuth 2.0对Web有害吗?

    关于OAuth1.0和2.0的相关区别小结:

     (1)1.0每次请求都需要签名,2.0更简洁,不需要签名了

     (2)1.0:Request_Token->Authorization_Code; Authorization_Code->Access_Token 2.0:Authorization_Code->Access_Token

     (3)1.0每个token都需要加密,2.0则不需要,这样不就不安全了,但是2.0要求使用https(是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议。如果不是登陆到一些帐户和密码时,没什么用,只有需要登陆密码时这样候它的作用就非常大了。)协议,安全性更高一筹 

     (4)2.0有4种授权模式,1.0只有1种

  • 相关阅读:
    C​S​S3​:​transition与visibility
    CSS ::before 和 ::after 伪元素 进阶
    [转]达梦数据库报错:不能同时包含聚集KEY和大字段(text类型)
    [转].netcore webapi post参数长度超过最大限制
    efcore执行sql查询(无需定义dbset<model>)
    Rabbitmq的死信
    用Docker搭建RabbitMq的普通集群和镜像集群
    .NetCore在IdentityServer4因为Cookies的SameSite导致授权登录跳转回登录页的问题
    2021>2022
    js 宽高相关及其应用
  • 原文地址:https://www.cnblogs.com/Chary/p/9760316.html
Copyright © 2011-2022 走看看