Oauth

在现代身份认证与授权体系中，OAuth 2.0 和 OpenID Connect（OIDC） 经常被一起提及，但它们解决的是不同层面的问题。理解两者的区别和协作关系，是构建安全、标准的身份系统的关键。 是什么？ OAuth 2.0 不是身份验证协议，而是一个授权框架，允许第三方应用在用户授权下访问受保护资源，而无需获取用户密码。 OpenID Connect（OIDC）是一种基于OAuth 2.0协议构建的‌身份认证标准‌，旨在为现代应用程序提供简单、安全且可互操作的用户身份验证方式。它通过在OAuth 2.0的授权框架之上添加一个身份层，解决了OAuth 2.0本身不完善的身份认证问题。 核心角色： Resource Owner（资源所有者）：通常是用户自己 Client（客户端）：请求访问用户资源的应用（Web、移动、单页应用SPA 等） Authorization Server（授权服务器）：颁发令牌（如 Casdoor、Keycloak、Google OAuth） Resource Server（资源服务器）：托管用户数据（如 API 服务），接受并验证访问令牌，以确定请求是否合法 重要区分： OAuth 2.0 = 授权 OpenID Connect = 身份认证+授权 OAuth2.0授权流程 OAuth2 定义了好几种授权模式，有Authorization Code、Client Credentials、Device Code、Implicit Flow和Password Credentials，隐式流和密码凭据模式被认为是不安全的，不推荐使用。 授权码模式（Authorization Code Flow） 适用于：服务器端 Web 应用、移动 App、单页应用SPA(配合 PKCE 使用) sequenceDiagram participant User as 用户 participant Client as 客户端 participant AS as 授权服务器 participant RS as 资源服务器 User->>Client: 访问应用 Client-->>User: 重定向至授权服务器<br>(client_id, redirect_uri, scope, state, code_challenge) User->>AS: 登录并同意授权 AS-->>User: 重定向回客户端<br>(?code=xxx&state=yyy) User->>Client: 浏览器携带授权码 Client->>AS: POST /token<br>(code, client_id, client_secret*, code_verifier) AS-->>Client: 返回 access_token (+ refresh_token) Client->>RS: GET /api/data<br>Authorization: Bearer <access_token> RS-->>Client: 返回受保护资源 流程 ...