OAuth协议

什么是OAuth协议

定义:开放授权(OAuth)是一种开放标准授权框架,它授予应用程序访问用户受保护资源,而无需用户的账户名和密码。

应用场景:例如开放平台中开发者的开发应用需要访问用户的相关数据,需要用户进行授权;要求用户"使用 Google 登录?"或"允许访问您的账户信息?"的网站和第三方应用程序。这些场景都会使用OAuth协议,以实现用户可以在不共享其用户凭证的情况下,轻松授予这些应用程序访问其账户数据的权限。

为什么要有OAuth协议

www.ruanyifeng.com/blog/2014/0...

有一个"云冲印"的网站,可以将用户储存在Google的照片,冲印出来。用户为了使用该服务,必须让"云冲印"读取自己储存在Google上的照片。

问题是只有得到用户的授权,Google才会同意"云冲印"读取这些照片。那么,"云冲印"怎样获得用户的授权呢? 传统方法是,用户将自己的Google用户名和密码,告诉"云冲印",后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点:

  1. "云冲印"为了后续的服务,会保存用户的密码,这样很不安全;
  2. Google不得不部署密码登录,而我们知道,单纯的密码登录并不安全;
  3. "云冲印"拥有了获取用户储存在Google所有资料的权力,用户没法限制"云冲印"获得授权的范围和有效期;
  4. 用户只有修改密码,才能收回赋予"云冲印"的权力。但是这样做,会使得其他所有获得用户授权的第三方应用程序全部失效;
  5. 只要有一个第三方应用程序被破解,就会导致用户密码泄漏,以及所有被密码保护的数据泄漏。 OAuth就是为了解决上面这些问题而诞生的。

OAuth协议的基本概念

OAuth 框架的主要包括以下基本概念:

  1. 资源所有者:能够授权应用程序对其所拥有的资源进行访问的实体;
  2. 资源服务器:托管受保护资源的服务器,能够接受和响应应用程序使用令牌对受保护资源的请求;
  3. 客户端:又称第三方应用程序,根据资源所有者的授权,能够代表资源所有者对受保护资源发起请求;
  4. 认证服务器:用于颁发访问令牌给客户端的服务器(和资源服务器可以是同一台服务器,也可以是不同的服务器)。
    OAuth在客户端和资源服务器之间,抽象了一层授权层。客户端不能直接通过用户名和密码访问资源服务器中相应用户的资源,只能登陆授权层,以此将用户与客户端隔离开。"客户端"登录授权层后,认证服务器会向其颁发一个令牌(token),令牌中包含了权限范围和有效期。

OAuth的基本流程

以下用ai生成的一张图,看起来还不错: (A)用户打开客户端以后,客户端要求用户给予授权。

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

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

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

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

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

上面几个步骤中,B是最关键的,用户怎样才能给客户端授权?下面讲讲客户端获取授权的四种模式。

客户端授权模式

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

  • 授权码模式(authorization code)
  • 简化模式(implicit)
  • 密码模式(resource owner password credentials)
  • 客户端模式(client credentials)

授权码模式

授权码模式通过客户端的后台服务器,与认证服务器进行交互,适用于有后台服务器的应用程序: 以上是基于浏览器重定向完成的授权:

  1. 客户端将用户导向认证服务器提供的授权页面;
  2. 用户决定是否授权,若授权,认证服务器将用户导向客户端事先指定的重定向URI,同时附上一个授权码;
  3. 客户端收到授权码,附上之前指定的重定向URI,向认证服务器申请令牌(这一步在客户端的后台服务器上完成的,对用户不可见);
  4. 认证服务器对授权码和重定向URI进行身份验证,验证通过后,则给客户端颁发访问令牌(access token)和刷新令牌(refresh token)。 在第一步中,客户端导向认证服务器时,URI需要包含以下参数:
  • response_type:表示授权类型,必选项,此处的值固定为"code"
  • client_id:表示客户端的ID,必选项
  • redirect_uri:表示重定向URI,可选项
  • scope:表示申请的权限范围,可选项
  • state:表示客户端的当前状态,可以指定任意值,认证服务器会原封不动地返回这个值。
ini 复制代码
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

在第二步中,认证服务器通过发送以下HTTP响应重定向至用户指定的URI:

ini 复制代码
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz
  • code:表示授权码,必选项。该码的有效期应该很短,通常设为10分钟,客户端只能使用该码一次,否则会被授权服务器拒绝。该码与客户端ID和重定向URI,是一一对应关系。
  • state:如果客户端的请求中包含这个参数,认证服务器的回应也必须一模一样包含这个参数。 第三步中,客户端向认证服务器发起申请令牌的HTTP请求,示例如下:
ini 复制代码
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
  • grant_type:表示使用的授权模式,必选项,此处的值固定为"authorization_code"。
  • code:表示上一步获得的授权码,必选项。
  • redirect_uri:表示重定向URI,必选项,且必须与A步骤中的该参数值保持一致。
  • client_id:表示客户端ID,必选项 第四步中,认证服务器返回HTTP响应:
css 复制代码
 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"
     }

包含了访问令牌、刷新令牌、过期时间和权限范围。 下面以开放平台的授权流程举个例子:

简化模式

该模式能够不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了授权码这个步骤。所有步骤在浏览器中完成,令牌对用户可见,且客户端不需要认证。

  1. 客户端将用户导向认证服务器提供的授权页面。
  2. 用户决定是否给于客户端授权。
  3. 假设用户给予授权,认证服务器将用户导向客户端指定的"重定向URI"(通过请求时或者客户端注册时提供的重定向URI),并在URI的Hash部分包含了访问令牌。
  4. 浏览器根据重定向URI向资源服务器发出请求,其中不包括上一步收到的Hash值。
  5. 资源服务器返回一个网页(通常带有嵌入式脚本),其中包含的代码可以获取Hash值中的令牌。
  6. 浏览器执行上一步获得的脚本,提取出令牌。
  7. 浏览器将令牌发给客户端。

密码模式

密码模式中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向"服务商提供商"索要授权。

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

客户端模式

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

刷新令牌

访问令牌到期后,如何让用户不用重新走一遍授权流程,能够自动刷新访问令牌?令牌到期前,客户端使用刷新令牌向认证服务器请求新的访问令牌即可。

yaml 复制代码
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

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

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

OAuth应用场景

MCP OAuth

TODO

相关推荐
@yanyu6661 小时前
springboot实现查询学生
java·spring boot·后端
酷爱码1 小时前
Spring Boot项目中JSON解析库的深度解析与应用实践
spring boot·后端·json
AI小智2 小时前
Google刀刃向内,开源“深度研究Agent”:Gemini 2.5 + LangGraph 打造搜索终结者!
后端
java干货2 小时前
虚拟线程与消息队列:Spring Boot 3.5 中异步架构的演进与选择
spring boot·后端·架构
一只叫煤球的猫2 小时前
MySQL 8.0 SQL优化黑科技,面试官都不一定知道!
后端·sql·mysql
写bug写bug3 小时前
如何正确地对接口进行防御式编程
java·后端·代码规范
不超限3 小时前
Asp.net core 使用EntityFrame Work
后端·asp.net
豌豆花下猫4 小时前
Python 潮流周刊#105:Dify突破10万星、2025全栈开发的最佳实践
后端·python·ai
忆雾屿5 小时前
云原生时代 Kafka 深度实践:06原理剖析与源码解读
java·后端·云原生·kafka