驗證參考 authentication-reference

您可以在此頁面查詢驗證欄位與合約。 如需安裝歷程，請參閱使用您自己的身分識別提供者來驗證一般使用者。

驗證設定 authentication-settings

在​設定 > 驗證​下找到。 每個欄位都依環境儲存 — Workspace​選擇器會選取您正在編輯的欄位，而且儲存時不會影響其他欄位。

驗證規則

簽發者​上的結尾斜線會正規化，而iss比較容許差異 — 一律發出結尾斜線的提供者仍會驗證。

驗證模式 auth-modes

在​ 每個動作組態 ​下設定每個動作。

必要​動作的處理常式，永遠不會在沒有有效、範圍正確的權杖的情況下執行。 Optional​動作的處理常式一律執行，而且可能要求使用extra.challengeAuth()登入本身。

因此，必要​是唯一拒絕未驗證來電者的模式。 只有當應用程式的每一個動作為​ 必要 ​時，應用程式才會完全關閉；單一​ 無 ​或​ 選用 ​動作會混合應用程式，因為匿名呼叫至少仍會成功執行一個動作。

只有在​ 啟用驗證 ​開啟時，驗證模式才會生效。 變更會在應用程式下一次部署時生效。

切換開關時會重寫每個動作的模式：

切換​ Workspace ​絕不重寫模式 — 它會載入其他環境的儲存組態。

啟用驗證 （每個動作皆設為​無）為有效但無效的組合：從未拒絕任何呼叫，但應用程式仍發佈其授權伺服器以供探索。 關閉開關，讓應用程式完全公開。

各模式可在一個應用程式中自由混合。 請參閱LLM平台行為，瞭解每個平台如何套用這些行為。

權杖需求 token-requirements

您的身分提供者必須核發符合下列所有條件的存取權杖。 未通過任何檢查的Token會被視為不存在 — 呼叫者未驗證，且​ 必要 ​動作會要求他們登入。

您的提供者包含的任何其他一般宣告（例如tenant或email）都會傳遞給您的處理常式。 巢狀物件會被捨棄，長字串值會被截斷。

身分提供者探索 discovery

您的應用程式會發佈自己的RFC 9728受保護資源中繼資料，讓LLM平台可以找到您的授權伺服器。 您沒有為其建立、託管或設定任何專案。

您必須自行提供探索：

處理常式驗證API handler-auth-api

已從@adobe/llm-apps-runtime匯出。 每個協助程式都採用extra，這是您的處理常式所接收的第二個引數。

原始的已驗證權杖資訊位於extra.authInfo上，對於未驗證的呼叫而言是undefined。

extra.challengeAuth(options)僅適用於​ 選擇性 ​動作。 從您的處理常式傳回結果，要求使用者登入而非傳回內容。

LLM平台行為 platform-behavior

對驗證個別動作的支援因平台而異。 兩者設定相同方式，差異在於使用者體驗。

相關