Account API によるアカウント設定

Logto Account API とは

Logto Account API は、エンドユーザーが Management API を経由せずに直接 API アクセスできる包括的な API セットです。主な特徴は以下の通りです：

• 直接アクセス：Account API により、エンドユーザーは Management API を介さずに自分のアカウントプロファイルへ直接アクセス・管理できます。
• ユーザープロファイルとアイデンティティ管理：ユーザーは自分のプロファイルやセキュリティ設定を完全に管理できます。メール、電話、パスワードなどのアイデンティティ情報の更新や、ソーシャル連携の管理が可能です。多要素認証 (MFA) やシングルサインオン (SSO) のサポートも近日追加予定です。
• グローバルアクセス制御：管理者はアクセス設定をグローバルに完全管理でき、各フィールドごとにカスタマイズ可能です。
• シームレスな認可 (Authorization)：認可 (Authorization) がこれまで以上に簡単に！client.getAccessToken() を使って OP (Logto) 用の不透明トークン (Opaque token) を取得し、Authorization ヘッダーに Bearer <access_token> として付与するだけです。

Logto Account API を使えば、Logto と完全連携したプロフィールページのようなカスタムアカウント管理システムを構築できます。

主なユースケース例：

• ユーザープロファイルの取得
• ユーザープロファイルの更新
• ユーザーパスワードの更新
• メール、電話、ソーシャル連携などのユーザーアイデンティティの更新
• MFA 要素（認証要素）の管理
• ユーザーセッションの管理
• ユーザー認可済みアプリ（グラント）の管理

利用可能な API の詳細は Logto Account API Reference および Logto Verification API Reference をご覧ください。

注記:

SSO アカウントの閲覧やアカウント削除機能は現在 Logto Management API で提供されています。実装方法は Management API によるアカウント設定 を参照してください。

Account API の有効化方法

コンソール > サインイン & アカウント > アカウントセンター に移動します。

Account API はデフォルトで無効になっており、アクセス制御もロックされています。Account API を有効化 を切り替えてオンにします。

有効化後は、直近の認証 ウィンドウ（1～120分、デフォルトは 10分）や、識別子・プロファイルデータ・サードパーティトークンアクセスごとのフィールド権限を設定できます。各フィールドは Off、ReadOnly、Edit から選択でき、デフォルトは Off です。

1. セキュリティフィールド:
   • 対象フィールド：プライマリメール、プライマリ電話、ソーシャルアイデンティティ、パスワード、パスキー、MFA、パーソナルアクセストークン。
   • 機微な操作には、ファーストパーティアプリからの直近のユーザー認証が必要です。acr が urn:logto:acr:1fa を満たし、設定した直近認証ウィンドウ内のアクセストークンが必要です（OIDC ステップアップ認証 参照）。
   • MFA 用に WebAuthn パスキーを利用する場合は、WebAuthn 関連オリジン にフロントエンドアプリのドメインを追加し、アカウントセンターとサインイン体験でパスキーを共有できるようにします。新しい WebAuthn パスキーの連携 を参照してください。
2. プロファイルフィールド:
   • 対象フィールド：ユーザー名、名前、アバター、プロファイル（その他標準プロファイル属性）、カスタムデータ。
   • これらは追加認証なしで編集可能ですが、username のみ直近のユーザー認証が必要です。
3. シークレットボールト:
   • OIDC や OAuth のソーシャル・エンタープライズコネクター用に、Logto シークレットボールト が認証後のサードパーティアクセストークン・リフレッシュトークンを安全に保存します。アプリはユーザーに再度サインインを求めずに外部 API（例：Google カレンダー同期）を呼び出せます。Account API 有効化後、自動的にトークン取得が可能になります。
4. セッション管理:
   • 有効化すると、ユーザーは自分のアクティブセッション（デバイス情報や最終サインイン時刻含む）を閲覧・管理できます。特定デバイスからのログアウト（セッションの取り消し）も可能です。
   • この Sessions フィールド権限は、ユーザー認可済みアプリ（グラント）API（閲覧・取り消し）にも適用されます。
   • セッション・グラント管理へのアクセスもセキュリティフィールドと同じ直近ユーザー認証が必要です。

Account API へのアクセス方法

注記:

アクセストークンに適切な権限があることを保証するため、Logto 設定で対応するスコープを正しく設定してください。

例えば、POST /api/my-account/primary-email API には email スコープ、POST /api/my-account/primary-phone API には phone スコープが必要です。

import { type LogtoConfig, UserScope } from '@logto/js';

const config: LogtoConfig = {
  // ...他のオプション
  // ユースケースに合った適切なスコープを追加
  scopes: [
    UserScope.Email, // `{POST,DELETE} /api/my-account/primary-email` 用
    UserScope.Phone, // `{POST,DELETE} /api/my-account/primary-phone` 用
    UserScope.CustomData, // カスタムデータ管理用
    UserScope.Address, // 住所管理用
    UserScope.Identities, // アイデンティティ・MFA 関連 API 用
    UserScope.Profile, // ユーザープロファイル管理用
    UserScope.Sessions, // ユーザーセッション・アプリグラント管理用
  ],
};

アクセストークンの取得

アプリケーションで SDK をセットアップした後、client.getAccessToken() メソッドでアクセストークンを取得できます。このトークンは Account API へのアクセスに使える不透明トークン (Opaque token) です。

公式 SDK を使わない場合は、アクセストークングラントリクエスト /oidc/token で resource を空に設定してください。

アクセストークンを使った Account API へのアクセス

Account API へリクエストする際は、HTTP ヘッダーの Authorization フィールドに Bearer 形式（Bearer YOUR_TOKEN）でアクセストークンを付与してください。

ユーザーアカウント情報を取得する例：

curl https://[tenant-id].logto.app/api/my-account \
  -H 'authorization: Bearer <access_token>'

基本的なアカウント情報の管理

ユーザーアカウント情報の取得

ユーザーデータを取得するには、GET /api/my-account エンドポイントを利用します。

curl https://[tenant-id].logto.app/api/my-account \
  -H 'authorization: Bearer <access_token>'

レスポンス例：

{
  "id": "...",
  "username": "...",
  "name": "...",
  "avatar": "..."
}

レスポンスフィールドはアカウントセンターの設定によって異なる場合があります。

基本的なアカウント情報の更新

基本的なアカウント情報には、ユーザー名、名前、アバター、カスタムデータ、その他プロファイル情報が含まれます。

username, name, avatar, customData を更新するには、PATCH /api/my-account エンドポイントを利用します。

curl -X PATCH https://[tenant-id].logto.app/api/my-account \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"username":"...","name":"...","avatar":"..."}'

その他のプロファイル情報（familyName, givenName, middleName, nickname, profile（プロフィールページ URL）, website, gender, birthdate, zoneinfo, locale, address など）を更新するには、PATCH /api/my-account/profile エンドポイントを利用します。

curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"familyName":"...","givenName":"..."}'

識別子やその他機微情報の管理

セキュリティ上の理由から、機微な Account API 操作にはファーストパーティアプリからの直近ユーザー認証が必要です：アクセストークンは acr が urn:logto:acr:1fa を満たし、auth_time がテナントの 直近の認証 ウィンドウ（デフォルト 600 秒 / 10 分、60～7,200 秒で設定可能）内である必要があります。

アクセストークンが urn:logto:acr:1fa を持たない、またはウィンドウを超えている場合、Account API は RFC 9470 の WWW-Authenticate ヘッダー付きで 401 Unauthorized を返します（error="insufficient_user_authentication"、acr_values="urn:logto:acr:1fa"、max_age="<window>"）。そのパラメータで OIDC ステップアップ認証 を開始し、新しいアクセストークンで再試行してください。

注記:

新しい メールアドレス、電話番号、ソーシャルアイデンティティ、WebAuthn パスキーの紐付けには、その新しい識別子や要素の所有証明も必要です。Verification API で検証し、リクエストボディに newIdentifierVerificationRecordId を渡してください（各セクション参照）。

ユーザーパスワードの更新

ユーザーパスワードを更新するには、POST /api/my-account/password エンドポイントを利用します。

curl -X POST https://[tenant-id].logto.app/api/my-account/password \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"password":"..."}'

ヒント:

サインアップ時と同様、Account API で設定するパスワードも コンソール > セキュリティ > パスワードポリシー で設定した パスワードポリシー に準拠する必要があります。ポリシー違反時は詳細なバリデーション結果とエラーメッセージが返されます。

新しいメールの更新・連携

注記:

この方法を利用するには メールコネクターの設定 と BindNewIdentifier テンプレートの設定が必要です。

新しいメールを更新・連携するには、まずメールの所有証明が必要です。

POST /api/verifications/verification-code エンドポイントで認証コードをリクエストします。

curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"identifier":{"type":"email","value":"..."}}'

レスポンスで verificationId を取得し、メールで認証コードを受け取ります。それを使ってメールを検証します。

curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}'

コード検証後、PATCH /api/my-account/primary-email でユーザーのメールを更新できます。リクエストボディの newIdentifierVerificationRecordId に verificationId を指定します。

curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"email":"...","newIdentifierVerificationRecordId":"<verification_record_id_from_new_email>"}'

ヒント:

サインアップ時と同様、Account API で連携するメールも コンソール > セキュリティ > ブロックリスト で設定した ブロックリスト 検証に合格する必要があります。違反時はリクエストが拒否され、詳細なエラーが返されます。

ユーザーのメール削除

ユーザーのメールを削除するには、DELETE /api/my-account/primary-email エンドポイントを利用します。

curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \
  -H 'authorization: Bearer <access_token>'

電話番号の管理

注記:

この方法を利用するには SMS コネクターの設定 と BindNewIdentifier テンプレートの設定が必要です。

メール更新と同様に、PATCH /api/my-account/primary-phone で新しい電話番号の更新・連携、DELETE /api/my-account/primary-phone でユーザーの電話番号削除が可能です。

新しいソーシャル連携の追加

新しいソーシャル連携を追加するには、まず POST /api/verifications/social で認可 URL をリクエストします。

curl -X POST https://[tenant-id].logto.app/api/verifications/social \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"connectorId":"...","redirectUri":"...","state":"..."}'

• connectorId: ソーシャルコネクター の ID
• redirectUri: ユーザー認可後のリダイレクト先。ここでコールバックを受け取るページをホストしてください。
• state: 認可後に返されるランダムな文字列。CSRF 攻撃防止用。

レスポンスで verificationRecordId を取得し、後で利用します。

ユーザーがアプリを認可すると、redirectUri で state パラメータ付きのコールバックを受け取ります。その後、POST /api/verifications/social/verify でソーシャル連携を検証します。

curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"connectorData":"...","verificationRecordId":"..."}'

connectorData はソーシャルコネクターから返されたデータです。コールバックページで redirectUri のクエリパラメータをパースし、JSON 形式で connectorData に渡します。

最後に、POST /api/my-account/identities でソーシャル連携を追加します。

curl -X POST https://[tenant-id].logto.app/api/my-account/identities \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"newIdentifierVerificationRecordId":"<verification_record_id_from_social>"}'

ソーシャル連携の削除

ソーシャル連携を削除するには、DELETE /api/my-account/identities エンドポイントを利用します。

curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connector_target_id] \
  -H 'authorization: Bearer <access_token>'

新しい WebAuthn パスキーの連携

注記:

まず MFA と WebAuthn の有効化 を行ってください。

注記:

この方法を利用するには アカウントセンター設定 で mfa フィールドを有効化してください。

ステップ 1: フロントエンドアプリのオリジンを関連オリジンに追加

WebAuthn パスキーは Relying Party ID (RP ID) という特定のホスト名に紐付きます。RP ID のオリジンでホストされているアプリのみ、そのパスキーで登録・認証できます。

フロントエンドアプリが Logto の認証ページとは異なるドメインから Account API を呼び出す場合、関連オリジン を設定してクロスオリジンのパスキー操作を許可する必要があります。

Logto の RP ID 判定方法：

• デフォルト：Logto のデフォルトドメイン https://[tenant-id].logto.app の場合、RP ID は [tenant-id].logto.app
• カスタムドメイン： カスタムドメイン 例：https://auth.example.com の場合、RP ID は auth.example.com

関連オリジンの設定方法：

PATCH /api/account-center エンドポイントでフロントエンドアプリのオリジンを追加します。例：アカウントセンターが https://account.example.com で動作している場合：

curl -X PATCH https://[tenant-id].logto.app/api/account-center \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}'

注記:

WebAuthn の関連オリジンは最大 5 つのユニークな eTLD+1 ラベルまでサポートします。eTLD+1（有効なトップレベルドメイン＋1 ラベル）は登録可能なドメイン部分です。例：

• https://example.com, https://app.example.com, https://auth.example.com は 1 ラベル（example.com）
• https://shopping.com, https://shopping.co.uk, https://shopping.co.jp も 1 ラベル（shopping）
• https://example.com と https://another.com は 2 ラベル

5 ドメインを超える場合は Related Origin Requests ドキュメントを参照してください。

ステップ 2: 新規登録オプションのリクエスト

POST /api/verifications/web-authn/registration エンドポイントで新しいパスキー登録をリクエストします。Logto では 1 アカウントにつき複数のパスキー登録が可能です。

curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

レスポンス例：

{
  "registrationOptions": "...",
  "verificationRecordId": "...",
  "expiresAt": "..."
}

ステップ 3: ローカルブラウザでパスキー登録

@simplewebauthn/browser 例：startRegistration 関数でローカルブラウザにパスキーを登録します。

import { startRegistration } from '@simplewebauthn/browser';

// ...
const response = await startRegistration({
  optionsJSON: registrationOptions, // ステップ1でサーバーから返されたデータ
});
// 後で利用するために response を保存

ステップ 4: パスキー登録の検証

POST /api/verifications/web-authn/registration/verify エンドポイントでパスキー登録を検証します。

このステップでは、認証器が生成した暗号署名を検証し、パスキーが正当に作成され、転送中に改ざんされていないことを確認します。

curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration/verify \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"payload":"...","verificationRecordId":"..."}'

• payload: ステップ2のローカルブラウザからのレスポンス
• verificationRecordId: ステップ1でサーバーから返された ID

ステップ 5: パスキーの連携

最後に、POST /api/my-account/mfa-verifications エンドポイントでパスキーをユーザーアカウントに連携します。

curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"type":"WebAuthn","newIdentifierVerificationRecordId":"..."}'

• type: MFA 要素のタイプ。現在は WebAuthn のみサポート。
• newIdentifierVerificationRecordId: ステップ1でサーバーから返された ID

既存 WebAuthn パスキーの管理

既存の WebAuthn パスキー管理には、GET /api/my-account/mfa-verifications エンドポイントで現在のパスキーや他の MFA 要素を取得します。

curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \
  -H 'authorization: Bearer <access_token>'

レスポンス例：

[
  {
    "id": "...",
    "type": "WebAuthn",
    "name": "...",
    "agent": "...",
    "createdAt": "...",
    "updatedAt": "..."
  }
]

• id: 検証の ID
• type: 検証タイプ。WebAuthn パスキーの場合は WebAuthn
• name: パスキー名（任意）
• agent: パスキーのユーザーエージェント

パスキー名の更新は PATCH /api/my-account/mfa-verifications/{verificationId}/name で行います：

curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId}/name \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"name":"..."}'

パスキーの削除は DELETE /api/my-account/mfa-verifications/{verificationId} で行います：

curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId} \
  -H 'authorization: Bearer <access_token>'

新しい TOTP の連携

注記:

まず MFA と TOTP の有効化 を行ってください。

注記:

この方法を利用するには アカウントセンター設定 で mfa フィールドを有効化してください。

ステップ 1: TOTP シークレットの生成

POST /api/my-account/mfa-verifications/totp-secret/generate エンドポイントで TOTP シークレットを生成します。

curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp-secret/generate \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

レスポンス例：

{
  "secret": "..."
}

ステップ 2: ユーザーに TOTP シークレットを表示

シークレットを使って QR コードを生成するか、直接ユーザーに表示します。ユーザーは Google Authenticator、Microsoft Authenticator、Authy などの認証アプリに追加します。

QR コードの URI 形式：

otpauth://totp/[Issuer]:[Account]?secret=[Secret]&issuer=[Issuer]

例：

otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp

ステップ 3: TOTP 要素のバインド

ユーザーが認証アプリにシークレットを追加した後、検証してアカウントにバインドします。POST /api/my-account/mfa-verifications エンドポイントを利用します。

curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"type":"Totp","secret":"..."}'

• type: Totp を指定
• secret: ステップ1で生成した TOTP シークレット

注記:

ユーザーは TOTP 要素を 1 つだけ持てます。既に TOTP 要素がある場合、追加しようとすると 422 エラーになります。

既存 TOTP の置き換え

既に TOTP 要素が設定されている場合、PUT /api/my-account/mfa-verifications/totp エンドポイントで新しいものに置き換えられます。この操作は冪等で、既存 TOTP を削除し新しいものをバインドします。

注記:

この方法を利用するには アカウントセンター設定 で mfa フィールドを有効化してください。

ステップ 1: 新しい TOTP シークレットの生成

POST /api/my-account/mfa-verifications/totp-secret/generate で新しい TOTP シークレットを生成し、新しい TOTP の連携 と同様にユーザーに表示します。

ステップ 2: TOTP 要素の置き換え

curl -X PUT https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"secret":"...","code":"..."}'

• secret: ステップ1で生成した新しい TOTP シークレット
• code: 新しいシークレットから生成した TOTP コード（バインド確認用）

バックアップコードの管理

注記:

まず MFA とバックアップコードの有効化 を行ってください。

注記:

この方法を利用するには アカウントセンター設定 で mfa フィールドを有効化してください。

ステップ 1: 新しいバックアップコードの生成

POST /api/my-account/mfa-verifications/backup-codes/generate エンドポイントで 10 個の新しいバックアップコードを生成します。

curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes/generate \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

レスポンス例：

{
  "codes": ["...", "...", "..."]
}

ステップ 2: バックアップコードをユーザーに表示

バインド前に、ユーザーに以下を案内してください：

• すぐにダウンロードまたは書き留めること
• 安全な場所に保管すること
• 各コードは一度しか使えないこと
• プライマリ MFA 手段を失った場合の最後の手段であること

コピーしやすい形式で表示し、ダウンロード（テキストファイルや PDF など）も推奨します。

ステップ 3: バックアップコードのバインド

POST /api/my-account/mfa-verifications エンドポイントでバックアップコードをバインドします。

curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"type":"BackupCode","codes":["...","...","..."]}'

• type: BackupCode を指定
• codes: 前ステップで生成したバックアップコード配列

注記:

• ユーザーは 1 セットのみバックアップコードを持てます。すべて使い切った場合は新たに生成・バインドが必要です。
• バックアップコードだけを MFA 要素にすることはできません。必ず他の MFA 要素（WebAuthn や TOTP など）も有効化してください。
• 各バックアップコードは一度しか使えません。

既存バックアップコードの閲覧

既存のバックアップコードと使用状況は GET /api/my-account/mfa-verifications/backup-codes で取得できます：

curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes \
  -H 'authorization: Bearer <access_token>'

レスポンス例：

{
  "codes": [
    {
      "code": "...",
      "usedAt": null
    },
    {
      "code": "...",
      "usedAt": "2024-01-15T10:30:00.000Z"
    }
  ]
}

• code: バックアップコード
• usedAt: 使用日時。未使用なら null

2段階認証設定の管理

注記:

これらの方法を利用するには アカウントセンター設定 で mfa フィールドを有効化してください。

エンドユーザーは自分のアカウントで 2段階認証のオン/オフを切り替えられます。例えば、MFA 要素（パスキーなど）を設定していてもサインイン時のみ使いたい場合、2段階認証を無効にするとサインイン時の MFA プロンプトをスキップしつつ MFA 要素自体は保持できます。これはユーザーごとの skipMfaOnSignIn 設定で制御します。

現在の MFA 設定の取得

GET /api/my-account/mfa-settings で現在の 2段階認証設定を取得します。

curl https://[tenant-id].logto.app/api/my-account/mfa-settings \
  -H 'authorization: Bearer <access_token>'

レスポンス例：

{
  "skipMfaOnSignIn": false
}

MFA 設定の更新

2段階認証の有効・無効を切り替えるには、PATCH /api/my-account/mfa-settings を利用します。

curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-settings \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  --data-raw '{"skipMfaOnSignIn":true}'

• skipMfaOnSignIn: true で 2段階認証を無効化、false で有効化

注記:

この設定は MFA ポリシーが オプション の場合のみ有効です。必須 または 適応型 の場合は skipMfaOnSignIn は無視され、MFA が強制されます。

ユーザーセッションの管理

アクティブセッションの一覧取得

ユーザーのアクティブセッション一覧は GET /api/my-account/sessions で取得できます。

注記:

• このエンドポイントには UserScope.Sessions スコープが必要です。
• アカウントセンター設定の Sessions フィールドは ReadOnly または Edit に設定してください。

curl https://[tenant-id].logto.app/api/my-account/sessions \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

セッション ID 指定でのセッション取り消し

特定セッションを取り消すには、DELETE /api/my-account/sessions/{sessionId} を利用します。

注記:

• このエンドポイントには UserScope.Sessions スコープが必要です。
• アカウントセンター設定の Sessions フィールドは Edit に設定してください。

curl -X DELETE https://[tenant-id].logto.app/api/my-account/sessions/{sessionId} \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

オプションのクエリパラメータ：

• revokeGrantsTarget: セッションと同時に取り消すグラントの対象を指定可能。値：
  • all: セッションに紐づくすべてのグラントを取り消し
  • firstParty: ファーストパーティアプリのグラントのみ取り消し（自社アプリのアクセスのみ無効化し、サードパーティアプリは維持。多くのケースで推奨）
  • 未指定: デフォルトは offline_access スコープを持たないグラントのみ取り消し（通常はリフレッシュトークン以外のグラント）

ユーザー認可済みアプリ（グラント）の管理

ユーザーがアカウント設定ページから認可済みアプリを確認・取り消す場合にグラント API を利用します。

注記:

• アプリグラント API はセッション API と同じ権限モデルを共有します。
• UserScope.Sessions スコープが必要です。
• アカウントセンター設定の Sessions フィールドは有効化必須：
  • ReadOnly または Edit でグラント一覧取得
  • Edit でグラント取り消し

アクティブなアプリグラント一覧の取得

現在のユーザーのアクティブなアプリグラント一覧は GET /api/my-account/grants で取得します。

curl https://[tenant-id].logto.app/api/my-account/grants \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

オプションのクエリパラメータ：

• appType=firstParty: ファーストパーティアプリのみ返す
• appType=thirdParty: サードパーティアプリのみ返す
• appType 省略: すべてのアクティブグラントを返す

curl "https://[tenant-id].logto.app/api/my-account/grants?appType=thirdParty" \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

グラント ID 指定でのアプリグラント取り消し

特定アプリグラントを取り消すには、DELETE /api/my-account/grants/{grantId} を利用します。

curl -X DELETE https://[tenant-id].logto.app/api/my-account/grants/{grantId} \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json'

グラントが取り消されると、そのグラントで発行された不透明トークン (Opaque token) やリフレッシュトークン (Refresh token) は無効化されます。