OAuth 2.0
由IETF于2012年通过RFC 6749正式标准化的授权协议，核心设计思想是「授权与认证分离」，将令牌体系拆分为access_token（短期）和refresh_token（长期）两层，是现代Web身份认证的主流标准。
核心事实
时间轴 (近 90 天)
在远程MCP授权中，需要验证token的有效性、预期受众（audience）和范围（scope），不应盲目将传入的token传给另一个后端。
OAuth 2.0 的 access token 是用于调用 Google API 的短期凭据，通常有效期为 1 小时；refresh token 是用于在 access token 过期后静默换取新令牌的长期凭据。
SCIM标准本身并不规定具体的认证机制，仅建议使用OAuth 2.0。
OIDC（OpenID Connect）构建在 OAuth 2.0 之上，使用 JSON 和 JWT，更轻量、更易调试，正逐渐取代 SAML 成为新项目的首选。
目前还没有针对Agent委托链的公认端到端标准，导致每一跳都容易丢失原始操作者身份，下游系统只看到一个宽泛的服务身份
OAuth 2.0 提供了授权码、PKCE、Token Exchange（RFC 8693）等机制来表达用户A授权应用B代表自己访问资源C
Scope是OAuth 2.0体系中的概念，用于限定凭证能访问哪些API或读写范围；如果scope没配或配错，即便服务账号拥有IAM权限，请求也会因令牌权限不足被拒，因为认证是IAM权限与OAuth scope双重校验。
在 n8n 中连接 Gmail 节点时，OAuth 流程为：在 Google Cloud Console 创建项目、启用 Gmail API、配置 OAuth 同意屏幕、生成 Client ID 与 Client Secret，用户授权后获得访问令牌（Access Token）和刷新令牌（Refresh Token）。
Dick Hardt 是 OAuth 2.0 设计的主导者，并参与了关于意图驱动认证的小组讨论。
业界正在推动的机器身份管理方案包括：为每个机器身份签发短期证书（如SPIFFE/SPIRE标准）、用OAuth 2.0客户端凭证模式替代静态密钥、将机器身份纳入与人类用户相同的策略引擎。
还有 40 条时间轴事件
全部知识事实 (20)
OAuth 2.0由IETF在RFC 6749中定义
90%已验证OpenID Connect是在OAuth 2.0之上构建的身份层，引入了通常为JWT格式的ID Token用于向客户端证明用户身份
75%已验证OAuth 2.0 Token Exchange（RFC 8693）定义了令牌交换机制，允许一个服务用已持有的令牌换取适用于下游服务的新令牌
75%已验证MCP 的权限模型借鉴了 OAuth 2.0 授权码流程，工具调用需要明确的用户授权
75%已验证OAuth协议最初设计用于解决第三方应用代表用户访问资源的问题，核心机制是用户向授权服务器授权换取访问令牌
65%已验证Microsoft Graph API 是微软统一的 RESTful API 接口，覆盖邮件、日历、文件等 Microsoft 365 全套服务
65%已验证OAuth 2.0专门处理授权委托，OpenID Connect在OAuth 2.0之上叠加身份验证层，SAML多用于企业联邦身份场景
65%已验证OAuth 2.0 只解决授权问题，而 OIDC 在此基础上增加了标准化的身份认证层，引入了通常为 JWT 格式的 ID Token 来携带用户身份信息
65%已验证微信小程序的登录流程遵循OAuth 2.0的授权码模式变体，前端调用wx.login()获取临时登录凭证code，服务器用code加AppID和AppSecret向微信服务器换取openid和session_key
65%待验证Gemini CLI 通过 OAuth 2.0 协议认证，在本地启动临时 HTTP 服务器并打开浏览器完成 Google 账户授权，token 存储在本地配置目录中
90%待验证OAuth 2.0的Access Token通常有效期较短（15分钟到1小时），Refresh Token有效期较长
90%待验证One API的二次分发Key机制借鉴了OAuth 2.0中的令牌委托模式，原始Key仅存储在服务端
80%待验证Gemini CLI的身份认证基于OAuth 2.0协议，如果认证不成功大概率是因为没有开启TUN模式（全局代理模式）
80%待验证Windsurf使用JWT（JSON Web Token）作为用户身份凭证，基于OAuth 2.0认证流程
75%待验证OAuth模式通过引入身份提供方对用户进行身份认证，工具认证后签发访问令牌供智能体使用
60%待验证OAuth 2.0是授权框架,配合OIDC扩展实现身份认证
60%待验证OAuth 2.1强制要求使用PKCE（Proof Key for Code Exchange）来防止授权码拦截攻击
60%待验证常见的 SSO 实现协议包括 SAML 2.0、OAuth 2.0 和 OpenID Connect（OIDC）
60%待验证OAuth 2.0 是当前 SaaS 服务最常用的授权协议，通过授权码流程、客户端凭证流程等多种模式实现第三方应用在不暴露用户密码的情况下获取受限资源的访问权限
60%待验证OAuth的交互式授权流程依赖浏览器重定向和用户手动点击授权，不适合无头（headless）自动化Agent运行
60%