关于 OAuth 你又了解哪些?

OAuth 2.0 是一种开放授权协议,用于授权第三方应用代表用户访问受保护资源。文章详细介绍了 OAuth 的背景、授权流程、角色,以及与 OIDC(OpenID Connect)的关系。此外,还展示了 Apache APISIX 如何支持 OAuth/OIDC,作为API网关实现集中化的鉴权管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

作者罗锦华,API7.ai 技术专家/技术工程师,开源项目 pgcat,lua-resty-ffi,lua-resty-inspect 的作者。

原文链接

OAuth 的背景

OAuth,O 是 Open,Auth 是授权,也就是开放授权的意思。OAuth 始于 2006 年,其设计初衷正是委托授权,就是让最终用户也就是资源拥有者,将他们在受保护资源服务器上的部分权限(例如查询当天订单)委托给第三方应用,使得第三方应用能够代表最终用户执行操作(查询当天订单)。

OAuth 1.0 协议于 2010 年 4 月作为 RFC 5849 发布,这是一份信息性的评论请求。OAuth 2.0 框架的发布考虑了从更广泛的 IETF 社区收集的其他用例和可扩展性要求。尽管基于 OAuth 1.0 部署体验构建,OAuth 2.0 并不向后兼容 OAuth 1.0。OAuth 2.0 于 2012 年 10 月作为 RFC 6749 发布,承载令牌使用作为 RFC 6750 发布。

在 OAuth 协议中,通过为每个第三方软件和每个用户的组合分别生成对受保护资源具有受限的访问权限的凭据,也就是访问令牌,来代替之前的用户名和密码。而生成访问令牌之前的登录操作,又是在用户跟平台之间进行的,第三方软件根本无从得知用户的任何信息。

这样第三方软件的逻辑处理就大大简化了,它今后的动作就变成了请求访问令牌、使用访问令牌、访问受保护资源,同时在第三方软件调用大量 API 的时候,不再传输用户名和密码,从而减少了网络安全的攻击面。

说白了就是集中授权。

值得注意的是,OAuth 并非身份验证,这里的 Auth 是 Authorization,OAuth 是发生在用户做了身份验证后的事情,系统授权用户能做什么操作。互联网中所有的受保护资源,几乎都是以 Web API 的形式来提供访问的。不同的用户能做的事情不同,例如一个 GitHub 项目,有些用户只有读取和提交 PR(pull request)的权限,而管理员用户则能合并 PR。将用户权限在 API 层面细分,是 OAuth 要做的事情。

OAuth的授权流程

角色

在 OAuth 2.0 的体系里面有四种角色:

  • 第三方应用:一般分为前端浏览器、APP 和后端应用服务器。
  • 资源拥有者:使用第三方应用的用户,并在授权服务器上有账号。
  • 授权服务:提供授权的开发平台,例如微博、GitHub、微信。
  • 受保护资源:用户的各类信息,例如用户名、头像、昵称、邮箱等信息。

流程

图片

步骤A:第三方应用向用户(其实是通过授权服务器)申请授权码

步骤B:授权服务器返回授权码给第三方应用

步骤C:第三方应用将授权码发给资源服务器,申请访问口令

步骤D:授权服务器返回访问口令给第三方应用

步骤E:第三方应用使用访问口令向资源服务器请求用户信息

步骤F:资源服务器返回用户信息,第三方应用提供业务逻辑给用户

授权码和访问口令

获取访问口令的方式在标准里有四种,这里只谈论授权码方式,这也是最常见最安全的方式:

<think>好的,我现在需要解释Google OAuth的流程。首先,我应该回忆一下OAuth的基本概念,然后具体到Google的实现。用户可能想知道整个流程的步骤,以及各个参与方的作用。 首先,OAuth是一个授权框架,允许第三方应用获取用户资源而不需要知道用户的凭证。Google OAuth流程应该遵循OAuth 2.0的标准,但可能有一些特定的实现细节需要注意。 接下来,可能需要分步骤解释流程。比如,第一步是应用注册,开发者需要在Google Cloud Platform创建项目,获取客户端ID密钥。这是基础,因为后续的请求都需要这些凭证。 然后,用户被重定向到Google的授权页面。这里需要说明请求的参数,比如client_id、redirect_uri、response_type(通常是code)、scope(请求的权限范围),以及可能的state参数用于防止CSRF攻击。用户登录并同意授权后,Google会返回授权码到指定的redirect_uri。 接下来,应用用授权码交换访问令牌。这里需要发送client_id、client_secret、授权码redirect_uri到Google的令牌端点。返回的访问令牌刷新令牌是关键,应用可以用访问令牌调用API,而刷新令牌用于获取新的访问令牌。 之后,应用使用访问令牌访问用户资源,比如通过调用Google API获取用户信息。访问令牌有过期时间,所以当过期后,应用需要使用刷新令牌获取新的访问令牌,而不需要用户再次授权。 需要注意的是,各个步骤中涉及的安全措施,比如HTTPS的必要性,客户端密钥的保密,state参数的作用等。可能还需要提到不同授权方式的适用场景,比如Web应用、移动应用或单页应用的不同处理方式。 另外,应该指出一些常见的术语,如OAuth中的角色:资源拥有者(用户)、客户端(第三方应用)、授权服务器(Google)、资源服务器(Google API)。这些术语有助于用户理解流程中各部分的责任。 可能还需要提到OAuth流程中的不同授权类型,如授权码模式、隐式模式等,但Google主要推荐使用授权码模式,尤其是带有PKCE扩展的,以增强安全性,特别是对于公共客户端如移动应用。 最后,总结整个流程的步骤,确保逻辑清晰,用户能够按顺序理解每个阶段发生了什么,以及为什么需要这些步骤。同时,提醒用户注意安全最佳实践,比如正确处理令牌,避免泄露,使用合适的scope等。 可能存在的疑问点包括:授权码访问令牌的区别,为什么需要中间步骤交换授权码,而不是直接返回令牌?这是因为授权码是短暂的,且需要通过后端交换,避免暴露令牌在前端,提高安全性。 需要确认流程中的各个端点的URL是否正确,比如授权服务器端点令牌端点。例如,Google的授权端点可能是https://accounts.google.com/o/oauth2/auth,而令牌端点是https://oauth2.googleapis.com/token。 此外,可能需要提及用户同意页面的外观,以及如何配置OAuth同意屏幕中的信息,如应用名称、logo、权限范围等,这些都会影响用户的信任度。 在解释过程中,应使用中文,避免技术术语过于晦涩,必要时举例说明,比如scope参数可以是openid、email profile等,具体取决于应用需要访问的数据。 检查是否有遗漏的步骤,比如错误处理,如何处理用户拒绝授权的情况,或者授权码被篡改的情况(state参数的作用)。同时,刷新令牌的使用存储也是重要点,特别是长期有效的情况下如何安全保存。 总结来说,需要将整个流程分解为几个关键步骤,每步骤简明扼要地说明,同时补充相关的安全考虑最佳实践,确保用户不仅了解流程,还能正确安全地实施。</think>Google OAuth 流程是遵循 OAuth 2.0 标准的授权协议,用于第三方应用安全获取用户资源(如邮箱、个人资料等)。以下是其核心步骤逻辑: --- ### **1. 应用注册与凭证获取** - **注册应用**:开发者在 Google Cloud Platform 创建项目,配置 OAuth 同意屏幕(定义应用名称、权限范围等),获取 **客户端 ID** **客户端密钥**。 - **权限范围(Scopes)**:指定应用请求的权限,例如 `email`、`profile` 或 Google API 相关权限(如 `https://www.googleapis.com/auth/calendar`)。 --- ### **2. 用户授权请求** - **重定向用户至 Google 授权页面** 应用生成授权链接,用户被重定向到如下格式的 URL: ``` https://accounts.google.com/o/oauth2/auth? client_id=你的客户端ID& redirect_uri=回调地址& response_type=code& scope=请求的权限范围& state=随机字符串(防CSRF) ``` - **用户登录与授权** 用户在 Google 页面登录并确认是否授予应用所请求的权限。 --- ### **3. 获取授权码(Authorization Code)** - **回调至应用** 若用户同意授权,Google 将返回一个 **短期有效的授权码(code)** 到 `redirect_uri`,并附带 `state` 参数(需与请求时一致,防止篡改)。 --- ### **4. 用授权码交换访问令牌(Access Token)** - **发送 POST 请求到 Google 令牌端点** 应用后端发送以下参数至 `https://oauth2.googleapis.com/token`: ```http POST /token HTTP/1.1 Content-Type: application/x-www-form-urlencoded code=授权码& client_id=客户端ID& client_secret=客户端密钥& redirect_uri=回调地址& grant_type=authorization_code ``` - **响应结果** Google 返回 JSON 数据,包含: - `access_token`:用于访问用户资源的令牌(短期有效,通常 1 小时)。 - `refresh_token`:长期令牌(首次授权时返回),用于刷新 `access_token`。 - `expires_in`:`access_token` 的有效期。 --- ### **5. 使用访问令牌调用 Google API** - **访问受保护资源** 应用在请求头中添加 `Authorization: Bearer access_token`,调用 Google API(如 `https://www.googleapis.com/oauth2/v2/userinfo` 获取用户信息)。 --- ### **6. 刷新访问令牌(可选)** - **当 `access_token` 过期时**,应用使用 `refresh_token` 请求新的 `access_token`: ```http POST /token HTTP/1.1 Content-Type: application/x-www-form-urlencoded client_id=客户端ID& client_secret=客户端密钥& refresh_token=刷新令牌& grant_type=refresh_token ``` --- ### **关键安全机制** 1. **授权码模式**:避免在前端暴露 `access_token`,通过后端交换授权码。 2. **State 参数**:防止跨站请求伪造(CSRF)。 3. **HTTPS 强制要求**:所有通信必须加密。 4. **最小权限原则**:仅请求必要的 `scopes`。 --- ### **适用场景** - **Web 应用**:标准授权码模式。 - **移动/单页应用**:使用带 PKCE 扩展的授权码模式,增强公共客户端安全性。 --- 通过此流程,用户无需向第三方应用直接提供密码,即可安全授权其访问 Google 资源。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

API7.ai 技术团队

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值