Dreamer Dreamer
首页
  • 分类
  • 标签
  • 归档
关于
GitHub (opens new window)

lycpan233

白日梦想家
首页
  • 分类
  • 标签
  • 归档
关于
GitHub (opens new window)
  • System

  • 博客

  • IDE

  • OAuth

    • OAuth1.0
      • OAuth
      • OAuth 1.0
        • 基础概念
        • 角色划分
        • 授权流程
        • 获取未授权的 Request Token
        • 获取 User 授权
        • 获取 Access Token
        • 安全问题
      • 相关链接
  • 大杂烩
  • OAuth
lycpan233
2024-04-10
目录

OAuth1.0

# OAuth

开放授权(OAuth)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站(例如,视频编辑网站)在特定的时段(例如,接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样,OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息,而非所有内容。

# OAuth 1.0

# 基础概念

# 角色划分

OAuth 1.0 授权流程中涉及三个角色: Service Provider、User、Customer。

  • Service Provider:
    • 资源所有者,允许通过 OAuth 访问的应用主体。
  • User:
    • 在 Service Provider 拥有账户的个人。
  • Customer:
    • 三方应用,代表 User 使用 OAuth 访问 Service Provider 的资源。

举一个例子方便大家理解这三个角色:

​ 我通过微信登录极客时间~~(没收广告费)~~。其中 我(User)、极客时间(Customer)、微信(Service Provider),从用户的角度看,整个流程就是极客时间(Customer)通过唤起微信(Service Provider)让我(User)扫码登录微信(Service Provider)进行授权,授权成功后也成功登录了极客时间(Cusotmer)。

(这个例子可能有一些不恰当的地方,比如真实场景里,它们的授权方式可能不是本文提到的 OAuth1.0,便于大家理解这块的概念,不用过于纠结)

# 授权流程

OAuth 1.0 授权分为三步:

  1. Customer 获取未授权的 Request Token。
  2. User 授权 Request Token。
  3. Customer 通过授权过的 Request Token 换取 Access Token。

diagram


# 获取未授权的 Request Token

Request Token 的作用是接收 User 授权,并且只能用于换取 Access Token。

  1. Customer 获取 Request Token

Customer 根据 Service Provider 提供的文档,构造 HTTP 请求。当前请求的参数包含,Service Provider 颁发的身份信息、约定的额外参数及签名等。

  1. Service Provider 发放未授权的 Request Token

Service Provider 会对 Customer 的请求进行校验,校验通过后它会生成 Request Token 和 Token Secret 并作为参数响应。

响应里会包含两个关键参数:

oauth_token: Request Token。

oauth_token_secret: Token Secret。

# 获取 User 授权

Request Token 在未得到 User 授权之前是无法使用的。

  1. Customer 引导 User 到 Service Provider

Customer 想要将 Request Token 换成 Access Token,需要先让 User 在 Service Provider 处对 Request Token 进行授权。

Customer 可以通过以下参数,构造一个HTTP的 Get 请求,请求地址指向 Service Provider 的『用户授权 URL』。

oauth_token:上一步返回的 Token, 可以根据 Service Provider 的声明,选择是拼接到 URL 上还是让用户输入。

oauth_callback: Customer 提供的回调地址,User 授权完毕后会被重定向到该地址。

  1. Service Provider 认证 User 并获取授权许可

OAuth 没有指定 Service Provider 如何认证 User 的身份,但是它提供了一组必要的验证步骤。

  • Service Provider 必须先验证 User 的身份。如果 User 没登录,可能需要 User 进行登录。
  • Service Provider 需要向 User 展示 Customer 索取的资源信息(相关的资源需要 Customer 的开发者,之前已经在 Service Provider 申请过)。
  • User 必须允许或者拒绝授权。如果 User 拒绝授权,那么 Service Provider 将不允许访问受限资源。
  1. Service Provider 引导用户返回 Customer

User 允许或者拒绝授权, Service Provider 需要通知 Customer 授权结果。

如果 Customer 在 oauth_callback 中提供了一个回调 URL。Service Provider 将构造一个 HTTP Get 请求 URL,并使用以下参数将 User 重定向到该 URL。

oauth_token: User 允许/拒绝授权的 Request Token

# 获取 Access Token

Customer 将 Request Token 换为能够访问 User 资源的 Access Token。

  1. Customer 请求获取 Access Token

Customer 根据 Service Provider 提供的文档,构造 HTTP 请求。请求参数包括上一步获取的 oauth_token。

  1. Service Provider 授予 Access Token

Service Provider 需要确保:

  • 请求签名已经成功验证。
  • Request Token 不存在重复兑换。
  • Request Token 与 Customer 的密钥匹配。

如果校验成功 Service Provider 将会生成 Access Token 和 Token Secret ,并将其作为参数响应。

oauth_token: Access Token。

oauth_token_secret: Token Secret。

# 安全问题

OAuth 1.0 存在会话固定攻击( session fixation attack (opens new window).)风险目前已经废弃。

# 相关链接

开放授权 - 维基百科,自由的百科全书 (wikipedia.org) (opens new window)

OAuth Core 1.0 (opens new window)

编辑 (opens new window)
上次更新: 2025/04/15, 03:48:14
GitLens 怎么更换头像

← GitLens 怎么更换头像

最近更新
01
docker基础概念
02-26
02
js 获取变量准确类型
02-19
03
Mysql SQL 优化思路
02-18
更多文章>
Theme by Vdoing | Copyright © 2023-2025 Dreamer | MIT License
粤ICP备2025379918号
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式