安全¶

处理安全、认证和授权的方式有很多。

通常这是一个复杂且“困难”的话题。

在许多框架和系统中，仅处理安全和认证就需要大量的工作和代码（在许多情况下，它可能占所有编写代码的 50% 或更多）。

FastAPI 提供了多种工具，帮助你以简单、快速、标准的方式处理**安全**问题，而无需研究和学习所有安全规范。

但首先，让我们检查一些小的概念。

赶时间？¶

如果你不关心这些术语，只是需要立即添加基于用户名和密码的认证安全机制，请跳到下一章。

OAuth2 是一个定义了多种处理认证和授权方式的规范。

它是一个相当广泛的规范，涵盖了多个复杂的用例。

它包括使用“第三方”进行认证的方式。

这就是所有“使用 Facebook、Google、Twitter、GitHub 登录”的系统底层所使用的技术。

曾经有一个 OAuth 1，它与 OAuth2 非常不同，并且更为复杂，因为它直接包含了如何加密通信的规范。

如今它并不流行或被广泛使用。

OAuth2 没有规定如何加密通信，它假设你的应用程序通过 HTTPS 提供服务。

/// 提示

在关于**部署**的部分，你将看到如何使用 Traefik 和 Let's Encrypt 免费设置 HTTPS。

///

OpenID Connect 是另一个基于 OAuth2 的规范。

它只是扩展了 OAuth2，澄清了一些在 OAuth2 中相对模糊的内容，试图使其更具互操作性。

例如，Google 登录使用 OpenID Connect（底层使用 OAuth2）。

但 Facebook 登录不支持 OpenID Connect。它有自己的 OAuth2 风格。

还有一个名为“OpenID”的规范。它试图解决与 OpenID Connect 相同的问题，但不是基于 OAuth2。

因此，它是一个完全独立的系统。

如今它并不流行或被广泛使用。

OpenAPI（以前称为 Swagger）是构建 API 的开放规范（现在是 Linux 基金会的一部分）。

FastAPI 基于 OpenAPI。

这就是为什么它能够支持多种自动交互式文档界面、代码生成等功能。

OpenAPI 有一种定义多种安全“方案”的方式。

通过使用这些方案，你可以利用所有这些基于标准的工具，包括这些交互式文档系统。

OpenAPI 定义了以下安全方案：

apiKey：一个特定于应用程序的密钥，可以来自：
- 查询参数。
- 头部。
- cookie。
http：标准的 HTTP 认证系统，包括：
- bearer：一个值为 Bearer 加上令牌的 Authorization 头部。这是从 OAuth2 继承的。
- HTTP Basic 认证。
- HTTP Digest 等。
oauth2：所有 OAuth2 处理安全的方式（称为“流程”）。
- 其中几种流程适合构建 OAuth 2.0 认证提供者（如 Google、Facebook、Twitter、GitHub 等）：
  - implicit
  - clientCredentials
  - authorizationCode
- 但有一个特定的“流程”可以完美地用于直接在同一应用程序中处理认证：
  - password：接下来的几章将涵盖此示例。
openIdConnect：有一种定义如何自动发现 OAuth2 认证数据的方式。
- 这种自动发现是在 OpenID Connect 规范中定义的。

/// 提示

集成其他认证/授权提供者（如 Google、Facebook、Twitter、GitHub 等）也是可能且相对容易的。

最复杂的问题是构建像这些一样的认证/授权提供者，但 FastAPI 为你提供了轻松完成此任务的工具，同时为你处理了繁重的工作。

///

FastAPI 在 fastapi.security 模块中为每种安全方案提供了多种工具，简化了这些安全机制的使用。

在接下来的章节中，你将看到如何使用 FastAPI 提供的这些工具为你的 API 添加安全机制。

你还将看到它如何自动集成到交互式文档系统中。