OAuth 2.0和OpenID Connect概述

OAuth 2.0 和 OpenID Connect （OIDC）是用于用户身份验证和授权的行业标准协议。Okta 身份解决方案基于这些标准。

OAuth 2.0 与 OpenID Connect

OAuth 2.0 和 OpenID Connect （OIDC）是互补协议。它们定义服务器如何对用户进行身份验证，然后授予用户对资源的访问权限。

OAuth 2.0 版本（打开新窗口）控制并委派访问受保护资源（如 Web 应用程序、本机应用程序或 API 服务）的授权。它通过限定范围的访问令牌提供 API 安全性。
OIDC （打开新窗口）通过用户身份验证和单点登录（SSO）功能扩展了 OAuth 2.0。它使您能够检索和存储有关最终用户的身份验证信息。它还定义了多个 OAuth 2.0 范围，使应用程序能够访问用户配置文件信息。

Okta 建议使用其身份验证部署模型之一来满足应用程序的身份验证需求。每个模型都抽象了 OAuth 2.0 和 OIDC 协议，因此您不必直接使用它们。

提示：如果您需要自定义应用程序设置和工作流程，并可以直接访问您的 Okta 组织和应用程序集成，请使用Authentication API。此 API 支持 Okta 重定向模型、嵌入式登录小部件和身份验证 JS 开发工具包。

OAuth 2.0 版本

OAuth 2.0 是一种标准，应用程序通过该标准向客户端应用程序提供访问权限。如果您希望以一种安全的方式授予对您应用数据的访问权限，那么您应该使用 OAuth 2.0 协议。

OAuth 2.0 规范有四个重要角色：

客户端：想要访问某些数据的应用程序。
资源服务器：存储客户端要访问的数据的 API 或应用程序。
资源所有者：资源服务器上数据的所有者。例如，您是 Facebook 个人主页的所有者。
授权服务器：管理访问并颁发访问令牌的服务器。在本例中，Okta 是授权服务器。

其他重要术语：

OAuth 2.0 授权：用户授予（或授予）给客户端的授权。授权的示例包括 Authorization Code 和 Client Credentials。每个 OAuth 授权都有相应的流程。
access token：授权服务器（Okta）为换取授权而颁发的令牌。
refresh token：如果访问令牌已过期，则交换为新访问令牌的可选令牌。

下面介绍了常用的 OAuth 2.0 授权代码流程。

客户端向资源所有者（通常是用户）请求授权。
如果所有者授予授权，则客户端会将授权授予传递给授权服务器（在本例中为 Okta）。
如果授权有效，则授权服务器将返回访问令牌，可能与刷新和/或 ID 令牌一起返回。
客户端现在使用该访问令牌访问资源服务器。

OAuth 2.0 和 OIDC（OpenID Connect）的核心都是授权服务器。授权服务器本质上就是一个 OAuth 2.0 令牌生成引擎。每个授权服务器都有一个唯一的发行者 URI（Uniform Resource Identifier，统一资源标识符）和自己的令牌签名密钥，以确保安全域之间有明显的界限。在本指南的上下文中，Okta 就是您的授权服务器。

授权服务器还充当 OIDC 提供程序。这意味着您可以请求ID 令牌（打开新窗口）除了访问令牌（打开新窗口）从授权服务器端点。

OpenID 连接

OpenID Connect (OIDC) 是一个在 OAuth 2.0 基础上构建的身份验证标准。它定义了一种 ID 令牌类型，与 OAuth 2.0 的访问令牌和刷新令牌配合使用。此外，OIDC 还对 OAuth 2.0 中留待选择的一些领域进行了标准化，如作用域（scopes）、端点发现（endpoint discovery）以及客户端的动态注册（dynamic registration）。Okta 已获得 OpenID 认证。

尽管 OIDC 扩展了 OAuth 2.0，但OIDC 规范（打开新窗口）对流中的角色使用略有不同的术语：

OpenID 提供程序：颁发 ID 令牌的授权服务器。在这种情况下，Okta 是 OpenID 提供商。
end user：ID 令牌中包含的最终用户信息。
信赖方：从 Okta 请求 ID 令牌的客户端应用程序。
ID 令牌：由 OpenID 提供程序颁发的令牌，其中包含有关声明形式的最终用户的信息。
claim：claim是有关最终用户的一条信息。

OpenID Connect 和常规 OAuth 2.0 流的高级流看起来相同。主要区别在于，OpenID Connect 流除了会生成任何访问令牌或刷新令牌外，还会生成 ID 令牌。

选择 OAuth 2.0 流程

您使用的 OAuth 流程取决于您的使用案例。以下部分根据以下因素推荐 OAuth 2.0 流程：

您正在构建的应用程序类型以及应用程序所需的令牌类型
您正在构建的客户端类型

您正在构建什么类型的应用程序？

下表显示了要用于您正在构建的应用程序类型的 OAuth 2.0 流程。

应用程序类型	OAuth 2.0 流程/授权类型	访问令牌？	ID 令牌？
服务器端（又名 Web）、单页应用程序或本机	带有 PKCE 或交互代码的授权代码（仅限身份引擎）。	✅	✅
信任	交互代码	✅	✅
服务	客户端凭证	✅	❌

注意：还有一个 OAuth 2.0 SAML 2.0 断言流。此流程适用于希望使用现有信任关系而无需在授权服务器上执行直接用户批准步骤的客户端应用程序。它支持 access 令牌和 ID 令牌。

您正在构建什么样的客户端？

OAuth 2.0 流的类型取决于您要构建的客户端类型。此流程图可以快速帮助您决定使用哪个流程。

您的客户是公开的吗？

单页应用（SPA）、移动应用和原生应用都属于公开应用，终端用户可以查看甚至可能修改应用的源代码。代码中的任何敏感信息都可能暴露给恶意用户。相比之下，服务器端（Web）应用和桌面应用属于机密或私有应用。机密客户端可以使用客户端认证方法，如客户端密钥和私钥。

您的客户使用的是重定向模型还是嵌入式模型？

重定向模型

如果您的 SPA 或本机应用程序将身份验证请求重定向到 Okta 托管的登录页面，请使用带有 PKCE 的授权码流程。

嵌入式模型

如果您的应用程序本身托管身份验证流，请使用 Interaction Code 流。

客户端是否有最终用户？

一个在没有直接终端用户参与的服务器上运行的客户端应用可以被信任为能够负责任地使用其自身的凭据。如果您的客户端应用仅进行机器到机器的交互，那么您应该使用客户端凭据流（Client Credentials Flow）。

您的应用是否受到高度信任？

如果您既拥有某个应用，又拥有该应用所访问的资源，那么这个应用就是高可信度的。因为您对这两者都拥有所有权，所以您可以信任该应用能够妥善处理终端用户的用户名和密码。在这种情况下，并且仅当其他认证流程不可行时，您可以使用资源所有者密码凭据流程（Resource Owner Password Credentials Flow，简称资源密码流）。但是，该流程不支持多因素身份验证，因此请考虑使用其他替代方案，如授权码流程

如果您的应用程序不是高信任度，或者您想要利用多重身份验证，则应使用授权代码流程。

具有 PKCE 流的授权代码流

代码交换的证明密钥（PKCE）最初设计为保护移动应用程序中的授权代码流的扩展。但是，它能够防止授权代码注入并保持流程安全，因此非常适合各种类型的 OAuth 客户端。Okta 建议您尽可能将授权代码流程与 PKCE 一起用于 OAuth 客户端。

该流程要求您的应用生成一个加密随机字符串，称为代码验证程序。然后，对代码验证程序进行哈希处理以创建代码质询，并且此质询与授权代码请求一起传递。授权服务器使用授权码进行响应，并将代码质询与授权码相关联。

应用程序收到授权码后，它会在访问令牌请求中发送授权码和代码验证器。授权服务器使用先前商定的哈希算法重新计算验证程序的质询。然后，授权服务器将挑战码与之前与授权码关联的挑战码进行比较。如果两个挑战码和验证器相匹配，授权服务器就知道这两个请求是由同一个客户端发送的。

显示使用 PKCE 的授权代码流的资源所有者、授权服务器和资源服务器之间的交互的序列图

交互代码流

交互代码流程扩展了 OAuth 2.0 和 OIDC 标准。它要求客户端将客户端 ID 和 PKCE 参数传递给 Okta，以确保流的安全。用户可以用最少的信息启动请求，依靠客户端来促进与 Okta 的交互以验证用户身份。

注意：交互代码流仅在 Identity Engine 组织中可用。

资源所有者密码流

资源所有者密码流适用于以下使用案例：

您可以控制客户端应用程序及其与之交互的资源。
客户端可以存储客户端密钥，并且可以使用资源所有者的凭证进行信任。
您不需要用户使用多重身份验证。

它最常见于为在线服务制作的第一方客户端中，比如与Facebook服务交互的Facebook客户端应用。它不需要像授权码流程或隐式流程那样进行重定向，而是只涉及对端点的一次经过身份验证的调用。/token

显示资源所有者、授权服务器和资源服务器之间的交互的序列图 Resource Owner Password 流

客户端凭据流

客户端凭据流适用于没有最终用户的服务器端（机密）客户端应用程序。通常，这意味着机器对机器的通信。该应用需要是服务器端应用，因为它必须能够安全地保管客户端密钥。由于凭证是硬编码的，因此实际的终端用户无法使用它。该流程涉及向端点发送一个经过身份验证的请求，该请求将返回一个访问令牌。/token

注意：客户端凭证流不支持刷新令牌。

显示 Client Credentials 流的资源所有者、授权服务器和资源服务器之间交互的序列图

SAML 2.0 断言流

此流程适用于无需在授权服务器上直接获取用户批准，而是利用现有信任关系的客户端应用。它允许客户端应用从SAML身份提供者（Identity Provider）处获得一个有效且已签名的SAML断言，并以此断言来从OAuth授权服务器处获取一个OAuth访问令牌。例如，当您希望从仅支持委托权限而无需提示用户输入凭据的API中检索数据时，此流程就非常有用。

要使用 SAML 2.0 断言作为授权授予，客户端需要向身份提供商发出 SAML 请求。然后，身份提供商在响应中发送回 SAML 2.0 断言。然后，客户端请求具有授权类型的访问令牌并包含该参数。该参数的值是 Base64 编码的 SAML 2.0 断言。在该请求中，您只能发送一个 SAML 断言。urn:ietf:params:oauth:grant-type:saml2-bearerassertionassertion

显示 SAML 2.0 断言流的序列图，该流显示资源所有者、授权服务器、身份提供者和客户端之间的交互”

隐式流

注意：隐式流是仅用于不支持 PKCE 的 SPA 的旧流。

隐式流程（Implicit Flow）旨在为不支持跨源资源共享（CORS）的基于浏览器的应用而设计。此外，它还适用于缺乏现代加密API且无法保护客户端密钥的基于浏览器的应用。在此流程中，客户端不会向端点发送请求，而是在从端点重定向的过程中接收访问令牌。客户端必须能够与资源所有者的用户代理交互，并接收来自授权服务器的传入请求（通过重定向）。/token/authorize