使用您自己的身分提供者來驗證一般使用者 authentication

根據預設，您應用程式上的每個動作都是公開的：任何擁有您MCP伺服器URL的LLM平台都可以呼叫它，而且您的處理常式無法識別一般使用者。

當動作需要知道哪些一般使用者在要求時（例如，傳回其訂單、權益或帳戶詳細資訊），請開啟驗證。 LLM平台使用​ 您的 ​身分提供者(IdP)登入使用者，每次呼叫都會傳送產生的存取權杖，而且您的處理常式會接收已驗證的身分識別。

歷程：​複製資源識別碼→設定您的身分提供者→開啟驗證，→為→部署的每個動作設定驗證模式→讀取處理常式中的身分識別，→測試受保護的應用程式。

這是進階分支，不是首次執行歷程的一部分。 完成自動建立您的第一個應用程式並先部署您的應用程式。

運作方式

您自備身分識別提供者。 您部署的應用程式只是OAuth 2.1 資源伺服器 — 它驗證您的授權伺服器所發行的權杖。 它不會核發權杖，且Adobe不會儲存您的使用者端ID或使用者端密碼。

┌── Your identity provider ───────────────────────────────────────────────┐
│  Authorization server — you own it                                      │
│  Issues access tokens, holds the user directory, defines the scopes     │
└─────────────────────────────────────────────────────────────────────────┘
        ▲  2  user signs in, platform gets an access token
        │                                    │
        │  1  platform discovers your        │  3  every tools/call carries
        │     authorization server from      │     Authorization: Bearer <token>
        │     your app's metadata            ▼
┌── LLM platform (ChatGPT, Claude, …) ────────────────────────────────────┐
└─────────────────────────────────────────────────────────────────────────┘
                                             │
                                             ▼
┌── Your LLM App on Adobe I/O Runtime ────────────────────────────────────┐
│  Resource server — verifies the token's signature, issuer, audience,    │
│  and expiry, then enforces the auth mode you set for each action        │
│                                                                         │
│  Your handler reads the verified identity from its second argument      │
└─────────────────────────────────────────────────────────────────────────┘

已針對每個環境​ 設定 ​驗證。 階段​和​ 生產 ​保留獨立的設定，所以您可以在​ 生產 ​上啟用它之前，針對開發IdP租使用者驗證設定。

開始之前

複製資源識別碼

應用程式的​ 資源識別碼 ​是其MCP伺服器URL。 您的身分提供者針對此應用程式發行的每個存取Token都必須將該確切URL命名為對象 — 該繫結可防止針對您的應用程式重播為其他服務所指定的Token。

保留此值：您需要在下一步的身分提供者中使用此值。 貼上複製的URL，而非重新輸入。 對象檢查是完全相符的字串，包括任何路徑元件，因此單一字元差異會導致每個權杖驗證失敗。

設定您的身分提供者

確切的步驟依提供者而異，但每個提供者需要相同的四個專案。

開啟驗證

如需每個欄位接受的內容，請參閱驗證設定。

選擇每個動作的驗證模式

當您開啟​ 啟用驗證 ​時，目前設定為​ 無 ​的每個動作都會變更為​必要。 在​ 每個動作組態 ​下，檢閱該指派並設定每個動作所需的模式：

動作已設定為​ 必要 ​或​選用，請保留其現有模式。

若要執行​ 必要 ​或​ 選用 ​動作，請新增所需的​領域。 每個範圍必須已出現在以上支援的​ 範圍 ​中；否則應用程式會要求不通告給LLM平台的許可權。 儲存會被封鎖，直到不符問題解決為止。

支援的領域​是此清單的授權單位。 如果您從其中移除範圍，當您進行變更時，會從每個需要它的動作中移除該範圍 — 因此，請先在那裡新增範圍，然後將其指派給動作。

所有動作都需要驗證​將每個動作設定為​必要。 清除它會傳回每個動作至​無。

完成時選取​儲存。 驗證模式和範圍變更會與應用程式層級設定一併儲存。

支援在單一應用程式中混合模式（部分為公開動作，其他為閘道動作），且ChatGPT會個別套用每個動作的模式：只有閘道動作會提示使用者登入。

部署變更

驗證變更會在此應用程式的下一次部署中生效。 再次將應用程式​部署至您設定的環境。 請參閱部署您的應用程式。

您的MCP伺服器URL不會變更，因此您已經建立的任何外掛程式或聯結器會繼續運作。 現在此功能已設為閘道，因此下次使用者使用此功能時，系統會要求使用者登入。

讀取處理常式中的身分識別

經過驗證的身分會到達您的處理常式，做為第二個引數。 無論動作的驗證模式為何，只要呼叫者傳送有效的權杖，就會出現權杖，因此​ 選用 ​動作可以在權杖存在時個人化其結果，而在權杖不存在時仍會傳回結果。

使用getAuthenticatedUser讀取登入的使用者：

const { getAuthenticatedUser } = require('@adobe/llm-apps-runtime');

module.exports = async ({ orderId }, extra) => {
  const userId = getAuthenticatedUser(extra);

  if (!userId) {
    return { content: [{ type: 'text', text: 'Sign in to see your orders.' }] };
  }

  const order = await fetchOrderForUser(userId, orderId);

  return {
    content: [{ type: 'text', text: `Order ${order.id} is ${order.status}.` }],
    structuredContent: order
  };
};

您不需要自行驗證權杖。 對於​ 必要 ​動作，執行階段會封鎖每個缺少有效權杖的呼叫，該權杖包含您列出的範圍，因此處理常式只會針對授權呼叫者執行。 當您想要在許可權上分支而不是依賴閘道時，請使用hasScope，例如，在​ 選擇性 ​動作中。

選擇性​動作可要求使用者傳回extra.challengeAuth()以登入對話中間。 這僅適用於​ 選擇性 ​動作：

module.exports = async ({ signIn }, extra) => {
  if (signIn && !extra.authInfo) {
    return extra.challengeAuth({
      error: 'invalid_token',
      errorDescription: 'Sign in to see member pricing.'
    });
  }

  return {
    content: [{
      type: 'text',
      text: extra.authInfo ? await memberDeals() : await publicDeals()
    }]
  };
};

決定是否從明確的輸入引數呈報（如signIn在此做的那樣），而不是透過檢查使用者的措辭呈報。

設定error以符合您報告的條件。 當呼叫者沒有有效的工作階段且需要登入時，請使用invalid_token，如上述範例所示；當呼叫者已登入但權杖缺少動作所需的範圍時，請使用insufficient_scope。 LLM平台會選擇使用者所看到提示的措辭，以及此值在不同平台之間的差異程度，因此請傳送描述該條件的正確程式碼。

只有在您需要的身分確實遺失時，才能提出質詢，就像這裡的!extra.authInfo檢查一樣。 如果處理常式要求無條件挑戰，則無法透過登入來加以滿足，因此系統會要求使用者在每次呼叫時再次進行驗證。

保留身分識別伺服器端。 只將Widget需要的傳遞到structuredContent，並且永遠不要將存取權杖放在該處 — 請參閱自訂產生的處理常式。

如需完整合約，請參閱處理常式驗證API。

測試受保護的應用程式

您現有的外掛程式或聯結器會在部署後擷取變更。 若要從頭開始設定：

ChatGPT

在​ 新外掛程式 ​對話方塊中，設定​ 驗證 ​以符合您設定應用程式動作的方式：

Optional​動作一律會接受匿名呼叫，因此包含此動作的應用程式永遠不會完整接通 — 即使每個動作都設為​Optional，請選擇​Mixed。 只有​ 必要 ​拒絕未驗證的來電者。

請參閱測試ChatGPT外掛程式，瞭解對話方塊的其餘部分。

Claude

新增自訂聯結器，然後選取​ 連線 ​並完成您的身分提供者顯示的登入。 沒有要進行的驗證選擇 — Claude會在任何動作被閘道時閘道整個聯結器。 請參閱測試克勞德聯結器。

驗證

如果登入未開始，或權杖被拒絕，請參閱疑難排解。

安全性指引

後續步驟