OIDC 与 OAuth2.0 综述

在选择一种认证授权模式前,建议先理解 OAuth 2.0OpenID Connect 协议,有助于选择最适合你的应用的授权模式。

基本认证 vs OAuth 2.0 vs OpenID Connect

目前 Authing 有三种可以选择的认证方式:

  • 基本认证是基于 API 接口,通过发送账密、手机验证码到 Authing 后端的方式直接完成用户认证。提供 MFA、忘记密码等功能。Authing 的 Guard 组件以及 SDK 都基于这些 API。
  • OAuth 2.0 协议主要用于资源授权。
  • OpenID Connect 协议,简称 OIDC,是 OAuth 2.0 协议的超集,能够认证用户并完成资源授权。在可以选择 OIDC 的情况下,应该选择 OIDC

如果你希望通过 API 的方式直接认证你的用户,你可以查看开发集成部分的接口文档和 SDK 文档。

如果你希望实现单点登录或先鉴权用户再返回资源,建议使用 OIDC 协议

OAuth 2.0

OAuth 2.0 是一个授权标准协议。如果你希望将自己应用的数据安全地授权给调用方,建议使用 OAuth 2.0。

根据 OAuth 2.0 协议规范,主要有四个主体

  • 授权服务器,负责颁发 Access Token,Authing 是授权服务器。
  • 资源所有者,你的应用的用户是资源的所有者,授权其他人访问他的资源。
  • 调用方,调用方请求获取 Access Token,经过用户授权后,Authing 为其颁发 Access Token。调用方可以携带 Access Token 到资源服务器访问用户的资源。
  • 资源服务器,接受 Access Token,然后验证它的被赋予的权限项目,最后返回资源。

其他重要概念:

  • 一次 OAuth 2.0 授权是指用户授权调用方相关的权限。
  • Code 授权码是由授权服务器 Authing 颁发的,用于调用方使用 Code 换取 Token。
  • Access Token 由授权服务器 Authing 颁发,持有 Access Token 说明完成了用户授权。
  • Refresh Token 是一个可选的 Token,用于在 Access Token 过期后获取一个新的 Access Token。

常见的 OAuth 2.0 授权流程如下:

  1. 在你的应用中,让用户访问登录链接,浏览器跳转到 Authing,用户在 Authing 完成认证
  2. 浏览器接收到一个从 Authing 服务器发来的授权码
  3. 浏览器通过重定向将授权码发送到你的应用后端
  4. 你的应用服务将授权码发送到 Authing 获取 AccessToken,如果需要,还会返回 refresh token。
  5. 你的应用后端现在知道了用户的身份,后续可以保存用户信息,重定向到前端其他页面,使用 AccessToken 调用资源方的其他 API 等等。

如果你想了解更多的 OAuth 2.0 内容,可以阅读协议规范 (opens new window)

OAuth 2.0 以及 OIDC 的核心就是授权服务器。授权服务器用于签发 Access Token。每个授权服务器都有一个唯一的 Issuer URI 和*签名密钥**。Authing 中每个应用都是一个授权服务器。

OpenID Connect

OpenID Connect 是基于 OAuth 2.0 的身份认证协议,增加了 Id Token。OIDC 也制定了 OAuth 2.0 中未定义部分的规范,例如 scope,服务发现,用户信息字段等。Authing 支持 OIDC。

OIDC 规范 (opens new window)中,有些名词与 OAuth 2.0 有区别:

  • OpenID Provider,指授权服务器,负责签发 Id Token。Authing 是 OpenID Provider。
  • 终端用户,Id Token 的信息中会包含终端用户的信息。
  • 调用方,请求 Id Token 的应用。
  • Id Token 由 OpenID Provider 颁发,包含关于终端用户的信息字段。
  • Claim 指终端用户信息字段。

OIDC 的授权流程与 OAuth 2.0 一样,主要区别在于 OIDC 授权流程中会额外返回 Id Token。