Endbenutzer bei Ihrem eigenen Identitätsanbieter authentifizieren authentication

Standardmäßig ist jede Aktion in Ihrer App öffentlich: Jede LLM-Plattform mit Ihrer MCP-Server-URL kann sie aufrufen, und Ihr Handler kann den Endbenutzer nicht identifizieren.

Aktivieren Sie die Authentifizierung, wenn eine Aktion wissen muss, welcher Endbenutzer fragt - z. B. um seine Bestellungen, Berechtigungen oder Kontodetails zurückzugeben. Die LLM-Plattform meldet den Benutzer bei Ihrem Identitätsanbieter (IdP) an, sendet das daraus resultierende Zugriffstoken bei jedem Aufruf und Ihr Handler erhält die verifizierte Identität.

Journey: Kopieren Sie die Ressourcenkennung → konfigurieren Sie Ihren Identitätsanbieter → aktivieren Sie die Authentifizierung → legen Sie einen Authentifizierungsmodus für jede Aktion fest, → Sie die Identität in Ihrem Handler bereitstellen → lesen → die geschützte App testen.

Dies ist eine erweiterte Verzweigung, die nicht Teil der Erstausführung von Journey ist. Schließen Sie Erste App automatisch erstellen ab und Bereitstellen der App.

Funktionsweise

Sie bringen Ihren eigenen Identitätsanbieter mit. Ihre bereitgestellte App ist nur ein OAuth 2.1 Ressourcen-Server - sie überprüft Token, die von Ihrem Autorisierungs-Server ausgestellt wurden. Es gibt nie Token aus und speichert Adobe nie Ihre Client-ID oder Ihr Client-Geheimnis.

┌── 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      │
└─────────────────────────────────────────────────────────────────────────┘

Die Authentifizierung wird pro Umgebung konfiguriert. Staging und Produktion enthalten unabhängige Einstellungen, sodass Sie die Konfiguration mit einem Entwicklungs-IDp-Mandanten vergleichen können, bevor Sie sie auf Produktion aktivieren.

Voraussetzungen

Kopieren der Ressourcenkennung

Die „Ressourcenkennung Ihrer App ist MCP-Server-URL. Jedes Zugriffstoken, das Ihr Identitätsanbieter für diese App ausgibt, muss diese exakte URL als Zielgruppe benennen - diese Bindung verhindert, dass ein Token, das für einen anderen Service geprägt wurde, erneut für Ihre App angezeigt wird.

Behalten Sie diesen Wert bei: Sie benötigen ihn im nächsten Schritt bei Ihrem Identitätsanbieter. Fügen Sie die kopierte URL ein, anstatt sie erneut einzugeben. Bei der Zielgruppenprüfung handelt es sich um eine exakte Zeichenfolgenübereinstimmung, einschließlich einer Pfadkomponente, sodass ein einzelner Zeichenunterschied dazu führt, dass die Validierung jedes Tokens fehlschlägt.

Konfigurieren des Identitätsanbieters

Die genauen Schritte unterscheiden sich je nach Anbieter, aber jeder Anbieter benötigt die gleichen vier Dinge.

Authentifizierung aktivieren

Informationen dazu, was jedes Feld akzeptiert, finden Sie unter Authentifizierungseinstellungen.

Authentifizierungsmodus für jede Aktion auswählen

Wenn Sie die Authentifizierung aktivieren ändert sich jede Aktion, die derzeit auf Keine festgelegt ist, in Erforderlich. Überprüfen unter „Konfiguration pro Aktion diese Zuweisung und legen Sie den Modus fest, den jede Aktion benötigt:

Aktionen, die bereits auf Erforderlich oder Optional festgelegt sind, behalten ihren vorhandenen Modus bei.

Fügen Sie für eine Erforderlich oder Optional-Aktion die Bereiche erforderlichen hinzu. Jeder Bereich muss bereits oben unter Unterstützte Bereiche angezeigt werden. Andernfalls benötigt die App eine Berechtigung, die sie nicht an LLM-Plattformen weitergibt. Das Speichern ist blockiert, bis die Diskrepanz behoben ist.

Unterstützte Bereiche ist die Autorität für diese Liste. Wenn Sie einen Bereich daraus entfernen, wird dieser Bereich aus jeder Aktion entfernt, für die er erforderlich ist, sobald Sie die Änderung vornehmen. Fügen Sie also zuerst einen Bereich hinzu und weisen Sie ihn dann einer Aktion zu.

Authentifizierung für alle Aktionen verlangen setzt jede Aktion auf Erforderlich. Wenn Sie sie löschen, wird jede Aktion auf Keine zurückgesetzt.

Wählen abschließend Speichern“ aus. Änderungen an Authentifizierungsmodus und -umfang werden zusammen mit den Einstellungen auf Programmebene gespeichert.

Das Mischen von Modi in einer App - einige öffentliche, andere gated - wird unterstützt, und ChatGPT wendet den Modus jeder Aktion einzeln an: Nur die gated Aktionen fordern den Benutzer zur Anmeldung auf.

Änderung bereitstellen

Authentifizierungsänderungen werden bei der nächsten Bereitstellung dieser App wirksam. Die App erneut bereitstellen in der von Ihnen konfigurierten Umgebung. Siehe Bereitstellen der App.

Ihre MCP-Server-URL ändert sich nicht, sodass alle bereits erstellten Plug-ins oder Connectoren weiterhin funktionieren. Es ist jetzt beschriftet, sodass seine Benutzer aufgefordert werden, sich bei der nächsten Verwendung anzumelden.

Lesen der Identität in Ihrem Handler

Eine verifizierte Identität erreicht Ihren Handler als zweites Argument. Sie ist immer vorhanden, wenn der Aufrufer ein gültiges Token gesendet hat, unabhängig vom Authentifizierungsmodus der Aktion. Daher kann eine Optional-Aktion ihr Ergebnis personalisieren, wenn ein Token vorhanden ist, und dennoch ein Ergebnis zurückgeben, wenn dies nicht der Fall ist.

Verwenden Sie getAuthenticatedUser, um den angemeldeten Benutzer zu lesen:

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
  };
};

Sie müssen das Token nicht selbst überprüfen. Bei einer Erforderlich-Aktion blockiert die Laufzeit jeden Aufruf, dem ein gültiges Token fehlt, das die aufgeführten Bereiche enthält, sodass der Handler nur für autorisierte Aufrufer ausgeführt wird. Verwenden Sie hasScope, wenn Sie eine Verzweigung für eine Berechtigung erstellen möchten, anstatt sich auf das Gate zu verlassen, z. B. in einer optionalen Aktion.

Eine optionale Aktion kann den Benutzer bitten, sich während der Konversation anzumelden, indem extra.challengeAuth() zurückgegeben wird. Dies ist nur für optionale Aktionen verfügbar:

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()
    }]
  };
};

Entscheiden Sie, ob eine Eskalation von einem expliziten Eingabeparameter aus erfolgen soll, wie signIn dies hier tut, anstatt den Text des Benutzers zu überprüfen.

Stellen Sie error so ein, dass es der von Ihnen gemeldeten Bedingung entspricht. Verwenden Sie invalid_token, wenn der Aufrufer keine gültige Sitzung hat und sich anmelden muss, wie im Beispiel oben, und insufficient_scope, wenn der Aufrufer bereits angemeldet ist, aber das Token keinen Umfang hat, den die Aktion benötigt. Die LLM-Plattform wählt den Wortlaut der Eingabeaufforderung aus, die der Benutzer sieht, und wie weit dieser Wortlaut mit diesem Wert variiert, hängt von der Plattform ab. Senden Sie daher den Code, der die Bedingung genau beschreibt.

Herausforderung nur dann, wenn die benötigte Identität wirklich fehlt, wie hier bei der !extra.authInfo. Ein Handler, der Herausforderungen ohne Bedingungen stellt, kann nicht durch die Anmeldung erfüllt werden, sodass der Benutzer bei jedem Aufruf aufgefordert wird, sich erneut zu authentifizieren.

Bewahren Sie die Identität Server-seitig auf. Übergeben Sie nur das, was das Widget benötigt, in structuredContent und fügen Sie das Zugriffstoken nie dort ein - siehe Anpassen eines generierten Handlers.

Den vollständigen Vertrag finden Sie unter Handler-Auth-API.

Testen der geschützten App

Das vorhandene Plug-in oder der vorhandene Connector übernimmt die Änderung nach der Bereitstellung. So richten Sie eine neue ein:

ChatGPT

Legen Sie im Dialogfeld Neues Plug die Einstellung Authentifizierung fest, um sie an die Konfiguration der App-Aktionen anzupassen:

Eine Optional-Aktion akzeptiert immer anonyme Aufrufe, sodass eine App, die eine enthält, nie vollständig gated wird. Wählen Sie Gemischt, auch wenn jede Aktion auf Optional gesetzt ist. Nur Erforderlich lehnt nicht authentifizierte Aufrufe ab.

Siehe Testen des ChatGPTPlug-ins für den Rest des Dialogfelds.

Claude

Fügen Sie den benutzerdefinierten Connector hinzu, wählen Sie Verbinden und schließen Sie die Anmeldung ab, die Ihr Identitätsanbieter vorstellt. Es gibt keine Authentifizierungsauswahl - Claude tort den gesamten Connector, wenn eine Aktion tortiert wird. Siehe Testen des Claude-Connectors.

Überprüfen

Wenn die Anmeldung nicht gestartet oder ein Token abgelehnt wird, finden Sie weitere Informationen unter Fehlerbehebung.

Sicherheitsleitfaden

Wie geht es weiter