logto-io
diff --git a/‎docs/developers/signing-keys.mdx‎
Lines changed: 1 addition & 1 deletion b/‎docs/developers/signing-keys.mdx‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎docs/end-user-flows/account-settings/by-account-api.mdx‎
Lines changed: 54 additions & 1 deletion b/‎docs/end-user-flows/account-settings/by-account-api.mdx‎
Lines changed: 54 additions & 1 deletion
diff --git a/‎docs/end-user-flows/account-settings/by-management-api.mdx‎
Lines changed: 15 additions & 0 deletions b/‎docs/end-user-flows/account-settings/by-management-api.mdx‎
Lines changed: 15 additions & 0 deletions
diff --git a/‎docs/end-user-flows/sign-out.mdx‎
Lines changed: 11 additions & 145 deletions b/‎docs/end-user-flows/sign-out.mdx‎
Lines changed: 11 additions & 145 deletions
diff --git a/‎docs/integrate-logto/application-data-structure.mdx‎
Lines changed: 19 additions & 0 deletions b/‎docs/integrate-logto/application-data-structure.mdx‎
Lines changed: 19 additions & 0 deletions
@@ -7,7 +7,7 @@ sidebar_position: 5
 
 # Signing keys
 
-Logto [OIDC signing keys](https://auth.wiki/signing-key), as known as "OIDC private keys" and "OIDC cookie keys", are the signing keys used to sign JWTs ([access tokens](https://auth.wiki/access-token) and [ID tokens](https://auth.wiki/id-token)) and browser cookies in Logto [sign-in sessions](/end-user-flows/sign-out#what-is-a-logto-session). These signing keys are generated when seeding Logto database ([open-source](/logto-oss)) or creating a new tenant ([Cloud](/logto-cloud)) and can be managed through [CLI](/logto-oss/using-cli) (open-source), Management APIs or Console UI.
+Logto [OIDC signing keys](https://auth.wiki/signing-key), as known as "OIDC private keys" and "OIDC cookie keys", are the signing keys used to sign JWTs ([access tokens](https://auth.wiki/access-token) and [ID tokens](https://auth.wiki/id-token)) and browser cookies in Logto [sign-in sessions](/sessions#what-is-a-logto-session). These signing keys are generated when seeding Logto database ([open-source](/logto-oss)) or creating a new tenant ([Cloud](/logto-cloud)) and can be managed through [CLI](/logto-oss/using-cli) (open-source), Management APIs or Console UI.
 
 By default, Logto uses the elliptic curve (EC) algorithm to generate digital signatures. However, considering that users often need to verify JWT signatures and many older tools do not support the EC algorithm (only supporting RSA), we have implemented the functionality to rotate private keys and allow users to choose the signature algorithm (including both RSA and EC). This ensures compatibility with services that use outdated signature verification tools.
 
 
@@ -24,6 +24,7 @@ Some frequent use cases are listed below:
 - Update user identities including email, phone, and social connections
 - Manage MFA factors (verifications)
 - Manage user sessions
+- Manage user authorized apps (grants)
 
 To learn more about the available APIs, please visit [Logto Account API Reference](https://openapi.logto.io/group/endpoint-my-account) and [Logto Verification API Reference](https://openapi.logto.io/group/endpoint-verifications).
 
@@ -52,6 +53,7 @@ Once enabled, configure per-field permissions for identifiers, profile data, and
    - For OIDC or OAuth social and enterprise connectors, Logto [secret vault](/secret-vault/federated-token-set) securely stores third-party access and refresh tokens after authentication. Apps can then call external APIs, such as syncing Google Calendar events, without prompting users to sign in again. Token retrieval becomes available automatically once the Account API is enabled.
 4. **Session management**:
    - When enabled, users can view and manage their active sessions, including device information and last sign-in time. Users can also revoke sessions to log out from specific devices.
+   - This same `Sessions` field permission also controls user authorized apps (grants) APIs (view and revoke grants).
    - Before end users access session management, they must verify their identity via password, email, or SMS to obtain a 10-minute verification record ID. See [Get a verification record id](#get-a-verification-record-id).
 
 ## How to access Account API \{#how-to-access-account-api}
@@ -74,7 +76,7 @@ const config: LogtoConfig = {
     UserScope.Address, // To manage address
     UserScope.Identities, // For identity and MFA related APIs
     UserScope.Profile, // To manage user profile
-    UserScope.Sessions, // To manage user sessions
+    UserScope.Sessions, // To manage user sessions and app grants
   ],
 };
 ```
@@ -713,3 +715,54 @@ Optional query parameters:
   - `all`: Revoke all grants associated with the session.
   - `firstParty`: Revoke only first-party app grants associated with the session. (Recommended for most use cases, as it revokes access for your own app while keeping third-party app grants intact, providing a better user experience.)
   - unspecified: Default behavior revokes grants that does not have `offline_access` scope, which typically means revoking non-refresh-token grants for the session.
+
+### Manage user authorized apps (grants) \{#manage-user-authorized-apps-grants}
+
+Use user authorized apps (grants) APIs when users need to review and revoke authorized apps from their account settings page.
+
+:::note
+
+- App grant APIs share the same permission model as session APIs.
+- `UserScope.Sessions` scope is required.
+- `Sessions` field in account center settings must be enabled:
+  - `ReadOnly` or `Edit` to list grants.
+  - `Edit` to revoke grants.
+
+:::
+
+**List active app grants**
+
+To list active app grants of the current user, use the [`GET /api/my-account/grants`](https://openapi.logto.io/operation/operation-getgrants) endpoint.
+
+```bash
+curl https://[tenant-id].logto.app/api/my-account/grants \
+  -H 'authorization: Bearer <access_token>' \
+  -H 'logto-verification-id: <verification_record_id>' \
+  -H 'content-type: application/json'
+```
+
+Optional query parameter:
+
+- `appType=firstParty`: Return first-party app grants only.
+- `appType=thirdParty`: Return third-party app grants only.
+- Omit `appType`: Return all active grants.
+
+```bash
+curl "https://[tenant-id].logto.app/api/my-account/grants?appType=thirdParty" \
+  -H 'authorization: Bearer <access_token>' \
+  -H 'logto-verification-id: <verification_record_id>' \
+  -H 'content-type: application/json'
+```
+
+**Revoke app grant by grant ID**
+
+To revoke a specific app grant, use the [`DELETE /api/my-account/grants/{grantId}`](https://openapi.logto.io/operation/operation-deletegrantbyid) endpoint.
+
+```bash
+curl -X DELETE https://[tenant-id].logto.app/api/my-account/grants/{grantId} \
+  -H 'authorization: Bearer <access_token>' \
+  -H 'logto-verification-id: <verification_record_id>' \
+  -H 'content-type: application/json'
+```
+
+When a grant is revoked, previously issued opaque access tokens and refresh tokens for that grant are invalidated.
@@ -202,3 +202,18 @@ Personal access tokens provide a secure way for users to grant [access token](ht
 | GET    | [/api/users/\{userId\}/sessions](https://openapi.logto.io/operation/operation-listusersessions)                | Get user sessions by user ID.        |
 | GET    | [/api/users/\{userId\}/sessions/\{sessionId\}](https://openapi.logto.io/operation/operation-getusersession)    | Get a user session by session ID.    |
 | DELETE | [/api/users/\{userId\}/sessions/\{sessionId\}](https://openapi.logto.io/operation/operation-deleteusersession) | Delete a user session by session ID. |
+
+### Manage user authorized apps (grants) \{#manage-user-authorized-apps-grants}
+
+| method | path                                                                                                     | description                          |
+| ------ | -------------------------------------------------------------------------------------------------------- | ------------------------------------ |
+| GET    | [/api/users/\{userId\}/grants](https://openapi.logto.io/operation/operation-listusergrants)              | List active app grants for the user. |
+| DELETE | [/api/users/\{userId\}/grants/\{grantId\}](https://openapi.logto.io/operation/operation-deleteusergrant) | Revoke a specific app grant by ID.   |
+
+Optional query parameter for grant listing:
+
+- `appType=firstParty`: Return first-party app grants only.
+- `appType=thirdParty`: Return third-party app grants only.
+- Omit `appType`: Return all active grants.
+
+When a grant is revoked, previously issued opaque access tokens and refresh tokens for that grant are invalidated.
@@ -1,155 +1,15 @@
 ---
-sidebar_position: 8
+sidebar_position: 7.5
 ---
 
 # Sign-out
 
-Sign-out in Logto (as an OIDC identity provider) involves both:
+Sign-out in Logto involves two layers:
 
-- A **centralized Logto session** (browser cookie under Logto domain), and
-- **Distributed client-side auth state** (tokens and local app session in each app).
+- **Logto session sign-out**: Ends the centralized sign-in session under the Logto domain.
+- **App sign-out**: Clears local session state and tokens in your client application.
 
-To understand sign-out behavior, it helps to separate these two layers and then see how **grants** connect them.
-
-## Core concepts \{#core-concepts}
-
-### What is a Logto session? \{#what-is-a-logto-session}
-
-A Logto session is the centralized sign-in state managed by Logto. It is created after successful authentication and represented by cookies under the Logto domain.
-
-If the session cookie is valid, the user can be silently authenticated (SSO) across multiple apps that trust the same Logto tenant.
-
-If no valid session exists, Logto shows the sign-in page.
-
-### What are grants? \{#what-are-grants}
-
-A **grant** represents the authorization status for a specific user + client application combination.
-
-- One Logto session can have grants for multiple client apps.
-- A grant is what issued tokens are associated with.
-- In this doc set, use **grant** as the cross-app authorization unit.
-
-### How session, grants, and client auth status relate \{#how-session-grants-and-client-auth-status-relate}
-
-```mermaid
-flowchart LR
-  subgraph Logto [Logto domain]
-    S[Logto session]
-    G1[Grant for App A]
-    G2[Grant for App B]
-  end
-
-  subgraph AppA [Client domain A]
-    A[Local session / tokens]
-  end
-
-  subgraph AppB [Client domain B]
-    B[Local session / tokens]
-  end
-
-  S --> G1
-  S --> G2
-  G1 --> A
-  G2 --> B
-```
-
-- **Logto session** controls centralized SSO experience.
-- **Client local session/tokens** control whether each app currently treats user as signed in.
-- **Grants** connect these two worlds by representing app-specific authorization state.
-
-## Sign-in recap (why sign-out is multi-layered) \{#sign-in-recap-why-sign-out-is-multi-layered}
-
-```mermaid
-sequenceDiagram
-  autonumber
-  actor User
-
-  box Relying Party (RP)
-    participant Client as Client application
-  end
-
-  box Logto (IdP)
-    participant OIDC as OIDC provider
-    participant SignIn as Sign-in page
-  end
-
-  User ->> Client: Access application
-  Client ->> OIDC: Redirect for authentication
-  OIDC -->> OIDC: Check Logto session
-  OIDC ->> SignIn: Prompt sign-in if needed
-  SignIn ->> OIDC: User authenticates
-  OIDC -->> OIDC: Create session and grant
-  OIDC ->> Client: Return authorization code
-  Client ->> OIDC: Exchange code for tokens
-  OIDC -->> Client: Return tokens
-```
-
-## Session topology across apps/devices \{#session-topology-across-apps-devices}
-
-### Shared session cookie (same browser/user agent) \{#shared-session-cookie-same-browser-user-agent}
-
-If a user signs in to multiple apps from the same browser, those apps can reuse the same Logto session cookie and SSO behavior applies.
-
-```mermaid
-flowchart TD
-  U[User]
-  A["Client Application A (Client domain A)"]
-  B["Client Application B (Client domain B)"]
-  C{"Logto session exists? (Logto domain)"}
-  D["Sign-in page (Logto domain)"]
-
-  subgraph UA["User agent A (same browser)"]
-    U
-    A
-    B
-    C
-    D
-  end
-
-  U -->|Sign in| A
-  A -->|Redirect to Logto| C
-  U -->|Open app| B
-  B -->|Redirect to Logto| C
-  C -->|No| D
-  D -->|Create session| C
-```
-
-### Isolated session cookies (different devices/browsers) \{#isolated-session-cookies-different-devices-browsers}
-
-Different browsers/devices hold different Logto cookies, so sign-in session state is isolated.
-
-```mermaid
-flowchart TD
-  U[User]
-  A["Client Application A (Client domain A)"]
-  C{"Logto session exists? (Device A, Logto domain)"}
-  D["Sign-in page (Device A, Logto domain)"]
-
-  subgraph DeviceA["User agent A"]
-    A
-    C
-    D
-  end
-
-  B["Client Application B (Client domain B)"]
-  E{"Logto session exists? (Device B, Logto domain)"}
-  F["Sign-in page (Device B, Logto domain)"]
-
-  subgraph DeviceB["User agent B"]
-    B
-    E
-    F
-  end
-
-  U -->|Sign in| A
-  A -->|Redirect to Logto| C
-  U -->|Sign in| B
-  B -->|Redirect to Logto| E
-  C -->|No| D
-  E -->|No| F
-  D -->|Create session| C
-  F -->|Create session| E
-```
+To better understand how sessions work in Logto, see [Sessions](/sessions).
 
 ## Sign-out mechanisms \{#sign-out-mechanisms}
 
@@ -174,6 +34,12 @@ In current Logto SDK behavior:
 
 As a result, current SDK sign-out is treated as **global sign-out**.
 
+:::note
+
+- **Global sign-out**: Revoke the centralized Logto session.
+
+:::
+
 ### What happens during global sign-out \{#what-happens-during-global-sign-out}
 
 ```mermaid
 
@@ -179,6 +179,25 @@ To ensure the refresh token TTL setting takes full effect, make sure to include
 
 The OpenID Connect backchannel logout endpoint. See [Federated sign-out: Back-channel logout](#) for more information.
 
+### Max allowed grants (`maxAllowedGrants`) \{#max-allowed-grants-maxallowedgrants}
+
+`maxAllowedGrants` is an optional app-level field under `customClientMetadata` that controls the maximum number of concurrent active grants per user for the current app.
+
+- **Default**: `undefined` (no limit)
+- **When configured**: On each successful authorization, Logto checks the total active grants for the user in the current app (across browsers and devices). If the limit is exceeded, Logto revokes the oldest grants.
+
+This setting is useful when you want to cap concurrent authenticated devices per app.
+
+:::note
+
+This field is not supported for:
+
+- Machine-to-machine apps
+- Protected apps
+- SAML apps
+
+:::
+
 ### Custom data \{#custom-data}
 
 Additional custom application info not listed in the pre-defined application properties, users can define their own custom data fields according to their specific needs, such as business-specific settings and configurations.