![](/contact/xiaochengxu.jpg)
![](/contact/xiaohongshu.jpg)
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 |
这是在浏览器中:
![代码流1](https://demo007x-articles.oss-cn-beijing.aliyuncs.com/demo007x-articles/202305220831619.png)
请注意,在新屏幕上,您将被重定向回redirect_uri
最初指定的页面:
![代码流2](https://demo007x-articles.oss-cn-beijing.aliyuncs.com/demo007x-articles/202305220831388.png)
在幕后,使用固定的用户名和密码建立会话。如果您自己部署此应用程序,当您单击该链接时,您将被重定向到登录,然后被重定向回同一页面。
在上面的屏幕截图中,您可以看到返回的代码和原始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
,这使得可以将附加信息编码到其中。
这是浏览器中的流程:
![隐式流 1](https://demo007x-articles.oss-cn-beijing.aliyuncs.com/demo007x-articles/202305220832759.png)
您将被重定向回redirect_uri
最初指定的位置(带有返回的令牌和 original state
)
![隐式流 2](https://demo007x-articles.oss-cn-beijing.aliyuncs.com/demo007x-articles/202305220832680.png)
应用程序现在可以在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
![混合流 1](https://demo007x-articles.oss-cn-beijing.aliyuncs.com/demo007x-articles/202305220832780.png)
您将被重定向回redirect_uri
最初指定的位置(带有返回的代码、令牌和 original state
):
![混合流 2](https://demo007x-articles.oss-cn-beijing.aliyuncs.com/demo007x-articles/202305220832381.png)
类似的帖子
![](/contact/xiaochengxu.jpg)
![](/contact/xiaohongshu.jpg)