アプリケーションデータ構造
はじめに
Logto における アプリケーション とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代理での操作を行う権限が付与された特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API へのリクエスト元を識別し、ユーザーがそれらのアプリケーションにアクセスする際の認証 (Authentication) および認可 (Authorization) プロセスを管理するために使用されます。
Logto のサインイン体験におけるアプリケーションの利用により、ユーザーは一元的な場所から認可 (Authorization) されたアプリケーションへ簡単かつ安全にアクセス・管理できるようになります。これにより、ユーザー体験が効率化され、認可 (Authorization) された人物のみが機密情報へアクセスしたり、組織の代理で操作を行ったりできることが保証されます。
また、アプリケーションは Logto の監査ログにも使用され、ユーザーのアクティビティを追跡し、潜在的なセキュリティ脅威や侵害を特定するのに役立ちます。特定の操作を特定のアプリケーションと関連付けることで、Logto はデータがどのようにアクセス・利用されているかについて詳細なインサイトを提供し、組織がセキュリティやコンプライアンス要件をより適切に管理できるようにします。 アプリケーションを Logto と連携したい場合は、 Logto 連携 をご覧ください。
プロパティ
アプリケーション ID
アプリケーション ID は、Logto 内でアプリケーションを識別するための一意の自動生成キーであり、OAuth 2.0 では client id として参照されます。
アプリケーションタイプ
アプリケーション は、次のいずれかのアプリケーションタイプとなります：
- ネイティブアプリ：ネイティブ環境で動作するアプリ。例：iOS アプリ、Android アプリ。
- シングルページアプリ：Web ブラウザ上で動作し、サーバーから新しいデータを取得してページ全体を再読み込みせずに更新するアプリ。例：React DOM アプリ、Vue アプリ。
- 従来型 Web アプリ：Web サーバーのみでページをレンダリング・更新するアプリ。例：JSP、PHP。
- マシン間通信 (M2M) アプリ：ユーザー操作なしでサービス間通信を直接行うマシン環境で動作するアプリケーション。
アプリケーションシークレット
アプリケーションシークレット は、認証 (Authentication) システム内でアプリケーションを認証 (Authentication) するためのキーであり、特にプライベートクライアント（従来型 Web および M2M アプリ）に対するプライベートなセキュリティバリアとして機能します。
シングルページアプリ (SPA) およびネイティブアプリは、アプリシークレットを提供しません。SPA およびネイティブアプリは「パブリッククライアント」であり、シークレットを保持できません（ブラウザコードやアプリバンドルは検査可能なため）。アプリシークレットの代わりに、Logto は PKCE、厳格なリダイレクト URI / CORS 検証、短命なアクセス トークン、リフレッシュ トークンのローテーションで保護します。
アプリケーション名
アプリケーション名 は、アプリケーションの人間が読める名称であり、管理コンソールに表示されます。
アプリケーション名 は Logto でアプリケーションを管理する上で重要な要素であり、管理者がプラットフォーム内で個々のアプリケーションのアクティビティを簡単に識別・追跡できるようにします。
アプリケーション名 は管理コンソールにアクセスできるすべてのユーザーに表示されるため、慎重に選択することが重要です。アプリケーションの目的や機能を正確に反映し、分かりやすく認識しやすい名称にしてください。
説明
アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的や機能、その他関連情報など、管理者に追加情報を提供することを意図しています。
リダイレクト URI
リダイレクト URI は、アプリケーションに事前設定された有効なリダイレクト URI のリストです。ユーザーが Logto にサインインしアプリケーションへアクセスしようとすると、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。
許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto へ送信される認可 (Authorization) リクエストに含まれるリダイレクト URI を検証するために使用されます。認可 (Authorization) リクエストで指定されたリダイレクト URI がアプリケーション設定の許可リストのいずれかと一致する場合、認証 (Authentication) 成功後にその URI へリダイレクトされます。リダイレクト URI が許可リストにない場合、リダイレクトされず認証 (Authentication) プロセスは失敗します。
すべての有効なリダイレクト URI を Logto のアプリケーションの許可リストに追加しておくことが重要です。これにより、認証 (Authentication) 後にユーザーが正常にアプリケーションへアクセスできるようになります。
詳細は Redirection endpoint をご覧ください。
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 のリストです。
Allowed Post Sign-out Redirect URIs の利用は、OIDC の RP-Initiated (Relying Party Initiated) Logout 仕様の一部です。この仕様は、アプリケーションがユーザーのログアウトリクエストを開始し、サインアウト後にユーザーを事前設定されたエンドポイントへリダイレクトする標準化された方法を提供します。
ユーザーが Logto からサインアウトすると、そのセッションは終了し、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。これにより、サインアウト後にユーザーが認可 (Authorization) された有効なエンドポイントのみに誘導され、未知または未検証のエンドポイントへのリダイレクトによる不正アクセスやセキュリティリスクを防ぎます。
詳細は RP-initiated logout をご覧ください。
CORS 許可オリジン
CORS (クロスオリジンリソースシェアリング) 許可オリジン は、アプリケーションが Logto サービスへリクエストを送信できる許可済みオリジンのリストです。許可リストに含まれていないオリジンからは Logto サービスへのリクエストはできません。
CORS 許可オリジンリストは、未認可ドメインからの Logto サービスへのアクセスを制限し、クロスサイトリクエストフォージェリ (CSRF) 攻撃の防止にも役立ちます。Logto でアプリケーションごとに許可オリジンを指定することで、認可 (Authorization) されたドメインのみがサービスへリクエストできるようにします。
許可オリジンリストには、アプリケーションが提供されるオリジンを含めてください。これにより、アプリケーションからのリクエストは許可され、未認可オリジンからのリクエストはブロックされます。
OpenID プロバイダー構成エンドポイント
OpenID Connect Discovery のエンドポイントです。
認可 (Authorization) エンドポイント
認可 (Authorization) エンドポイント は OIDC 用語であり、ユーザーの認証 (Authentication) プロセスを開始するために使用される必須エンドポイントです。Logto プラットフォームに登録された保護リソースやアプリケーションへユーザーがアクセスしようとすると、認可 (Authorization) エンドポイント へリダイレクトされ、アイデンティティの認証 (Authentication) およびリソースへの認可 (Authorization) を取得します。
詳細は Authorization Endpoint をご覧ください。
トークンエンドポイント
トークンエンドポイント は OIDC 用語であり、OIDC クライアントが OIDC プロバイダーからアクセス トークン、ID トークン、リフレッシュ トークンを取得するための Web API エンドポイントです。
OIDC クライアントがアクセス トークンや ID トークンを取得する必要がある場合、認可 (Authorization) グラント（通常は認可コードまたはリフレッシュ トークン）を付与してトークンエンドポイントへリクエストを送信します。トークンエンドポイントは認可 (Authorization) グラントを検証し、有効な場合はクライアントにアクセス トークンや ID トークンを発行します。
詳細は Token Endpoint をご覧ください。
Userinfo エンドポイント
OpenID Connect の UserInfo Endpoint です。
常にリフレッシュ トークンを発行
対象: 従来型 Web、SPA
有効にすると、認証 (Authentication) リクエストで prompt=consent やスコープに offline_access が指定されていなくても、Logto は常にリフレッシュ トークンを発行します。
ただし、この運用は OpenID Connect との互換性がなく、問題が発生する可能性があるため、必要な場合（通常はリフレッシュ トークンを必要とする一部のサードパーティ OAuth 連携など）を除き推奨されません。
リフレッシュ トークンのローテーション
デフォルト: true
有効にすると、Logto は以下の条件下でトークンリクエスト時に新しいリフレッシュ トークンを発行します：
- リフレッシュ トークンが 1 年間ローテーション（新しいものが発行され有効期限が延長）された場合；または
- リフレッシュ トークンの有効期限が近い場合（元の TTL の 70% 以上経過）；または
- クライアントがパブリッククライアント（例：ネイティブアプリやシングルページアプリ (SPA)）の場合。
パブリッククライアントの場合、この機能が有効だと、リフレッシュ トークンで新しいアクセス トークンを取得するたびに常に新しいリフレッシュ トークンが発行されます。 パブリッククライアントでもこの機能を無効にできますが、セキュリティ上有効にしておくことを強く推奨します。
リフレッシュ トークンのローテーションの理解
リフレッシュ トークンの有効期間 (TTL) 日数
対象: SPA 以外；デフォルト: 14 日
リフレッシュ トークンが失効し無効になるまで、新しいアクセス トークンをリクエストできる期間です。トークンリクエストにより、リフレッシュ トークンの TTL はこの値まで延長されます。
通常は、より短い値が推奨されます。
注意：SPA（シングルページアプリ）ではセキュリティ上の理由から TTL の延長はできません。つまり、Logto はトークンリクエストによる TTL 延長を行いません。ユーザー体験向上のため、「リフレッシュ トークンのローテーション」機能を有効にすることで、必要に応じて新しいリフレッシュ トークンを発行できます。
認可 (Authorization) リクエストで offline_access スコープ なし でリフレッシュ トークンが発行された場合、そのトークンはユーザーセッションにバインドされます。セッションの TTL は 14 日間 で固定です。セッションが失効すると、リフレッシュ トークンは自身の TTL 設定に関わらず無効となります。
リフレッシュ トークンの TTL 設定を最大限活用するには、認可 (Authorization) リクエストに offline_access スコープを含めてください。
バックチャネルログアウト URI
OpenID Connect のバックチャネルログアウトエンドポイントです。詳細は フェデレーションサインアウト：バックチャネルログアウト をご覧ください。
カスタムデータ
事前定義されたアプリケーションプロパティに含まれない追加のカスタムアプリケーション情報です。ユーザーは、ビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。