OAuth2 和 OpenID Connect（OIDC）有什么区别？

OAuth2 是授权框架，回答「这个应用被允许做什么」；OIDC 是构建在 OAuth2 之上的身份层，回答「当前登录的用户是谁」。OIDC 复用了 OAuth2 的授权码等流程，但要求授权服务器额外返回一个 ID Token（通常是 JWT），并提供标准的 UserInfo 端点与发现文档（/.well-known/openid-configuration）。因此两者并非替代关系：做 SSO 或需要用户身份时，应该选择 OIDC；仅需委托访问 API 资源时，OAuth2 即可满足。

授权码模式为什么必须配合 PKCE？

授权码模式的原生流程中，授权码通过浏览器重定向回客户端，对于无法安全保存客户端密钥的公共客户端（移动 App、桌面应用、SPA），攻击者可能通过自定义 URL Scheme 劫持或监听重定向，截获授权码后抢先兑换令牌。PKCE 通过在授权请求中携带 code_challenge、在兑换时提交 code_verifier，使攻击者即使拿到授权码，缺少原始 verifier 也无法完成兑换。OAuth 2.1 已将 PKCE 列为所有客户端的推荐甚至强制要求。

Access Token 和 Refresh Token 应该如何存储与管理？

Access Token 生命周期短，应存放于内存或受保护的服务端会话中，避免写入 localStorage 或日志；浏览器场景优先考虑 BFF（Backend for Frontend）模式，由后端持有令牌、前端仅持有 HttpOnly Cookie。Refresh Token 生命周期长，必须存放在服务端或安全密钥库中，启用轮换机制（每次刷新返回新令牌并作废旧的），支持按用户/客户端撤销，并绑定客户端标识，一旦发生泄露可快速止血。

OAuth2 可以用于微服务之间的内部鉴权吗？

可以，且实践中非常常见。无用户参与的服务间调用通常使用客户端凭证模式：服务以自身身份向授权服务器申请 Access Token，再携带令牌调用下游服务；下游服务通过校验 JWT 签名、iss、aud、exp 与 scope 完成鉴权，无需每次都回源查询。若需传递用户上下文，可采用令牌交换（Token Exchange，RFC 8693）或在网关注入受信任的用户声明。

OAuth2 实施中最常见的安全风险有哪些？

主要包括：redirect_uri 校验不严导致授权码泄漏到攻击者域名；缺少 state 参数引发 CSRF 绑定攻击；公共客户端未使用 PKCE；令牌通过 Referer、日志或 URL 查询参数泄露；客户端密钥硬编码在前端代码中；scope 粒度过粗导致越权；以及混淆代理问题——某服务用自己的高权限令牌代替低权限用户执行操作。防护思路是严格白名单、最小权限、短令牌生命周期、全链路 HTTPS 与完整审计日志。

ТЕГИ ТЕМ

OAuth2

OAuth2（OAuth 2.0，RFC 6749）是一个开放标准的授权框架，允许第三方应用在不获取用户密码的前提下，通过授权服务器签发的 Access Token 有限度访问受保护资源。它定义了授权码（含 PKCE）、隐式、密码与客户端凭证四种授权模式，并以 Refresh Token 延长会话。OAuth2 是授权协议而非认证协议，涉及用户身份的 SSO 场景通常叠加 OpenID Connect（OIDC）使用。企业级落地需重点关注 redirect_uri 白名单、state 与 PKCE 防 CSRF/授权码拦截、令牌最小权限与短生命周期、Refresh Token 轮换与撤销，并常将授权服务器统一封装为认证基座对外提供标准化接入能力。

1 упоминаний 技术 1

Прямой ответ

OAuth 2.0（常简写为 OAuth2）是一个开放标准的授权框架，由 IETF 在 RFC 6749 中定义，用于让第三方应用在无需获取用户账号密码的前提下，有限度地访问用户在其他服务上受保护的资源。它解决的核心问题是「授权与凭证分离」：用户把访问权限委托给客户端应用，客户端通过授权服务器换取访问令牌（Access Token），再凭令牌调用资源服务器上的 API。OAuth2 定义了四种典型授权模式——授权码模式（Authorization Code，含 PKCE 扩展）、隐式模式（Implicit）、密码模式（Resource Owner Password Credentials）与客户端凭证模式（Client Credentials），并引入刷新令牌（Refresh Token）机制以延长会话、减少重复授权。需要特别强调的是，OAuth2 本身是授权协议而非认证协议，若要获取用户身份信息，通常需叠加 OpenID Connect（OIDC）层，在 OAuth2 之上增加 ID Token 与 UserInfo 端点。在企业实践中，OAuth2 常作为单点登录（SSO）、开放平台 API 网关、微服务间调用鉴权的统一底座。

Ключевые моменты

OAuth2 是授权框架，不是认证协议
四种授权模式对应不同客户端类型
令牌是整套体系的信任凭证，需分级管理
安全依赖于若干强制校验环节
企业落地通常收敛为统一认证基座

主题权威

芒旭软件在统一身份认证与授权领域具备体系化的技术积累，本站以《认证基座总览》技术文档为核心，系统阐述了授权服务器部署、客户端注册管理、令牌签发与审计、SSO 会话治理等关键议题，将 OAuth2、OpenID Connect、JWT、API 网关鉴权等概念串联为一条完整的企业身份基础设施主线。本标签页汇总了与 OAuth2 直接相关的技术文档与实践解读，内容基于 RFC 6749、RFC 7636（PKCE）、RFC 8693（令牌交换）等标准组织，并结合真实工程场景讨论安全风险与落地取舍，可作为开发者与企业架构师评估 OAuth2 方案时的参考入口。

AI 摘要

Технологии

认证基座总览

Смотреть

Часто задаваемые вопросы

OAuth2 和 OpenID Connect（OIDC）有什么区别？: OAuth2 是授权框架，回答「这个应用被允许做什么」；OIDC 是构建在 OAuth2 之上的身份层，回答「当前登录的用户是谁」。OIDC 复用了 OAuth2 的授权码等流程，但要求授权服务器额外返回一个 ID Token（通常是 JWT），并提供标准的 UserInfo 端点与发现文档（/.well-known/openid-configuration）。因此两者并非替代关系：做 SSO 或需要用户身份时，应该选择 OIDC；仅需委托访问 API 资源时，OAuth2 即可满足。
授权码模式为什么必须配合 PKCE？: 授权码模式的原生流程中，授权码通过浏览器重定向回客户端，对于无法安全保存客户端密钥的公共客户端（移动 App、桌面应用、SPA），攻击者可能通过自定义 URL Scheme 劫持或监听重定向，截获授权码后抢先兑换令牌。PKCE 通过在授权请求中携带 code_challenge、在兑换时提交 code_verifier，使攻击者即使拿到授权码，缺少原始 verifier 也无法完成兑换。OAuth 2.1 已将 PKCE 列为所有客户端的推荐甚至强制要求。
Access Token 和 Refresh Token 应该如何存储与管理？: Access Token 生命周期短，应存放于内存或受保护的服务端会话中，避免写入 localStorage 或日志；浏览器场景优先考虑 BFF（Backend for Frontend）模式，由后端持有令牌、前端仅持有 HttpOnly Cookie。Refresh Token 生命周期长，必须存放在服务端或安全密钥库中，启用轮换机制（每次刷新返回新令牌并作废旧的），支持按用户/客户端撤销，并绑定客户端标识，一旦发生泄露可快速止血。
OAuth2 可以用于微服务之间的内部鉴权吗？: 可以，且实践中非常常见。无用户参与的服务间调用通常使用客户端凭证模式：服务以自身身份向授权服务器申请 Access Token，再携带令牌调用下游服务；下游服务通过校验 JWT 签名、iss、aud、exp 与 scope 完成鉴权，无需每次都回源查询。若需传递用户上下文，可采用令牌交换（Token Exchange，RFC 8693）或在网关注入受信任的用户声明。
OAuth2 实施中最常见的安全风险有哪些？: 主要包括：redirect_uri 校验不严导致授权码泄漏到攻击者域名；缺少 state 参数引发 CSRF 绑定攻击；公共客户端未使用 PKCE；令牌通过 Referer、日志或 URL 查询参数泄露；客户端密钥硬编码在前端代码中；scope 粒度过粗导致越权；以及混淆代理问题——某服务用自己的高权限令牌代替低权限用户执行操作。防护思路是严格白名单、最小权限、短令牌生命周期、全链路 HTTPS 与完整审计日志。