Browse Month: 八月 2016

OAuth2.0 概念和使用

OAuth 是什么
面向客户端开发者应该如何理解OAuth
OAuth 工作原理
OAuth 微信验证实例
OAuth 的安全问题
OAuth 的历史故事

OAuth

OAuth(Open Authorization)

  • 2007 OAuth1.0
  • 2010 OAuth2.0

应用场景

开放第三方登录

工作原理

实现有3个主要步骤

第一步: 请求OAuth 登录页 获取 Request Token

Request Token URL – 未授权的令牌请求服务地址

请求登录页面时带有特定参数的 URL

第二步:用户使用账户登录并授权

redirect_uri 跳转会指定回调地址,并获取 code

第三部:获取 Access Token

User Authorization URL 用户授权的令牌请求服务地址

用户授权之后需要请求的一个带有特定参数的 URL

第四步:以 AccessToken 进行后续 API访问

AccessToken 过期刷新

Refresh Token 刷新 Access Token

User Authorization URL 请求中添加refersh token 参数

实战与使用演示

QQ三方登录 PHP 实战

所需条件

  • 三方平台账户
  • 公网 IP

参考

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

本文对OAuth 2.0的设计思路和运行流程,做一个简明通俗的解释,主要参考材料为RFC 6749。

一、应用场景

OAuth 有两种应用场景:一是授权登录,用户用微信或者支付宝登录自己的网站或者应用;另一种是授权使用资源,如用户使用github 账户授权我们的网站访问他的GitHub 仓库,点赞数等。

二、名词定义
在详细讲解OAuth 2.0之前,需要了解几个专用名词。它们对读懂后面的讲解,尤其是几张图,至关重要。

(1) Third-party application:第三方应用程序,本文中又称”客户端”(client),即上一节例子中的”云冲印”。

(2)HTTP service:HTTP服务提供商,本文中简称”服务提供商”,即上一节例子中的Google。

(3)Resource Owner:资源所有者,本文中又称”用户”(user)。

(4)User Agent:用户代理,本文中就是指浏览器。

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

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

知道了上面这些名词,就不难理解,OAuth的作用就是让”客户端”安全可控地获取”用户”的授权,与”服务商提供商”进行互动。

三、OAuth的思路
OAuth在”客户端”与”服务提供商”之间,设置了一个授权层(authorization layer)。”客户端”不能直接登录”服务提供商”,只能登录授权层,以此将用户与客户端区分开来。”客户端”登录授权层所用的令牌(token),与用户的密码不同。用户可以在登录的时候,指定授权层令牌的权限范围和有效期。

“客户端”登录授权层以后,”服务提供商”根据令牌的权限范围和有效期,向”客户端”开放用户储存的资料。

四、运行流程
OAuth 2.0的运行流程如下图,摘自RFC 6749。

OAuth运行流程

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

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

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

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

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

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

不难看出来,上面六个步骤之中,B是关键,即用户怎样才能给于客户端授权。有了这个授权以后,客户端就可以获取令牌,进而凭令牌获取资源。

下面一一讲解客户端获取授权的四种模式。

五、客户端的授权模式
客户端必须得到用户的授权(authorization grant),才能获得令牌(access token)。OAuth 2.0定义了四种授权方式。

授权码模式(authorization code)
简化模式(implicit)
密码模式(resource owner password credentials)
客户端模式(client credentials)
六、授权码模式
授权码模式(authorization code)是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与”服务提供商”的认证服务器进行互动。

授权码模式

它的步骤如下:

(A)用户访问客户端,后者将前者导向认证服务器。

(B)用户选择是否给予客户端授权。

(C)假设用户给予授权,认证服务器将用户导向客户端事先指定的”重定向URI”(redirection URI),同时附上一个授权码。

(D)客户端收到授权码,附上早先的”重定向URI”,向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。

(E)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。

下面是上面这些步骤所需要的参数。

A步骤中,客户端申请认证的URI,包含以下参数:

response_type:表示授权类型,必选项,此处的值固定为”code”
client_id:表示客户端的ID,必选项
redirect_uri:表示重定向URI,可选项
scope:表示申请的权限范围,可选项
state:表示客户端的当前状态,可以指定任意值,认证服务器会原封不动地返回这个值。
下面是一个例子。

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz

    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

Host: server.example.com

C步骤中,服务器回应客户端的URI,包含以下参数:

code:表示授权码,必选项。该码的有效期应该很短,通常设为10分钟,客户端只能使用该码一次,否则会被授权服务器拒绝。该码与客户端ID和重定向URI,是一一对应关系。
state:如果客户端的请求中包含这个参数,认证服务器的回应也必须一模一样包含这个参数。
下面是一个例子。

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA

      &state=xyz

D步骤中,客户端向认证服务器申请令牌的HTTP请求,包含以下参数:

grant_type:表示使用的授权模式,必选项,此处的值固定为”authorization_code”。
code:表示上一步获得的授权码,必选项。
redirect_uri:表示重定向URI,必选项,且必须与A步骤中的该参数值保持一致。
client_id:表示客户端ID,必选项。
下面是一个例子。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

E步骤中,认证服务器发送的HTTP回复,包含以下参数:

access_token:表示访问令牌,必选项。
token_type:表示令牌类型,该值大小写不敏感,必选项,可以是bearer类型或mac类型。
expires_in:表示过期时间,单位为秒。如果省略该参数,必须其他方式设置过期时间。
refresh_token:表示更新令牌,用来获取下一次的访问令牌,可选项。
scope:表示权限范围,如果与客户端申请的范围一致,此项可省略。
下面是一个例子。

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "example_parameter":"example_value"
 }

从上面代码可以看到,相关参数使用JSON格式发送(Content-Type: application/json)。此外,HTTP头信息中明确指定不得缓存。

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

简化模式

它的步骤如下:

(A)客户端将用户导向认证服务器。

(B)用户决定是否给于客户端授权。

(C)假设用户给予授权,认证服务器将用户导向客户端指定的”重定向URI”,并在URI的Hash部分包含了访问令牌。

(D)浏览器向资源服务器发出请求,其中不包括上一步收到的Hash值。

(E)资源服务器返回一个网页,其中包含的代码可以获取Hash值中的令牌。

(F)浏览器执行上一步获得的脚本,提取出令牌。

(G)浏览器将令牌发给客户端。

下面是上面这些步骤所需要的参数。

A步骤中,客户端发出的HTTP请求,包含以下参数:

response_type:表示授权类型,此处的值固定为”token”,必选项。
client_id:表示客户端的ID,必选项。
redirect_uri:表示重定向的URI,可选项。
scope:表示权限范围,可选项。
state:表示客户端的当前状态,可以指定任意值,认证服务器会原封不动地返回这个值。
下面是一个例子。

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

C步骤中,认证服务器回应客户端的URI,包含以下参数:

access_token:表示访问令牌,必选项。
token_type:表示令牌类型,该值大小写不敏感,必选项。
expires_in:表示过期时间,单位为秒。如果省略该参数,必须其他方式设置过期时间。
scope:表示权限范围,如果与客户端申请的范围一致,此项可省略。
state:如果客户端的请求中包含这个参数,认证服务器的回应也必须一模一样包含这个参数。
下面是一个例子。

 HTTP/1.1 302 Found
 Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
           &state=xyz&token_type=example&expires_in=3600

在上面的例子中,认证服务器用HTTP头信息的Location栏,指定浏览器重定向的网址。注意,在这个网址的Hash部分包含了令牌。

根据上面的D步骤,下一步浏览器会访问Location指定的网址,但是Hash部分不会发送。接下来的E步骤,服务提供商的资源服务器发送过来的代码,会提取出Hash中的令牌。

八、密码模式
密码模式(Resource Owner Password Credentials Grant)中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向”服务商提供商”索要授权。

在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下,比如客户端是操作系统的一部分,或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下,才能考虑使用这种模式。

密码模式

它的步骤如下:

(A)用户向客户端提供用户名和密码。

(B)客户端将用户名和密码发给认证服务器,向后者请求令牌。

(C)认证服务器确认无误后,向客户端提供访问令牌。

B步骤中,客户端发出的HTTP请求,包含以下参数:

grant_type:表示授权类型,此处的值固定为”password”,必选项。
username:表示用户名,必选项。
password:表示用户的密码,必选项。
scope:表示权限范围,可选项。
下面是一个例子。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

C步骤中,认证服务器向客户端发送访问令牌,下面是一个例子。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
 "access_token":"2YotnFZFEjr1zCsicMWpAA",
 "token_type":"example",
 "expires_in":3600,
 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
 "example_parameter":"example_value"
}

上面代码中,各个参数的含义参见《授权码模式》一节。

整个过程中,客户端不得保存用户的密码。

九、客户端模式
客户端模式(Client Credentials Grant)指客户端以自己的名义,而不是以用户的名义,向”服务提供商”进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求”服务提供商”提供服务,其实不存在授权问题。

客户端模式

它的步骤如下:

(A)客户端向认证服务器进行身份认证,并要求一个访问令牌。

(B)认证服务器确认无误后,向客户端提供访问令牌。

A步骤中,客户端发出的HTTP请求,包含以下参数:

granttype:表示授权类型,此处的值固定为”clientcredentials”,必选项。
scope:表示权限范围,可选项。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

认证服务器必须以某种方式,验证客户端身份。

B步骤中,认证服务器向客户端发送访问令牌,下面是一个例子。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}

上面代码中,各个参数的含义参见《授权码模式》一节。

十、更新令牌
如果用户访问的时候,客户端的”访问令牌”已经过期,则需要使用”更新令牌”申请一个新的访问令牌。

客户端发出更新令牌的HTTP请求,包含以下参数:

granttype:表示使用的授权模式,此处的值固定为”refreshtoken”,必选项。
refresh_token:表示早前收到的更新令牌,必选项。
scope:表示申请的授权范围,不可以超出上一次申请的范围,如果省略该参数,则表示与上一次一致。
下面是一个例子。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

wiki
https://oauth.net/2/
https://en.wikipedia.org/wiki/OAuth
http://download.csdn.net/download/samxx8/8858103

rfc

https://tools.ietf.org/html/rfc6749

weixin

https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419316518&token=&lang=zh_CN

https://diamondfsd.com/article/7fc2b070-e238-4fbb-acaf-47f0e3fdaabc

百度百科
https://baike.baidu.com/item/oAuth/7153134?fr=aladdin

概述

  1. [x] 大型网站架构演化

    • 大型网站软件系统的特点
    • 大型网站架构演化发展历程
    • 初始阶段的网站架构
    • 应用服务和数据服务分离
    • 使用缓存改善网站性能
    • 使用应用服务器集群改善网站的并发处理能力
    • 数据库读写分离
    • 使用反向代理和CDN加速网站响应
    • 使用分布式文件系统和分布式数s据库系统
    • 使用NoSQL和搜索引擎
    • 业务拆分
    • 分布式服务
    • 大型网站架构演化的价值观
    • 随网站所需灵活应对
    • 业务驱动网站技术发展
    • 网站架构设计误区
    • 一味追随大公司的解决方案
    • 为了技术而技术
    • 企图用技术解决所有问题
  2. 大型网站架构模式
    2.1 网站架构模式
    2.1.1 分层
    2.1.2 分割
    2.1.3 分布式
    2.1.4 集群
    2.1.5 缓存
    2.1.6 异步
    2.1.7 冗余
    2.1.8 自动化
    2.1.9 安全
    2.2 架构模式在新浪微博的应用

  3. 大型网站核心架构要素
    3.1 性能
    3.2 可用性
    3.3 伸缩性
    3.4 扩展性
    3.5 安全性

架构

  1. [x] 网站的高性能架构
  • 网站性能测试
    • 不同视角下的网站性能
    • 性能测试指标
    • 性能测试方法
    • 性能测试报告
    • 性能优化策略
  • Web前端性能优化
    • 浏览器访问优化
    • CDN加速
    • 反向代理
  • 应用服务器性能优化
    • 分布式缓存
    • 异步操作
    • 使用集群
    • 代码优化
  • 存储性能优化
    • 机械硬盘vs固态硬盘
    • B+树vsLSM树
    • RAID vs HDFS
  1. [x] 网站的高可用架构
  • 网站可用性的度量与考核
  • 高可用的网站架构
  • 高可用的应用
    • 通过负载均衡进行无状态服务的失效转移
    • 应用服务器集群的Session管理
  • 高可用的服务
  • 高可用的数据
    • CAP原理
    • 数据备份
    • 失效转移
  • 高可用网站的软件质量保证
    • 网站发布
    • 自动化测试
    • 预发布验证
    • 代码控制
    • 自动化发布
    • 灰度发布
  • 网站运行监控
    • 监控数据采集
    • 监控管理

伸缩性架构

  • 网站架构的伸缩性设计
    • 不同功能进行物理分离实现伸缩
    • 单一功能通过集群规模实现伸缩
  • 应用服务器集群的伸缩性设计
    • HTTP重定向负载均衡
    • DNS域名解析负载均衡
    • 反向代理负载均衡
    • IP负载均衡
    • 数据链路层负载均衡
    • 负载均衡算法
  • 分布式缓存集群的伸缩性设计
    • Memcached分布式缓存集群的访问模型
    • Memcached分布式缓存集群的伸缩性挑战
    • 分布式缓存的一致性Hash算法
  • 数据存储服务器集群的伸缩性设计
    • 关系数据库集群的伸缩性设计
    • NoSQL数据库的伸缩性设计
  1. 随需应变:网站的可扩展架构
    7.1 构建可扩展的网站架构
    7.2 利用分布式消息队列降低系统耦合性
    7.2.1 事件驱动架构
    7.2.2 分布式消息队列
    7.3 利用分布式服务打造可复用的业务平台
    7.3.1 Web Service与企业级分布式服务
    7.3.2 大型网站分布式服务的需求与特点
    7.3.3 分布式服务框架设计
    7.4 可扩展的数据结构
    7.5 利用开放平台建设网站生态圈

  2. 固若金汤:网站的安全架构
    8.1 道高一尺魔高一丈的网站应用攻击与防御
    8.1.1 XSS攻击
    8.1.2 注入攻击
    8.1.3 CSRF攻击
    8.1.4 其他攻击和漏洞
    8.1.5 Web应用防火墙
    8.1.6 网站安全漏洞扫描
    8.2 信息加密技术及密钥安全管理
    8.2.1 单向散列加密
    8.2.2 对称加密
    8.2.3 非对称加密
    8.2.4 密钥安全管理
    8.3 信息过滤与反垃圾
    8.3.1 文本匹配
    8.3.2 分类算法
    8.3.3 黑名单
    8.4 电子商务风险控制
    8.4.1 风险
    8.4.2 风控

第.3篇 案例
9 淘宝网的架构演化案例分析
9.1 淘宝网的业务发展历程
9.2 淘宝网技术架构演化

1.0 维基百科的高性能架构设计分析
10.1 Wikipedia网站整体架构
10.2 Wikipedia性能优化策略
10.2.1 Wikipedia前端性能优化
10.2.2 Wikipedia服务端性能优化
10.2.3 Wikipedia后端性能优化
11 海量分布式存储系统Doris的高可用架构设计分析
11.1 分布式存储系统的高可用架构
11.2 不同故障情况下的高可用解决方案
11.2.1 分布式存储系统的故障分类
11.2.2 正常情况下系统访问结构
11.2.3 瞬时故障的高可用解决方案
11.2.4 临时故障的高可用解决方案
11.2.5 永久故障的高可用解决方案
12 网购秒杀系统架构设计案例分析
12.1 秒杀活动的技术挑战
12.2 秒杀系统的应对策略
12.3 秒杀系统架构设计

1.3 大型网站典型故障案例分析
13.1 写日志也会引发故障
13.2 高并发访问数据库引发的故障
13.3 高并发情况下锁引发的故障
13.4 缓存引发的故障
13.5 应用启动不同步引发的故障
13.6 大文件读写独占磁盘引发的故障
13.7 滥用生产环境引发的故障
13.8 不规范的流程引发的故障
13.9 不好的编程习惯引发的故障

第.4篇 架构师
14 架构师领导艺术
14.1 关注人而不是产品
14.2 发掘人的优秀
14.3 共享美好蓝图
14.4 共同参与架构
14.5 学会妥协
14.6 成就他人
15 网站架构师职场攻略
15.1 发现问题,寻找突破
15.2 提出问题,寻求支持
15.3 解决问题,达成绩效
16 漫话网站架构师
16.1 按作用划分架构师
16.2 按效果划分架构师
16.3 按职责角色划分架构师
16.4 按关注层次划分架构师
16.5 按口碑划分架构师
16.6 非主流方式划分架构师
附录A 大型网站架构技术一览
附录B Web开发技术发展历程