Jamstack 上的 API 和身份验证

Jamstack 中的第一个“A”代表“API”，它是使静态站点工作如此强大的关键因素。API 让开发者可以自由地卸载复杂性，并为在静态站点中添加动态功能提供途径。通常，访问 API 需要验证请求的真实性。这通常以身份验证（auth）的形式出现，可以根据所用服务和正在执行的任务在客户端或服务器端进行。 

鉴于可用协议的广阔范围，API 在其各自的身份验证实现方面有所不同。这些身份验证协议和实现细节在将 API 集成到 Jamstack 站点时增加了额外的挑战。值得庆幸的是，这种混乱是有方法的。每个协议都可以映射到特定的用例，而实现身份验证只是理解这一点的问题。

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

召唤协议

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

主要有四种授权类型 - 授权码、隐式流、资源所有者凭据和客户端凭据。我们将分别查看它们。

授权码授权

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

• 首先，用户会被定向到同意屏幕，也称为授权服务器，在那里他们授予该服务对其个人帐户和数据的限制性访问权限。
• 一旦获得许可，下一步就是从身份验证服务器检索访问令牌，然后可以将其用于对 API 端点的请求进行身份验证。

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

隐式授权

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

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

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

资源所有者凭据

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

客户端凭据

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

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

结论

Jamstack 站点依赖第三方服务来实现复杂功能，因此精心设计的身份验证解决方案对于维护 Jamstack 站点的安全性至关重要。API 是在 Jamstack 中交换数据的主要方式，是其中的重要组成部分。我们介绍了四种不同的 API 请求身份验证方法，每种方法都有其优点和对用户体验的影响。

我们在开头提到，这四种是用于向 API 请求数据的主要身份验证形式。还有很多其他类型，在 oauth.net 上有很好的概述。整个网站是对可用身份验证类型和 OAuth 框架本身的深入介绍。

您是否偏爱其中一种方法？您是否有可以指出的使用示例？请在评论中分享！