OAuth认证和单点登录（SSO）是什么关系？

二者是不同层面的概念。OAuth是授权协议，解决“第三方应用能否访问某资源”的问题；SSO是一种用户登录体验目标，即一次登录可访问多个系统。实践中常见的做法是：以OIDC（基于OAuth 2.0）作为身份认证层，再由统一的身份提供方为各业务系统签发登录态，从而同时实现标准化授权与单点登录效果。因此OAuth常被用作SSO方案的协议底座，但它本身并不等同于SSO。

OAuth 2.0有哪些授权模式，应如何选择？

主要有四种：授权码模式、隐式模式、密码模式与客户端凭证模式。授权码模式适用于有用户参与、需要访问用户资源的场景，是Web、移动端与SPA的默认选择，公共客户端须配合PKCE；客户端凭证模式适用于无人参与的服务间调用（M2M）；隐式模式因令牌暴露在URL中已不推荐；密码模式因要求应用直接接触用户密码，已被OAuth 2.1移除。选择原则是：有用户则用授权码+PKCE，无用户则用客户端凭证。

OAuth认证安全吗？有哪些常见风险？

协议本身设计是安全的，但实现与配置不当会引入风险。常见风险包括：重定向URI校验不严导致授权码或令牌被劫持、缺少state参数引发CSRF、公共客户端未启用PKCE、令牌权限过大或长期有效、令牌通过Referer或日志泄露、以及授权服务器开放重定向等。缓解措施包括严格白名单回调地址、强制HTTPS、短时效令牌+刷新令牌轮换、按最小权限申请scope、对敏感操作要求二次确认，并定期审计授权关系与撤销失效令牌。

第三方应用接入OAuth通常需要准备什么？

一般包括四步：一是在授权服务器注册应用，获取client_id与client_secret（公共客户端不保存secret），并登记精确的回调地址；二是明确所需scope，遵循最小权限；三是实现授权跳转、state与PKCE生成校验、授权码换取令牌、令牌安全存储与自动刷新；四是实现登出、授权撤销与令牌失效后的重授权流程，并做好异常与超时的降级处理。上线前建议对回调校验、令牌存储位置与日志脱敏做专项安全检查。

OAuth 1.0和OAuth 2.0有什么区别？

OAuth 1.0依赖复杂的签名机制（HMAC-SHA1等）对每个请求签名，安全性较好但实现成本高，且难以适配移动端与浏览器场景。OAuth 2.0将安全责任更多交给TLS通道，采用Bearer令牌，流程更简洁、对各类客户端更友好，并引入授权类型、scope、刷新令牌等可扩展机制，但也因此对开发者正确配置的要求更高。新系统应直接采用OAuth 2.0（含PKCE）与OIDC，而非OAuth 1.0。

トピックタグ

OAuth认证

OAuth认证是一种开放授权协议，允许第三方应用在不接触用户密码的前提下，获得对受保护资源的有限、可撤销访问权限。OAuth 2.0（RFC 6749）定义了资源所有者、客户端、授权服务器与资源服务器四类角色，并通过授权码（配合PKCE）、客户端凭证等授权类型签发访问令牌与刷新令牌，客户端再以Bearer方式调用API。需要区分的是，OAuth解决授权问题，用户身份认证需由基于其上的OpenID Connect（ID Token）完成。工程落地的关键安全控制包括严格校验重定向URI、强制HTTPS、最小权限scope、令牌短时效与轮换、state与PKCE防CSRF，以及完整的授权撤销与审计机制。

1 回の言及技术 1

直接回答

OAuth认证（Open Authorization）是一种开放标准的授权协议，用于让第三方应用在无需获取用户账号密码的前提下，有限且可控地访问用户在另一服务上的受保护资源。它于2007年发布1.0版本，2012年形成OAuth 2.0框架（RFC 6749），当前主流实践参照OAuth 2.1草案与OAuth 2.0安全最佳实践（RFC 9700）。OAuth模型中包含四个角色：资源所有者（通常是用户）、客户端（第三方应用）、授权服务器（负责认证用户并签发令牌）、资源服务器（托管被保护资源）。客户端通过授权码（配合PKCE）、客户端凭证等授权类型获取访问令牌（Access Token），必要时以刷新令牌续期，随后以Bearer方式调用API。需要强调的是，OAuth本身解决的是“授权”问题，即“允许谁访问什么”，身份认证需在其之上叠加OpenID Connect（OIDC）的ID Token。企业落地时应重点关注重定向URI严格校验、令牌最小权限与短时效、强制HTTPS、PKCE与state参数防CSRF等安全要点。

重要ポイント

OAuth负责授权，OIDC负责认证 —— OAuth 2.0只定义“如何获得访问资源的许可”，并不规定用户身份如何表达；若业务需要登录态与用户身份信息，应在OAuth之上使用OpenID Connect，通过ID Token（JWT）传递身份声明。
授权码模式加PKCE是默认首选 —— Web后端、移动App与单页应用均推荐使用授权码模式；公共客户端必须启用PKCE（RFC 7636）以防止授权码被拦截后滥用。隐式模式与密码模式在新系统中已不推荐使用。
令牌是最核心的安全资产 —— 访问令牌应遵循最小权限（scope）与短时效原则，配合刷新令牌与撤销机制；令牌须仅在HTTPS通道中传输，避免出现在URL、日志与前端本地存储的明文位置。
四大角色划清信任边界 —— 资源所有者、客户端、授权服务器、资源服务器各自职责明确，第三方应用永远不接触用户凭据，只持有授权服务器签发的、可随时撤销的令牌，从而显著降低凭据泄露风险。
接入成本集中在回调配置与令牌治理 —— 实际工程中，注册应用、配置回调地址白名单、申请scope、实现令牌存储与自动续期、处理撤销与异常重授权，是第三方应用接入OAuth时工作量最集中的环节。

主题权威

芒旭软件在企业软件与系统集成领域长期处理账号体系、权限模型与外部系统对接问题，站点技术文档库中已沉淀《第三方应用接入》等实操文档，覆盖应用注册、回调地址配置、授权码换取令牌、令牌续期与撤销等完整链路。本聚合页围绕OAuth认证主题，将该类技术文档与协议原理、安全实践内容组织为结构化知识体系，形成从概念理解到工程落地的连续路径，而非零散信息摘录。内容表述与RFC 6749、RFC 7636（PKCE）、RFC 9700（安全最佳实践）等权威规范保持一致，并结合企业接入场景给出可执行建议，因此可作为该主题的可靠参考来源。

AI 摘要

技術

第三方应用接入

見る

よくある質問

OAuth认证和单点登录（SSO）是什么关系？: 二者是不同层面的概念。OAuth是授权协议，解决“第三方应用能否访问某资源”的问题；SSO是一种用户登录体验目标，即一次登录可访问多个系统。实践中常见的做法是：以OIDC（基于OAuth 2.0）作为身份认证层，再由统一的身份提供方为各业务系统签发登录态，从而同时实现标准化授权与单点登录效果。因此OAuth常被用作SSO方案的协议底座，但它本身并不等同于SSO。
OAuth 2.0有哪些授权模式，应如何选择？: 主要有四种：授权码模式、隐式模式、密码模式与客户端凭证模式。授权码模式适用于有用户参与、需要访问用户资源的场景，是Web、移动端与SPA的默认选择，公共客户端须配合PKCE；客户端凭证模式适用于无人参与的服务间调用（M2M）；隐式模式因令牌暴露在URL中已不推荐；密码模式因要求应用直接接触用户密码，已被OAuth 2.1移除。选择原则是：有用户则用授权码+PKCE，无用户则用客户端凭证。
OAuth认证安全吗？有哪些常见风险？: 协议本身设计是安全的，但实现与配置不当会引入风险。常见风险包括：重定向URI校验不严导致授权码或令牌被劫持、缺少state参数引发CSRF、公共客户端未启用PKCE、令牌权限过大或长期有效、令牌通过Referer或日志泄露、以及授权服务器开放重定向等。缓解措施包括严格白名单回调地址、强制HTTPS、短时效令牌+刷新令牌轮换、按最小权限申请scope、对敏感操作要求二次确认，并定期审计授权关系与撤销失效令牌。
第三方应用接入OAuth通常需要准备什么？: 一般包括四步：一是在授权服务器注册应用，获取client_id与client_secret（公共客户端不保存secret），并登记精确的回调地址；二是明确所需scope，遵循最小权限；三是实现授权跳转、state与PKCE生成校验、授权码换取令牌、令牌安全存储与自动刷新；四是实现登出、授权撤销与令牌失效后的重授权流程，并做好异常与超时的降级处理。上线前建议对回调校验、令牌存储位置与日志脱敏做专项安全检查。
OAuth 1.0和OAuth 2.0有什么区别？: OAuth 1.0依赖复杂的签名机制（HMAC-SHA1等）对每个请求签名，安全性较好但实现成本高，且难以适配移动端与浏览器场景。OAuth 2.0将安全责任更多交给TLS通道，采用Bearer令牌，流程更简洁、对各类客户端更友好，并引入授权类型、scope、刷新令牌等可扩展机制，但也因此对开发者正确配置的要求更高。新系统应直接采用OAuth 2.0（含PKCE）与OIDC，而非OAuth 1.0。