关于web:OAuth每次授权暗中保护你的那个MAN

43次阅读

共计 5777 个字符，预计需要花费 15 分钟才能阅读完成。

摘要 ：OAuth 是一种受权协定，容许用户在不将账号口令泄露给第三方利用的前提下，使第三方利用能够取得用户在某个 web 服务上寄存资源的拜访权限。

背景

在传统模式下，用户的客户端在拜访某个 web 服务提供的具备肯定拜访限度的资源时，须要提供用于进行身份认证的凭证（credential），例如明码，accesskey 等。如果存在第三方的利用须要该 web 服务上用户的资源，用户必须将本人的凭证共享给第三方利用，这种实际带来了一些问题：

  1. 第三方利用须要寄存用户的凭证，且必须拿到明文（例如应用用户名和明码近程调用 web 服务的 API），如果第三方利用被攻打，用户的凭证可能被泄露。
  2. 无奈限度第三方利用的权限。第三方利用拿到用户凭证明文后，等于拿到了用户的所有权限，且用户无奈对第三方利用在什么工夫拜访哪些资源进行限度，可能被越权。
  3. 用户无奈回收对某个第三方利用的受权，除非更改明码。更改明码可能导致依赖该明码的其余第三方利用无法访问。
  4. 用户资源的安全性取决于安全性最弱的第三方利用（木桶实践），任何一个第三方利用被攻打，都可能导致用户的身份凭证泄露，以及寄存在 web 服务上的资源被攻打。

基本原理

OAuth 是一种受权协定，容许用户在不将账号口令泄露给第三方利用的前提下，使第三方利用能够取得用户在某个 web 服务上寄存资源的拜访权限。

例如下图，通过华为账号登录腾讯新闻利用时，并不需要将账号口令提供给腾讯新闻利用，用户只有领有华为账号，只须要微微点击一下受权就能够无缝拜访，在保障平安和隐衷的同时带来体验上质的飞跃，体验晋升的继续谋求使得 OAuth 协定在互联网失去了十分宽泛的利用。

OAuth 通过引入 authorization server 的概念，并对受权拜访过程中的几个参与方进行从新定义和角色解耦。

下面是一个十分十分形象的流程图，仅仅为了厘清 OAuth 交互过程中存在哪些角色及承当的职责，实际上具体利用过程中的差别十分大。从上图大略能够看出，OAuth 协定交互过程中存在四种角色：

  • resource owner

须要拜访资源的主体，能够是人，也能够是物，指代人的时候就是咱们通常说的 end-user。

  • resource server

寄存受爱护资源的 web 服务，接管资源的拜访申请并响应，resource server 对申请进行鉴权。例如用户寄存照片的华为终端云服务。

  • client

用来代理 resource owner 申请资源的应用程序，client 拜访资源须要失去 resource owner 的受权。例如照片美图 APP，须要拉取用户寄存在云服务上的照片。

  • authorization server

对 resource owner 进行身份认证和鉴权，并颁发拜访凭证。例如华为账号认证服务。

其余阐明

  1. OAuth 协定以后曾经倒退到 0 版本。1.0 版本曾经废除，且 OAuth2.0 并不能后向兼容 1.0。
  2. OAuth 协定罕用于 web 拜访，基于 HTTP 协定。实际上，OAuth 只是定义了一种流程，以及该流程中各方的角色定义和性能职责，并不限于 HTTP 这一种传输通道。
  3. 下面的流程图中并没有介绍 resource server 和 authorization server 之间的交互，它们可能承载在同一个 web 服务中，也可能由不同的独立 web 服务承载。当 resource server 和 authorization server 各自独立时，正是因为 OAuth 协定没有定义其交互过程，导致 OAuth 协定在产品标准化和工程化中呈现艰难，前面会缓缓介绍。

OAuth：受权流程

接下来咱们探讨一下，获取受权和获取 token 的几种模式，利用场景，交互过程以及 API 的定义。

分类

筹备工作

在开始 OAuth2.0 的受权流程前，利用的开发者须要将利用的信息注册到 authorization server，例如华为账号服务、百度开发者核心这些出名的开放平台，注册胜利后失去最重要的两个参数：client_id 和 client_secret，这两个参数在前面介绍的简直每种受权流程都会频繁应用。

如下图华为终端开发者联盟管理中心注册界面：

开发者进行利用注册时，个别须要提交利用类型。利用类型常见的几大类：

对于 web application，开发者还须要提交 redirect URI，即 web application 接管 grant code 的地址，authorization server 在认证实现后重定向到此地址。

受权码流程

受权码流程是 oauth2.0 最常见的交互流程，甚至很多开放平台仅反对这一种流程。受权码流程示意见下图：

该流程次要实用于 web 利用，基于浏览器的重定向能力实现整个交互过程。

谬误返回

当 resource-owner 回绝 client 的拜访申请，或者受权申请谬误，authorization server 将错误信息通过 redirect_uri 返回给 client 利用，除非 redirect_uri 自身就不正确。

参数

阐明，所有参数需通过“application/x-www-form-urlencoded”编码。

隐式受权（Implicit Grant）

如下面介绍，隐式受权实用于代码运行在客户端上的利用，例如网页利用，利用浏览器的重定向能力失去 resource-owner 的受权。不同于受权码流程，隐式受权流程的受权申请能够间接失去 access token，没有 authorization code 的两头过程。隐式受权过程产生在 resource owner 的设施上，必须有 resource owner 在场，且 client 代码不能蕴含 client 的凭证（client_secret），另外 access_token 返回给 client 时，存在裸露到同一个设施（user-agent）上其余利用的危险。

身份信息透传受权（Resource Owner Password Credentials Grant）

如果 resource owner 十分信赖这个利用，能够将身份凭证（口令，密钥等）通过利用传递到 authorization server。个别不举荐这种形式，利用能够截留用户的身份凭证明文，危险较高，RFC 协定也仅倡议用于存量的利用迁徙到 OAuth 协定。集体认为，如果 client 自身就是 authorization server，其身份验证过程这样做也是可行的，相当于 authorization server 的外部实现。

客户端凭证间接受权（Client Credentials Grant）

利用拿着 client_id 和 client_secret 间接从 authorization server 获取 access token，这种流程仅用于拜访利用自身的与 resource owner 无关的数据，不须要 resource owner 受权的场景，能够应用这种受权，个别都是机机接口调用。

扩大利用

不同厂商的开放平台能够扩大受权流程，以满足不能场景的需要，例如手机、平板等端侧设施利用，或者电视、游戏手柄等娱乐设施利用。

挪动端和 PC 桌面的利用受权

对于运行在手机、平台和 PC 上的应用程序，也能够通过 OAuth 协定失去用户的受权来平安的拜访用户的数据。这种场景的受权流程和 web server 利用十分相似，也是 authorization grant 模式，次要区别是此类利用须要提供本地 web server 或者反对利用间跳转，并提供零碎内置的“browser”（例如 android 的 intent）实现与 authorization server 之间的交互。

这种受权形式的交互过程和接口和上文介绍得 authorization grant 模式一样，唯独受权申请的 redirect_uri 参数有差别：

电视或输出受限设施的利用受权

当咱们在应用智能电视、游戏手柄或者带液晶屏的打印机须要拜访用户的数据，例如放在网盘上的照片、文档等，须要失去用户的受权，而这类设施的输出能力无限，没有浏览器进行重定向，也不不便输出账号口令等认证凭证。

此类场景的利用受权大抵步骤如下：

Step1: 获取 device_code

–

Java 代码 

1
POST /device/code
2
Content-Type: application/x-www-form-urlencoded
3
4
client_id=client_id&response_type=device_code&scope=email%20profile

Step2: 解决 authorization 响应

–

Java 代码 

{
    "device_code": "4/4-GMMhhdfkdkfgdgegkfkfkeegjgjgj",
    "user_code": "GQVQ-JKEC",
    "verification_url": "https://www.google.com/device",
"qrcode_url": "http://www.google.com/device/qrcodeddggheghehhhdddddddddddddddhgerhh",   // 二维码
    "expires_in": 1800    // code 有效期
    "interval": 5   // poll 的距离

Step3: 显示 user_code

能够屏幕显示 verification_url 和 user_code，甚至如果反对的话能够显示二维码。

Step4：poll 用户受权后果

APP 依据第 2 步受权响应的 interval 距离，向 authorization server 拉取用户的受权后果。

–

Javascript 代码 

POST /token
Content-Type: application/x-www-form-urlencoded
 
client_id={client_id}&
client_secret={client_secret}&
code={device_code}&
grant_type=device_code

Step5: 用户关上浏览器输出 verification_url 和 user_code，或者通过手机扫码实现登录和受权。

Step6: 解决 poll 响应

Javascript 代码 

{
    "access_token": "1/ffffdgdg",  
    "expires_in": 3920,
    "scope": "openid profile email",
    "token_type": "Bearer",
    "refresh_token": "dgegegegedgegeg"

}

OAuth：API 定义和扩大

在上一篇中介绍了不同场景下的利用取得租户受权的交互流程。本文次要介绍 OAuth2.0 协定的受权和 token API 定义及常见的扩大计划。OAuth2.0 的所有参数都通过 ”urlencoded” 编码，在申请头部须要减少“application/x-www-form-urlencoded”。

1. code 受权申请 API

实用于 authorization code grant 模式，利用通过浏览器将受权申请重定向给 authorization server，除了通过重定向外，我认为也能够通过 FORM 表单提交。

1.1 参数

1.2 示例

GET /oauth2/authorize?response_type=code&

client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

1.3 扩大

看了 Google 的 OAuth2.0 接口定义，选取几个实际中比拟有意义的扩大参数：

1.4 响应

authorization server 实现用户身份认证并失去用户受权后，将 code 作为参数重定向给 redirect_uri。

2. 隐式受权申请 API

实用于 implicit grant 模式，浏览器 JS 间接向 authorization server 发送受权申请。

2.1 参数

2.2 示例 

 GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

2.3 响应

认证服务器在实现用户身份认证并失去用户的受权后，将回跳到 redirect_uri，并携带 access_token 参数。

API 定义和扩大

OAuth2.0 的所有参数都通过 ”urlencoded” 编码，在申请头部须要减少“application/x-www-form-urlencoded”。

1. code 受权申请 API

实用于 authorization code grant 模式，利用通过浏览器将受权申请重定向给 authorization server，除了通过重定向外，我认为也能够通过 FORM 表单提交。

1.1 参数

1.2 示例

GET /oauth2/authorize?response_type=code&

client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

1.3 扩大

看了 Google 的 OAuth2.0 接口定义，选取几个实际中比拟有意义的扩大参数：

1.4 响应

authorization server 实现用户身份认证并失去用户受权后，将 code 作为参数重定向给 redirect_uri。

2. 隐式受权申请 API

实用于 implicit grant 模式，浏览器 JS 间接向 authorization server 发送受权申请。

2.1 参数

2.2 示例 

 GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

2.3 响应

认证服务器在实现用户身份认证并失去用户的受权后，将回跳到 redirect_uri，并携带 access_token 参数。

本文分享自华为云社区《【系列汇合篇】浅谈 OAuth 二三事》，原文作者：APTX-486977。

点击关注，第一工夫理解华为云陈腐技术~

正文完
web
发表至： web
2021-02-18
 0
关于web:KubeVela-上手1｜让云端应用交付更加丝滑
关于web:什么是-Web-应用性能评测领域的-RAIL-模型
关于web:IndexedDB详解
关于web:Sitadel-Web安全扫描工具