OIDC的介绍

Mikey689

已于 2024-03-04 12:49:19 修改

阅读量1.6k

点赞数 16

文章标签：后端

于 2024-01-26 10:20:10 首次发布

本文链接：https://blog.csdn.net/weixin_65692248/article/details/135859821

版权

本文详细介绍了OIDC（OpenIDConnect）如何在OAuth2.0基础上增强身份验证，包括ID令牌的作用，以及AuthorizationCodeFlow、ImplicitFlow和HybridFlow三种流程的工作原理和适用场景。强调了在不同安全需求下选择合适的身份验证方法的重要性。

摘要由CSDN通过智能技术生成

一、OIDC概述

1.1 OpenID Connect简介

身份验证层：OIDC 在 OAuth 2.0 的基础上添加了一个身份验证层。它是一个标准化的身份层，使用OAuth 2.0协议来安全地认证用户身份。
用途：主要用于身份验证，即确认用户的身份并向第三方应用提供关于用户的基本信息。
ID 令牌：引入了ID令牌（ID Token），这是一个JSON Web Token（JWT），包含了用户的身份信息。
基于标准的协议：OIDC是一个开放标准，这意味着任何开发人员或组织都可以使用它来实现跨应用的安全身份验证。
灵活性和可扩展性：OIDC支持多种流程（如授权码流程、隐式流程和混合流程），这使得它可以适应各种应用场景，从简单的网页登录到复杂的企业级应用。

1.2 OAuth 2.0 概述

授权框架：OAuth 2.0 是一个广泛使用的授权框架，允许第三方应用在用户授权的情况下访问其在另一服务上的资源。
用途：主要用于授权，即允许应用访问用户在另一个服务（例如Facebook或Google）上的数据。
流程：OAuth 2.0 提供了多种授权流程（如授权码流程、客户端凭据流程），适用于不同类型的客户端（例如网页应用、移动应用）。

1.3 OIDC和OAuth2.0的区别

基于OAuth 2.0：OIDC 是在OAuth 2.0之上构建的。这意味着所有使用OAuth 2.0的应用理论上也可以实现OIDC。
目的：OAuth 2.0 专注于授权，允许应用访问用户在其他服务上的资源。而OIDC扩展了这一功能，提供了用户身份验证的机制。
兼容性：因为OIDC是对OAuth 2.0的扩展，所以在实现OIDC的同时，它自然支持OAuth 2.0的所有功能。实现OIDC的系统自动兼容OAuth 2.0。
ID令牌 vs 访问令牌：在OAuth 2.0中，客户端接收访问令牌（Access Token）来访问用户数据。而在OIDC中，客户端除了获得访问令牌，还会得到ID令牌，后者包含了用户的身份信息。

二、OIDC的工作原理

官方介绍:编辑How OpenID Connect Works - OpenID Foundation

三、协议流程

1.流程类型

流程由授权请求中包含的response_type值决定。

"response_type" value	Flow
`code`	Authorization Code Flow
`id_token`	Implicit Flow
`id_token token`	Implicit Flow
`code id_token`	Hybrid Flow
`code token`	Hybrid Flow
`code id_token token`	Hybrid Flow

2.Authorization Code Flow

1. 使用授权码流程进行身份验证

授权代码流程将授权代码返回给客户端，然后客户端可以直接将其交换为 ID 令牌和访问令牌。这样做的好处是不会向用户代理以及可能访问用户代理的其他恶意应用程序暴露任何令牌。授权服务器还可以在将授权代码交换为访问令牌之前对客户端进行身份验证。授权代码流程适用于可以在自己和授权服务器之间安全维护客户端密钥的客户端。

2.授权代码流程经历以下步骤。

客户端准备包含所需请求参数的身份验证请求。
客户端将请求发送到授权服务器。
授权服务器对最终用户进行身份验证。
授权服务器获得最终用户同意/授权。
授权服务器将最终用户连同授权代码发送回客户端。
客户端使用令牌端点处的授权代码请求响应。
客户端收到响应正文中包含 ID 令牌和访问令牌的响应。
客户端验证 ID 令牌并检索最终用户的主题标识符。

3.Implicit Flow

1.使用隐式流程进行身份验证

使用隐式流程时，所有令牌均从授权端点返回；未使用令牌端点。

隐式流程主要由使用脚本语言在浏览器中实现的客户端使用。访问令牌和 ID 令牌直接返回给客户端，这可能会将它们公开给最终用户和有权访问最终用户的用户代理的应用程序。授权服务器不执行客户端身份验证。

2.隐式流程步骤

客户端准备包含所需请求参数的身份验证请求。
客户端将请求发送到授权服务器。
授权服务器对最终用户进行身份验证。
授权服务器获得最终用户同意/授权。
授权服务器将最终用户连同 ID 令牌以及访问令牌（如果请求）发送回客户端。
客户端验证 ID 令牌并检索最终用户的主题标识符。

4.Hybrid Flow

1.使用混合流进行身份验证

使用混合流时，一些令牌从授权端点返回，另一些令牌从令牌端点返回。

2.混合流程步骤

客户端准备包含所需请求参数的身份验证请求。
客户端将请求发送到授权服务器。
授权服务器对最终用户进行身份验证。
授权服务器获得最终用户同意/授权。
授权服务器将最终用户连同授权代码以及一个或多个附加参数（根据响应类型）发送回客户端。
客户端使用令牌端点处的授权代码请求响应。
客户端收到响应正文中包含 ID 令牌和访问令牌的响应。
客户端验证 ID 令牌并检索最终用户的主题标识符。

该图片转载

四、应用场景

在OIDC中，授权码流（Authorization Code Flow）、隐式流（Implicit Flow）和混合流（Hybrid Flow）适用于不同的场景，根据安全需求和应用程序的性质选择不同的流程。

授权码流（Authorization Code Flow）：
- 使用场景：适合具有高安全要求的应用程序，特别是涉及敏感数据的应用程序。授权码流通过将授权码直接发送到服务器，而不是在浏览器中公开传输令牌，提供了更高的安全性。
- 工作方式：用户在应用程序中进行身份验证后，会重定向到授权服务器以获取授权码，然后应用程序使用该授权码与授权服务器交换访问令牌。
隐式流（Implicit Flow）：
- 使用场景：适合具有低安全要求的应用程序，特别是单页应用程序和移动应用程序。隐式流允许在浏览器中通过重定向返回令牌，从而避免了使用授权码，并简化了流程。
- 工作方式：用户在应用程序中进行身份验证后，将直接从授权服务器获取访问令牌，而不是先获取授权码。
混合流（Hybrid Flow）：
- 使用场景：适合需要同时满足高安全性和良好用户体验的应用程序，特别是涉及敏感数据的应用程序。混合流结合了授权码流和隐式流的优点，提供了更好的安全性和灵活性。
- 工作方式：用户在应用程序中进行身份验证后，会先获取授权码，然后使用授权码与授权服务器交换访问令牌。此外，还可以通过隐式流直接从授权服务器获取令牌，以提供更好的用户体验和性能。