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

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

はじめに​

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

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

また、アプリケーションは 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) システムでアプリケーションを認証 (Authentication) するためのキーであり、特にプライベートクライアント（従来型 Web および M2M アプリ）でプライベートなセキュリティバリアとして機能します。

ヒント:

シングルページアプリ (SPA) およびネイティブアプリにはアプリシークレットはありません。SPA およびネイティブアプリは「パブリッククライアント」であり、シークレットを保持できません（ブラウザコードやアプリバンドルは検査可能なため）。アプリシークレットの代わりに、Logto は PKCE、厳格なリダイレクト URI / CORS 検証、短命なアクセス トークン、リフレッシュ トークンのローテーションで保護します。

アプリケーション名​

アプリケーション名 は、人間が読めるアプリケーションの名称で、管理コンソールに表示されます。

アプリケーション名 は Logto でアプリケーションを管理する上で重要な要素であり、管理者が個々のアプリケーションのアクティビティを簡単に識別・追跡できるようにします。

注記:

アプリケーション名 は管理コンソールにアクセスできるすべてのユーザーに表示されるため、慎重に選択することが重要です。アプリケーションの目的や機能を正確に反映し、分かりやすく認識しやすい名称にしてください。

説明​

アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的や機能、その他関連情報など、管理者に追加情報を提供するためのものです。

リダイレクト URI​

リダイレクト URI は、アプリケーションに事前設定された有効なリダイレクト URI のリストです。ユーザーが Logto にサインインしてアプリケーションへアクセスしようとすると、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。

許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto へ送信される認可 (Authorization) リクエストに含まれるリダイレクト URI の検証に使用されます。認可 (Authorization) リクエストで指定されたリダイレクト 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 のいずれかにリダイレクトされます。これにより、サインアウト後にユーザーが認可 (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 は常にリフレッシュ トークンを発行します。

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

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

デフォルト: true

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

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

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

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

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

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

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

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

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

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

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

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

注記:

SPA ではセキュリティ上の理由から TTL の延長はできません。SPA ではこの設定がリフレッシュ トークンの固定有効期間を制御します。Logto はトークンリクエストによる TTL 延長を行わず、リフレッシュ トークンのローテーションも SPA のリフレッシュ トークンの有効期限切れを防ぎません。

リフレッシュ トークン TTL とグラント TTL:

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

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

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

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

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

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

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

最大許可グラント数 (maxAllowedGrants)​

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

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

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

注記:

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

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

カスタムデータ​

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