jamstack上的API和身份验证-css教程-PHP中文网

首页

web前端

css教程

jamstack上的API和身份验证

尊渡假赌尊渡假赌尊渡假赌

Apr 08, 2025 am 09:32 AM

APIs and Authentication on the Jamstack

Jamstack架构的核心在于“APIs”（应用程序接口），它赋予静态网站强大的动态功能。通过APIs，开发者可以将复杂性转移，并为静态网站添加动态功能。访问API通常需要验证请求的真实性，这通常以身份验证（Auth）的形式出现，可以根据所使用的服务和要完成的任务在客户端或服务器端进行。

各种协议的差异导致API的身份验证实现各不相同。这些身份验证协议和实现细节在将API集成到Jamstack站点时增加了额外的挑战。幸运的是，这并非毫无章法。每种协议都可以映射到特定的用例，实现身份验证的关键在于理解这一点。

为了更好地说明这一点，让我们深入探讨各种协议及其最适合的场景。

协议概述

OAuth 2.0是当今身份验证遵循的通用标准。OAuth是一个相当灵活的授权框架，它包含一系列授权，定义了客户端和API端点之间的关系。在OAuth流程中，客户端应用程序向授权端点请求访问令牌，并使用该令牌为API端点签名请求。

主要有四种授权类型——授权码、隐式流程、资源所有者密码和客户端凭据。我们将分别研究每一种。

授权码授权

在所有OAuth授权类型中，授权码授权可能是最常见的。此授权流程主要用于在用户明确授予权限后获取访问令牌以授权API请求，它遵循两步过程：

首先，用户会被引导到同意屏幕（即授权服务器），在那里他们授予服务访问其个人帐户和数据的权限。
一旦获得权限，下一步就是从身份验证服务器检索访问令牌，然后可以使用该令牌对API端点的请求进行身份验证。

与其他授权类型相比，授权码授权通过增加请求用户明确授权的步骤，增加了额外的安全层。这种多步骤代码交换意味着访问令牌永远不会暴露，并且始终通过应用程序和授权服务器之间的安全后端通道发送。这样，攻击者就无法通过拦截请求轻松窃取访问令牌。谷歌拥有的服务（如Gmail和Google日历）利用此授权码流程来访问用户帐户中的个人内容。如果您想更深入地了解此工作流程，请查看此博文以了解更多信息。

隐式授权

隐式授权类似于授权码授权，但有一个明显的区别：它不是让用户授予权限以检索授权码，然后将其交换为访问令牌，而是通过重定向URL的片段（哈希）部分（即前通道）立即返回访问令牌。

由于减少了授权码步骤，隐式授权流程存在令牌暴露的风险。由于令牌直接嵌入到URL中（并记录到浏览器历史记录中），如果重定向被拦截，则很容易访问。

尽管存在漏洞，但隐式授权对于基于用户代理的客户端（如单页应用程序）很有用。由于客户端呈现的应用程序中可以轻松访问应用程序代码和存储，因此没有安全的方法来保护客户端密钥。隐式流程通过为应用程序提供一种快速简便的方式来在客户端对用户进行身份验证，从而成为解决此问题的逻辑方法。它也是解决CORS问题的有效方法，尤其是在使用不支持跨域请求的第三方授权服务器时。由于这种方法固有的令牌暴露风险，需要注意的是，隐式流程中的访问令牌往往是短暂的，并且永远不会发出刷新令牌。因此，此流程可能需要为每个对特权资源的请求登录。

资源所有者密码授权

在资源所有者密码授权的情况下，资源所有者将其用户名和密码凭据发送到授权服务器，然后授权服务器发送回带有可选刷新令牌的访问令牌。由于资源所有者凭据在客户端应用程序和授权服务器之间的授权交换中可见，因此资源所有者和客户端应用程序之间必须存在信任关系。尽管显然不如其他授权类型安全，但资源所有者密码授权为第一方客户端提供了极佳的用户体验。此授权流程最适合应用程序具有高度特权或在设备操作系统中工作的情况。当其他流程不可行时，此授权流程通常用于。

客户端凭据授权

客户端凭据授权类型主要用于客户端需要在用户上下文之外获取访问令牌时。当无法保证对受保护资源的每次访问都获得用户的明确许可时，这适用于机器到机器身份验证。CLI和在后端运行的服务是此授权类型派上用场的实例。它不依赖于用户登录，而是传递客户端ID和密钥以获取令牌，然后可以使用该令牌对API请求进行身份验证。

通常，在客户端凭据授权中，会建立一个服务帐户，应用程序通过该帐户运行并进行API调用。这样，用户不会直接参与，并且应用程序仍然可以继续对请求进行身份验证。此工作流程在应用程序想要访问其自身数据（例如分析）而不是特定用户数据的情况下相当常见。