OIDC & OAuth2.0 协议及其授权模式详解|认证协议最佳实践系列【1】_百 ...
发布网友
发布时间：2024-10-16 12:18
共1个回答
热心网友
时间：2024-10-16 17:38
在数字时代，安全地访问用户的资源成为了一个重要的课题。为了实现这一目标，OIDC（OpenID Connect）和OAuth2.0应运而生，它们提供了一种开放标准，用于应用程序安全访问用户资源，而无需泄露用户凭据。通过这些标准协议，我们可以建立统一的用户目录和认证中心，实现业务系统的集中化管理，避免了每个系统都需独立构建用户体系的不便与风险。
本文将深入探讨OAuth2.0与OIDC及其授权模式，以帮助您理解这些协议如何工作以及如何在不同场景下应用。
1. 协议介绍
1.1 OAuth 2.0与OIDC
OAuth 2.0是一个授权框架，允许应用程序以安全方式访问HTTP服务上的用户帐户，如Facebook、GitHub和DigitalOcean。它通过将用户认证委托给托管用户帐户的服务，并授权第三方应用程序访问用户帐户来实现。OpenID Connect (OIDC)则建立在OAuth 2.0之上，提供了一个简单身份层，在OAuth 2.0授权的基础上添加了认证功能。简单来说，OIDC在OAuth2.0的基础上提供了用户认证、获取用户信息的标准实现。我们推荐使用OIDC，因为它兼容OAuth2.0，且提供了一站式解决方案。
1.2 术语介绍
在理解协议交互时，有几个关键角色需要了解。这些角色在授权模式介绍中将被详细阐述，以便更好地理解不同模式的流程。
1.3 Client类型介绍
OAuth2.0和OIDC定义了两种客户端类型：机密型应用（Confidential Clients）和公共型应用（Public Clients）。
机密型应用（Confidential Clients）：能够安全存储凭证（client_secret），适合有后端服务的应用场景，如Vue前端+Java后台，可以使用授权码模式。
公共型应用（Public Clients）：无法安全存储凭证，如单页应用（SPA）、移动端或完全前后端分离应用，应使用授权码+PKCE模式。
1.4 OIDC授权模式与选型建议
选择合适的授权模式对于系统安全和开发效率至关重要。下面详细介绍了不同授权模式及其适用场景。
2. 授权模式详细介绍
2.1 授权码模式（Authorization Code）
授权码模式适合具备后端服务器的应用场景。它要求应用能够安全地存储密钥，用于后续的授权码换Access Token。流程包括认证授权、通过浏览器重定向将授权码发送给后端服务，以及使用授权码换Token和Token换用户信息。
2.2 授权码+PKCE模式（Authorization Code With PKCE）
对于SPA、移动端或无法安全存储密钥的应用，推荐使用授权码+PKCE模式。它涉及code_verifier和code_challenge的生成和验证，确保应用在不能安全存储密钥的情况下进行安全认证。
2.3 客户端凭证模式（Client Credentials）
适用于服务器间授权（M2M）场景，无需用户参与。在这种模式下，应用需要创建编程访问账号，并将AK、SK密钥对提供给资源调用方。注意，此模式不支持Refresh Token。
2.4 隐式模式（Implicit）（不推荐）
隐式模式适用于无法安全存储密钥的场景，如前端浏览器。它不推荐使用，因为它在认证过程中不通过code换token，且不支持获取Refresh Token。流程直接返回AccessToken和IdToken。
2.5 密码模式（Password）（不推荐）
密码模式不推荐使用，除非在特定情况下作为最后选择。它通常用于集成非常古老的应用。使用时确保代码逻辑极其安全，以防止用户凭证泄露。
2.6 设备代码模式（Device Code）（几乎用不到）
设备代码模式主要针对连接到互联网的输入受限设备，允许用户通过链接或二维码在手机或电脑上进行认证，以提升用户体验。此模式与前面介绍的模式不同，客户端从发起认证变为响应认证请求。
一个设计良好的系统需要一个标准、安全、可扩展的用户认证协议。在接下来的内容中，我们将详细介绍如何将授权码模式、授权码+PKCE模式、客户端凭证模式集成到Authing中。敬请期待！
