Okta身份验证第2部分

选择OAuth 2.0流程：

本部分可帮助您基于以下几点选择OAuth流程。

1. 您需要的令牌类型。
2. 您正在构建的客户端应用程序的类型。

您的应用程序需要ID令牌吗？

根据下表，您可以选择所需的OAuth流程。

您要建立什么样的客户？

下面的流程图可以快速帮助您确定要使用的OAuth流。

对于本机应用程序，Okta使用带有证明密钥的授权代码流进行代码交换（PKCE）。

带有PKCE流的授权码：

对于本机/移动应用程序，客户端机密无法存储在应用程序中，因为它很容易被公开。 因此，本机应用程序应使用代码交换证明密钥（PKCE），该密钥作为秘密使用，以确保授权代码流的安全。

验证码流程相似，不同之处在于它包含各种流程中的PKCE元素。

PKCE身份验证代码流要求您的应用程序生成一个称为“代码验证程序”的加密随机密钥。 从验证程序创建一个“代码质询”，并将其与授权码请求一起传递。

在访问令牌请求中发送了授权代码后，代码验证程序将作为请求的一部分发送。 授权服务器使用哈希算法重新计算代码挑战，并比较两个代码挑战和验证者匹配，以了解客户端发送的两个请求。

带有PKCE的授权代码流是标准代码流，在开头有一个额外的步骤，在结尾有一个额外的验证。 从总体上讲，该流程包含以下步骤：

• 您的应用程序将生成一个代码验证器，然后是一个代码质询。
• 您的应用程序将浏览器与生成的代码质询一起定向到Okta登录页面，然后用户进行身份验证。
• Okta使用授权代码重定向回您的本机应用程序。
• 您的应用程序将此代码以及代码验证器发送到Okta。 Okta返回访问和ID令牌，以及可选的刷新令牌。
• 您的应用程序现在可以代表用户使用这些令牌来调用资源服务器（例如API）。

第3部分我将用示例解释OpenID Connect。 🙂

而已。 😃😃😃感谢您的阅读。

如果您想在社交媒体上关注我，这里有一些链接。 Linkedin ， twitter ， github 。

您可以 在这里 查看我的上一篇文章 。