身分驗證

Restorm 沒有「身分驗證類型」下拉選單。它提供的是更通用的機制：驗證請求——一個 獨立完整的請求，唯一職責就是為其他請求產生標頭。

好處是：任何驗證機制都能建模，包括下拉選單永遠不會預先提供的那些——兩段式交換、 簽章權杖、自家寫的 API。代價是：您得先把它寫一次。

建立驗證路由

在環境資料夾上按右鍵 ▸ 新增 ▸ 驗證請求。

請先像設定任何 HTTP 請求那樣設定這次呼叫：方法、URL、標頭、內文。接著開啟它的 設定分頁，身分驗證專屬的三項設定都在那裡。

產生的標頭

這條路由會注入到每個引用它的請求中的標頭清單。每個值都是一個在驗證請求的回應 內文上求值的運算式。

標頭	值
Authorization	{{token_type}} {{access_token}}

逾期時間（秒）

同樣在回應內文上求值的運算式，得出以秒為單位的有效期限——通常是 {{expires_in}}。留空時，權杖不會自行逾期。

身分驗證錯誤碼

當使用這條路由的請求收到這些 HTTP 狀態碼時，就會觸發更新權杖並自動重試。 預設為 401 與 403。

兩個名稱，同一樣東西

驗證請求是您在樹狀結構中建立的那個項目。驗證路由則是同一個項目從另一個 請求看過去的樣子，也就是把它附加上去的那個選擇器。兩個名稱指的是同一個實體，只是 出現在介面的兩個位置。

把路由附加到請求上

在請求分頁的 smartbar 上，有一個驗證路由 選擇器，列出該環境資料夾提供的所有路由。預設標籤是「無驗證」。

一旦附加上去，每次傳送都會注入產生的標頭，權杖會快取到逾期為止，而收到 401 便 會觸發一次完全無感的權杖更新。

常見做法

Bearer／OAuth 2 client credentials

請求：POST https://auth.exemple.test/oauth/token，內文採 x-www-form-urlencoded，帶 grant_type=client_credentials、 client_id={{clientId}}、client_secret={{clientSecret}} （其中的密碼是一個密鑰類型的值）。

產生的標頭：Authorization = {{token_type}} {{access_token}}。 逾期時間：{{expires_in}}。

Basic

如果您已經握有認證資訊，就不需要任何請求：直接把標頭放在請求（或資料夾）上即可：

Authorization = Basic {{base64Encode (append (append user ":") password)}}

API 金鑰

一個標頭或一個查詢參數就夠了：X-API-Key = {{apiKey}}，其中的金鑰是一個密鑰 類型的變數。

需要兩次呼叫才能取得的權杖

請建立一個情境：第一次呼叫、取出中間碼、 第二次呼叫，然後用設定變數把權杖寫進執行變數。情境中後續的請求便以 {{token}} 讀取它。

匯入時會做什麼

匯入規格時，其中宣告的安全性結構會被轉換成預先接好線的標頭或參數，並自動為您 建立一個環境變數：

規格中的結構	Restorm 放上的內容
apiKey（標頭或查詢）	一組以該結構命名的鍵值對，值為 {{<schema>}}
http / basic	Authorization: Basic {{<schema>_credentials}}
http / bearer、oauth2、openIdConnect	Authorization: Bearer {{<schema>_token}}

接下來您只需要填入該變數的值，或者——若希望自動更新權杖——把它換成一條驗證路由。

Postman、Insomnia 與 Bruno 的集合

這些工具的身分驗證區塊在匯入時會被讀取並記錄成文件（敏感值會被遮蔽），但不會 轉換成可執行的認證資訊：請重新建立一條驗證路由。

各協定的原生認證欄位

有些協定不透過 HTTP 標頭傳遞認證資訊，它們的認證資訊是請求本身的欄位：

協定	欄位
MQTT	username、password、用戶端識別碼
AMQP	username、password、vhost
Redis	password
Kafka	SASL 機制（plain、scram-sha-256、scram-sha-512）、識別碼、密碼、TLS
STOMP	CONNECT 的 login 與 passcode 標頭
gRPC	呼叫的中介資料

以上每一個密碼欄位都接受密鑰類型的值。