OAuth2和SSO为何常常被当作同一种技术混淆使用？

简介 最近在工作中遇到了一个问题，在实现OAuth2的过程中，发现公司的实际落地与理论不完全相同。故此复习一下。 What is OAuth2? OAuth2(OAuth2.0)是一个开放标准的授权框架，用于第三方应用(客户端)在取得用户(资源所有者)的授权下，可以访问用户敏感信息。而无需向第三方应用暴露账号密码。 核心是"授权"而非"认证" 设计之初聚焦于权限管理 OAuth2诞生的初衷是为了避免第三方应用获取用户的原始密码，同时让用户(资源所有者)自主控制第三方应用(客户端)对自己敏感信息的访问权限(比如只读，修改，删除)，其本质是"授权第三方有限度的使用资源"。 本身不参与认证 在OAuth2流程中，用户身份的验证始终由资源所有者的平台负责(比如微信，GITHUB)，由它们提供Login页面。 OAuth本身不参与用户身份的验证，它只是在验证通过后，传递"已授权"的凭证。 仅仅是一份授权证明 OAuth2最终发放的是"访问令牌(Access Token)"，它仅仅代表用户允许第三方应用如何访问特定资源，不包含用户身份信息，也不能作为用户身份的证明。 举个例子，使用该Access Token在https://www.jwt.io/ 中解析。eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzQ1Niwic2NvcGUiOiJwcm9maWxlIG9wZW5pZCIsImV4cCI6MTczMzcwMjQwMCwiaWF0IjoxNzMzNjk4ODAwLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20ifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c 核心角色 OAuth2定义了4个核心角色，所有流程都围绕这4个角色展开 角色 含义 举个例子 资源所有者 用户本身，有权决定是否授权客户端访问自己的资源 使用微信的你 客户端 第三方应用，希望访问用户(也就是你)的敏感信息 比如小红书希望访问你微信上的照片，头像，昵称等 授权服务器 由资源服务器提供，验证用户的身份，生成授权凭证(Access Token) 微信的授权服务器 资源服务器 存储受保护资源的服务器，接收并验证客户端的Access Token 微信的用户信息服务器（存储你的头像、昵称等，只有验证令牌后才返回）。 核心授权类型(Grant Type) OAuth2根据客户端的类型(是否有服务器，是否能安全存储密钥)定了多种Grant Type。 授权码模式(Authorization Code) 适用场景： 有自己服务器的客户端，能够安全存储客户端密钥，不会暴露给前端 特点： 通过授权码间接获取访问令牌，是最常用也是最安全的模式。 隐式模式（Implicit） 适用场景： 有自己服务器的客户端(比如无需与后端交互的纯前端应用)，无法安全存储客户端密钥（密钥会暴露在前端代码中） 特点：跳过“授权码”步骤，直接从授权服务器获取访问令牌（通过URL片段返回），不返回刷新令牌。 缺点：访问令牌直接暴露在前端，安全性较低（可能被拦截）。 密码模式（Resource Owner Password Credentials） 适用场景：客户端与资源所有者高度信任（如公司内部应用），用户愿意向客户端提供账号密码。 流程：用户直接向客户端输入账号密码，客户端拿着密码向授权服务器请求访问令牌（如“公司内部APP用域账号密码登录，获取员工信息系统的访问权限”）。 缺点：客户端获取了用户密码，违背OAuth“不暴露密码”的初衷。 客户端模式（Client Credentials） 适用场景：客户端访问自己的资源（非用户个人资源），无需用户授权。 流程：客户端直接用自己的客户端ID和密钥向授权服务器请求访问令牌（如“天气APP的后端服务，用自己的凭证获取天气数据API的访问权限”）。 重点关注授权码模式（Authorization Code）即可，剩下的三种纯属凑数。谁敢在生产环境暴露密钥？谁又能保证密钥永远不会泄露？ 核心凭证 OAuth2中有3种关键凭证，用于确保授权流程的安全性 授权码(Authorization Code) 短期有效(几分钟)，由授权服务器在用户同意授权后生成。 仅能使用一次，兑换令牌后失效，避免被劫持后重复使用。