Authentifizierungsreferenz authentication-reference
Auf dieser Seite können Sie Authentifizierungsfelder und Verträge nachschlagen. Informationen zur Setup-Journey finden Sie unter Endbenutzer bei Ihrem eigenen Identitätsanbieter authentifizieren.
Authentifizierungseinstellungen authentication-settings
Gefunden unter Einstellungen > Authentifizierung. Jedes Feld wird pro Umgebung gespeichert - die Auswahl Workspace wählt aus, welche Sie bearbeiten, und das Speichern wirkt sich nie auf die andere Umgebung aus.
iss. Muss HTTPS sein. Wird auch als Autorisierungs-Server dieser App veröffentlicht. Ein Identitätsanbieter pro AppValidierungsregeln
offline_access wird in Unterstützte Bereiche oder in einer Aktion aufgeführtoffline_access fordert ein Aktualisierungs-Token von Ihrem Autorisierungs-Server an, anstatt Zugriff auf diese App zu gewähren, sodass es sich nicht um einen Bereich handelt, für den diese App wirbt. Sie müssen sie nicht auflisten - die LLM-Plattform fordert sie direkt von Ihrem Autorisierungs-Server anNachfolgende Schrägstriche bei Aussteller werden normalisiert, und der iss Vergleich toleriert den Unterschied - ein Anbieter, der immer einen nachfolgenden Schrägstrich ausgibt, validiert weiterhin.
Authentifizierungsmodi auth-modes
Festgelegt pro Aktion unter Konfiguration pro Aktion.
noauthoauth2noauth und oauth2Der Handler einer Erforderlich-Aktion wird nie ohne ein gültiges Token mit korrektem Bereich ausgeführt. Der Handler einer Optional-Aktion wird immer ausgeführt und kann die Anmeldung selbst mit extra.challengeAuth() anfordern.
Erforderlich ist daher der einzige Modus, der nicht authentifizierte Aufrufer ablehnt. Eine App wird nur dann vollständig erfasst, wenn jede ihrer Aktionen Erforderlich ist. Eine einzelne Keine oder Optional Aktion sorgt für eine Mischung der App, da anonyme Aufrufe für mindestens eine Aktion immer noch erfolgreich sind.
Authentifizierungsmodi sind nur gültig, wenn Authentifizierung aktivieren aktiviert ist. Änderungen werden bei der nächsten Bereitstellung der App wirksam.
Durch Umschalten dieses Schalters werden die Modi für die einzelnen Aktionen neu geschrieben:
Beim Wechsel zu Workspace werden die Modi nie neu geschrieben. Die gespeicherte Konfiguration der anderen Umgebung wird unverändert geladen.
Authentifizierung aktivieren bei jeder auf "" gesetzten Aktion eine gültige, aber inaktive Kombination: Es wird nie ein Aufruf abgelehnt, und die App veröffentlicht dennoch ihren Autorisierungs-Server zur Erkennung. Schalten Sie den Schalter aus, um die App vollständig öffentlich zu machen.
Modi können in einer App frei gemischt werden. Siehe LLM-Plattformverhalten, wie sie von den einzelnen Plattformen angewendet werden.
Token-Anforderungen token-requirements
Ihr Identitätsanbieter muss Zugriffstoken ausstellen, die alle folgenden Bedingungen erfüllen. Ein Token, bei dem eine Überprüfung fehlschlägt, wird als abwesend behandelt - der Aufrufer ist nicht authentifiziert, und eine Erforderlich-Aktion fordert ihn zur Anmeldung auf.
RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 oder PS512. HMAC-Algorithmen wie HS256 werden abgelehntissaudexpscope oder scpsubgetAuthenticatedUserAuthorization: Bearer <token>-HeaderAlle zusätzlichen flachen Ansprüche, die Ihr Anbieter enthält - z. B. tenant oder email -, werden an Ihren Handler weitergeleitet. Verschachtelte Objekte werden entfernt, und lange Zeichenfolgenwerte werden abgeschnitten.
Identitätsanbietererkennung discovery
Ihre App veröffentlicht ihre eigenen RFC 9728 geschützten Ressourcenmetadaten, damit LLM-Plattformen Ihren Autorisierungs-Server finden können. Sie erstellen, hosten oder konfigurieren keine hierfür erforderlichen Elemente.
Sie müssen Discovery auf Ihrer eigenen Seite bereitstellen:
/.well-known/ bereitstellen. Ihre App liest es, um Ihre Signierschlüssel zu findenhttps://auth.example.com/oauth2/default stellt seine Metadaten unter https://auth.example.com/.well-known/oauth-authorization-server/oauth2/default bereitHandler-Authentifizierungs-API handler-auth-api
Aus @adobe/llm-apps-runtime exportiert. Jeder Helper benötigt extra, das zweite Argument, das Ihr Handler erhält.
getAuthenticatedUser(extra)sub Anspruch des angemeldeten Benutzers oder der undefined, wenn der Aufruf nicht authentifiziert wirdhasScope(extra, scope)true, wenn das Token des Aufrufers scope enthältDie unbearbeiteten Informationen zum verifizierten Token befinden sich auf extra.authInfo, was für einen nicht authentifizierten Aufruf undefined wird.
authInfo.tokenauthInfo.clientIdclient_id oder azp Forderung oder unknownauthInfo.scopesauthInfo.expiresAtexp behauptetauthInfo.resourceauthInfo.extrasub plus alle anderen Pauschalansprüche, die Ihr Identitätsanbieter beinhaltetextra.challengeAuth(options) ist nur für optionale Aktionen verfügbar. Geben Sie das Ergebnis von Ihrem Handler zurück, um den Benutzer zu bitten, sich anzumelden, anstatt Inhalte zurückzugeben.
errorinvalid_token, insufficient_scope oder invalid_request. Standardwert ist insufficient_scopeerrorDescriptionscopeerror. Verwenden Sie invalid_token für einen Aufrufer ohne gültige Sitzung und insufficient_scope nur für einen Aufrufer, dessen Token gültig ist, aber keinen erforderlichen Gültigkeitsbereich hat. Der Wert wird an die LLM-Plattform übergeben, die selbst entscheidet, wie die Eingabeaufforderung für den Benutzer formuliert wird. Senden Sie den Code, der die Bedingung genau beschreibt, und nicht den Code, dessen Eingabeaufforderung Sie bevorzugen.LLM-Plattformverhalten platform-behavior
Die Unterstützung für die Authentifizierung einzelner Aktionen variiert je nach Plattform. Konfigurieren Sie für beide auf die gleiche Weise, denn der Unterschied besteht darin, was den Benutzenden angezeigt wird.