OAuth2.0 OpenID Connect 二

OAuth2.0 OpenID Connect 二

demo007x/oauth2-client: Oauth2 Client package for Golang (github.com) 欢迎star

在[本 OpenID Connect (OIDC)](./6-OpenID Connect一[4.15].md) 系列的第一部分中，我们了解了一些 OIDC 基础知识、它的历史以及涉及的各种流类型、范围和令牌。在这篇文章中，我们将深入探讨 OIDC 的机制，并了解各种流程的实际应用。

您从 OIDC 流返回的令牌和端点的内容/userinfo是请求的流类型和范围的函数。scope在这里，您可以为和设置不同的开关response_type，这决定了您应用程序的流类型。

您的用例将决定使用哪个流程。您是否正在构建需要直接与 OpenID 提供商 (OP) 交互的 SPA 或移动应用程序？您是否有将与 OP 交互的中间件，例如 Spring Boot 或 Node.js Express？下面，我们将深入探讨一些可用的流程以及何时适合使用它们。

从端点返回一个代码/authorization，可以使用端点交换 ID 和访问令牌/token。

当您有一个连接到 OIDC OP 的中间件客户端并且（不一定）希望令牌返回到最终用户应用程序（例如浏览器）时，这是一种合适的方法。这也意味着最终用户应用程序永远不需要知道密钥。

下面是这个流程如何使用 Okta 开始的示例：

https://micah.okta.com/oauth2/aus2yrcz7aMrmDAKZ1t7/v1/authorize?client_id=0oa2yrbf35Vcbom491t7&response_type=code&scope=openid&state=little-room-greasy-pie&nonce=b1e7b75d-6248-4fc7-bad0-ac5ae0f2e581&redirect_uri=https%3A%2F%2Fokta-oidc-fun.herokuapp.com%2Fflow_result

让我们分解一下：

Key	Value	Description
Organization URL	https://micah.okta.com	Okta Tenant
Authorization URL	/oauth2/aus2yrcz7aMrmDAKZ1t7/v1/authorize	Default authorization endpoint for your org
client_id	0oa2yrbf35Vcbom491t7	Client ID of the OIDC Application defined in Okta
response_type	code	The response type indicating code flow
scope	openid	openid scope is required
state	little-room-greasy-pie	Randon value is returned back at the end of the flow
nonce	b1e7b75d-6248-4fc7-bad0-ac5ae0f2e581	Random value to encode into the id_token for later validation
redirect_uri	https%3A%2F%2Fokta-oidc-fun.herokuapp.com%2Fflow_result	url-encoded url that the OP redirects to

这是在浏览器中：

请注意，在新屏幕上，您将被重定向回redirect_uri最初指定的页面：

在幕后，使用固定的用户名和密码建立会话。如果您自己部署此应用程序，当您单击该链接时，您将被重定向到登录，然后被重定向回同一页面。

在上面的屏幕截图中，您可以看到返回的代码和原始state.

现在可以通过中间层（在本例中为 Spring Boot 应用程序）将该代码交换为 和id_token。access_token这个中间层将验证我们之前在授权请求中发送的状态，并使用客户端密钥发出请求，为用户/token创建access_token和。id_token

隐式流程

本质上，访问和 ID 令牌是直接从/authorization端点返回的。端点/token未使用。

当您使用要与 OIDC OP 直接交互的客户端（例如单页应用程序或移动应用程序）时，这是一种合适的方法。

下面是这个流程如何使用 Okta 开始的示例：

https://micah.okta.com/oauth2/aus2yrcz7aMrmDAKZ1t7/v1/authorize?client_id=0oa2yrbf35Vcbom491t7&response_type=id_token+token&scope=openid&state=shrill-word-accessible-iron&nonce=f8c658f0-1eb9-4f8d-8692-5da4e2f24cf0&redirect_uri=https%3A%2F%2Fokta-oidc-fun.herokuapp.com%2Fflow_result

它与授权代码流程几乎相同，除了response_type是id_token,token或id_token+token。下面，我们将准确介绍这些令牌中的内容及其驱动方式，但请记住：一个id_token编码身份信息，一个access_token（如果指定则返回token）是用于访问资源的不记名令牌。Okta 还将 JWT 用于access_token，这使得可以将附加信息编码到其中。

这是浏览器中的流程：

您将被重定向回redirect_uri最初指定的位置（带有返回的令牌和 original state）

应用程序现在可以在id_token本地验证。使用/introspect端点验证access_token. 它还可以使用access_token作为不记名令牌来访问受保护的资源，例如端点/userinfo。

Hybrid Flow

在此流程中，一些令牌从授权端点 ( ) 返回/authorize，其他令牌从令牌端点 ( ) 返回/token。

当您希望最终用户应用程序能够立即访问短期令牌（例如身份信息）id_token，并且还希望使用后端服务使用刷新将授权代码交换为长期令牌时，这是一种合适的方法令牌。

它是授权代码和隐式代码流的组合。您可以通过查看它response_type必须包含的code和其中之一或两者id_token来发现它token：

https://micah.okta.com/oauth2/aus2yrcz7aMrmDAKZ1t7/v1/authorize?client_id=0oa2yrbf35Vcbom491t7&response_type=code+id_token+token&scope=openid&state=shrill-word-accessible-iron&nonce=f8c658f0-1eb9-4f8d-8692-5da4e2f24cf0&redirect_uri=https%3A%2F%2Fokta-oidc-fun.herokuapp.com%2Fflow_result

您将被重定向回redirect_uri最初指定的位置（带有返回的代码、令牌和 original state）：