アプリケーションデータ構造
はじめに
Logto における アプリケーション とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代理でのアクションを実行する権限を付与された特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API に対するリクエストの発信元を識別し、これらのアプリケーションにアクセスするユーザーの認証 (Authentication) と認可 (Authorization) プロセスを管理するために使用されます。
Logto のサインイン体験におけるアプリケーションの使用により、ユーザーは一元的な場所から簡単に認可 (Authorization) されたアプリケーションにアクセスし管理することができ、一貫性のある安全な認証 (Authentication) プロセスを提供します。これにより、ユーザー体験がスムーズになり、組織の代理で機密情報にアクセスしたりアクションを実行したりするのが認可 (Authorization) された個人だけであることが保証されます。
アプリケーションはまた、Logto の監査ログでユーザーの活動を追跡し、潜在的なセキュリティ脅威や侵害を特定するためにも使用されます。特定のアクションを特定のアプリケーションに関連付けることで、Logto はデータがどのようにアクセスされ使用されているかについての詳細な洞察を提供し、組織がセキュリティとコンプライアンス要件をより適切に管理できるようにします。 アプリケーションを Logto と統合したい場合は、Logto を統合する を参照してください。
プロパティ
アプリケーション ID
アプリケーション ID は、Logto 内でアプリケーションを識別するための一意の自動生成キーであり、OAuth 2.0 では client id として参照されます。
アプリケーションタイプ
アプリケーション は次のいずれかのアプリケーションタイプであることができます：
- ネイティブアプリ はネイティブ環境で実行されるアプリです。例：iOS アプリ、Android アプリ。
- シングルページアプリ は、ウェブブラウザで実行され、サーバーからの新しいデータでページを更新するアプリです。例：React DOM アプリ、Vue アプリ。
- 従来のウェブアプリ は、ウェブサーバーによってページをレンダリングおよび更新するアプリです。例：JSP、PHP。
- マシン間通信 (M2M) アプリ は、ユーザーの操作なしに直接サービス間通信を行うためのマシン環境で実行されるアプリケーションです。
アプリケーションシークレット
アプリケーションシークレット は、認証 (Authentication) システム内でアプリケーションを認証 (Authentication) するために使用されるキーであり、特にプライベートクライアント（従来のウェブアプリおよび M2M アプリ）に対するプライベートセキュリティバリアとして機能します。
アプリケーション名
アプリケーション名 は、人間が読みやすいアプリケーションの名前であり、管理コンソールに表示されます。
アプリケーション名 は、Logto でアプリケーションを管理する際の重要な要素であり、管理者がプラットフォーム内の個々のアプリケーションの活動を簡単に識別し追跡できるようにします。
アプリケーション名 は管理コンソールにアクセスできるすべてのユーザーに表示されるため、慎重に選択することが重要です。アプリケーションの目的と機能を正確に反映し、理解しやすく認識しやすいものであるべきです。
説明
アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的、機能、およびその他の関連する詳細情報を管理者に提供することを目的としています。
リダイレクト URI
リダイレクト URI は、アプリケーションに対して事前に設定された有効なリダイレクト URI のリストです。ユーザーが Logto にサインインし、アプリケーションにアクセスしようとすると、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。
許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto に送信される認可 (Authorization) リクエストに含まれるリダイレクト URI を検証するために使用されます。認可 (Authorization) リクエストで指定されたリダイレクト URI がアプリケーション設定の許可された URI のいずれかと一致する場合、ユーザーは認証 (Authentication) に成功した後、その URI にリダイレクトされます。リダイレクト URI が許可リストにない場合、ユーザーはリダイレクトされず、認証 (Authentication) プロセスは失敗します。
すべての有効なリダイレクト URI が Logto のアプリケーションに対して許可リストに追加されていることを確認することが重要です。これにより、ユーザーが認証 (Authentication) 後にアプリケーションに正常にアクセスできるようになります。
リダイレクションエンドポイント についての詳細情報を確認できます。
認可コードフローでの OIDC におけるリダイレクト URI の理解
サインアウト後のリダイレクト URI
サインアウト後のリダイレクト URI は、Logto からサインアウトした後にユーザーをリダイレクトするためにアプリケーションに対して事前に設定された有効な URI のリストです。
ログアウトのための許可された サインアウト後のリダイレクト URI の使用は、OIDC の RP-Initiated (Relying Party Initiated) ログアウト仕様の一部です。この仕様は、ユーザーのログアウトリクエストをアプリケーションが開始するための標準化された方法を提供し、ユーザーがサインアウトした後に事前に設定されたエンドポイントにリダイレクトすることを含みます。
ユーザーが 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) エンドポイント についての詳細情報を確認できます。
トークンエンドポイント
トークンエンドポイント は OIDC 用語であり、OIDC クライアントが OIDC プロバイダーからアクセス トークン、ID トークン、またはリフレッシュ トークンを取得するために使用される Web API エンドポイントです。
OIDC クライアントがアクセス トークンまたは ID トークンを取得する必要がある場合、通常は認可 (Authorization) コードまたはリフレッシュ トークンである認可 (Authorization) グラントを使用してトークンエンドポイントにリクエストを送信します。トークンエンドポイントは認可 (Authorization) グラントを検証し、グラントが有効であればクライアントにアクセス トークンまたは ID トークンを発行します。
トークンエンドポイント についての詳細情報を確認できます。
ユーザー情報エンドポイント
OpenID Connect ユーザー情報エンドポイント。
常にリフレッシュ トークンを発行する
利用可能性: 従来の Web、SPA
有効にすると、Logto は認証 (Authentication) リクエストに prompt=consent が提示されているかどうか、またはスコープに offline_access が提示されているかどうかに関係なく、常にリフレッシュ トークンを発行します。
ただし、この方法は OpenID Connect と互換性がなく、問題を引き起こす可能性があるため、必要でない限り（通常、リフレッシュ トークンを必要とする一部のサードパーティ OAuth 統合に役立ちます）、推奨されません。
リフレッシュ トークンをローテーションする
デフォルト: true
有効にすると、Logto は次の条件下でトークンリクエストに対して新しいリフレッシュ トークンを発行します：
- リフレッシュ トークンが 1 年間ローテーションされている場合（新しいトークンを発行して TTL が延長されている場合）；または
- リフレッシュ トークンが有効期限に近い場合（元の Time to Live (TTL) の >=70% が経過した場合）；または
- クライアントがパブリッククライアントである場合、例：ネイティブアプリケーションまたはシングルページアプリケーション (SPA)。
パブリッククライアントの場合、この機能が有効になっていると、クライアントがリフレッシュ トークンを使用して新しいアクセス トークンを交換するたびに、新しいリフレッシュ トークンが常に発行されます。 これらのパブリッククライアントに対しても機能をオフにすることはできますが、セキュリティ上の理由から有効にしておくことを強くお勧めします。
リフレッシュ トークンのローテーションの理解
リフレッシュ トークンの有効期間 (TTL) （日単位）
利用可能性: SPA ではない; デフォルト: 14 日
リフレッシュ トークンが有効期限を迎えて無効になる前に、新しいアクセス トークンを要求するために使用できる期間。トークンリクエストは、リフレッシュ トークンの TTL をこの値に延長します。
通常、より低い値が好まれます。
注意: セキュリティ上の理由から、SPA（シングルページアプリケーション）では TTL の更新は利用できません。これは、Logto がトークンリクエストを通じて TTL を延長しないことを意味します。ユーザー体験を向上させるために、「リフレッシュ トークンをローテーションする」機能を有効にして、必要に応じて Logto が新しいリフレッシュ トークンを発行できるようにすることができます。
バックチャネルログアウト URI
OpenID Connect バックチャネルログアウトエンドポイント。フェデレーテッドサインアウト: バックチャネルログアウト についての詳細情報を確認できます。
カスタムデータ
事前定義されたアプリケーションプロパティにリストされていない追加のカスタムアプリケーション情報。ユーザーは、ビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。