【NGINX--5】身份驗證

1、HTTP 基本身份驗證

需要通過 HTTP 基本身份驗證保護應用或內容。

生成以下格式的文件，其中的密碼使用某個受支持的格式進行了加密或哈希處理：

# comment 
name1:password1 
name2:password2:comment 
name3:password3

第一個字段是用戶名，第二個字段是密碼，冒號是分隔符。第三個字段為可選項，您可以使用該字段對每個用戶進行評論。NGINX 能理解幾種不同的密碼格式，其中一個是使用 C 函數 crypt() 加密的密碼。該函數通過 openssl passwd 命令暴露在命令行中。安裝 openssl 后，您可以使用以下命令創建加密的密碼字符串：

$ openssl passwd MyPassword1234

輸出結果將是一個字符串，可供 NGINX 在密碼文件中使用。
在 NGINX 配置中使用 auth_basic 和 auth_basic_user_file 指令，實現基本身份驗證：

location / {auth_basic "Private site"; auth_basic_user_file conf.d/passwd;
}

您可以在 http、server 或 location 上下文中使用 auth_basic 指令。auth_basic 指令帶一個字符串參數，如有未經授權的用戶訪問，該參數將顯示在基本身份驗證彈窗中。auth_basic_user_file 指定了用戶文件的路徑。
如要測試配置，您可以使用帶 -u 或 --user 標志的 curl 來構建請求的 Authorization 請
求頭：

$ curl --user myuser:MyPassword1234 https://localhost

詳解
您可以通過幾種方式生成具有不同格式和安全等級的基本身份驗證密碼。Apache 的htpasswd 命令也可以生成密碼。openssl 和 htpasswd 都可以使用 apr1 算法生成密碼，并且 NGINX 也能理解這種格式的密碼。該密碼也可以是輕型目錄訪問協議（LDAP）和 Dovecot 使用的 Salted SHA-1 格式。NGINX 支持其他更多格式和哈希算法；然而，許多算法容易遭到暴力破解攻擊，因此人們認為這些算法不安全。

您可以使用基本身份驗證來保護整個 NGINX 主機的上下文、特定的虛擬服務器甚至只是特定的 location 代碼塊。基本身份驗證不會取代 Web 應用的用戶身份驗證，但可以保護私人信息的安全。實際上，基本身份驗證是由服務器返回 401 Unauthorized HTTP 代碼和響應頭 WWW-Authenticate 完成的。該響應頭的值為Basic realm=“your string”。收到此響應后，瀏覽器將提示輸入用戶名和密碼。用戶名和密碼用冒號連接和分隔，然后用 base64 編碼，最后在名為 Authorization 的請求頭中發送。Authorization 請求頭將指定一個 Basic 和 user:password 編碼字符串。服務器對請求頭進行解碼，并根據提供的 auth_basic_user_file 進行驗證。由于用戶名和密碼字符串僅通過 base64 編碼，我們建議在基本身份驗證中使用 HTTPS。

2、身份驗證子請求

希望通過第三方身份驗證系對請求進行身份驗證。

使用 http_auth_request_module 請求訪問身份驗證服務，在響應請求之前驗證身份：

location /private/ { auth_request /auth;auth_request_set $auth_status $upstream_status;
}
location = /auth { internal;proxy_pass http://auth-server; proxy_pass_request_body off; proxy_set_header Content-Length "";proxy_set_header X-Original-URI $request_uri;
}

auth_request 指令帶一個 URI 參數，該參數必須是本地內部位置。auth_request_set 指令允許您設置身份驗證子請求的變量。
詳解
http_auth_request_module 可驗證 NGINX 服務器處理的每個請求的身份。該模塊將使用子請求來確定是否授予請求訪問權。子請求是指 NGINX 將請求傳遞給內部替代位置，并在將請求路由到目的地之前觀察它的響應。auth 位置將原始請求（包括正文和請求頭）傳遞到身份驗證服務器。子請求的 HTTP 狀態碼決定是否授予請求訪問權。如果子請求返回 HTTP 200 狀態碼，則表示身份驗證成功，請求已完成。如果子請求返回HTTP 401 或 403，則原始請求也將返回 HTTP 401 或 403。

如果您的身份驗證服務未請求請求正文，則可以使用 proxy_pass_request_body 指令刪除請求正文，如上所示。這種做法可減少請求的大小和時間。由于響應正文被丟棄，Content-Length 請求頭必須設置為空字符串。如果身份驗證服務需要知道請求訪問的URI，則需要將該值放入身份驗證服務檢查和驗證的自定義請求頭中。如果您確實希望將子請求中的某些內容保留給身份驗證服務（例如響應頭或其他信息），您可以使用auth_request_set 指令從響應數據中創建新的變量。

3、使用 NGINX Plus 驗證 JWT

需要在使用 NGINX Plus 處理請求之前驗證 JWT。

使用 NGINX Plus 的 HTTP JWT 身份驗證模塊來驗證令牌簽名，并將 JWT 聲明和請求頭作為 NGINX 變量嵌入：

location /api/ {auth_jwt "api"; auth_jwt_key_file conf/keys.json;
}

此配置可以驗證該位置的 JWT。auth_jwt 指令傳遞一個字符串，該字符串被用作身份驗證領域。auth_jwt 配置帶一個保存 JWT 的變量的可選令牌參數。默認情況下，根據JWT 標準使用 Authentication 請求頭。auth_jwt 指令還可用于從繼承的配置中消除所需的 JWT 身份驗證的影響。要關閉（off）身份驗證，只需將關鍵字傳遞給 auth_jwt 指令。要取消繼承的身份驗證要求，只需將 off 關鍵字傳遞到 auth_jwt 指令。auth_jwt_key_file 帶一個參數。該參數是采用標準 JSON Web Key（JWK）格式的密鑰文件的路徑。
詳解
NGINX Plus 支持驗證 JSON Web 簽名類型的令牌，而不是將整個令牌進行加密的JSON Web 加密類型。NGINX Plus 支持驗證使用 HS256、RS256 和 ES256 算法簽名的簽名。使用 NGINX Plus 驗證令牌可以節省向身份驗證服務發出子請求所需的時間和資源。NGINX Plus 可破解 JWT 請求頭和有效載荷，并將標準請求頭和聲明捕獲到嵌入式變量中，供您使用。auth_jwt 指令可在 http、server、location 及 limit_except 上下文中使用。

參考資料
RFC JSON Web Signature 標準文檔
RFC JSON Web 算法標準文檔
RFC JSON Web Token 標準文檔
NGINX Plus JWT 身份驗證
“借助 JWT 和 NGINX Plus 驗證 API 客戶端身份”

4、創建 JSON Web Key

需要使用 JSON Web Key（JWK）才能使用 NGINX Plus。

NGINX Plus 使用 RFC 標準中指定的 JWK 格式。該標準允許在 JWK 文件中包含一個關鍵對象數組。
以下是該密鑰文件的示例：

{"keys":[{"kty":"oct","kid":"0001","k":"OctetSequenceKeyValue"},{"kty":"EC","kid":"0002""crv":"P-256","x": "XCoordinateValue","y": "YCoordinateValue","d": "PrivateExponent","use": "sig"},{"kty":"RSA","kid":"0003""n": "Modulus","e": "Exponent","d": "PrivateExponent"}]
}

所示的 JWK 文件演示了 RFC 標準中指出的三類初始密鑰。這些密鑰的格式也是 RFC 標準的一部分。kty 屬性是密鑰類型。該文件顯示了三種密鑰類型：Octet Sequence（oct）、EllipticCurve（EC）和 RSA 類型。kid 屬性是密鑰 ID。這些密鑰的標準中指定了其他屬性。更多信息請查看這些標準的 RFC 文檔。
詳解
有許多提供不同語言的庫可以生成 JWK。建議創建一個密鑰服務，作為 JWK 的中央權限，以定期創建和輪換您的 JWK。為了增強安全性，建議讓 JWK 與 SSL/TLS 證書一樣安全。使用適當的用戶和組權限保護密鑰文件。最好將它們保存在主機的內存中。您可以通過創建類似 ramfs 的內存文件系統來實現。定期輪換密鑰也很重要；您可以選擇創建一個密鑰服務來創建公鑰和私鑰，并通過 API 將它們提供給應用和 NGINX。
參考資料
RFC JSON Web Key 標準文檔

5、使用 NGINX Plus 驗證 JSON Web Token

使用 NGINX Plus 驗證 JSON Web Token。

使用 NGINX Plus 自帶的 JWT 模塊保護位置或服務器，并指示 airt_jwt 指令使用$cookie_auth_token 作為要驗證的令牌：

location /private/ {auth_jwt "Google Oauth" token=$cookie_auth_token; auth_jwt_key_file /etc/nginx/google_certs.jwk;
}

此配置指示 NGINX Plus 通過 JWT 驗證保護 /private/ URI 路徑。Google OAuth 2.0 OpenID Connect 使用 cookie auth_token 而不是默認的 bearer 令牌。因此，您必須指示 NGINX 在此 cookie 中查找令牌，而不是在 NGINX Plus 的默認位置中查找。我們將在實操指南 6.6 中介紹如何將 auth_jwt_key_file 位置設置為任意路徑。
詳解
此配置說明了如何使用 NGINX Plus 驗證 Google OAuth 2.0 OpenID Connect JWT。NGINX Plus 的 HTTP JWT 身份驗證模塊支持驗證符合 RFC JSON Web Signature 規范的 JWT，允許任何使用 JWT 的 SSO 授權立即在 NGINX Plus 層中進行驗證。OpenID 1.0 協議層位于 OAuth 的上面。OpenID 2.0 身份驗證協議添加了身份，支持使用 JWT 來證明發送請求的用戶的身份。NGINX Plus 可通過令牌的簽名驗證令牌自簽名以來是否經過修改。這允許 Google 使用一種異步簽名方法，可在保護其私人JWK 的同時分發公共 JWK。
參考資料
“借助 JWT 和 NGINX Plus 驗證 API 客戶端身份”

6、使用 NGINX Plus 自動獲取和緩存 JSON Web Key Set

希望 NGINX Plus 自動請求提供商的 JSON Web Key Set（JWKS）并進行緩存。

利用緩存區和 auth_jwt_key_request 指令自動更新密鑰：

proxy_cache_path /data/nginx/cache levels=1 keys_zone=foo:10m;
server {# ...location / {auth_jwt "closed site";auth_jwt_key_request /jwks_uri;}location = /jwks_uri {internal;proxy_cache foo;proxy_pass https://idp.example.com/keys;}
}

在此示例中，auth_jwt_key_request 指令指示 NGINX Plus 從內部子請求中檢索 JWK。該子請求被定向到 /jwks_uri，后者將請求代理給身份提供商。默認請求緩存時間為 10 分鐘，以限制開銷。
詳解
NGINX Plus R17 中引入了 auth_jwt_key_request 指令。此功能支持 NGINX Plus 服務器在發出請求時動態更新其 JWK。使用子請求方法來獲取 JWK，這意味著指令指向的位置必須是 NGINX Plus 服務器本地的位置。在上面的示例中，子請求的位置被鎖定，以確保僅響應內部的 NGINX Plus 請求。還可使用緩存來確保僅在必要時發出 JWK 檢索請求，并且不會導致身份提供商過載。auth_jwt_key_request 指令在 http、server、location 和 limit_except 上下文中有效。
參考資料
“借助 JWT 和 NGINX Plus 驗證 API 客戶端身份”
NGINX Plus“借助 JSON Web Key Set 緩存加快 JWT 驗證”

7、使用 NGINX Plus 通過現有的 OpenID Connect SSO 驗證用戶身份

希望將 NGINX Plus 與 OpenID Connect（OIDC）身份提供商集成在一起。

該解決方案由許多配置要素和一些 NGINX JavaScript 代碼組成。身份提供商（IdP）必須支持 OpenID Connect 1.0。NGINX Plus 將在授權代碼流中充當 OIDC 的中繼方。NGINX Inc. 維護了一個 GitHub 公共倉庫，該倉庫包含作為 OIDC 與 NGINX Plus 集成參考實現的配置和代碼。“其他參考資料”部分中的倉庫鏈接提供了關于如何使用自己的 IdP 設置參考實現的最新說明。

詳解
該解決方案只與參考實現有關，可確保各位讀者擁有最新的解決方案。提供的參考將NGINX Plus 配置為 OpenID Connect 1.0 授權代碼流的中繼方。在此配置中，如果將對受保護資源未經授權的請求發送到 NGINX Plus，NGINX Plus 首先會將該請求重定向到 IdP。IdP 會讓客戶端完成自己的登錄流程，然后向 NGINX Plus 返回一個身份驗證代碼。然后，NGINX Plus 直接與 IdP 通信，用身份驗證代碼交換一組 ID 令牌。這些令牌使用 JWT 進行驗證，并存儲在 NGINX Plus 的鍵值（key-value）存儲中。通過使用鍵值存儲，采用高可用性（HA）配置的所有 NGINX Plus 節點都能獲得這組令牌。在這個過程中，NGINX Plus 為客戶端生成了一個會話 cookie，該 cookie 被用于在鍵值存儲中查找令牌的密鑰。然后，客戶端的 cookie 被重定向到初始請求的資源。隨后的請求將通過使用 cookie 查找 NGINX Plus 鍵值存儲中的 ID 令牌來進行驗證。

該功能支持與大多數主要身份提供商進行集成，包括 CA 單點登錄（以前稱為SiteMinder）、ForgeRock OpenAM、Keycloak、Okta、OneLogin 和 Ping Identity。作為一項標準，OIDC 與身份驗證密切相關 —— 前面提到的身份提供商只是可能集成的一個子集。
參考資料
“借助 OpenID Connect 和 NGINX Plus 對訪問當前應用的用戶進行身份驗證”
OpenID Connect
NGINX OpenID Connect GitHub