設定 MQTT 代理程式驗證
重要
此頁面包含使用 Kubernetes 部署指令清單來管理 Azure IoT Operations 元件的指示，其處於預覽狀態。 這項功能隨附 數個限制，不應用於生產工作負載。
請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。
MQTT 訊息代理程式支援用戶端的多個驗證方法。 您可以將每個接聽程式埠設定為使用 BrokerAuthentication 資源有自己的驗證設定。 如需可用設定的清單，請參閱 訊息代理程式驗證 API 參考。
Link BrokerListener 和 BrokerAuthentication
下列規則適用於 BrokerListener 與 BrokerAuthentication 資源之間的關聯性：
- 每個 BrokerListener 資源可以有多個埠。 您可以將每個埠連結至 BrokerAuthentication 資源。
- 每個 BrokerAuthentication 資源都可以一次支援多個驗證方法。
- 未連結 BrokerAuthentication 資源的埠已停用驗證。
若要將 BrokerListener 埠連結至 BrokerAuthentication 資源，請在 BrokerListener 資源的設定中ports指定 authenticationRef 字段。 若要深入瞭解，請參閱 BrokerListener 資源。
預設 BrokerAuthentication 資源
Azure IoT 作業會部署名為 default 連結的預設 BrokerAuthentication 資源，並在命名空間中azure-iot-operations鏈接預設接聽程式。 它只會 使用 Kubernetes 服務帳戶令牌 （SAT） 進行驗證。
重要
需要預設 BrokerAuthentication 資源中的 SAT 驗證方法，IoT 作業中的元件才能正常運作。 避免更新或刪除預設 BrokerAuthentication 資源。
在 Azure 入口網站 中，移至您的 IoT 作業實例。
在 [元件] 底下，選取 [MQTT Broker]。
選取 [驗證] 索引標籤。
從驗證原則清單中，選取 預設 原則名稱。
若要新增驗證方法，請選取 [新增方法]。
驗證流程
指定之驗證方法的順序會決定 MQTT 訊息代理程式如何驗證用戶端。 MQTT 訊息代理程式會嘗試使用第一個指定的方法驗證客戶端的認證，並逐一查看指定的方法，直到找到相符專案或到達結尾為止。
針對每個方法，MQTT 訊息代理程式會先檢查客戶端的認證 是否與該方法相關 。 例如，SAT 驗證需要以 K8S-SAT 開頭的使用者名稱，而 X.509 驗證需要用戶端憑證。 如果客戶端的認證相關，MQTT 訊息代理程式會驗證它們是否有效。 如需詳細資訊，請參閱設定驗證方法一節。
針對自定義驗證，MQTT 訊息代理程式會將與自定義驗證伺服器通訊失敗視為 與認證無關。 如果無法連線到自定義驗證伺服器，此行為可讓 MQTT 訊息代理程式回復至其他方法。
驗證流程在下列狀況下結束：
- 其中一個條件為 True:
- 用戶端的認證與其中一種方法相關且有效。
- 用戶端的認證與任何方法無關。
- 用戶端的認證與其中一種方法相關但無效。
- MQTT 訊息代理程式會根據驗證流程的結果，授與或拒絕對用戶端的存取權。
例如：
apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
name: default
namespace: azure-iot-operations
spec:
authenticationMethods:
- method: Custom
customSettings:
# ...
- method: ServiceAccountToken
serviceAccountTokenSettings:
# ...
前任的範例會 custom 指定 和 SAT。 當用戶端連線時，MQTT 訊息代理程式會嘗試依照順序 custom 使用指定的方法來驗證客戶端，然後 SAT執行 。
- MQTT 訊息代理程式會檢查客戶端的認證是否適用於自訂驗證。 由於自定義驗證依賴外部伺服器來判斷認證的有效性，因此訊息代理程式會考慮與自定義驗證相關的所有認證，並將其轉送至自定義驗證伺服器。
- 如果自定義驗證伺服器以
Pass或Fail結果回應，驗證流程就會結束。 如果自定義驗證伺服器無法使用，MQTT 訊息代理程式會回復為其餘指定的方法，而 SAT 是下一個。 - MQTT 訊息代理程式會嘗試將認證驗證為 SAT 認證。
如果自定義驗證伺服器無法使用，且所有後續方法都判斷所提供的認證不相關，訊息代理程式會拒絕客戶端連線。
設定驗證方法
您可以新增驗證方法，例如 X.509、SAT 或自定義至驗證原則。
若要將驗證方法新增至原則：
在 Azure 入口網站 中，移至您的 IoT 作業實例。
在 [元件] 底下，選取 [MQTT Broker]。
選取 [驗證] 索引標籤。
選擇現有的驗證原則或建立新的驗證原則。
選取 [新增方法] 以新增方法。
從下拉式清單中選擇方法類型，然後選取 [ 新增詳細數據 ] 以設定方法。
若要深入瞭解每個驗證選項，請參閱每個方法的後續各節。
如需如何透過設定 Azure 金鑰保存庫 實例和啟用工作負載身分識別來啟用安全設定的詳細資訊，請參閱在 Azure IoT 作業部署中啟用安全設定。
X.509
提示
如需如何設定 X.509 驗證的端對端範例，請參閱 教學課程：TLS、X.509 用戶端驗證和屬性型訪問控制 （ABAC） 授權。
透過 X.509 驗證，MQTT 訊息代理程式會使用 受信任的證書頒發機構單位 （CA） 憑證 來驗證客戶端憑證。 此信任的 CA 可以是根或中繼 CA。 訊息代理程式會針對受信任的 CA 憑證檢查客戶端憑證鏈結。 如果鏈結有效，則會驗證用戶端。
若要搭配受信任的 CA 憑證使用 X.509 驗證，您必須符合下列需求：
- 傳輸層安全性 （TLS） 通訊協定：因為 X.509 依賴 TLS 用戶端憑證， 因此必須使用 X.509 驗證為埠啟用 TLS。
- 密鑰演算法：支援 EC 和 RSA 金鑰，但鏈結中的所有憑證都必須使用相同的密鑰演演算法。
- 格式：CA 憑證必須是隱私權增強郵件 （PEM） 格式。
提示
PEM 格式是憑證和金鑰的常見格式。 PEM 檔案是以Base64編碼的 ASCII 檔案，具有和-----BEGIN EC PRIVATE KEY-----等-----BEGIN CERTIFICATE-----標頭。
如果您有另一種格式的憑證，您可以使用 OpenSSL 將它轉換成 PEM。 如需詳細資訊，請參閱 將憑證轉換成適當的格式。
取得受信任的 CA 憑證
在生產設定中，CA 憑證是由組織的公鑰基礎結構 （PKI） 或公用證書頒發機構單位所提供。
若要進行測試，請使用 OpenSSL 建立自我簽署的 CA 憑證。 例如，執行下列命令來產生具有 RSA 金鑰、辨別名稱 CN=Contoso Root CA Cert的自我簽署 CA 憑證，以及有效期限為 365 天：
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"
使用步驟 CLI 的相同命令，這是管理憑證的便利工具，是：
step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
--not-after 8760h
這些命令會以 PEM 格式建立 CA 憑證 ca.pem和私鑰 ca-key.pem。 您可以將 CA 憑證 ca.pem 匯入 MQTT 訊息代理程式以進行 X.509 驗證。
匯入信任的 CA 憑證
若要開始使用 X.509 驗證，請將受信任的 CA 憑證匯入命名空間中的 azure-iot-operations ConfigMap。 若要將受信任的 CA 憑證 ca.pem 匯入名為 client-ca的 ConfigMap，請執行：
kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations
在此範例中，CA 憑證會匯入金鑰 ca.pem底下。 MQTT 訊息代理程式信任 ConfigMap 中的所有 CA 憑證，因此您可以將任何專案用於密鑰的名稱。
若要檢查根 CA 憑證是否已正確匯入，請執行 kubectl describe configmap。 結果會顯示 PEM 憑證檔案的相同 Base64 編碼方式。
kubectl describe configmap client-ca -n azure-iot-operations
Name: client-ca
Namespace: azure-iot-operations
Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----
BinaryData
====
設定 X.509 驗證方法
匯入受信任的 CA 憑證之後，請在 BrokerAuthentication 資源中將它新增為驗證方法，以啟用 X.509 客戶端驗證。 請確定此資源已連結至已啟用 TLS 的接聽程式埠。
在 Azure 入口網站 中，移至您的 IoT 作業實例。
在 [元件] 底下，選取 [MQTT Broker]。
選取 [驗證] 索引標籤。
選擇現有的驗證原則或建立新的驗證原則。
選取 [新增方法] 以新增方法。
從下拉式清單中選擇 X.509 方法。 然後選取 [ 新增詳細數據 ] 以設定 方法。
在 [ X.509 驗證詳細數據 ] 窗格中，使用 JSON 格式指定受信任的 CA 憑證 ConfigMap 名稱。
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }將取代
<TRUSTED_CA_CONFIGMAP>為包含受信任 CA 憑證的 ConfigMap 名稱。 例如，使用"trustedClientCaCert": "client-ca"。
或者，使用 X.509 憑證新增客戶端的授權屬性。 若要深入瞭解，請參閱 授權的憑證屬性。
選取 [套用] 以儲存變更。
選擇性：授權的憑證屬性
您可以在 BrokerAuthentication 資源中指定 X.509 屬性，根據客戶端的憑證屬性來授權用戶端。 屬性定義於 authorizationAttributes 欄位中。
例如：
在 Azure 入口網站 中，當您設定 X.509 驗證方法時，請以 JSON 格式在 X.509 驗證詳細資料窗格中新增授權屬性。
{
"trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
"authorizationAttributes": {
"root": {
"subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
"attributes": {
"organization": "contoso"
}
},
"intermediate": {
"subject": "CN = Contoso Intermediate CA",
"attributes": {
"city": "seattle",
"foo": "bar"
}
},
"smartfan": {
"subject": "CN = smart-fan",
"attributes": {
"building": "17"
}
}
}
}
在此範例中，每一個具有具有辨別名稱 CN = Contoso Root CA Cert, OU = Engineering, C = US 之根 CA 所簽發憑證的用戶端，或具有辨別名稱 CN = Contoso Intermediate CA 的中繼 CA 都會接收列出的屬性。 此外，智慧型風扇用戶端憑證會接收其專屬的屬性。
屬性的比對一律從分葉用戶端憑證開始，然後沿著鏈結進行。 屬性指派會在最初相符項目之後停止。 在上一個範例中，即使 smart-fan 有中繼憑證 CN = Contoso Intermediate CA，它也不會取得相關聯的屬性。
您可以使用具有這些屬性的 X.509 憑證，將授權規則套用至用戶端。 若要深入瞭解，請參閱 授權使用 X.509 驗證的用戶端。
啟用接聽程式埠的 X.509 驗證
匯入受信任的 CA 憑證並設定 BrokerAuthentication 資源之後，請將它連結至已啟用 TLS 的接聽程式埠。 此步驟很重要，因為 X.509 驗證依賴 TLS 進行用戶端憑證驗證。
若要取得已啟用 TLS 的接聽程式埠，請參閱 啟用埠 的 TLS 手動憑證管理和 啟用埠的 TLS 自動憑證管理。
注意
在訊息代理程式接聽程式埠上啟用 TLS 表示訊息代理程式使用伺服器證書進行 TLS 加密。 當用戶端連線到此埠時，他們必須信任伺服器證書，方法是在其信任存放區中簽署該憑證的 CA 憑證。 此程式稱為 信任分配 或 信任組合。 請務必瞭解客戶端驗證與伺服器驗證之間的差異：
-
客戶端驗證：MQTT 訊息代理程式（伺服器）會根據欄位中指定的
trustedClientCaCert受信任 CA 憑證來檢查客戶端憑證，以進行 X.509 客戶端驗證。 -
伺服器驗證：用戶端（例如 Mosquitto 或 MQTTX）會根據信任存放區中受信任的 CA 憑證檢查 MQTT 訊息代理程式的伺服器證書。 針對 Mosquitto 用戶端，請使用
--cafile參數來指定 CA 憑證檔案。 針對 MQTTX，將 CA 憑證新增至設定中的信任存放區。
啟用 X.509 驗證之後，請確定用戶端在 信任存放區中有伺服器端 CA 憑證，以信任訊息代理程式的伺服器證書。 請勿將信任伺服器端 CA 憑證與用於欄位中指定之客戶端驗證的trustedClientCaCert用戶端 CA 憑證混淆。
如需完整範例，請參閱 教學課程：TLS、X.509 用戶端驗證和屬性型訪問控制 （ABAC） 授權。
使用 X.509 用戶端憑證將 Mosquitto 用戶端連線到 MQTT 訊息代理程式
像 Mosquitto 這樣的用戶端需要兩個檔案，才能使用 TLS 和 X.509 用戶端驗證連線到 MQTT 訊息代理程式：
-
--cert參數指定用戶端憑證 PEM 檔案。 此檔案也應該包含任何中繼憑證，以協助 MQTT 訊息代理程式建置完整的憑證鏈結。 -
--key參數指定用戶端私密金鑰 PEM 檔案。
如果 MQTT 訊息代理程式使用自我簽署的 CA 憑證發出其 TLS 伺服器證書， --cafile 則需要 參數。 此檔案包含 CA 憑證（也稱為 信任套件組合），Mosquitto 用戶端會在透過 TLS 連線時用來驗證訊息代理程式的伺服器證書。 如果 MQTT 訊息代理程式伺服器證書的簽發者是系統根存放區的一部分（例如已知的公用 CA）， --cafile 則可以省略 參數。
例如：
mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem
了解 MQTT 代理程式 X.509 用戶端驗證流程
請遵循下列步驟進行客戶端驗證：
- 開啟 X.509 用戶端驗證時，連線客戶端必須出示客戶端憑證和任何中繼憑證，讓 MQTT 訊息代理程式建置跟在其其中一個已設定的受信任憑證的憑證鏈結。
- 負載平衡器會將通訊導向至其中一個前端訊息代理程式。
- 在前端代理程式收到客戶端憑證之後，它會嘗試建置跟在其中一個已設定憑證的憑證鏈結。 如果前端代理程式成功建置鏈結並驗證呈現的鏈結，則會完成 TLS 交握。 線上客戶端能夠透過 TLS 通道將 MQTT 封包傳送至前端。
- TLS 通道已開啟，但用戶端驗證或授權尚未完成。
- 用戶端接著會將 CONNECT 封包傳送至 MQTT 訊息代理程式。
- CONNECT 封包會再次路由傳送至前端。
- 前端會收集到目前為止呈現的所有客戶端認證，例如 CONNECT 封包中的驗證數據，以及 TLS 交握期間呈現的用戶端憑證鏈結。
- 前端會將這些憑證傳送至驗證服務。 驗證服務會再次檢查憑證鏈結，並收集鏈結中所有憑證的主體名稱。
- 驗證服務會使用其 設定的授權規則 來判斷連線客戶端擁有的屬性。 這些屬性會決定客戶端可執行哪些作業，包括 CONNECT 封包本身。
- 驗證服務會將決策傳回給前端訊息代理程式。
- 前端訊息代理程式知道用戶端屬性，以及它是否允許連線。 如果是，則 MQTT 連線已完成，而且用戶端可以繼續傳送和接收由其授權規則決定的 MQTT 封包。
Kubernetes 服務帳戶令牌
Kubernetes SAT 是與 Kubernetes 服務帳戶相關聯的 JSON Web 令牌。 用戶端向 MQTT 代理程式出示 SAT，以自行驗證。
MQTT 訊息代理程式會使用系結的服務帳戶令牌，如 GKE 使用者需要知道 Kubernetes 的新服務帳戶令牌文章中所述。 以下是文章的主要功能：
在 Kubernetes 1.13 中啟動的系結令牌，並以 1.21 格式成為預設格式。 系結令牌可解決舊版令牌的所有有限功能，以及更多功能：
- 令牌很難竊取和濫用。 它們是時間系結、對象系結和對象系結。
- 它們採用標準化格式。 OpenID Connect （OIDC），具有完整的 OIDC 探索，可讓服務提供者更容易接受它們。
- 它們會使用新的 Kubelet 投影磁碟區類型，以更安全的方式散發到 Pod。
訊息代理程式會使用 Kubernetes 令牌檢閱 API 來驗證令牌。 啟用 Kubernetes TokenRequestProjection 功能以指定 audiences （預設值自 1.21 起）。 如果未啟用此功能，您就無法使用 SAT。
建立服務帳戶
若要建立 SAT，請先 建立服務帳戶。 下列命令會建立名為 mqtt-client的服務帳戶：
kubectl create serviceaccount mqtt-client -n azure-iot-operations
選擇性：新增授權的屬性
透過 SAT 進行驗證的用戶端可以選擇性地為其服務帳戶加上批注，以搭配授權原則使用。 為了區別這些批注與其他批注，其開頭為 aio-broker-auth/ 前置詞。
您可以使用 來標註服務帳戶 kubectl annotate：
kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations
或者，您可以將批註新增至服務帳戶指令清單檔案：
apiVersion: v1
kind: ServiceAccount
metadata:
name: <SERVICE_ACCOUNT_NAME>
namespace: azure-iot-operations
annotations:
aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>
若要深入瞭解，請參閱 授權使用 Kubernetes 服務帳戶令牌的用戶端。
啟用 SAT 驗證
修改 BrokerAuthentication 資源中的 authenticationMethods 設定，將 ServiceAccountToken 指定為有效的驗證方法。 參數 audiences 會指定令牌的有效物件清單。 選擇可識別 MQTT 代理程式服務的唯一值。 您必須指定至少一個對象，且所有 SAT 都必須符合其中一個指定的對象。
- 在 Azure 入口網站 中，移至您的 IoT 作業實例。
- 在 [元件] 底下，選取 [MQTT Broker]。
- 選取 [驗證] 索引標籤。
- 選擇現有的驗證原則或建立新的驗證原則。
- 選取 [新增方法] 以新增方法。
- 從下拉式清單中選擇 Kubernetes SAT 的方法類型。 然後選取 [ 新增詳細數據 ] 以設定 方法。
測試 SAT 驗證
SAT 驗證會使用 MQTT v5 增強式驗證欄位。 客戶端必須將增強的驗證方法設定為 ， K8S-SAT 並將增強的驗證數據設定為令牌。
例如，使用 Mosquitto （某些欄位省略為簡潔）：
mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>
<TOKEN>以下是服務帳戶令牌。 若要取得測試權杖，請執行：
kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>
<SERVICE_ACCOUNT>以下是您建立的服務帳戶名稱，也是 <AUDIENCE> BrokerAuthentication 資源中設定的其中一個物件。
如需如何設定 Kubernetes Pod 以使用 SAT 驗證的範例，請參閱 連線到叢集內的預設接聽程式。
在 Pod 組態中 serviceAccountName ，字段必須符合與所使用令牌相關聯的服務帳戶。 欄位 serviceAccountToken.audience 必須是 BrokerAuthentication 資源中設定的 audiences 其中一個。
重新整理服務帳戶權杖
服務帳戶權杖在有限的時間內有效，並使用 expirationSeconds 進行設定。 不過，Kubernetes 會在權杖到期之前自動重新整理。 權杖會在背景重新整理，用戶端不需要執行任何其他動作，即可再次擷取權杖。
例如，如果用戶端是使用掛接為磁碟區的令牌的Pod，就像在測試SAT驗證範例中一樣，則最新令牌可在相同的路徑/var/run/secrets/tokens/broker-sat中使用。 當用戶端建立新的連線時，用戶端可以擷取最新的令牌，並使用它進行驗證。 用戶端也應該有一個機制，藉由擷取最新的權杖並重試連線，來處理 MQTT 的未授權錯誤。
自訂驗證
使用自訂驗證，將用戶端驗證延伸至提供的驗證方法之外。 這是可插入的，因為只要服務遵守 API 即可。
當用戶端連線到已啟用自訂驗證的 MQTT 訊息代理程式時，訊息代理程式會使用客戶端的認證，將 HTTPS 要求傳送至自訂驗證伺服器。 然後，伺服器會以核准或拒絕回應，包括客戶端的 授權屬性。
建立自訂驗證服務
自訂驗證伺服器會與 MQTT 訊息代理程式分開實作和部署。
GitHub 提供範例自訂驗證伺服器和指示。 使用此範例作為範本和起點，以實作您自己的自定義驗證邏輯。
API
MQTT 訊息代理程式和自訂驗證伺服器之間的 API 遵循自定義驗證的 API 規格。 GitHub 提供 OpenAPI 規格。
需要具有 TLS 加密的 HTTPS
MQTT 訊息代理程式會將包含敏感性客戶端認證的要求傳送至自定義驗證伺服器。 若要保護這些認證，MQTT 訊息代理程式和自定義驗證伺服器之間的通訊必須使用 TLS 加密。
自定義驗證伺服器必須出示伺服器證書，而且 MQTT 訊息代理程式必須具有受信任的根 CA 憑證，才能驗證伺服器證書。 或者，自定義驗證伺服器可能需要 MQTT 訊息代理程式出示客戶端憑證來驗證本身。
啟用接聽程式的自訂驗證
修改 BrokerAuthentication 資源中的驗證方法設定，將 Custom 指定為有效的驗證方法。 然後，指定與自定驗證伺服器通訊所需的參數。
在 Azure 入口網站 中，移至您的 IoT 作業實例。
在 [元件] 底下，選取 [MQTT Broker]。
選取 [驗證] 索引標籤。
選擇現有的驗證原則或建立新的驗證原則。
選取 [新增方法] 以新增方法。
從下拉式清單中選擇 [自定義] 方法類型。 然後選取 [ 新增詳細數據 ] 以設定 方法。
停用驗證
若要進行測試，您可以停用訊息代理程式接聽程式埠的驗證。 不建議停用生產環境的驗證。
- 在 Azure 入口網站 中，移至您的 IoT 作業實例。
- 在 [元件] 底下，選取 [MQTT Broker]。
- 從清單中選取您要編輯的訊息代理程式接聽程式。
- 在您要停用驗證的埠上，選取 [驗證] 下拉式清單中的 [無 ]。
認證到期后用戶端中斷連線
MQTT 訊息代理程式會在其認證到期時中斷用戶端連線。 認證到期后中斷連線適用於所有連線到 MQTT 訊息代理程式前端的用戶端，例如：
- 使用 SAT 驗證的用戶端會在其 SAT 到期時中斷連線。
- 用戶端在用戶端憑證到期時，以 X.509 驗證的用戶端中斷連線。
- 使用自訂驗證來進行驗證的用戶端會根據自訂驗證伺服器所傳回的過期時間來中斷連線。
在中斷連線時，用戶端的網路連線會關閉。 用戶端不會收到 MQTT DISCONNECT 封包，但訊息代理程式會記錄它中斷用戶端連線的訊息。
使用 SAT 和自訂驗證來進行驗證的 MQTT v5 用戶端可以在初始認證過期前，使用新的認證重新驗證。 X.509 用戶端無法重新驗證，而且必須重新建立連線，因為驗證是在 TLS 層完成。
用戶端可以藉由傳送 MQTT v5 AUTH 封包來重新驗證， 原因為 ReAuth。
SAT 用戶端會傳送具有字段 method: K8S-SAT 和 的 data: <token>AUTH 用戶端。 自訂驗證用戶端會按照自訂驗證伺服器的要求來設定方法和資料欄位。
成功重新驗證會使用其新認證到期時間更新客戶端的認證到期日。 訊息代理程式會以 Success AUTH 封包回應。 由於暫時性問題，例如自定義驗證伺服器無法使用，導致訊息代理程式回應 ContinueAuthentication 驗證封包失敗。 用戶端可以稍後再試一次。 其他驗證失敗則會導致代理程式傳送 DISCONNECT 封包，並關閉用戶端的網路連線。