OAuth2.0 OpenID Connect 二
OAuth2.0 OpenID Connect 二
在系列的第一部分中，我们了解了一些 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）：
