Laravel 新闻

说到 Laravel 中的认证，有很多选择。但是，当谈到 API 认证时，我们应该使用什么呢？

传统上，我们会依赖于像 JSON Web Token 这样的东西来进行 API 认证，类似于基于会话的 Web 认证。您用凭据交换一些可以提供您长时间访问的东西。

然后，我们开始使用 Laravel Passport，这是一个出色的 OAuth 实现，您可以使用它来为您的 Laravel 应用程序提供 OAuth 访问权限，无论是服务器到服务器认证、移动认证还是其他类型的认证。很长一段时间，我们坚持使用 Laravel Passport 和密码授权类型，这使我们能够将我们的凭据与 OAuth 应用程序详细信息一起发送，然后我们会得到一个访问令牌和一个刷新令牌 - 使我们能够访问并能够在令牌过期时刷新该访问权限。但是，这种方式不再被推荐作为我们以前使用的认证机制。

那么我们现在该怎么办？Sanctum 是唯一推荐的选择吗？好吧，是也不是。Sanctum 被设计为 Passport 的轻量级替代品，但实际上，它已经实现了比这更多的东西。无论您是在构建 Web 应用程序、客户端实现还是介于两者之间的东西 - sanctum 已经迅速成为 Laravel 生态系统中金标准的认证机制。

那么，这对 API 意味着什么呢？我们每次想要认证时都需要传递令牌名称吗？当然，您可以这样做 - 这不会伤害任何人。但是，如何在 Laravel 中对我的 API 进行认证？

让我们来看看我的方法，看看它为什么有效/有意义。它始于用户的凭据 - 就像任何合适的认证机制一样。我们将这些凭据发送到我们的登录或注册端点 - Laravel 为我们做一些魔法 (取决于我们使用的包)。

假设我们使用的是 Laravel Breeze 或 Jetstream。在这种情况下，提供的认证将为我们创建一个基于会话的 cookie - 我们的实现随后可以将其用于每个后续请求以证明其已认证状态。现在，这让我有点困惑。我在想我的令牌应该在哪里，除了 cookie 之外，我还有什么东西可以证明我已认证？我一直习惯于处理这个令牌或那个令牌，这样我就可以使用它来证明我的身份。cookie 是用于 Web 的，对吧？我没有把我的 API 看作一个 Web API，这表明我们有时都会有点天真。

假设我要构建一个 CLI 应用程序、移动应用程序，或者一些需要与我的本地系统一起作为可安装内容工作的集成。在这种情况下，我们可以使用 Sanctum 传递一个名称来创建需要存储的令牌 - 这感觉很自然。但是，我们的 API 可能通过单页应用程序进行集成 - 甚至另一个也使用 Laravel 构建的应用程序。这部分并不重要，因为它不是我们正在安装的东西。

处理认证的最佳方法是遵循我所谓的简单指南。

您正在构建一些被访问，而不是被安装的东西。在这种情况下，您应该使用 Laravel Sanctum 以及基于 cookie 的认证。可以将 cookie 配置为与您的访问需求一样长或短，当访问停止时，认证也可以停止。

您正在构建一些安装在用户设备上的东西。在这里，我们需要做出几个选择。访问是否需要基于身份控制？换句话说 - 应用程序是否可以访问所有内容，并且没有授权层？如果是这种情况，使用客户端凭据的 Laravel Passport 是一个不错的选择。Laravel Passport 有一种授权类型称为客户端凭据：您认证一个客户端而不是一个用户 - 因此任何拥有客户端访问权限的人都可以控制系统。您可以使用 PKCE 进一步实现这一点，在 PKCE 中，您无法保证客户端秘密的机密性。

如果您需要认证一个用户而不是一个客户端 - 那么请依靠 Laravel Sanctum，并为已安装的应用程序传递一个唯一的名称 - 这样您就可以存储提供的令牌并重复使用它。

使用 Laravel Sanctum 的最大问题是，您必须获取一个跨站点请求 cookie 来向您的 Laravel API 发出请求。当构建一个 SPA 时，这不是问题，并且比将 JSON Web Token 存储在本地存储中是一个更好的方法。