認証リファレンス authentication-reference
このページを使用して、認証フィールドと契約を検索します。 セットアップ手順については、独自のID プロバイダーでエンドユーザーを認証するを参照してください。
認証の設定 authentication-settings
設定 > 認証を開きます。 各環境には、独自の設定が保存されます。 Workspace ピッカーを使用して、編集対象の環境を選択します。設定を保存しても、他の環境には影響しません。
iss要求。 HTTPSである必要があります。 このアプリの認証サーバーとしても公開されます。 アプリごとに1つのID プロバイダー検証ルール
offline_accessは、サポートされている範囲またはアクションに一覧表示されますoffline_accessは、このアプリへのアクセスを許可するのではなく、認証サーバーに更新トークンを要求しているため、このアプリが広告する範囲ではありません。 リストする必要はありません。LLM プラットフォームは、認証サーバーから直接リクエストします発行者の末尾のスラッシュが正規化されます。 issの比較では違いが許容されるため、末尾のスラッシュを常に含むプロバイダーのトークンは引き続き検証されます。
認証モード auth-modes
アクションごとの設定のアクションごとに設定します。
noauthoauth2noauth および oauth2必須 アクションのハンドラーは、有効で正しくスコープ付けされたトークンがなければ実行されません。 オプション アクションのハンドラーは常に実行され、extra.challengeAuth()へのサインイン自体を要求できます。
したがって、Requiredは、未認証の発信者を拒否する唯一のモードです。 アプリは、すべてのアクションが 必須 の場合にのみ、すべての匿名呼び出しを拒否します。 任意のアクションが None または Optional の場合、少なくとも1つのアクションが匿名呼び出しを受け入れるため、アプリは混合認証を使用します。
認証モードは、認証を有効にするが有効な場合にのみ有効になります。 変更は、アプリの次のデプロイメントに影響を与えます。
認証スイッチを変更すると、アクションごとのモードも書き換えられます。
Workspaceを切り替えると、モードが書き換えられません。 ピッカーは、他の環境に保存された設定を変更せずに読み込みます。
認証を有効にするが有効で、すべてのアクションが なし に設定されているため、アプリは認証を必要としませんが、検出のために認証サーバーを公開します。 アプリを完全に公開するには、スイッチをオフにします。
アプリは、個々のアクションに対して異なる認証モードを使用できます。 各プラットフォームでの適用方法については、LLM プラットフォームの動作を参照してください。
トークン要件 token-requirements
ID プロバイダーは、次のすべての要件を満たすアクセストークンを発行する必要があります。 ランタイムは、チェックに失敗したトークンを不在として扱います。呼び出し元は未認証であり、必須 アクションが呼び出し元にサインインを求めます。
RS256、RS384、RS512、ES256、ES384、ES512、PS256、PS384またはPS512。 HS256などのHMAC アルゴリズムは拒否されますissaudexpscope か scp のどちらかにする必要があります。scope文字列を読み取るか、scpの文字列の配列にフォールバックします。 各アクションの要件に照らしてチェックされたスコープには、これらのシェイプのいずれかを使用しますsubgetAuthenticatedUserを読み取るユーザー識別子Authorization: Bearer <token> リクエストヘッダープロバイダーに含まれる追加のフラット要求（例：tenantまたはemail）は、ハンドラーに渡されます。 ネストされたオブジェクトはドロップされ、長い文字列値は切り捨てられます。
ID プロバイダーの検出 discovery
アプリは独自のRFC 9728保護されたリソースメタデータを公開しているため、LLM プラットフォームは認証サーバーを見つけることができます。 保護されたリソースのメタデータを作成、ホスト、設定する必要はありません。
ID プロバイダーは、次の検出情報を提供する必要があります。
jwks_uriを見つけます。OIDC検出パスにフォールバックしません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)は、オプション アクションでのみ使用できます。 ハンドラーから結果を返し、コンテンツを返す代わりにユーザーにログインを依頼します。
ヘルパーは、ChatGPTに対するツール結果チャレンジを返します。 Claudeには、トランスポート レベルのHTTP チャレンジが必要です。 ランタイムは、Required アクションに対してそのチャレンジを提供しますが、オプションのハンドラーヘルパーを使用してはなりません。
errorinvalid_token、insufficient_scopeまたはinvalid_request。 デフォルトは insufficient_scopeerrorDescriptionscopeerrorを明示的に設定してください。 有効なセッションのない発信者にはinvalid_tokenを使用し、トークンは有効だが必要な範囲が不足している発信者にのみinsufficient_scopeを使用します。 ランタイムは値をLLM プラットフォームに渡し、ログインプロンプトの文言を選択します。 任意のプロンプトを使用して、コードではなく条件を正確に記述したコードを送信します。LLM プラットフォームの動作 platform-behavior
どちらのプラットフォームも同じアプリで公開アクションと保護アクションをサポートしていますが、ログイントリガーが異なります。
extra.challengeAuth()現在のクライアントの動作については、Claude lazy authenticationおよびChatGPT authenticationを参照してください。 コネクタのUIとポリシーは、アカウントと組織によって異なります。