認証リファレンス authentication-reference
このページを使用して、認証フィールドと契約を検索します。 セットアップ ジャーニーについては、独自のID プロバイダーでエンドユーザーを認証するを参照してください。
認証の設定 authentication-settings
設定 > 認証の下に見つかりました。 すべてのフィールドは環境ごとに保存されます。Workspace ピッカーは、どのフィールドを編集するかを選択し、保存しても他のフィールドには影響しません。
iss要求。 HTTPSである必要があります。 このアプリの認証サーバーとしても公開されます。 アプリごとに1つのID プロバイダー検証ルール
offline_accessは、サポートされている範囲またはアクションに一覧表示されますoffline_accessは、このアプリへのアクセスを許可するのではなく、認証サーバーに更新トークンを要求しているため、このアプリが広告する範囲ではありません。 リストする必要はありません。LLM プラットフォームは、認証サーバーから直接リクエストします発行者の末尾のスラッシュは正規化され、issの比較では違いが許容されます。末尾のスラッシュを常に送信するプロバイダーは、引き続き検証されます。
認証モード auth-modes
アクションごとの設定のアクションごとに設定します。
noauthoauth2noauth および oauth2必須 アクションのハンドラーは、有効で正しくスコープ付けされたトークンがなければ実行されません。 オプション アクションのハンドラーは常に実行され、extra.challengeAuth()へのサインイン自体を要求できます。
したがって、Requiredは、未認証の発信者を拒否する唯一のモードです。 アプリが完全にゲートされるのは、すべてのアクションが 必須 の場合のみです。1つの なし またはオプション アクションを実行すると、アプリが混在します。これは、少なくとも1つのアクションで匿名呼び出しが成功するためです。
認証モードは、認証を有効にするが有効な場合にのみ有効になります。 変更は、アプリの次のデプロイに影響を与えます。
スイッチを切り替えると、アクションごとのモードが書き換えられます。
Workspaceを切り替えると、モードは書き換えられません。他の環境の保存された設定をそのまま読み込みます。
すべてのアクションが None に設定された上で認証を有効にする は、有効だが無効な組み合わせです。呼び出しは拒否されませんが、アプリは引き続き検出のために認証サーバーを公開します。 アプリを完全に公開するには、切り替えスイッチをオフにします。
モードは、1つのアプリ間で自由に混在できます。 各プラットフォームでの適用方法については、LLM プラットフォームの動作を参照してください。
トークン要件 token-requirements
ID プロバイダーは、次のすべての要件を満たすアクセストークンを発行する必要があります。 チェックに失敗したトークンは不在として扱われます。呼び出し元は未認証であり、必須 アクションにより、ログインが要求されます。
RS256、RS384、RS512、ES256、ES384、ES512、PS256、PS384またはPS512。 HS256などのHMAC アルゴリズムは拒否されますissaudexpscope か scp のどちらかにする必要があります。subgetAuthenticatedUserを読み取るユーザー識別子Authorization: Bearer <token> リクエストヘッダープロバイダーに含まれる追加のフラット要求（例：tenantまたはemail）は、ハンドラーに渡されます。 ネストされたオブジェクトはドロップされ、長い文字列値は切り捨てられます。
ID プロバイダーの検出 discovery
アプリは独自のRFC 9728保護されたリソースメタデータを公開しているため、LLM プラットフォームは認証サーバーを見つけることができます。 作成、ホスト、または設定は行いません。
自分自身で発見を提供する必要があります：
/.well-known/ パスで提供する必要があります。 アプリはそれを読み取り、署名キーを見つけますhttps://auth.example.com/oauth2/defaultのイシュアは、https://auth.example.com/.well-known/oauth-authorization-server/oauth2/defaultでメタデータを提供しますハンドラー認証API handler-auth-api
@adobe/llm-apps-runtimeからエクスポートしました。 各ヘルパーはextraを受け取ります。これは、ハンドラーが受け取る2番目の引数です。
getAuthenticatedUser(extra)sub要求、または呼び出しが未認証の場合はundefinedhasScope(extra, scope)true呼び出し元のトークンがscopeを含む場合未認証の検証済みトークン情報はextra.authInfoにあり、未認証の呼び出しではundefinedです。
authInfo.tokenauthInfo.clientIdclient_idまたはazpの要求、またはunknownauthInfo.scopesauthInfo.expiresAtexp件の要求authInfo.resourceauthInfo.extrasubに加えて、ID プロバイダーが含まれているその他のフラットな請求extra.challengeAuth(options)は、オプション アクションでのみ使用できます。 ハンドラーから結果を返し、コンテンツを返す代わりにユーザーにログインを依頼します。
errorinvalid_token、insufficient_scopeまたはinvalid_request。 デフォルトは insufficient_scopeerrorDescriptionscopeerrorを明示的に設定してください。 有効なセッションのない発信者にはinvalid_tokenを使用し、トークンは有効だが必要な範囲が不足している発信者にのみinsufficient_scopeを使用します。 値はLLM プラットフォームに渡され、ユーザーに表示されるプロンプトの単語を自分で指定します。 プロンプトで希望する条件ではなく、条件を正確に記述したコードを送信します。LLM プラットフォームの動作 platform-behavior
個々のアクションの認証のサポートは、プラットフォームによって異なります。 両者で同じ方法を設定します。両者の違いは、オーディエンスが体験するものです。