跳到主要内容

OAuth 2.0 与 OpenID Connect

OAuth 2.0 怎样让应用获得有限资源访问权？​

  • OAuth 2.0: 授权框架，使客户端无需拿到用户密码，也能在获准范围内访问受保护资源;
  • 资源所有者: 有权批准访问的用户或系统;
  • 客户端: 希望调用资源的应用，可能是能保密的服务端，也可能是无法保密的浏览器或移动应用;
  • 授权服务器: 验证身份与授权条件后发放令牌;
  • 资源服务器: 验证访问令牌及权限后提供资源;
  • Scope: 表达授予的权限范围，具体字符串和含义由资源系统定义;
  • Access Token: 调用资源时出示的授权凭据，格式不必是 JWT;

授权码流程怎样避免把密码交给第三方？​

客户端 → 浏览器前往授权服务器：client_id、scope、redirect_uri 等
用户 → 授权服务器登录并同意
授权服务器 → 已登记回调地址：一次性授权码
客户端 → 令牌端点：授权码与所需校验信息
客户端 → 资源服务器：访问令牌
  • 客户端认证: 机密客户端可以使用凭据，公开客户端不能安全保存共享 secret，不能强制每个客户端都内置密钥;
  • PKCE: 客户端先承诺一个随机校验值的摘要，换令牌时出示原值，使被截获授权码更难被他人兑换;
  • Refresh Token: 在获准条件下用来换取新访问令牌，属于需要保护的长期凭据，不直接用于普通资源调用;
  • 安全条件: 使用 TLS、严格回调地址校验和适当的请求绑定，遵循 RFC 9700的安全要求;
  • 原文修正: 不以直接返回访问令牌的旧式浏览器流程作为推荐范例，也不说 OAuth 缺乏标准实现规则;

OIDC 怎样在授权之上表达用户身份？​

  • OIDC: OpenID Connect，在 OAuth 2.0 之上加入身份认证语义，使客户端能验证“谁已登录”;
  • RP: Relying Party，即依赖身份提供方结果的应用;
  • OP: OpenID Provider，负责用户认证并提供身份声明的服务，不只是一个转发一次性验证码的中间站;
  • ID Token: 面向客户端的身份声明，采用 JWT，不能与用于访问资源的 Access Token 混用;
  • UserInfo: 客户端在获准范围内通过访问令牌获取用户资料的端点;
  • 验证: 按流程校验签名、签发者、受众、有效期及必要的 nonce，收到一个 JWT 字符串并不代表已验证登录;
  • 依据: OIDC Core区分身份令牌与资源访问令牌，未规定统一的一小时有效期;

授权与认证在设计中如何分开？​

  • 认证: 确认当前主体是谁，由 OIDC 等认证机制提供;
  • 授权: 决定该主体能对哪个资源执行哪些操作，OAuth 的 scope 仍需结合资源级规则;
  • 实施成本: 权限词汇、令牌生命周期和信任配置由系统管理，选择标准协议不代表集成没有安全复杂度;

为什么拿到 Access Token 不等于完成用户登录？​

  • 受众区别: Access Token 通常面向资源服务器，ID Token 面向当前客户端，不能把一方的令牌冒充另一方的凭据;
  • 登录上下文: 客户端必须把认证响应绑定到自己发起的请求，验证签发者、受众及有效期，防止接收不属于本次登录的结果;