¶ OIDC 与 OAuth2.0 综述
在选择一种认证授权模式前,建议先理解 OAuth 2.0 和 OpenID 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 授权流程如下:
- 在你的应用中,让用户访问登录链接,浏览器跳转到 Authing,用户在 Authing 完成认证。
- 浏览器接收到一个从 Authing 服务器发来的授权码。
- 浏览器通过重定向将授权码发送到你的应用后端。
- 你的应用服务将授权码发送到 Authing 获取 AccessToken,如果需要,还会返回 refresh token。
- 你的应用后端现在知道了用户的身份,后续可以保存用户信息,重定向到前端其他页面,使用 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。
本文是否有解决您的问题?
如果遇到其他问题,你可以在 authing-chat/community 联系我们。