アプリケーションデータ構造
はじめに
Logto における アプリケーション とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代わりにアクションを実行する権限を与えられた特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API に対するリクエストの発信元を識別し、これらのアプリケーションにアクセスするユーザーの認証 (Authentication) および認可 (Authorization) プロセスを管理するために使用されます。
Logto のサインイン体験におけるアプリケーションの使用により、ユーザーは一元的な場所から認可されたアプリケーションに簡単にアクセスし、管理することができ、一貫性のある安全な認証 (Authentication) プロセスを提供します。これにより、ユーザー体験が簡素化され、組織の代わりに機密情報にアクセスしたりアクションを実行したりするのは認可された個人のみであることが保証されます。
アプリケーションは、Logto の監査ログでも使用され、ユーザーの活動を追跡し、潜在的なセキュリティ脅威や侵害を特定します。特定のアクションを特定のアプリケーションに関連付けることにより、Logto はデータがどのようにアクセスされ、使用されているかについての詳細な洞察を提供し、組織がセキュリティおよびコンプライアンス要件をより適切に管理できるようにします。 アプリケーションを Logto と統合したい場合は、Logto の統合を参照してください。
プロパティ
アプリケーション ID
アプリケーション ID は、Logto 内でアプリケーションを識別するための一意の自動生成キーであり、OAuth 2.0 では client id として参照されます。
アプリケーションタイプ
アプリケーション は、次のいずれかのアプリケーションタイプにすることができます：
- ネイティブアプリ は、ネイティブ環境で実行されるアプリです。例：iOS アプリ、Android アプリ。
- デバイスフローアプリ は、入力が制限されたデバイスやヘッドレスアプリケーション（例：スマートテレビ、ゲームコンソール、CLI ツール、IoT デバイス）向けの特別なタイプのネイティブアプリです。標準のリダイレクトベースのフローの代わりに OAuth 2.0 デバイス認可グラント を使用します。詳細は デバイスフローのクイックスタート を参照してください。
- シングルページアプリ は、Web ブラウザで実行され、サーバーからの新しいデータでページを更新し、完全に新しいページを読み込むことなく動作するアプリです。例：React DOM アプリ、Vue アプリ。
- 従来の Web アプリ は、Web サーバーによってページをレンダリングおよび更新するアプリです。例：JSP、PHP。
- マシン間通信 (M2M) アプリ は、ユーザーの操作なしにサービス間通信を直接行うためのマシン環境で実行されるアプリケーションです。
アプリケーションシークレット
アプリケーションシークレット は、認証 (Authentication) システム内でアプリケーションを認証するために使用されるキーであり、特にプライベートクライアント（従来の Web アプリおよび M2M アプリ）に対するプライベートなセキュリティバリアとして機能します。
シングルページアプリ (SPA) およびネイティブアプリは、アプリシークレットを提供しません。SPA およびネイティブアプリは「パブリッククライアント」であり、シークレットを保持できません（ブラウザコードやアプリバンドルは検査可能です）。アプリシークレットの代わりに、Logto は PKCE、厳格なリダイレクト URI / CORS 検証、短命のアクセス トークン、およびリフレッシュ トークンのローテーションでそれらを保護します。
アプリケーション名
アプリケーション名 は、人間が読みやすいアプリケーションの名前であり、管理コンソールに表示されます。
アプリケーション名 は、Logto でアプリケーションを管理する上で重要なコンポーネントであり、管理者がプラットフォーム内の個々のアプリケーションの活動を簡単に識別および追跡できるようにします。
アプリケーション名 は、管理コンソールにアクセスできるすべてのユーザーに表示されるため、慎重に選択する必要があります。アプリケーションの目的と機能を正確に反映し、理解しやすく認識しやすいものであるべきです。
説明
アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的、機能、およびその他の関連する詳細情報を管理者に提供することを目的としています。
リダイレクト URI
リダイレクト URI は、アプリケーションのために事前に構成された有効なリダイレクト URI のリストです。ユーザーが Logto にサインインし、アプリケーションにアクセスしようとすると、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。
許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto に送信される認可 (Authorization) リクエストに含まれるリダイレクト URI を検証するために使用されます。認可 (Authorization) リクエストで指定されたリダイレクト URI がアプリケーション設定の許可された URI のいずれかと一致する場合、ユーザーは認証 (Authentication) に成功した後、その URI にリダイレクトされます。リダイレクト URI が許可リストにない場合、ユーザーはリダイレクトされず、認証 (Authentication) プロセスは失敗します。
すべての有効なリダイレクト URI が Logto のアプリケーションの許可リストに追加されていることを確認することが重要です。これにより、ユーザーが認証 (Authentication) 後にアプリケーションに正常にアクセスできるようになります。
リダイレクションエンドポイント を参照して、詳細情報を確認できます。
OIDC における認可コードフローでのリダイレクト URI の理解
ワイルドカードパターン
利用可能性: シングルページアプリ、従来の Web アプリ
リダイレクト URI は、プレビュー展開などの動的環境のためにワイルドカードパターン (*) をサポートしています。ワイルドカードは、HTTP / HTTPS URI のホスト名およびパス名コンポーネントで使用できます。
ルール:
- ワイルドカードはホスト名およびパス名でのみ許可されます
- ワイルドカードはスキーム、ポート、クエリパラメータ、またはハッシュフラグメントでは許可されません
- ホスト名のワイルドカードには少なくとも 1 つのドットを含める必要があります（例：
https://*.example.com/callback）
例:
https://*.example.com/callback- 任意のサブドメインに一致https://preview-*.example.com/callback- プレビュー展開に一致https://example.com/*/callback- 任意のパスセグメントに一致
ワイルドカードリダイレクト URI は標準の OIDC ではなく、攻撃の表面を増やす可能性があります。可能な限り正確なリダイレクト URI を使用することをお勧めします。
サインアウト後のリダイレクト URI
サインアウト後のリダイレクト URI は、Logto からサインアウトした後にユーザーをリダイレクトするためにアプリケーションに事前に構成された有効な URI のリストです。
ログアウトのための許可された サインアウト後のリダイレクト URI の使用は、OIDC の RP-Initiated (Relying Party Initiated) Logout 仕様の一部です。この仕様は、ユーザーのログアウトリクエストをアプリケーションが開始するための標準化された方法を提供し、ユーザーがサインアウトした後に事前に構成されたエンドポイントにリダイレクトすることを含みます。
ユーザーが Logto からサインアウトすると、そのセッションは終了し、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。これにより、ユーザーがサインアウトした後に認可された有効なエンドポイントにのみリダイレクトされることが保証され、ユーザーを未知または未確認のエンドポイントにリダイレクトすることによる不正アクセスやセキュリティリスクを防ぐことができます。
RP-initiated logout を参照して、詳細情報を確認できます。
CORS 許可されたオリジン
CORS (クロスオリジンリソース共有) 許可されたオリジン は、アプリケーションが Logto サービスにリクエストを行うことができる許可されたオリジンのリストです。許可リストに含まれていないオリジンは、Logto サービスにリクエストを行うことができません。
CORS 許可されたオリジンリストは、未承認のドメインからの Logto サービスへのアクセスを制限し、クロスサイトリクエストフォージェリ (CSRF) 攻撃を防ぐのに役立ちます。Logto でアプリケーションの許可されたオリジンを指定することにより、サービスは許可されたドメインのみがサービスにリクエストを行うことができるようにします。
許可されたオリジンリストには、アプリケーションが提供されるオリジンを含める必要があります。これにより、アプリケーションからのリクエストが許可され、未承認のオリジンからのリクエストがブロックされます。
OpenID プロバイダー構成エンドポイント
OpenID Connect Discovery のエンドポイント。
認可 (Authorization) エンドポイント
認可 (Authorization) エンドポイント は OIDC 用語であり、ユーザーの認証 (Authentication) プロセスを開始するために使用される必須のエンドポイントです。Logto プラットフォームに登録された保護されたリソースまたはアプリケーションにユーザーがアクセスしようとすると、認可 (Authorization) エンドポイント にリダイレクトされ、アイデンティティを認証 (Authentication) し、要求されたリソースへのアクセスを取得します。
認可 (Authorization) エンドポイント を参照して、詳細情報を確認できます。
トークンエンドポイント
トークンエンドポイント は OIDC 用語であり、OIDC クライアントが OIDC プロバイダーからアクセス トークン、ID トークン、またはリフレッシュ トークンを取得するために使用される Web API エンドポイントです。
OIDC クライアントがアクセス トークンまたは ID トークンを取得する必要がある場合、トークンエンドポイントに認可 (Authorization) グラント（通常は認可コードまたはリフレッシュ トークン）を含むリクエストを送信します。トークンエンドポイントは認可 (Authorization) グラントを検証し、グラントが有効であればクライアントにアクセス トークンまたは ID トークンを発行します。
トークンエンドポイント を参照して、詳細情報を確認できます。
ユーザー情報エンドポイント
OpenID Connect ユーザー情報エンドポイント。
常にリフレッシュ トークンを発行する
利用可能性: 従来の Web、SPA
有効にすると、Logto は prompt=consent が認証 (Authentication) リクエストに提示されているかどうか、または offline_access がスコープに提示されているかどうかに関係なく、常にリフレッシュ トークンを発行します。
ただし、これは OpenID Connect と互換性がなく、問題を引き起こす可能性があるため、必要な場合を除いて（通常、リフレッシュ トークンを必要とする一部のサードパーティ OAuth 統合に役立ちます）、この方法は推奨されません。
リフレッシュ トークンのローテーション
デフォルト: true
有効にすると、Logto は次の条件下でトークンリクエストに対して新しいリフレッシュ トークンを発行します：
- リフレッシュ トークンが 1 年間ローテーションされた場合（新しいものを発行して TTL が延長された場合）；または
- リフレッシュ トークンが有効期限に近づいている場合（元の Time to Live (TTL) の >=70% が経過した場合）；または
- クライアントがパブリッククライアントである場合、例：ネイティブアプリケーションまたはシングルページアプリケーション (SPA)。
パブリッククライアントの場合、この機能が有効になっていると、クライアントがリフレッシュ トークンを使用して新しいアクセス トークンを交換する際に常に新しいリフレッシュ トークンが発行されます。 これらのパブリッククライアントに対しても機能をオフにすることはできますが、セキュリティ上の理由から有効にしておくことを強くお勧めします。
リフレッシュ トークンのローテーションの理解
リフレッシュ トークンの有効期間 (TTL) （日数）
利用可能性: SPA ではない；デフォルト: 14 日
リフレッシュ トークンが新しいアクセス トークンを要求するために使用できる期間であり、有効期限が切れて無効になるまでの期間です。トークンリクエストは、リフレッシュ トークンの TTL をこの値に延長します。
通常、より低い値が推奨されます。
注意: セキュリティ上の理由から、SPA（シングルページアプリ）では TTL の更新は利用できません。つまり、Logto はトークンリクエストを通じて TTL を延長しません。ユーザー体験を向上させるために、「リフレッシュ トークンのローテーション」機能を有効にして、必要に応じて Logto が新しいリフレッシュ トークンを発行できるようにすることができます。
認可 (Authorization) リクエストで offline_access スコープなしでリフレッシュ トークンが発行された場合、それはユーザーセッションにバインドされます。セッションの TTL は 14 日 に固定されています。セッションが期限切れになると、リフレッシュ トークンはその独自の TTL 設定に関係なく無効になります。
リフレッシュ トークンの TTL 設定が完全に効果を発揮するようにするには、認可 (Authorization) リクエストに offline_access スコープを含めることを確認してください。
バックチャネルログアウト URI
OpenID Connect のバックチャネルログアウトエンドポイント。詳細は フェデレーテッドサインアウト: バックチャネルログアウト を参照してください。
最大許可グラント数 (maxAllowedGrants)
maxAllowedGrants は、現在のアプリに対するユーザーごとの同時アクティブグラントの最大数を制御する customClientMetadata の下のオプションのアプリレベルフィールドです。
- デフォルト:
undefined（制限なし） - 設定時: 各認可 (Authorization) 成功時に、Logto は現在のアプリでのユーザーの総アクティブグラントを確認します（ブラウザおよびデバイス全体で）。制限を超えた場合、Logto は最も古いグラントを取り消します。
この設定は、アプリごとに同時認証されたデバイスを制限したい場合に便利です。
このフィールドは次のものにはサポートされていません：
- マシン間通信アプリ
- 保護されたアプリ
- SAML アプリ
カスタムデータ
事前定義されたアプリケーションプロパティにリストされていない追加のカスタムアプリケーション情報であり、ユーザーはビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。