单页应用程序（也称为基于浏览器的应用程序）在从网页加载 JavaScript 和 HTML 源代码后完全在浏览器中运行。由于浏览器可以使用整个源代码，因此它们无法维护客户端机密的机密性，因此这些应用程序不使用机密。因为他们不能使用客户端密码，所以最好的选择是使用 PKCE 扩展来保护重定向中的授权代码。这类似于也不能使用客户端密码的移动应用程序的解决方案。
高级概述是这样的： - 使用应用程序的客户端 ID、重定向 URL、状态和 PKCE 代码查询参数创建登录链接 - 用户看到授权提示并批准请求 - 使用授权码将用户重定向回应用程序的服务器 - 该应用程序交换访问令牌的授权代码
本节中我们将介绍如何在现有的 OAuth 2.0 服务器上访问您的数据。对于此示例，我们将使用 GitHub API 并构建一个简单的应用程序，该应用程序将列出登录用户的授权信息。本文中的代码实现是golang。
JWT 的好处是能够在其中携带信息。有了可用于您的应用程序的此信息，您可以轻松强制执行令牌过期并减少 API 调用次数。此外，由于它们经过加密，您可以验证它们是否未被篡改。
您从 OIDC 流返回的令牌和端点的内容/userinfo是请求的流类型和范围的函数。scope在这里，您可以为和设置不同的开关response_type，这决定了您应用程序的流类型。 您的用例将决定使用哪个流程。您是否正在构建需要直接与 OpenID 提供商 (OP) 交互的 SPA 或移动应用程序？您是否有将与 OP 交互的中间件，例如 Spring Boot 或 Node.js Express？下面，我们将深入探讨一些可用的流程以及何时适合使用它们。
您最近可能听说过一些关于 OAuth 2.0 隐式流程的讨论。OAuth 工作组发布了一些关于隐式流程和基于 JavaScript 的应用程序的新指南，特别指出不应再使用隐式流程。在本文中，我们将了解隐式流程发生了什么变化以及原因。
授权代码授权类型可能是您将遇到的最常见的 OAuth 2.0 授权类型。Web 应用程序和本机应用程序都使用它在用户授权应用程序后获取访问令牌。 这篇文章是我们探索常用的 OAuth 2.0 授权类型系列文章的第一部分。如果您想在深入了解 OAuth 2.0 之前稍微回顾一下并了解更多信息，请查看[OAuth 到底是什么？
跨源资源共享CORS，是一种基于HTTP头的机制，该机制通过允许服务器标示除了它自己以外的其他源（域、协议或端口），使得浏览器允许这些源访问加载自己的资源。跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求，该机制通过浏览器发起一个到服务器托管的跨源资源的“预检”请求。在预检中，浏览器发送的头中标示有 HTTP 方法和真实请求中会用到的头。
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
