メインコンテンツまでスキップ

アプリケーションデータ構造

はじめに​

Logto における アプリケーション とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代理でアクションを実行する権限が付与された特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API へのリクエスト元の識別や、ユーザーがそれらのアプリケーションにアクセスする際の認証 (Authentication) および認可 (Authorization) プロセスの管理に使用されます。

Logto のサインイン体験におけるアプリケーションの利用により、ユーザーは一元的な場所から認可されたアプリケーションへ簡単にアクセス・管理でき、統一された安全な認証 (Authentication) プロセスが実現されます。これにより、ユーザー体験が効率化され、認可された人物のみが機密情報へアクセスしたり、組織の代理でアクションを実行できるようになります。

また、アプリケーションは Logto の監査ログでも使用され、ユーザーアクティビティの追跡や潜在的なセキュリティ脅威・侵害の特定に役立ちます。特定のアクションを特定のアプリケーションと関連付けることで、Logto はデータのアクセス・利用状況について詳細なインサイトを提供し、組織がセキュリティやコンプライアンス要件をより適切に管理できるようにします。 アプリケーションを Logto と統合したい場合は、 Logto との統合 をご覧ください。

プロパティ​

アプリケーション ID​

アプリケーション ID は、Logto 内でアプリケーションを識別するための一意な自動生成キーであり、OAuth 2.0 では client id として参照されます。

アプリケーションタイプ​

アプリケーション は、次のいずれかのタイプとなります：

  • ネイティブアプリ：ネイティブ環境で動作するアプリ。例：iOS アプリ、Android アプリ。
    • デバイスフローアプリ：入力制限のあるデバイスやヘッドレスアプリケーション（例：スマート TV、ゲーム機、CLI ツール、IoT デバイス）向けの特別なネイティブアプリです。標準のリダイレクトベースフローの代わりに OAuth 2.0 Device Authorization Grant を使用します。詳細は デバイスフロー クイックスタート を参照してください。
  • シングルページアプリ：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 へ送信される認可リクエストに含まれるリダイレクト URI の検証に使用されます。認可リクエストで指定されたリダイレクト URI がアプリケーション設定の許可リストのいずれかと一致する場合、認証 (Authentication) 成功後にその 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 のいずれかにリダイレクトされます。これにより、サインアウト後にユーザーが認可された有効なエンドポイントのみに誘導され、未知または未検証のエンドポイントへのリダイレクトによる不正アクセスやセキュリティリスクを防ぎます。

詳細は RP-initiated logout をご覧ください。

CORS 許可オリジン​

CORS（クロスオリジンリソースシェアリング）許可オリジン は、アプリケーションが Logto サービスへリクエストを送信できる許可されたオリジンのリストです。許可リストに含まれていないオリジンからは Logto サービスへのリクエストはできません。

CORS 許可オリジンリストは、未認可ドメインからの Logto サービスへのアクセスを制限し、クロスサイトリクエストフォージェリ（CSRF）攻撃の防止にも役立ちます。Logto でアプリケーションごとに許可オリジンを指定することで、認可されたドメインのみがサービスへリクエストできるようにします。

注記:

許可オリジンリストには、アプリケーションが提供されるオリジンを含めてください。これにより、アプリケーションからのリクエストは許可され、未認可オリジンからのリクエストはブロックされます。

OpenID プロバイダー構成エンドポイント​

OpenID Connect Discovery のためのエンドポイントです。

認可エンドポイント​

認可エンドポイント は OIDC 用語であり、ユーザーの認証 (Authentication) プロセスを開始するために使用される必須エンドポイントです。Logto プラットフォームに登録された保護されたリソースやアプリケーションへユーザーがアクセスしようとすると、認可エンドポイント へリダイレクトされ、アイデンティティの認証 (Authentication) およびリソースへのアクセス権限の取得が行われます。

詳細は Authorization Endpoint をご覧ください。

トークンエンドポイント​

トークンエンドポイント は OIDC 用語であり、OIDC クライアントが OIDC プロバイダーからアクセス トークン、ID トークン、リフレッシュ トークンを取得するための Web API エンドポイントです。

OIDC クライアントがアクセス トークンや ID トークンを取得する必要がある場合、認可グラント（通常は認可コードまたはリフレッシュ トークン）とともにトークンエンドポイントへリクエストを送信します。トークンエンドポイントは認可グラントを検証し、有効であればクライアントにアクセス トークンや ID トークンを発行します。

詳細は Token Endpoint をご覧ください。

Userinfo エンドポイント​

OpenID Connect の UserInfo Endpoint です。

常にリフレッシュ トークンを発行​

対象：従来型 Web、SPA

有効にすると、認証 (Authentication) リクエストで prompt=consent やスコープに offline_access が指定されていなくても、Logto は常にリフレッシュ トークンを発行します。

ただし、この運用は必要な場合（通常はリフレッシュ トークンを必要とする一部のサードパーティ OAuth 連携）を除き推奨されません。OpenID Connect との互換性がなく、問題が発生する可能性があります。

リフレッシュ トークンのローテーション​

デフォルト：true

有効にすると、クライアントがリフレッシュ トークンを使って新しいトークンをリクエストする際に、新しいリフレッシュ トークンが発行される場合があります。リフレッシュ トークンとそのアプリアクセス許可が有効な場合、デフォルトのローテーションポリシーは次の通りです：

  • リフレッシュ トークンは、リフレッシュ トークンチェーンが 1 年間存在するまでのみローテーション可能です。これは内部的なローテーション安全上限であり、リフレッシュ トークン自体の TTL やアプリアクセス許可の TTL が先に切れる場合もあります。上限に達すると、Logto はリフレッシュ トークンをローテーションせず、現在のリフレッシュ トークンの有効期限が最終となります。
  • センダー制約付きリフレッシュ トークンを使用しないパブリッククライアント（通常のネイティブアプリやシングルページアプリなど）では、ローテーションが許可されている間はリフレッシュ トークンリクエストごとにリフレッシュ トークンをローテーションします。
  • その他のクライアントでは、有効期限が近づいた場合（元の TTL の 70％以上経過）にのみリフレッシュ トークンをローテーションします。
注記:

パブリッククライアントでは、セキュリティ上の理由からリフレッシュ トークンのローテーションを有効にしておくことを強く推奨します。

センダー制約付きリフレッシュ トークンは、クライアントが保持する証明鍵や証明書にバインドされます。通常の SPA では、ローテーションにより新しいリフレッシュ トークンが発行されますが、リフレッシュ トークンの有効期間は延長されません。新しいリフレッシュ トークンは前のリフレッシュ トークンの残り TTL を継承します。

リフレッシュ トークンチェーンの有効期間:

リフレッシュ トークンはアプリアクセス許可に紐づいています。Logto のデフォルトのアクセス許可 TTL は 180 日 です。アクセス許可が失効すると、リフレッシュ トークンリクエストは失敗し、リフレッシュ トークンは新しいトークンの取得に使用できなくなります。リフレッシュ トークンのローテーションが有効でも同様です。

つまり、リフレッシュ トークンによる認可の実質的な最大有効期間は、アクセス許可 TTL、明示的な失効、またはリフレッシュ トークン自体の有効期限のいずれか早い方で制限されます。

リフレッシュ トークンローテーションの理解

リフレッシュ トークンの有効期間（TTL、日数）​

対象：ネイティブアプリ、従来型 Web、SPA；デフォルト：14 日；最大：180 日

リフレッシュ トークンが新しいアクセス トークンをリクエストできる有効期間です。有効期間を過ぎるとリフレッシュ トークンは無効となります。トークンリクエストによりリフレッシュ トークンの TTL はこの値まで延長されます。

通常は、より低い値が推奨されます。

注記:

SPA（シングルページアプリ）ではセキュリティ上の理由から TTL の延長はできません。SPA ではこの設定がリフレッシュ トークンの発行時からの固定有効期間となります。Logto はトークンリクエストによる TTL 延長を行わず、リフレッシュ トークンのローテーションも SPA のリフレッシュ トークンの有効期限切れを防ぎません。

リフレッシュ トークン TTL とアクセス許可 TTL:

リフレッシュ トークン TTL だけが有効期限の制限ではありません。リフレッシュ トークンはアプリアクセス許可に紐づいており、Logto のデフォルトのアクセス許可 TTL は 180 日 です。アクセス許可が失効すると、リフレッシュ トークンが有効でもリクエストは失敗します。

トークンリクエストでリフレッシュ トークン TTL が延長されるクライアントでは、アクセス許可 TTL がリフレッシュ トークンチェーンの絶対最大有効期間となります。SPA ではリフレッシュ トークンの固定 TTL がアクセス許可より先に切れる場合もあります。

リフレッシュ トークンとセッションバインディング:

認可リクエストで offline_access スコープを指定 しない 場合、リフレッシュ トークンはユーザーセッションにバインドされます。セッションの固定 TTL は 14 日 です。セッションが失効すると、リフレッシュ トークンは自身の TTL 設定に関わらず無効となります。

リフレッシュ トークン TTL 設定を最大限活用するには、認可リクエストに offline_access スコープを必ず含めてください。

バックチャネルログアウト URI​

OpenID Connect のバックチャネルログアウトエンドポイントです。詳細は フェデレーションサインアウト：バックチャネルログアウト をご覧ください。

最大許可グラント数（maxAllowedGrants）​

maxAllowedGrants は、customClientMetadata 配下のオプションのアプリレベルフィールドで、現在のアプリにおけるユーザーごとの同時アクティブグラント数の上限を制御します。

  • デフォルト：undefined（制限なし）
  • 設定時：認可が成功するたびに、Logto は現在のアプリでのユーザーのアクティブグラント総数（ブラウザやデバイスをまたいで）をチェックします。上限を超えた場合、Logto は最も古いグラントを失効させます。

この設定は、アプリごとに同時認証デバイス数を制限したい場合に便利です。

注記:

このフィールドは以下には対応していません：

  • マシン間通信アプリ
  • 保護されたアプリ
  • SAML アプリ

カスタムデータ​

事前定義されたアプリケーションプロパティに含まれない追加のカスタムアプリ情報です。ユーザーは、ビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。