-Kurz gesagt, wenn du eine Berechtigung anforderst, erhältst du die entsprechenden Ansprüche in den Benutzerinformationen. Zum Beispiel, wenn du die `email` Berechtigung anforderst, erhältst du die `email` und `email_verified` Daten des Benutzers. +Kurz gesagt: Wenn du eine Berechtigung (Scope) anforderst, erhältst du die entsprechenden Ansprüche (Claims) in den Benutzerinformationen. Zum Beispiel: Wenn du die Berechtigung `email` anforderst, erhältst du die Daten `email` und `email_verified` des Benutzers.
- Standardmäßig fordert das Logto SDK immer drei Berechtigungen an: `openid`, `profile` und - `offline_access`, und es gibt keine Möglichkeit, diese Standardberechtigungen zu entfernen. Aber - du kannst weitere Berechtigungen hinzufügen, wenn du Logto konfigurierst: + Standardmäßig fordert das Logto SDK immer drei Berechtigungen (Scopes) an: `openid`, `profile` und + `offline_access`. Es gibt keine Möglichkeit, diese Standardberechtigungen zu entfernen. Du kannst + jedoch beim Konfigurieren von Logto weitere Berechtigungen hinzufügen:
{props.configScopesCode} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/developers/README.mdx index 20b290c1fa8..94804161033 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -1,8 +1,8 @@ # Desarrollador -Logto es un servicio de [gestión de identidad y acceso (IAM)](https://auth.wiki/iam) basado en los protocolos [OAuth 2](https://auth.wiki/oauth-2.0) y [OIDC](https://auth.wiki/openid-connect). Los servicios IAM como Logto suelen servir como la base para otros servicios web; varios estados de autorización dentro de esos servicios web se ven directamente afectados por Logto. +Logto es un servicio de [gestión de identidad y acceso (IAM)](https://auth.wiki/iam) basado en los protocolos [OAuth 2](https://auth.wiki/oauth-2.0) y [OIDC](https://auth.wiki/openid-connect). Los servicios IAM como Logto suelen servir como base para otros servicios web; varios estados de autorización dentro de esos servicios web se ven directamente afectados por Logto. -Para brindar comodidad a nuestros usuarios, Logto ofrece una serie de funciones comunes para desarrolladores. +Para brindar comodidad a nuestros usuarios, Logto ofrece una serie de funciones de uso común para desarrolladores. ## Relacionadas con la experiencia de inicio de sesión \{#sign-in-experience-related} @@ -19,18 +19,27 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: 'Reclamos personalizados de token', + label: 'Token de acceso personalizado', href: '/developers/custom-token-claims', - description: 'Expande las capacidades del control de acceso adjuntando reclamos adicionales (claims), lo que puede ayudar a lograr ABAC o rechazar la emisión de tokens.', + description: 'Utiliza scripts personalizados para adjuntar reclamos adicionales a los tokens de acceso (Access tokens), habilitando ABAC o rechazando la emisión del token.', customProps: { icon:
B{Alcances solicitados}
+ B --> C[Alcances estándar de OIDC]
+ B --> D[Alcances extendidos]
+ C --> E[Reclamos estándar incluidos en el token de ID]
+ D --> F{¿Interruptor habilitado en la consola?}
+ F -->|Sí| G[Reclamos extendidos incluidos en el token de ID]
+ F -->|No| H[Reclamos no incluidos]
+```
+
+## Reclamos estándar de OIDC \{#standard-oidc-claims}
+
+Los reclamos estándar están completamente gobernados por la especificación OIDC. Su inclusión en el token de ID depende únicamente de los alcances que tu aplicación solicite durante la autenticación. Logto no proporciona ninguna opción para deshabilitar o excluir selectivamente reclamos estándar individuales.
+
+La siguiente tabla muestra la relación entre los alcances estándar y sus reclamos correspondientes:
+
+| Alcance | Reclamos |
+| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `openid` | `sub` |
+| `profile` | `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, `updated_at` |
+| `email` | `email`, `email_verified` |
+| `phone` | `phone_number`, `phone_number_verified` |
+| `address` | `address` |
+
+Por ejemplo, si tu aplicación solicita los alcances `openid profile email`, el token de ID incluirá todos los reclamos de los alcances `openid`, `profile` y `email`.
+
+## Reclamos extendidos \{#extended-claims}
+
+Más allá de los reclamos estándar de OIDC, Logto extiende reclamos adicionales que transportan información de identidad específica del ecosistema Logto. Estos reclamos extendidos siguen un **modelo de doble condición** para ser incluidos en el token de ID:
+
+1. **Condición de alcance**: La aplicación debe solicitar el alcance correspondiente durante la autenticación.
+2. **Interruptor en la consola**: El administrador debe habilitar la inclusión del reclamo en el token de ID a través de Logto Console.
+
+Ambas condiciones deben cumplirse simultáneamente. El alcance sirve como declaración de acceso a nivel de protocolo, mientras que el interruptor sirve como control de exposición a nivel de producto: sus responsabilidades son claras y no sustituibles.
+
+### Alcances y reclamos extendidos disponibles \{#available-extended-scopes-and-claims}
+
+| Alcance | Reclamos | Descripción | Incluido por defecto |
+| ------------------------------------ | ------------------------------ | -------------------------------------------------------- | -------------------- |
+| `custom_data` | `custom_data` | Datos personalizados almacenados en el objeto de usuario | |
+| `identities` | `identities`, `sso_identities` | Identidades sociales y SSO vinculadas del usuario | |
+| `roles` | `roles` | Roles asignados al usuario | ✅ |
+| `urn:logto:scope:organizations` | `organizations` | IDs de las organizaciones del usuario | ✅ |
+| `urn:logto:scope:organizations` | `organization_data` | Datos de la organización del usuario | |
+| `urn:logto:scope:organization_roles` | `organization_roles` | Asignaciones de roles de organización del usuario | ✅ |
+
+### Configuración en Logto Console \{#configure-in-logto-console}
+
+Para habilitar reclamos extendidos en el token de ID:
+
+1. Ve a 
{
@@ -49,7 +49,7 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
Este editor utiliza el servidor de lenguaje JavaScript para proporcionar resaltado de sintaxis básico, autocompletado de código y verificación de errores. El parámetro de entrada está bien tipado y documentado en estilo jsDoc. Puedes usar IntelliSense del editor para acceder correctamente a las propiedades del objeto de entrada. Puedes encontrar las definiciones detalladas de los parámetros en el lado derecho de la página.
:::note
-Esta función se exportará como un módulo. Asegúrate de mantener el nombre de la función como `getCustomJwtClaims` para que el módulo pueda exportar la función correctamente.
+Esta función será exportada como un módulo. Asegúrate de mantener el nombre de la función como `getCustomJwtClaims` para que el módulo pueda exportar la función correctamente.
:::
## Paso 2: Parámetros de entrada \{#step-2-input-parameters}
@@ -66,10 +66,10 @@ Puedes encontrar la definición de tipo detallada del objeto de carga útil del
| Propiedad | Descripción | Tipo |
| -------------------- | ------------------------------------------------ | ------------- |
| `jti` | El identificador único del JWT | `string` |
- | `aud` | La audiencia (Audience) del token | `string` |
- | `scope` | Los alcances (Scopes) del token | `string` |
+ | `aud` | La audiencia del token | `string` |
+ | `scope` | Los alcances del token | `string` |
| `clientId` | El id del cliente del token | `string` |
- | `accountId` | El id de usuario del token | `string` |
+ | `accountId` | El id del usuario del token | `string` |
| `expiresWithSession` | Si el token expirará con la sesión | `boolean` |
| `grantId` | El id de concesión de autenticación actual del token | `string` |
| `gty` | El tipo de concesión del token | `string` |
@@ -78,21 +78,21 @@ Puedes encontrar la definición de tipo detallada del objeto de carga útil del
| Propiedad | Descripción | Tipo |
| ---------- | -------------------------- | ------------------- |
| `jti` | El identificador único del JWT | `string` |
- | `aud` | La audiencia (Audience) del token | `string` |
- | `scope` | Los alcances (Scopes) del token | `string` |
+ | `aud` | La audiencia del token | `string` |
+ | `scope` | Los alcances del token | `string` |
| `clientId` | El id del cliente del token | `string` |
| `kind` | El tipo de token | `ClientCredentials` |
### context (Solo disponible para token de acceso de usuario) \{#context-only-available-for-user-access-token}
-El objeto de contexto contiene los datos del usuario y los datos de la concesión relevantes para el proceso de autorización (Authorization) actual.
+El objeto de contexto contiene los datos del usuario y los datos de la concesión relevantes para el proceso actual de autorización (Authorization).
- **Objeto de datos de usuario**
- Para el token de acceso de usuario, Logto proporciona un contexto adicional de datos de usuario para que puedas acceder. El objeto de datos de usuario contiene todos los datos del perfil del usuario y los datos de membresía de organización (Organization) que puedas necesitar para configurar los reclamos personalizados. Consulta [Usuarios](/user-management/user-data) y [Organizaciones](/organizations/organization-management#organization-data-structure) para más detalles.
+ Para el token de acceso de usuario, Logto proporciona un contexto adicional de datos de usuario para que puedas acceder. El objeto de datos de usuario contiene todos los datos del perfil de usuario y datos de membresía de organización que puedas necesitar para configurar los reclamos personalizados. Consulta [Usuarios](/user-management/user-data) y [Organizaciones](/organizations/organization-management#organization-data-structure) para más detalles.
- **Objeto de datos de concesión**
Para el token de acceso de usuario concedido por intercambio de token de suplantación, Logto proporciona un contexto adicional de datos de concesión para que puedas acceder. El objeto de datos de concesión contiene el contexto personalizado del token de sujeto. Consulta [Suplantación de usuario](/developers/user-impersonation) para más detalles.
- **Objeto de datos de interacción de usuario**
- Para un token de acceso de usuario dado, puede haber casos en los que necesites acceder a los detalles de interacción del usuario para la sesión de autorización (Authorization) actual. Por ejemplo, podrías necesitar recuperar la identidad de SSO empresarial utilizada por el usuario para iniciar sesión. Este objeto de datos de interacción de usuario contiene los datos de interacción más recientes enviados por el usuario, incluyendo:
+ Para un token de acceso de usuario dado, puede haber instancias donde necesites acceder a los detalles de interacción del usuario para la sesión de autorización actual. Por ejemplo, podrías necesitar recuperar la identidad de SSO empresarial del usuario utilizada para iniciar sesión. Este objeto de datos de interacción de usuario contiene los datos de interacción más recientes enviados por el usuario, incluyendo:
| Propiedad | Descripción | Tipo |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
@@ -225,16 +225,16 @@ El objeto de contexto contiene los datos del usuario y los datos de la concesió
```
:::note
- Puede haber múltiples registros de verificación en el objeto de datos de interacción de usuario, especialmente cuando el usuario ha pasado por varios procesos de inicio de sesión o registro.
+ Puede haber múltiples registros de verificación en el objeto de datos de interacción de usuario, especialmente cuando el usuario ha pasado por múltiples procesos de inicio de sesión o registro.
- Por ejemplo, el usuario ha iniciado sesión usando un registro de verificación `Social`, luego ha vinculado una nueva dirección de correo electrónico mediante un registro de verificación `EmailVerificationCode`, y luego ha verificado el estado de MFA con un registro de verificación `Totp`. En este caso, es posible que debas manejar todos los registros de verificación en tu script.
+ Por ejemplo, el usuario ha iniciado sesión usando un registro de verificación `Social`, luego ha vinculado una nueva dirección de correo electrónico mediante un registro de verificación `EmailVerificationCode`, y luego ha verificado el estado de MFA con un registro de verificación `Totp`. En este caso, es posible que debas manejar todos los registros de verificación en consecuencia en tu script.
Cada tipo de registro de verificación solo estará presente una vez en el objeto de datos de interacción de usuario.
:::
### environmentVariables \{#environmentvariables}
-Utiliza la sección **Configurar variables de entorno** en la parte derecha para configurar las variables de entorno para tu script. Puedes usar estas variables para almacenar información sensible o datos de configuración que no quieras codificar directamente en el script, por ejemplo, claves de API, secretos o URLs.
+Utiliza la sección **Configurar variables de entorno** en la derecha para configurar las variables de entorno para tu script. Puedes usar estas variables para almacenar información sensible o datos de configuración que no quieras codificar directamente en el script. Por ejemplo, claves de API, secretos o URLs.
Todas las variables de entorno que configures aquí estarán disponibles en el script. Usa el objeto `environmentVariables` en el parámetro de entrada para acceder a estas variables.
@@ -273,17 +273,17 @@ Ten en cuenta que cualquier obtención de datos externos puede introducir latenc
Además:
-- Maneja correctamente los errores y los tiempos de espera en tu script para evitar que el proceso de emisión del token se bloquee.
+- Maneja correctamente los errores y el tiempo de espera en tu script para evitar que el proceso de emisión del token se bloquee.
- Usa encabezados de autorización adecuados para proteger tu API externa de accesos no autorizados.
:::
## Paso 4: Probar el script \{#step-4-test-the-script}
-Asegúrate de probar tu script antes de guardarlo. Haz clic en la pestaña **Contexto de prueba** en el lado derecho de la página para modificar la carga útil simulada del token y el contexto de datos de usuario para las pruebas.
+Asegúrate de probar tu script antes de guardarlo. Haz clic en la pestaña **Contexto de prueba** en el lado derecho de la página para modificar la carga útil simulada del token y el contexto de datos de usuario para pruebas.
Haz clic en **Ejecutar prueba** en la esquina superior derecha del editor para ejecutar el script con los datos simulados. El resultado del script se mostrará en el panel **Resultado de la prueba**.
-
+
:::note
El resultado de la prueba es la salida de la función `getCustomJwtClaims` con los datos simulados que configures ("reclamos extra del token" obtenidos después de completar el paso 3 en [el diagrama de secuencia](/developers/custom-token-claims/#how-do-custom-token-claims-work)). La carga útil real del token y el contexto de datos de usuario serán diferentes cuando el script se ejecute en el proceso de emisión del token.
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index cd868d44c78..a2dece4833f 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/es/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -1,36 +1,38 @@
---
id: sdk-conventions
-title: Convenciones del SDK de plataforma
-sidebar_label: Convenciones del SDK de plataforma
-sidebar_position: 7
+title: Convenciones de SDK de plataforma
+sidebar_label: Convenciones de SDK de plataforma
+sidebar_position: 8
---
-# Convenciones del SDK de plataforma
+# Convenciones de SDK de plataforma
-Logto proporciona un servicio de autenticación web muy poderoso y flexible.
+Logto ofrece un servicio de autenticación web muy potente y flexible.
En el uso práctico de los servicios de Logto, por conveniencia, a menudo es necesario que los desarrolladores integren el SDK de Logto en sus propias aplicaciones cliente para gestionar el estado de inicio de sesión del usuario, permisos y más.
Puedes encontrar SDKs para todos los lenguajes de programación / frameworks compatibles con Logto [aquí](/quick-starts).
-Si tienes mala suerte y no encuentras el SDK que deseas, aquí hay una convención que puedes seguir para implementar el SDK para tu lenguaje de programación deseado, facilitando el uso de los servicios de Logto.
+Si tienes la mala suerte de no encontrar el SDK que deseas, aquí tienes una convención que puedes seguir para implementar el SDK para tu lenguaje de programación preferido, facilitando el uso de los servicios de Logto.
Esta convención contiene tres partes principales:
-### ¿Cómo depurar el timeout de un webhook? \{#how-to-debug-webhook-timeout} +### ¿Cómo depurar el tiempo de espera del webhook? \{#how-to-debug-webhook-timeout}
-El endpoint que recibe los Webhooks debe devolver una respuesta 2xx lo más rápido posible para indicar a Logto que el Webhook se ha recibido correctamente. Dado que los diferentes usuarios tienen lógicas de procesamiento muy distintas para los Webhooks, las tareas excesivamente complejas pueden tardar varios segundos, provocando que el Webhook de Logto agote el tiempo de espera. La mejor práctica es mantener tu propia cola de eventos; al recibir el Webhook de Logto, inserta el evento en la cola y devuelve una respuesta 2xx a Logto. Luego, deja que tu propio worker procese las tareas en la cola paso a paso. Si el worker encuentra un error, manéjalo en tu propio servidor. +Para el endpoint que recibe los Webhooks, debe devolver una respuesta 2xx lo más rápido posible para indicar a Logto que el Webhook se ha recibido correctamente. Dado que diferentes usuarios tienen lógicas de procesamiento muy distintas para los Webhooks, las tareas excesivamente complejas pueden tardar varios segundos, provocando que el Webhook de Logto agote el tiempo de espera. La mejor práctica es mantener tu propia cola de eventos; al recibir el Webhook de Logto, inserta el evento en la cola y devuelve una respuesta 2xx a Logto. Luego, deja que tu propio worker procese las tareas en la cola paso a paso. Si el worker encuentra un error, manéjalo en tu propio servidor.
+
+ );
+}
+```
+
+### Paso 3: Gestiona las redirecciones de éxito \{#step-3-handle-success-redirects}
+
+Después de que los usuarios completen una acción, serán redirigidos a la URL que especificaste con un parámetro de consulta opcional `show_success`. Puedes usar esto para mostrar un mensaje de éxito:
+
+```tsx
+function SettingsPage() {
+ const searchParams = new URLSearchParams(window.location.search);
+ const showSuccess = searchParams.get('show_success');
+
+ return (
+ Configuración de cuenta
+ +
+ Email: user@example.com
+ Actualizar email
+
+
+
+ Contraseña: ••••••••
+
+ Cambiar contraseña
+
+
+
+
+ MFA: No configurado
+
+ Configurar autenticador
+
+
+
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## Consideraciones de seguridad \{#security-considerations}
+
+La interfaz preconstruida del Centro de Cuenta incluye medidas de seguridad integradas:
+
+- **Verificación de identidad**: Antes de realizar cambios sensibles (correo, teléfono, contraseña, MFA), los usuarios deben verificar su identidad usando su contraseña actual o un método de verificación existente
+- **Códigos de verificación**: Las actualizaciones de correo y teléfono requieren códigos de verificación enviados a la nueva dirección/número
+- **Validación de sesión**: Todas las operaciones validan la sesión del usuario para prevenir accesos no autorizados
+
+## Opciones de personalización \{#customization-options}
+
+La interfaz preconstruida del Centro de Cuenta hereda la personalización de marca de la configuración de tu experiencia de inicio de sesión, incluyendo:
+
+- Logo y colores
+- Modo oscuro / claro
+- Configuración de idioma
+
+Si necesitas más personalización de la que ofrece la interfaz preconstruida, considera usar [Account API](/end-user-flows/account-settings/by-account-api) para construir tus propias páginas personalizadas de gestión de cuentas.
+
+## Recursos relacionados \{#related-resources}
+
+- [Configuración de cuenta mediante Account API](/end-user-flows/account-settings/by-account-api) - Crea una gestión de cuentas personalizada con control total mediante API
+- [Configuración de cuenta mediante Management API](/end-user-flows/account-settings/by-management-api) - Gestión de cuentas a nivel de administrador
+- [Configuración de MFA](/end-user-flows/mfa) - Configura autenticación multifactor (MFA)
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/introduction/README.mdx
index e447e541d37..b98f81645b5 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/es/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -143,6 +143,10 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
icon: ¡Correo electrónico actualizado correctamente!
}
+ {showSuccess === 'password' && ¡Contraseña actualizada correctamente!
}
+ {/* ... resto de tu página de configuración */}
+ - Por defecto, Logto SDK siempre solicitará tres alcances: `openid`, `profile` y `offline_access`, y - no hay forma de eliminar estos alcances predeterminados. Pero puedes añadir más alcances al - configurar Logto: + Por defecto, el SDK de Logto siempre solicitará tres alcances: `openid`, `profile` y + `offline_access`, y no hay forma de eliminar estos alcances predeterminados. Pero puedes añadir + más alcances al configurar Logto:
{props.configScopesCode} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/developers/README.mdx index 86c93364028..6265735c72c 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -4,7 +4,7 @@ Logto est un service de [gestion des identités et des accès (IAM)](https://aut Afin de fournir plus de commodité à nos utilisateurs, Logto propose une série de fonctionnalités couramment utilisées par les développeurs. -## Lié à l’expérience de connexion \{#sign-in-experience-related} +## Liées à l’expérience de connexion \{#sign-in-experience-related} ```mdx-code-block import DocCardList from '@theme/DocCardList'; @@ -19,9 +19,18 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: 'Revendications personnalisées de jeton', + label: 'Jeton d’accès personnalisé', href: '/developers/custom-token-claims', - description: 'Étendez les capacités du contrôle d’accès en ajoutant des revendications supplémentaires, ce qui peut aider à réaliser l’ABAC ou à refuser l’émission de jetons.', + description: 'Utilisez des scripts personnalisés pour attacher des revendications supplémentaires aux jetons d’accès (access tokens), permettant l’ABAC ou le rejet de l’émission du jeton.', + customProps: { + icon:-### J’utilise Logto auto-hébergé et il faut plusieurs secondes pour obtenir les journaux d’audit, comment améliorer les performances ? \{#im-using-self-hosted-logto-and-it-takes-seconds-to-get-the-audit-logs-how-can-i-improve-the-performance} +### J’utilise Logto auto-hébergé et il faut plusieurs secondes pour obtenir les journaux d’audit, comment puis-je améliorer les performances ? \{#im-using-self-hosted-logto-and-it-takes-seconds-to-get-the-audit-logs-how-can-i-improve-the-performance}
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx new file mode 100644 index 00000000000..0b11362067f --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx @@ -0,0 +1,81 @@ +--- +sidebar_position: 3 +--- + +# Jeton d’identifiant personnalisé (Custom ID token) + +## Introduction \{#introduction} + +[Jeton d’identifiant (ID token)](https://auth.wiki/id-token) est un type spécial de jeton défini par le protocole [OpenID Connect (OIDC)](https://auth.wiki/openid-connect). Il sert d’attestation d’identité émise par le serveur d’autorisation (Logto) après qu’un utilisateur s’est authentifié avec succès, transportant des revendications sur l’identité de l’utilisateur authentifié. + +Contrairement aux [jetons d’accès (Access tokens)](/developers/custom-token-claims) qui sont utilisés pour accéder à des ressources protégées, les jetons d’identifiant sont spécifiquement conçus pour transmettre l’identité de l’utilisateur authentifié aux applications clientes. Ce sont des [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) qui contiennent des revendications sur l’événement d’authentification et l’utilisateur authentifié. + +## Fonctionnement des revendications du jeton d’identifiant \{#how-id-token-claims-work} + +Dans Logto, les revendications du jeton d’identifiant sont divisées en deux catégories : + +1. **Revendications OIDC standard** : Définies par la spécification OIDC, ces revendications sont entièrement déterminées par les portées demandées lors de l’authentification. +2. **Revendications étendues** : Revendications étendues par Logto pour transporter des informations d’identité supplémentaires, contrôlées par un **modèle à double condition** (Portée + Bascule). + +```mermaid +flowchart TD + A[Requête d’authentification utilisateur] --> B{Portées demandées} + B --> C[Portées OIDC standard] + B --> D[Portées étendues] + C --> E[Revendications standard incluses dans le jeton d’identifiant] + D --> F{Bascule activée dans la console ?} + F -->|Oui| G[Revendications étendues incluses dans le jeton d’identifiant] + F -->|Non| H[Revendications non incluses] +``` + +## Revendications OIDC standard \{#standard-oidc-claims} + +Les revendications standard sont entièrement régies par la spécification OIDC. Leur inclusion dans le jeton d’identifiant dépend uniquement des portées que votre application demande lors de l’authentification. Logto ne propose aucune option pour désactiver ou exclure sélectivement des revendications standard individuelles. + +Le tableau suivant montre la correspondance entre les portées standard et leurs revendications correspondantes : + +| Portée | Revendications | +| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `openid` | `sub` | +| `profile` | `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, `updated_at` | +| `email` | `email`, `email_verified` | +| `phone` | `phone_number`, `phone_number_verified` | +| `address` | `address` | + +Par exemple, si votre application demande les portées `openid profile email`, le jeton d’identifiant inclura toutes les revendications des portées `openid`, `profile` et `email`. + +## Revendications étendues \{#extended-claims} + +Au-delà des revendications OIDC standard, Logto étend des revendications supplémentaires qui transportent des informations d’identité spécifiques à l’écosystème Logto. Ces revendications étendues suivent un **modèle à double condition** pour être incluses dans le jeton d’identifiant : + +1. **Condition de portée** : L’application doit demander la portée correspondante lors de l’authentification. +2. **Bascule dans la console** : L’administrateur doit activer l’inclusion de la revendication dans le jeton d’identifiant via Logto Console. + +Les deux conditions doivent être satisfaites simultanément. La portée sert de déclaration d’accès au niveau du protocole, tandis que la bascule sert de contrôle d’exposition au niveau du produit — leurs responsabilités sont claires et non substituables. + +### Portées et revendications étendues disponibles \{#available-extended-scopes-and-claims} + +| Portée | Revendications | Description | Inclus par défaut | +| ------------------------------------ | ------------------------------ | ----------------------------------------------------- | ----------------- | +| `custom_data` | `custom_data` | Données personnalisées stockées sur l’utilisateur | | +| `identities` | `identities`, `sso_identities` | Identités sociales et SSO liées de l’utilisateur | | +| `roles` | `roles` | Rôles attribués à l’utilisateur | ✅ | +| `urn:logto:scope:organizations` | `organizations` | Identifiants des organisations de l’utilisateur | ✅ | +| `urn:logto:scope:organizations` | `organization_data` | Données d’organisation de l’utilisateur | | +| `urn:logto:scope:organization_roles` | `organization_roles` | Affectations de rôles d’organisation de l’utilisateur | ✅ | + +### Configuration dans Logto Console \{#configure-in-logto-console} + +Pour activer les revendications étendues dans le jeton d’identifiant : + +1. Accédez à
## Étape 1 : Modifier le script \{#step-1-edit-the-script}
-Utilisez l’éditeur de code à gauche pour modifier le script. Un `getCustomJwtClaims` par défaut avec une valeur de retour d’objet vide est fourni pour commencer. Vous pouvez modifier la fonction pour retourner un objet contenant vos propres revendications personnalisées.
+Utilisez l’éditeur de code à gauche pour modifier le script. Une fonction `getCustomJwtClaims` par défaut avec une valeur de retour d’objet vide est fournie pour commencer. Vous pouvez modifier la fonction pour retourner un objet contenant vos propres revendications personnalisées.
```jsx
const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
@@ -85,20 +85,20 @@ Vous trouverez la définition de type détaillée de l’objet de charge utile d
### context (Disponible uniquement pour le jeton d’accès utilisateur) \{#context-only-available-for-user-access-token}
-L’objet context contient les données utilisateur et les données de subvention pertinentes pour le processus d’autorisation (Authorization) en cours.
+L’objet context contient les données utilisateur et les données de subvention pertinentes pour le processus d’autorisation actuel.
- **Objet de données utilisateur**
- Pour le jeton d’accès utilisateur, Logto fournit un contexte de données utilisateur supplémentaire auquel vous pouvez accéder. L’objet de données utilisateur contient toutes les données de profil utilisateur et les données d’appartenance à l’organisation (Organization) dont vous pourriez avoir besoin pour configurer les revendications personnalisées. Veuillez consulter [Utilisateurs](/user-management/user-data) et [Organisations](/organizations/organization-management#organization-data-structure) pour plus de détails.
+ Pour le jeton d’accès utilisateur, Logto fournit un contexte de données utilisateur supplémentaire auquel vous pouvez accéder. L’objet de données utilisateur contient toutes les données de profil utilisateur et les données d’appartenance à l’organisation dont vous pourriez avoir besoin pour configurer les revendications personnalisées. Veuillez consulter [Utilisateurs](/user-management/user-data) et [Organisations](/organizations/organization-management#organization-data-structure) pour plus de détails.
- **Objet de données de subvention**
Pour le jeton d’accès utilisateur accordé par échange de jeton d’usurpation, Logto fournit un contexte de données de subvention supplémentaire auquel vous pouvez accéder. L’objet de données de subvention contient le contexte personnalisé du jeton sujet. Veuillez consulter [Usurpation d’identité utilisateur](/developers/user-impersonation) pour plus de détails.
- **Objet de données d’interaction utilisateur**
- Pour un jeton d’accès utilisateur donné, il peut y avoir des cas où vous devez accéder aux détails d’interaction de l’utilisateur pour la session d’autorisation (Authorization) en cours. Par exemple, vous pourriez avoir besoin de récupérer l’identité SSO d’entreprise de l’utilisateur utilisée pour la connexion. Cet objet de données d’interaction utilisateur contient les données d’interaction les plus récentes soumises par l’utilisateur, y compris :
+ Pour un jeton d’accès utilisateur donné, il peut y avoir des cas où vous devez accéder aux détails d’interaction de l’utilisateur pour la session d’autorisation en cours. Par exemple, vous pourriez avoir besoin de récupérer l’identité SSO d’entreprise de l’utilisateur utilisée pour la connexion. Cet objet de données d’interaction utilisateur contient les données d’interaction les plus récentes soumises par l’utilisateur, y compris :
- | Propriété | Description | Type |
- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
- | `interactionEvent` | L’événement d’interaction de l’utilisateur actuel | `SignIn` ou `Register` |
- | `userId` | L’identifiant utilisateur de l’interaction utilisateur actuelle | `string` |
- | `verificationRecords` | Une liste d’enregistrements de vérification soumis par l’utilisateur pour s’identifier et se vérifier lors des interactions. | `VerificationRecord[]` |
+ | Propriété | Description | Type |
+ | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
+ | `interactionEvent` | L’événement d’interaction de l’utilisateur actuel | `SignIn` ou `Register` |
+ | `userId` | L’identifiant utilisateur de l’interaction utilisateur actuelle | `string` |
+ | `verificationRecords` | Liste des enregistrements de vérification soumis par l’utilisateur pour identifier et vérifier son identité lors des interactions. | `VerificationRecord[]` |
Type d’enregistrement de vérification :
@@ -234,7 +234,7 @@ L’objet context contient les données utilisateur et les données de subventio
### environmentVariables \{#environmentvariables}
-Utilisez la section **Définir les variables d’environnement** à droite pour configurer les variables d’environnement pour votre script. Vous pouvez utiliser ces variables pour stocker des informations sensibles ou des données de configuration que vous ne souhaitez pas coder en dur dans le script. Par exemple, des clés API, des secrets ou des URLs.
+Utilisez la section **Définir les variables d’environnement** à droite pour configurer les variables d’environnement de votre script. Vous pouvez utiliser ces variables pour stocker des informations sensibles ou des données de configuration que vous ne souhaitez pas coder en dur dans le script. Par exemple, des clés API, des secrets ou des URLs.
Toutes les variables d’environnement que vous définissez ici seront disponibles dans le script. Utilisez l’objet `environmentVariables` dans le paramètre d’entrée pour accéder à ces variables.
@@ -246,11 +246,11 @@ L’objet `api` fournit un ensemble de fonctions utilitaires que vous pouvez uti
api.denyAccess(message?: string): void
```
-La fonction `api.denyAccess()` vous permet de refuser le processus de délivrance du jeton avec un message personnalisé. Vous pouvez utiliser cette fonction pour appliquer une validation d’accès supplémentaire lors du processus de délivrance du jeton.
+La fonction `api.denyAccess()` vous permet de refuser la délivrance du jeton avec un message personnalisé. Vous pouvez utiliser cette fonction pour appliquer une validation d’accès supplémentaire lors du processus de délivrance du jeton.
## Étape 3 : Récupérer des données externes \{#step-3-fetch-external-data}
-Vous pouvez utiliser la fonction intégrée `fetch` de node pour récupérer des données externes dans votre script. La fonction `fetch` est basée sur les promesses et vous permet d’effectuer des requêtes HTTP vers des API externes.
+Vous pouvez utiliser la fonction intégrée `fetch` de node pour récupérer des données externes dans votre script. La fonction `fetch` est basée sur les promesses et vous permet de faire des requêtes HTTP vers des API externes.
```jsx
const getCustomJwtClaims = async ({ environmentVariables }) => {
@@ -269,7 +269,7 @@ const getCustomJwtClaims = async ({ environmentVariables }) => {
```
:::note
-Attention, toute récupération de données externes peut introduire une latence dans le processus de délivrance du jeton. Assurez-vous que l’API externe est fiable et suffisamment rapide pour répondre à vos exigences.
+Attention, toute récupération de données externe peut introduire une latence dans le processus de délivrance du jeton. Assurez-vous que l’API externe est fiable et suffisamment rapide pour répondre à vos exigences.
De plus :
@@ -279,14 +279,14 @@ De plus :
## Étape 4 : Tester le script \{#step-4-test-the-script}
-Assurez-vous de tester votre script avant de l’enregistrer. Cliquez sur l’onglet **Contexte de test** à droite de la page pour modifier la charge utile du jeton simulée et le contexte de données utilisateur pour les tests.
+Assurez-vous de tester votre script avant de l’enregistrer. Cliquez sur l’onglet **Contexte de test** à droite de la page pour modifier la charge utile du jeton simulé et le contexte de données utilisateur pour les tests.
Cliquez sur **Exécuter le test** dans le coin supérieur droit de l’éditeur pour exécuter le script avec les données simulées. Le résultat du script s’affichera dans le tiroir **Résultat du test**.
:::note
-Le résultat du test correspond à la sortie de la fonction `getCustomJwtClaims` avec les données simulées que vous avez définies ("revendications supplémentaires du jeton" obtenues après avoir terminé l’étape 3 dans [le diagramme de séquence](/developers/custom-token-claims/#how-do-custom-token-claims-work)). La charge utile réelle du jeton et le contexte de données utilisateur seront différents lorsque le script sera exécuté lors du processus de délivrance du jeton.
+Le résultat du test est la sortie de la fonction `getCustomJwtClaims` avec les données simulées que vous avez définies ("revendications de jeton supplémentaires" obtenues après avoir complété l’étape 3 dans [le diagramme de séquence](/developers/custom-token-claims/#how-do-custom-token-claims-work)). La charge utile réelle du jeton et le contexte de données utilisateur seront différents lorsque le script sera exécuté lors du processus de délivrance du jeton.
:::
-Cliquez sur le bouton **Créer** pour enregistrer le script. Le script de revendications personnalisées pour le jeton sera enregistré et appliqué au processus de délivrance du jeton d’accès (Access token).
+Cliquez sur le bouton **Créer** pour enregistrer le script. Le script de revendications personnalisées sera enregistré et appliqué au processus de délivrance du jeton d’accès.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index af8c3eb9d43..5537d8cb327 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -2,18 +2,18 @@
id: sdk-conventions
title: Conventions des SDK de plateforme
sidebar_label: Conventions des SDK de plateforme
-sidebar_position: 7
+sidebar_position: 8
---
# Conventions des SDK de plateforme
-Logto offre un service d'authentification web très puissant et flexible.
+Logto fournit un service d'authentification web très puissant et flexible.
-Dans l'utilisation pratique des services de Logto, pour plus de commodité, il est souvent nécessaire pour les développeurs d'intégrer le SDK Logto dans leurs propres applications clientes pour gérer le statut de connexion des utilisateurs, les permissions, et plus encore.
+Dans l'utilisation pratique des services Logto, pour plus de commodité, il est souvent nécessaire pour les développeurs d'intégrer le SDK Logto dans leurs propres applications clientes afin de gérer l'état de connexion des utilisateurs, les permissions (Permissions), et plus encore.
Vous pouvez trouver les SDK pour tous les langages de programmation / frameworks pris en charge par Logto [ici](/quick-starts).
-Si vous n'avez pas de chance et ne trouvez pas le SDK que vous souhaitez, voici une convention que vous pouvez suivre pour implémenter le SDK pour le langage de programmation de votre choix, facilitant ainsi l'utilisation des services Logto.
+Si vous n'avez pas de chance et que vous ne trouvez pas le SDK que vous souhaitez, voici une convention que vous pouvez suivre pour implémenter le SDK dans le langage de programmation de votre choix, ce qui facilitera l'utilisation des services Logto.
Cette convention contient trois parties principales :
@@ -23,14 +23,14 @@ Cette convention contient trois parties principales :
Convention du SDK de plateforme
-## Ressources connexes \{#related-resources}
+## Ressources associées \{#related-resources}
+
+ );
+}
+```
+
+### Étape 3 : Gérer les redirections de succès \{#step-3-handle-success-redirects}
+
+Après avoir terminé une action, les utilisateurs seront redirigés vers l’URL que vous avez spécifiée avec un paramètre de requête optionnel `show_success`. Vous pouvez l’utiliser pour afficher un message de succès :
+
+```tsx
+function SettingsPage() {
+ const searchParams = new URLSearchParams(window.location.search);
+ const showSuccess = searchParams.get('show_success');
+
+ return (
+ Paramètres du compte
+ +
+ Email : user@example.com
+
+ Mettre à jour l’e-mail
+
+
+
+
+ Mot de passe : ••••••••
+
+ Changer le mot de passe
+
+
+
+
+ MFA : Non configuré
+
+ Configurer l’authentificateur
+
+
+
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## Considérations de sécurité \{#security-considerations}
+
+L’interface préconstruite du Centre de compte intègre des mesures de sécurité :
+
+- **Vérification d’identité** : Avant toute modification sensible (e-mail, téléphone, mot de passe, MFA), l’utilisateur doit vérifier son identité à l’aide de son mot de passe actuel ou d’une méthode de vérification existante
+- **Codes de vérification** : Les mises à jour d’e-mail et de téléphone nécessitent des codes de vérification envoyés à la nouvelle adresse/numéro
+- **Validation de session** : Toutes les opérations valident la session de l’utilisateur pour empêcher tout accès non autorisé
+
+## Options de personnalisation \{#customization-options}
+
+L’interface préconstruite du Centre de compte hérite de la personnalisation de votre expérience de connexion, notamment :
+
+- Logo et couleurs
+- Mode sombre / clair
+- Paramètres de langue
+
+Si vous avez besoin de plus de personnalisation que ce que propose l’interface préconstruite, envisagez d’utiliser l’[Account API](/end-user-flows/account-settings/by-account-api) pour créer vos propres pages de gestion de compte.
+
+## Ressources associées \{#related-resources}
+
+- [Paramètres du compte via Account API](/end-user-flows/account-settings/by-account-api) - Créez une gestion de compte personnalisée avec un contrôle total via l’API
+- [Paramètres du compte via Management API](/end-user-flows/account-settings/by-management-api) - Gestion de compte au niveau administrateur
+- [Configuration MFA](/end-user-flows/mfa) - Configurer l’authentification multi-facteurs (MFA)
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/introduction/README.mdx
index d423cb98f6e..d15f4988822 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -1,5 +1,5 @@
---
-description: Lancez rapidement votre système de gestion des identités et des accès en intégrant Logto. Profitez de l’authentification (Authentication), de l’autorisation (Authorization) et de la gestion multi-locataire, tout-en-un.
+description: Lancez rapidement votre système de gestion des identités et des accès en intégrant Logto. Profitez de l’authentification (Authentication), de l’autorisation (Authorization) et de la gestion multi-locataires, tout-en-un.
---
import AuditLogIcon from '@site/src/assets/audit-log.svg';
@@ -143,6 +143,10 @@ Bienvenue dans la documentation Logto ! Logto est une solution de gestion des id
icon: E-mail mis à jour avec succès !
}
+ {showSuccess === 'password' && Mot de passe mis à jour avec succès !
}
+ {/* ... reste de votre page de paramètres */}
+ -En bref, lorsque vous demandez une Portée, vous obtiendrez les Revendications correspondantes dans les informations utilisateur. Par exemple, si vous demandez la portée `email`, vous obtiendrez les données `email` et `email_verified` de l'utilisateur. +En résumé, lorsque vous demandez une portée (Scope), vous obtiendrez les revendications (Claims) correspondantes dans les informations utilisateur. Par exemple, si vous demandez la portée `email`, vous recevrez les données `email` et `email_verified` de l’utilisateur.
- Par défaut, le SDK Logto demandera toujours trois Portées : `openid`, `profile` et - `offline_access`, et il n'est pas possible de supprimer ces Portées par défaut. Mais vous pouvez - ajouter plus de Portées lors de la configuration de Logto : + Par défaut, le SDK Logto demandera toujours trois portées : `openid`, `profile` et + `offline_access`, et il n’est pas possible de supprimer ces portées par défaut. Cependant, vous + pouvez ajouter d’autres portées lors de la configuration de Logto :
{props.configScopesCode} diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/developers/README.mdx index 971437d6acd..08eae780af0 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -1,8 +1,8 @@ # 開発者 -Logto は、 [OAuth 2](https://auth.wiki/oauth-2.0) および [OIDC](https://auth.wiki/openid-connect) プロトコルに基づく [アイデンティティおよびアクセス管理 (IAM)](https://auth.wiki/iam) サービスです。Logto のような IAM サービスは、他の Web サービスの基盤として機能することが多く、それらの Web サービス内のさまざまな認可 (Authorization) 状態は Logto によって直接影響を受けます。 +Logto は、[OAuth 2](https://auth.wiki/oauth-2.0) および [OIDC](https://auth.wiki/openid-connect) プロトコルに基づいた [アイデンティティおよびアクセス管理 (IAM)](https://auth.wiki/iam) サービスです。Logto のような IAM サービスは、他の Web サービスの基盤として機能することが多く、それらの Web サービス内のさまざまな認可 (Authorization) 状態は Logto によって直接影響を受けます。 -ユーザーの利便性を高めるために、Logto はよく使われる開発者向け機能を一連で提供しています。 +ユーザーの利便性を高めるために、Logto はよく使われる開発者向け機能を一連提供しています。 ## サインイン体験関連 \{#sign-in-experience-related} @@ -19,9 +19,18 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: 'カスタムトークンクレーム (Custom token claims)', + label: 'カスタムアクセス トークン', href: '/developers/custom-token-claims', - description: '追加のクレーム (Claims) を付与することでアクセス制御の機能を拡張し、ABAC の実現やトークン発行の拒否などが可能になります。', + description: 'カスタムスクリプトを使用してアクセス トークンに追加のクレーム (Claims) を付与し、ABAC の実現やトークン発行の拒否を可能にします。', + customProps: { + icon:
:::note
-テスト結果は、モックデータを使った `getCustomJwtClaims` 関数の出力です（[シーケンス図](/developers/custom-token-claims/#how-do-custom-token-claims-work) のステップ 3 で得られる「追加トークンクレーム」）。実際のトークンペイロードやユーザーデータコンテキストは、トークン発行プロセスでスクリプトが実行される際に異なります。
+テスト結果は、モックデータを使った `getCustomJwtClaims` 関数の出力です（[シーケンス図](/developers/custom-token-claims/#how-do-custom-token-claims-work) のステップ 3 完了後に得られる「追加トークンクレーム」）。実際のトークンペイロードやユーザーデータコンテキストは、トークン発行プロセスでスクリプトが実行される際に異なります。
:::
-**作成** ボタンをクリックしてスクリプトを保存します。カスタムトークンクレームスクリプトは保存され、アクセス トークン (Access token) 発行プロセスに適用されます。
+**作成** ボタンをクリックしてスクリプトを保存します。カスタムトークンクレームスクリプトは保存され、アクセス トークン発行プロセスに適用されます。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index 1274ae21ff2..44f41546f10 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -2,20 +2,20 @@
id: sdk-conventions
title: プラットフォーム SDK の規約
sidebar_label: プラットフォーム SDK の規約
-sidebar_position: 7
+sidebar_position: 8
---
# プラットフォーム SDK の規約
Logto は非常に強力で柔軟な Web 認証 (Authentication) サービスを提供しています。
-Logto のサービスを実際に使用する際には、開発者が自分のクライアントアプリケーションに Logto SDK を統合して、ユーザーのサインイン状態や権限を管理することが便利です。
+Logto のサービスを実際に利用する際、利便性のために開発者が自身のクライアントアプリケーションに Logto SDK を統合し、ユーザーのサインイン状態や権限などを管理する必要がよくあります。
-Logto がサポートするすべてのプログラミング言語 / フレームワークの SDK は [こちら](/quick-starts) で見つけることができます。
+Logto がサポートするすべてのプログラミング言語 / フレームワーク向けの SDK は [こちら](/quick-starts) で確認できます。
-もし、希望する SDK が見つからない場合は、希望するプログラミング言語用に SDK を実装するための規約を以下に示します。これにより、Logto サービスをより簡単に利用できます。
+もし希望する SDK が見つからなかった場合は、ここで紹介する規約に従って、希望するプログラミング言語向けの SDK を実装することで、Logto サービスをより簡単に利用できるようになります。
-この規約は、次の 3 つの主要な部分で構成されています：
+この規約は主に 3 つのパートで構成されています：
+
+ );
+}
+```
+
+### ステップ 3: 成功時のリダイレクト処理 \{#step-3-handle-success-redirects}
+
+ユーザーが操作を完了すると、指定した URL へ `show_success` クエリパラメータ付きでリダイレクトされます。これを利用して成功メッセージを表示できます：
+
+```tsx
+function SettingsPage() {
+ const searchParams = new URLSearchParams(window.location.search);
+ const showSuccess = searchParams.get('show_success');
+
+ return (
+ Account Settings
+ +
+ Email: user@example.com
+ Update Email
+
+
+
+ Password: ••••••••
+ Change Password
+
+
+
+ MFA: Not configured
+
+ Set up Authenticator
+
+
+
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## セキュリティに関する考慮事項 \{#security-considerations}
+
+組み込み Account Center UI には、以下のセキュリティ対策が組み込まれています：
+
+- **アイデンティティ確認**：重要な変更（メール、電話、パスワード、MFA）の前に、現在のパスワードや既存の認証方法で本人確認を実施
+- **認証コード**：メールや電話番号の更新時には、新しいアドレス／番号へ認証コードを送信
+- **セッション検証**：すべての操作でユーザーのセッションを検証し、不正アクセスを防止
+
+## カスタマイズオプション \{#customization-options}
+
+組み込み Account Center UI は、サインイン体験設定のブランディング（ロゴやカラー、ダーク／ライトモード、言語設定など）を継承します。
+
+組み込み UI 以上のカスタマイズが必要な場合は、[Account API](/end-user-flows/account-settings/by-account-api) を利用して独自のアカウント管理ページを構築することも可能です。
+
+## 関連リソース \{#related-resources}
+
+- [Account API によるアカウント設定](/end-user-flows/account-settings/by-account-api) - API をフル活用したカスタムアカウント管理
+- [Management API によるアカウント設定](/end-user-flows/account-settings/by-management-api) - 管理者向けアカウント管理
+- [MFA 設定](/end-user-flows/mfa) - 多要素認証 (MFA) の設定
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/introduction/README.mdx
index e6a66804fbc..998d9f09740 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -32,7 +32,7 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
# はじめに
-Logto ドキュメントへようこそ！Logto は、モダンなアプリや SaaS プロダクト向けに設計されたアイデンティティおよびアクセス管理 (IAM) ソリューションです。アプリケーション向けに、安全でスケーラブルかつカスタマイズ可能な認証 (Authentication)・認可 (Authorization) システムを提供します。
+Logto ドキュメントへようこそ！Logto は、モダンなアプリや SaaS プロダクト向けに設計されたアイデンティティおよびアクセス管理 (IAM) ソリューションです。アプリケーションのために、安全でスケーラブルかつカスタマイズ可能な認証 (Authentication)・認可 (Authorization) システムを提供します。
## 機能から探す \{#explore-by-features}
@@ -143,6 +143,10 @@ Logto ドキュメントへようこそ！Logto は、モダンなアプリや S
icon: Email updated successfully!
}
+ {showSuccess === 'password' && Password updated successfully!
}
+ {/* ... rest of your settings page */}
+ -要するに、スコープをリクエストすると、ユーザー情報の対応するクレームを取得できます。例えば、`email` スコープをリクエストすると、ユーザーの `email` と `email_verified` データを取得できます。 +簡単に言うと、スコープ (Scope) をリクエストすると、対応するクレーム (Claim) がユーザー情報として取得できます。例えば、`email` スコープ (Scope) をリクエストすると、ユーザーの `email` および `email_verified` データが取得できます。
- デフォルトでは、Logto SDK は常に 3 つのスコープをリクエストします：`openid`、`profile`、および - `offline_access` です。 これらのデフォルトスコープを削除する方法はありませんが、Logto - を設定する際にさらにスコープを追加することができます： + デフォルトで、Logto SDK は常に 3 つのスコープ + (Scope)（`openid`、`profile`、`offline_access`）をリクエストします。 これらのデフォルトスコープ + (Scope) を削除する方法はありませんが、Logto の設定時に追加のスコープ (Scope) を追加できます：
{props.configScopesCode} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/developers/README.mdx index 9d20842bf7d..f134ca2cc12 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -1,6 +1,6 @@ # 개발자 -Logto는 [OAuth 2](https://auth.wiki/oauth-2.0) 및 [OIDC](https://auth.wiki/openid-connect) 프로토콜을 기반으로 한 [아이덴티티 및 접근 관리 (IAM)](https://auth.wiki/iam) 서비스입니다. Logto와 같은 IAM 서비스는 종종 다른 웹 서비스의 기반이 되며, 해당 웹 서비스 내의 다양한 인가 (Authorization) 상태는 Logto에 의해 직접적으로 영향을 받습니다. +Logto는 [OAuth 2](https://auth.wiki/oauth-2.0) 및 [OIDC](https://auth.wiki/openid-connect) 프로토콜을 기반으로 한 [아이덴티티 및 접근 관리 (IAM)](https://auth.wiki/iam) 서비스입니다. Logto와 같은 IAM 서비스는 종종 다른 웹 서비스의 기반 역할을 하며, 해당 웹 서비스 내의 다양한 인가 (Authorization) 상태는 Logto에 의해 직접적으로 영향을 받습니다. 사용자에게 편의를 제공하기 위해, Logto는 자주 사용되는 개발자 기능들을 제공합니다. @@ -19,9 +19,18 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: '커스텀 토큰 클레임 (Custom token claims)', + label: '커스텀 액세스 토큰 (Custom access token)', href: '/developers/custom-token-claims', - description: '추가 클레임 (Claims)을 첨부하여 접근 제어의 기능을 확장할 수 있으며, ABAC 구현 또는 토큰 발급 거부에 활용할 수 있습니다.', + description: '커스텀 스크립트를 사용하여 액세스 토큰 (Access token)에 추가 클레임 (Claim)을 부여하고, ABAC를 활성화하거나 토큰 발급을 거부할 수 있습니다.', + customProps: { + icon:원시 액세스 토큰 페이로드 생성 + IdP-->>IdP: 자격 증명 검증 및
원시 액세스 토큰 페이로드 생성 rect var(--mermaid-rect-fill) - note over IdP: 커스텀 토큰 클레임 - IdP->>IdP: 커스텀 토큰 클레임 스크립트 실행 (`getCustomJwtClaims`) &
추가 토큰 클레임 획득 + note over IdP: 커스텀 토큰 클레임 (Claim) + IdP->>IdP: 커스텀 토큰 클레임 스크립트 실행 (`getCustomJwtClaims`) 및
추가 토큰 클레임 획득 end IdP-->>IdP: 원시 액세스 토큰 페이로드와 추가 토큰 클레임 병합 IdP-->>IdP: 페이로드 서명 및 암호화하여 액세스 토큰 획득 @@ -48,11 +48,12 @@ sequenceDiagram ``` :::warning -Logto 내장 토큰 클레임은 덮어쓰거나 수정할 수 없습니다. 커스텀 클레임은 추가 클레임으로 토큰에 포함됩니다. 만약 커스텀 클레임이 내장 클레임과 충돌할 경우, 해당 커스텀 클레임은 무시됩니다. +Logto 내장 토큰 클레임 (Claim)은 덮어쓰거나 수정할 수 없습니다. 커스텀 클레임은 토큰에 추가 클레임으로 추가됩니다. 만약 커스텀 클레임이 내장 클레임과 충돌할 경우, 해당 커스텀 클레임은 무시됩니다. ::: ## 관련 리소스 \{#related-resources}
+
-## 1단계: 스크립트 편집하기 \{#step-1-edit-the-script}
+## 1단계: 스크립트 수정 \{#step-1-edit-the-script}
-좌측의 코드 에디터를 사용하여 스크립트를 수정하세요. 기본적으로 빈 객체를 반환하는 `getCustomJwtClaims` 함수가 제공됩니다. 이 함수를 수정하여 원하는 커스텀 클레임 객체를 반환할 수 있습니다.
+좌측의 코드 에디터를 사용하여 스크립트를 수정하세요. 기본적으로 빈 객체를 반환하는 `getCustomJwtClaims` 함수가 제공됩니다. 이 함수를 수정하여 원하는 커스텀 클레임(Claim) 객체를 반환할 수 있습니다.
```jsx
const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
@@ -43,10 +43,10 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
};
```
-이 에디터는 JavaScript 언어 서버를 사용하여 기본적인 구문 강조, 코드 완성, 오류 검사를 제공합니다. 입력 파라미터는 잘 타입 지정되어 있으며 jsDoc 스타일로 문서화되어 있습니다. 에디터의 IntelliSense를 활용하여 입력 객체의 속성에 올바르게 접근할 수 있습니다. 상세한 파라미터 정의는 페이지 우측에서 확인할 수 있습니다.
+이 에디터는 JavaScript 언어 서버를 사용하여 기본적인 문법 하이라이트, 코드 자동완성, 오류 검사를 제공합니다. 입력 파라미터는 잘 타입이 지정되어 있으며 jsDoc 스타일로 문서화되어 있습니다. 에디터의 IntelliSense를 활용하여 입력 객체의 속성에 올바르게 접근할 수 있습니다. 자세한 파라미터 정의는 페이지 우측에서 확인할 수 있습니다.
:::note
-이 함수는 모듈로 export됩니다. 함수 이름을 반드시 `getCustomJwtClaims`로 유지해야 모듈이 올바르게 함수를 export할 수 있습니다.
+이 함수는 모듈로 export됩니다. 함수명이 `getCustomJwtClaims`로 유지되어야 모듈이 올바르게 함수를 export할 수 있습니다.
:::
## 2단계: 입력 파라미터 \{#step-2-input-parameters}
@@ -55,49 +55,49 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
### token \{#token}
-토큰 페이로드 객체입니다. 이 객체에는 원본 토큰 클레임과 스크립트에서 접근할 수 있는 메타데이터가 포함되어 있습니다.
+토큰 페이로드 객체입니다. 이 객체에는 원본 토큰 클레임(Claim)과 스크립트에서 접근할 수 있는 메타데이터가 포함되어 있습니다.
-토큰 페이로드 객체와 사용자 데이터 객체의 상세 타입 정의는 페이지 우측에서 확인할 수 있습니다. 에디터의 IntelliSense를 통해 입력 객체의 속성에 올바르게 접근할 수 있습니다.
+토큰 페이로드 객체와 사용자 데이터 객체의 자세한 타입 정의는 페이지 우측에서 확인할 수 있습니다. 에디터의 IntelliSense를 통해 입력 객체의 속성에 올바르게 접근할 수 있습니다.
-- 사용자 액세스 토큰 데이터 객체
+- 사용자 액세스 토큰(Access token) 데이터 객체
| Property | Description | Type |
| -------------------- | ------------------------------------------------ | ------------- |
| `jti` | 고유 JWT id | `string` |
- | `aud` | 토큰의 대상 (Audience) | `string` |
- | `scope` | 토큰의 스코프 (Scope) | `string` |
+ | `aud` | 토큰의 대상(Audience) | `string` |
+ | `scope` | 토큰의 스코프(Scope) | `string` |
| `clientId` | 토큰의 클라이언트 id | `string` |
| `accountId` | 토큰의 사용자 id | `string` |
| `expiresWithSession` | 토큰이 세션과 함께 만료되는지 여부 | `boolean` |
- | `grantId` | 토큰의 현재 인증 (Authentication) grant id | `string` |
- | `gty` | 토큰의 grant type | `string` |
+ | `grantId` | 토큰의 현재 인증(인증(Authentication)) grant id | `string` |
+ | `gty` | 토큰의 grant 타입 | `string` |
| `kind` | 토큰 종류 | `AccessToken` |
-- 기계 간 액세스 토큰 데이터 객체
+- 기계 간 액세스 토큰(Access token) 데이터 객체
| Property | Description | Type |
| ---------- | -------------------------- | ------------------- |
| `jti` | 고유 JWT id | `string` |
- | `aud` | 토큰의 대상 (Audience) | `string` |
- | `scope` | 토큰의 스코프 (Scope) | `string` |
+ | `aud` | 토큰의 대상(Audience) | `string` |
+ | `scope` | 토큰의 스코프(Scope) | `string` |
| `clientId` | 토큰의 클라이언트 id | `string` |
| `kind` | 토큰 종류 | `ClientCredentials` |
-### context (사용자 액세스 토큰에서만 사용 가능) \{#context-only-available-for-user-access-token}
+### context (사용자 액세스 토큰(Access token)에서만 사용 가능) \{#context-only-available-for-user-access-token}
-context 객체에는 현재 인가 (Authorization) 과정과 관련된 사용자 데이터 및 grant 데이터가 포함되어 있습니다.
+context 객체에는 현재 인가(Authorization) 과정과 관련된 사용자 데이터 및 grant 데이터가 포함되어 있습니다.
- **사용자 데이터 객체**
- 사용자 액세스 토큰의 경우, Logto는 커스텀 클레임 설정에 필요한 모든 사용자 프로필 데이터와 조직 멤버십 데이터를 포함한 추가 사용자 데이터 컨텍스트를 제공합니다. 자세한 내용은 [사용자](/user-management/user-data) 및 [조직](/organizations/organization-management#organization-data-structure)을 확인하세요.
+ 사용자 액세스 토큰(Access token)의 경우, Logto는 추가적인 사용자 데이터 컨텍스트를 제공합니다. 사용자 데이터 객체에는 커스텀 클레임(Claim) 설정에 필요한 모든 사용자 프로필 데이터와 조직(Organization) 멤버십 데이터가 포함되어 있습니다. 자세한 내용은 [사용자](/user-management/user-data) 및 [조직](/organizations/organization-management#organization-data-structure)을 참고하세요.
- **Grant 데이터 객체**
- impersonation 토큰 교환으로 부여된 사용자 액세스 토큰의 경우, Logto는 추가 grant 데이터 컨텍스트를 제공합니다. grant 데이터 객체에는 subject 토큰의 커스텀 컨텍스트가 포함되어 있습니다. 자세한 내용은 [사용자 가장 (User impersonation)](/developers/user-impersonation)을 확인하세요.
+ 임퍼서네이션 토큰 교환으로 부여된 사용자 액세스 토큰(Access token)의 경우, Logto는 추가적인 grant 데이터 컨텍스트를 제공합니다. grant 데이터 객체에는 subject 토큰에서 전달된 커스텀 컨텍스트가 포함되어 있습니다. 자세한 내용은 [사용자 가장(User impersonation)](/developers/user-impersonation)을 참고하세요.
- **사용자 상호작용 데이터 객체**
- 특정 사용자 액세스 토큰의 경우, 현재 인가 세션에 대한 사용자의 상호작용 세부 정보를 접근해야 할 때가 있습니다. 예를 들어, 사용자가 로그인에 사용한 엔터프라이즈 SSO 아이덴티티를 조회해야 할 수 있습니다. 이 사용자 상호작용 데이터 객체에는 최근 사용자가 제출한 상호작용 데이터가 포함되어 있습니다. 예시:
+ 특정 사용자 액세스 토큰(Access token)의 경우, 현재 인가(Authorization) 세션에서 사용자의 상호작용 세부 정보를 접근해야 할 때가 있습니다. 예를 들어, 사용자가 로그인에 사용한 엔터프라이즈 SSO 아이덴티티를 조회해야 할 수 있습니다. 이 사용자 상호작용 데이터 객체에는 최근 사용자가 제출한 상호작용 데이터가 포함되어 있습니다. 주요 속성은 다음과 같습니다:
- | Property | Description | Type |
- | --------------------- | ----------------------------------------------------------------------------- | ------------------------ |
- | `interactionEvent` | 현재 사용자 상호작용의 이벤트 | `SignIn` 또는 `Register` |
- | `userId` | 현재 사용자 상호작용의 사용자 id | `string` |
- | `verificationRecords` | 상호작용 중 사용자가 아이덴티티를 식별 및 검증하기 위해 제출한 검증 기록 목록 | `VerificationRecord[]` |
+ | Property | Description | Type |
+ | --------------------- | ------------------------------------------------------------------------- | ------------------------ |
+ | `interactionEvent` | 현재 사용자 상호작용 이벤트 | `SignIn` 또는 `Register` |
+ | `userId` | 현재 사용자 상호작용의 사용자 id | `string` |
+ | `verificationRecords` | 상호작용 중 사용자가 본인 확인을 위해 제출한 검증(Verification) 기록 목록 | `VerificationRecord[]` |
- 검증 기록 타입 예시:
+ 검증(Verification) 기록 타입 예시:
```ts
// VerificationType.Password
@@ -222,28 +222,28 @@ context 객체에는 현재 인가 (Authorization) 과정과 관련된 사용자
```
:::note
- 사용자 상호작용 데이터 객체에는 여러 개의 검증 기록이 존재할 수 있습니다. 특히 사용자가 여러 번 로그인 또는 회원가입 과정을 거친 경우에 그렇습니다.
+ 사용자 상호작용 데이터 객체에는 여러 개의 검증(Verification) 기록이 존재할 수 있습니다. 특히 사용자가 여러 번 로그인 또는 회원가입 과정을 거친 경우에 해당합니다.
- 예: 사용자가 `Social` 검증 기록으로 로그인한 후, `EmailVerificationCode` 검증 기록을 통해 새 이메일 주소를 바인딩하고, `Totp` 검증 기록으로 MFA 상태를 검증한 경우. 이 경우, 스크립트에서 모든 검증 기록을 적절히 처리해야 할 수 있습니다.
+ 예를 들어, 사용자가 `Social` 검증(Verification) 기록으로 로그인한 후, `EmailVerificationCode` 검증(Verification) 기록을 통해 새 이메일을 바인딩하고, 이어서 `Totp` 검증(Verification) 기록으로 MFA 상태를 검증한 경우가 있습니다. 이 경우, 스크립트에서 모든 검증(Verification) 기록을 적절히 처리해야 합니다.
- 각 검증 기록 타입은 사용자 상호작용 데이터 객체에 한 번만 존재합니다.
+ 각 검증(Verification) 기록 타입은 사용자 상호작용 데이터 객체에 한 번만 존재합니다.
:::
### environmentVariables \{#environmentvariables}
-우측의 **환경 변수 설정 (Set environment variables)** 섹션을 사용하여 스크립트에 사용할 환경 변수를 설정하세요. 이 변수들은 스크립트 내에 하드코딩하고 싶지 않은 민감 정보나 설정 데이터를 저장하는 데 사용할 수 있습니다. 예: API 키, 시크릿, URL 등.
+우측의 **환경 변수 설정** 섹션을 사용하여 스크립트에 사용할 환경 변수를 설정하세요. 이 변수들은 스크립트 내에서 하드코딩하지 않고 민감 정보나 설정 데이터를 저장하는 데 사용할 수 있습니다. 예: API 키, 시크릿, URL 등.
여기서 설정한 모든 환경 변수는 스크립트 내에서 사용할 수 있습니다. 입력 파라미터의 `environmentVariables` 객체를 통해 접근하세요.
### api \{#api}
-`api` 객체는 토큰 발급 과정에서 추가 접근 제어를 위해 사용할 수 있는 유틸리티 함수 집합을 제공합니다. `api` 객체에는 다음과 같은 함수가 포함되어 있습니다:
+`api` 객체는 토큰 발급 과정에서 추가적인 접근 제어를 위해 사용할 수 있는 유틸리티 함수 집합을 제공합니다. `api` 객체에는 다음과 같은 함수가 포함되어 있습니다:
```jsx
api.denyAccess(message?: string): void
```
-`api.denyAccess()` 함수는 커스텀 메시지와 함께 토큰 발급 과정을 거부할 수 있게 해줍니다. 이 함수를 사용하여 토큰 발급 과정에서 추가 접근 검증을 강제할 수 있습니다.
+`api.denyAccess()` 함수는 커스텀 메시지와 함께 토큰 발급 과정을 거부할 수 있습니다. 이 함수를 사용하여 토큰 발급 과정에서 추가적인 접근 검증을 강제할 수 있습니다.
## 3단계: 외부 데이터 가져오기 \{#step-3-fetch-external-data}
@@ -266,24 +266,24 @@ const getCustomJwtClaims = async ({ environmentVariables }) => {
```
:::note
-외부 데이터 가져오기는 토큰 발급 과정에 지연을 초래할 수 있으니 주의하세요. 외부 API가 충분히 신뢰할 수 있고 빠른지 반드시 확인하세요.
+외부 데이터를 가져오는 과정은 토큰 발급 과정에 지연을 초래할 수 있습니다. 외부 API가 충분히 신뢰할 수 있고 빠른지 반드시 확인하세요.
추가로:
-- 스크립트 내에서 오류 및 타임아웃을 적절히 처리하여 토큰 발급 과정이 차단되지 않도록 하세요.
-- 적절한 인가 (Authorization) 헤더를 사용하여 외부 API가 무단 접근으로부터 보호되도록 하세요.
+- 토큰 발급 과정이 차단되지 않도록 스크립트 내에서 오류 및 타임아웃을 적절히 처리하세요.
+- 외부 API가 무단 접근으로부터 보호될 수 있도록 적절한 인가(Authorization) 헤더를 사용하세요.
:::
-## 4단계: 스크립트 테스트하기 \{#step-4-test-the-script}
+## 4단계: 스크립트 테스트 \{#step-4-test-the-script}
-스크립트를 저장하기 전에 반드시 테스트하세요. 페이지 우측의 **Test context** 탭을 클릭하여 테스트용 모의 토큰 페이로드와 사용자 데이터 컨텍스트를 수정할 수 있습니다.
+스크립트를 저장하기 전에 반드시 테스트하세요. 페이지 우측의 **테스트 컨텍스트** 탭을 클릭하여 테스트용 모의 토큰 페이로드 및 사용자 데이터 컨텍스트를 수정할 수 있습니다.
-에디터 우측 상단의 **Run test**를 클릭하여 모의 데이터로 스크립트를 실행하세요. 스크립트의 출력 결과는 **Test Result** 드로어에 표시됩니다.
+에디터 우측 상단의 **테스트 실행**을 클릭하여 모의 데이터로 스크립트를 실행하세요. 스크립트의 출력 결과는 **테스트 결과** 드로어에 표시됩니다.
:::note
-테스트 결과는 설정한 모의 데이터로 `getCustomJwtClaims` 함수가 실행된 출력값입니다 ("추가 토큰 클레임"은 [시퀀스 다이어그램](/developers/custom-token-claims/#how-do-custom-token-claims-work) 3단계 완료 후 얻은 값). 실제 토큰 페이로드와 사용자 데이터 컨텍스트는 토큰 발급 과정에서 실행될 때와 다를 수 있습니다.
+테스트 결과는, [시퀀스 다이어그램](/developers/custom-token-claims/#how-do-custom-token-claims-work) 3단계 완료 후 얻은 "추가 토큰 클레임(Claim)"(extra token claims)과 같이, 모의 데이터로 실행한 `getCustomJwtClaims` 함수의 출력입니다. 실제 토큰 페이로드 및 사용자 데이터 컨텍스트는 토큰 발급 과정에서 실행될 때와 다를 수 있습니다.
:::
-**Create** 버튼을 클릭하여 스크립트를 저장하세요. 커스텀 토큰 클레임 스크립트가 저장되어 액세스 토큰 발급 과정에 적용됩니다.
+**생성** 버튼을 클릭하여 스크립트를 저장하세요. 커스텀 토큰 클레임(Claim) 스크립트가 저장되어 액세스 토큰(Access token) 발급 과정에 적용됩니다.
diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index 4c282c16094..2552783fa0f 100644
--- a/i18n/ko/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/ko/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -1,36 +1,34 @@
---
id: sdk-conventions
-title: 플랫폼 SDK 규칙
-sidebar_label: 플랫폼 SDK 규칙
-sidebar_position: 7
+title: 플랫폼 SDK 규약
+sidebar_label: 플랫폼 SDK 규약
+sidebar_position: 8
---
-# 플랫폼 SDK 규칙
+# 플랫폼 SDK 규약
Logto는 매우 강력하고 유연한 웹 인증 (Authentication) 서비스를 제공합니다.
-Logto의 서비스를 실제로 사용할 때, 개발자가 사용자 로그인 상태, 권한 등을 관리하기 위해 Logto SDK를 자신의 클라이언트 애플리케이션에 통합하는 것이 편리한 경우가 많습니다.
+실제 Logto 서비스를 사용할 때, 개발자는 사용자 로그인 상태, 권한 등 관리를 위해 Logto SDK를 자신의 클라이언트 애플리케이션에 통합하는 것이 편리합니다.
-Logto가 지원하는 모든 프로그래밍 언어 / 프레임워크에 대한 SDK는 [여기](/quick-starts)에서 찾을 수 있습니다.
+Logto가 지원하는 모든 프로그래밍 언어 / 프레임워크용 SDK는 [여기](/quick-starts)에서 확인할 수 있습니다.
-원하는 SDK를 찾지 못한 경우, 원하는 프로그래밍 언어에 대한 SDK를 구현하기 위해 따를 수 있는 규칙이 있습니다. 이를 통해 Logto 서비스를 더 쉽게 사용할 수 있습니다.
+원하는 SDK가 없다면, 아래의 규약을 참고하여 원하는 프로그래밍 언어용 SDK를 직접 구현할 수 있습니다. 이를 통해 Logto 서비스를 더 쉽게 사용할 수 있습니다.
-이 규칙은 세 가지 주요 부분으로 구성되어 있습니다:
+이 규약은 세 가지 주요 부분으로 구성되어 있습니다:
--### Logto는 동기화된 webhook을 지원하나요? \{#does-logto-support-synced-webhooks} +### Logto는 동기 Webhook을 지원하나요? \{#does-logto-support-synced-webhooks}
-동기화된 webhook은 사용자 로그인 흐름을 더 원활하게 만들 수 있지만, 아직 지원하지 않습니다 (향후 지원 예정입니다). 따라서 현재 동기화된 webhook에 의존하는 시나리오는 모두 별도의 우회 방법이 필요합니다. 궁금한 점이 있다면 언제든 문의해 주세요. +동기 Webhook이 사용자 로그인 흐름을 더 원활하게 만들 수 있지만, 아직 지원하지 않습니다 (향후 지원 예정). 따라서 현재 동기 Webhook에 의존하는 시나리오는 모두 별도의 우회 방법이 필요합니다. 궁금한 점이 있으면 언제든 문의해 주세요.-### webhook 타임아웃은 어떻게 디버깅하나요? \{#how-to-debug-webhook-timeout} +### Webhook 타임아웃은 어떻게 디버깅하나요? \{#how-to-debug-webhook-timeout}
-Webhook을 수신하는 엔드포인트는 Logto에 Webhook이 성공적으로 수신되었음을 알리기 위해 가능한 한 빨리 2xx 응답을 반환해야 합니다. 사용자마다 Webhook 처리 로직이 매우 다르기 때문에, 지나치게 복잡한 작업은 몇 초가 걸릴 수 있어 Logto Webhook이 타임아웃될 수 있습니다. 최선의 방법은 자체 이벤트 큐를 유지하는 것입니다. Logto Webhook을 수신하면 이벤트를 큐에 삽입하고 Logto에 2xx 응답을 반환하세요. 이후 자체 워커가 큐의 작업을 단계별로 처리하도록 하세요. 워커에서 오류가 발생하면 자체 서버에서 처리하면 됩니다. +Webhook을 수신하는 엔드포인트는 Logto에 Webhook이 성공적으로 수신되었음을 알리기 위해 가능한 한 빨리 2xx 응답을 반환해야 합니다. 사용자마다 Webhook 처리 로직이 매우 다르기 때문에, 지나치게 복잡한 작업은 몇 초가 걸릴 수 있어 Logto Webhook이 타임아웃될 수 있습니다. 최선의 방법은 자체 이벤트 큐를 유지하는 것입니다. Logto Webhook을 수신하면 이벤트를 큐에 삽입하고 Logto에 2xx 응답을 반환하세요. 이후 워커가 큐의 작업을 단계별로 처리하도록 하세요. 워커에서 오류가 발생하면 자체 서버에서 처리하면 됩니다.-### `PostSignIn` webhook에서 클라이언트 IP 주소를 얻을 수 있나요? \{#can-i-get-the-client-ip-address-from-postsignin-webhooks} +### `PostSignIn` webhook에서 클라이언트 IP 주소를 받을 수 있나요? \{#can-i-get-the-client-ip-address-from-postsignin-webhooks}
-네, Webhook 페이로드에서 IP 주소, 사용자 에이전트 등을 얻을 수 있습니다. 현재 지원되지 않는 정보가 필요하다면 GitHub 이슈에 기능 요청을 생성하거나, 저희에게 연락해 주세요. +네, Webhook 페이로드에서 IP 주소, 사용자 에이전트 등을 받을 수 있습니다. 현재 지원되지 않는 정보가 필요하다면 GitHub 이슈에 기능 요청을 하거나, 저희에게 연락해 주세요.
+
+ );
+}
+```
+
+### 3단계: 성공 리디렉션 처리 \{#step-3-handle-success-redirects}
+
+사용자가 작업을 완료하면, 선택적으로 `show_success` 쿼리 파라미터와 함께 지정한 URL로 리디렉션됩니다. 이를 활용해 성공 메시지를 표시할 수 있습니다:
+
+```tsx
+function SettingsPage() {
+ const searchParams = new URLSearchParams(window.location.search);
+ const showSuccess = searchParams.get('show_success');
+
+ return (
+ Account Settings
+ +
+ Email: user@example.com
+ Update Email
+
+
+
+ Password: ••••••••
+ Change Password
+
+
+
+ MFA: Not configured
+
+ Set up Authenticator
+
+
+
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## 보안 고려 사항 \{#security-considerations}
+
+기본 제공 Account Center UI에는 다음과 같은 내장 보안 조치가 포함되어 있습니다:
+
+- **아이덴티티 확인**: 민감한 변경(이메일, 전화번호, 비밀번호, MFA) 전, 사용자는 현재 비밀번호 또는 기존 인증 방법으로 본인 확인 필요
+- **인증 코드**: 이메일 및 전화번호 업데이트 시 새 주소/번호로 인증 코드 전송 필요
+- **세션 검증**: 모든 작업에서 사용자의 세션을 검증하여 무단 접근 방지
+
+## 커스터마이징 옵션 \{#customization-options}
+
+기본 제공 Account Center UI는 로그인 경험 설정에서 지정한 브랜딩(로고, 색상, 다크/라이트 모드, 언어 설정 등)을 상속받습니다.
+
+기본 제공 UI 이상의 커스터마이징이 필요하다면, [Account API](/end-user-flows/account-settings/by-account-api)를 사용하여 맞춤형 계정 관리 페이지를 직접 구축할 수 있습니다.
+
+## 관련 리소스 \{#related-resources}
+
+- [Account API로 계정 설정](/end-user-flows/account-settings/by-account-api) - 전체 API 제어로 맞춤형 계정 관리 구축
+- [Management API로 계정 설정](/end-user-flows/account-settings/by-management-api) - 관리자 수준 계정 관리
+- [MFA 구성](/end-user-flows/mfa) - 다단계 인증 (MFA) 설정
diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/introduction/README.mdx
index 5f5a00f3121..39f0516fb76 100644
--- a/i18n/ko/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/ko/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -1,5 +1,5 @@
---
-description: Logto를 통합하여 아이덴티티 및 접근 관리 시스템을 빠르게 시작하세요. 인증 (Authentication), 인가 (Authorization), 다중 테넌트 관리까지 한 번에 누릴 수 있습니다.
+description: Logto를 통합하여 아이덴티티 및 접근 관리 시스템을 빠르게 시작하세요. 인증 (Authentication), 인가 (Authorization), 멀티 테넌트 관리를 한 번에 경험할 수 있습니다.
---
import AuditLogIcon from '@site/src/assets/audit-log.svg';
@@ -32,9 +32,9 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
# 소개
-Logto 문서에 오신 것을 환영합니다! Logto는 현대 앱과 SaaS 제품을 위해 설계된 아이덴티티 및 접근 관리 (IAM) 솔루션입니다. 애플리케이션을 위한 안전하고 확장 가능하며 맞춤화 가능한 인증 (Authentication) 및 인가 (Authorization) 시스템을 제공합니다.
+Logto 문서에 오신 것을 환영합니다! Logto는 현대 앱과 SaaS 제품을 위해 설계된 아이덴티티 및 접근 관리 (IAM) 솔루션입니다. 애플리케이션을 위한 안전하고, 확장 가능하며, 맞춤화 가능한 인증 (Authentication) 및 인가 (Authorization) 시스템을 제공합니다.
-## 기능별로 살펴보기 \{#explore-by-features}
+## 기능별 탐색 \{#explore-by-features}
Email updated successfully!
}
+ {showSuccess === 'password' && Password updated successfully!
}
+ {/* ... 나머지 설정 페이지 */}
+ -간단히 말해, 스코프를 요청하면 사용자 정보에서 해당 클레임을 받게 됩니다. 예를 들어, `email` 스코프를 요청하면 사용자의 `email` 및 `email_verified` 데이터를 받게 됩니다. +요약하자면, 스코프 (Scope)를 요청하면 해당하는 클레임 (Claim)을 사용자 정보에서 받을 수 있습니다. 예를 들어, `email` 스코프 (Scope)를 요청하면 사용자의 `email` 및 `email_verified` 데이터를 받을 수 있습니다.
- 기본적으로, Logto SDK는 항상 세 가지 스코프를 요청합니다: `openid`, `profile`, 그리고 - `offline_access`. 이 기본 스코프들은 제거할 수 없습니다. 그러나 Logto를 구성할 때 더 많은 스코프를 - 추가할 수 있습니다: + 기본적으로 Logto SDK는 항상 세 가지 스코프 (Scope)를 요청합니다: `openid`, `profile`, 그리고 + `offline_access`입니다. 이 기본 스코프 (Scope)는 제거할 수 없습니다. 하지만 Logto를 구성할 때 더 + 많은 스코프 (Scope)를 추가할 수 있습니다:
{props.configScopesCode} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/README.mdx index 783426d28d8..023daee6aa6 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -19,16 +19,25 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: 'Reivindicações personalizadas de token', + label: 'Token de acesso personalizado', href: '/developers/custom-token-claims', - description: 'Expanda as capacidades do controle de acesso anexando reivindicações adicionais, o que pode ajudar a alcançar ABAC ou rejeitar a emissão de tokens.', + description: 'Use scripts personalizados para anexar reivindicações adicionais aos tokens de acesso, habilitando ABAC ou rejeitando a emissão do token.', customProps: { icon:Console > Gerenciamento de usuários.
2. Selecione o usuário desejado e vá para a página de detalhes.
-3. Clique em "Logs do usuário". A tabela resultante exibirá exclusivamente eventos de log realizados e acionados por aquele usuário em particular.
+3. Clique em "Logs do usuário". A tabela resultante exibirá exclusivamente eventos de log realizados e acionados por esse usuário em particular.
-## Perguntas frequentes (FAQs) \{#faqs}
+## Perguntas frequentes \{#faqs}
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx
new file mode 100644
index 00000000000..228a847158e
--- /dev/null
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx
@@ -0,0 +1,81 @@
+---
+sidebar_position: 3
+---
+
+# Token de ID personalizado
+
+## Introdução \{#introduction}
+
+[Token de ID (ID token)](https://auth.wiki/id-token) é um tipo especial de token definido pelo protocolo [OpenID Connect (OIDC)](https://auth.wiki/openid-connect). Ele serve como uma asserção de identidade emitida pelo servidor de autorização (Logto) após um usuário ser autenticado com sucesso, carregando reivindicações sobre a identidade do usuário autenticado.
+
+Diferente dos [tokens de acesso (Access tokens)](/developers/custom-token-claims), que são usados para acessar recursos protegidos, os tokens de ID são projetados especificamente para transmitir a identidade do usuário autenticado para aplicativos clientes. Eles são [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) que contêm reivindicações sobre o evento de autenticação e o usuário autenticado.
+
+## Como funcionam as reivindicações do token de ID \{#how-id-token-claims-work}
+
+No Logto, as reivindicações do token de ID são divididas em duas categorias:
+
+1. **Reivindicações OIDC padrão**: Definidas pela especificação OIDC, essas reivindicações são totalmente determinadas pelos escopos solicitados durante a autenticação.
+2. **Reivindicações estendidas**: Reivindicações estendidas pelo Logto para carregar informações adicionais de identidade, controladas por um **modelo de dupla condição** (Escopo + Alternância).
+
+```mermaid
+flowchart TD
+ A[Solicitação de autenticação do usuário] --> B{Escopos solicitados}
+ B --> C[Escopos OIDC padrão]
+ B --> D[Escopos estendidos]
+ C --> E[Reivindicações padrão incluídas no token de ID]
+ D --> F{Alternância ativada no Console?}
+ F -->|Sim| G[Reivindicações estendidas incluídas no token de ID]
+ F -->|Não| H[Reivindicações não incluídas]
+```
+
+## Reivindicações OIDC padrão \{#standard-oidc-claims}
+
+As reivindicações padrão são completamente regidas pela especificação OIDC. Sua inclusão no token de ID depende exclusivamente dos escopos que seu aplicativo solicita durante a autenticação. O Logto não oferece nenhuma opção para desabilitar ou excluir seletivamente reivindicações padrão individuais.
+
+A tabela a seguir mostra o mapeamento entre escopos padrão e suas respectivas reivindicações:
+
+| Escopo | Reivindicações |
+| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `openid` | `sub` |
+| `profile` | `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, `updated_at` |
+| `email` | `email`, `email_verified` |
+| `phone` | `phone_number`, `phone_number_verified` |
+| `address` | `address` |
+
+Por exemplo, se seu aplicativo solicitar os escopos `openid profile email`, o token de ID incluirá todas as reivindicações dos escopos `openid`, `profile` e `email`.
+
+## Reivindicações estendidas \{#extended-claims}
+
+Além das reivindicações OIDC padrão, o Logto estende reivindicações adicionais que carregam informações de identidade específicas do ecossistema Logto. Essas reivindicações estendidas seguem um **modelo de dupla condição** para serem incluídas no token de ID:
+
+1. **Condição de escopo**: O aplicativo deve solicitar o escopo correspondente durante a autenticação.
+2. **Alternância no Console**: O administrador deve ativar a inclusão da reivindicação no token de ID através do Logto Console.
+
+Ambas as condições devem ser satisfeitas simultaneamente. O escopo serve como declaração de acesso na camada de protocolo, enquanto a alternância serve como controle de exposição na camada de produto — suas responsabilidades são claras e não substituíveis.
+
+### Escopos e reivindicações estendidas disponíveis \{#available-extended-scopes-and-claims}
+
+| Escopo | Reivindicações | Descrição | Incluído por padrão |
+| ------------------------------------ | ------------------------------ | ----------------------------------------------- | ------------------- |
+| `custom_data` | `custom_data` | Dados personalizados armazenados no usuário | |
+| `identities` | `identities`, `sso_identities` | Identidades sociais e SSO vinculadas do usuário | |
+| `roles` | `roles` | Papéis atribuídos ao usuário | ✅ |
+| `urn:logto:scope:organizations` | `organizations` | IDs das organizações do usuário | ✅ |
+| `urn:logto:scope:organizations` | `organization_data` | Dados da organização do usuário | |
+| `urn:logto:scope:organization_roles` | `organization_roles` | Papéis do usuário nas organizações | ✅ |
+
+### Configurar no Logto Console \{#configure-in-logto-console}
+
+Para habilitar reivindicações estendidas no token de ID:
+
+1. Navegue até Console > Custom JWT .
+2. Ative as reivindicações que deseja incluir no token de ID.
+3. Certifique-se de que seu aplicativo solicite os escopos correspondentes durante a autenticação.
+
+## Recursos relacionados \{#related-resources}
+
+Token de acesso personalizado
+
+
+ OpenID Connect Core - Token de ID
+
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx
index 46e708274c8..b517219c0ce 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx
@@ -2,26 +2,26 @@
sidebar_position: 2
---
-# Reivindicações personalizadas de token
+# Token de acesso personalizado
-O Logto oferece flexibilidade para adicionar reivindicações personalizadas dentro dos tokens de acesso (JWT / Token opaco). Com esse recurso, você pode incluir informações adicionais para sua lógica de negócio, todas transmitidas com segurança nos tokens e recuperáveis via introspecção no caso de tokens opacos.
+O Logto oferece flexibilidade para adicionar reivindicações personalizadas dentro dos tokens de acesso (Token de acesso JWT / Token opaco). Com esse recurso, você pode incluir informações adicionais para sua lógica de negócio, todas transmitidas com segurança nos tokens e recuperáveis via introspecção no caso de tokens opacos.
## Introdução \{#introduction}
[Tokens de acesso (Access tokens)](https://auth.wiki/access-token) desempenham um papel fundamental no processo de autenticação (Authentication) e autorização (Authorization), carregando as informações de identidade e permissões do sujeito, e são passados entre o [servidor Logto](/concepts/core-service) (atua como servidor de autenticação ou provedor de identidade, IdP), seu servidor de serviço web (provedor de recurso) e aplicativos clientes (clientes).
-[Reivindicações de token (Token claims)](https://auth.wiki/claim) são pares chave-valor que fornecem informações sobre uma entidade ou sobre o próprio token. As reivindicações podem incluir informações do usuário, tempo de expiração do token, permissões e outros metadados relevantes para o processo de autenticação (Authentication) e autorização (Authorization).
+[Reivindicações do token (Token claims)](https://auth.wiki/claim) são pares chave-valor que fornecem informações sobre uma entidade ou sobre o próprio token. As reivindicações podem incluir informações do usuário, tempo de expiração do token, permissões e outros metadados relevantes para o processo de autenticação (Authentication) e autorização (Authorization).
Existem dois tipos de tokens de acesso no Logto:
- **JSON Web Token:** [JSON Web Token (JWT)](https://auth.wiki/jwt) é um formato popular que codifica reivindicações de forma segura e legível pelos clientes. Reivindicações comuns como `sub`, `iss`, `aud` etc. são usadas em conformidade com o protocolo OAuth 2.0 (Veja [este link](https://datatracker.ietf.org/doc/html/rfc7519#section-4) para mais detalhes). JWTs permitem que consumidores acessem diretamente as reivindicações sem etapas adicionais de validação. No Logto, tokens de acesso são emitidos no formato JWT por padrão quando um cliente inicia solicitações de autorização de recursos ou organizações específicas.
- **Token opaco (Opaque token):** Um [token opaco](http://localhost:3000/concepts/opaque-token) não é autocontido e sempre requer uma etapa adicional de validação via endpoint de [introspecção de token](https://auth.wiki/token-introspection). Apesar do formato não transparente, tokens opacos podem ajudar a obter reivindicações e serem transmitidos com segurança entre as partes. As reivindicações do token são armazenadas com segurança no servidor Logto e acessadas pelos aplicativos clientes via endpoint de introspecção de token. Tokens de acesso são emitidos no formato opaco quando nenhum recurso ou organização específica é incluído na solicitação de autorização. Esses tokens são usados principalmente para acessar o endpoint OIDC `userinfo` e outros propósitos gerais.
-Em muitos casos, as reivindicações padrão não são suficientes para atender às necessidades específicas dos seus aplicativos, seja você usando JWT ou tokens opacos. Para resolver isso, o Logto oferece flexibilidade para adicionar reivindicações personalizadas dentro dos tokens de acesso. Com esse recurso, você pode incluir informações adicionais para sua lógica de negócio, todas transmitidas com segurança nos tokens e recuperáveis via introspecção no caso de tokens opacos.
+Em muitos casos, as reivindicações padrão não são suficientes para atender às necessidades específicas de seus aplicativos, seja usando JWT ou tokens opacos. Para resolver isso, o Logto oferece flexibilidade para adicionar reivindicações personalizadas dentro dos tokens de acesso. Com esse recurso, você pode incluir informações adicionais para sua lógica de negócio, todas transmitidas com segurança nos tokens e recuperáveis via introspecção no caso de tokens opacos.
## Como funcionam as reivindicações personalizadas de token? \{#how-do-custom-token-claims-work}
-O Logto permite inserir reivindicações personalizadas no `token de acesso (access token)` através de uma função de callback `getCustomJwtClaims`. Você pode fornecer sua implementação da função `getCustomJwtClaims` para retornar um objeto de reivindicações personalizadas. O valor retornado será mesclado com o payload original do token e assinado para gerar o token de acesso final.
+O Logto permite inserir reivindicações personalizadas no `token de acesso` através de uma função de callback `getCustomJwtClaims`. Você pode fornecer sua implementação da função `getCustomJwtClaims` para retornar um objeto de reivindicações personalizadas. O valor retornado será mesclado com o payload original do token e assinado para gerar o token de acesso final.
```mermaid
sequenceDiagram
@@ -34,11 +34,11 @@ sequenceDiagram
activate IdP
IdP-->>IdP: Validar credenciais &
gerar payload bruto do token de acesso
rect var(--mermaid-rect-fill)
- note over IdP: Reivindicações personalizadas de token
- IdP->>IdP: Executar script de reivindicações personalizadas (`getCustomJwtClaims`) &
obter reivindicações extras do token
+ note over IdP: Reivindicações personalizadas do token
+ IdP->>IdP: Executar script de reivindicações personalizadas do token (`getCustomJwtClaims`) &
obter reivindicações extras do token
end
IdP-->>IdP: Mesclar payload bruto do token de acesso e reivindicações extras
- IdP-->>IdP: Assinar & criptografar payload para obter o token de acesso
+ IdP-->>IdP: Assinar & criptografar payload para obter token de acesso
deactivate IdP
IdP-->>U: Emitir token de acesso no formato JWT
par Obter serviço via API
@@ -48,12 +48,12 @@ sequenceDiagram
```
:::warning
-As reivindicações internas do Logto NÃO podem ser sobrescritas ou modificadas. As reivindicações personalizadas serão adicionadas ao token como reivindicações adicionais. Se alguma reivindicação personalizada conflitar com as reivindicações internas, essas reivindicações personalizadas serão ignoradas.
+As reivindicações internas do token do Logto NÃO podem ser sobrescritas ou modificadas. As reivindicações personalizadas serão adicionadas ao token como reivindicações adicionais. Se houver conflito entre reivindicações personalizadas e as internas, as personalizadas serão ignoradas.
:::
## Recursos relacionados \{#related-resources}
Adicione reivindicações personalizadas para tokens de acesso JWT com Logto para potencializar sua
- autorização (Authorization)
+ autorização
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx
index 80834b8484e..e3c114c3b93 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx
@@ -7,32 +7,32 @@ sidebar_position: 2
# Casos de uso comuns
-Nesta seção, forneceremos alguns exemplos para ajudar você a entender cenários onde as [reivindicações personalizadas de token](/developers/custom-token-claims) podem ser úteis, oferecendo algumas referências. Assim, quando você encontrar dificuldades no gerenciamento de acesso, poderá avaliar se as reivindicações personalizadas de token podem trazer mais conveniência.
+Nesta seção, forneceremos alguns exemplos para ajudar você a entender cenários onde [reivindicações personalizadas em tokens de acesso](/developers/custom-token-claims) podem ser úteis, oferecendo algumas referências. Assim, quando você encontrar dificuldades no gerenciamento de acesso, poderá avaliar se as reivindicações personalizadas em tokens de acesso podem trazer conveniência.
## Tornar o controle de acesso baseado em atributos (ABAC) possível \{#make-attribute-based-access-control-abac-possible}
-[Controle de acesso baseado em atributos (ABAC)](https://auth.wiki/abac) é um modelo de controle de acesso que utiliza atributos (como papéis de usuário, propriedades do recurso e condições ambientais) para tomar decisões de controle de acesso. É uma forma flexível e dinâmica de gerenciar o acesso a recursos protegidos.
+[Controle de acesso baseado em atributos (ABAC)](https://auth.wiki/abac) é um modelo de controle de acesso que utiliza atributos (como papéis de usuário, propriedades de recursos e condições ambientais) para tomar decisões de controle de acesso. É uma forma flexível e dinâmica de gerenciar o acesso a recursos protegidos.
-Suponha que você esteja desenvolvendo um aplicativo, e o lançamento do app seja dividido em duas fases: beta público e lançamento oficial. Mesmo após o lançamento oficial do app, você deseja que os usuários antigos que participaram do beta público continuem usando os recursos pagos.
+Suponha que você esteja desenvolvendo um aplicativo, e o lançamento do app seja dividido em duas fases: beta público e lançamento oficial. Mesmo após o lançamento oficial do app, você deseja que os usuários antigos que participaram do beta público continuem utilizando os recursos pagos.
Após o lançamento oficial do app, você utiliza o recurso de [controle de acesso baseado em papel (RBAC)](/authorization/role-based-access-control) do Logto para implementar o controle de acesso ao uso dos recursos pagos. Para verificar facilmente se um usuário já utilizava o app durante a fase beta pública, você pode usar o método `getCustomJwtClaims()` para adicionar uma reivindicação `createdAt` no payload do token.
Então, ao realizar o controle de acesso em suas APIs protegidas, você precisa permitir tokens de acesso que atendam a uma das seguintes condições:
1. Com o contexto RBAC, possuir o escopo para acessar recursos pagos.
-2. O campo `createdAt` ser anterior ao término da fase beta pública.
+2. O campo `createdAt` ser anterior ao horário de término da fase beta pública.
-Se não houver o recurso de reivindicações personalizadas de token, ao verificar permissões para [autorização (Authorization)](/authorization), seria necessário chamar a Management API do Logto para verificar se o usuário com o token de acesso atual possui as permissões correspondentes ao papel exigido por determinado recurso de API.
+Se não houver o recurso de reivindicações personalizadas em tokens, ao verificar permissões para [autorização](/authorization), seria necessário chamar a Management API do Logto para verificar se o usuário com o token de acesso atual possui as permissões correspondentes ao papel exigido por determinado recurso de API.
-Em um cenário semelhante, suponha que seu app exiba mensagens de aniversário na página de login se o aniversário do usuário estiver próximo. Você pode usar reivindicações personalizadas de token para adicionar um campo de aniversário ao [payload do token](/user-management/personal-access-token#example-token-exchange), que pode ser usado para determinar se uma mensagem específica deve ser exibida.
+Em um cenário semelhante, suponha que seu app exiba mensagens de aniversário na página de login se o aniversário do usuário estiver próximo. Você pode usar reivindicações personalizadas em tokens para adicionar um campo de aniversário ao [payload do token](/user-management/personal-access-token#example-token-exchange), que pode ser utilizado para determinar se uma mensagem específica deve ser exibida.
## Bloquear manualmente a emissão de tokens \{#manually-block-token-issuance}
-Suponha que Joe esteja administrando um jogo online e utilize o Logto como sistema de [gerenciamento de identidade e acesso (IAM)](https://auth.wiki/iam).
+Suponha que Joe administre um jogo online e utilize o Logto como sistema de [gerenciamento de identidade e acesso (IAM)](https://auth.wiki/iam).
-Imagine que esse jogo exige recargas para comprar tempo de jogo. Joe registra o saldo de cada usuário em seu serviço de jogo e desconta continuamente do saldo conforme o tempo de jogo é utilizado. Joe deseja forçar os jogadores a fazer logout quando o saldo da conta for esgotado, incentivando-os a recarregar.
+Imagine que esse jogo exige recargas para comprar tempo de jogo. Joe registra o saldo de cada usuário em seu serviço de jogos e faz deduções contínuas do saldo conforme o tempo de jogo é utilizado. Joe deseja forçar os jogadores a sair do jogo quando o saldo da conta for esgotado, incentivando-os a recarregar.
-Neste caso, Joe também pode usar o recurso de reivindicações personalizadas de token fornecido pelo Logto para alcançar esse objetivo:
+Neste caso, Joe também pode usar o recurso de reivindicações personalizadas em tokens fornecido pelo Logto para alcançar esse objetivo:
1. No script, uma chamada de API externa [buscar dados externos](/developers/custom-token-claims/create-script/#step-3-fetch-external-data) pode ser usada para recuperar o saldo atual do jogador no servidor de jogos do Joe.
2. Se o saldo for menor ou igual a 0, o método [`api.denyAccess()`](/developers/custom-token-claims/create-script/#api) pode ser utilizado para bloquear a emissão do token.
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx
index 4e40e3882b5..71b6bb37a01 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx
@@ -1,19 +1,19 @@
---
id: create-script
-title: Criar um script de reivindicações personalizadas de token
-sidebar_label: Criar um script de reivindicações personalizadas de token
+title: Criar um script de token de acesso personalizado
+sidebar_label: Criar um script de token de acesso personalizado
sidebar_position: 3
---
-# Criar um script de reivindicações personalizadas de token
+# Criar um script de token de acesso personalizado
-Para [adicionar reivindicações personalizadas](/developers/custom-token-claims) ao [token de acesso (Access token)](https://auth.wiki/access-token), você precisa fornecer um script que retorne um objeto contendo essas reivindicações. O script deve ser escrito como uma função `JavaScript` que retorna um objeto com as reivindicações personalizadas.
+Para [adicionar reivindicações personalizadas](/developers/custom-token-claims) ao [token de acesso](https://auth.wiki/access-token), você precisa fornecer um script que retorne um objeto contendo essas reivindicações. O script deve ser escrito como uma função `JavaScript` que retorna um objeto com as reivindicações personalizadas.
-1. Navegue até Console > JWT personalizado .
+1. Navegue até Console > JWT Personalizado .
2. Existem dois tipos diferentes de tokens de acesso para os quais você pode personalizar as reivindicações do token de acesso:
- - **Token de acesso do usuário**: O token de acesso emitido para usuários finais. Ex.: para aplicativos Web ou aplicativos móveis.
- - **Token de acesso máquina para máquina**: O token de acesso emitido para serviços ou aplicativos. Ex.: para [aplicativos máquina para máquina](/quick-starts/m2m).
+ - **Token de acesso do usuário**: O token de acesso emitido para usuários finais. Ex.: para aplicações Web ou aplicações móveis.
+ - **Token de acesso máquina para máquina**: O token de acesso emitido para serviços ou aplicativos. Ex.: para [aplicações máquina para máquina](/quick-starts/m2m).
Diferentes tipos de tokens de acesso podem ter diferentes contextos de payload do token. Você pode personalizar as reivindicações do token para cada tipo de token de acesso separadamente.
@@ -29,16 +29,16 @@ O recurso de reivindicações personalizadas de token está disponível apenas p
## Implementar a função `getCustomJwtClaims()` \{#implement-getcustomjwtclaims-function}
-Na página de detalhes do **JWT personalizado**, você encontrará o editor de script para escrever seu script de reivindicações personalizadas de token. O script deve ser uma função `JavaScript` que retorna um objeto de reivindicações personalizadas.
+Na página de detalhes do **JWT Personalizado**, você encontrará o editor de script para escrever seu script de reivindicações personalizadas de token. O script deve ser uma função `JavaScript` que retorna um objeto de reivindicações personalizadas.
## Passo 1: Edite o script \{#step-1-edit-the-script}
-Use o editor de código no lado esquerdo para modificar o script. Um `getCustomJwtClaims` padrão com um valor de retorno de objeto vazio é fornecido para você começar. Você pode modificar a função para retornar um objeto com suas próprias reivindicações personalizadas.
+Use o editor de código no lado esquerdo para modificar o script. Um `getCustomJwtClaims` padrão com valor de retorno de objeto vazio é fornecido para você começar. Você pode modificar a função para retornar um objeto com suas próprias reivindicações personalizadas.
```jsx
const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
@@ -58,9 +58,9 @@ A função `getCustomJwtClaims` recebe um objeto como parâmetro de entrada. O o
### token \{#token}
-O objeto payload do token. Este objeto contém as reivindicações originais do token e metadados que você pode precisar acessar no script.
+O objeto de payload do token. Este objeto contém as reivindicações originais do token e metadados que você pode precisar acessar no script.
-Você pode encontrar a definição de tipo detalhada do objeto payload do token e do objeto de dados do usuário no lado direito da página. O IntelliSense do editor também ajudará você a acessar corretamente essas propriedades do objeto de entrada.
+Você pode encontrar a definição de tipo detalhada do objeto de payload do token e do objeto de dados do usuário no lado direito da página. O IntelliSense do editor também ajudará você a acessar corretamente essas propriedades do objeto de entrada.
- Objeto de dados do token de acesso do usuário
| Propriedade | Descrição | Tipo |
@@ -85,12 +85,12 @@ Você pode encontrar a definição de tipo detalhada do objeto payload do token
### context (Disponível apenas para token de acesso do usuário) \{#context-only-available-for-user-access-token}
-O objeto context contém os dados do usuário e dados da concessão relevantes para o processo atual de autorização (Authorization).
+O objeto de contexto contém os dados do usuário e dados da concessão relevantes para o processo atual de autorização.
- **Objeto de dados do usuário**
- Para token de acesso do usuário, o Logto fornece contexto adicional de dados do usuário para você acessar. O objeto de dados do usuário contém todos os dados de perfil do usuário e dados de associação à organização que você pode precisar para configurar as reivindicações personalizadas. Consulte [Usuários](/user-management/user-data) e [Organizações](/organizations/organization-management#organization-data-structure) para mais detalhes.
+ Para token de acesso do usuário, o Logto fornece contexto adicional de dados do usuário para você acessar. O objeto de dados do usuário contém todos os dados do perfil do usuário e dados de associação à organização que você pode precisar para configurar as reivindicações personalizadas. Consulte [Usuários](/user-management/user-data) e [Organizações](/organizations/organization-management#organization-data-structure) para mais detalhes.
- **Objeto de dados da concessão**
- Para token de acesso do usuário concedido por troca de token de imitação, o Logto fornece contexto adicional de dados da concessão para você acessar. O objeto de dados da concessão contém o contexto personalizado do token de sujeito. Consulte [Imitação de usuário (User impersonation)](/developers/user-impersonation) para mais detalhes.
+ Para token de acesso do usuário concedido por troca de token de imitação, o Logto fornece contexto adicional de dados da concessão para você acessar. O objeto de dados da concessão contém o contexto personalizado do token de sujeito. Consulte [Imitação de usuário](/developers/user-impersonation) para mais detalhes.
- **Objeto de dados de interação do usuário**
Para um determinado token de acesso do usuário, pode haver situações em que você precise acessar os detalhes de interação do usuário para a sessão de autorização atual. Por exemplo, você pode precisar recuperar a identidade SSO corporativa do usuário usada para login. Este objeto de dados de interação do usuário contém os dados de interação mais recentes enviados pelo usuário, incluindo:
@@ -225,7 +225,7 @@ O objeto context contém os dados do usuário e dados da concessão relevantes p
```
:::note
- Pode haver vários registros de verificação no objeto de dados de interação do usuário, especialmente quando o usuário passou por vários processos de login ou registro.
+ Pode haver vários registros de verificação no objeto de dados de interação do usuário, especialmente quando o usuário passou por múltiplos processos de login ou registro.
Ex.: o usuário fez login usando um registro de verificação `Social`, depois vinculou um novo endereço de e-mail através de um registro de verificação `EmailVerificationCode` e, em seguida, verificou o status MFA com um registro de verificação `Totp`. Nesse caso, você pode precisar tratar todos os registros de verificação adequadamente em seu script.
@@ -250,7 +250,7 @@ A função `api.denyAccess()` permite negar o processo de emissão do token com
## Passo 3: Buscar dados externos \{#step-3-fetch-external-data}
-Você pode usar a função nativa do node `fetch` para buscar dados externos em seu script. A função `fetch` é baseada em promessas e permite fazer requisições HTTP para APIs externas.
+Você pode usar a função `fetch` nativa do node para buscar dados externos em seu script. A função `fetch` é baseada em promessas e permite fazer requisições HTTP para APIs externas.
```jsx
const getCustomJwtClaims = async ({ environmentVariables }) => {
@@ -269,7 +269,7 @@ const getCustomJwtClaims = async ({ environmentVariables }) => {
```
:::note
-Atenção: qualquer busca de dados externos pode introduzir latência no processo de emissão do token. Certifique-se de que a API externa seja confiável e rápida o suficiente para atender aos seus requisitos.
+Atenção, qualquer busca de dados externos pode introduzir latência no processo de emissão do token. Certifique-se de que a API externa seja confiável e rápida o suficiente para atender aos seus requisitos.
Além disso:
@@ -281,12 +281,12 @@ Além disso:
Certifique-se de testar seu script antes de salvá-lo. Clique na aba **Contexto de teste** no lado direito da página para modificar o payload de token simulado e o contexto de dados do usuário para teste.
-Clique em **Executar teste** no canto superior direito do editor para rodar o script com os dados simulados. A saída do script será exibida na gaveta **Resultado do teste**.
+Clique em **Executar teste** no canto superior direito do editor para rodar o script com os dados simulados. A saída do script será exibida no painel **Resultado do teste**.
:::note
-O resultado do teste é a saída da função `getCustomJwtClaims` com os dados simulados que você definiu ("reivindicações extras do token" obtidas após concluir o passo 3 no [diagrama de sequência](/developers/custom-token-claims/#how-do-custom-token-claims-work)). O payload real do token e o contexto de dados do usuário serão diferentes quando o script for executado no processo de emissão do token.
+O resultado do teste é a saída da função `getCustomJwtClaims` com os dados simulados que você definiu ("reivindicações extras do token" obtidas após completar o passo 3 no [diagrama de sequência](/developers/custom-token-claims/#how-do-custom-token-claims-work)). O payload real do token e o contexto de dados do usuário serão diferentes quando o script for executado no processo de emissão do token.
:::
Clique no botão **Criar** para salvar o script. O script de reivindicações personalizadas de token será salvo e aplicado ao processo de emissão do token de acesso.
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index ae09c435efb..a986632af6a 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -1,34 +1,34 @@
---
id: sdk-conventions
-title: Convenções do SDK da plataforma
-sidebar_label: Convenções do SDK da plataforma
-sidebar_position: 7
+title: Convenções de SDK de plataforma
+sidebar_label: Convenções de SDK de plataforma
+sidebar_position: 8
---
-# Convenções do SDK da plataforma
+# Convenções de SDK de plataforma
-Logto fornece um serviço de autenticação web muito poderoso e flexível.
+Logto oferece um serviço de autenticação web muito poderoso e flexível.
No uso prático dos serviços do Logto, para conveniência, muitas vezes é necessário que os desenvolvedores integrem o SDK do Logto em seus próprios aplicativos cliente para gerenciar o status de login do usuário, permissões e mais.
Você pode encontrar SDKs para todas as linguagens de programação / frameworks suportados pelo Logto [aqui](/quick-starts).
-Se você não tiver sorte e não encontrar o SDK que deseja, aqui está uma convenção que você pode seguir para implementar o SDK para a linguagem de programação desejada, facilitando o uso dos serviços do Logto.
+Se você não tiver sorte e não encontrar o SDK desejado, aqui está uma convenção que você pode seguir para implementar o SDK na linguagem de programação desejada, facilitando o uso dos serviços do Logto.
Esta convenção contém três partes principais:
Estratégia de design
-Convenção do Core SDK
-Convenção do SDK da plataforma
+Convenção do SDK principal
+Convenção do SDK de plataforma
## Recursos relacionados \{#related-resources}
- Implementar um SDK OIDC simples no lado do cliente
+ Implemente um SDK OIDC simples no lado do cliente
- Criando um SDK baseado em framework Node.js para Logto em minutos
+ Criando um SDK baseado em Node.js para Logto em minutos
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx
index 3a1e32fac18..2b681c9c068 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx
@@ -2,12 +2,12 @@
id: signing-keys
title: Chaves de assinatura
sidebar_label: Chaves de assinatura
-sidebar_position: 4
+sidebar_position: 5
---
# Chaves de assinatura
-As [chaves de assinatura OIDC](https://auth.wiki/signing-key) do Logto, também conhecidas como "chaves privadas OIDC" e "chaves de cookie OIDC", são as chaves de assinatura usadas para assinar JWTs ([tokens de acesso (Access tokens)](https://auth.wiki/access-token) e [tokens de ID (ID tokens)](https://auth.wiki/id-token)) e cookies de navegador nas [sessões de login (sign-in sessions)](/end-user-flows/sign-out#sign-in-session) do Logto. Essas chaves de assinatura são geradas ao inicializar o banco de dados do Logto ([open-source](/logto-oss)) ou ao criar um novo tenant ([Cloud](/logto-cloud)) e podem ser gerenciadas via [CLI](/logto-oss/using-cli) (open-source), Management APIs ou Console UI.
+As [chaves de assinatura OIDC](https://auth.wiki/signing-key) do Logto, também conhecidas como "chaves privadas OIDC" e "chaves de cookie OIDC", são as chaves de assinatura usadas para assinar JWTs ([tokens de acesso (Access tokens)](https://auth.wiki/access-token) e [tokens de ID (ID tokens)](https://auth.wiki/id-token)) e cookies de navegador nas [sessões de login](/end-user-flows/sign-out#sign-in-session) do Logto. Essas chaves de assinatura são geradas ao inicializar o banco de dados do Logto ([open-source](/logto-oss)) ou ao criar um novo tenant ([Cloud](/logto-cloud)) e podem ser gerenciadas via [CLI](/logto-oss/using-cli) (open-source), Management APIs ou Console UI.
Por padrão, o Logto utiliza o algoritmo de curva elíptica (EC) para gerar assinaturas digitais. No entanto, considerando que os usuários frequentemente precisam verificar assinaturas de JWT e muitas ferramentas antigas não suportam o algoritmo EC (apenas RSA), implementamos a funcionalidade de rotação de chaves privadas e permitimos que os usuários escolham o algoritmo de assinatura (incluindo tanto RSA quanto EC). Isso garante compatibilidade com serviços que utilizam ferramentas de verificação de assinatura desatualizadas.
@@ -18,17 +18,17 @@ Teoricamente, as chaves de assinatura não devem ser expostas e não possuem tem
## Como funciona? \{#how-it-works}
- **Chave privada OIDC**
- Ao inicializar uma instância Logto, um par de chave pública e chave privada é gerado automaticamente e registrado no provedor OIDC subjacente. Assim, quando o Logto emite um novo JWT (token de acesso ou token de ID), o token é assinado com a chave privada. Ao mesmo tempo, qualquer aplicativo cliente que recebe um JWT pode usar a chave pública correspondente para verificar a assinatura do token, garantindo que o token não foi adulterado por terceiros. A chave privada é protegida no servidor Logto. A chave pública, como o nome sugere, é pública para todos e pode ser acessada através da interface `/oidc/jwks` do endpoint OIDC. Um algoritmo de assinatura pode ser especificado ao gerar a chave privada, e o Logto utiliza o algoritmo EC (Curva Elíptica) por padrão. Os usuários administradores podem alterar o algoritmo padrão para RSA (Rivest-Shamir-Adleman) ao rotacionar as chaves privadas.
+ Ao inicializar uma instância do Logto, um par de chave pública e chave privada é gerado automaticamente e registrado no provedor OIDC subjacente. Assim, quando o Logto emite um novo JWT (token de acesso ou token de ID), o token é assinado com a chave privada. Ao mesmo tempo, qualquer aplicativo cliente que recebe um JWT pode usar a chave pública correspondente para verificar a assinatura do token, garantindo que o token não foi adulterado por terceiros. A chave privada é protegida no servidor Logto. A chave pública, como o nome sugere, é pública para todos e pode ser acessada através da interface `/oidc/jwks` do endpoint OIDC. Um algoritmo de chave de assinatura pode ser especificado ao gerar a chave privada, e o Logto utiliza o algoritmo EC (Curva Elíptica) por padrão. Os usuários administradores podem alterar o algoritmo padrão para RSA (Rivest-Shamir-Adleman) ao rotacionar as chaves privadas.
- **Chave de cookie OIDC**
- Quando o usuário inicia um fluxo de login ou cadastro, uma "sessão OIDC" será criada no servidor, assim como um conjunto de cookies no navegador. Com esses cookies, o navegador pode solicitar à Experience API do Logto para realizar uma série de interações em nome do usuário, como login, cadastro e redefinição de senha. No entanto, ao contrário dos JWTs, os cookies são assinados e verificados apenas pelo próprio serviço OIDC do Logto, não sendo necessárias medidas de criptografia assimétrica. Portanto, não temos pares de chaves públicas para as chaves de assinatura de cookies, nem algoritmos de criptografia assimétrica.
+ Quando o usuário inicia um fluxo de login ou cadastro, uma "sessão OIDC" será criada no servidor, assim como um conjunto de cookies de navegador. Com esses cookies, o navegador pode solicitar à Experience API do Logto para realizar uma série de interações em nome do usuário, como login, cadastro e redefinição de senha. No entanto, ao contrário dos JWTs, os cookies são assinados e verificados apenas pelo próprio serviço OIDC do Logto, não sendo necessárias medidas de criptografia assimétrica. Portanto, não temos chaves públicas pareadas para as chaves de assinatura de cookies, nem algoritmos de criptografia assimétrica.
## Rotacionar chaves de assinatura pela Console UI \{#rotate-signing-keys-from-console-ui}
-O Logto introduz o recurso de "Rotação de Chaves de Assinatura", que permite criar uma nova chave privada OIDC e uma chave de cookie em seu tenant.
+O Logto introduz o recurso de "Rotação de Chaves de Assinatura", que permite criar uma nova chave privada OIDC e uma nova chave de cookie em seu tenant.
1. Navegue até Console > Chaves de assinatura . Lá, você pode gerenciar tanto as chaves privadas OIDC quanto as chaves de cookie OIDC.
2. Para rotacionar a chave de assinatura, clique no botão "Rotacionar chaves privadas" ou "Rotacionar chaves de cookie". Ao rotacionar as chaves privadas, você tem a opção de alterar o algoritmo de assinatura.
-3. Você encontrará uma tabela que lista todas as chaves de assinatura em uso. Observação: Você pode excluir a chave anterior, mas não pode excluir a atual.
+3. Você encontrará uma tabela que lista todas as chaves de assinatura em uso. Observação: Você pode excluir a chave anterior, mas não pode excluir a chave atual.
| Status | Descrição |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx
index 2aac19e39c1..3f7ff4edd0e 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx
@@ -1,8 +1,8 @@
---
id: user-impersonation
-title: Imitação de usuário (User impersonation)
-sidebar_label: Imitação de usuário (User impersonation)
-sidebar_position: 3
+title: Imitação de usuário
+sidebar_label: Imitação de usuário
+sidebar_position: 4
---
import TokenExchangePrerequisites from './fragments/_token-exchange-prerequisites.mdx';
@@ -32,7 +32,7 @@ sequenceDiagram
TechCorp-->>Sarah: Retorna token de sujeito
Sarah->>LogtoToken: POST /oidc/token
- Note over Sarah,LogtoToken: Troca o token de sujeito por um token de acesso
+ Note over Sarah,LogtoToken: Troca token de sujeito por token de acesso
LogtoToken-->>Sarah: Retorna token de acesso
Note over Sarah: Sarah agora pode acessar recursos como Alex
@@ -65,11 +65,11 @@ Content-Type: application/json
}
```
-Nesta API, o backend deve realizar verificações de autorização adequadas para garantir que Sarah tenha as permissões necessárias para imitar Alex.
+Nesta API, o backend deve realizar verificações adequadas de autorização para garantir que Sarah tenha as permissões necessárias para imitar Alex.
### Etapa 2: Obtendo um token de sujeito \{#step-2-obtaining-a-subject-token}
-O servidor da TechCorp, após validar a solicitação da Sarah, irá então chamar a [Management API](/integrate-logto/interact-with-management-api) do Logto para obter um token de sujeito.
+Após validar a solicitação de Sarah, o servidor da TechCorp irá chamar a [Management API](/integrate-logto/interact-with-management-api) do Logto para obter um token de sujeito.
**Requisição (servidor da TechCorp para a Management API do Logto)**
@@ -113,11 +113,11 @@ O servidor da TechCorp deve então retornar esse token de sujeito para o aplicat
{
try {
// Etapas 1 e 2: Solicitar imitação e obter token de sujeito
@@ -272,7 +272,7 @@ async function performImpersonation(): Promise {
// highlight-end
console.log('Token de acesso de imitação para Alex:', accessToken);
} catch (error) {
- console.error('Falha ao realizar a imitação:', error);
+ console.error('Falha ao realizar imitação:', error);
}
}
@@ -283,18 +283,18 @@ void performImpersonation();
:::note
1. O token de sujeito é de curta duração e para uso único.
-2. O token de acesso de imitação não vem com um [token de atualização (Refresh token)](https://auth.wiki/refresh-token). Sarah precisará repetir esse processo se o token expirar antes de resolver o problema de Alex.
-3. O servidor backend da TechCorp deve implementar verificações de autorização adequadas para garantir que apenas membros autorizados do suporte, como Sarah, possam solicitar imitação.
+2. O token de acesso de imitação não vem com um [token de atualização (refresh token)](https://auth.wiki/refresh-token). Sarah precisará repetir esse processo se o token expirar antes de resolver o problema de Alex.
+3. O servidor backend da TechCorp deve implementar verificações adequadas de autorização para garantir que apenas membros autorizados do suporte, como Sarah, possam solicitar imitação.
:::
-## Reivindicação `act` \{#act-claim}
+## `act` claim \{#act-claim}
-Ao usar o fluxo de troca de token para imitação, o token de acesso emitido pode incluir uma reivindicação adicional `act` (ator). Essa reivindicação representa a identidade da "parte atuante" — em nosso exemplo, Sarah, que está realizando a imitação.
+Ao usar o fluxo de troca de token para imitação, o token de acesso emitido pode incluir um claim adicional `act` (ator). Esse claim representa a identidade da "parte atuante" — no nosso exemplo, Sarah, que está realizando a imitação.
-Para incluir a reivindicação `act`, o aplicativo da Sarah precisa fornecer um `actor_token` na requisição de troca de token. Esse token deve ser um token de acesso válido para Sarah com o escopo `openid`. Veja como incluí-lo na requisição de troca de token:
+Para incluir o claim `act`, o aplicativo da Sarah precisa fornecer um `actor_token` na requisição de troca de token. Esse token deve ser um token de acesso válido para Sarah com o escopo `openid`. Veja como incluí-lo na requisição de troca de token:
-Para aplicativos web tradicionais ou aplicativos máquina para máquina:
+Para aplicações web tradicionais ou aplicações máquina para máquina:
```bash
POST /oidc/token HTTP/1.1
@@ -312,7 +312,7 @@ grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&resource=https://api.techcorp.com/customer-data
```
-Para SPA ou aplicativos nativos, inclua o `client_id` no corpo da requisição:
+Para SPA ou aplicações nativas, inclua o `client_id` no corpo da requisição:
```bash
POST /oidc/token HTTP/1.1
@@ -330,7 +330,7 @@ grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&resource=https://api.techcorp.com/customer-data
```
-Se um `actor_token` for fornecido, o token de acesso resultante conterá uma reivindicação `act` assim:
+Se um `actor_token` for fornecido, o token de acesso resultante conterá um claim `act` assim:
```json
{
@@ -344,11 +344,11 @@ Se um `actor_token` for fornecido, o token de acesso resultante conterá uma rei
}
```
-Essa reivindicação `act` indica claramente que Sarah (sarah789) está agindo em nome de Alex (alex123). A reivindicação `act` pode ser útil para auditoria e rastreamento de ações de imitação.
+Esse claim `act` indica claramente que Sarah (sarah789) está atuando em nome de Alex (alex123). O claim `act` pode ser útil para auditoria e rastreamento de ações de imitação.
-## Personalizando as reivindicações do token \{#customizing-token-claims}
+## Personalizando claims do token \{#customizing-token-claims}
-O Logto permite que você [personalize as reivindicações do token](/developers/custom-token-claims) para tokens de imitação. Isso pode ser útil para adicionar contexto ou metadados adicionais ao processo de imitação, como o motivo da imitação ou o chamado de suporte associado.
+O Logto permite [personalizar os claims do token](/developers/custom-token-claims) para tokens de imitação. Isso pode ser útil para adicionar contexto ou metadados adicionais ao processo de imitação, como o motivo da imitação ou o chamado de suporte associado.
Quando o servidor da TechCorp solicita um token de sujeito à Management API do Logto, ele pode incluir um objeto `context`:
@@ -363,7 +363,7 @@ Quando o servidor da TechCorp solicita um token de sujeito à Management API do
}
```
-Esse [contexto](/developers/custom-token-claims/create-script#context-only-available-for-user-access-token) pode então ser usado em uma função `getCustomJwtClaims()` para adicionar reivindicações específicas ao token de acesso final. Veja um exemplo de como isso pode ser implementado:
+Esse [contexto](/developers/custom-token-claims/create-script#context-only-available-for-user-access-token) pode então ser usado em uma função `getCustomJwtClaims()` para adicionar claims específicos ao token de acesso final. Veja um exemplo de como isso pode ser implementado:
```tsx
const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
@@ -392,14 +392,14 @@ O token de acesso resultante que Sarah recebe pode ser assim:
"reason": "Problema de acesso ao recurso",
"support_engineer": "sarah789"
}
- // ... outras reivindicações padrão
+ // ... outros claims padrão
}
```
-Personalizando as reivindicações do token de acesso dessa forma, a TechCorp pode incluir informações valiosas sobre o contexto da imitação, facilitando a auditoria e o entendimento das atividades de imitação em seu sistema.
+Ao personalizar os claims do token de acesso dessa forma, a TechCorp pode incluir informações valiosas sobre o contexto da imitação, facilitando a auditoria e o entendimento das atividades de imitação em seu sistema.
:::note
-Tenha cautela ao adicionar reivindicações personalizadas aos seus tokens. Evite incluir informações sensíveis que possam representar riscos de segurança caso o token seja interceptado ou vazado. Os JWTs são assinados, mas não criptografados, portanto as reivindicações são visíveis para qualquer pessoa com acesso ao token.
+Tenha cautela ao adicionar claims personalizados aos seus tokens. Evite incluir informações sensíveis que possam representar riscos de segurança caso o token seja interceptado ou vazado. Os JWTs são assinados, mas não criptografados, então os claims são visíveis para qualquer pessoa com acesso ao token.
:::
## Recursos relacionados \{#related-resources}
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx
index 3d73ca5880e..e09a8a70552 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx
@@ -1,12 +1,12 @@
---
-sidebar_position: 5
+sidebar_position: 6
---
# Webhooks
O [Webhook](https://auth.wiki/webhook) do Logto fornece notificações em tempo real para vários eventos, incluindo alterações em contas de usuários, papéis, permissões, organizações, papéis de organização, permissões de organização e [interações do usuário](/end-user-flows).
-Quando um evento é acionado, o Logto envia uma solicitação HTTP para a URL do Endpoint que você fornecer, contendo informações detalhadas sobre o evento, como ID do usuário, nome de usuário, email e outros detalhes relevantes (para saber mais sobre os dados incluídos no payload e no header, consulte [Solicitação de Webhook](/developers/webhooks/webhooks-request)). Seu aplicativo pode processar essa solicitação e tomar ações personalizadas, como enviar um email ou atualizar dados no banco de dados.
+Quando um evento é acionado, o Logto envia uma solicitação HTTP para a URL do Endpoint que você fornecer, contendo informações detalhadas sobre o evento, como ID do usuário, nome de usuário, e-mail e outros detalhes relevantes (para saber mais sobre os dados incluídos no payload e no header, consulte [Solicitação de Webhook](/developers/webhooks/webhooks-request)). Seu aplicativo pode processar essa solicitação e tomar ações personalizadas, como enviar um e-mail ou atualizar dados no banco de dados.
Continuamos adicionando mais eventos com base nas necessidades dos usuários. Se você tiver requisitos específicos para o seu negócio, por favor, nos avise.
@@ -16,10 +16,10 @@ Webhooks oferecem comunicação em tempo real entre aplicativos, eliminando a ne
Aqui estão alguns exemplos de casos de uso comuns de Webhook para CIAM:
-- **Enviar emails:** Configure um Webhook para enviar um email de boas-vindas a novos usuários após o registro ou notificar administradores quando um usuário fizer login de um novo dispositivo ou local.
-- **Enviar notificações:** Configure um Webhook para acionar um assistente virtual com seu sistema CRM para fornecer suporte ao cliente em tempo real quando os usuários se cadastrarem.
-- **Realizar chamadas adicionais de API**: Configure um Webhook para verificar o acesso do usuário checando seu domínio de email ou endereço IP e, em seguida, use a Management API do Logto para atribuir papéis apropriados com permissões de recursos.
-- **Sincronização de dados:** Configure Webhook para manter o aplicativo atualizado sobre alterações como suspensões ou exclusões de contas de usuários.
+- **Enviar e-mails:** Configure um Webhook para enviar um e-mail de boas-vindas a novos usuários após o registro ou notificar administradores quando um usuário fizer login de um novo dispositivo ou local.
+- **Enviar notificações:** Configure um Webhook para acionar um assistente virtual com seu sistema CRM para fornecer suporte ao cliente em tempo real quando usuários se cadastrarem.
+- **Realizar chamadas adicionais de API**: Configure um Webhook para verificar o acesso do usuário checando seu domínio de e-mail ou endereço IP e, em seguida, use a Management API do Logto para atribuir papéis apropriados com permissões de recurso.
+- **Sincronização de dados:** Configure Webhook para manter o aplicativo atualizado sobre alterações como suspensões ou exclusões de contas de usuário.
- **Gerar relatórios**: Configure um Webhook para receber dados de atividade de login de usuários e aproveite-os para criar relatórios sobre engajamento ou padrões de uso dos usuários.
## Termos \{#terms}
@@ -31,15 +31,15 @@ Aqui estão alguns exemplos de casos de uso comuns de Webhook para CIAM:
| Webhook | Um subtipo de hook que indica a chamada de uma API com o payload do evento. |
| Digamos que um desenvolvedor queira enviar uma notificação quando o usuário fizer login por um novo dispositivo, o desenvolvedor pode adicionar um webhook que chama a API do seu serviço de segurança para o evento PostSignIn. |
-Aqui está um exemplo de habilitação de dois web hooks para o evento `PostSignIn` no Logto:
+Aqui está um exemplo de habilitação de dois webhooks para o evento `PostSignIn` no Logto:
```mermaid
graph LR
subgraph Logto
SF(Login finalizado)
PS(Pós-login)
- WH2(Web hook 2)
- WH1(Web hook 1)
+ WH2(Webhook 2)
+ WH1(Webhook 1)
end
subgraph Serviço 2
@@ -67,7 +67,7 @@ graph LR
-Embora webhooks sincronizados tornassem o fluxo de login do usuário mais suave, ainda não os suportamos (iremos suportar no futuro). Portanto, cenários que dependem de webhooks sincronizados atualmente exigem diferentes soluções alternativas. Se você tiver dúvidas, não hesite em nos contatar.
+Embora webhooks sincronizados tornariam o fluxo de login do usuário mais suave, ainda não os suportamos (mas iremos no futuro). Portanto, cenários que dependem de webhooks sincronizados atualmente exigem soluções alternativas diferentes. Se você tiver dúvidas, não hesite em nos contatar.
+
+ );
+}
+```
+
+### Passo 3: Lide com os redirecionamentos de sucesso \{#step-3-handle-success-redirects}
+
+Após os usuários concluírem uma ação, eles serão redirecionados para a URL especificada com um parâmetro de consulta opcional `show_success`. Você pode usar isso para exibir uma mensagem de sucesso:
+
+```tsx
+function SettingsPage() {
+ const searchParams = new URLSearchParams(window.location.search);
+ const showSuccess = searchParams.get('show_success');
+
+ return (
+ Configurações da Conta
+ +
+ Email: user@example.com
+ Atualizar Email
+
+
+
+ Senha: ••••••••
+ Alterar Senha
+
+
+
+ MFA: Não configurado
+
+ Configurar Autenticador
+
+
+
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## Considerações de segurança \{#security-considerations}
+
+A interface pré-construída do Account Center inclui medidas de segurança integradas:
+
+- **Verificação de identidade**: Antes de realizar alterações sensíveis (email, telefone, senha, MFA), os usuários devem verificar sua identidade usando a senha atual ou outro método de verificação existente
+- **Códigos de verificação**: Atualizações de email e telefone exigem códigos de verificação enviados para o novo endereço/número
+- **Validação de sessão**: Todas as operações validam a sessão do usuário para evitar acessos não autorizados
+
+## Opções de personalização \{#customization-options}
+
+A interface pré-construída do Account Center herda a personalização das configurações da sua experiência de login, incluindo:
+
+- Logo e cores
+- Modo escuro/claro
+- Configurações de idioma
+
+Se você precisar de mais personalização além do que a interface pré-construída oferece, considere usar o [Account API](/end-user-flows/account-settings/by-account-api) para construir suas próprias páginas personalizadas de gerenciamento de conta.
+
+## Recursos relacionados \{#related-resources}
+
+- [Configurações de conta pelo Account API](/end-user-flows/account-settings/by-account-api) - Crie gerenciamento de conta personalizado com controle total via API
+- [Configurações de conta pelo Management API](/end-user-flows/account-settings/by-management-api) - Gerenciamento de conta em nível administrativo
+- [Configuração de MFA](/end-user-flows/mfa) - Configure autenticação multifatorial
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/introduction/README.mdx
index 861e4b4856c..d7436017907 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -109,7 +109,7 @@ Bem-vindo à documentação do Logto! O Logto é uma solução de gerenciamento
/>
Email atualizado com sucesso!
}
+ {showSuccess === 'password' && Senha atualizada com sucesso!
}
+ {/* ... resto da sua página de configurações */}
+ -Em resumo, quando você solicita um escopo, você obterá as reivindicações correspondentes nas informações do usuário. Por exemplo, se você solicitar o escopo `email`, você obterá os dados `email` e `email_verified` do usuário. +Resumidamente, ao solicitar um escopo, você receberá as reivindicações correspondentes nas informações do usuário. Por exemplo, se você solicitar o escopo `email`, receberá os dados `email` e `email_verified` do usuário.
- Por padrão, o Logto SDK sempre solicitará três escopos: `openid`, `profile` e `offline_access`, e - não há como remover esses escopos padrão. Mas você pode adicionar mais escopos ao configurar o + Por padrão, o SDK do Logto sempre solicitará três escopos: `openid`, `profile` e `offline_access`, + e não há como remover esses escopos padrão. Mas você pode adicionar mais escopos ao configurar o Logto:
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/README.mdx index d2f5cbf4e5d..8c86bcee3b9 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -1,8 +1,8 @@ # นักพัฒนา -Logto คือบริการ [การจัดการข้อมูลระบุตัวตนและการเข้าถึง (IAM)](https://auth.wiki/iam) ที่สร้างขึ้นบนโปรโตคอล [OAuth 2](https://auth.wiki/oauth-2.0) และ [OIDC](https://auth.wiki/openid-connect) บริการ IAM เช่น Logto มักเป็นรากฐานของบริการเว็บอื่น ๆ; สถานะการอนุญาตต่าง ๆ ภายในบริการเว็บเหล่านั้นจะได้รับผลโดยตรงจาก Logto +Logto คือบริการ [การจัดการเอกลักษณ์และการเข้าถึง (IAM)](https://auth.wiki/iam) ที่สร้างขึ้นบนโปรโตคอล [OAuth 2](https://auth.wiki/oauth-2.0) และ [OIDC](https://auth.wiki/openid-connect) บริการ IAM เช่น Logto มักเป็นรากฐานให้กับบริการเว็บอื่น ๆ; สถานะการอนุญาตต่าง ๆ ภายในบริการเหล่านั้นจะได้รับผลกระทบโดยตรงจาก Logto -เพื่ออำนวยความสะดวกให้กับผู้ใช้ Logto จึงมีฟีเจอร์สำหรับนักพัฒนาที่ใช้บ่อยหลายรายการ +เพื่ออำนวยความสะดวกให้กับผู้ใช้ Logto จึงมีฟีเจอร์สำหรับนักพัฒนาที่ใช้บ่อยให้เลือกใช้งาน ## เกี่ยวกับประสบการณ์การลงชื่อเข้าใช้ \{#sign-in-experience-related} @@ -19,18 +19,27 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: 'Custom token claims', + label: 'โทเค็นการเข้าถึงแบบกำหนดเอง (Custom access token)', href: '/developers/custom-token-claims', - description: 'ขยายความสามารถของการควบคุมการเข้าถึงด้วยการแนบการอ้างสิทธิ์ (claims) เพิ่มเติม ซึ่งช่วยให้บรรลุ ABAC หรือปฏิเสธการออกโทเค็น', + description: 'ใช้สคริปต์กำหนดเองเพื่อแนบการอ้างสิทธิ์เพิ่มเติม (claims) ไปยังโทเค็นการเข้าถึง ช่วยให้รองรับ ABAC หรือปฏิเสธการออกโทเค็น', customProps: { icon:
## วิเคราะห์เชิงลึกในระดับผู้ใช้ \{#perform-a-detailed-analysis-at-the-user-level}
-ผู้ดูแลระบบสามารถวิเคราะห์บันทึกที่เกี่ยวข้องกับผู้ใช้แต่ละรายได้อย่างละเอียด ช่วยให้สามารถตรวจสอบเหตุการณ์เฉพาะได้อย่างครบถ้วน ขั้นตอนการนำทางก็ง่ายและเป็นมิตรกับผู้ใช้
+ผู้ดูแลระบบสามารถวิเคราะห์บันทึกที่เกี่ยวข้องกับผู้ใช้แต่ละรายได้อย่างละเอียด ช่วยให้ตรวจสอบเหตุการณ์เฉพาะได้อย่างครบถ้วน ขั้นตอนการนำทางก็ง่ายและเป็นมิตรกับผู้ใช้
เพื่อเข้าถึงบันทึกเฉพาะผู้ใช้ ให้ทำตามขั้นตอนดังนี้:
1. ไปที่
-## คำถามที่พบบ่อย (FAQs) \{#faqs}
+## คำถามที่พบบ่อย \{#faqs}
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx
new file mode 100644
index 00000000000..395b766dbb3
--- /dev/null
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx
@@ -0,0 +1,81 @@
+---
+sidebar_position: 3
+---
+
+# โทเค็น ID แบบกำหนดเอง (Custom ID token)
+
+## บทนำ \{#introduction}
+
+[โทเค็น ID (ID token)](https://auth.wiki/id-token) คือโทเค็นชนิดพิเศษที่กำหนดโดยโปรโตคอล [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) ทำหน้าที่เป็นการยืนยันตัวตนที่ออกโดยเซิร์ฟเวอร์การอนุญาต (Logto) หลังจากผู้ใช้ยืนยันตัวตนสำเร็จ โดยจะบรรจุการอ้างสิทธิ์ (claims) เกี่ยวกับตัวตนของผู้ใช้ที่ได้รับการยืนยัน
+
+แตกต่างจาก [โทเค็นการเข้าถึง (Access tokens)](/developers/custom-token-claims) ซึ่งใช้สำหรับเข้าถึงทรัพยากรที่ได้รับการป้องกัน โทเค็น ID ถูกออกแบบมาโดยเฉพาะเพื่อส่งข้อมูลตัวตนของผู้ใช้ที่ได้รับการยืนยันไปยังแอปพลิเคชันไคลเอนต์ โทเค็นเหล่านี้เป็น [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) ที่บรรจุการอ้างสิทธิ์เกี่ยวกับเหตุการณ์การยืนยันตัวตนและผู้ใช้ที่ได้รับการยืนยัน
+
+## การทำงานของการอ้างสิทธิ์ในโทเค็น ID \{#how-id-token-claims-work}
+
+ใน Logto การอ้างสิทธิ์ในโทเค็น ID แบ่งออกเป็น 2 ประเภท:
+
+1. **การอ้างสิทธิ์ OIDC มาตรฐาน (Standard OIDC claims)**: กำหนดโดยข้อกำหนดของ OIDC การอ้างสิทธิ์เหล่านี้ขึ้นอยู่กับขอบเขต (scopes) ที่ร้องขอระหว่างการยืนยันตัวตน
+2. **การอ้างสิทธิ์แบบขยาย (Extended claims)**: การอ้างสิทธิ์ที่ Logto ขยายขึ้นเพื่อบรรจุข้อมูลตัวตนเพิ่มเติม โดยควบคุมด้วย **โมเดลสองเงื่อนไข (Scope + Toggle)**
+
+```mermaid
+flowchart TD
+ A[คำขอการยืนยันตัวตนของผู้ใช้] --> B{ขอบเขตที่ร้องขอ}
+ B --> C[ขอบเขต OIDC มาตรฐาน]
+ B --> D[ขอบเขตแบบขยาย]
+ C --> E[การอ้างสิทธิ์มาตรฐานที่รวมในโทเค็น ID]
+ D --> F{เปิด toggle ใน Console หรือไม่?}
+ F -->|ใช่| G[การอ้างสิทธิ์แบบขยายที่รวมในโทเค็น ID]
+ F -->|ไม่| H[ไม่รวมการอ้างสิทธิ์]
+```
+
+## การอ้างสิทธิ์ OIDC มาตรฐาน \{#standard-oidc-claims}
+
+การอ้างสิทธิ์มาตรฐานถูกควบคุมโดยข้อกำหนด OIDC อย่างสมบูรณ์ การรวมไว้ในโทเค็น ID ขึ้นอยู่กับขอบเขตที่แอปพลิเคชันของคุณร้องขอระหว่างการยืนยันตัวตน Logto ไม่ได้มีตัวเลือกให้ปิดหรือยกเว้นการอ้างสิทธิ์มาตรฐานแต่ละรายการ
+
+ตารางต่อไปนี้แสดงการแมประหว่างขอบเขตมาตรฐานกับการอ้างสิทธิ์ที่เกี่ยวข้อง:
+
+| ขอบเขต (Scope) | การอ้างสิทธิ์ (Claims) |
+| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `openid` | `sub` |
+| `profile` | `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, `updated_at` |
+| `email` | `email`, `email_verified` |
+| `phone` | `phone_number`, `phone_number_verified` |
+| `address` | `address` |
+
+ตัวอย่างเช่น หากแอปพลิเคชันของคุณร้องขอขอบเขต `openid profile email` โทเค็น ID จะรวมการอ้างสิทธิ์ทั้งหมดจากขอบเขต `openid`, `profile` และ `email`
+
+## การอ้างสิทธิ์แบบขยาย \{#extended-claims}
+
+นอกเหนือจากการอ้างสิทธิ์ OIDC มาตรฐาน Logto ยังขยายการอ้างสิทธิ์เพิ่มเติมที่บรรจุข้อมูลตัวตนเฉพาะของระบบ Logto การอ้างสิทธิ์แบบขยายเหล่านี้จะถูกเพิ่มในโทเค็น ID ตาม **โมเดลสองเงื่อนไข** ดังนี้:
+
+1. **เงื่อนไขขอบเขต (Scope condition)**: แอปพลิเคชันต้องร้องขอขอบเขตที่เกี่ยวข้องระหว่างการยืนยันตัวตน
+2. **Toggle ใน Console**: ผู้ดูแลระบบต้องเปิดการรวมการอ้างสิทธิ์นั้นในโทเค็น ID ผ่าน Logto Console
+
+ทั้งสองเงื่อนไขต้องเป็นจริงพร้อมกัน ขอบเขตทำหน้าที่เป็นการประกาศการเข้าถึงในระดับโปรโตคอล ส่วน toggle ทำหน้าที่ควบคุมการเปิดเผยในระดับผลิตภัณฑ์ — หน้าที่ของแต่ละส่วนชัดเจนและไม่สามารถทดแทนกันได้
+
+### ขอบเขตและการอ้างสิทธิ์แบบขยายที่มีให้ใช้งาน \{#available-extended-scopes-and-claims}
+
+| ขอบเขต (Scope) | การอ้างสิทธิ์ (Claims) | คำอธิบาย | รวมโดยค่าเริ่มต้น |
+| ------------------------------------ | ------------------------------ | ----------------------------------------------- | ----------------- |
+| `custom_data` | `custom_data` | ข้อมูลกำหนดเองที่เก็บในอ็อบเจกต์ผู้ใช้ | |
+| `identities` | `identities`, `sso_identities` | ข้อมูลบัญชีโซเชียลและ SSO ที่เชื่อมโยงกับผู้ใช้ | |
+| `roles` | `roles` | บทบาทที่กำหนดให้กับผู้ใช้ | ✅ |
+| `urn:logto:scope:organizations` | `organizations` | รหัสองค์กรของผู้ใช้ | ✅ |
+| `urn:logto:scope:organizations` | `organization_data` | ข้อมูลองค์กรของผู้ใช้ | |
+| `urn:logto:scope:organization_roles` | `organization_roles` | บทบาทของผู้ใช้ในแต่ละองค์กร | ✅ |
+
+### การตั้งค่าใน Logto Console \{#configure-in-logto-console}
+
+เพื่อเปิดใช้งานการอ้างสิทธิ์แบบขยายในโทเค็น ID:
+
+1. ไปที่ Console > Custom JWT
+2. เปิด toggle สำหรับการอ้างสิทธิ์ที่คุณต้องการรวมในโทเค็น ID
+3. ตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณร้องขอขอบเขตที่เกี่ยวข้องระหว่างการยืนยันตัวตน
+
+## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources}
+
+โทเค็นการเข้าถึงแบบกำหนดเอง (Custom access token)
+
+
+ OpenID Connect Core - ID Token
+
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx
index 4128e2af18a..3e971ac7552 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/README.mdx
@@ -2,45 +2,45 @@
sidebar_position: 2
---
-# การอ้างสิทธิ์โทเค็นแบบกำหนดเอง (Custom token claims)
+# โทเค็นการเข้าถึงแบบกำหนดเอง (Custom access token)
-Logto มอบความยืดหยุ่นในการเพิ่มการอ้างสิทธิ์แบบกำหนดเองภายในโทเค็นการเข้าถึง (โทเค็นการเข้าถึง (Access token); JWT / โทเค็นทึบ (Opaque token)). ด้วยฟีเจอร์นี้ คุณสามารถใส่ข้อมูลเพิ่มเติมสำหรับตรรกะทางธุรกิจของคุณ ซึ่งจะถูกส่งอย่างปลอดภัยในโทเค็นและสามารถดึงกลับมาได้ผ่าน introspection ในกรณีของโทเค็นทึบ
+Logto มอบความยืดหยุ่นในการเพิ่มการอ้างสิทธิ์ (claims) แบบกำหนดเองภายในโทเค็นการเข้าถึง (โทเค็นการเข้าถึง (Access token); JWT / โทเค็นทึบ (Opaque token)). ด้วยฟีเจอร์นี้ คุณสามารถใส่ข้อมูลเพิ่มเติมสำหรับตรรกะทางธุรกิจของคุณ ซึ่งจะถูกส่งอย่างปลอดภัยในโทเค็นและสามารถเรียกดูได้ผ่าน introspection ในกรณีของโทเค็นทึบ
## บทนำ \{#introduction}
-[โทเค็นการเข้าถึง (Access tokens)](https://auth.wiki/access-token) มีบทบาทสำคัญในกระบวนการการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) โดยจะบรรจุข้อมูลอัตลักษณ์และสิทธิ์ของผู้ถูกอ้างถึง (Subject) และถูกส่งต่อระหว่าง [เซิร์ฟเวอร์ Logto](/concepts/core-service) (ทำหน้าที่เป็น auth server หรือผู้ให้บริการข้อมูลระบุตัวตน (IdP)), เซิร์ฟเวอร์เว็บเซอร์วิสของคุณ (ผู้ให้บริการทรัพยากร), และแอปพลิเคชันฝั่งไคลเอนต์ (clients)
+[โทเค็นการเข้าถึง (Access tokens)](https://auth.wiki/access-token) มีบทบาทสำคัญในกระบวนการ การยืนยันตัวตน (Authentication) และ การอนุญาต (Authorization) โดยจะบรรจุข้อมูลอัตลักษณ์ของผู้ถูกอ้างถึง (Subject) และสิทธิ์ต่าง ๆ และถูกส่งต่อระหว่าง [เซิร์ฟเวอร์ Logto](/concepts/core-service) (ทำหน้าที่เป็น auth server หรือ identity provider, IdP), เซิร์ฟเวอร์เว็บเซอร์วิสของคุณ (resource provider), และแอปพลิเคชันฝั่งลูกค้า (clients)
-[การอ้างสิทธิ์โทเค็น (Token claims)](https://auth.wiki/claim) คือคู่คีย์-ค่า ที่ให้ข้อมูลเกี่ยวกับเอนทิตีหรือโทเค็นเอง การอ้างสิทธิ์อาจรวมถึงข้อมูลผู้ใช้, เวลาหมดอายุของโทเค็น, สิทธิ์ (Permissions), และเมตาดาต้าอื่น ๆ ที่เกี่ยวข้องกับกระบวนการการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization)
+[การอ้างสิทธิ์ของโทเค็น (Token claims)](https://auth.wiki/claim) คือคู่คีย์-ค่า ที่ให้ข้อมูลเกี่ยวกับเอนทิตีหรือโทเค็นเอง การอ้างสิทธิ์อาจรวมถึงข้อมูลผู้ใช้ เวลาหมดอายุของโทเค็น สิทธิ์ และเมตาดาต้าอื่น ๆ ที่เกี่ยวข้องกับกระบวนการ การยืนยันตัวตน (Authentication) และ การอนุญาต (Authorization)
ใน Logto มีโทเค็นการเข้าถึงอยู่ 2 ประเภท:
-- **JSON Web Token:** [JSON Web Token (JWT)](https://auth.wiki/jwt) เป็นฟอร์แมตยอดนิยมที่เข้ารหัสการอ้างสิทธิ์ในรูปแบบที่ปลอดภัยและอ่านได้โดยไคลเอนต์ การอ้างสิทธิ์มาตรฐาน เช่น `sub`, `iss`, `aud` ฯลฯ ถูกใช้ตามโปรโตคอล OAuth 2.0 (ดู [ลิงก์นี้](https://datatracker.ietf.org/doc/html/rfc7519#section-4) สำหรับรายละเอียดเพิ่มเติม) JWT อนุญาตให้ผู้บริโภคเข้าถึงการอ้างสิทธิ์ได้โดยตรงโดยไม่ต้องตรวจสอบเพิ่มเติม ใน Logto โทเค็นการเข้าถึงจะออกในรูปแบบ JWT โดยค่าเริ่มต้นเมื่อไคลเอนต์เริ่มคำขอการอนุญาตสำหรับทรัพยากรหรือองค์กรที่ระบุ
-- **โทเค็นทึบ (Opaque token):** [โทเค็นทึบ (Opaque token)](http://localhost:3000/concepts/opaque-token) ไม่ได้บรรจุข้อมูลในตัวเองและต้องตรวจสอบเพิ่มเติมผ่าน [token introspection](https://auth.wiki/token-introspection) เสมอ แม้จะมีรูปแบบที่ไม่โปร่งใส แต่โทเค็นทึบสามารถใช้เพื่อรับการอ้างสิทธิ์และส่งต่ออย่างปลอดภัยระหว่างแต่ละฝ่าย การอ้างสิทธิ์โทเค็นจะถูกเก็บไว้อย่างปลอดภัยในเซิร์ฟเวอร์ Logto และเข้าถึงได้โดยแอปไคลเอนต์ผ่าน endpoint introspection โทเค็นการเข้าถึงจะออกในรูปแบบทึบเมื่อไม่มีการระบุทรัพยากรหรือองค์กรในคำขอการอนุญาต โทเค็นเหล่านี้ใช้หลัก ๆ สำหรับเข้าถึง OIDC `userinfo` endpoint และวัตถุประสงค์ทั่วไปอื่น ๆ
+- **JSON Web Token:** [JSON Web Token (JWT)](https://auth.wiki/jwt) เป็นรูปแบบยอดนิยมที่เข้ารหัสการอ้างสิทธิ์ในลักษณะที่ปลอดภัยและอ่านได้โดย client การอ้างสิทธิ์มาตรฐาน เช่น `sub`, `iss`, `aud` ฯลฯ ถูกใช้ตามโปรโตคอล OAuth 2.0 (ดู [ลิงก์นี้](https://datatracker.ietf.org/doc/html/rfc7519#section-4) สำหรับรายละเอียดเพิ่มเติม) JWT อนุญาตให้ผู้ใช้เข้าถึงการอ้างสิทธิ์ได้โดยตรงโดยไม่ต้องตรวจสอบเพิ่มเติม ใน Logto โทเค็นการเข้าถึงจะออกในรูปแบบ JWT โดยค่าเริ่มต้นเมื่อ client เริ่มคำขอการอนุญาตของทรัพยากรหรือองค์กรที่ระบุ
+- **โทเค็นทึบ (Opaque token):** [โทเค็นทึบ (Opaque token)](http://localhost:3000/concepts/opaque-token) ไม่ได้บรรจุข้อมูลในตัวเองและต้องตรวจสอบเพิ่มเติมผ่าน [token introspection](https://auth.wiki/token-introspection) เสมอ แม้จะมีรูปแบบที่ไม่โปร่งใส แต่โทเค็นทึบสามารถใช้รับการอ้างสิทธิ์และส่งต่ออย่างปลอดภัยระหว่างแต่ละฝ่าย การอ้างสิทธิ์ของโทเค็นจะถูกเก็บไว้อย่างปลอดภัยในเซิร์ฟเวอร์ Logto และเข้าถึงได้โดย client ผ่าน token introspection endpoint โทเค็นการเข้าถึงจะออกในรูปแบบทึบเมื่อไม่มีการระบุ resource หรือ organization ในคำขอการอนุญาต โทเค็นเหล่านี้ใช้หลัก ๆ สำหรับเข้าถึง OIDC `userinfo` endpoint และวัตถุประสงค์ทั่วไปอื่น ๆ
-ในหลายกรณี การอ้างสิทธิ์มาตรฐานอาจไม่เพียงพอต่อความต้องการเฉพาะของแอปพลิเคชันของคุณ ไม่ว่าคุณจะใช้ JWT หรือโทเค็นทึบ เพื่อแก้ไขปัญหานี้ Logto จึงมอบความยืดหยุ่นในการเพิ่มการอ้างสิทธิ์แบบกำหนดเองภายในโทเค็นการเข้าถึง ด้วยฟีเจอร์นี้ คุณสามารถใส่ข้อมูลเพิ่มเติมสำหรับตรรกะทางธุรกิจของคุณ ซึ่งจะถูกส่งอย่างปลอดภัยในโทเค็นและสามารถดึงกลับมาได้ผ่าน introspection ในกรณีของโทเค็นทึบ
+ในหลายกรณี การอ้างสิทธิ์มาตรฐานอาจไม่เพียงพอต่อความต้องการเฉพาะของแอปพลิเคชันของคุณ ไม่ว่าคุณจะใช้ JWT หรือโทเค็นทึบก็ตาม เพื่อแก้ไขปัญหานี้ Logto จึงให้ความยืดหยุ่นในการเพิ่มการอ้างสิทธิ์แบบกำหนดเองในโทเค็นการเข้าถึง คุณสามารถใส่ข้อมูลเพิ่มเติมสำหรับตรรกะทางธุรกิจของคุณ ซึ่งจะถูกส่งอย่างปลอดภัยในโทเค็นและสามารถเรียกดูได้ผ่าน introspection ในกรณีของโทเค็นทึบ
## การอ้างสิทธิ์โทเค็นแบบกำหนดเองทำงานอย่างไร? \{#how-do-custom-token-claims-work}
-Logto อนุญาตให้คุณแทรกการอ้างสิทธิ์แบบกำหนดเองลงใน `access token` ผ่าน callback function `getCustomJwtClaims` คุณสามารถกำหนดฟังก์ชัน `getCustomJwtClaims` ของคุณเองเพื่อคืนค่าเป็นอ็อบเจกต์ของการอ้างสิทธิ์แบบกำหนดเอง ค่าที่คืนมาจะถูกรวมกับ payload ดั้งเดิมของโทเค็นและเซ็นเพื่อลงนามเป็นโทเค็นการเข้าถึงสุดท้าย
+Logto อนุญาตให้คุณแทรกการอ้างสิทธิ์แบบกำหนดเองลงใน `access token` ผ่านฟังก์ชัน callback `getCustomJwtClaims` คุณสามารถกำหนดการทำงานของ `getCustomJwtClaims` เพื่อคืนค่าเป็นอ็อบเจกต์ของการอ้างสิทธิ์แบบกำหนดเอง ค่าที่คืนมาจะถูกรวมกับ payload ดั้งเดิมของโทเค็นและถูกเซ็นเพื่อลงนามเป็นโทเค็นการเข้าถึงสุดท้าย
```mermaid
sequenceDiagram
participant U as ผู้ใช้หรือ user agent
- participant IdP as Logto (ผู้ให้บริการข้อมูลระบุตัวตน (IdP))
+ participant IdP as Logto (ผู้ให้บริการข้อมูลระบุตัวตน)
participant SP as ผู้ให้บริการเซอร์วิส
autonumber
U ->> IdP: คำขอการยืนยันตัวตน (พร้อมข้อมูลรับรอง)
activate IdP
- IdP-->>IdP: ตรวจสอบข้อมูลรับรอง &
สร้าง payload โทเค็นการเข้าถึงดิบ
+ IdP-->>IdP: ตรวจสอบข้อมูลรับรอง &
สร้าง payload ดิบของโทเค็นการเข้าถึง
rect var(--mermaid-rect-fill)
note over IdP: การอ้างสิทธิ์โทเค็นแบบกำหนดเอง
IdP->>IdP: รันสคริปต์การอ้างสิทธิ์โทเค็นแบบกำหนดเอง (`getCustomJwtClaims`) &
รับการอ้างสิทธิ์โทเค็นเพิ่มเติม
end
- IdP-->>IdP: รวม payload โทเค็นการเข้าถึงดิบกับการอ้างสิทธิ์โทเค็นเพิ่มเติม
+ IdP-->>IdP: รวม payload ดิบของโทเค็นการเข้าถึงกับการอ้างสิทธิ์เพิ่มเติม
IdP-->>IdP: เซ็น & เข้ารหัส payload เพื่อรับโทเค็นการเข้าถึง
deactivate IdP
- IdP-->>U: ออกโทเค็นการเข้าถึงรูปแบบ JWT
+ IdP-->>U: ออกโทเค็นการเข้าถึงแบบ JWT
par ขอใช้บริการผ่าน API
U->>SP: คำขอบริการ (พร้อม JWT access token)
SP-->>U: ตอบกลับบริการ
@@ -48,12 +48,11 @@ sequenceDiagram
```
:::warning
-การอ้างสิทธิ์โทเค็นที่มีอยู่ใน Logto ไม่สามารถถูกเขียนทับหรือแก้ไขได้ การอ้างสิทธิ์แบบกำหนดเองจะถูกเพิ่มเข้าไปในโทเค็นเป็นการอ้างสิทธิ์เพิ่มเติม หากมีการอ้างสิทธิ์แบบกำหนดเองที่ขัดแย้งกับการอ้างสิทธิ์ที่มีอยู่ในระบบ การอ้างสิทธิ์แบบกำหนดเองนั้นจะถูกละเว้น
+การอ้างสิทธิ์ที่มีอยู่ใน Logto ไม่สามารถถูกเขียนทับหรือแก้ไขได้ การอ้างสิทธิ์แบบกำหนดเองจะถูกเพิ่มเข้าไปในโทเค็นเป็นข้อมูลเพิ่มเติม หากมีการอ้างสิทธิ์แบบกำหนดเองที่ขัดแย้งกับการอ้างสิทธิ์ที่มีอยู่ การอ้างสิทธิ์แบบกำหนดเองนั้นจะถูกละเว้น
:::
## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources}
- เพิ่มการอ้างสิทธิ์แบบกำหนดเองสำหรับโทเค็นการเข้าถึง JWT ด้วย Logto
- เพื่อเสริมประสิทธิภาพการอนุญาตของคุณ
+ เพิ่มการอ้างสิทธิ์แบบกำหนดเองให้กับ JWT access token ด้วย Logto เพื่อยกระดับการอนุญาตของคุณ
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx
index d4e50b168a3..d3c591b4f1b 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/common-use-cases.mdx
@@ -7,34 +7,34 @@ sidebar_position: 2
# กรณีการใช้งานทั่วไป
-ในส่วนนี้ เราจะยกตัวอย่างเพื่อช่วยให้คุณเข้าใจสถานการณ์ที่ [การอ้างสิทธิ์โทเค็นแบบกำหนดเอง](/developers/custom-token-claims) สามารถนำไปใช้ได้จริง พร้อมทั้งเป็นข้อมูลอ้างอิง เมื่อคุณพบปัญหาในการจัดการการเข้าถึง คุณจะสามารถประเมินได้ว่าการอ้างสิทธิ์โทเค็นแบบกำหนดเองจะช่วยให้คุณสะดวกขึ้นหรือไม่
+ในส่วนนี้ เราจะยกตัวอย่างเพื่อช่วยให้คุณเข้าใจสถานการณ์ที่ [การอ้างสิทธิ์โทเค็นการเข้าถึงแบบกำหนดเอง](/developers/custom-token-claims) อาจมีประโยชน์ พร้อมทั้งให้ข้อมูลอ้างอิงบางประการ เพื่อที่เมื่อคุณพบปัญหาในการจัดการการเข้าถึง คุณจะสามารถประเมินได้ว่าการอ้างสิทธิ์โทเค็นการเข้าถึงแบบกำหนดเองจะช่วยให้คุณสะดวกขึ้นหรือไม่
## ทำให้การควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC) เป็นไปได้ \{#make-attribute-based-access-control-abac-possible}
-[การควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC)](https://auth.wiki/abac) คือโมเดลการควบคุมการเข้าถึงที่ใช้แอตทริบิวต์ (เช่น บทบาทผู้ใช้ คุณสมบัติของทรัพยากร และเงื่อนไขแวดล้อม) ในการตัดสินใจอนุญาตการเข้าถึง เป็นวิธีที่ยืดหยุ่นและไดนามิกในการจัดการการเข้าถึงทรัพยากรที่ได้รับการปกป้อง
+[การควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC)](https://auth.wiki/abac) เป็นโมเดลการควบคุมการเข้าถึงที่ใช้แอตทริบิวต์ (เช่น บทบาทผู้ใช้ คุณสมบัติของทรัพยากร และเงื่อนไขแวดล้อม) ในการตัดสินใจควบคุมการเข้าถึง เป็นวิธีที่ยืดหยุ่นและไดนามิกในการจัดการการเข้าถึงทรัพยากรที่ได้รับการปกป้อง
-สมมติว่าคุณกำลังสร้างแอป และการเปิดตัวแอปแบ่งเป็น 2 เฟส: เบต้าสาธารณะ และเปิดตัวอย่างเป็นทางการ แม้หลังจากแอปเปิดตัวอย่างเป็นทางการแล้ว คุณยังต้องการให้ผู้ใช้เก่าที่เข้าร่วมเบต้าสาธารณะสามารถใช้ฟีเจอร์แบบชำระเงินต่อไปได้
+สมมติว่าคุณกำลังสร้างแอป และการเปิดตัวแอปแบ่งเป็น 2 เฟส: เบต้าสาธารณะ และเปิดตัวอย่างเป็นทางการ แม้หลังจากแอปเปิดตัวอย่างเป็นทางการแล้ว คุณยังต้องการให้ผู้ใช้เก่าที่เคยเข้าร่วมเบต้าสาธารณะสามารถใช้ฟีเจอร์แบบชำระเงินต่อไปได้
-หลังจากแอปเปิดตัวอย่างเป็นทางการ คุณใช้ฟีเจอร์ [การควบคุมการเข้าถึงตามบทบาท (RBAC)](/authorization/role-based-access-control) ของ Logto เพื่อควบคุมการเข้าถึงฟีเจอร์แบบชำระเงิน เพื่อให้ตรวจสอบได้ง่ายว่าผู้ใช้เคยใช้แอปในช่วงเบต้าสาธารณะหรือไม่ คุณสามารถใช้เมธอด `getCustomJwtClaims()` เพื่อเพิ่มการอ้างสิทธิ์ชื่อ `createdAt` ลงใน payload ของโทเค็น
+หลังจากแอปเปิดตัวอย่างเป็นทางการ คุณใช้ฟีเจอร์ [การควบคุมการเข้าถึงตามบทบาท (RBAC)](/authorization/role-based-access-control) ของ Logto เพื่อควบคุมการเข้าถึงฟีเจอร์แบบชำระเงิน หากต้องการตรวจสอบได้ง่ายว่าผู้ใช้เคยใช้แอปในช่วงเบต้าสาธารณะหรือไม่ คุณสามารถใช้เมธอด `getCustomJwtClaims()` เพื่อเพิ่มการอ้างสิทธิ์ `createdAt` ใน payload ของโทเค็น
-จากนั้น เมื่อควบคุมการเข้าถึงใน API ที่ได้รับการปกป้องของคุณ คุณต้องอนุญาตโทเค็นการเข้าถึงที่ตรงตามเงื่อนไขใดเงื่อนไขหนึ่งต่อไปนี้:
+จากนั้น เมื่อควบคุมการเข้าถึงใน API ที่ได้รับการปกป้องของคุณ คุณต้องอนุญาตโทเค็นการเข้าถึงที่ตรงตามเงื่อนไขใดเงื่อนไขหนึ่งดังนี้:
-1. ในบริบทของ RBAC มีขอบเขต (scope) สำหรับเข้าถึงทรัพยากรแบบชำระเงิน
+1. ในบริบทของ RBAC มีขอบเขตสำหรับการเข้าถึงทรัพยากรแบบชำระเงิน
2. `createdAt` เกิดขึ้นก่อนเวลาสิ้นสุดของเฟสเบต้าสาธารณะ
หากไม่มีฟีเจอร์การอ้างสิทธิ์โทเค็นแบบกำหนดเอง เมื่อยืนยันสิทธิ์สำหรับ [การอนุญาต (Authorization)](/authorization) จำเป็นต้องเรียก Logto Management API เพื่อตรวจสอบว่าผู้ใช้ที่มีโทเค็นการเข้าถึงปัจจุบันมีสิทธิ์ตามบทบาทที่ API resource นั้นต้องการหรือไม่
-ในสถานการณ์คล้ายกัน สมมติว่าแอปของคุณจะแสดงคำอวยพรวันเกิดในหน้าลงชื่อเข้าใช้หากวันเกิดของผู้ใช้ใกล้เข้ามา คุณสามารถใช้การอ้างสิทธิ์โทเค็นแบบกำหนดเองเพื่อเพิ่มฟิลด์วันเกิดลงใน [payload ของโทเค็น](/user-management/personal-access-token#example-token-exchange) ซึ่งสามารถใช้ตัดสินใจว่าจะแสดงข้อความเฉพาะหรือไม่
+ในสถานการณ์คล้ายกัน สมมติว่าแอปของคุณแสดงคำอวยพรวันเกิดในหน้าลงชื่อเข้าใช้หากวันเกิดของผู้ใช้ใกล้จะถึง คุณสามารถใช้การอ้างสิทธิ์โทเค็นแบบกำหนดเองเพื่อเพิ่มฟิลด์วันเกิดลงใน [payload ของโทเค็น](/user-management/personal-access-token#example-token-exchange) ซึ่งสามารถใช้เพื่อตัดสินใจว่าจะแสดงข้อความเฉพาะหรือไม่
## บล็อกการออกโทเค็นด้วยตนเอง \{#manually-block-token-issuance}
-สมมติว่า Joe กำลังให้บริการเกมออนไลน์และใช้ Logto เป็นระบบ [การจัดการข้อมูลระบุตัวตนและการเข้าถึง (IAM)](https://auth.wiki/iam)
+สมมติว่า Joe กำลังดำเนินธุรกิจเกมออนไลน์และใช้ Logto เป็นระบบ [การจัดการข้อมูลระบุตัวตนและการเข้าถึง (IAM)](https://auth.wiki/iam)
-สมมติว่าเกมนี้ต้องเติมเงินเพื่อซื้อเวลาเล่นเกม Joe บันทึกยอดเงินของผู้ใช้แต่ละคนไว้ในบริการเกมของเขา และหักยอดเงินอย่างต่อเนื่องตามเวลาที่เล่นเกม Joe ต้องการบังคับให้ผู้เล่นออกจากระบบเมื่อยอดเงินหมด เพื่อกระตุ้นให้เติมเงิน
+สมมติว่าเกมนี้ต้องเติมเงินเพื่อซื้อเวลาเล่นเกม Joe บันทึกยอดเงินของผู้ใช้แต่ละคนไว้ในบริการเกมของเขา และหักยอดเงินอย่างต่อเนื่องเมื่อเวลาการเล่นเกมเพิ่มขึ้น Joe ต้องการบังคับให้ผู้เล่นออกจากระบบเมื่อยอดเงินในบัญชีหมด เพื่อกระตุ้นให้เติมเงิน
ในจุดนี้ Joe สามารถใช้ฟีเจอร์การอ้างสิทธิ์โทเค็นแบบกำหนดเองของ Logto เพื่อทำสิ่งนี้ได้:
1. ในสคริปต์ สามารถเรียก API ภายนอก [ดึงข้อมูลภายนอก](/developers/custom-token-claims/create-script/#step-3-fetch-external-data) เพื่อดึงยอดเงินปัจจุบันของผู้เล่นจากเซิร์ฟเวอร์เกมของ Joe
2. หากยอดเงินน้อยกว่าหรือเท่ากับ 0 สามารถใช้เมธอด [`api.denyAccess()`](/developers/custom-token-claims/create-script/#api) เพื่อบล็อกการออกโทเค็น
-ในขณะนี้ เมื่อไม่สามารถรับโทเค็นการเข้าถึงที่ถูกต้องใหม่ได้ ผู้เล่นจะถูกบังคับให้ออกจากระบบเกมทันที
+ในขณะนี้ เนื่องจากไม่สามารถรับโทเค็นการเข้าถึงที่ถูกต้องใหม่ได้ ผู้เล่นจะถูกบังคับให้ออกจากระบบเกมทันที
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx
index 95a07628bfe..90c97d943ee 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/custom-token-claims/create-script.mdx
@@ -1,35 +1,35 @@
---
id: create-script
-title: สร้างสคริปต์การอ้างสิทธิ์โทเค็นแบบกำหนดเอง
-sidebar_label: สร้างสคริปต์การอ้างสิทธิ์โทเค็นแบบกำหนดเอง
+title: สร้างสคริปต์โทเค็นการเข้าถึงแบบกำหนดเอง
+sidebar_label: สร้างสคริปต์โทเค็นการเข้าถึงแบบกำหนดเอง
sidebar_position: 3
---
-# สร้างสคริปต์การอ้างสิทธิ์โทเค็นแบบกำหนดเอง
+# สร้างสคริปต์โทเค็นการเข้าถึงแบบกำหนดเอง
-เพื่อ [เพิ่มการอ้างสิทธิ์แบบกำหนดเอง](/developers/custom-token-claims) ให้กับ [โทเค็นการเข้าถึง (Access token)](https://auth.wiki/access-token) คุณต้องเตรียมสคริปต์ที่คืนอ็อบเจกต์ซึ่งมีการอ้างสิทธิ์เหล่านั้น สคริปต์ควรเขียนเป็นฟังก์ชัน `JavaScript` ที่คืนอ็อบเจกต์ซึ่งมีการอ้างสิทธิ์แบบกำหนดเอง
+เพื่อ [เพิ่มการอ้างสิทธิ์ (claims) แบบกำหนดเอง](/developers/custom-token-claims) ให้กับ [โทเค็นการเข้าถึง (Access token)](https://auth.wiki/access-token) คุณต้องเตรียมสคริปต์ที่คืนอ็อบเจกต์ซึ่งมีการอ้างสิทธิ์เหล่านั้น สคริปต์ควรเขียนเป็นฟังก์ชัน `JavaScript` ที่คืนอ็อบเจกต์ซึ่งมีการอ้างสิทธิ์แบบกำหนดเอง
1. ไปที่ Console > Custom JWT
-2. มีโทเค็นการเข้าถึงสองประเภทที่คุณสามารถปรับแต่งการอ้างสิทธิ์ของโทเค็นได้:
+2. มีโทเค็นการเข้าถึง 2 ประเภทที่คุณสามารถปรับแต่งการอ้างสิทธิ์ได้:
- **โทเค็นการเข้าถึงของผู้ใช้ (User access token)**: โทเค็นการเข้าถึงที่ออกให้กับผู้ใช้ปลายทาง เช่น สำหรับแอปพลิเคชันเว็บหรือแอปมือถือ
- **โทเค็นการเข้าถึงแบบเครื่องต่อเครื่อง (Machine-to-Machine access token)**: โทเค็นการเข้าถึงที่ออกให้กับบริการหรือแอปพลิเคชัน เช่น สำหรับ [แอปพลิเคชันเครื่องต่อเครื่อง](/quick-starts/m2m)
- โทเค็นการเข้าถึงแต่ละประเภทอาจมีบริบท payload ของโทเค็นที่แตกต่างกัน คุณสามารถปรับแต่งการอ้างสิทธิ์ของโทเค็นแต่ละประเภทแยกกันได้
+ โทเค็นการเข้าถึงแต่ละประเภทอาจมีบริบท payload ที่แตกต่างกัน คุณสามารถปรับแต่งการอ้างสิทธิ์ของแต่ละประเภทแยกกันได้
- เลือกประเภทโทเค็นการเข้าถึงที่คุณต้องการปรับแต่งการอ้างสิทธิ์ แล้วคลิกปุ่ม **Add custom claims** เพื่อสร้างสคริปต์ใหม่
+ เลือกประเภทโทเค็นการเข้าถึงที่ต้องการปรับแต่ง แล้วคลิกปุ่ม **Add custom claims** เพื่อสร้างสคริปต์ใหม่
:::note
ฟีเจอร์การอ้างสิทธิ์โทเค็นแบบกำหนดเองนี้ใช้ได้เฉพาะกับ:
- ผู้ใช้ [Logto OSS](/logto-oss)
-- ผู้เช่า [Logto Cloud ที่มีสภาพแวดล้อมการพัฒนา](/logto-cloud/tenant-settings#development)
+- ผู้เช่า [Logto Cloud ที่มีสภาพแวดล้อมสำหรับการพัฒนา](/logto-cloud/tenant-settings#development)
- ผู้เช่า Logto Cloud แบบชำระเงินที่มีสภาพแวดล้อม production (รวมถึง [Pro tenants และ Enterprise tenants](https://logto.io/pricing))
:::
## สร้างฟังก์ชัน `getCustomJwtClaims()` \{#implement-getcustomjwtclaims-function}
-ในหน้า **Custom JWT** รายละเอียด คุณจะพบตัวแก้ไขสคริปต์สำหรับเขียนสคริปต์การอ้างสิทธิ์โทเค็นแบบกำหนดเอง สคริปต์ควรเป็นฟังก์ชัน `JavaScript` ที่คืนอ็อบเจกต์ของการอ้างสิทธิ์แบบกำหนดเอง
+ในหน้ารายละเอียด **Custom JWT** คุณจะพบตัวแก้ไขสคริปต์สำหรับเขียนสคริปต์การอ้างสิทธิ์โทเค็นแบบกำหนดเอง สคริปต์ควรเป็นฟังก์ชัน `JavaScript` ที่คืนอ็อบเจกต์ของการอ้างสิทธิ์แบบกำหนดเอง
{
@@ -46,10 +46,10 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
};
```
-ตัวแก้ไขนี้ใช้ JavaScript language server เพื่อให้ไฮไลต์ไวยากรณ์พื้นฐาน การเติมโค้ดอัตโนมัติ และการตรวจสอบข้อผิดพลาด พารามิเตอร์อินพุตถูกกำหนดชนิดและมีเอกสารประกอบในรูปแบบ jsDoc คุณสามารถใช้ IntelliSense ของตัวแก้ไขเพื่อเข้าถึงพร็อพเพอร์ตี้ของอ็อบเจกต์อินพุตได้อย่างถูกต้อง คุณสามารถดูรายละเอียดนิยามพารามิเตอร์ได้ทางด้านขวาของหน้า
+ตัวแก้ไขนี้ใช้ language server ของ JavaScript เพื่อให้ไฮไลต์ไวยากรณ์พื้นฐาน การเติมโค้ดอัตโนมัติ และการตรวจสอบข้อผิดพลาด พารามิเตอร์อินพุตถูกกำหนดชนิดและมีเอกสารประกอบในรูปแบบ jsDoc คุณสามารถใช้ IntelliSense ของตัวแก้ไขเพื่อเข้าถึงพร็อพเพอร์ตี้ของอ็อบเจกต์อินพุตได้อย่างถูกต้อง คุณสามารถดูรายละเอียดการกำหนดพารามิเตอร์ได้ทางด้านขวาของหน้า
:::note
-ฟังก์ชันนี้จะถูกส่งออกเป็นโมดูล ตรวจสอบให้แน่ใจว่าชื่อฟังก์ชันยังคงเป็น `getCustomJwtClaims` เพื่อให้โมดูลสามารถส่งออกฟังก์ชันได้อย่างถูกต้อง
+ฟังก์ชันนี้จะถูก export เป็นโมดูล ตรวจสอบให้แน่ใจว่าคุณใช้ชื่อฟังก์ชันว่า `getCustomJwtClaims` เพื่อให้โมดูลสามารถ export ฟังก์ชันนี้ได้อย่างถูกต้อง
:::
## ขั้นตอนที่ 2: พารามิเตอร์อินพุต \{#step-2-input-parameters}
@@ -60,45 +60,45 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
อ็อบเจกต์ payload ของโทเค็น อ็อบเจกต์นี้มีการอ้างสิทธิ์โทเค็นดั้งเดิมและเมตาดาต้าที่คุณอาจต้องเข้าถึงในสคริปต์
-คุณสามารถดูนิยามชนิดของอ็อบเจกต์ payload ของโทเค็นและอ็อบเจกต์ข้อมูลผู้ใช้ได้ทางด้านขวาของหน้า IntelliSense ของตัวแก้ไขจะช่วยให้คุณเข้าถึงพร็อพเพอร์ตี้เหล่านี้ได้อย่างถูกต้อง
+คุณสามารถดูการกำหนดชนิดของอ็อบเจกต์ payload ของโทเค็นและข้อมูลผู้ใช้ได้ทางด้านขวาของหน้า IntelliSense ของตัวแก้ไขจะช่วยให้คุณเข้าถึงพร็อพเพอร์ตี้เหล่านี้ได้อย่างถูกต้อง
- อ็อบเจกต์ข้อมูลโทเค็นการเข้าถึงของผู้ใช้
| พร็อพเพอร์ตี้ | คำอธิบาย | ชนิดข้อมูล |
| -------------------- | ------------------------------------------------ | ------------- |
- | `jti` | รหัส JWT ที่ไม่ซ้ำกัน | `string` |
+ | `jti` | รหัส JWT ที่ไม่ซ้ำ | `string` |
| `aud` | ผู้รับ (Audience) ของโทเค็น | `string` |
| `scope` | ขอบเขต (Scopes) ของโทเค็น | `string` |
- | `clientId` | รหัสไคลเอนต์ของโทเค็น | `string` |
+ | `clientId` | รหัส client ของโทเค็น | `string` |
| `accountId` | รหัสผู้ใช้ของโทเค็น | `string` |
- | `expiresWithSession` | โทเค็นจะหมดอายุตามเซสชันหรือไม่ | `boolean` |
+ | `expiresWithSession` | โทเค็นจะหมดอายุตาม session หรือไม่ | `boolean` |
| `grantId` | รหัส grant การยืนยันตัวตนปัจจุบันของโทเค็น | `string` |
| `gty` | ประเภท grant ของโทเค็น | `string` |
- | `kind` | ประเภทของโทเค็น | `AccessToken` |
+ | `kind` | ประเภทโทเค็น | `AccessToken` |
- อ็อบเจกต์ข้อมูลโทเค็นการเข้าถึงแบบเครื่องต่อเครื่อง
| พร็อพเพอร์ตี้ | คำอธิบาย | ชนิดข้อมูล |
| ---------- | -------------------------- | ------------------- |
- | `jti` | รหัส JWT ที่ไม่ซ้ำกัน | `string` |
+ | `jti` | รหัส JWT ที่ไม่ซ้ำ | `string` |
| `aud` | ผู้รับ (Audience) ของโทเค็น | `string` |
| `scope` | ขอบเขต (Scopes) ของโทเค็น | `string` |
- | `clientId` | รหัสไคลเอนต์ของโทเค็น | `string` |
- | `kind` | ประเภทของโทเค็น | `ClientCredentials` |
+ | `clientId` | รหัส client ของโทเค็น | `string` |
+ | `kind` | ประเภทโทเค็น | `ClientCredentials` |
### context (ใช้ได้เฉพาะกับโทเค็นการเข้าถึงของผู้ใช้) \{#context-only-available-for-user-access-token}
-อ็อบเจกต์ context มีข้อมูลผู้ใช้และข้อมูล grant ที่เกี่ยวข้องกับกระบวนการการอนุญาต (Authorization) ปัจจุบัน
+อ็อบเจกต์ context มีข้อมูลผู้ใช้และข้อมูล grant ที่เกี่ยวข้องกับกระบวนการอนุญาต (Authorization) ปัจจุบัน
- **อ็อบเจกต์ข้อมูลผู้ใช้**
- สำหรับโทเค็นการเข้าถึงของผู้ใช้ Logto ให้ context ข้อมูลผู้ใช้เพิ่มเติมสำหรับการเข้าถึง อ็อบเจกต์ข้อมูลผู้ใช้นี้มีข้อมูลโปรไฟล์ผู้ใช้และข้อมูลสมาชิกองค์กรทั้งหมดที่คุณอาจต้องใช้ในการตั้งค่าการอ้างสิทธิ์แบบกำหนดเอง โปรดดู [ผู้ใช้](/user-management/user-data) และ [องค์กร](/organizations/organization-management#organization-data-structure) สำหรับรายละเอียดเพิ่มเติม
+ สำหรับโทเค็นการเข้าถึงของผู้ใช้ Logto จะให้ context ข้อมูลผู้ใช้เพิ่มเติมสำหรับการเข้าถึง อ็อบเจกต์ข้อมูลผู้ใช้นี้มีข้อมูลโปรไฟล์ผู้ใช้และข้อมูลสมาชิกองค์กรทั้งหมดที่คุณอาจต้องใช้ในการตั้งค่าการอ้างสิทธิ์แบบกำหนดเอง โปรดดู [ผู้ใช้](/user-management/user-data) และ [องค์กร](/organizations/organization-management#organization-data-structure) สำหรับรายละเอียดเพิ่มเติม
- **อ็อบเจกต์ข้อมูล grant**
- สำหรับโทเค็นการเข้าถึงของผู้ใช้ที่ได้จากการแลกเปลี่ยนโทเค็นสวมรอย Logto ให้ context ข้อมูล grant เพิ่มเติมสำหรับการเข้าถึง อ็อบเจกต์ข้อมูล grant นี้มี context แบบกำหนดเองจาก subject token โปรดดู [การสวมรอยผู้ใช้](/developers/user-impersonation) สำหรับรายละเอียดเพิ่มเติม
+ สำหรับโทเค็นการเข้าถึงของผู้ใช้ที่ได้จากการแลกเปลี่ยนโทเค็นสวมรอย (impersonation token exchange) Logto จะให้ context ข้อมูล grant เพิ่มเติมสำหรับการเข้าถึง อ็อบเจกต์ข้อมูล grant นี้มี context แบบกำหนดเองจาก subject token โปรดดู [การสวมรอยผู้ใช้ (Impersonation)](/developers/user-impersonation) สำหรับรายละเอียดเพิ่มเติม
- **อ็อบเจกต์ข้อมูลการโต้ตอบของผู้ใช้**
- สำหรับโทเค็นการเข้าถึงของผู้ใช้ อาจมีกรณีที่คุณต้องเข้าถึงรายละเอียดการโต้ตอบของผู้ใช้สำหรับเซสชันการอนุญาตปัจจุบัน เช่น คุณอาจต้องดึงข้อมูลตัวตน SSO สำหรับองค์กรที่ผู้ใช้ใช้ในการลงชื่อเข้าใช้ อ็อบเจกต์ข้อมูลการโต้ตอบของผู้ใช้นี้มีข้อมูลการโต้ตอบล่าสุดที่ผู้ใช้ส่งมา รวมถึง:
+ สำหรับโทเค็นการเข้าถึงของผู้ใช้ อาจมีกรณีที่คุณต้องเข้าถึงรายละเอียดการโต้ตอบของผู้ใช้ใน session การอนุญาตปัจจุบัน เช่น คุณอาจต้องดึงข้อมูลตัวตน SSO ขององค์กรที่ใช้ในการลงชื่อเข้าใช้ อ็อบเจกต์ข้อมูลการโต้ตอบนี้มีข้อมูลการโต้ตอบล่าสุดที่ผู้ใช้ส่งมา รวมถึง:
- | พร็อพเพอร์ตี้ | คำอธิบาย | ชนิดข้อมูล |
- | --------------------- | ------------------------------------------------------------------------------------ | ------------------------ |
- | `interactionEvent` | เหตุการณ์การโต้ตอบของผู้ใช้ปัจจุบัน | `SignIn` หรือ `Register` |
- | `userId` | รหัสผู้ใช้ของการโต้ตอบปัจจุบัน | `string` |
- | `verificationRecords` | รายการบันทึกการยืนยันตัวตนที่ผู้ใช้ส่งมาเพื่อระบุตัวตนและยืนยันตัวตนระหว่างการโต้ตอบ | `VerificationRecord[]` |
+ | พร็อพเพอร์ตี้ | คำอธิบาย | ชนิดข้อมูล |
+ | --------------------- | ------------------------------------------------------------------------ | ------------------------ |
+ | `interactionEvent` | เหตุการณ์การโต้ตอบของผู้ใช้ปัจจุบัน | `SignIn` หรือ `Register` |
+ | `userId` | รหัสผู้ใช้ของการโต้ตอบปัจจุบัน | `string` |
+ | `verificationRecords` | รายการบันทึกการยืนยันตัวตนที่ผู้ใช้ส่งมาเพื่อยืนยันตัวตนระหว่างการโต้ตอบ | `VerificationRecord[]` |
ชนิดของบันทึกการยืนยันตัวตน:
@@ -227,16 +227,16 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
:::note
อาจมีบันทึกการยืนยันตัวตนหลายรายการในอ็อบเจกต์ข้อมูลการโต้ตอบของผู้ใช้ โดยเฉพาะเมื่อผู้ใช้ผ่านกระบวนการลงชื่อเข้าใช้หรือสมัครสมาชิกหลายครั้ง
- เช่น ผู้ใช้ลงชื่อเข้าใช้ด้วยบันทึก `Social` จากนั้นผูกอีเมลใหม่ผ่านบันทึก `EmailVerificationCode` และยืนยันสถานะ MFA ด้วยบันทึก `Totp` ในกรณีนี้ คุณอาจต้องจัดการบันทึกการยืนยันตัวตนทั้งหมดในสคริปต์ของคุณ
+ เช่น ผู้ใช้ลงชื่อเข้าใช้ด้วยบันทึก `Social` แล้วผูกอีเมลใหม่ผ่านบันทึก `EmailVerificationCode` และยืนยันสถานะ MFA ด้วยบันทึก `Totp` ในกรณีนี้ คุณอาจต้องจัดการบันทึกการยืนยันตัวตนทั้งหมดในสคริปต์ของคุณ
แต่ละประเภทของบันทึกการยืนยันตัวตนจะมีเพียงหนึ่งรายการในอ็อบเจกต์ข้อมูลการโต้ตอบของผู้ใช้
:::
### environmentVariables \{#environmentvariables}
-ใช้ส่วน **Set environment variables** ทางขวาเพื่อกำหนด environment variables สำหรับสคริปต์ของคุณ คุณสามารถใช้ตัวแปรเหล่านี้เพื่อเก็บข้อมูลสำคัญหรือข้อมูลการตั้งค่าที่คุณไม่ต้องการเขียนลงในสคริปต์โดยตรง เช่น API key, secret หรือ URL
+ใช้ส่วน **Set environment variables** ทางด้านขวาเพื่อกำหนด environment variables สำหรับสคริปต์ของคุณ คุณสามารถใช้ตัวแปรเหล่านี้เพื่อเก็บข้อมูลสำคัญหรือข้อมูลตั้งค่าที่ไม่ต้องการเขียนลงในสคริปต์โดยตรง เช่น API key, secret หรือ URL
-environment variables ทั้งหมดที่คุณตั้งค่าที่นี่จะสามารถใช้งานได้ในสคริปต์ ใช้อ็อบเจกต์ `environmentVariables` ในพารามิเตอร์อินพุตเพื่อเข้าถึงตัวแปรเหล่านี้
+ตัวแปร environment ทั้งหมดที่คุณตั้งค่าที่นี่จะสามารถใช้งานได้ในสคริปต์ ใช้อ็อบเจกต์ `environmentVariables` ในพารามิเตอร์อินพุตเพื่อเข้าถึงตัวแปรเหล่านี้
### api \{#api}
@@ -246,7 +246,7 @@ environment variables ทั้งหมดที่คุณตั้งค่
api.denyAccess(message?: string): void
```
-ฟังก์ชัน `api.denyAccess()` ช่วยให้คุณปฏิเสธกระบวนการออกโทเค็นพร้อมข้อความแบบกำหนดเอง คุณสามารถใช้ฟังก์ชันนี้เพื่อบังคับตรวจสอบการเข้าถึงเพิ่มเติมในกระบวนการออกโทเค็น
+ฟังก์ชัน `api.denyAccess()` ช่วยให้คุณปฏิเสธกระบวนการออกโทเค็นพร้อมข้อความที่กำหนดเอง คุณสามารถใช้ฟังก์ชันนี้เพื่อบังคับตรวจสอบการเข้าถึงเพิ่มเติมในกระบวนการออกโทเค็น
## ขั้นตอนที่ 3: ดึงข้อมูลภายนอก \{#step-3-fetch-external-data}
@@ -269,24 +269,24 @@ const getCustomJwtClaims = async ({ environmentVariables }) => {
```
:::note
-โปรดทราบ การดึงข้อมูลภายนอกอาจทำให้กระบวนการออกโทเค็นล่าช้า ตรวจสอบให้แน่ใจว่า API ภายนอกมีความน่าเชื่อถือและรวดเร็วเพียงพอต่อความต้องการของคุณ
+โปรดทราบ การดึงข้อมูลภายนอกอาจทำให้กระบวนการออกโทเค็นล่าช้า ตรวจสอบให้แน่ใจว่า API ภายนอกมีความน่าเชื่อถือและรวดเร็วเพียงพอสำหรับความต้องการของคุณ
นอกจากนี้:
-- จัดการข้อผิดพลาดและ timeout ในสคริปต์ของคุณอย่างเหมาะสมเพื่อป้องกันไม่ให้กระบวนการออกโทเค็นติดขัด
+- จัดการข้อผิดพลาดและ timeout ในสคริปต์ของคุณอย่างเหมาะสมเพื่อป้องกันไม่ให้กระบวนการออกโทเค็นถูกบล็อก
- ใช้ header การอนุญาตที่เหมาะสมเพื่อปกป้อง API ภายนอกของคุณจากการเข้าถึงโดยไม่ได้รับอนุญาต
:::
## ขั้นตอนที่ 4: ทดสอบสคริปต์ \{#step-4-test-the-script}
-อย่าลืมทดสอบสคริปต์ของคุณก่อนบันทึก คลิกที่แท็บ **Test context** ทางขวาของหน้าเพื่อแก้ไข mock token payload และ context ข้อมูลผู้ใช้สำหรับการทดสอบ
+อย่าลืมทดสอบสคริปต์ของคุณก่อนบันทึก คลิกที่แท็บ **Test context** ทางด้านขวาของหน้าเพื่อแก้ไข mock token payload และ context ข้อมูลผู้ใช้สำหรับการทดสอบ
-คลิก **Run test** ที่มุมขวาบนของตัวแก้ไขเพื่อรันสคริปต์ด้วย mock data ผลลัพธ์ของสคริปต์จะแสดงใน **Test Result** drawer
+คลิก **Run test** ที่มุมขวาบนของตัวแก้ไขเพื่อรันสคริปต์ด้วย mock data ผลลัพธ์ของสคริปต์จะแสดงใน drawer **Test Result**
:::note
-ผลลัพธ์การทดสอบคือ output ของฟังก์ชัน `getCustomJwtClaims` ที่ใช้ mock data ที่คุณตั้งค่า ("extra token claims" ที่ได้หลังจากจบขั้นตอนที่ 3 ใน [sequence diagram](/developers/custom-token-claims/#how-do-custom-token-claims-work)) ข้อมูล payload ของโทเค็นจริงและ context ข้อมูลผู้ใช้จะต่างออกไปเมื่อสคริปต์ถูกรันในกระบวนการออกโทเค็นจริง
+ผลลัพธ์การทดสอบคือ output ของฟังก์ชัน `getCustomJwtClaims` ที่ใช้ mock data ที่คุณตั้งค่า ("extra token claims" ที่ได้หลังจากจบขั้นตอนที่ 3 ใน [sequence diagram](/developers/custom-token-claims/#how-do-custom-token-claims-work)) ข้อมูล payload โทเค็นจริงและ context ข้อมูลผู้ใช้จะต่างออกไปเมื่อสคริปต์ถูกรันในกระบวนการออกโทเค็นจริง
:::
คลิกปุ่ม **Create** เพื่อบันทึกสคริปต์ สคริปต์การอ้างสิทธิ์โทเค็นแบบกำหนดเองจะถูกบันทึกและนำไปใช้กับกระบวนการออกโทเค็นการเข้าถึง
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index 664e168b0bc..955e8336385 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -2,18 +2,18 @@
id: sdk-conventions
title: แนวทางปฏิบัติของ Platform SDK
sidebar_label: แนวทางปฏิบัติของ Platform SDK
-sidebar_position: 7
+sidebar_position: 8
---
# แนวทางปฏิบัติของ Platform SDK
Logto ให้บริการการยืนยันตัวตนบนเว็บที่ทรงพลังและยืดหยุ่นมาก
-ในการใช้งาน Logto จริง เพื่อความสะดวก มักจำเป็นที่นักพัฒนาจะต้องผสานรวม SDK ของ Logto เข้ากับแอปพลิเคชันฝั่งลูกค้าของตนเอง เพื่อจัดการสถานะการลงชื่อเข้าใช้ของผู้ใช้ สิทธิ์ และอื่น ๆ
+ในการใช้งาน Logto จริง เพื่อความสะดวก มักจำเป็นที่นักพัฒนาจะต้องผสานรวม Logto SDK เข้ากับแอปพลิเคชันฝั่งลูกค้าของตนเอง เพื่อจัดการสถานะการลงชื่อเข้าใช้ของผู้ใช้, สิทธิ์ (permissions) และอื่น ๆ
-คุณสามารถค้นหา SDK สำหรับภาษาโปรแกรม / เฟรมเวิร์กทั้งหมดที่ Logto รองรับได้ [ที่นี่](/quick-starts)
+คุณสามารถค้นหา SDK สำหรับภาษา / เฟรมเวิร์กโปรแกรมมิ่งที่ Logto รองรับทั้งหมด [ได้ที่นี่](/quick-starts)
-หากคุณไม่พบ SDK ที่ต้องการ นี่คือแนวทางปฏิบัติที่คุณสามารถยึดถือเพื่อพัฒนา SDK สำหรับภาษาที่คุณต้องการ เพื่อให้ใช้งานบริการของ Logto ได้ง่ายขึ้น
+หากคุณไม่โชคดีและไม่พบ SDK ที่ต้องการ นี่คือแนวทางปฏิบัติที่คุณสามารถยึดถือเพื่อพัฒนา SDK สำหรับภาษาที่คุณต้องการ เพื่อให้ใช้งานบริการของ Logto ได้ง่ายขึ้น
แนวทางปฏิบัตินี้ประกอบด้วย 3 ส่วนหลัก:
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx
index 8ee4f640c09..3ce83454bbb 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/signing-keys.mdx
@@ -2,50 +2,50 @@
id: signing-keys
title: คีย์สำหรับลงนาม
sidebar_label: คีย์สำหรับลงนาม
-sidebar_position: 4
+sidebar_position: 5
---
# คีย์สำหรับลงนาม
[OIDC signing keys](https://auth.wiki/signing-key) ของ Logto หรือที่รู้จักกันในชื่อ "OIDC private keys" และ "OIDC cookie keys" คือคีย์สำหรับลงนามที่ใช้ในการลงนาม JWTs ([โทเค็นการเข้าถึง (Access tokens)](https://auth.wiki/access-token) และ [โทเค็น ID (ID tokens)](https://auth.wiki/id-token)) และคุกกี้ของเบราว์เซอร์ใน [เซสชันการลงชื่อเข้าใช้ (sign-in sessions)](/end-user-flows/sign-out#sign-in-session) ของ Logto คีย์สำหรับลงนามเหล่านี้จะถูกสร้างขึ้นเมื่อมีการ seed ฐานข้อมูล Logto ([โอเพ่นซอร์ส](/logto-oss)) หรือสร้าง tenant ใหม่ ([Cloud](/logto-cloud)) และสามารถจัดการได้ผ่าน [CLI](/logto-oss/using-cli) (โอเพ่นซอร์ส), Management APIs หรือ Console UI
-โดยปกติ Logto จะใช้ อัลกอริทึม elliptic curve (EC) ในการสร้างลายเซ็นดิจิทัล อย่างไรก็ตาม เนื่องจากผู้ใช้มักต้องตรวจสอบลายเซ็นของ JWT และเครื่องมือรุ่นเก่าหลายตัวไม่รองรับอัลกอริทึม EC (รองรับเฉพาะ RSA) เราจึงได้เพิ่มฟีเจอร์สำหรับการหมุนเวียนคีย์ส่วนตัว (private key rotation) และให้ผู้ใช้เลือกอัลกอริทึมสำหรับลายเซ็น (ทั้ง RSA และ EC) เพื่อให้แน่ใจว่าสามารถใช้งานร่วมกับบริการที่ใช้เครื่องมือตรวจสอบลายเซ็นรุ่นเก่าได้
+โดยปกติ Logto จะใช้ อัลกอริทึม elliptic curve (EC) ในการสร้างลายเซ็นดิจิทัล อย่างไรก็ตาม เนื่องจากผู้ใช้มักต้องตรวจสอบลายเซ็นของ JWT และเครื่องมือรุ่นเก่าหลายตัวไม่รองรับอัลกอริทึม EC (รองรับเฉพาะ RSA) เราจึงได้เพิ่มฟีเจอร์สำหรับหมุนคีย์ส่วนตัว (private key rotation) และให้ผู้ใช้เลือกอัลกอริทึมสำหรับลายเซ็น (ทั้ง RSA และ EC) เพื่อให้แน่ใจว่าสามารถใช้งานร่วมกับบริการที่ใช้เครื่องมือตรวจสอบลายเซ็นรุ่นเก่าได้
:::note
-ตามทฤษฎีแล้ว คีย์สำหรับลงนามไม่ควรถูกเปิดเผยและไม่มีวันหมดอายุ หมายความว่าไม่จำเป็นต้องหมุนเวียนคีย์ แต่การหมุนเวียนคีย์เป็นระยะหลังจากช่วงเวลาหนึ่งสามารถเพิ่มความปลอดภัยได้
+ตามทฤษฎีแล้ว คีย์สำหรับลงนามไม่ควรถูกเปิดเผยและไม่มีวันหมดอายุ หมายความว่าไม่จำเป็นต้องหมุนคีย์ แต่การหมุนคีย์เป็นระยะหลังจากใช้งานไปช่วงเวลาหนึ่งจะช่วยเพิ่มความปลอดภัย
:::
## ทำงานอย่างไร? \{#how-it-works}
- **OIDC private key**
- เมื่อเริ่มต้น Logto instance จะมีการสร้างคู่คีย์ public / private โดยอัตโนมัติและลงทะเบียนใน OIDC provider ที่อยู่เบื้องหลัง ดังนั้นเมื่อ Logto ออก JWT ใหม่ (โทเค็นการเข้าถึง หรือ โทเค็น ID) โทเค็นจะถูกลงนามด้วยคีย์ส่วนตัว ในขณะเดียวกัน แอปพลิเคชันไคลเอนต์ใด ๆ ที่ได้รับ JWT สามารถใช้คีย์สาธารณะที่จับคู่กันเพื่อตรวจสอบลายเซ็นของโทเค็น เพื่อให้แน่ใจว่าโทเค็นไม่ได้ถูกแก้ไขโดยบุคคลที่สาม คีย์ส่วนตัวจะถูกปกป้องบนเซิร์ฟเวอร์ Logto ส่วนคีย์สาธารณะตามชื่อคือสาธารณะสำหรับทุกคน และสามารถเข้าถึงได้ผ่านอินเทอร์เฟซ `/oidc/jwks` ของ OIDC endpoint สามารถระบุอัลกอริทึมของคีย์สำหรับลงนามได้ขณะสร้างคีย์ส่วนตัว โดย Logto จะใช้อัลกอริทึม EC (Elliptic Curve) เป็นค่าเริ่มต้น ผู้ดูแลระบบสามารถเปลี่ยนอัลกอริทึมเริ่มต้นเป็น RSA (Rivest-Shamir-Adleman) ได้โดยการหมุนเวียนคีย์ส่วนตัว
+ เมื่อเริ่มต้น Logto instance จะมีการสร้างคู่คีย์ public / private ขึ้นโดยอัตโนมัติ และลงทะเบียนไว้ใน OIDC provider ที่อยู่เบื้องหลัง ดังนั้นเมื่อ Logto ออก JWT ใหม่ (โทเค็นการเข้าถึง หรือ โทเค็น ID) โทเค็นจะถูกลงนามด้วยคีย์ส่วนตัว ในขณะเดียวกัน แอปพลิเคชันไคลเอนต์ใด ๆ ที่ได้รับ JWT สามารถใช้คีย์สาธารณะที่จับคู่กันเพื่อตรวจสอบลายเซ็นของโทเค็น เพื่อให้แน่ใจว่าโทเค็นไม่ได้ถูกแก้ไขโดยบุคคลที่สาม คีย์ส่วนตัวจะถูกปกป้องไว้บนเซิร์ฟเวอร์ Logto ส่วนคีย์สาธารณะตามชื่อคือสาธารณะสำหรับทุกคน และสามารถเข้าถึงได้ผ่านอินเทอร์เฟซ `/oidc/jwks` ของ OIDC endpoint สามารถระบุอัลกอริทึมสำหรับคีย์ลงนามได้ขณะสร้างคีย์ส่วนตัว โดย Logto จะใช้อัลกอริทึม EC (Elliptic Curve) เป็นค่าเริ่มต้น ผู้ดูแลระบบสามารถเปลี่ยนอัลกอริทึมเริ่มต้นเป็น RSA (Rivest-Shamir-Adleman) ได้โดยการหมุนคีย์ส่วนตัว
- **OIDC cookie key**
- เมื่อผู้ใช้เริ่มต้น flow การลงชื่อเข้าใช้หรือสมัครสมาชิก จะมีการสร้าง "OIDC session" บนเซิร์ฟเวอร์ พร้อมกับชุดคุกกี้ของเบราว์เซอร์ ด้วยคุกกี้เหล่านี้ เบราว์เซอร์สามารถร้องขอ Logto Experience API เพื่อดำเนินการโต้ตอบต่าง ๆ ในนามของผู้ใช้ เช่น ลงชื่อเข้าใช้ สมัครสมาชิก และรีเซ็ตรหัสผ่าน อย่างไรก็ตาม แตกต่างจาก JWT คุกกี้จะถูกลงนามและตรวจสอบโดยบริการ OIDC ของ Logto เองเท่านั้น ไม่จำเป็นต้องใช้การเข้ารหัสแบบอสมมาตร (asymmetric cryptography) ดังนั้นเราจึงไม่มีคีย์สาธารณะสำหรับคีย์ที่ใช้ลงนามคุกกี้ และไม่ใช้อัลกอริทึมการเข้ารหัสแบบอสมมาตร
+ เมื่อผู้ใช้เริ่มต้น flow การลงชื่อเข้าใช้หรือสมัครสมาชิก จะมีการสร้าง "OIDC session" บนเซิร์ฟเวอร์ พร้อมกับชุดคุกกี้ในเบราว์เซอร์ ด้วยคุกกี้เหล่านี้ เบราว์เซอร์สามารถร้องขอ Logto Experience API เพื่อดำเนินการต่าง ๆ ในนามของผู้ใช้ เช่น ลงชื่อเข้าใช้ สมัครสมาชิก และรีเซ็ตรหัสผ่าน อย่างไรก็ตาม แตกต่างจาก JWT คุกกี้จะถูกลงนามและตรวจสอบโดยบริการ OIDC ของ Logto เองเท่านั้น ไม่จำเป็นต้องใช้การเข้ารหัสแบบอสมมาตร (asymmetric cryptography) ดังนั้นเราจึงไม่มีคีย์สาธารณะคู่สำหรับคีย์ลงนามคุกกี้ และไม่ใช้อัลกอริทึมเข้ารหัสแบบอสมมาตร
-## หมุนเวียนคีย์สำหรับลงนามจาก Console UI \{#rotate-signing-keys-from-console-ui}
+## หมุนคีย์สำหรับลงนามจาก Console UI \{#rotate-signing-keys-from-console-ui}
-Logto มีฟีเจอร์ "Signing Keys Rotation" ซึ่งช่วยให้คุณสร้าง OIDC private key และ cookie key ใหม่ใน tenant ของคุณ
+Logto มีฟีเจอร์ "Signing Keys Rotation" ที่ช่วยให้คุณสร้าง OIDC private key และ cookie key ใหม่ใน tenant ของคุณ
-1. ไปที่ Console > คีย์สำหรับลงนาม จากนั้นคุณสามารถจัดการทั้ง OIDC private keys และ OIDC cookie keys ได้
-2. หากต้องการหมุนเวียนคีย์สำหรับลงนาม ให้คลิกปุ่ม "Rotate private keys" หรือ "Rotate cookie keys" เมื่อหมุนเวียนคีย์ส่วนตัว คุณสามารถเลือกอัลกอริทึมสำหรับลายเซ็นได้
+1. ไปที่ Console > คีย์สำหรับลงนาม จากที่นี่คุณสามารถจัดการทั้ง OIDC private keys และ OIDC cookie keys ได้
+2. หากต้องการหมุนคีย์สำหรับลงนาม ให้คลิกปุ่ม "Rotate private keys" หรือ "Rotate cookie keys" เมื่อหมุนคีย์ส่วนตัว คุณสามารถเลือกอัลกอริทึมสำหรับลายเซ็นได้
3. คุณจะพบตารางที่แสดงคีย์สำหรับลงนามทั้งหมดที่ใช้งานอยู่ หมายเหตุ: คุณสามารถลบคีย์ก่อนหน้าได้ แต่ไม่สามารถลบคีย์ปัจจุบันได้
- | สถานะ | คำอธิบาย |
- | -------- | ---------------------------------------------------------------------------------------------------- |
- | ปัจจุบัน | หมายถึงคีย์นี้กำลังถูกใช้งานอยู่ในแอปพลิเคชันและ API ของคุณ |
- | ก่อนหน้า | หมายถึงคีย์ที่เคยใช้งานมาก่อนแต่ถูกหมุนเวียนออกไปแล้ว โทเค็นที่ลงนามด้วยคีย์นี้ยังคงใช้งานได้ตามปกติ |
+ | สถานะ | คำอธิบาย |
+ | -------- | -------------------------------------------------------------------------------------------- |
+ | ปัจจุบัน | หมายถึงคีย์นี้กำลังถูกใช้งานอยู่ในแอปพลิเคชันและ API ของคุณ |
+ | ก่อนหน้า | หมายถึงคีย์ที่เคยใช้งานมาก่อนแต่ถูกหมุนออกไปแล้ว โทเค็นที่ลงนามด้วยคีย์นี้ยังคงใช้งานได้อยู่ |
-โปรดจำไว้ว่าการหมุนเวียนคีย์ประกอบด้วย 3 ขั้นตอนดังนี้:
+โปรดจำไว้ว่าการหมุนคีย์ประกอบด้วย 3 ขั้นตอนดังนี้:
-1. **สร้างคีย์สำหรับลงนามใหม่**: ซึ่งจะทำให้ **แอปพลิเคชัน** และ **API** ทั้งหมดของคุณต้องใช้คีย์สำหรับลงนามใหม่นี้
-2. **หมุนเวียนคีย์ปัจจุบัน**: คีย์ที่ใช้งานอยู่จะถูกกำหนดสถานะเป็น "ก่อนหน้า" หลังการหมุนเวียน และจะไม่ถูกใช้กับแอปพลิเคชันและ API ที่สร้างใหม่ อย่างไรก็ตาม โทเค็นที่ลงนามด้วยคีย์นี้ยังคงใช้งานได้
+1. **สร้างคีย์สำหรับลงนามใหม่**: แอปพลิเคชัน **และ** API ทั้งหมดของคุณจะต้องใช้คีย์สำหรับลงนามใหม่นี้
+2. **หมุนคีย์ปัจจุบัน**: คีย์ที่มีอยู่จะถูกกำหนดสถานะเป็น "ก่อนหน้า" หลังการหมุน และจะไม่ถูกใช้กับแอปพลิเคชันและ API ที่สร้างใหม่ อย่างไรก็ตาม โทเค็นที่ลงนามด้วยคีย์นี้จะยังคงใช้งานได้
3. **ลบคีย์ก่อนหน้าของคุณ**: คีย์ที่มีสถานะ "ก่อนหน้า" จะถูกเพิกถอนและลบออกจากตาราง
:::warning
-อย่าหมุนเวียนคีย์สำหรับลงนามติดต่อกัน (สองครั้งขึ้นไป) เพราะอาจทำให้โทเค็นที่ออกทั้งหมดไม่สามารถใช้งานได้
+ห้ามหมุนคีย์สำหรับลงนามติดต่อกัน (สองครั้งขึ้นไป) เพราะอาจทำให้โทเค็นที่ออกไปแล้ว **ทั้งหมด** ใช้งานไม่ได้
-- สำหรับผู้ใช้ OSS หลังจากหมุนเวียนคีย์สำหรับลงนามแล้ว ต้องรีสตาร์ท Logto instance เพื่อให้คีย์ใหม่มีผล
-- สำหรับผู้ใช้ Cloud คีย์สำหรับลงนามใหม่จะมีผลทันทีหลังการหมุนเวียน แต่โปรดตรวจสอบว่าไม่ได้หมุนเวียนคีย์สำหรับลงนามติดต่อกันหลายครั้ง
+- สำหรับผู้ใช้ OSS หลังจากหมุนคีย์สำหรับลงนามแล้ว ต้องรีสตาร์ท Logto instance เพื่อให้คีย์ใหม่มีผล
+- สำหรับผู้ใช้ Cloud คีย์สำหรับลงนามใหม่จะมีผลทันทีหลังการหมุน แต่โปรดอย่าหมุนคีย์สำหรับลงนามหลายครั้งติดต่อกัน
:::
## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources}
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx
index 9249671776d..831a3599f15 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/user-impersonation.mdx
@@ -2,16 +2,16 @@
id: user-impersonation
title: การสวมรอยผู้ใช้ (User impersonation)
sidebar_label: การสวมรอยผู้ใช้ (User impersonation)
-sidebar_position: 3
+sidebar_position: 4
---
import TokenExchangePrerequisites from './fragments/_token-exchange-prerequisites.mdx';
# การสวมรอยผู้ใช้ (User impersonation)
-ลองจินตนาการว่า Sarah วิศวกรฝ่ายสนับสนุนของ TechCorp ได้รับทิกเก็ตด่วนจาก Alex ลูกค้าที่ไม่สามารถเข้าถึงทรัพยากรสำคัญได้ เพื่อวินิจฉัยและแก้ไขปัญหาอย่างมีประสิทธิภาพ Sarah จำเป็นต้องเห็นสิ่งเดียวกับที่ Alex เห็นในระบบ นี่คือจุดที่ฟีเจอร์การสวมรอยผู้ใช้ของ Logto มีประโยชน์อย่างยิ่ง
+ลองจินตนาการว่า Sarah วิศวกรฝ่ายสนับสนุนที่ TechCorp ได้รับตั๋วแจ้งปัญหาด่วนจาก Alex ลูกค้าที่ไม่สามารถเข้าถึงทรัพยากรสำคัญได้ เพื่อวินิจฉัยและแก้ไขปัญหาอย่างมีประสิทธิภาพ Sarah จำเป็นต้องเห็นสิ่งเดียวกับที่ Alex เห็นในระบบ นี่คือจุดที่ฟีเจอร์การสวมรอยผู้ใช้ของ Logto มีประโยชน์อย่างยิ่ง
-การสวมรอยผู้ใช้ช่วยให้ผู้ใช้ที่ได้รับอนุญาต เช่น Sarah สามารถดำเนินการแทนผู้ใช้อื่น เช่น Alex ได้ชั่วคราวภายในระบบ ฟีเจอร์นี้ทรงพลังมากสำหรับการแก้ไขปัญหา การให้บริการลูกค้า และการดำเนินงานในฐานะผู้ดูแลระบบ
+การสวมรอยผู้ใช้ช่วยให้ผู้ใช้ที่ได้รับอนุญาต เช่น Sarah สามารถดำเนินการในระบบแทนผู้ใช้อื่น เช่น Alex ได้ชั่วคราว ฟีเจอร์นี้มีประโยชน์มากสำหรับการแก้ไขปัญหา การให้บริการลูกค้า และการดำเนินงานในฐานะผู้ดูแลระบบ
## ทำงานอย่างไร? \{#how-it-works}
@@ -35,14 +35,14 @@ sequenceDiagram
Note over Sarah,LogtoToken: แลก subject token เป็น access token
LogtoToken-->>Sarah: ส่งคืน access token
- Note over Sarah: ตอนนี้ Sarah สามารถเข้าถึงทรัพยากรในฐานะ Alex ได้แล้ว
+ Note over Sarah: Sarah สามารถเข้าถึงทรัพยากรในฐานะ Alex ได้แล้ว
```
กระบวนการสวมรอยประกอบด้วย 3 ขั้นตอนหลัก:
1. Sarah ขอสิทธิ์สวมรอยผ่าน backend server ของ TechCorp
2. เซิร์ฟเวอร์ของ TechCorp ขอ subject token จาก Logto Management API
-3. แอปของ Sarah แลก subject token นี้เป็นโทเค็นการเข้าถึง (access token)
+3. แอปของ Sarah แลก subject token นี้เป็น access token
มาดูกันว่า Sarah จะใช้ฟีเจอร์นี้เพื่อช่วยเหลือ Alex ได้อย่างไร
@@ -50,7 +50,7 @@ sequenceDiagram
ก่อนอื่น แอปสนับสนุนของ Sarah ต้องขอสิทธิ์สวมรอยจาก backend server ของ TechCorp
-**คำขอ (แอปของ Sarah ไปยังเซิร์ฟเวอร์ของ TechCorp)**
+**Request (แอปของ Sarah ไปยังเซิร์ฟเวอร์ของ TechCorp)**
```bash
POST /api/request-impersonation HTTP/1.1
@@ -60,18 +60,18 @@ Content-Type: application/json
{
"userId": "alex123",
- "reason": "Investigating resource access issue",
+ "reason": "กำลังตรวจสอบปัญหาการเข้าถึงทรัพยากร",
"ticketId": "TECH-1234"
}
```
-ใน API นี้ backend ควรตรวจสอบการอนุญาตอย่างเหมาะสมเพื่อให้แน่ใจว่า Sarah มีสิทธิ์ที่จำเป็นในการสวมรอย Alex
+ใน API นี้ backend ควรตรวจสอบสิทธิ์อย่างเหมาะสมเพื่อให้แน่ใจว่า Sarah มีสิทธิ์สวมรอย Alex
### ขั้นตอนที่ 2: ขอ subject token \{#step-2-obtaining-a-subject-token}
เมื่อเซิร์ฟเวอร์ของ TechCorp ตรวจสอบคำขอของ Sarah แล้ว จะเรียก [Management API](/integrate-logto/interact-with-management-api) ของ Logto เพื่อขอ subject token
-**คำขอ (เซิร์ฟเวอร์ของ TechCorp ไปยัง Logto Management API)**
+**Request (เซิร์ฟเวอร์ของ TechCorp ไปยัง Logto Management API)**
```bash
POST /api/subject-tokens HTTP/1.1
@@ -83,13 +83,13 @@ Content-Type: application/json
"userId": "alex123",
"context": {
"ticketId": "TECH-1234",
- "reason": "Resource access issue",
+ "reason": "ปัญหาการเข้าถึงทรัพยากร",
"supportEngineerId": "sarah789"
}
}
```
-**การตอบกลับ (Logto ไปยังเซิร์ฟเวอร์ของ TechCorp)**
+**Response (Logto ไปยังเซิร์ฟเวอร์ของ TechCorp)**
```json
{
@@ -98,9 +98,9 @@ Content-Type: application/json
}
```
-เซิร์ฟเวอร์ของ TechCorp ควรส่ง subject token นี้กลับไปยังแอปของ Sarah
+เซิร์ฟเวอร์ของ TechCorp ควรส่งคืน subject token นี้ให้กับแอปของ Sarah
-**การตอบกลับ (เซิร์ฟเวอร์ของ TechCorp ไปยังแอปของ Sarah)**
+**Response (เซิร์ฟเวอร์ของ TechCorp ไปยังแอปของ Sarah)**
```json
{
@@ -113,11 +113,11 @@ Content-Type: application/json
{
try {
// ขั้นตอนที่ 1 & 2: ขอสิทธิ์สวมรอยและรับ subject token
@@ -201,7 +201,7 @@ async function impersonateUser(
},
body: JSON.stringify({
userId,
- reason: 'Investigating resource access issue',
+ reason: 'กำลังตรวจสอบปัญหาการเข้าถึงทรัพยากร',
ticketId,
}),
}
@@ -215,7 +215,7 @@ async function impersonateUser(
// ขั้นตอนที่ 3: แลก subject token เป็น access token
// highlight-start
- // สำหรับเว็บแอปแบบดั้งเดิมหรือแอป M2M ใช้ Basic auth พร้อม client secret
+ // สำหรับเว็บแอปแบบดั้งเดิมหรือ M2M ใช้ Basic auth พร้อม client secret
// สำหรับ SPA หรือ native app ให้ใส่ client_id ใน body
const headers: Record = {
'Content-Type': 'application/x-www-form-urlencoded',
@@ -261,7 +261,7 @@ async function impersonateUser(
async function performImpersonation(): Promise {
try {
// highlight-start
- // สำหรับเว็บแอปแบบดั้งเดิมหรือแอป M2M ให้ส่ง client secret
+ // สำหรับเว็บแอปแบบดั้งเดิมหรือ M2M ให้ส่ง client secret
const accessToken = await impersonateUser(
'alex123',
'techcorp_support_app',
@@ -270,7 +270,7 @@ async function performImpersonation(): Promise {
'your-client-secret' // ไม่ต้องใส่สำหรับ SPA หรือ native app
);
// highlight-end
- console.log('โทเค็นการเข้าถึงสำหรับการสวมรอย Alex:', accessToken);
+ console.log('access token สำหรับสวมรอย Alex:', accessToken);
} catch (error) {
console.error('สวมรอยไม่สำเร็จ:', error);
}
@@ -283,18 +283,18 @@ void performImpersonation();
:::note
1. subject token มีอายุสั้นและใช้ได้เพียงครั้งเดียว
-2. โทเค็นการเข้าถึงสำหรับการสวมรอยจะไม่มี [refresh token](https://auth.wiki/refresh-token) หากหมดอายุ Sarah ต้องทำกระบวนการนี้ใหม่อีกครั้ง
-3. backend server ของ TechCorp ต้องตรวจสอบการอนุญาตอย่างเหมาะสมเพื่อให้แน่ใจว่าเฉพาะเจ้าหน้าที่สนับสนุนที่ได้รับอนุญาต เช่น Sarah เท่านั้นที่สามารถขอสวมรอยได้
+2. access token สำหรับการสวมรอยจะไม่มี [refresh token](https://auth.wiki/refresh-token) หากหมดอายุ Sarah ต้องทำขั้นตอนนี้ใหม่อีกครั้ง
+3. backend server ของ TechCorp ต้องตรวจสอบสิทธิ์อย่างเหมาะสมเพื่อให้แน่ใจว่าเฉพาะเจ้าหน้าที่สนับสนุนที่ได้รับอนุญาต เช่น Sarah เท่านั้นที่สามารถขอสิทธิ์สวมรอยได้
:::
## `act` claim \{#act-claim}
-เมื่อใช้ token exchange flow สำหรับการสวมรอย access token ที่ออกให้สามารถมี `act` (actor) claim เพิ่มเติมได้ claim นี้แสดงตัวตนของ “ผู้ดำเนินการ” — ในตัวอย่างนี้คือ Sarah ผู้ที่กำลังสวมรอย
+เมื่อใช้ token exchange flow สำหรับการสวมรอย access token ที่ออกมาอาจมี `act` (actor) claim เพิ่มเติม ซึ่งแสดงตัวตนของ “ผู้ดำเนินการ” — ในตัวอย่างนี้คือ Sarah ผู้ที่สวมรอย
-หากต้องการให้มี `act` claim แอปของ Sarah ต้องส่ง `actor_token` ในคำขอ token exchange โดย token นี้ควรเป็น access token ที่ถูกต้องของ Sarah พร้อมขอบเขต `openid` ตัวอย่างการใส่ในคำขอ:
+หากต้องการให้มี `act` claim แอปของ Sarah ต้องส่ง `actor_token` ในคำขอ token exchange โดย token นี้ควรเป็น access token ที่ถูกต้องของ Sarah พร้อม scope `openid` ตัวอย่างการใส่ในคำขอ:
-สำหรับเว็บแอปแบบดั้งเดิมหรือแอปเครื่องต่อเครื่อง:
+สำหรับเว็บแอปแบบดั้งเดิมหรือแอป machine-to-machine:
```bash
POST /oidc/token HTTP/1.1
@@ -330,7 +330,7 @@ grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&resource=https://api.techcorp.com/customer-data
```
-หากมีการส่ง `actor_token` โทเค็นการเข้าถึงที่ได้จะมี `act` claim เช่นนี้:
+หากมีการส่ง `actor_token` access token ที่ได้จะมี `act` claim ดังนี้:
```json
{
@@ -348,7 +348,7 @@ grant_type=urn:ietf:params:oauth:grant-type:token-exchange
## การปรับแต่ง token claims \{#customizing-token-claims}
-Logto อนุญาตให้คุณ [ปรับแต่ง token claims](/developers/custom-token-claims) สำหรับโทเค็นการสวมรอย ซึ่งมีประโยชน์สำหรับการเพิ่มข้อมูลบริบทหรือเมตาดาต้าเพิ่มเติม เช่น เหตุผลในการสวมรอยหรือหมายเลขทิกเก็ตที่เกี่ยวข้อง
+Logto อนุญาตให้คุณ [ปรับแต่ง token claims](/developers/custom-token-claims) สำหรับ token การสวมรอย ซึ่งมีประโยชน์สำหรับการเพิ่มข้อมูลบริบทหรือ metadata เพิ่มเติม เช่น เหตุผลในการสวมรอย หรือตั๋วสนับสนุนที่เกี่ยวข้อง
เมื่อเซิร์ฟเวอร์ของ TechCorp ขอ subject token จาก Logto Management API สามารถใส่ `context` object ได้ดังนี้:
@@ -357,13 +357,13 @@ Logto อนุญาตให้คุณ [ปรับแต่ง token claim
"userId": "alex123",
"context": {
"ticketId": "TECH-1234",
- "reason": "Resource access issue",
+ "reason": "ปัญหาการเข้าถึงทรัพยากร",
"supportEngineerId": "sarah789"
}
}
```
-[context](/developers/custom-token-claims/create-script#context-only-available-for-user-access-token) นี้สามารถนำไปใช้ในฟังก์ชัน `getCustomJwtClaims()` เพื่อเพิ่ม claim เฉพาะลงใน access token สุดท้าย ตัวอย่างเช่น:
+[context นี้](/developers/custom-token-claims/create-script#context-only-available-for-user-access-token) สามารถนำไปใช้ในฟังก์ชัน `getCustomJwtClaims()` เพื่อเพิ่ม claim เฉพาะลงใน access token สุดท้าย ตัวอย่างเช่น:
```tsx
const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
@@ -389,21 +389,21 @@ access token ที่ Sarah ได้รับอาจมีลักษณะ
"aud": "https://api.techcorp.com/customer-data",
"impersonation_context": {
"ticket_id": "TECH-1234",
- "reason": "Resource access issue",
+ "reason": "ปัญหาการเข้าถึงทรัพยากร",
"support_engineer": "sarah789"
}
// ... claim มาตรฐานอื่น ๆ
}
```
-ด้วยการปรับแต่ง access token claims แบบนี้ TechCorp สามารถใส่ข้อมูลสำคัญเกี่ยวกับบริบทการสวมรอย ช่วยให้ตรวจสอบและเข้าใจการดำเนินการสวมรอยในระบบได้ง่ายขึ้น
+ด้วยการปรับแต่ง access token claims แบบนี้ TechCorp สามารถใส่ข้อมูลสำคัญเกี่ยวกับบริบทการสวมรอย ทำให้ตรวจสอบและเข้าใจการสวมรอยในระบบได้ง่ายขึ้น
:::note
-โปรดระวังเมื่อเพิ่ม custom claim ลงในโทเค็นของคุณ หลีกเลี่ยงการใส่ข้อมูลสำคัญที่อาจก่อให้เกิดความเสี่ยงด้านความปลอดภัยหากโทเค็นถูกดักจับหรือรั่วไหล JWT จะถูกเซ็นชื่อแต่ไม่ถูกเข้ารหัส ดังนั้น claim จะมองเห็นได้สำหรับผู้ที่เข้าถึงโทเค็น
+โปรดระมัดระวังเมื่อเพิ่ม custom claim ลงใน token ของคุณ หลีกเลี่ยงการใส่ข้อมูลสำคัญที่อาจก่อให้เกิดความเสี่ยงด้านความปลอดภัยหาก token ถูกดักจับหรือรั่วไหล JWT จะถูกเซ็นชื่อแต่ไม่ได้เข้ารหัส ดังนั้น claim จะมองเห็นได้สำหรับผู้ที่เข้าถึง token
:::
## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources}
- การสวมรอยในโลกไซเบอร์และการจัดการเอกลักษณ์คืออะไร? AI agent ใช้ประโยชน์จากมันได้อย่างไร?
+ การสวมรอยในโลกไซเบอร์และการจัดการเอกลักษณ์คืออะไร? AI agent ใช้งานได้อย่างไร?
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx
index 20ce217bb10..576c8cd7776 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/developers/webhooks/README.mdx
@@ -1,37 +1,37 @@
---
-sidebar_position: 5
+sidebar_position: 6
---
# Webhook
-Logto [Webhook](https://auth.wiki/webhook) ให้การแจ้งเตือนแบบเรียลไทม์สำหรับเหตุการณ์ต่าง ๆ รวมถึงการเปลี่ยนแปลงบัญชีผู้ใช้, บทบาท (Role), สิทธิ์ (Permission), องค์กร (Organization), บทบาทขององค์กร, สิทธิ์ขององค์กร และ [การโต้ตอบของผู้ใช้](/end-user-flows)
+Logto [Webhook](https://auth.wiki/webhook) ให้การแจ้งเตือนแบบเรียลไทม์สำหรับเหตุการณ์ต่าง ๆ รวมถึงการเปลี่ยนแปลงบัญชีผู้ใช้, บทบาท (Roles), สิทธิ์ (Permissions), องค์กร (Organizations), บทบาทขององค์กร, สิทธิ์ขององค์กร และ [การโต้ตอบของผู้ใช้](/end-user-flows)
-เมื่อเกิดเหตุการณ์ Logto จะส่งคำขอ HTTP ไปยัง Endpoint URL ที่คุณกำหนด โดยมีข้อมูลรายละเอียดของเหตุการณ์ เช่น user ID, username, email และรายละเอียดอื่น ๆ ที่เกี่ยวข้อง (ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อมูลใน payload และ header ได้ที่ [Webhook request](/developers/webhooks/webhooks-request)) แอปพลิเคชันของคุณสามารถประมวลผลคำขอนี้และดำเนินการที่กำหนดเอง เช่น ส่งอีเมล หรืออัปเดตข้อมูลในฐานข้อมูล
+เมื่อเกิดเหตุการณ์ Logto จะส่ง HTTP request ไปยัง Endpoint URL ที่คุณกำหนด โดยมีข้อมูลรายละเอียดของเหตุการณ์ เช่น user ID, username, email และรายละเอียดอื่น ๆ ที่เกี่ยวข้อง (ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อมูลใน payload และ header ได้ที่ [Webhook request](/developers/webhooks/webhooks-request)) แอปพลิเคชันของคุณสามารถประมวลผล request นี้และดำเนินการที่กำหนดเอง เช่น ส่งอีเมล หรืออัปเดตข้อมูลในฐานข้อมูล
-เรายังคงเพิ่มเหตุการณ์ใหม่ ๆ ตามความต้องการของผู้ใช้ หากคุณมีความต้องการเฉพาะสำหรับธุรกิจของคุณ โปรดแจ้งให้เราทราบ
+เรายังคงเพิ่มเหตุการณ์ใหม่ ๆ ตามความต้องการของผู้ใช้ หากคุณมีความต้องการเฉพาะสำหรับธุรกิจของคุณ กรุณาแจ้งให้เราทราบ
## ทำไมต้องใช้ Webhook? \{#why-use-webhook}
-Webhook มอบการสื่อสารแบบเรียลไทม์ระหว่างแอปพลิเคชัน ช่วยลดความจำเป็นในการ polling และทำให้ข้อมูลอัปเดตทันที ช่วยให้การผสานระบบและการทำงานอัตโนมัติของแอปพลิเคชันง่ายขึ้นโดยไม่ต้องใช้โค้ดที่ซับซ้อนหรือ API เฉพาะทาง
+Webhook มอบการสื่อสารแบบเรียลไทม์ระหว่างแอปพลิเคชัน ช่วยลดความจำเป็นในการ polling และทำให้ข้อมูลอัปเดตทันที ช่วยให้การเชื่อมต่อแอปพลิเคชันและการทำงานอัตโนมัติของ workflow ง่ายขึ้นโดยไม่ต้องใช้โค้ดที่ซับซ้อนหรือ API เฉพาะทาง
ตัวอย่างการใช้งาน Webhook ที่พบบ่อยสำหรับ CIAM ได้แก่:
-- **ส่งอีเมล:** ตั้งค่า Webhook เพื่อส่งอีเมลต้อนรับผู้ใช้ใหม่เมื่อสมัครสมาชิก หรือแจ้งเตือนผู้ดูแลระบบเมื่อผู้ใช้ลงชื่อเข้าใช้จากอุปกรณ์หรือสถานที่ใหม่
-- **ส่งการแจ้งเตือน:** ตั้งค่า Webhook เพื่อเรียกผู้ช่วยเสมือนกับระบบ CRM ของคุณเพื่อให้การสนับสนุนลูกค้าแบบเรียลไทม์เมื่อผู้ใช้สมัครสมาชิก
-- **เรียก API เพิ่มเติม:** ตั้งค่า Webhook เพื่อตรวจสอบการเข้าถึงของผู้ใช้โดยเช็ค domain อีเมลหรือ IP address จากนั้นใช้ Logto Management API เพื่อกำหนดบทบาท (Role) และสิทธิ์ (Permission) ที่เหมาะสมกับทรัพยากร
-- **ซิงค์ข้อมูล:** ตั้งค่า Webhook เพื่อให้แอปพลิเคชันอัปเดตเกี่ยวกับการเปลี่ยนแปลง เช่น การระงับหรือการลบบัญชีผู้ใช้
-- **สร้างรายงาน:** ตั้งค่า Webhook เพื่อรับข้อมูลกิจกรรมการเข้าสู่ระบบของผู้ใช้และนำไปสร้างรายงานเกี่ยวกับการมีส่วนร่วม หรือรูปแบบการใช้งานของผู้ใช้
+- **ส่งอีเมล:** กำหนดค่า Webhook เพื่อส่งอีเมลต้อนรับให้ผู้ใช้ใหม่เมื่อสมัครสมาชิก หรือแจ้งเตือนผู้ดูแลระบบเมื่อผู้ใช้ลงชื่อเข้าใช้จากอุปกรณ์หรือสถานที่ใหม่
+- **ส่งการแจ้งเตือน:** กำหนดค่า Webhook เพื่อเรียกผู้ช่วยเสมือนกับระบบ CRM ของคุณ เพื่อให้บริการลูกค้าแบบเรียลไทม์เมื่อผู้ใช้สมัครสมาชิก
+- **เรียก API เพิ่มเติม:** กำหนดค่า Webhook เพื่อตรวจสอบการเข้าถึงของผู้ใช้โดยเช็ค domain อีเมลหรือ IP address จากนั้นใช้ Logto Management API เพื่อกำหนดบทบาทและสิทธิ์ทรัพยากรที่เหมาะสม
+- **ซิงโครไนซ์ข้อมูล:** กำหนดค่า Webhook เพื่อให้แอปพลิเคชันอัปเดตเกี่ยวกับการเปลี่ยนแปลง เช่น การระงับหรือการลบบัญชีผู้ใช้
+- **สร้างรายงาน:** ตั้งค่า Webhook เพื่อรับข้อมูลกิจกรรมการเข้าสู่ระบบของผู้ใช้และนำไปใช้สร้างรายงานเกี่ยวกับการมีส่วนร่วมของผู้ใช้หรือรูปแบบการใช้งาน
## คำศัพท์ \{#terms}
-| Item | Description |
-| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Event | เมื่อมีการดำเนินการเฉพาะ จะเกิด hook event ประเภทหนึ่งขึ้น เช่น Logto จะส่ง hook event ประเภท PostRegister เมื่อผู้ใช้ลงทะเบียนเสร็จและสร้างบัญชีใหม่ |
-| Hook | การกระทำหนึ่งหรือชุดของการกระทำที่ผูกกับเหตุการณ์เฉพาะ การกระทำอาจเป็นการเรียก API, รันโค้ด ฯลฯ |
-| Webhook | ประเภทหนึ่งของ hook ที่หมายถึงการเรียก API พร้อม payload ของเหตุการณ์ |
-| สมมติว่านักพัฒนาต้องการส่งการแจ้งเตือนเมื่อผู้ใช้ลงชื่อเข้าใช้ผ่านอุปกรณ์ใหม่ นักพัฒนาสามารถเพิ่ม webhook ที่เรียก API ของบริการรักษาความปลอดภัยของเขากับเหตุการณ์ PostSignIn ได้ |
+| Item | Description |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Event | เมื่อมีการกระทำเฉพาะ จะเกิด hook event ประเภทหนึ่งขึ้น เช่น Logto จะส่ง hook event ประเภท PostRegister เมื่อผู้ใช้สมัครสมาชิกเสร็จและสร้างบัญชีใหม่ |
+| Hook | การกระทำหนึ่งหรือหลายอย่างที่ hook กับ event เฉพาะ การกระทำอาจเป็นการเรียก API, รันโค้ด ฯลฯ |
+| Webhook | ประเภทหนึ่งของ hook ที่หมายถึงการเรียก API พร้อม payload ของ event |
+| สมมติว่านักพัฒนาต้องการส่งการแจ้งเตือนเมื่อผู้ใช้ลงชื่อเข้าใช้ผ่านอุปกรณ์ใหม่ นักพัฒนาสามารถเพิ่ม webhook ที่เรียก API ของบริการรักษาความปลอดภัยของเขากับ event PostSignIn ได้ |
-ตัวอย่างการเปิดใช้งาน webhook สองตัวสำหรับเหตุการณ์ `PostSignIn` ใน Logto:
+ตัวอย่างการเปิดใช้งาน web hook สองตัวสำหรับ event `PostSignIn` ใน Logto:
```mermaid
graph LR
@@ -63,11 +63,11 @@ graph LR
-### Logto รองรับ webhook แบบซิงค์หรือไม่? \{#does-logto-support-synced-webhooks}
+### Logto รองรับ synced webhook หรือไม่? \{#does-logto-support-synced-webhooks}
-แม้ว่า webhook แบบซิงค์จะทำให้ flow การลงชื่อเข้าใช้ของผู้ใช้ราบรื่นขึ้น แต่ขณะนี้เรายังไม่รองรับ (แต่จะรองรับในอนาคต) ดังนั้นกรณีที่ต้องพึ่งพา webhook แบบซิงค์ในปัจจุบันจึงต้องใช้วิธีแก้ไขอื่น หากคุณมีคำถามเพิ่มเติม โปรดติดต่อเรา
+แม้ว่า synced webhook จะช่วยให้ flow การลงชื่อเข้าใช้ของผู้ใช้ราบรื่นขึ้น แต่ขณะนี้เรายังไม่รองรับ (แต่จะรองรับในอนาคต) ดังนั้นกรณีที่ต้องพึ่งพา synced webhook ในปัจจุบันจำเป็นต้องใช้วิธีแก้ไขเฉพาะ หากมีคำถามเพิ่มเติมสามารถติดต่อเราได้
@@ -89,18 +89,18 @@ graph LR
-สำหรับ endpoint ที่รับ Webhook ควรตอบกลับด้วยรหัส 2xx ให้เร็วที่สุดเพื่อแจ้ง Logto ว่าได้รับ Webhook แล้ว เนื่องจากแต่ละผู้ใช้อาจมีตรรกะการประมวลผล Webhook ที่แตกต่างกัน งานที่ซับซ้อนมากอาจใช้เวลาหลายวินาที ทำให้ Webhook ของ Logto timeout แนวทางที่ดีที่สุดคือให้คุณมี event queue ของตัวเอง เมื่อได้รับ Webhook จาก Logto ให้นำเหตุการณ์ใส่ queue แล้วตอบกลับ 2xx กลับไป จากนั้นให้ worker ของคุณประมวลผลงานใน queue ทีละขั้นตอน หาก worker พบข้อผิดพลาด ให้จัดการที่เซิร์ฟเวอร์ของคุณเอง
+สำหรับ endpoint ที่รับ Webhook ควรตอบกลับด้วย 2xx response ให้เร็วที่สุดเพื่อแจ้ง Logto ว่าได้รับ Webhook แล้ว เนื่องจากแต่ละผู้ใช้อาจมีตรรกะการประมวลผล Webhook ที่แตกต่างกัน งานที่ซับซ้อนมากอาจใช้เวลาหลายวินาที ทำให้ Webhook ของ Logto timeout แนวปฏิบัติที่ดีที่สุดคือสร้าง event queue ของคุณเอง เมื่อได้รับ Webhook จาก Logto ให้ใส่ event ลงใน queue แล้วตอบกลับ 2xx response จากนั้นให้ worker ของคุณประมวลผลงานใน queue ทีละขั้นตอน หาก worker พบข้อผิดพลาด ให้จัดการที่เซิร์ฟเวอร์ของคุณเอง
-### Logto รองรับ webhook แบบซิงค์หรือไม่? \{#does-logto-support-synced-webhooks} +### Logto รองรับ synced webhook หรือไม่? \{#does-logto-support-synced-webhooks}
-แม้ว่า webhook แบบซิงค์จะทำให้ flow การลงชื่อเข้าใช้ของผู้ใช้ราบรื่นขึ้น แต่ขณะนี้เรายังไม่รองรับ (แต่จะรองรับในอนาคต) ดังนั้นกรณีที่ต้องพึ่งพา webhook แบบซิงค์ในปัจจุบันจึงต้องใช้วิธีแก้ไขอื่น หากคุณมีคำถามเพิ่มเติม โปรดติดต่อเรา +แม้ว่า synced webhook จะช่วยให้ flow การลงชื่อเข้าใช้ของผู้ใช้ราบรื่นขึ้น แต่ขณะนี้เรายังไม่รองรับ (แต่จะรองรับในอนาคต) ดังนั้นกรณีที่ต้องพึ่งพา synced webhook ในปัจจุบันจำเป็นต้องใช้วิธีแก้ไขเฉพาะ หากมีคำถามเพิ่มเติมสามารถติดต่อเราได้-### สามารถรับ IP address ของ client จาก webhook `PostSignIn` ได้หรือไม่? \{#can-i-get-the-client-ip-address-from-postsignin-webhooks} +### สามารถรับ client IP address จาก webhook `PostSignIn` ได้หรือไม่? \{#can-i-get-the-client-ip-address-from-postsignin-webhooks}
-ได้ คุณสามารถรับ IP address, user agent ฯลฯ ใน payload ของ Webhook หากคุณต้องการข้อมูลที่ยังไม่รองรับในปัจจุบัน สามารถสร้าง feature request ใน GitHub issues หรือ ติดต่อเรา +ได้ คุณสามารถรับ IP address, user agent ฯลฯ ใน payload ของ Webhook หากต้องการข้อมูลที่ยังไม่รองรับ สามารถสร้าง feature request ใน GitHub issues หรือ ติดต่อเรา
+
+ );
+}
+```
+
+### ขั้นตอนที่ 3: จัดการการเปลี่ยนเส้นทางสำเร็จ \{#step-3-handle-success-redirects}
+
+หลังจากผู้ใช้ดำเนินการเสร็จ จะถูกเปลี่ยนเส้นทางไปยัง URL ที่คุณระบุ พร้อมพารามิเตอร์ `show_success` (ถ้ามี) คุณสามารถใช้สิ่งนี้เพื่อแสดงข้อความสำเร็จ:
+
+```tsx
+function SettingsPage() {
+ const searchParams = new URLSearchParams(window.location.search);
+ const showSuccess = searchParams.get('show_success');
+
+ return (
+ การตั้งค่าบัญชีผู้ใช้
+ +
+ อีเมล: user@example.com
+ อัปเดตอีเมล
+
+
+
+ รหัสผ่าน: ••••••••
+ เปลี่ยนรหัสผ่าน
+
+
+
+ MFA: ยังไม่ได้ตั้งค่า
+
+ ตั้งค่าแอปยืนยันตัวตน
+
+
+
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## ข้อควรพิจารณาด้านความปลอดภัย \{#security-considerations}
+
+UI ศูนย์บัญชีผู้ใช้ที่สร้างไว้ล่วงหน้ามีมาตรการความปลอดภัยในตัว:
+
+- **การยืนยันตัวตน**: ก่อนเปลี่ยนแปลงข้อมูลสำคัญ (อีเมล, โทรศัพท์, รหัสผ่าน, MFA) ผู้ใช้ต้องยืนยันตัวตนด้วยรหัสผ่านปัจจุบันหรือวิธีการยืนยันที่มีอยู่
+- **รหัสยืนยัน**: การอัปเดตอีเมลและโทรศัพท์ต้องใช้รหัสยืนยันที่ส่งไปยังที่อยู่/หมายเลขใหม่
+- **การตรวจสอบเซสชัน**: ทุกการดำเนินการจะตรวจสอบเซสชันของผู้ใช้เพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต
+
+## ตัวเลือกการปรับแต่ง \{#customization-options}
+
+UI ศูนย์บัญชีผู้ใช้ที่สร้างไว้ล่วงหน้าจะรับการตั้งค่าแบรนด์จากการตั้งค่าประสบการณ์การลงชื่อเข้าใช้ของคุณ รวมถึง:
+
+- โลโก้และสี
+- โหมดมืด / สว่าง
+- การตั้งค่าภาษา
+
+หากคุณต้องการปรับแต่งมากกว่าที่ UI สำเร็จรูปนี้ให้ได้ แนะนำให้ใช้ [Account API](/end-user-flows/account-settings/by-account-api) เพื่อสร้างหน้าจัดการบัญชีของคุณเอง
+
+## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources}
+
+- [การตั้งค่าบัญชีผู้ใช้ด้วย Account API](/end-user-flows/account-settings/by-account-api) - สร้างการจัดการบัญชีแบบกำหนดเองด้วยการควบคุม API เต็มรูปแบบ
+- [การตั้งค่าบัญชีผู้ใช้ด้วย Management API](/end-user-flows/account-settings/by-management-api) - การจัดการบัญชีในระดับผู้ดูแลระบบ
+- [การตั้งค่า MFA](/end-user-flows/mfa) - ตั้งค่าการยืนยันตัวตนหลายปัจจัย (MFA)
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/introduction/README.mdx
index abcc4021b20..a79eb71f570 100644
--- a/i18n/th/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/th/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -1,5 +1,5 @@
---
-description: เปิดตัวระบบจัดการเอกลักษณ์และการเข้าถึงของคุณอย่างรวดเร็วด้วยการผสาน Logto สนุกกับการยืนยันตัวตน (Authentication), การอนุญาต (Authorization) และการจัดการหลายผู้เช่า (multi-tenant) ในที่เดียว
+description: เปิดตัวระบบจัดการเอกลักษณ์และการเข้าถึงของคุณอย่างรวดเร็วด้วยการผสาน Logto สนุกกับการยืนยันตัวตน (Authentication), การอนุญาต (Authorization), และการจัดการหลายผู้เช่า (multi-tenant) ในที่เดียว
---
import AuditLogIcon from '@site/src/assets/audit-log.svg';
@@ -32,7 +32,7 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
# แนะนำ
-ยินดีต้อนรับสู่เอกสาร Logto! Logto คือโซลูชันการจัดการเอกลักษณ์และการเข้าถึง (IAM) ที่ออกแบบมาสำหรับแอปสมัยใหม่และผลิตภัณฑ์ SaaS โดยมอบระบบการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) ที่ปลอดภัย ขยายได้ และปรับแต่งได้สำหรับแอปพลิเคชันของคุณ
+ยินดีต้อนรับสู่เอกสาร Logto! Logto คือโซลูชันการจัดการเอกลักษณ์และการเข้าถึง (IAM) ที่ออกแบบมาสำหรับแอปสมัยใหม่และผลิตภัณฑ์ SaaS โดยให้ระบบการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) ที่ปลอดภัย ขยายได้ และปรับแต่งได้สำหรับแอปพลิเคชันของคุณ
## สำรวจตามฟีเจอร์ \{#explore-by-features}
@@ -143,6 +143,10 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
icon: อัปเดตอีเมลเรียบร้อยแล้ว!
}
+ {showSuccess === 'password' && เปลี่ยนรหัสผ่านเรียบร้อยแล้ว!
}
+ {/* ... ส่วนอื่น ๆ ของหน้าตั้งค่า */}
+ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index 73c0f8b9fd4..d4f40c52a8b 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -1,81 +1,87 @@ -นี่คือรายการขอบเขต (scopes) ที่รองรับและการอ้างสิทธิ์ (claims) ที่เกี่ยวข้อง: +นี่คือรายการขอบเขต (Scopes) ที่รองรับและการอ้างสิทธิ์ (Claims) ที่เกี่ยวข้อง: -**`openid`** +### ขอบเขต OIDC มาตรฐาน {#standard-oidc-scopes} -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | -| ----------------- | -------- | ------------------------- | ----------------- | -| sub | `string` | ตัวระบุที่ไม่ซ้ำของผู้ใช้ | ไม่ | +**`openid`** (ค่าเริ่มต้น) -**`profile`** +| Claim name | Type | คำอธิบาย | +| ---------- | -------- | ------------------------- | +| sub | `string` | ตัวระบุที่ไม่ซ้ำของผู้ใช้ | -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | -| ----------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | -| name | `string` | ชื่อเต็มของผู้ใช้ | ไม่ | -| username | `string` | ชื่อผู้ใช้ของผู้ใช้ | ไม่ | -| picture | `string` | URL ของรูปโปรไฟล์ของผู้ใช้ปลายทาง (End-User) URL นี้ **ต้อง** อ้างอิงถึงไฟล์รูปภาพ (เช่น ไฟล์ PNG, JPEG หรือ GIF) ไม่ใช่หน้าเว็บที่มีรูปภาพ โปรดทราบว่า URL นี้ **ควร** อ้างอิงถึงรูปโปรไฟล์ของผู้ใช้ปลายทางที่เหมาะสมสำหรับแสดงเมื่ออธิบายผู้ใช้ปลายทาง ไม่ใช่รูปภาพใด ๆ ที่ผู้ใช้ถ่ายมา | ไม่ | -| created_at | `number` | เวลาที่สร้างผู้ใช้ปลายทาง เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | ไม่ | -| updated_at | `number` | เวลาที่ข้อมูลของผู้ใช้ปลายทางถูกอัปเดตล่าสุด เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | ไม่ | +**`profile`** (ค่าเริ่มต้น) -[การอ้างสิทธิ์มาตรฐาน](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) อื่น ๆ เช่น `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, และ `locale` จะถูกรวมอยู่ในขอบเขต `profile` ด้วย โดยไม่จำเป็นต้องร้องขอ endpoint userinfo ความแตกต่างเมื่อเทียบกับการอ้างสิทธิ์ข้างต้นคือ การอ้างสิทธิ์เหล่านี้จะถูกส่งกลับเมื่อค่าของมันไม่ว่างเปล่าเท่านั้น ในขณะที่การอ้างสิทธิ์ข้างต้นจะส่งกลับ `null` หากค่าของมันว่างเปล่า +| Claim name | Type | คำอธิบาย | +| ---------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| name | `string` | ชื่อเต็มของผู้ใช้ | +| username | `string` | ชื่อผู้ใช้ของผู้ใช้ | +| picture | `string` | URL ของรูปโปรไฟล์ผู้ใช้ปลายทาง (End-User) URL นี้ต้องชี้ไปที่ไฟล์รูปภาพ (เช่น PNG, JPEG, หรือ GIF) ไม่ใช่หน้าเว็บที่มีรูปภาพ โปรดทราบว่า URL นี้ควรอ้างอิงถึงรูปโปรไฟล์ของผู้ใช้ปลายทางโดยเฉพาะ เหมาะสำหรับแสดงเมื่ออธิบายผู้ใช้ปลายทาง ไม่ใช่รูปภาพใด ๆ ที่ผู้ใช้ถ่ายมาโดยพลการ | +| created_at | `number` | เวลาที่สร้างผู้ใช้ปลายทาง เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | +| updated_at | `number` | เวลาที่ข้อมูลของผู้ใช้ปลายทางถูกอัปเดตล่าสุด เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | + +[การอ้างสิทธิ์มาตรฐาน](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) อื่น ๆ เช่น `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, และ `locale` จะถูกรวมอยู่ในขอบเขต `profile` โดยไม่จำเป็นต้องร้องขอ endpoint userinfo ความแตกต่างเมื่อเทียบกับการอ้างสิทธิ์ข้างต้นคือ การอ้างสิทธิ์เหล่านี้จะถูกส่งกลับเมื่อค่าของมันไม่ว่างเปล่าเท่านั้น ในขณะที่การอ้างสิทธิ์ข้างต้นจะส่งกลับ `null` หากค่าของมันว่างเปล่า :::note -ต่างจากการอ้างสิทธิ์มาตรฐาน การอ้างสิทธิ์ `created_at` และ `updated_at` ใช้หน่วยมิลลิวินาทีแทนที่จะเป็นวินาที +ต่างจากการอ้างสิทธิ์มาตรฐาน การอ้างสิทธิ์ `created_at` และ `updated_at` ใช้หน่วยเป็นมิลลิวินาทีแทนที่จะเป็นวินาที ::: **`email`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | -| ----------------- | --------- | ------------------------------- | ----------------- | -| email | `string` | อีเมลของผู้ใช้ | ไม่ | -| email_verified | `boolean` | อีเมลได้รับการยืนยันแล้วหรือไม่ | ไม่ | +| Claim name | Type | คำอธิบาย | +| -------------- | --------- | ------------------------------- | +| email | `string` | อีเมลของผู้ใช้ | +| email_verified | `boolean` | อีเมลได้รับการยืนยันแล้วหรือไม่ | **`phone`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | -| --------------------- | --------- | ----------------------------------------- | ----------------- | -| phone_number | `string` | หมายเลขโทรศัพท์ของผู้ใช้ | ไม่ | -| phone_number_verified | `boolean` | หมายเลขโทรศัพท์ได้รับการยืนยันแล้วหรือไม่ | ไม่ | +| Claim name | Type | คำอธิบาย | +| --------------------- | --------- | ----------------------------------------- | +| phone_number | `string` | หมายเลขโทรศัพท์ของผู้ใช้ | +| phone_number_verified | `boolean` | หมายเลขโทรศัพท์ได้รับการยืนยันแล้วหรือไม่ | **`address`** -โปรดดูรายละเอียดของการอ้างสิทธิ์ที่อยู่ได้ที่ [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) +โปรดดูรายละเอียดของการอ้างสิทธิ์ address ได้ที่ [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) + +:::info +ขอบเขตที่มีเครื่องหมาย **(ค่าเริ่มต้น)** จะถูกร้องขอโดย Logto SDK เสมอ การอ้างสิทธิ์ภายใต้ขอบเขต OIDC มาตรฐานจะถูกรวมอยู่ในโทเค็น ID เสมอเมื่อมีการร้องขอขอบเขตที่เกี่ยวข้อง — ไม่สามารถปิดการใช้งานได้ +::: + +### ขอบเขตเพิ่มเติม {#extended-scopes} + +ขอบเขตต่อไปนี้ถูกขยายโดย Logto และจะส่งคืนการอ้างสิทธิ์ผ่าน [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) การอ้างสิทธิ์เหล่านี้สามารถตั้งค่าให้ถูกรวมอยู่ในโทเค็น ID ได้โดยตรงผ่าน
-โดยสรุป เมื่อคุณร้องขอขอบเขต (scope) ใด คุณจะได้รับข้อมูลการอ้างสิทธิ์ (claim) ที่เกี่ยวข้องในข้อมูลผู้ใช้ เช่น หากคุณร้องขอขอบเขต `email` คุณจะได้รับข้อมูล `email` และ `email_verified` ของผู้ใช้ +โดยสรุป เมื่อคุณร้องขอขอบเขต (scope) ใด คุณจะได้รับการอ้างสิทธิ์ (claim) ที่เกี่ยวข้องในข้อมูลผู้ใช้ เช่น หากคุณร้องขอขอบเขต `email` คุณจะได้รับข้อมูล `email` และ `email_verified` ของผู้ใช้
- โดยปกติ Logto SDK จะร้องขอขอบเขตสามรายการเสมอ: `openid`, `profile` และ `offline_access` - และไม่สามารถลบขอบเขตเริ่มต้นเหล่านี้ได้ แต่คุณสามารถเพิ่มขอบเขตเพิ่มเติมขณะกำหนดค่า Logto ได้: + โดยค่าเริ่มต้น Logto SDK จะร้องขอขอบเขตสามรายการเสมอ: `openid`, `profile` และ `offline_access` + และไม่สามารถลบขอบเขตเริ่มต้นเหล่านี้ได้ แต่คุณสามารถเพิ่มขอบเขตเพิ่มเติมได้เมื่อกำหนดค่า Logto:
{props.configScopesCode} diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/README.mdx index b85c5a81d79..771786e024b 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -1,8 +1,8 @@ # 开发者 -Logto 是一个基于 [OAuth 2](https://auth.wiki/oauth-2.0) 和 [OIDC](https://auth.wiki/openid-connect) 协议的 [身份与访问管理 (IAM)](https://auth.wiki/iam) 服务。像 Logto 这样的 IAM 服务通常作为其他 Web 服务的基础；这些 Web 服务中的各种授权 (Authorization) 状态会直接受到 Logto 的影响。 +Logto 是一个基于 [OAuth 2](https://auth.wiki/oauth-2.0) 和 [OIDC](https://auth.wiki/openid-connect) 协议的 [身份和访问管理 (IAM)](https://auth.wiki/iam) 服务。像 Logto 这样的 IAM 服务通常作为其他 Web 服务的基础；这些 Web 服务中的各种授权 (Authorization) 状态会直接受到 Logto 的影响。 -为了为用户提供便利，Logto 提供了一系列常用的开发者功能。 +为了方便用户，Logto 提供了一系列常用的开发者功能。 ## 登录体验相关 \{#sign-in-experience-related} @@ -19,9 +19,18 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: '自定义令牌声明 (Custom token claims)', + label: '自定义访问令牌 (Access token)', href: '/developers/custom-token-claims', - description: '通过附加额外的声明 (Claims)，扩展访问控制能力，可实现 ABAC 或拒绝令牌 (Token) 签发。', + description: '使用自定义脚本为访问令牌 (Access token) 添加额外声明 (Claims)，实现 ABAC 或拒绝令牌 (Token) 签发。', + customProps: { + icon:生成原始访问令牌负载 + IdP-->>IdP: 验证凭据 &
生成原始访问令牌负载 rect var(--mermaid-rect-fill) - note over IdP: 自定义令牌声明 + note over IdP: 自定义令牌声明 (Claims) IdP->>IdP: 运行自定义令牌声明脚本（`getCustomJwtClaims`）&
获取额外令牌声明 end IdP-->>IdP: 合并原始访问令牌负载和额外令牌声明 @@ -48,11 +48,11 @@ sequenceDiagram ``` :::warning -Logto 内置令牌声明不可被覆盖或修改。自定义声明将作为附加声明添加到令牌中。如果任何自定义声明与内置声明冲突，这些自定义声明将被忽略。 +Logto 内置令牌声明 (Claims) 不能被覆盖或修改。自定义声明 (Claims) 会作为附加声明添加到令牌中。如果任何自定义声明与内置声明冲突，这些自定义声明将被忽略。 ::: ## 相关资源 \{#related-resources}
+
## 步骤 1：编辑脚本 \{#step-1-edit-the-script}
-使用左侧的代码编辑器修改脚本。系统为你提供了一个默认返回空对象的 `getCustomJwtClaims`，你可以在此基础上修改函数以返回你自己的自定义声明对象。
+使用左侧的代码编辑器修改脚本。系统为你提供了一个默认返回空对象的 `getCustomJwtClaims`，你可以在此基础上修改函数以返回你自己的自定义声明 (Claims) 对象。
```jsx
const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
@@ -43,21 +43,21 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
};
```
-该编辑器使用 JavaScript 语言服务，提供基础语法高亮、代码补全和错误检查。输入参数类型良好，并采用 jsDoc 风格文档。你可以使用编辑器的智能提示 (IntelliSense) 正确访问输入对象的属性。详细的参数定义可在页面右侧查看。
+该编辑器使用 JavaScript 语言服务，提供基础语法高亮、代码补全和错误检查。输入参数类型良好，并采用 jsDoc 风格文档。你可以利用编辑器的 IntelliSense 正确访问输入对象的属性。详细的参数定义可在页面右侧查看。
:::note
-此函数将作为模块导出。请确保函数名保持为 `getCustomJwtClaims`，以便模块能正确导出该函数。
+该函数将作为模块导出。请确保函数名保持为 `getCustomJwtClaims`，以便模块正确导出该函数。
:::
## 步骤 2：输入参数 \{#step-2-input-parameters}
-`getCustomJwtClaims` 函数接收一个对象作为输入参数。该输入对象包含以下属性：
+`getCustomJwtClaims` 函数以一个对象作为输入参数。该输入对象包含以下属性：
### token \{#token}
令牌负载对象。该对象包含原始令牌声明 (Claims) 和你可能需要在脚本中访问的元数据。
-你可以在页面右侧找到令牌负载对象和用户数据对象的详细类型定义。编辑器的智能提示 (IntelliSense) 也会帮助你正确访问输入对象的这些属性。
+你可以在页面右侧找到令牌负载对象和用户数据对象的详细类型定义。编辑器的 IntelliSense 也会帮助你正确访问输入对象的这些属性。
- 用户访问令牌 (User access token) 数据对象
| 属性 | 描述 | 类型 |
@@ -65,8 +65,8 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
| `jti` | 唯一 JWT id | `string` |
| `aud` | 令牌受众 (Audience) | `string` |
| `scope` | 令牌权限 (Scopes) | `string` |
- | `clientId` | 令牌的客户端 id | `string` |
- | `accountId` | 令牌的用户 id | `string` |
+ | `clientId` | 令牌客户端 id | `string` |
+ | `accountId` | 令牌用户 id | `string` |
| `expiresWithSession` | 令牌是否随会话过期 | `boolean` |
| `grantId` | 令牌当前认证 (Authentication) 授权 id | `string` |
| `gty` | 令牌授权类型 | `string` |
@@ -77,23 +77,23 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
| `jti` | 唯一 JWT id | `string` |
| `aud` | 令牌受众 (Audience) | `string` |
| `scope` | 令牌权限 (Scopes) | `string` |
- | `clientId` | 令牌的客户端 id | `string` |
+ | `clientId` | 令牌客户端 id | `string` |
| `kind` | 令牌类型 | `ClientCredentials` |
### context（仅用户访问令牌 (User access token) 可用）\{#context-only-available-for-user-access-token}
-context 对象包含与当前授权 (Authorization) 流程相关的用户数据和授权数据。
+context 对象包含与当前授权 (Authorization) 过程相关的用户数据和授权数据。
- **用户数据对象**
- 对于用户访问令牌 (User access token)，Logto 提供了额外的用户数据上下文供你访问。用户数据对象包含你设置自定义声明时可能需要的所有用户资料数据和组织 (Organization) 成员数据。请参阅 [用户](/user-management/user-data) 和 [组织 (Organizations)](/organizations/organization-management#organization-data-structure) 获取更多信息。
+ 对于用户访问令牌 (User access token)，Logto 提供了额外的用户数据上下文供你访问。用户数据对象包含你设置自定义声明 (Claims) 可能需要的所有用户资料数据和组织 (Organization) 成员数据。详见 [用户](/user-management/user-data) 和 [组织 (Organizations)](/organizations/organization-management#organization-data-structure)。
- **授权数据对象**
- 对于通过模拟 (Impersonation) 令牌交换获得的用户访问令牌 (User access token)，Logto 提供了额外的授权数据上下文供你访问。授权数据对象包含来自主体 (Subject) 令牌的自定义上下文。详情请参阅 [用户模拟 (User impersonation)](/developers/user-impersonation)。
+ 对于通过模拟 (Impersonation) 令牌交换获得的用户访问令牌 (User access token)，Logto 提供了额外的授权数据上下文。授权数据对象包含来自主体 (Subject) 令牌的自定义上下文。详见 [用户模拟 (User impersonation)](/developers/user-impersonation)。
- **用户交互数据对象**
- 对于给定的用户访问令牌 (User access token)，有时你需要访问当前授权 (Authorization) 会话的用户交互详情。例如，你可能需要获取用户用于登录的企业单点登录 (Enterprise SSO) 身份。该用户交互数据对象包含最近用户提交的交互数据，包括：
+ 对于给定的用户访问令牌 (User access token)，有时你需要访问当前授权 (Authorization) 会话的用户交互详情。例如，你可能需要获取用户用于登录的企业单点登录 (Enterprise SSO) 身份。该用户交互数据对象包含最近一次用户提交的交互数据，包括：
| 属性 | 描述 | 类型 |
| --------------------- | ------------------------------------------------------ | ---------------------- |
- | `interactionEvent` | 当前用户交互事件 | `SignIn` 或 `Register` |
+ | `interactionEvent` | 当前用户交互的事件 | `SignIn` 或 `Register` |
| `userId` | 当前用户交互的用户 id | `string` |
| `verificationRecords` | 用户在交互过程中提交的用于身份识别和验证的验证记录列表 | `VerificationRecord[]` |
@@ -231,19 +231,19 @@ context 对象包含与当前授权 (Authorization) 流程相关的用户数据
### environmentVariables \{#environmentvariables}
-使用右侧的 **设置环境变量** 区域为你的脚本设置环境变量。你可以使用这些变量存储敏感信息或配置数据，避免在脚本中硬编码。例如 API 密钥、密钥或 URL。
+使用右侧的 **设置环境变量 (Set environment variables)** 区域为你的脚本设置环境变量。你可以用这些变量存储敏感信息或配置数据，避免在脚本中硬编码。例如 API 密钥、密钥或 URL。
-你在这里设置的所有环境变量都可以在脚本中使用。通过输入参数中的 `environmentVariables` 对象访问这些变量。
+你在此设置的所有环境变量都可在脚本中使用。通过输入参数中的 `environmentVariables` 对象访问这些变量。
### api \{#api}
-`api` 对象为你提供了一组实用函数，可用于在脚本中对令牌签发过程进行额外访问控制。`api` 对象包含以下函数：
+`api` 对象为你的脚本提供了一组实用函数，用于对令牌签发过程进行额外访问控制。`api` 对象包含以下函数：
```jsx
api.denyAccess(message?: string): void
```
-`api.denyAccess()` 函数允许你通过自定义消息拒绝令牌签发过程。你可以使用此函数在令牌签发过程中强制执行额外的访问验证。
+`api.denyAccess()` 函数允许你通过自定义消息拒绝令牌签发过程。你可以用此函数对令牌签发过程进行额外访问校验。
## 步骤 3：获取外部数据 \{#step-3-fetch-external-data}
@@ -276,14 +276,14 @@ const getCustomJwtClaims = async ({ environmentVariables }) => {
## 步骤 4：测试脚本 \{#step-4-test-the-script}
-在保存脚本前务必进行测试。点击页面右侧的 **测试上下文** 标签，修改用于测试的模拟令牌负载和用户数据上下文。
+请务必在保存前测试你的脚本。点击页面右侧的 **测试上下文 (Test context)** 标签，修改用于测试的模拟令牌负载和用户数据上下文。
-点击编辑器右上角的 **运行测试**，使用模拟数据运行脚本。脚本输出将在 **测试结果** 抽屉中显示。
+点击编辑器右上角的 **运行测试 (Run test)**，即可用模拟数据运行脚本。脚本输出将在 **测试结果 (Test Result)** 抽屉中展示。
:::note
-测试结果是你设置的模拟数据下 `getCustomJwtClaims` 函数的输出（即在[时序图](/developers/custom-token-claims/#how-do-custom-token-claims-work)第 3 步获得的“额外令牌声明”）。实际令牌负载和用户数据上下文在令牌签发过程中会有所不同。
+测试结果是你设置的模拟数据下 `getCustomJwtClaims` 函数的输出（即在[时序图](/developers/custom-token-claims/#how-do-custom-token-claims-work)第 3 步获得的“额外令牌声明 (Claims)”）。实际令牌负载和用户数据上下文在令牌签发流程中会有所不同。
:::
-点击 **创建** 按钮保存脚本。自定义令牌声明脚本将被保存并应用于访问令牌 (Access token) 签发流程。
+点击 **创建 (Create)** 按钮保存脚本。自定义令牌声明 (Claims) 脚本将被保存并应用于访问令牌 (Access token) 签发流程。
diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index 9ae18a24af8..59adc513dea 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -2,20 +2,20 @@
id: sdk-conventions
title: 平台 SDK 约定
sidebar_label: 平台 SDK 约定
-sidebar_position: 7
+sidebar_position: 8
---
# 平台 SDK 约定
-Logto 提供了一个非常强大且灵活的网络认证 (Authentication) 服务。
+Logto 提供了非常强大且灵活的 Web 认证 (Authentication) 服务。
-在实际使用 Logto 的服务时，为了方便，开发者通常需要将 Logto SDK 集成到他们自己的客户端应用程序中，以管理用户登录状态、权限等。
+在实际使用 Logto 服务时，为了方便，开发者通常需要将 Logto SDK 集成到自己的客户端应用中，以管理用户登录状态、权限等。
你可以在 [这里](/quick-starts) 找到 Logto 支持的所有编程语言 / 框架的 SDK。
-如果你不幸没有找到你想要的 SDK，这里有一个约定，你可以遵循它来为你想要的编程语言实现 SDK，使使用 Logto 服务更加容易。
+如果你不幸没有找到想要的 SDK，这里有一套约定可以遵循，用于为你期望的编程语言实现 SDK，从而更方便地使用 Logto 服务。
-这个约定包含三个主要部分：
+本约定包含三个主要部分：
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## 安全性说明 \{#security-considerations}
+
+预构建账户中心 UI 内置了安全措施：
+
+- **身份验证**：在进行敏感操作（邮箱、手机号、密码、MFA）前，用户必须通过当前密码或现有验证方式验证身份
+- **验证码**：邮箱和手机号更新需要向新地址 / 号码发送验证码
+- **会话校验**：所有操作都会校验用户会话，防止未授权访问
+
+## 个性化定制选项 \{#customization-options}
+
+预构建账户中心 UI 会继承你的登录体验设置中的品牌，包括：
+
+- Logo 和配色
+- 深色 / 浅色模式
+- 语言设置
+
+如果你需要超出预构建 UI 提供范围的自定义，可以考虑使用 [Account API](/end-user-flows/account-settings/by-account-api) 自行开发账户管理页面。
+
+## 相关资源 \{#related-resources}
+
+- [通过 Account API 进行账户设置](/end-user-flows/account-settings/by-account-api) - 使用完整 API 控制自定义账户管理
+- [通过 Management API 进行账户设置](/end-user-flows/account-settings/by-management-api) - 管理员级账户管理
+- [MFA 配置](/end-user-flows/mfa) - 设置多因素认证 (MFA)
diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/introduction/README.mdx
index 066b216ef2f..07487c56897 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -1,5 +1,5 @@
---
-description: 通过集成 Logto，快速启动你的身份和访问管理系统。尽享认证 (Authentication)、授权 (Authorization) 和多租户管理于一体的体验。
+description: 通过集成 Logto，快速启动你的身份和访问管理系统。享受认证 (Authentication)、授权 (Authorization) 和多租户管理一体化体验。
---
import AuditLogIcon from '@site/src/assets/audit-log.svg';
@@ -32,7 +32,7 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
# 简介
-欢迎来到 Logto 文档！Logto 是为现代应用和 SaaS 产品设计的身份与访问管理 (IAM) 解决方案。它为你的应用程序提供安全、可扩展且可定制的认证 (Authentication) 和授权 (Authorization) 系统。
+欢迎来到 Logto 文档！Logto 是为现代应用和 SaaS 产品设计的身份和访问管理 (IAM) 解决方案。它为你的应用程序提供安全、可扩展且可定制的认证 (Authentication) 和授权 (Authorization) 系统。
## 按功能探索 \{#explore-by-features}
@@ -143,6 +143,10 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
icon: 邮箱更新成功！
}
+ {showSuccess === 'password' && 密码更新成功！
}
+ {/* ... 你的设置页面其他内容 */}
+ -简而言之，当你请求一个权限时，你将获得用户信息中的相应声明。例如，如果你请求 `email` 权限，你将获得用户的 `email` 和 `email_verified` 数据。 +简而言之，当你请求某个权限 (Scope) 时，你将在用户信息中获得对应的声明 (Claims)。例如，如果你请求了 `email` 权限 (Scope)，你将获得用户的 `email` 和 `email_verified` 数据。
- 默认情况下，Logto SDK 总是会请求三个权限：`openid`、`profile` 和 - `offline_access`，并且无法移除这些默认权限。但你可以在配置 Logto 时添加更多权限： + 默认情况下，Logto SDK 总是会请求三个权限 (Scopes)：`openid`、`profile` 和 `offline_access`， + 并且无法移除这些默认权限 (Scopes)。但你可以在配置 Logto 时添加更多权限 (Scopes)：
{props.configScopesCode} diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/README.mdx index dd5d7226729..05d10fe82cc 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/README.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/README.mdx @@ -1,6 +1,6 @@ # 開發者 (Developer) -Logto 是一個基於 [OAuth 2](https://auth.wiki/oauth-2.0) 與 [OIDC](https://auth.wiki/openid-connect) 協議的 [身分與存取管理 (IAM, Identity and Access Management)](https://auth.wiki/iam) 服務。像 Logto 這樣的 IAM 服務通常作為其他網路服務的基礎；這些網路服務中的各種授權 (Authorization) 狀態會直接受到 Logto 的影響。 +Logto 是一套基於 [OAuth 2](https://auth.wiki/oauth-2.0) 與 [OIDC](https://auth.wiki/openid-connect) 協議的 [身分與存取管理 (IAM, Identity and Access Management)](https://auth.wiki/iam) 服務。像 Logto 這樣的 IAM 服務通常作為其他網路服務的基礎；這些網路服務中的各種授權 (Authorization) 狀態會直接受到 Logto 的影響。 為了方便使用者，Logto 提供了一系列常用的開發者功能。 @@ -19,9 +19,18 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg'; items={[ { type: 'link', - label: '自訂權杖宣告 (Custom token claims)', + label: '自訂存取權杖 (Custom access token)', href: '/developers/custom-token-claims', - description: '透過附加額外宣告 (Claims)，擴展存取控制能力，有助於實現 ABAC 或拒絕權杖 (Token) 發放。', + description: '使用自訂腳本為存取權杖 (Access token) 附加額外宣告 (Claims)，以實現 ABAC 或拒絕權杖 (Token) 發放。', + customProps: { + icon:
@@ -47,7 +47,7 @@ Logto 的日誌提供完整細節，確保操作便利與客戶安全。它們
-### 我使用自架版 Logto，取得稽核日誌需數秒，有什麼方法能提升效能？ \{#im-using-self-hosted-logto-and-it-takes-seconds-to-get-the-audit-logs-how-can-i-improve-the-performance} +### 我使用自託管 Logto，取得稽核日誌需數秒，如何提升效能？ \{#im-using-self-hosted-logto-and-it-takes-seconds-to-get-the-audit-logs-how-can-i-improve-the-performance}
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx new file mode 100644 index 00000000000..782f76d6035 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/custom-id-token/README.mdx @@ -0,0 +1,81 @@ +--- +sidebar_position: 3 +--- + +# 自訂 ID 權杖 (ID token) + +## 介紹 \{#introduction} + +[ID 權杖 (ID token)](https://auth.wiki/id-token) 是由 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 協議定義的一種特殊權杖。它作為授權伺服器（Logto）在使用者成功驗證後簽發的身分聲明，攜帶經驗證使用者身分的宣告 (Claims)。 + +與用於存取受保護資源的 [存取權杖 (Access tokens)](/developers/custom-token-claims) 不同，ID 權杖專為向用戶端應用程式傳遞經驗證使用者身分而設計。它們是 [JSON Web Token (JWT)](https://auth.wiki/jwt)，包含有關驗證事件與經驗證使用者的宣告 (Claims)。 + +## ID 權杖宣告 (Claims) 的運作方式 \{#how-id-token-claims-work} + +在 Logto 中，ID 權杖宣告 (Claims) 分為兩類： + +1. **標準 OIDC 宣告 (Standard OIDC claims)**：由 OIDC 規範定義，完全由驗證時請求的權限範圍 (Scopes) 決定。 +2. **擴充宣告 (Extended claims)**：Logto 擴充的宣告，用於攜帶額外身分資訊，受 **雙重條件模型（Scope + 開關）** 控制。 + +```mermaid +flowchart TD + A[使用者驗證請求 (User authentication request)] --> B{請求的權限範圍 (Requested scopes)} + B --> C[標準 OIDC 權限範圍 (Standard OIDC scopes)] + B --> D[擴充權限範圍 (Extended scopes)] + C --> E[標準宣告納入 ID 權杖 (Standard claims included in ID token)] + D --> F{控制台開關已啟用？ (Console toggle enabled?)} + F -->|是 (Yes)| G[擴充宣告納入 ID 權杖 (Extended claims included in ID token)] + F -->|否 (No)| H[宣告未納入 (Claims not included)] +``` + +## 標準 OIDC 宣告 (Standard OIDC claims) \{#standard-oidc-claims} + +標準宣告完全遵循 OIDC 規範。它們是否被納入 ID 權杖，僅取決於你的應用程式在驗證時請求了哪些權限範圍 (Scopes)。Logto 不提供任何選項來停用或選擇性排除個別標準宣告。 + +下表顯示標準權限範圍與其對應宣告的對應關係： + +| 權限範圍 (Scope) | 宣告 (Claims) | +| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `openid` | `sub` | +| `profile` | `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, `updated_at` | +| `email` | `email`, `email_verified` | +| `phone` | `phone_number`, `phone_number_verified` | +| `address` | `address` | + +例如，若你的應用程式請求了 `openid profile email` 權限範圍，ID 權杖將包含來自 `openid`、`profile` 與 `email` 權限範圍的所有宣告。 + +## 擴充宣告 (Extended claims) \{#extended-claims} + +除了標準 OIDC 宣告外，Logto 還擴充了額外宣告，攜帶 Logto 生態系專屬的身分資訊。這些擴充宣告需同時滿足 **雙重條件模型** 才會被納入 ID 權杖： + +1. **權限範圍條件 (Scope condition)**：應用程式在驗證時必須請求對應的權限範圍。 +2. **控制台開關 (Console toggle)**：管理員需在 Logto Console 啟用該宣告納入 ID 權杖。 + +兩個條件必須同時滿足。權限範圍屬於協議層級的存取聲明，開關則屬於產品層級的資訊揭露控制——兩者職責明確且不可互相取代。 + +### 可用的擴充權限範圍與宣告 \{#available-extended-scopes-and-claims} + +| 權限範圍 (Scope) | 宣告 (Claims) | 說明 (Description) | 預設納入 (Included by default) | +| ------------------------------------ | ------------------------------ | --------------------------------- | ------------------------------ | +| `custom_data` | `custom_data` | 儲存在使用者物件上的自訂資料 | | +| `identities` | `identities`, `sso_identities` | 使用者綁定的社交與 SSO 身分 | | +| `roles` | `roles` | 使用者被指派的角色 (Roles) | ✅ | +| `urn:logto:scope:organizations` | `organizations` | 使用者所屬組織 (Organizations) ID | ✅ | +| `urn:logto:scope:organizations` | `organization_data` | 使用者的組織資料 | | +| `urn:logto:scope:organization_roles` | `organization_roles` | 使用者的組織角色指派 | ✅ | + +### 在 Logto Console 設定 \{#configure-in-logto-console} + +啟用 ID 權杖中的擴充宣告： + +1. 前往產生原始存取權杖內容 rect var(--mermaid-rect-fill) @@ -38,21 +38,21 @@ sequenceDiagram IdP->>IdP: 執行自訂權杖宣告腳本（`getCustomJwtClaims`）&
取得額外權杖宣告 end IdP-->>IdP: 合併原始存取權杖內容與額外權杖宣告 - IdP-->>IdP: 簽署並加密內容以取得存取權杖 + IdP-->>IdP: 簽名並加密內容以取得存取權杖 deactivate IdP - IdP-->>U: 發放 JWT 格式存取權杖 - par 透過 API 取得服務 - U->>SP: 服務請求（附帶 JWT 存取權杖） + IdP-->>U: 發送 JWT 格式存取權杖 + par 透過 API 取得服務 (Get service via API) + U->>SP: 服務請求（附 JWT 存取權杖） SP-->>U: 服務回應 end ``` :::warning -Logto 內建權杖宣告不可被覆蓋或修改。自訂宣告會以額外宣告的形式加入權杖中。若自訂宣告與內建宣告衝突，該自訂宣告將被忽略。 +Logto 內建權杖宣告不可被覆蓋或修改。自訂宣告會以額外宣告加入權杖中。若自訂宣告與內建宣告衝突，該自訂宣告將被忽略。 ::: ## 相關資源 \{#related-resources}
+
## 步驟 1：編輯腳本 \{#step-1-edit-the-script}
-使用左側的程式碼編輯器來修改腳本。預設會提供一個回傳空物件的 `getCustomJwtClaims`，你可以從這裡開始，修改函式以回傳你自訂的宣告 (claims) 物件。
+使用左側的程式碼編輯器修改腳本。預設已提供一個回傳空物件的 `getCustomJwtClaims`，你可以從這裡開始，修改函式以回傳你自訂的宣告物件。
```jsx
const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
@@ -46,37 +46,37 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
此編輯器使用 JavaScript 語言伺服器，提供基本語法高亮、程式碼補全與錯誤檢查。輸入參數皆有良好型別與 jsDoc 文件說明。你可以利用編輯器的 IntelliSense 正確存取輸入物件的屬性。詳細參數定義可於頁面右側查看。
:::note
-此函式將作為模組匯出。請務必保持函式名稱為 `getCustomJwtClaims`，以確保模組正確匯出該函式。
+此函式將作為模組匯出。請確保函式名稱維持為 `getCustomJwtClaims`，以便模組正確匯出該函式。
:::
## 步驟 2：輸入參數 \{#step-2-input-parameters}
-`getCustomJwtClaims` 函式接受一個物件作為輸入參數。該輸入物件包含以下屬性：
+`getCustomJwtClaims` 函式以一個物件作為輸入參數。該物件包含以下屬性：
### token \{#token}
-權杖內容 (payload) 物件。此物件包含原始權杖宣告 (claims) 與你可能需要在腳本中存取的中繼資料。
+權杖內容 (Payload) 物件。此物件包含原始權杖宣告與你可能需要在腳本中存取的中繼資料。
-你可以在頁面右側找到權杖內容 (payload) 物件與使用者資料物件的詳細型別定義。編輯器的 IntelliSense 也會協助你正確存取這些屬性。
+你可以在頁面右側找到權杖內容物件與使用者資料物件的詳細型別定義。編輯器的 IntelliSense 也會協助你正確存取這些屬性。
- 使用者存取權杖資料物件
- | 屬性 (Property) | 說明 (Description) | 型別 (Type) |
+ | Property | 說明 | Type |
| -------------------- | ------------------------------------------------ | ------------- |
| `jti` | JWT 唯一識別碼 | `string` |
- | `aud` | 權杖的受眾 (Audience) | `string` |
- | `scope` | 權杖的權限範圍 (Scopes) | `string` |
+ | `aud` | 權杖受眾 (Audience) | `string` |
+ | `scope` | 權杖權限範圍 (Scopes) | `string` |
| `clientId` | 權杖的用戶端 ID | `string` |
| `accountId` | 權杖的使用者 ID | `string` |
- | `expiresWithSession` | 權杖是否隨會話到期 | `boolean` |
- | `grantId` | 權杖的當前驗證 (Authentication) 授權 ID | `string` |
- | `gty` | 權杖的授權類型 | `string` |
+ | `expiresWithSession` | 權杖是否隨工作階段到期 | `boolean` |
+ | `grantId` | 權杖的當前驗證 (Authentication) 授權 (Grant) ID | `string` |
+ | `gty` | 權杖的授權類型 (Grant type) | `string` |
| `kind` | 權杖類型 | `AccessToken` |
- 機器對機器存取權杖資料物件
- | 屬性 (Property) | 說明 (Description) | 型別 (Type) |
+ | Property | 說明 | Type |
| ---------- | -------------------------- | ------------------- |
| `jti` | JWT 唯一識別碼 | `string` |
- | `aud` | 權杖的受眾 (Audience) | `string` |
- | `scope` | 權杖的權限範圍 (Scopes) | `string` |
+ | `aud` | 權杖受眾 (Audience) | `string` |
+ | `scope` | 權杖權限範圍 (Scopes) | `string` |
| `clientId` | 權杖的用戶端 ID | `string` |
| `kind` | 權杖類型 | `ClientCredentials` |
@@ -85,13 +85,13 @@ const getCustomJwtClaims = async ({ token, context, environmentVariables }) => {
context 物件包含與當前授權 (Authorization) 流程相關的使用者資料與授權資料。
- **使用者資料物件**
- 對於使用者存取權杖，Logto 會提供額外的使用者資料 context 供你存取。該物件包含所有使用者個人資料與組織 (Organization) 成員資料，方便你設置自訂宣告 (claims)。詳情請參閱 [使用者](/user-management/user-data) 與 [組織](/organizations/organization-management#organization-data-structure)。
+ 對於使用者存取權杖，Logto 會提供額外的使用者資料 context 供你存取。該物件包含所有使用者個人資料與組織成員資料，方便你設置自訂宣告。詳情請參閱 [使用者](/user-management/user-data)與[組織](/organizations/organization-management#organization-data-structure)。
- **授權資料物件**
- 對於透過模擬 (Impersonation) 權杖交換取得的使用者存取權杖，Logto 會提供額外的授權資料 context。該物件包含來自主體 (Subject) 權杖的自訂 context。詳情請參閱 [使用者模擬 (User impersonation)](/developers/user-impersonation)。
+ 對於透過模擬 (Impersonation) 權杖交換取得的使用者存取權杖，Logto 會提供額外的授權資料 context。該物件包含來自主體權杖的自訂 context。詳情請參閱[使用者模擬 (User impersonation)](/developers/user-impersonation)。
- **使用者互動資料物件**
- 對於特定使用者存取權杖，有時你需要存取當前授權 (Authorization) 會話的使用者互動細節。例如，你可能需要取得使用者登入時所用的企業級單一登入 (Enterprise SSO) 身分。此物件包含最近一次使用者提交的互動資料，包括：
+ 對於特定使用者存取權杖，你可能需要存取當前授權會話的使用者互動細節。例如，你可能需要取得使用者登入時所用的企業級單一登入 (Enterprise SSO) 身分。此物件包含最近一次使用者提交的互動資料，包括：
- | 屬性 (Property) | 說明 (Description) | 型別 (Type) |
+ | Property | 說明 | Type |
| --------------------- | -------------------------------------------------------- | ---------------------- |
| `interactionEvent` | 當前使用者互動事件 | `SignIn` 或 `Register` |
| `userId` | 當前使用者互動的使用者 ID | `string` |
@@ -224,30 +224,30 @@ context 物件包含與當前授權 (Authorization) 流程相關的使用者資
:::note
使用者互動資料物件中可能包含多筆驗證紀錄，特別是當使用者經歷多次登入或註冊流程時。
- 例如，使用者先以 `Social` 驗證紀錄登入，再透過 `EmailVerificationCode` 綁定新電子郵件，最後以 `Totp` 驗證紀錄驗證 MFA 狀態。在這種情況下，你可能需要在腳本中分別處理所有驗證紀錄。
+ 例如，使用者先以 `Social` 驗證紀錄登入，再透過 `EmailVerificationCode` 綁定新電子郵件，最後以 `Totp` 驗證紀錄驗證 MFA 狀態。此時，你可能需要在腳本中依序處理所有驗證紀錄。
- 每種驗證紀錄類型在使用者互動資料物件中僅會出現一次。
+ 每種驗證紀錄型別在使用者互動資料物件中僅會出現一次。
:::
### environmentVariables \{#environmentvariables}
-使用右側的 **設定環境變數 (Set environment variables)** 區塊來為你的腳本設置環境變數。你可以利用這些變數儲存敏感資訊或設定資料，避免在腳本中硬編碼。例如 API 金鑰、密鑰或 URL。
+使用右側的 **設定環境變數 (Set environment variables)** 區塊為你的腳本設置環境變數。你可以用這些變數儲存敏感資訊或設定資料，避免在腳本中硬編碼，例如 API 金鑰、密鑰或 URL。
-你在此設置的所有環境變數都可於腳本中存取。請透過輸入參數中的 `environmentVariables` 物件來取得這些變數。
+所有你在此設置的環境變數都可於腳本中取得。請透過輸入參數中的 `environmentVariables` 物件存取這些變數。
### api \{#api}
-`api` 物件提供一組實用函式，讓你在腳本中對權杖發放流程進行額外存取控制。`api` 物件包含以下函式：
+`api` 物件提供一組工具函式，讓你在腳本中對權杖發放流程進行額外存取控制。`api` 物件包含以下函式：
```jsx
api.denyAccess(message?: string): void
```
-`api.denyAccess()` 函式允許你以自訂訊息拒絕權杖發放流程。你可以利用此函式對權杖發放流程施加額外存取驗證。
+`api.denyAccess()` 函式可讓你以自訂訊息拒絕權杖發放流程。你可以利用此函式對權杖發放流程進行額外存取驗證。
## 步驟 3：擷取外部資料 \{#step-3-fetch-external-data}
-你可以在腳本中使用 Node 內建的 `fetch` 函式來擷取外部資料。`fetch` 是一個基於 Promise 的函式，允許你向外部 API 發送 HTTP 請求。
+你可以在腳本中使用 Node 內建的 `fetch` 函式擷取外部資料。`fetch` 是一個基於 Promise 的函式，允許你向外部 API 發送 HTTP 請求。
```jsx
const getCustomJwtClaims = async ({ environmentVariables }) => {
@@ -276,14 +276,14 @@ const getCustomJwtClaims = async ({ environmentVariables }) => {
## 步驟 4：測試腳本 \{#step-4-test-the-script}
-請務必在儲存前測試你的腳本。點擊頁面右側的 **測試 context (Test context)** 分頁，修改測試用的權杖內容 (payload) 與使用者資料 context。
+請務必在儲存前測試你的腳本。點擊頁面右側的 **測試 context (Test context)** 分頁，修改測試用的權杖內容與使用者資料 context。
-點擊編輯器右上角的 **執行測試 (Run test)**，即可以測試資料執行腳本。腳本的輸出結果將顯示於 **測試結果 (Test Result)** 抽屜中。
+點擊編輯器右上角的 **執行測試 (Run test)**，即可用測試資料執行腳本。腳本輸出將顯示於 **測試結果 (Test Result)** 抽屜中。
:::note
-測試結果即為 `getCustomJwtClaims` 函式以你設定的測試資料執行後的輸出（即[時序圖](/developers/custom-token-claims/#how-do-custom-token-claims-work)第 3 步取得的「額外權杖宣告 (extra token claims)」）。實際權杖內容 (payload) 與使用者資料 context 會因發放流程而異。
+測試結果即為 `getCustomJwtClaims` 函式以你設定的測試資料執行後的輸出（即[時序圖](/developers/custom-token-claims/#how-do-custom-token-claims-work)步驟 3 完成後取得的「額外權杖宣告」）。實際權杖內容與使用者資料 context 會因發放流程而異。
:::
-點擊 **建立 (Create)** 按鈕以儲存腳本。自訂權杖宣告 (claims) 腳本將被儲存並應用於存取權杖發放流程。
+點擊 **建立 (Create)** 按鈕以儲存腳本。自訂權杖宣告腳本將被儲存並應用於存取權杖發放流程。
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
index 7c351940c02..69385b84d20 100644
--- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
+++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx
@@ -1,32 +1,41 @@
---
id: sdk-conventions
-title: 平台 SDK 慣例
-sidebar_label: 平台 SDK 慣例
-sidebar_position: 7
+title: 平台 SDK 慣例 (Platform SDK conventions)
+sidebar_label: 平台 SDK 慣例 (Platform SDK conventions)
+sidebar_position: 8
---
-# 平台 SDK 慣例
+# 平台 SDK 慣例 (Platform SDK conventions)
-Logto 提供了一個非常強大且靈活的網頁驗證服務。
+Logto 提供功能強大且彈性的網頁驗證 (Authentication) 服務。
-在實際使用 Logto 的服務時，為了方便，開發者通常需要將 Logto SDK 整合到自己的客戶端應用程式中，以管理使用者登入狀態、權限等。
+在實際使用 Logto 服務時，為了方便，開發者通常需要將 Logto SDK 整合進自己的用戶端應用程式，以管理使用者登入狀態、權限等。
你可以在 [這裡](/quick-starts) 找到 Logto 支援的所有程式語言 / 框架的 SDK。
-如果不幸地沒有找到你想要的 SDK，這裡有一個慣例可以遵循，以便為你想要的程式語言實現 SDK，使使用 Logto 服務更為簡便。
+如果你不幸沒找到想要的 SDK，這裡有一套慣例可供參考，協助你為目標程式語言實作 SDK，讓你更輕鬆地使用 Logto 服務。
-此慣例包含三個主要部分：
+本慣例包含三個主要部分：
--### Logto 支援同步 webhook 嗎？\{#does-logto-support-synced-webhooks} +### Logto 支援同步 webhook 嗎？ \{#does-logto-support-synced-webhooks}
-雖然同步 webhook 能讓使用者登入流程更順暢，但目前尚未支援（未來會支援）。因此，目前所有依賴同步 webhook 的情境都需要不同的替代方案。如有疑問，歡迎聯繫我們。 +雖然同步 webhook 能讓使用者登入流程更順暢，但目前尚未支援（未來會支援）。因此，目前所有依賴同步 webhook 的情境都需要其他替代方案。如有疑問，歡迎聯絡我們。-### 如何處理使用者權限變更？\{#how-to-deal-with-user-permission-change} +### 如何處理使用者權限變更？ \{#how-to-deal-with-user-permission-change}
@@ -85,22 +85,22 @@ graph LR-### 如何偵錯 webhook 超時？\{#how-to-debug-webhook-timeout} +### 如何除錯 webhook 逾時？ \{#how-to-debug-webhook-timeout}
-接收 Webhook 的 endpoint 應盡快回傳 2xx 回應，告知 Logto Webhook 已成功接收。由於不同用戶對 Webhook 的處理邏輯差異極大，過於複雜的任務可能需數秒，導致 Logto Webhook 超時。最佳做法是維護自己的事件佇列；收到 Logto Webhook 時，將事件寫入佇列並立即回傳 2xx 給 Logto，然後讓自己的 worker 逐步處理佇列任務。若 worker 發生錯誤，請於自己的伺服器處理。 +接收 Webhook 的 endpoint 應盡快回傳 2xx 回應，告知 Logto Webhook 已成功接收。由於不同用戶對 Webhook 的處理邏輯差異極大，若任務過於複雜，可能需數秒才完成，導致 Logto Webhook 逾時。最佳做法是維護自己的事件佇列；收到 Logto Webhook 時，將事件寫入佇列並立即回傳 2xx 給 Logto，然後讓自己的 worker 逐步處理佇列任務。若 worker 發生錯誤，請在自己的伺服器上處理。-### 可以從 `PostSignIn` webhook 取得 client IP 嗎？\{#can-i-get-the-client-ip-address-from-postsignin-webhooks} +### 可以從 `PostSignIn` webhook 取得 client IP 嗎？ \{#can-i-get-the-client-ip-address-from-postsignin-webhooks}
-可以，你可以在 Webhook payload 中取得 IP 位址、user agent 等資訊。如果需要目前未支援的資訊，歡迎在 GitHub issues 提出功能需求，或聯繫我們。 +可以，你可以在 Webhook payload 中取得 IP 位址、user agent 等資訊。如需目前未支援的資訊，歡迎在 GitHub issues 提出功能需求或聯絡我們。
+
+ );
+}
+```
+
+### 步驟 3：處理成功導回 \{#step-3-handle-success-redirects}
+
+使用者完成操作後，會被導回你指定的 URL，並可能帶有 `show_success` 查詢參數。你可以用它來顯示成功訊息：
+
+```tsx
+function SettingsPage() {
+ const searchParams = new URLSearchParams(window.location.search);
+ const showSuccess = searchParams.get('show_success');
+
+ return (
+ 帳號設定
+ +
+ 電子郵件：user@example.com
+ 更新電子郵件
+
+
+
+ 密碼：••••••••
+ 變更密碼
+
+
+
+ MFA：尚未設定
+
+ 設定驗證器
+
+
+
+ {showSuccess === 'email' &&
+ );
+}
+```
+
+## 安全性考量 \{#security-considerations}
+
+預建帳號中心 UI 內建多項安全措施：
+
+- **身分驗證**：進行敏感變更（電子郵件、手機、密碼、MFA）前，使用者必須透過現有密碼或驗證方式驗證身分
+- **驗證碼**：電子郵件與手機更新需輸入發送至新地址／號碼的驗證碼
+- **工作階段驗證**：所有操作都會驗證使用者的工作階段，防止未授權存取
+
+## 客製化選項 \{#customization-options}
+
+預建帳號中心 UI 會繼承你的登入體驗設定，包括：
+
+- 標誌與配色
+- 深色／淺色模式
+- 語言設定
+
+若你需要超越預建 UI 的自訂化，請考慮使用 [Account API](/end-user-flows/account-settings/by-account-api) 自行打造專屬帳號管理頁面。
+
+## 相關資源 \{#related-resources}
+
+- [透過 Account API 進行帳號設定](/end-user-flows/account-settings/by-account-api)－以完整 API 控制自訂帳號管理
+- [透過 Management API 進行帳號設定](/end-user-flows/account-settings/by-management-api)－管理員層級帳號管理
+- [MFA 設定](/end-user-flows/mfa)－設定多重要素驗證 (MFA)
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/introduction/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/introduction/README.mdx
index a7f4401126e..2a75e59677e 100644
--- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/introduction/README.mdx
+++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/introduction/README.mdx
@@ -143,6 +143,10 @@ import WebhookIcon from '@site/src/assets/webhook.svg';
icon: 電子郵件更新成功！
}
+ {showSuccess === 'password' && 密碼更新成功！
}
+ {/* ... 其餘設定頁內容 */}
+ -如果你是身分系統新手，建議先閱讀以下重要概念： +如果你是身分系統新手，建議先閱讀這些重要概念：
-簡而言之，當你請求一個權限範圍 (Scope) 時，你將獲得使用者資訊中的對應宣告 (Claims)。例如，如果你請求 `email` 權限範圍 (Scope)，你將獲得使用者的 `email` 和 `email_verified` 資料。 +簡單來說，當你請求某個權限範圍 (Scope) 時，會在使用者資訊中取得對應的宣告 (Claim)。例如，若請求 `email` 權限範圍 (Scope)，你將取得使用者的 `email` 與 `email_verified` 資料。
- 預設情況下，Logto SDK 會始終請求三個權限範圍 (Scopes)：`openid`、`profile` 和 - `offline_access`，且無法移除這些預設的權限範圍 (Scopes)。但你可以在配置 Logto 時新增更多權限範圍 + 預設情況下，Logto SDK 會始終請求三個權限範圍 (Scopes)：`openid`、`profile` 以及 + `offline_access`，且無法移除這些預設權限範圍 (Scopes)。但你可以在設定 Logto 時新增更多權限範圍 (Scopes)：