fix: fix anchors

simeng-li · simeng-li · commit 49d2c0c1e239 · 2026-03-06T15:52:57.000+08:00
fix anchors
diff --git a/docs/developers/signing-keys.mdx b/docs/developers/signing-keys.mdx
@@ -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#sign-in-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](/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.
 
 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.
 
diff --git a/docs/end-user-flows/README.mdx b/docs/end-user-flows/README.mdx
@@ -21,7 +21,7 @@ End-user flows cover all verification processes for user interactions, categoriz
 | [Magic link (One-time token)](/end-user-flows/one-time-token)          | <ul><li>Organization member invitation</li><li>User invitation when registration is disabled</li><li>Sign in or sign up using magic link</li></ul>                                                                                                                                                                                                                                                                                                                                                                                    |
 | Authorize third-party apps                                             | <ul><li>[Consent screen for OIDC / OAuth apps](/end-user-flows/consent-screen)</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | Collect user profile                                                   | <ul><li>[Collect additional user data during sign-up](/end-user-flows/collect-user-profile)</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| [Sign-out](/end-user-flows/sign-out)                                   | <ul><li>[Clear tokens and local session at the client side](/end-user-flows/sign-out/#clear-tokens-and-local-session-at-the-client-side)</li><li>[Clear sign-in session at Logto](/end-user-flows/sign-out/#clear-sign-in-session-at-logto)</li><li>[Federated sign-out: Back-channel logout](/end-user-flows/sign-out/#federated-sign-out-back-channel-logout)</li></ul>                                                                                                                                                             |
+| [Sign-out](/end-user-flows/sign-out)                                   | <ul><li>[Clear tokens and local session at the client side](/end-user-flows/sign-out/#1-client-side-only-sign-out)</li><li>[Clear sign-in session at Logto](/end-user-flows/sign-out/#2-end-session-at-logto-global-sign-out-in-current-logto-implementation)</li><li>[Federated sign-out: Back-channel logout](/end-user-flows/sign-out/#federated-sign-out-back-channel-logout)</li></ul>                                                                                                                                           |
 
 This section introduces Logto’s pre-built UI for a streamlined sign-in experience, helping you accelerate time-to-market. For more flexibility in customizing your sign-in UI, try the “[Bring Your UI](/customization/bring-your-ui)” feature with Logto Experience APIs.
 
diff --git a/docs/end-user-flows/account-settings/by-account-api.mdx b/docs/end-user-flows/account-settings/by-account-api.mdx
@@ -670,7 +670,7 @@ The response body would be like:
 - `code`: the backup code.
 - `usedAt`: the timestamp when the code was used, `null` if not used yet.
 
-### Manage user sessions
+### Manage user sessions \{#manage-user-sessions}
 
 **List active sessions**
 
diff --git a/docs/end-user-flows/sign-out.mdx b/docs/end-user-flows/sign-out.mdx
@@ -11,25 +11,25 @@ Sign-out in Logto (as an OIDC identity provider) involves both:
 
 To understand sign-out behavior, it helps to separate these two layers and then see how **grants** connect them.
 
-## Core concepts
+## Core concepts \{#core-concepts}
 
-### What is a Logto session?
+### 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? \{#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 \{#how-session-grants-and-client-auth-status-relate}
 
 ```mermaid
 flowchart LR
@@ -57,7 +57,7 @@ flowchart LR
 - **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) \{#sign-in-recap-why-sign-out-is-multi-layered}
 
 ```mermaid
 sequenceDiagram
@@ -84,9 +84,9 @@ sequenceDiagram
   OIDC -->> Client: Return tokens
 ```
 
-## Session topology across apps/devices
+## Session topology across apps/devices \{#session-topology-across-apps-devices}
 
-### Shared session cookie (same browser/user agent)
+### 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.
 
@@ -114,7 +114,7 @@ flowchart TD
   D -->|Create session| C
 ```
 
-### Isolated session cookies (different devices/browsers)
+### 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.
 
@@ -151,16 +151,16 @@ flowchart TD
   F -->|Create session| E
 ```
 
-## Sign-out mechanisms
+## Sign-out mechanisms \{#sign-out-mechanisms}
 
-### 1) Client-side-only sign-out
+### 1) Client-side-only sign-out \{#1-client-side-only-sign-out}
 
 Client app clears its own local session and tokens (ID/access/refresh tokens). This signs user out from that app's local state only.
 
 - Logto session may still be active.
 - Other apps under same Logto session may still SSO.
 
-### 2) End-session at Logto (global sign-out in current Logto implementation)
+### 2) End-session at Logto (global sign-out in current Logto implementation) \{#2-end-session-at-logto-global-sign-out-in-current-logto-implementation}
 
 To clear centralized Logto session, app redirects user to the end session endpoint, for example:
 
@@ -174,7 +174,7 @@ In current Logto SDK behavior:
 
 As a result, current SDK sign-out is treated as **global sign-out**.
 
-### What happens during global sign-out
+### What happens during global sign-out \{#what-happens-during-global-sign-out}
 
 ```mermaid
 flowchart TD
@@ -194,13 +194,13 @@ During global sign-out:
   - If `offline_access` **is** granted, grants are not revoked by end-session.
 - For `offline_access` cases, refresh tokens and grants remain valid until grant expiration.
 
-## Grant lifetime and `offline_access` impact
+## Grant lifetime and `offline_access` impact \{#grant-lifetime-and-offline-access-impact}
 
 - Default Logto grant TTL is **180 days**.
 - If `offline_access` is granted, end-session does not revoke that app grant by default.
 - Refresh token chain associated with that grant can continue until the grant expires (or is explicitly revoked).
 
-## Federated sign-out: back-channel logout
+## Federated sign-out: back-channel logout \{#federated-sign-out-back-channel-logout}
 
 For cross-app consistency, Logto supports [back-channel logout](https://openid.net/specs/openid-connect-backchannel-1_0-final.html).
 
@@ -214,7 +214,7 @@ Typical flow:
 2. Logto processes end-session and sends logout token(s) to registered back-channel logout URI(s).
 3. Each app validates logout token and clears its own local session/tokens.
 
-## Sign-out methods in Logto SDKs
+## Sign-out methods in Logto SDKs \{#sign-out-methods-in-logto-sdks}
 
 - **SPA and web**: `client.signOut()` clears local token storage and redirects to Logto end-session endpoint. You may provide a post-logout redirect URI.
 - **Native (including React Native / Flutter)**: usually clears local token storage only. Sessionless webview means no persistent Logto browser cookie to clear.
@@ -223,7 +223,7 @@ Typical flow:
 For native applications that does not support sessionless webview or does not recognize the `emphasized` settings(Android app using **React Native** or **Flutter** SDK), you may force the user prompt to sign in again by passing the `prompt=login` parameter in the authorization request.
 :::
 
-## Enforce re-authentication on every access
+## Enforce re-authentication on every access \{#enforce-re-authentication-on-every-access}
 
 For high-security actions, include `prompt=login` in auth requests to bypass SSO and force credential entry each time.
 
@@ -235,12 +235,12 @@ Typical combined setting:
 prompt=login consent
 ```
 
-## FAQs
+## FAQs \{#faqs}
 
 <details>
   <summary>
 
-### I'm not receiving the back-channel logout notifications.
+### I'm not receiving the back-channel logout notifications. \{#im-not-receiving-the-back-channel-logout-notifications}
 
 </summary>
 
@@ -249,7 +249,7 @@ prompt=login consent
 
 </details>
 
-## Related resources
+## Related resources \{#related-resources}
 
 <Url href="https://blog.logto.io/oidc-back-channel-logout/">
   Understanding OIDC back-channel logout.
diff --git a/docs/quick-starts/fragments/_scope-claim-list.md b/docs/quick-starts/fragments/_scope-claim-list.md
@@ -1,6 +1,6 @@
 Here's the list of supported scopes and the corresponding claims:
 
-### Standard OIDC scopes
+### Standard OIDC scopes {#standard-oidc-scopes}
 
 **`openid`** (default)
 
@@ -46,7 +46,7 @@ Please refer to the [OpenID Connect Core 1.0](https://openid.net/specs/openid-co
 Scopes marked with **(default)** are always requested by the Logto SDK. Claims under standard OIDC scopes are always included in the ID token when the corresponding scope is requested — they cannot be turned off.
 :::
 
-### Extended scopes
+### Extended scopes {#extended-scopes}
 
 The following scopes are extended by Logto and will return claims through the [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). These claims can also be configured to be included directly in the ID token through <CloudLink to="/customize-jwt">Console > Custom JWT</CloudLink>. See [Custom ID token](/developers/custom-id-token) for more details.
 
diff --git a/docs/user-management/manage-users.mdx b/docs/user-management/manage-users.mdx
@@ -89,7 +89,7 @@ After you reset the password, copy and send it to the end-user. Once the "Reset
 
 You cannot set a specific password for users in the Logto Console, but you can use the [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` to specify a password.
 
-### Manage user active sessions
+### Manage user active sessions \{#manage-user-active-sessions}
 
 On the "User details" page, navigate to the "Session details" page by clicking on the "Manage" button of a specific session. Here you can view detailed information about the session, such as the device, location, and login time. If you want to log out the user from this session, simply click the "Revoke session" button at the right top corner, and the session will be immediately revoked.
 
