前置知识

说到使用者痛点一。仅有访问令牌却没有身份信息

如果只使用 OAuth 的 access_token程序只能知道「有人在访问」，却不知道「是谁」还有「拥有何种角色」。这会导致日志无法追踪、审计缺失还有权限判断困难。

从使用者痛点二来看，权限粒度缺失导致安全风险

没有明确的角色标签。程序只能给一个「unknown」使用者临时授权，结果要么全局放行，要么根本无法操作。

OAuth 与 OIDC 的区别与场景

访问程序有两种情况：

• 已注册并登录程序——拥有本地角色，可直接访问。说起来，
• 未注册但想开始进入——需要凭证来实现跨程序访问。这正是 OAuth 要解决的问题。

OAuth 只能解决“访问”吗？

• 安全问题：进入程序后无法显示使用者名。日志记录为 unknown，令牌泄露后难以溯源。
• RBAC 操作问题：没有角色信息就无法决定数据可视化和操作权限。老实说，
• Sso 真正需求：访问 + 身份识别 + 权限打通 三件事。而非单纯的资源授权，

纯 OAuth 实现 SSO流程

1. 子程序检测到未登录 → 重定向至 IAM 授权页。
2. 使用者在 IAM 完成登录并同意授权，返回 code
3. 子程序后端使用 code 换取 access_token
4. UserInfo 请求：子程序调用 IAM 的专属接口 /userinfo
5. IAM 返回使用者 ID、姓名、部门等信息 → 程序确认「当前是谁登录」
6. 依据使用者 ID 在本地 RBAC 表查询权限 → 完成登录鉴权并展示使用者名/菜单等。

User Pain Point: 若不调用 /userinfo 或缺少统一字段规范。 每接入一个新业务都需自行解析字段，维护成本爆炸。

为什么必须在 SSO 中加入 OIDC？

Pain Point 三：多余的接口请求与字段不统一

• Lack of Standardization: OAuth 没规定 /userinfo
• Addition of id_token: OIDC 强制统一返回标准 Claim（sub。name,email...)，一次接入即可复制模板，大幅降低集成成本。

Pain Point 四：Token 本身不携带身份信息且易被滥用

• No Built‑in Identity: access_token 仅是资源凭证；若泄露，可直接调用 /userinfo
• ID Token Benefits: id_token 是签名 JWT。自带签发者、过期时间与防篡改校验，一次验签即可确认身份真实性，无需额外请求。

User Pain Point: 在高合规领域。审计要求每一次操作都有明确身份记录，仅靠 OAuth 无法满足监管需求。

OIDC 简介 & 单点登录实现方式

OIDC在 OAuth 2.0 基础上增加了身份认证层。用标准化的 id_token 把「谁」与「能做什么」一次性传递给业务程序，实现真正意义上的单点登录。

SAML vs OIDC vs OAuth 对比表格

*以下表格仅示例关键差异，请根据实际需求选型 *

OAuth 2.0 为第三方 APP 授予资源访问权限。如相册、定位等 否 移动 APP、公开 API 调用 OIDC 统一身份认证 + 授权码流程，实现公司 SSO 是 公司内部多程序、一站式门户、需要审计日志的场景 CAS 内部信任程序，仅提供登录票据，无细粒度授权控制 否 传统内网 ERP 程序

Cookie / Session 与 Token / JWT 的区别及使用注意事项

Pain Point 五：前端存储失效导致循环重定向登陆

• Cookie 方式：同域名下自动随请求携带；若手动清除或跨域，则会触发重定向回登录页重新获取 JWT。
• LocalStorage / SessionStorage：需要在代码中手动读取并放入 Authorization Header；若存储被清空，一样导致强制重新登录。
• JWT 本身是自包含凭证，可直接用于后端鉴权。但必须配合 Refresh Token 实现无感刷新，否则长时间停留页面会因 Access Token 失效而掉线。