OAuth 2.0 / OIDC (Deep Workflow)
OAuth solves delegated authorization; OIDC adds identity on top. Most production bugs are wrong flow for client, token validation gaps, and confused redirect URIs.
When to Offer This Workflow
Trigger conditions:
- - Web, mobile, or SPA login; machine-to-machine clients
- Debugging
invalid_grant, redirect_uri mismatches, token replay - Hardening scopes, refresh rotation, logout
Initial offer:
Use six stages: (1) actors & client type, (2) select flow & PKCE, (3) tokens & validation, (4) scopes & consent UX, (5) session & logout, (6) operational hardening). Confirm IdP (Auth0, Cognito, Keycloak, Google, etc.).
Stage 1: Actors & Client Type
Goal: Classify confidential vs public clients and who holds secrets.
Rules
- - Server-side web app with secret: confidential; SPA and native: public → PKCE mandatory
- M2M: client credentials or JWT assertion—no user in loop
Exit condition: Architecture diagram: browser, backend, IdP, resource server.
Stage 2: Select Flow & PKCE
Goal: Authorization Code (+ PKCE for public clients); avoid Implicit and ROPC for new apps.
Practices
- - Exact redirect URI allowlist—no wildcards that enable open redirects
- State and nonce for CSRF and token binding (OIDC)
- Mobile: custom URL schemes vs universal links—document trade-offs
Exit condition: Sequence diagram for login happy path and error paths.
Stage 3: Tokens & Validation
Goal: Access token for APIs; ID token for identity claims—validate issuer, audience, exp, signature (JWKS rotation).
Practices
- - Never use ID token as API bearer unless your architecture explicitly defines that (usually wrong)
- Refresh token: rotation, reuse detection, secure storage (httpOnly cookie or secure OS storage on mobile)
- Clock skew tolerance when validating INLINECODE1
Exit condition: Documented validation steps in code or API gateway config.
Stage 4: Scopes & Consent
Goal: Least privilege scopes; incremental auth when possible.
UX
- - Clear consent copy; minimize scope creep at first login
Stage 5: Session & Logout
Goal: RP-initiated logout vs local session clearing—know what breaks SSO across apps.
Practices
- - Front-channel / back-channel logout when enterprise IdP requires
Stage 6: Operational Hardening
Goal: Rotate client secrets safely; monitor failed auth rates; alert on abnormal token issuance.
Pitfalls
- - Mixing dev and prod clients; leaking JWKS or introspection endpoints in client bundles
Final Review Checklist
- - [ ] Correct flow and PKCE for client class
- [ ] Redirect URIs strict; state/nonce used appropriately
- [ ] Token validation complete (sig, iss, aud, exp)
- [ ] Refresh handling and rotation policy
- [ ] Scopes minimal; logout behavior understood
Tips for Effective Guidance
- - Draw Authorization Code + PKCE as default for SPAs.
- Call out BFF pattern when SPA cannot hold secrets and APIs need cookies.
- Enterprise SAML bridge to OIDC adds quirks—defer to IdP docs when needed.
Handling Deviations
- - First-party only same-site: consider session cookie auth instead of full OAuth complexity if appropriate.
- Legacy Implicit: migration plan to Code+PKCE with downtime window.
OAuth 2.0 / OIDC(深度工作流)
OAuth解决委托授权问题;OIDC在此基础上增加了身份认证。大多数生产环境中的bug源于客户端流程错误、令牌验证漏洞和重定向URI混淆。
何时提供此工作流
触发条件:
- - Web、移动端或SPA登录;机器对机器客户端
- 调试invalidgrant、redirecturi不匹配、令牌重放问题
- 强化作用域、刷新令牌轮换、登出机制
初始建议:
采用六个阶段:(1) 参与者与客户端类型、(2) 选择流程与PKCE、(3) 令牌与验证、(4) 作用域与用户授权体验、(5) 会话与登出、(6) 运维加固。确认身份提供商(Auth0、Cognito、Keycloak、Google等)。
阶段1:参与者与客户端类型
目标: 区分机密型与公开型客户端,明确谁持有密钥。
规则
- - 持有密钥的服务端Web应用:机密型;SPA和原生应用:公开型 → 必须使用PKCE
- M2M:客户端凭证或JWT断言——无用户参与
退出条件: 架构图:浏览器、后端、IdP、资源服务器。
阶段2:选择流程与PKCE
目标: 授权码流程(公开型客户端需+ PKCE);新应用避免使用隐式流程和ROPC。
实践
- - 精确的重定向URI白名单——禁止使用通配符,防止开放重定向
- 使用state和nonce防范CSRF和令牌绑定(OIDC)
- 移动端:自定义URL方案 vs 通用链接——记录权衡方案
退出条件: 登录正常路径和错误路径的时序图。
阶段3:令牌与验证
目标: 访问令牌用于API;ID令牌用于身份声明——验证签发者、受众、过期时间、签名(JWKS轮换)。
实践
- - 切勿将ID令牌用作API承载令牌,除非架构明确如此定义(通常错误)
- 刷新令牌:轮换、重用检测、安全存储(移动端使用httpOnly cookie或安全OS存储)
- 验证exp时考虑时钟偏差容差
退出条件: 代码或API网关配置中记录验证步骤。
阶段4:作用域与用户授权
目标: 最小权限作用域;尽可能采用增量授权。
用户体验
阶段5:会话与登出
目标: RP发起的登出 vs 本地会话清除——了解哪些操作会破坏跨应用的SSO。
实践
- - 当企业IdP要求时,使用前端通道/后端通道登出
阶段6:运维加固
目标: 安全轮换客户端密钥;监控认证失败率;告警异常令牌发放。
陷阱
- - 混用开发和生产环境客户端;在客户端包中泄露JWKS或内省端点
最终审查清单
- - [ ] 客户端类型使用正确流程和PKCE
- [ ] 重定向URI严格;state/nonce使用得当
- [ ] 令牌验证完整(签名、签发者、受众、过期时间)
- [ ] 刷新令牌处理与轮换策略
- [ ] 作用域最小化;登出行为明确
有效指导技巧
- - 将授权码+PKCE作为SPA的默认方案。
- 当SPA无法持有密钥且API需要Cookie时,提出BFF模式。
- 企业SAML桥接到OIDC会增加复杂性——必要时参考IdP文档。
偏差处理
- - 仅限第一方同站点:如果合适,考虑使用会话Cookie认证替代完整的OAuth复杂性。
- 遗留隐式流程:制定迁移计划,在停机窗口内迁移至授权码+PKCE。