文章总结： 本文系统解析企业级三大身份认证协议：OAuth2.0聚焦第三方授权，详细阐述授权码、简化、密码、客户端四种模式的适用场景与安全差异；SAML实现跨企业单点登录，说明基于XML的8步认证流程及签名绕过等风险；SCRAM通过挑战响应机制实现双向认证。文章提供协议核心流程、安全要点及实践参考，助力开发与安全人员快速应用。 综合评分： 85 文章分类： WEB安全,应用安全,安全建设,技术标准,渗透测试

第二节｜企业级身份认证：OAuth、SAML与SCRAM详解

原创

皮皮宋 皮皮宋

皮皮宋渗透笔记

2026年4月15日 11:33 安徽

在小说阅读器读本章

去阅读

上一节给大家讲了身份认证的基础——多因子认证、SSO和JWT，适合日常简单场景的认证需求。

而在企业级场景中，认证逻辑会更复杂：比如第三方应用授权（微信登录、QQ登录）、跨企业系统单点登录、双向确认认证等，这就需要用到OAuth、SAML、SCRAM这些更专业的认证协议。

今天这一节，就聚焦这3个企业级认证协议，拆解它们的核心流程、适用场景和安全要点，不管是开发还是网安，都能直接用到。

（下一节咱们讲Windows相关的认证机制，以及权限系统设计模型，收尾整个身份认证系列～）

一、OAuth 2.0：最常用的第三方授权协议

4.1 简介

OAuth（Open Authorization），是一个关于“授权”的开放网络标准，目前广泛应用于第三方登录场景（如用微信登录小程序、用GitHub登录第三方工具），当前最新版本是2.0版。

OAuth的核心逻辑是“分离授权与认证”：客户端（如小程序）不能直接获取用户的密码，只能通过授权层获取“令牌（token）”，再通过令牌访问用户的资源，以此区分用户与客户端，保障用户信息安全。

用户可以在授权时，指定令牌的权限范围和有效期，比如授权小程序只能读取用户的昵称、头像，不能获取手机号、地址等敏感信息，灵活性极高。

OAuth 2.0定义了4种核心授权方式，适配不同的场景，重点掌握即可。

4.2 通用流程（6步走）

不管是哪种授权方式，OAuth 2.0的通用流程都离不开以下6步，核心是“令牌的申请与使用”：

用户打开客户端（如小程序），客户端要求用户给予授权；

用户同意给予客户端授权（如点击“微信登录”并确认）；

客户端使用上一步获得的授权，向认证服务器申请令牌；

认证服务器对客户端进行认证（验证客户端ID、授权范围等），确认无误后，发放令牌；

客户端使用令牌，向资源服务器申请获取用户资源；

资源服务器验证令牌的合法性（有效期、权限范围），确认无误后，向客户端开放资源。

4.3 核心授权方式（重点掌握4种）

1. 授权码模式（authorization code）

这是功能最完整、流程最严密的授权模式，适合有后端服务器的客户端（如网站、APP），核心特点是“通过客户端后台服务器，与认证服务器互动”，安全性最高。

具体流程（7步）：

用户访问客户端，客户端将用户导向认证服务器；

用户选择是否给予客户端授权；

假设用户给予授权，认证服务器将用户导向客户端事先指定的“重定向URI”，同时附上一个授权码；

客户端收到授权码，附上早先的“重定向URI”，向认证服务器申请令牌；

认证服务器核对授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）；

客户端使用访问令牌访问资源服务器；

访问令牌过期后，客户端使用更新令牌申请新的访问令牌。

关键参数（必记）：

申请认证时：response_type=code（固定）、client_id（客户端ID）、redirect_uri（重定向URI）；

申请令牌时：grant_type=authorization_code（固定）、code（授权码）、redirect_uri（与申请时一致）、client_id（客户端ID）；

服务器返回时：access_token（访问令牌）、token_type（令牌类型）、expires_in（过期时间）、refresh_token（更新令牌）。

2. 简化模式（implicit）

简化模式无需通过客户端后台服务器，直接在浏览器中向认证服务器申请令牌，跳过“授权码”步骤，所有流程在浏览器中完成，令牌对用户可见，客户端不需要认证。

适用场景：纯前端应用（如Vue、React单页应用），无后端服务器的场景，安全性低于授权码模式。

核心流程（7步）：

客户端将用户导向认证服务器；

用户决定是否给予客户端授权；

假设用户给予授权，认证服务器将用户导向客户端指定的重定向URI，并在URI的Hash部分包含访问令牌；

浏览器向资源服务器发出请求，Hash部分不会被发送；

资源服务器返回一个网页，包含可提取Hash值中令牌的代码；

浏览器执行脚本，提取出令牌；

浏览器将令牌发给客户端，客户端使用令牌访问资源。

3. 密码模式（resource owner password credentials）

密码模式中，用户直接向客户端提供自己的用户名和密码，客户端使用这些信息，向认证服务器索要授权令牌。

注意：客户端不得储存用户密码，仅用于一次性申请令牌，适用场景：客户端是用户信任的应用（如企业内部APP）。

核心流程（3步）：

用户向客户端提供用户名和密码；

客户端将用户名和密码发给认证服务器，请求令牌；

认证服务器确认无误后，向客户端提供访问令牌（可附带更新令牌）。

4. 客户端模式（client credentials）

客户端模式中，客户端以“自己的名义”（而非用户的名义）向认证服务器认证，获取令牌，用于访问客户端自身的资源（而非用户资源）。

适用场景：服务器之间的通信（如第三方API调用），无需用户参与。

核心流程（2步）：

客户端向认证服务器进行身份认证，并要求获取访问令牌；

认证服务器确认客户端身份无误后，向客户端提供访问令牌。

4.7 参考链接

rfc6749：

理解OAuth：

OAuth2.0 Vulnerabilities：

OAuth Community Site：

Hidden OAuth attack vectors：

二、SAML：基于XML的企业级SSO协议

5.1 简介

SAML（Security Assertion Markup Language），译为安全断言标记语言，是一种基于XML格式的语言，核心作用是完成企业级单点登录（SSO），常用于跨企业、跨系统的身份认证（如企业与合作伙伴系统的单点登录）。

SAML有1.1和2.0两个版本，两者不兼容，但核心逻辑和角色结构大致相同，目前主流使用2.0版本。

5.2 认证过程（3个角色，8步流程）

SAML认证涉及3个核心角色：服务提供者（SP）、认证服务（IDP）、用户（Client），典型流程如下：

用户（Client）访问SP的受保护资源；

SP生成SAML认证请求，返回给用户；

用户将SAML认证请求提交给IDP；

IDP返回认证页面，要求用户登录；

用户在IDP处完成登录（输入账号密码）；

认证成功后，IDP生成用私钥签名、包含用户权限的SAML断言，返回给用户；

用户将SAML断言提交给SP；

SP验证SAML断言的合法性（签名、有效期等），确认无误后，向用户返回受保护资源。

5.3 安全问题

SAML的安全风险主要集中在“断言验证”和“传输安全”，常见问题有2类：

签名绕过：在SSL模式下，若认证方式可选，攻击者可删除签名方式标签，绕过认证；

重放攻击：若SAML断言中缺少过期时间（expiration），且断言ID不唯一，攻击者可窃取合法断言，重复使用进行攻击。

5.4 参考链接

SAML Wiki：

RFC7522：

SSO Wars The Token Menace：

三、SCRAM：双向确认的安全认证机制

6.1 简介

SCRAM（Salted Challenge Response Authentication Mechanism），是一套包含“服务器和客户端双向确认”的用户认证机制，核心特点是“挑战-响应”模式，无需传输明文密码，安全性更高。

SCRAM常用于需要高安全性的场景（如数据库认证、API接口认证），通过“盐值+挑战码”的方式，避免密码在传输过程中被窃取，同时实现客户端与服务器的双向验证。

写在最后

OAuth、SAML、SCRAM，是企业级身份认证的“三大核心协议”——OAuth主打第三方授权，SAML主打跨企业SSO，SCRAM主打高安全双向认证，各自适配不同的企业场景。

掌握它们的流程和安全漏洞，不管是开发企业级系统，还是做渗透测试，都能快速定位问题、规避风险。下一节，咱们讲Windows系统专属的认证机制（Kerberos、NTLM），以及权限系统设计模型，彻底吃透身份认证与权限管控，记得蹲更～

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：皮皮宋渗透笔记 皮皮宋 皮皮宋《第二节｜企业级身份认证：OAuth、SAML与SCRAM详解》