日本語
Logto製品アップデート（2024年8月）
ユーザーの偽装、アプリケーションシークレット管理、組織およびアプリケーションレベルのサインイン体験のブランディングなど、多くの機能が含まれた2024年8月のリリースをご覧ください。
Simeng
Developer
Developer
ユーザーの偽装、アプリケーションシークレット管理、組織およびアプリケーションレベルのサインイン体験のブランディングなど、多くの機能が含まれた2024年8月のリリースをご覧ください。
トークン交換によるユーザーの偽装をサポートしました:
subject_token をリクエストするための新しいManagement APIエンドポイント POST /subject-tokens を追加しました。subject_token をユーザー偽装された access_token に交換するために、新しいグラントタイプ urn:ietf:params:oauth:grant-type:token-exchange を導入したOIDCエンドポイント POST /oidc/token を更新しました。詳細はユーザー偽装をご覧ください。
custom_dataアプリケーションに任意のオブジェクトフィールド custom_data を追加しました。このフィールドには、標準の Application スキーマで定義されていない追加情報を保存できます。
custom_data フィールドをパッチ更新するための新しいエンドポイント PATCH /api/applications/{applicationId}/custom-data を追加しました。PATCH /api/applications/{applicationId} エンドポイントを更新し、 custom_data フィールドを上書きできるようにしました。保護されたアプリケーションを除く、アプリケーションの詳細ページに新しいカスタムデータJSONエディターを追加しました。
今後、セキュアなアプリケーション（マシン間、従来のWeb、保護されたアプリケーション）は、有効期限付きの複数のアプリシークレットを持つことができます。これにより、シークレットのローテーションが可能となり、さらに安全な体験が提供されます。
注意: この機能が追加される前に作成されたレガシーシークレットは、クライアント認証に引き続き使用できます。ただし、セキュリティを強化するために古いシークレットを削除して、有効期限付きの新しいシークレットを作成することをお勧めします。
GET /api/applications/{applicationId}/secrets: アプリケーションのすべてのシークレットを一覧表示します。POST /api/applications/{applicationId}/secrets: アプリケーションの新しいシークレットを作成します。DELETE /api/applications/{applicationId}/secrets/{name}: 名前でアプリケーションのシークレットを削除します。PATCH /api/applications/{applicationId}/secrets/{name}: 名前でアプリケーションのシークレットを更新します。DELETE /api/applications/{applicationId}/legacy-secret: アプリケーションのレガシーシークレットを削除し、新しいシークレットと置換します。アプリケーションシークレットを管理するには、Logtoコンソール -> アプリケーション -> アプリケーション詳細 -> エンドポイント & 資格情報に移動します。
元のアプリシークレットの読み取り専用入力フィールドは、新しいシークレット管理テーブルに置き換えられました。このテーブルでシークレットの作成、更新、削除が可能です。
今後、組織のライトロゴおよびダークロゴを設定できるようになります。ロゴのアップロードは組織設定ページから行えます。
また、組織からサインイン体験のロゴを上書きすることもできます。認証リクエストに organization_id パラメーターを追加するだけです。ほとんどのLogto SDKでは、この操作は signIn メソッドの extraParams フィールドを使用して行えます。
例えば、JavaScript SDKでは以下のように行えます:
<organization-id> の値は、組織設定ページで確認できます。
使用しているSDKに extraParams フィールドが見つからない場合は、お知らせください。
今後、アプリのロゴ、ファビコン、カラーを設定できるようになります。これらの設定は、アプリが認証フローを開始したときに、サインイン体験に使用されます。ブランディング設定がないアプリに対しては、オムニサインイン体験のブランディングが使用されます。
認証リクエストで organization_id が指定されている場合、利用可能な場合はアプリレベルのブランディング設定は組織のブランディング設定で上書きされます。
Logtoは、サインイン体験の設定とフレーズを index.html ファイルに注入することで、初回の画面表示のパフォーマンスを向上させました。以下の場合、エクスペリエンスアプリは設定とフレーズを引き続きサーバーから取得します:
tsup を使用します。これによりビルドプロセスが速くなり、パッケージの機能には影響しません。@logto/console、@logto/demo-app、@logto/experience パッケージのトランスパイルとバンドルに Vite を使用します。ParcelJSを削除し、Viteに置き換えました。破壊的な変更は期待されていません。PATCH /api/applications/{applicationId} エンドポイントにおけるjsonb更新動作の修正Application オブジェクトのすべてのjsonbフィールドは、merge モードではなく replace モードで更新されるべきです。この変更により、PATCH メソッドはより予測可能で、一貫したRESTful API設計と一致します。
PATCH /api/applications/{applicationId} エンドポイントにおけるjsonbフィールドの更新モードを merge から replace に変更しました。PATCH /api/applications/{applicationId} エンドポイントにおけるAPIのjsonbフィールド入力パラメーターの検証を partial から full に変更しました。oidc_client_metadata、custom_client_metadata、protected_app_metadata および custom_data。注意: Logtoコンソールを使用して
Application設定を更新している場合、この変更の影響を受けることはありません。APIユーザーで、PATCHメソッドを使用してApplicationのjsonbフィールド設定を更新している場合は、この変更に注意する必要があります。PATCHメソッドは、今後jsonbフィールド全体を新しい入力データで置き換えます。影響を受けるフィールドに対する部分的な入力データは拒否されます。
影響を受けるWebhookイベント: Role.Scopes.Updated、Organizations.Membership.Updates。
Webhookイベントペイロードから返されたAPI応答ステータスコードは常に404でした。これは、Webhookイベントペイロードを挿入する前にAPI応答コンテキストが設定されていたためです。
イベントが正常に処理された場合のみWebhookがトリガーされるため、ステータスコードは常に2xxであるべきです。
この問題は、Webhookイベントペイロード挿入をAPI応答コンテキストの設定後に移動することで修正されました。
Argon2d および Argon2id。これらのアルゴリズムを持つユーザーは、正常なサインイン後に Argon2i に移行されます。@logto/experience のブラウザーリスト構成が README.md に記載されている内容と同期されました。