安全性¶

處理安全性、驗證和授權的方式有很多種。

這通常是一個複雜且「困難」的主題。

在許多框架和系統中，僅僅處理安全性和驗證就需要大量的精力和程式碼（在許多情況下，它可能佔所有編寫程式碼的 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：一個標頭 Authorization，其值為 Bearer 加上一個權杖。這是繼承自 OAuth2 的。
- HTTP 基本驗證。
- 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 新增安全性。

您還會看到它如何自動整合到互動式文件系統中。