diff --git a/docs/customization/match-your-brand.mdx b/docs/customization/match-your-brand.mdx index b2543b3a619..cb51b906140 100644 --- a/docs/customization/match-your-brand.mdx +++ b/docs/customization/match-your-brand.mdx @@ -8,11 +8,11 @@ sidebar_position: 1 Customize the look and feel of your sign-in page by navigating to Console > Sign-in experience > Branding. This section allows you to easily adjust key branding elements. -### Brand color +### Brand color \{#brand-color} Define the primary color used throughout the sign-in experience, including primary buttons, links, and other components. Replace the default Logto purple color with your brand's color. For dark mode, a separate brand color can be specified. -### Company logo +### Company logo \{#company-logo} The logo will be displayed on the sign-in homepage, sign-up home, loading page, and other interfaces with our expansion. @@ -20,7 +20,7 @@ The logo will be displayed on the sign-in homepage, sign-up home, loading page, - If you leave the logo field blank, the logo will not display in the interface. - A dark mode version of the logo can also be uploaded. -### Favicon +### Favicon \{#favicon} A favicon is a small icon representing a website and is displayed in the browser tab, bookmarks, and other areas of the browser interface. @@ -28,11 +28,11 @@ A favicon is a small icon representing a website and is displayed in the browser - A dark mode version of the favicon can also be uploaded. - Besides, the browser title for different flows (Sign in/Sign up/Forgot password, etc.) is now used instead of a custom title. -### Dark mode +### Dark mode \{#dark-mode} Enable dark mode to automatically adjust the sign-in page's appearance based on the user's system preferences. -### Hide Logto branding +### Hide Logto branding \{#hide-logto-branding} By default, the out-of-the-box sign-in experience pages display "Powered by Logto" at the bottom. Enable the "Hide Logto branding" option to remove the Logto mark and create a clean, professional sign-in experience that exclusively showcases your own brand identity. diff --git a/docs/integrate-logto/integrate-logto-into-your-application/README.mdx b/docs/integrate-logto/integrate-logto-into-your-application/README.mdx index 23adc7f6f23..a9f7f796d16 100644 --- a/docs/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/docs/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -25,7 +25,7 @@ The guide in the console is only for quick start with Logto using our SDK. For c Authorization Organizations -## FAQs +## FAQs \{#faqs}
diff --git a/docs/logto-cloud/system-limit.mdx b/docs/logto-cloud/system-limit.mdx index 3c0453dd0cb..4e93e6ae2e7 100644 --- a/docs/logto-cloud/system-limit.mdx +++ b/docs/logto-cloud/system-limit.mdx @@ -6,9 +6,9 @@ You may notice that some items on the pricing page are marked as _unlimited_ or If your use case is reasonable but reaches a system limit, feel free to contact us and share your feedback. This helps us better understand real-world usage patterns and adjust system limits to better support our loyal customers. -## Tenant-level rate limit protection +## Tenant-level rate limit protection \{#tenant-level-rate-limit-protection} -### Dev tenants +### Dev tenants \{#dev-tenants} For Dev tenants, users can take advantage of Logto's free features and offerings. To prevent abuse and set clear expectations, we define certain system limits. These limits help us manage our platform sustainably while still providing free access for testing and development purposes. @@ -41,7 +41,7 @@ If you'd like to increase your quota, you can contact us for assistance. We also | Audit log retention | 14 days | | Tenant members | 20 | -### Pro tenant +### Pro tenant \{#pro-tenant} For Pro tenants, entity limits define the upper ceiling for add-ons and other "unlimited" entities such as applications. The details of the Pro plan's system limits are listed below. @@ -74,6 +74,6 @@ For Pro tenants, entity limits define the upper ceiling for add-ons and other "u | Custom domains | 10 | | Tenant members | 100 | -### Enterprise +### Enterprise \{#enterprise} For Enterprise plans, limits and features are fully customizable and managed through a the contract. Please [contact us](https://logto.io/contact) for more details. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/de/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index 69db06881aa..132b4e78e30 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -19,9 +19,9 @@ Schütze produktweite APIs mit rollenbasierter Zugangskontrolle (RBAC) in Logto. Globale API-Ressourcen sind Endpunkte oder Dienste in deiner Anwendung, die für alle Benutzer zugänglich sind, unabhängig von Organisation oder Mandant. Dies sind typischerweise öffentlich zugängliche APIs, zentrale Produktdienste oder jeder Endpunkt, der nicht auf eine bestimmte Organisation beschränkt ist. -**Anwendungsfälle umfassen** +**Anwendungsfälle sind unter anderem** -- Öffentliche APIs oder Endpunkte, die von deiner gesamten Benutzerbasis geteilt werden. +- Öffentliche APIs oder Endpunkte, die von deiner gesamten Nutzerbasis geteilt werden. - Microservices, die nicht an Multi-Tenancy gebunden sind. - Zentrale Anwendungs-APIs (z. B. `/api/users`, `/api/products`), die von allen Kunden genutzt werden. @@ -30,8 +30,8 @@ Logto ermöglicht es dir, diese APIs mit OAuth 2.1 in Kombination mit flexibler, ## So funktioniert es in Logto \{#how-it-works-in-logto} - **API-Ressourcen und Berechtigungen werden global registriert:** Jede API, die du schützen möchtest, wird mit einem eindeutigen Ressourcenindikator (URI) und einem Satz von Berechtigungen (Scopes) definiert, die den Zugriff steuern. -- **Der Zugriff wird durch globale Rollen gesteuert:** Du kannst Berechtigungen Rollen zuweisen, die dann Benutzern oder Clients zugewiesen werden. -- **Getrennt von organisationsbezogenen Berechtigungen:** Globale API-Ressourcen haben keinen Organisationskontext. Sie können jedoch in Verbindung mit Organisationsrollen verwendet werden, um bei Bedarf eine zusätzliche Kontextebene bereitzustellen. Um organisationsbezogene APIs zu schützen, siehe [Organisationsbezogene API-Ressourcen schützen](/authorization/organization-level-api-resources). +- **Der Zugriff wird durch globale Rollen gesteuert:** Du kannst Berechtigungen Rollen zuweisen, die dann Benutzern oder Clients zugeordnet werden. +- **Getrennt von organisationsbezogenen Berechtigungen:** Globale API-Ressourcen haben keinen Organisationskontext. Sie können jedoch zusammen mit Organisationsrollen verwendet werden, um bei Bedarf eine zusätzliche Kontextebene bereitzustellen. Um organisationsbezogene APIs zu schützen, siehe [Organisationsbezogene API-Ressourcen schützen](/authorization/organization-level-api-resources). Globale API-Ressourcen RBAC @@ -45,24 +45,24 @@ Logto ermöglicht es dir, diese APIs mit OAuth 2.1 in Kombination mit flexibler, ### Ressourcenindikatoren verstehen \{#understanding-resource-indicators} -Logto modelliert API-Ressourcen gemäß [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html). Ein **Ressourcenindikator** ist eine URI, die die angeforderte Ziel-API oder den Dienst eindeutig identifiziert. +Logto modelliert API-Ressourcen gemäß [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html). Ein **Ressourcenindikator (resource indicator)** ist eine URI, die die angeforderte Ziel-API oder den Dienst eindeutig identifiziert. **Wichtige Punkte** - Ressourcenindikatoren müssen absolute URIs sein (z. B. `https://api.example.com`) -- Kein Fragmentbestandteil; vermeide nach Möglichkeit die Verwendung von Query-Strings. +- Kein Fragmentbestandteil; vermeide nach Möglichkeit Query-Strings. - Ressourcenindikatoren ermöglichen zielgruppenbeschränkte Tokens und unterstützen Multi-API-Architekturen. **Beispiel** - Management API: `https://my-tenant.logto.app/api` -- Benutzerdefinierte globale API: `https://api.yourapp.com` +- Eigene globale API: `https://api.yourapp.com` ### Autorisierungsfluss: Authentifizierung und Absicherung deiner API \{#authorization-flow-authenticating-and-securing-your-api} -Der folgende Ablauf gilt sowohl für interaktive Benutzer-Authentifizierung (Browser / App) als auch für Backend-Maschine-zu-Maschine (M2M)-Szenarien. +Der folgende Ablauf gilt sowohl für interaktive Benutzer-Authentifizierung (Browser/App) als auch für Backend-Maschine-zu-Maschine (M2M)-Szenarien. -Bitte beachte, dass der Ablauf keine vollständigen Details zu den erforderlichen Parametern oder Headern enthält, sondern sich auf die wichtigsten Schritte konzentriert. Lies weiter, um zu sehen, wie der Ablauf in der Praxis funktioniert. +Beachte, dass der Ablauf nicht alle Details zu erforderlichen Parametern oder Headern enthält, sondern sich auf die wichtigsten Schritte konzentriert. Lies weiter, um zu sehen, wie der Ablauf in der Praxis funktioniert. ```mermaid sequenceDiagram @@ -96,13 +96,13 @@ sequenceDiagram end ``` -_Benutzer-Authentifizierung = Browser / App. M2M = Backend-Dienst oder Skript mit Client-Credentials._ +_Benutzer-Authentifizierung = Browser/App. M2M = Backend-Dienst oder Skript mit Client-Credentials._ :::note -Der `resource`-Parameter muss exakt mit dem API-Identifier (Ressourcenindikator) übereinstimmen, den du in Logto registriert hast. +Der `resource`-Parameter muss exakt mit dem in Logto registrierten API-Identifier (Ressourcenindikator) übereinstimmen. ::: -## Umsetzungsschritte \{#implementation-steps} +## Implementierungsschritte \{#implementation-steps} ### Registriere deine API-Ressourcen \{#register-your-api-resources} @@ -111,7 +111,7 @@ Der `resource`-Parameter muss exakt mit dem API-Identifier (Ressourcenindikator) Für vollständige Konfigurationsschritte siehe [API-Ressourcen mit Berechtigungen definieren](/authorization/role-based-access-control#define-api-resources-with-permissions). -### Richte globale Rollen ein \{#set-up-global-roles} +### Globale Rollen einrichten \{#set-up-global-roles} 1. Gehe zu Konsole → Rollen. 2. Erstelle Rollen, die deinen API-Berechtigungen entsprechen (z. B. `read:products`, `write:products`). @@ -121,41 +121,41 @@ Für vollständige Konfigurationsschritte siehe [Globale Rollen verwenden](/auth ### Zugangstokens für globale API-Ressourcen erhalten \{#obtain-access-tokens-for-global-api-resources} -Bevor du auf eine globale API-Ressource zugreifst, muss dein Client ein Zugangstoken erhalten. Logto stellt [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) als Zugangstokens für globale API-Ressourcen aus. Dies geschieht typischerweise über den [OAuth 2.0 Authorization Code Flow](https://auth.wiki/authorization-code-flow), [Auffrischungstoken-Flow](https://auth.wiki/refresh-token) oder den [Client-Credentials-Flow](https://auth.wiki/client-credentials-flow). +Bevor auf eine globale API-Ressource zugegriffen werden kann, muss dein Client ein Zugangstoken erhalten. Logto stellt [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) als Zugangstokens für globale API-Ressourcen aus. Dies geschieht typischerweise über den [OAuth 2.0 Authorization Code Flow](https://auth.wiki/authorization-code-flow), [Auffrischungstoken-Flow](https://auth.wiki/refresh-token) oder den [Client-Credentials-Flow](https://auth.wiki/client-credentials-flow). #### Authorization Code oder Auffrischungstoken-Flow \{#authorization-code-or-refresh-token-flow} -Alle offiziellen Logto SDKs unterstützen das Abrufen von Zugangstokens für globale API-Ressourcen mit dem Auffrischungstoken-Flow direkt. Eine Standard-OAuth 2.0 / OIDC-Clientbibliothek kann ebenfalls verwendet werden, um diesen Flow zu implementieren. +Alle offiziellen Logto SDKs unterstützen das Abrufen von Zugangstokens für globale API-Ressourcen direkt über den Auffrischungstoken-Flow. Auch eine Standard-OAuth 2.0 / OIDC-Clientbibliothek kann für diesen Flow verwendet werden. Beim Initialisieren des Logto-Clients füge den Ressourcenindikator zum `resources`-Parameter (Array) hinzu und die gewünschten Berechtigungen (Scopes) zum `scopes`-Parameter. -Sobald der Benutzer authentifiziert ist, übergib den Ressourcenindikator im `resource`-Parameter oder einem ähnlich benannten Parameter, wenn du das Zugangstoken anforderst (z. B. beim Aufruf von `getAccessToken()`). +Sobald der Benutzer authentifiziert ist, übergib den Ressourcenindikator im `resource`-Parameter oder einem ähnlich benannten Parameter, wenn das Zugangstoken angefordert wird (z. B. beim Aufruf von `getAccessToken()`). -Details zu jedem SDK findest du in den [Quick Starts](/quick-starts). +Details zu jedem SDK findest du in den [Schnellstarts](/quick-starts). -Beim Konfigurieren deines OAuth 2.0-Clients oder beim Initialisieren des Authorization Code Flows stelle sicher, dass du den `resource`-Parameter und die gewünschten Scopes in der Autorisierungsanfrage einschließt. +Beim Konfigurieren deines OAuth 2.0-Clients oder beim Initialisieren des Authorization Code Flows stelle sicher, dass du den `resource`-Parameter und die gewünschten Scopes in der Autorisierungsanfrage einfügst. -Einige Bibliotheken unterstützen den `resource`-Parameter nicht nativ, erlauben aber in der Regel das Hinzufügen zusätzlicher Parameter in der Autorisierungsanfrage. Prüfe die Dokumentation deiner Bibliothek für Details. +Einige Bibliotheken unterstützen den `resource`-Parameter nicht nativ, erlauben aber in der Regel das Hinzufügen zusätzlicher Parameter zur Autorisierungsanfrage. Prüfe die Dokumentation deiner Bibliothek für Details. -Hier ist ein nicht-normatives Beispiel für die Autorisierungsanfrage mit den Parametern `resource` und `scope`: +Hier ein nicht-normatives Beispiel für die Autorisierungsanfrage mit den Parametern `resource` und `scope`: -Sobald der Benutzer authentifiziert ist, erhältst du einen Authorization Code. Tausche diesen Code gegen ein Zugangstoken aus, indem du eine POST-Anfrage an Logtos `/oidc/token`-Endpunkt stellst und den `resource`-Parameter im Anfragekörper einschließt. +Nach erfolgreicher Authentifizierung erhältst du einen Authorization Code. Tausche diesen Code gegen ein Zugangstoken, indem du eine POST-Anfrage an Logtos `/oidc/token`-Endpunkt stellst und den `resource`-Parameter im Anfragekörper angibst. -Hier ist ein nicht-normatives Beispiel für die Token-Anfrage mit dem Authorization Code Grant Type: +Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ authorization_code: -Du kannst auch den Grant Type `refresh_token` verwenden, um ein neues Zugangstoken ohne Benutzerinteraktion zu erhalten, solange der `resource`-Parameter in der Anfrage enthalten ist. +Du kannst auch den Grant-Typ `refresh_token` verwenden, um ohne Benutzerinteraktion ein neues Zugangstoken zu erhalten, solange der `resource`-Parameter in der Anfrage enthalten ist. -Hier ist ein nicht-normatives Beispiel für die Token-Anfrage mit dem Refresh Token Grant Type: +Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ refresh_token: @@ -168,10 +168,10 @@ Für Maschine-zu-Maschine (M2M)-Szenarien kannst du den Client-Credentials-Flow Es gibt zwei wichtige Parameter, die in der Anfrage enthalten sein müssen: -- `resource`: Die Ressourcenindikator-URI der API, auf die du zugreifen möchtest (z. B. `https://api.yourapp.com`). +- `resource`: Die URI des Ressourcenindikators der API, auf die du zugreifen möchtest (z. B. `https://api.yourapp.com`). - `scope`: Die Berechtigungen, die du für die API anfordern möchtest (z. B. `read:products write:products`). -Hier ist ein nicht-normatives Beispiel für die Token-Anfrage mit dem Client Credentials Grant Type: +Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ client_credentials: -Setze eine Standard-API-Ressource in der Logto-Konsole. Tokens verwenden diese Zielgruppe, wenn im Token-Request kein resource-Parameter angegeben ist. +Lege eine Standard-API-Ressource in der Logto-Konsole fest. Tokens verwenden diese Zielgruppe, wenn im Token-Request kein resource-Parameter angegeben ist.
@@ -227,9 +227,9 @@ Setze eine Standard-API-Ressource in der Logto-Konsole. Tokens verwenden diese Z Überprüfe die folgenden häufigen Probleme: -- **Token-Signatur**: Stelle sicher, dass dein Backend die richtigen JWKs von Logto abruft -- **Token-Gültigkeit**: Stelle sicher, dass das Token nicht abgelaufen ist (`exp`-Anspruch) -- **Zielgruppe**: Prüfe, dass der `aud`-Anspruch mit deinem registrierten API-Ressourcenindikator übereinstimmt +- **Token-Signatur**: Stelle sicher, dass dein Backend die korrekten JWKs von Logto abruft +- **Token-Ablauf**: Stelle sicher, dass das Token nicht abgelaufen ist (`exp`-Anspruch) +- **Zielgruppe**: Prüfe, ob der `aud`-Anspruch mit deinem registrierten API-Ressourcenindikator übereinstimmt - **Erforderliche Scopes**: Stelle sicher, dass das Token die notwendigen Berechtigungen im `scope`-Anspruch enthält @@ -241,13 +241,43 @@ Setze eine Standard-API-Ressource in der Logto-Konsole. Tokens verwenden diese Z -Verwende ein [Personal Access Token](/user-management/personal-access-token), um authentifizierte Aufrufe zu simulieren. So kannst du deine API-Endpunkte testen, ohne einen vollständigen OAuth-Flow in deiner Client-Anwendung zu implementieren. +Nutze ein [persönliches Zugangstoken](/user-management/personal-access-token), um authentifizierte Aufrufe zu simulieren. So kannst du deine API-Endpunkte testen, ohne einen vollständigen OAuth-Flow in deiner Client-Anwendung zu implementieren. + + + +
+ + +### Kann ich Scope-Präfixe oder Kurzformen bei der Berechtigungsanfrage verwenden? \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +Nein. Scope-Namen müssen **exakt** mit den in deiner API-Ressource definierten Berechtigungsnamen übereinstimmen. Präfixe und Kurzformen funktionieren nicht als Platzhalter. + +**Beispiel:** + +Wenn deine API-Ressource definiert: + +- `read:elections` +- `write:elections` + +Musst du anfordern: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +Das funktioniert **NICHT**: + +```swift +scopes: ["read", "write"] // ❌ Stimmt nicht mit den Berechtigungsnamen überein +```
## Weiterführende Literatur \{#further-reading} -Wie man Zugangstokens validiert +Zugangstokens validieren RBAC in der Praxis: Sichere Autorisierung für deine Anwendung implementieren diff --git a/i18n/de/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/de/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index 5309eb88911..d44bc0212b1 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -14,7 +14,7 @@ Passe die Spracheinstellungen ganz einfach in der Logto-Konsole an – ganz ohne 2. **Sprache verwalten**: Klicke auf die Schaltfläche „Sprache verwalten“, um auf deine Sprachbibliothek zuzugreifen. - **Vorhandene Sprachen bearbeiten:** Passe Übersetzungen der von Logto bereitgestellten Sprachen an. Diese Sprachen können nicht gelöscht werden, aber deine Änderungen überschreiben die Standardwerte. - **Neue Sprache hinzufügen:** Klicke auf die Schaltfläche „Sprache hinzufügen“, wähle ein Sprach-Tag aus, gib deine Übersetzungen ein und speichere die Änderungen, um eine neue Sprache hinzuzufügen. -3. **Auto-Erkennung aktivieren:** Wenn aktiviert, wird die Anmeldeseite automatisch in der bevorzugten Sprache des Benutzers angezeigt, basierend auf den Geräteeinstellungen. +3. **Auto-Erkennung aktivieren:** Wenn aktiviert, wird die Anmeldeseite automatisch in der bevorzugten Sprache des Benutzers entsprechend den Geräteeinstellungen angezeigt. 4. **Standardsprache festlegen:** Du kannst eine Standardsprache aus deiner Sprachbibliothek auswählen. Sie wird verwendet, wenn die erkannte Benutzersprache in der aktuellen Sprachbibliothek nicht abgedeckt ist. Hier sind einige wichtige Begriffe, die du beim Verwalten von Sprachen kennen solltest: @@ -54,13 +54,13 @@ Du kannst auch die [PATCH /api/sign-in-exp](https://openapi.logto.io/group/endpo ## Sprachauflösung zur Laufzeit \{#runtime-language-resolution} -Zur Laufzeit wird die Sprache der Anmeldeerfahrung mit folgender Priorität bestimmt: +Zur Laufzeit wird die Sprache der Anmeldeerfahrung mit folgender Priorität ermittelt: 1. `ui_locales` OIDC-Parameter aus der aktuellen Authentifizierungsanfrage (das erste unterstützte Tag wird verwendet). Siehe [ui_locales](/end-user-flows/authentication-parameters/ui-locales). 2. Andernfalls, wenn „Auto-Erkennung“ aktiviert ist, die erkannte Sprache des Benutzerclients (z. B. aus dem HTTP-Header `Accept-Language`). 3. Andernfalls die Standardsprache des Mandanten in der Anmeldeerfahrung. -Diese Auflösung beeinflusst auch die E-Mail-Lokalisierung für durch die Interaktion ausgelöste Nachrichten. Mehr erfahren: [E-Mail-Vorlagen-Lokalisierung](/connectors/email-connectors/email-templates#email-template-localization). +Diese Auflösung wirkt sich auch auf die E-Mail-Lokalisierung für durch die Interaktion ausgelöste Nachrichten aus. Mehr erfahren: [E-Mail-Vorlagen-Lokalisierung](/connectors/email-connectors/email-templates#email-template-localization). ## Anwendungsfälle \{#use-cases} @@ -72,14 +72,14 @@ Die Logto-Anmeldeerfahrung i18n macht individuelle Sprachen möglich. Klicke auf das Sprach-Tag `ja`, um deine eigene japanische Übersetzung hinzuzufügen. -So kann der Benutzer, der deine Seite aus Japan besucht, die Inhalte auf Japanisch lesen, die du gerade aus dem Englischen übersetzt hast. +So kann der Benutzer, der deine Seite aus Japan aufruft, die Inhalte auf Japanisch lesen, die du gerade aus dem Englischen übersetzt hast. ## FAQs \{#faqs}
-### Was passiert, wenn die von mir hinzugefügte Sprache zur von Logto bereitgestellten Sprache wird? \{#what-if-the-language-i-added-becomes-logto-provided-language} +### Was passiert, wenn die von mir hinzugefügte Sprache zu einer von Logto bereitgestellten Sprache wird? \{#what-if-the-language-i-added-becomes-logto-provided-language} @@ -90,15 +90,28 @@ Neben dem Sprach-Tag auf der linken Seite erscheint ein von Logto bereitgestellt
-### Was ist, wenn ich nur einige wenige benutzerdefinierte Werte hinzugefügt habe? \{#what-if-i-only-added-a-few-custom-values} +### Was ist, wenn ich nur wenige benutzerdefinierte Werte hinzugefügt habe? \{#what-if-i-only-added-a-few-custom-values} -Was die Endbenutzer sehen, ist das Ergebnis der Zusammenführung beider Spalten. +Das, was die Endbenutzer sehen, ist das Ergebnis der Zusammenführung beider Spalten. Angenommen, du möchtest nur einen Teil der ursprünglichen von Logto bereitgestellten Inhalte anpassen. Der einzige Unterschied zwischen deinem Anmeldebildschirm und dem von Logto bereitgestellten besteht in den von dir bearbeiteten Schlüsseln. Der Rest des Inhalts bleibt unverändert.
+
+ + +### Wie kann ich einen Standard-Ländercode für Telefonnummern in der Anmeldeerfahrung festlegen? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +Der Ländercode für Telefonnummern in der [Anmeldeerfahrung](/end-user-flows/sign-up-and-sign-in/sign-up) richtet sich standardmäßig nach der Browsersprache des Benutzers. Wenn beispielsweise die Browsersprache eines Benutzers auf `fr` eingestellt ist, wird der Ländercode standardmäßig auf Frankreich (+33) gesetzt. + +Um den Standard-Ländercode für bestimmte Benutzer oder Regionen programmatisch zu steuern, kannst du den [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) Authentifizierungsparameter verwenden. Wenn du z. B. `ui_locales=ja` setzt, wird der Ländercode standardmäßig auf Japan (+81) gesetzt. + +
+ ## Verwandte Ressourcen \{#related-resources} diff --git a/i18n/de/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/de/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index a3155ccb5d3..4398fa98c7a 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -8,50 +8,54 @@ sidebar_position: 1 Passe das Aussehen und das Gefühl deiner Anmeldeseite an, indem du zu Konsole > Anmeldeerlebnis > Branding navigierst. In diesem Abschnitt kannst du wichtige Branding-Elemente ganz einfach anpassen. -**Markenfarbe** +### Markenfarbe \{#brand-color} Definiere die Primärfarbe, die im gesamten Anmeldeerlebnis verwendet wird, einschließlich primärer Schaltflächen, Links und anderer Komponenten. Ersetze das standardmäßige Logto-Lila durch die Farbe deiner Marke. Für den Dunkelmodus kann eine separate Markenfarbe festgelegt werden. -**Firmenlogo** +### Firmenlogo \{#company-logo} -Das Logo wird auf der Anmelde-Startseite, der Registrierungs-Startseite, der Lade-Seite und anderen Oberflächen mit unserer Erweiterung angezeigt. +Das Logo wird auf der Anmelde-Startseite, der Registrierungsseite, der Lade-Seite und anderen Oberflächen mit unserer Erweiterung angezeigt. -- Es gibt einige Einschränkungen für Bilder: Sie müssen unter 500 KB groß sein und im SVG-, PNG-, JPG-, JPEG- oder ICO-Format vorliegen. -- Wenn du das Logofeld leer lässt, wird das Logo nicht in der Oberfläche angezeigt. +- Es gibt einige Einschränkungen für Bilder: Sie müssen unter 500KB groß sein und im SVG-, PNG-, JPG-, JPEG- oder ICO-Format vorliegen. +- Wenn du das Logo-Feld leer lässt, wird das Logo nicht in der Oberfläche angezeigt. - Eine Version des Logos für den Dunkelmodus kann ebenfalls hochgeladen werden. -**Favicon** +### Favicon \{#favicon} -Ein Favicon ist ein kleines Symbol, das eine Website repräsentiert und im Browser-Tab, in Lesezeichen und anderen Bereichen der Browseroberfläche angezeigt wird. +Ein Favicon ist ein kleines Symbol, das eine Website repräsentiert und im Browser-Tab, in Lesezeichen und anderen Bereichen der Browser-Oberfläche angezeigt wird. -- Das Bild muss unter 500 KB groß sein und im SVG-, PNG-, JPG-, JPEG- oder ICO-Format vorliegen. Es wird empfohlen, ein quadratisches Bild hochzuladen, um eine gute Darstellung zu gewährleisten. +- Das Bild muss unter 500KB groß sein und im SVG-, PNG-, JPG-, JPEG- oder ICO-Format vorliegen. Es wird empfohlen, ein quadratisches Bild hochzuladen, um eine gute Darstellung zu gewährleisten. - Eine Version des Favicons für den Dunkelmodus kann ebenfalls hochgeladen werden. - Außerdem wird jetzt der Browser-Titel für verschiedene Abläufe (Anmelden / Registrieren / Passwort vergessen usw.) anstelle eines benutzerdefinierten Titels verwendet. -**Dunkelmodus** +### Dunkelmodus \{#dark-mode} Aktiviere den Dunkelmodus, um das Erscheinungsbild der Anmeldeseite automatisch an die Systemeinstellungen des Benutzers anzupassen. +### Logto-Branding ausblenden \{#hide-logto-branding} + +Standardmäßig zeigen die sofort einsatzbereiten Anmeldeseiten „Powered by Logto“ am unteren Rand an. Aktiviere die Option „Logto-Branding ausblenden“, um das Logto-Zeichen zu entfernen und ein sauberes, professionelles Anmeldeerlebnis zu schaffen, das ausschließlich deine eigene Markenidentität präsentiert. + ## App-spezifisches Branding \{#app-specific-branding} Wenn dein Multi-App-Geschäft App-spezifische Anmeldeerlebnisse benötigt, kannst du dies auf der Anwendungsdetailseite konfigurieren. Navigiere zu Konsole > Anwendungen. -Durch das Aktivieren des "App-spezifischen Anmeldeerlebnisses" kannst du spezifische Branding-Logos, Favicons, Farben und sogar [benutzerdefiniertes CSS](/customization/custom-css) für jede App festlegen. Wenn eine Anmeldung von einer App mit aktiviertem App-spezifischen Branding initiiert wird, wird das Anmeldeerlebnis entsprechend den App-spezifischen Branding-Einstellungen angepasst; andernfalls werden die Standard-Einstellungen des Omni-Anmeldeerlebnisses verwendet. +Durch das Aktivieren von „App-spezifisches Anmeldeerlebnis“ kannst du für jede App spezifische Branding-Logos, Favicons, Farben und sogar [benutzerdefiniertes CSS](/customization/custom-css) festlegen. Wenn eine Anmeldung von einer App mit aktiviertem App-spezifischem Branding ausgelöst wird, wird das Anmeldeerlebnis entsprechend den App-spezifischen Branding-Einstellungen angepasst; andernfalls werden die Standard-Einstellungen des Omni-Anmeldeerlebnisses verwendet. -Sowohl helle als auch dunkle Modus-Einstellungen sind für das App-spezifische Branding verfügbar. Die Einstellungen für den Dunkelmodus werden nur wirksam, wenn der Dunkelmodus in den [Omni-Anmeldeerlebnis](#omni-sign-in-experience)-Einstellungen aktiviert ist. +Sowohl Einstellungen für den hellen als auch für den dunklen Modus sind für das App-spezifische Branding verfügbar. Die Einstellungen für den Dunkelmodus werden nur wirksam, wenn der Dunkelmodus in den [Omni-Anmeldeerlebnis](#omni-sign-in-experience)-Einstellungen aktiviert ist. ## Organisationsspezifisches Branding \{#organization-specific-branding} Um das Logo der Organisation deines Kunden dynamisch im Anmeldeerlebnis anzuzeigen, kannst du die Organisationslogos auf der Seite mit den Organisationseinstellungen hochladen. Navigiere zu Konsole > Organisationen. -Durch das Aktivieren des "Organisationsspezifischen Anmeldeerlebnisses" kannst du, wie beim App-spezifischen Branding, auch spezifische Branding-Logos, Favicons, Farben und [benutzerdefiniertes CSS](/customization/custom-css) für jede Organisation festlegen. +Durch das Aktivieren von „Organisationsspezifisches Anmeldeerlebnis“ kannst du, wie beim App-spezifischen Branding, für jede Organisation spezifische Branding-Logos, Favicons, Farben und [benutzerdefiniertes CSS](/customization/custom-css) festlegen. Wenn du dann eine Anmeldung auslöst, kannst du die Organisations-ID im Parameter `organization_id` übergeben, um Logto mitzuteilen, welches Organisationslogo angezeigt werden soll. Zum Beispiel, um das Organisationslogo für die Organisations-ID `123456` anzuzeigen: - Wenn du das Logto SDK verwendest, kannst du den Parameter `organization_id` im Objekt `extraParams` der Methode `signIn` übergeben. - Wenn du einen OIDC-Client verwendest, kannst du den Parameter `organization_id` beim Aufruf des [Autorisierungsendpunkts](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) übergeben. -Sowohl helle als auch dunkle Modus-Einstellungen sind für das organisationsspezifische Branding verfügbar. Die Einstellungen für den Dunkelmodus werden nur wirksam, wenn der Dunkelmodus in den [Omni-Anmeldeerlebnis](#omni-sign-in-experience)-Einstellungen aktiviert ist. +Sowohl Einstellungen für den hellen als auch für den dunklen Modus sind für das organisationsspezifische Branding verfügbar. Die Einstellungen für den Dunkelmodus werden nur wirksam, wenn der Dunkelmodus in den [Omni-Anmeldeerlebnis](#omni-sign-in-experience)-Einstellungen aktiviert ist. :::note Wenn sowohl App-spezifisches Branding als auch organisationsspezifisches Branding aktiviert sind, hat das organisationsspezifische Branding Vorrang. Die vollständige Reihenfolge der Priorität ist: @@ -64,7 +68,7 @@ Hier ist ein Beispiel, wie du den Parameter `organization_id` in der Methode `si ```tsx logtoClient.signIn({ - // ...andere Parameter + // ...weitere Parameter redirectUri: 'https://your-redirect-uri', extraParams: { organization_id: '123456', diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index c97a522f713..3e05bc3514e 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -1,5 +1,5 @@ --- -description: Erfahre, wie du die Account API zur Verwaltung von Benutzern nutzt (Learn how to use the Account API to manage user) +description: Erfahre, wie du die Account API zur Verwaltung von Benutzern nutzt sidebar_position: 1 --- @@ -7,12 +7,12 @@ sidebar_position: 1 ## Was ist die Logto Account API \{#what-is-logto-account-api} -Die Logto Account API ist eine umfassende Sammlung von APIs, die Endbenutzern direkten API-Zugriff ermöglicht, ohne den Umweg über die Management API gehen zu müssen. Hier die wichtigsten Punkte: +Die Logto Account API ist eine umfassende Sammlung von APIs, die Endbenutzern direkten API-Zugriff ermöglicht, ohne die Management API verwenden zu müssen. Hier die wichtigsten Punkte: -- Direkter Zugriff: Die Account API ermöglicht es Endbenutzern, direkt auf ihr eigenes Konto-Profil zuzugreifen und dieses zu verwalten, ohne dass die Management API zwischengeschaltet werden muss. -- Verwaltung von Benutzerprofilen und Identitäten: Benutzer können ihre Profile und Sicherheitseinstellungen vollständig verwalten, einschließlich der Möglichkeit, Identitätsinformationen wie E-Mail, Telefon und Passwort zu aktualisieren sowie soziale Verbindungen zu verwalten. MFA und SSO-Unterstützung folgen in Kürze. +- Direkter Zugriff: Die Account API ermöglicht es Endbenutzern, direkt auf ihr eigenes Konto und Profil zuzugreifen und diese zu verwalten, ohne dass die Management API zwischengeschaltet werden muss. +- Verwaltung von Benutzerprofilen und Identitäten: Benutzer können ihre Profile und Sicherheitseinstellungen vollständig verwalten, einschließlich der Möglichkeit, Identitätsinformationen wie E-Mail, Telefon und Passwort zu aktualisieren sowie soziale Verbindungen zu verwalten. Unterstützung für MFA und SSO folgt in Kürze. - Globale Zugangskontrolle: Administratoren haben vollständige, globale Kontrolle über die Zugriffseinstellungen und können jedes Feld individuell anpassen. -- Nahtlose Autorisierung (Authorization): Autorisierung (Authorization) ist jetzt einfacher denn je! Verwende einfach `client.getAccessToken()`, um ein opakes Zugangstoken (Opaque token) für OP (Logto) zu erhalten, und füge es dem Authorization-Header als `Bearer ` hinzu. +- Nahtlose Autorisierung (Authorization): Autorisierung ist einfacher denn je! Verwende einfach `client.getAccessToken()`, um ein opakes Zugangstoken (Opaque token) für OP (Logto) zu erhalten, und füge es dem Authorization-Header als `Bearer ` hinzu. Mit der Logto Account API kannst du ein individuelles Kontoverwaltungssystem wie eine Profilseite erstellen, das vollständig in Logto integriert ist. @@ -34,34 +34,34 @@ SSO-Kontoansicht und Kontolöschungsfunktionen sind derzeit über die Logto Mana ## Wie aktiviere ich die Account API \{#how-to-enable-account-api} -Navigiere zu Konsole > Anmeldung & Konto > Kontozentrale. +Navigiere zu Konsole > Anmeldung & Konto > Account Center. Die Account API ist standardmäßig deaktiviert, daher sind ihre Zugriffskontrollen gesperrt. Aktiviere **Account API aktivieren**, um sie einzuschalten. -Nach der Aktivierung kannst du die Berechtigungen pro Feld für Identifikatoren, Profildaten und Drittanbieter-Token-Zugriff konfigurieren. Jedes Feld unterstützt `Off`, `ReadOnly` oder `Edit`; der Standardwert ist `Off`. +Nach der Aktivierung kannst du die Berechtigungen pro Feld für Identifikatoren, Profildaten und Drittanbieter-Token-Zugriff konfigurieren. Jedes Feld unterstützt `Aus`, `Nur Lesen` oder `Bearbeiten`; der Standardwert ist `Aus`. 1. **Sicherheitsfelder**: - - Zu den Feldern gehören: primäre E-Mail, primäres Telefon, soziale Identitäten, Passwort und MFA. - - Bevor Endbenutzer diese Felder bearbeiten, müssen sie ihre Identität per Passwort, E-Mail oder SMS verifizieren, um eine 10-minütige Verifizierungsdatensatz-ID zu erhalten. Siehe [Verifizierungsdatensatz-ID erhalten](#get-a-verification-record-id). - - Um WebAuthn-Passkeys für MFA zu verwenden, füge die Domains deiner Frontend-App zu **WebAuthn Related Origins** hinzu, damit Kontozentrale und Anmeldungserlebnis Passkeys teilen können. Siehe [Neuen WebAuthn-Passkey verknüpfen](#link-a-new-webauthn-passkey). + - Felder umfassen: primäre E-Mail, primäres Telefon, soziale Identitäten, Passwort und MFA. + - Bevor Endbenutzer diese Felder bearbeiten, müssen sie ihre Identität per Passwort, E-Mail oder SMS verifizieren, um eine 10-minütige Verifizierungs-Record-ID zu erhalten. Siehe [Verifizierungs-Record-ID erhalten](#get-a-verification-record-id). + - Um WebAuthn-Passkeys für MFA zu verwenden, füge die Domains deiner Frontend-App zu **WebAuthn Related Origins** hinzu, damit Account Center und Anmeldungserlebnis Passkeys teilen können. Siehe [Neuen WebAuthn-Passkey verknüpfen](#link-a-new-webauthn-passkey). 2. **Profilfelder**: - - Zu den Feldern gehören: Benutzername, Name, Avatar, [Profil](/user-management/user-data#profile) (weitere Standard-Profilattribute) und [benutzerdefinierte Daten](/user-management/user-data#custom-data). + - Felder umfassen: Benutzername, Name, Avatar, [Profil](/user-management/user-data#profile) (weitere Standard-Profilattribute) und [benutzerdefinierte Daten](/user-management/user-data#custom-data). - Endbenutzer können diese ohne zusätzliche Verifizierung bearbeiten. -3. **Secret Vault**: Für OIDC- oder OAuth-Sozial- und Enterprise-Connectors speichert der Logto [Secret Vault](/secret-vault/federated-token-set) Drittanbieter-Zugangs- und Auffrischungstokens nach der Authentifizierung sicher. Apps können dann externe APIs aufrufen, wie z. B. das Synchronisieren von Google-Kalender-Ereignissen, ohne die Benutzer erneut zur Anmeldung aufzufordern. Die Token-Abfrage ist automatisch verfügbar, sobald die Account API aktiviert ist. +3. **Secret Vault**: Für OIDC- oder OAuth-Sozial- und Enterprise-Connectors speichert der Logto [Secret Vault](/secret-vault/federated-token-set) Drittanbieter-Zugangs- und Auffrischungstokens sicher nach der Authentifizierung. Apps können dann externe APIs aufrufen, z. B. Google Kalender synchronisieren, ohne die Benutzer erneut zur Anmeldung aufzufordern. Das Abrufen von Tokens ist automatisch verfügbar, sobald die Account API aktiviert ist. ## Wie greife ich auf die Account API zu \{#how-to-access-account-api} :::note -Um sicherzustellen, dass das Zugangstoken (Access token) die entsprechenden Berechtigungen hat, stelle sicher, dass du die entsprechenden Berechtigungen (Scopes) in deiner Logto-Konfiguration richtig eingerichtet hast. +Um sicherzustellen, dass das Zugangstoken die entsprechenden Berechtigungen hat, stelle sicher, dass du die entsprechenden Berechtigungen (Scopes) in deiner Logto-Konfiguration richtig eingestellt hast. -Zum Beispiel musst du für die `POST /api/my-account/primary-email` API die Berechtigung (Scope) `email` konfigurieren; für die `POST /api/my-account/primary-phone` API die Berechtigung (Scope) `phone`. +Zum Beispiel musst du für die `POST /api/my-account/primary-email` API die `email`-Berechtigung konfigurieren; für die `POST /api/my-account/primary-phone` API die `phone`-Berechtigung. ```ts import { type LogtoConfig, UserScope } from '@logto/js'; const config: LogtoConfig = { // ...andere Optionen - // Füge die passenden Berechtigungen (Scopes) hinzu, die zu deinen Anwendungsfällen passen. + // Füge die passenden Berechtigungen hinzu, die zu deinem Anwendungsfall passen. scopes: [ UserScope.Email, // Für `{POST,DELETE} /api/my-account/primary-email` APIs UserScope.Phone, // Für `{POST,DELETE} /api/my-account/primary-phone` APIs @@ -75,15 +75,15 @@ const config: LogtoConfig = { ::: -### Zugangstoken (Access token) abrufen \{#fetch-an-access-token} +### Zugangstoken abrufen \{#fetch-an-access-token} -Nachdem du das SDK in deiner Anwendung eingerichtet hast, kannst du die Methode `client.getAccessToken()` verwenden, um ein Zugangstoken (Access token) abzurufen. Dieses Token ist ein opaker Token (Opaque token), das für den Zugriff auf die Account API verwendet werden kann. +Nachdem du das SDK in deiner Anwendung eingerichtet hast, kannst du die Methode `client.getAccessToken()` verwenden, um ein Zugangstoken abzurufen. Dieses Token ist ein opaker Token (Opaque token), das für den Zugriff auf die Account API verwendet werden kann. Wenn du das offizielle SDK nicht verwendest, solltest du das `resource`-Feld für die Zugangstoken-Anfrage an `/oidc/token` leer lassen. -### Zugriff auf die Account API mit Zugangstoken (Access token) \{#access-account-api-using-access-token} +### Zugriff auf die Account API mit Zugangstoken \{#access-account-api-using-access-token} -Du solltest das Zugangstoken (Access token) im `Authorization`-Feld der HTTP-Header im Bearer-Format (`Bearer YOUR_TOKEN`) einfügen, wenn du mit der Account API interagierst. +Du solltest das Zugangstoken im `Authorization`-Feld der HTTP-Header im Bearer-Format (`Bearer YOUR_TOKEN`) einfügen, wenn du mit der Account API interagierst. Hier ein Beispiel, um die Benutzerkontoinformationen abzurufen: @@ -114,11 +114,11 @@ Die Antwort sieht beispielsweise so aus: } ``` -Die Antwortfelder können je nach Einstellungen der Kontozentrale variieren. +Die Antwortfelder können je nach Account Center-Einstellungen variieren. ### Grundlegende Kontoinformationen aktualisieren \{#update-basic-account-information} -Zu den grundlegenden Kontoinformationen gehören Benutzername, Name, Avatar, benutzerdefinierte Daten und andere Profilinformationen. +Grundlegende Kontoinformationen umfassen Benutzername, Name, Avatar, benutzerdefinierte Daten und andere Profilinformationen. Um **Benutzername, Name, Avatar und customData** zu aktualisieren, kannst du den [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) Endpunkt verwenden. @@ -129,7 +129,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account \ --data-raw '{"username":"...","name":"...","avatar":"..."}' ``` -Um andere Profilinformationen wie **familyName, givenName, middleName, nickname, profile (Profilseiten-URL), website, gender, birthdate, zoneinfo, locale und address** zu aktualisieren, kannst du den [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) Endpunkt verwenden. +Um andere Profilinformationen zu aktualisieren, einschließlich **familyName, givenName, middleName, nickname, profile (Profilseiten-URL), website, gender, birthdate, zoneinfo, locale und address**, kannst du den [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) Endpunkt verwenden. ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ @@ -142,11 +142,11 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ Aus Sicherheitsgründen erfordert die Account API eine zusätzliche Autorisierungsebene für Vorgänge, die Identifikatoren und andere sensible Informationen betreffen. -### Verifizierungsdatensatz-ID erhalten \{#get-a-verification-record-id} +### Verifizierungs-Record-ID erhalten \{#get-a-verification-record-id} -Zuerst musst du eine **Verifizierungsdatensatz-ID** mit einer Gültigkeit von 10 Minuten (TTL) erhalten. Diese kann verwendet werden, um die Identität des Benutzers zu verifizieren, bevor sensible Informationen aktualisiert werden. Das bedeutet, sobald ein Benutzer seine Identität erfolgreich per Passwort, E-Mail-Verifizierungscode oder SMS-Verifizierungscode bestätigt hat, hat er 10 Minuten Zeit, um seine authentifizierungsbezogenen Daten zu aktualisieren, einschließlich Identifikatoren, Zugangsdaten, Social-Account-Verknüpfung und MFA. +Zuerst musst du eine **Verifizierungs-Record-ID** mit einer 10-minütigen Ablaufzeit (TTL) erhalten. Diese kann verwendet werden, um die Identität des Benutzers zu verifizieren, bevor sensible Informationen aktualisiert werden. Das bedeutet: Sobald ein Benutzer seine Identität erfolgreich per Passwort, E-Mail-Verifizierungscode oder SMS-Verifizierungscode bestätigt hat, hat er 10 Minuten Zeit, um seine authentifizierungsbezogenen Daten wie Identifikatoren, Zugangsdaten, Social Account Linking und MFA zu aktualisieren. -Um eine Verifizierungsdatensatz-ID zu erhalten, kannst du [das Benutzerpasswort verifizieren](#verify-the-users-password) oder [einen Verifizierungscode an die E-Mail oder das Telefon des Benutzers senden](#verify-by-sending-a-verification-code-to-the-users-email-or-phone). +Um eine Verifizierungs-Record-ID zu erhalten, kannst du [das Benutzerpasswort verifizieren](#verify-the-users-password) oder [einen Verifizierungscode an die E-Mail oder das Telefon des Benutzers senden](#verify-by-sending-a-verification-code-to-the-users-email-or-phone). #### Passwort des Benutzers verifizieren \{#verify-the-users-password} @@ -169,10 +169,10 @@ Die Antwort sieht beispielsweise so aus: #### Verifizierungscode an die E-Mail oder das Telefon des Benutzers senden \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} :::note -Um diese Methode zu verwenden, musst du den [E-Mail-Connector konfigurieren](/connectors/email-connectors/) oder den [SMS-Connector konfigurieren](/connectors/sms-connectors/) und sicherstellen, dass die `UserPermissionValidation`-Vorlage konfiguriert ist. +Um diese Methode zu verwenden, musst du den [E-Mail-Connector](/connectors/email-connectors/) oder [SMS-Connector](/connectors/sms-connectors/) konfigurieren und sicherstellen, dass die `UserPermissionValidation`-Vorlage eingerichtet ist. ::: -Am Beispiel E-Mail: Fordere einen neuen Verifizierungscode an und erhalte die Verifizierungsdatensatz-ID: +Am Beispiel E-Mail: Fordere einen neuen Verifizierungscode an und erhalte die Verifizierungs-Record-ID: ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ @@ -190,7 +190,7 @@ Die Antwort sieht beispielsweise so aus: } ``` -Nach Erhalt des Verifizierungscodes kannst du ihn verwenden, um den Verifizierungsstatus des Verifizierungsdatensatzes zu aktualisieren. +Nach Erhalt des Verifizierungscodes kannst du ihn verwenden, um den Verifizierungsstatus des Verifizierungs-Records zu aktualisieren. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \ @@ -199,15 +199,15 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"123456"}' ``` -Nach der Verifizierung des Codes kannst du nun die Verifizierungsdatensatz-ID verwenden, um den Identifikator des Benutzers zu aktualisieren. +Nach erfolgreicher Verifizierung des Codes kannst du nun die Verifizierungs-Record-ID verwenden, um den Identifikator des Benutzers zu aktualisieren. Um mehr über Verifizierungen zu erfahren, siehe [Sicherheitsverifizierung über die Account API](/end-user-flows/security-verification). -### Anfrage mit Verifizierungsdatensatz-ID senden \{#send-request-with-verification-record-id} +### Anfrage mit Verifizierungs-Record-ID senden \{#send-request-with-verification-record-id} -Wenn du eine Anfrage zum Aktualisieren des Benutzeridentifikators sendest, musst du die Verifizierungsdatensatz-ID im Anfrage-Header mit dem Feld `logto-verification-id` angeben. +Wenn du eine Anfrage zum Aktualisieren des Benutzeridentifikators sendest, musst du die Verifizierungs-Record-ID im Request-Header mit dem Feld `logto-verification-id` angeben. -### Passwort des Benutzers aktualisieren \{#update-users-password} +### Benutzerpasswort aktualisieren \{#update-users-password} Um das Passwort des Benutzers zu aktualisieren, kannst du den [`POST /api/my-account/password`](https://openapi.logto.io/operation/operation-updatepassword) Endpunkt verwenden. @@ -219,13 +219,17 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +Wie Passwörter, die während der Registrierung erstellt wurden, müssen auch über die Account API gesetzte Passwörter der von dir konfigurierten [Passwortrichtlinie](/security/password-policy) in Konsole > Sicherheit > Passwortrichtlinie entsprechen. Logto gibt detaillierte Validierungsergebnisse und Fehlermeldungen zurück, wenn das Passwort die Richtlinie nicht erfüllt. +::: + ### Neue E-Mail aktualisieren oder verknüpfen \{#update-or-link-new-email} :::note -Um diese Methode zu verwenden, musst du den [E-Mail-Connector konfigurieren](/connectors/email-connectors/) und sicherstellen, dass die `BindNewIdentifier`-Vorlage konfiguriert ist. +Um diese Methode zu verwenden, musst du den [E-Mail-Connector](/connectors/email-connectors/) konfigurieren und sicherstellen, dass die `BindNewIdentifier`-Vorlage eingerichtet ist. ::: -Um eine neue E-Mail zu aktualisieren oder zu verknüpfen, musst du zuerst den Besitz der E-Mail nachweisen. +Um eine neue E-Mail zu aktualisieren oder zu verknüpfen, musst du zunächst den Besitz der E-Mail nachweisen. Rufe den [`POST /api/verifications/verification-code`](https://openapi.logto.io/operation/operation-createverificationbyverificationcode) Endpunkt auf, um einen Verifizierungscode anzufordern. @@ -245,7 +249,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}' ``` -Nach der Verifizierung des Codes kannst du nun [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) aufrufen, um die E-Mail des Benutzers zu aktualisieren. Setze die `verificationId` im Anfragekörper als `newIdentifierVerificationRecordId`. +Nach erfolgreicher Verifizierung des Codes kannst du nun [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) aufrufen, um die E-Mail des Benutzers zu aktualisieren. Setze die `verificationId` im Request-Body als `newIdentifierVerificationRecordId`. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -255,6 +259,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +Wie E-Mails, die während der Registrierung erfasst werden, muss jede über die Account API verknüpfte E-Mail die von dir konfigurierte [Blocklist](/security/blocklist) in Konsole > Sicherheit > Blocklist bestehen. Logto lehnt die Anfrage ab und gibt eine detaillierte Fehlermeldung zurück, wenn die E-Mail gegen die Richtlinie verstößt. +::: + ### E-Mail des Benutzers entfernen \{#remove-the-users-email} Um die E-Mail des Benutzers zu entfernen, kannst du den [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) Endpunkt verwenden. @@ -268,7 +276,7 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### Telefon verwalten \{#manage-phone} :::note -Um diese Methode zu verwenden, musst du den [SMS-Connector konfigurieren](/connectors/sms-connectors/) und sicherstellen, dass die `BindNewIdentifier`-Vorlage konfiguriert ist. +Um diese Methode zu verwenden, musst du den [SMS-Connector](/connectors/sms-connectors/) konfigurieren und sicherstellen, dass die `BindNewIdentifier`-Vorlage eingerichtet ist. ::: Ähnlich wie beim Aktualisieren der E-Mail kannst du den [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) Endpunkt verwenden, um ein neues Telefon zu aktualisieren oder zu verknüpfen. Und den [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) Endpunkt, um das Telefon des Benutzers zu entfernen. @@ -285,10 +293,10 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ ``` - `connectorId`: Die ID des [Social Connectors](/connectors/social-connectors/). -- `redirectUri`: Die Weiterleitungs-URL nach der Autorisierung durch den Benutzer. Du solltest eine Webseite unter dieser URL hosten und den Callback abfangen. -- `state`: Der State, der nach der Autorisierung durch den Benutzer zurückgegeben wird. Es handelt sich um einen zufälligen String, der zur Verhinderung von CSRF-Angriffen verwendet wird. +- `redirectUri`: Die Weiterleitungs-URL nach der Autorisierung der Anwendung durch den Benutzer. Du solltest eine Webseite unter dieser URL hosten und den Callback erfassen. +- `state`: Der State, der nach der Autorisierung der Anwendung zurückgegeben wird. Es handelt sich um einen zufälligen String, der zur Verhinderung von CSRF-Angriffen verwendet wird. -In der Antwort findest du eine `verificationRecordId`, die du für später aufbewahren solltest. +In der Antwort findest du eine `verificationRecordId`, die du für die spätere Verwendung aufbewahren solltest. Nachdem der Benutzer die Anwendung autorisiert hat, erhältst du einen Callback an die `redirectUri` mit dem Parameter `state`. Dann kannst du den [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) Endpunkt verwenden, um die soziale Verbindung zu verifizieren. @@ -299,7 +307,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -Das `connectorData` ist die von dem Social Connector nach der Autorisierung des Benutzers zurückgegebene Daten. Du musst die Query-Parameter aus der `redirectUri` auf deiner Callback-Seite extrahieren und sie als JSON im Feld `connectorData` übergeben. +Das `connectorData` ist die von dem Social Connector nach der Autorisierung der Anwendung zurückgegebene Daten. Du musst die Query-Parameter von der `redirectUri` auf deiner Callback-Seite extrahieren und sie als JSON im Feld `connectorData` übergeben. Abschließend kannst du den [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) Endpunkt verwenden, um die soziale Verbindung zu verknüpfen. @@ -324,16 +332,16 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connecto ### Neuen WebAuthn-Passkey verknüpfen \{#link-a-new-webauthn-passkey} :::note -Denke daran, zuerst [MFA und WebAuthn zu aktivieren](/end-user-flows/mfa). +Denke daran, zuerst [MFA und WebAuthn](/end-user-flows/mfa) zu aktivieren. ::: :::note -Um diese Methode zu verwenden, musst du das Feld `mfa` in den [Einstellungen der Kontozentrale](#how-to-enable-account-api) aktivieren. +Um diese Methode zu verwenden, musst du das Feld `mfa` in den [Account Center Einstellungen](#how-to-enable-account-api) aktivieren. ::: -**Schritt 1: Ursprungs-URL deiner Frontend-App zu den Related Origins hinzufügen** +**Schritt 1: Ursprungsdomain deiner Frontend-App zu den Related Origins hinzufügen** -WebAuthn-Passkeys sind an einen bestimmten Hostnamen gebunden, der als **Relying Party ID (RP ID)** bezeichnet wird. Nur Anwendungen, die auf dem Origin der RP ID gehostet werden, können diese Passkeys registrieren oder authentifizieren. +WebAuthn-Passkeys sind an einen bestimmten Hostnamen gebunden, den sogenannten **Relying Party ID (RP ID)**. Nur Anwendungen, die auf dem Ursprung der RP ID gehostet werden, können sich mit diesen Passkeys registrieren oder authentifizieren. Da deine Frontend-Anwendung die Account API von einer anderen Domain als die Logto-Authentifizierungsseiten aufruft, musst du **Related Origins** konfigurieren, um Cross-Origin-Passkey-Operationen zu ermöglichen. @@ -344,7 +352,7 @@ Da deine Frontend-Anwendung die Account API von einer anderen Domain als die Log **Related Origins konfigurieren:** -Verwende den [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) Endpunkt, um den Origin deiner Frontend-Anwendung hinzuzufügen. Wenn deine App beispielsweise unter `https://account.example.com` läuft: +Verwende den [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) Endpunkt, um den Ursprung deiner Frontend-Anwendung hinzuzufügen. Wenn dein Account Center z. B. unter `https://account.example.com` läuft: ```bash curl -X PATCH https://[tenant-id].logto.app/api/account-center \ @@ -353,11 +361,21 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -Um mehr über Related Origins zu erfahren, siehe die [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) Dokumentation. +:::note + +WebAuthn unterstützt bis zu 5 eindeutige eTLD+1-Labels für Related Origins. Die eTLD+1 (effective top-level domain plus one label) ist der registrierbare Domain-Teil. Zum Beispiel: + +- `https://example.com`, `https://app.example.com` und `https://auth.example.com` zählen als **ein** Label (`example.com`) +- `https://shopping.com`, `https://shopping.co.uk` und `https://shopping.co.jp` zählen ebenfalls als **ein** Label (`shopping`) +- `https://example.com` und `https://another.com` zählen als **zwei** Labels + +Wenn du mehr als 5 verschiedene Domains als Related Origins unterstützen musst, siehe die [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) Dokumentation für Details. + +::: **Schritt 2: Neue Registrierungsoptionen anfordern** -Verwende den [`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) Endpunkt, um eine Registrierung für einen neuen Passkey anzufordern. Logto erlaubt jedem Benutzerkonto die Registrierung mehrerer Passkeys. +Verwende den [`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) Endpunkt, um eine Registrierung für einen neuen Passkey anzufordern. Logto erlaubt es jedem Benutzerkonto, mehrere Passkeys zu registrieren. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration \ @@ -393,7 +411,7 @@ const response = await startRegistration({ Verwende den [`POST /api/verifications/web-authn/registration/verify`](https://openapi.logto.io/operation/operation-verifywebauthnregistration) Endpunkt, um die Passkey-Registrierung zu verifizieren. -In diesem Schritt wird die vom Authenticator generierte kryptografische Signatur überprüft, um sicherzustellen, dass der Passkey legitim erstellt wurde und während der Übertragung nicht manipuliert wurde. +Dieser Schritt überprüft die vom Authenticator generierte kryptografische Signatur, um sicherzustellen, dass der Passkey legitim erstellt wurde und während der Übertragung nicht manipuliert wurde. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration/verify \ @@ -403,7 +421,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registrat ``` - `payload`: Die Antwort aus dem lokalen Browser in Schritt 2. -- `verificationRecordId`: Die vom Server in Schritt 1 zurückgegebene Verifizierungsdatensatz-ID. +- `verificationRecordId`: Die vom Server in Schritt 1 zurückgegebene Verifizierungs-Record-ID. **Schritt 5: Passkey verknüpfen** @@ -417,9 +435,9 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"WebAuthn","newIdentifierVerificationRecordId":"..."}' ``` -- `verification_record_id`: Eine gültige Verifizierungsdatensatz-ID, die durch die Verifizierung des bestehenden Faktors des Benutzers gewährt wurde. Siehe [Verifizierungsdatensatz-ID erhalten](#get-a-verification-record-id) für Details. +- `verification_record_id`: Eine gültige Verifizierungs-Record-ID, die durch Verifizierung des bestehenden Faktors des Benutzers gewährt wurde. Siehe [Verifizierungs-Record-ID erhalten](#get-a-verification-record-id) für Details. - `type`: Der Typ des MFA-Faktors, aktuell wird nur `WebAuthn` unterstützt. -- `newIdentifierVerificationRecordId`: Die vom Server in Schritt 1 zurückgegebene Verifizierungsdatensatz-ID. +- `newIdentifierVerificationRecordId`: Die vom Server in Schritt 1 zurückgegebene Verifizierungs-Record-ID. ### Bestehende WebAuthn-Passkeys verwalten \{#manage-existing-webauthn-passkeys} @@ -450,7 +468,7 @@ Die Antwort sieht beispielsweise so aus: - `name`: Der Name des Passkeys, optionales Feld. - `agent`: Der User-Agent des Passkeys. -Den Passkey-Namen kannst du mit dem [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname) Endpunkt aktualisieren: +Aktualisiere den Passkey-Namen mit [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname): ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId}/name \ @@ -460,7 +478,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{ve --data-raw '{"name":"..."}' ``` -Den Passkey kannst du mit dem [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) Endpunkt löschen: +Lösche den Passkey mit [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification): ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId} \ @@ -471,11 +489,11 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{v ### Neues TOTP verknüpfen \{#link-a-new-totp} :::note -Denke daran, zuerst [MFA und TOTP zu aktivieren](/end-user-flows/mfa). +Denke daran, zuerst [MFA und TOTP](/end-user-flows/mfa) zu aktivieren. ::: :::note -Um diese Methode zu verwenden, musst du das Feld `mfa` in den [Einstellungen der Kontozentrale](#how-to-enable-account-api) aktivieren. +Um diese Methode zu verwenden, musst du das Feld `mfa` in den [Account Center Einstellungen](#how-to-enable-account-api) aktivieren. ::: **Schritt 1: TOTP-Secret generieren** @@ -498,7 +516,7 @@ Die Antwort sieht beispielsweise so aus: **Schritt 2: TOTP-Secret dem Benutzer anzeigen** -Verwende das Secret, um einen QR-Code zu generieren oder zeige es dem Benutzer direkt an. Der Benutzer sollte es in seiner Authenticator-App (wie Google Authenticator, Microsoft Authenticator oder Authy) hinzufügen. +Verwende das Secret, um einen QR-Code zu generieren oder zeige es dem Benutzer direkt an. Der Benutzer sollte es in seine Authenticator-App (wie Google Authenticator, Microsoft Authenticator oder Authy) hinzufügen. Das URI-Format für den QR-Code sollte sein: @@ -514,7 +532,7 @@ otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp **Schritt 3: TOTP-Faktor binden** -Nachdem der Benutzer das Secret zu seiner Authenticator-App hinzugefügt hat, muss er es verifizieren und an sein Konto binden. Verwende dazu den [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) Endpunkt. +Nachdem der Benutzer das Secret zu seiner Authenticator-App hinzugefügt hat, muss er es verifizieren und an sein Konto binden. Verwende den [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) Endpunkt, um den TOTP-Faktor zu binden. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -524,22 +542,22 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"Totp","secret":"..."}' ``` -- `verification_record_id`: Eine gültige Verifizierungsdatensatz-ID, die durch die Verifizierung des bestehenden Faktors des Benutzers gewährt wurde. Siehe [Verifizierungsdatensatz-ID erhalten](#get-a-verification-record-id) für Details. +- `verification_record_id`: Eine gültige Verifizierungs-Record-ID, die durch Verifizierung des bestehenden Faktors des Benutzers gewährt wurde. Siehe [Verifizierungs-Record-ID erhalten](#get-a-verification-record-id) für Details. - `type`: Muss `Totp` sein. - `secret`: Das in Schritt 1 generierte TOTP-Secret. :::note -Ein Benutzer kann nur einen TOTP-Faktor gleichzeitig haben. Wenn der Benutzer bereits einen TOTP-Faktor hat, führt der Versuch, einen weiteren hinzuzufügen, zu einem 422-Fehler. +Ein Benutzer kann nur einen TOTP-Faktor gleichzeitig haben. Wenn bereits ein TOTP-Faktor existiert, führt der Versuch, einen weiteren hinzuzufügen, zu einem 422-Fehler. ::: ### Backup-Codes verwalten \{#manage-backup-codes} :::note -Denke daran, zuerst [MFA und Backup-Codes zu aktivieren](/end-user-flows/mfa). +Denke daran, zuerst [MFA und Backup-Codes](/end-user-flows/mfa) zu aktivieren. ::: :::note -Um diese Methode zu verwenden, musst du das Feld `mfa` in den [Einstellungen der Kontozentrale](#how-to-enable-account-api) aktivieren. +Um diese Methode zu verwenden, musst du das Feld `mfa` in den [Account Center Einstellungen](#how-to-enable-account-api) aktivieren. ::: **Schritt 1: Neue Backup-Codes generieren** @@ -567,9 +585,9 @@ Bevor die Backup-Codes an das Benutzerkonto gebunden werden, musst du sie dem Be - Lade diese Codes sofort herunter oder schreibe sie auf - Bewahre sie an einem sicheren Ort auf - Jeder Code kann nur einmal verwendet werden -- Diese Codes sind die letzte Rettung, falls der Benutzer den Zugriff auf seine primären MFA-Methoden verliert +- Diese Codes sind die letzte Rettung, falls der Benutzer den Zugang zu seinen primären MFA-Methoden verliert -Du solltest die Codes in einem klaren, einfach zu kopierenden Format anzeigen und eine Download-Option (z. B. als Textdatei oder PDF) anbieten. +Du solltest die Codes in einem klaren, leicht kopierbaren Format anzeigen und eine Download-Option (z. B. als Textdatei oder PDF) anbieten. **Schritt 3: Backup-Codes an das Benutzerkonto binden** @@ -583,13 +601,13 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"BackupCode","codes":["...","...","..."]}' ``` -- `verification_record_id`: Eine gültige Verifizierungsdatensatz-ID, die durch die Verifizierung des bestehenden Faktors des Benutzers gewährt wurde. Siehe [Verifizierungsdatensatz-ID erhalten](#get-a-verification-record-id) für Details. +- `verification_record_id`: Eine gültige Verifizierungs-Record-ID, die durch Verifizierung des bestehenden Faktors des Benutzers gewährt wurde. Siehe [Verifizierungs-Record-ID erhalten](#get-a-verification-record-id) für Details. - `type`: Muss `BackupCode` sein. - `codes`: Das Array der im vorherigen Schritt generierten Backup-Codes. :::note -- Ein Benutzer kann immer nur einen Satz Backup-Codes gleichzeitig haben. Wenn alle Codes verwendet wurden, muss der Benutzer neue Codes generieren und binden. +- Ein Benutzer kann nur einen Satz Backup-Codes gleichzeitig haben. Wenn alle Codes verwendet wurden, muss der Benutzer neue Codes generieren und binden. - Backup-Codes können nicht der einzige MFA-Faktor sein. Der Benutzer muss mindestens einen weiteren MFA-Faktor (wie WebAuthn oder TOTP) aktiviert haben. - Jeder Backup-Code kann nur einmal verwendet werden. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index 695b652c288..23159f2d87a 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -2,26 +2,26 @@ sidebar_position: 2 --- -# First-Screen-Parameter +# Parameter für den ersten Bildschirm -Eine Reihe von benutzerdefinierten Authentifizierungsparametern, mit denen du das gewünschte First-Screen-Erlebnis für die Endbenutzer anpassen kannst. +Eine Reihe von benutzerdefinierten Authentifizierungsparametern, mit denen du das gewünschte Erlebnis auf dem ersten Bildschirm für die Endbenutzer anpassen kannst. -- `first_screen`: Gibt den ersten Bildschirm an, den der Benutzer sehen wird. +- `first_screen`: Legt fest, welcher Bildschirm dem Benutzer zuerst angezeigt wird. - `identifier`: Gibt die Identifikatortypen an, die das Anmelde- oder Registrierungsformular akzeptiert. - `login_hint`: Füllt das Identifikatorfeld mit der E-Mail-Adresse oder dem Benutzernamen des Benutzers aus. (Dies ist ein OIDC-Standardparameter) ## first_screen \{#first_screen} -Der Parameter `first_screen` ist der Schlüsselparameter, der bestimmt, welchen ersten Bildschirm die Benutzer sehen, wenn sie zur Logto-Anmeldeseite weitergeleitet werden. Standardmäßig wird das universelle Anmeldeformular angezeigt. Verwende diesen Parameter, um den ersten Bildschirm basierend auf den Anforderungen deiner Anwendung anzupassen. Unterstützte Werte sind: +Der Parameter `first_screen` ist der Schlüsselparameter, der bestimmt, welchen ersten Bildschirm die Benutzer sehen, wenn sie zur Logto-Anmeldeseite weitergeleitet werden. Standardmäßig wird das universelle Anmeldeformular angezeigt. Verwende diesen Parameter, um den ersten Bildschirm entsprechend den Anforderungen deiner Anwendung anzupassen. Unterstützte Werte sind: -- `sign_in`: Zeigt das Anmeldeformular an. (Standard) +- `sign_in` (Standard): Zeigt das Anmeldeformular an. - `register`: Zeigt das Registrierungsformular an. - `reset_password`: Zeigt das Formular zum Zurücksetzen des Passworts an. - `single_sign_on`: Zeigt das Enterprise SSO-Anmeldeformular an. (Es wird eine E-Mail-Adresse abgefragt, um die aktivierten SSO-Anbieter zu bestimmen) -- `identifier:sign-in`: Zeigt ein identifikatorspezifisches Anmeldeformular an. Der Identifikatortyp kann mit dem Parameter `identifier` angegeben werden. Dies ist nützlich, wenn du mehrere Identifikator-Anmeldemethoden aktiviert hast. -- `identifier:register`: Zeigt ein identifikatorspezifisches Registrierungsformular an. Der Identifikatortyp kann mit dem Parameter `identifier` angegeben werden. Dies ist nützlich, wenn du mehrere Identifikator-Registrierungsmethoden aktiviert hast. +- `identifier:sign-in`: Zeigt ein identifikatorspezifisches Anmeldeformular an. Der Identifikatortyp kann optional mit dem Parameter `identifier` angegeben werden. Dies ist nützlich, wenn du mehrere Identifikator-Anmeldemethoden aktiviert hast. +- `identifier:register`: Zeigt ein identifikatorspezifisches Registrierungsformular an. Der Identifikatortyp kann optional mit dem Parameter `identifier` angegeben werden. Dies ist nützlich, wenn du mehrere Identifikator-Registrierungsmethoden aktiviert hast. -First screen parameter +Parameter für den ersten Bildschirm Beispiel: Benutzer direkt zum Enterprise SSO-Anmeldeformular weiterleiten: @@ -30,6 +30,10 @@ curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +Der erste Bildschirm folgt den Einstellungen, die in Konsole > Anmeldeerlebnis konfiguriert wurden. Du musst zuerst die erforderlichen Authentifizierungsmethoden aktivieren und Branding, Nutzungsbedingungen, Datenschutzrichtlinien sowie Internationalisierung (i18n) konfigurieren. Beachte, dass standardmäßig nur die Seiten `sign-in` und `register` das Logo anzeigen. +::: + ## identifier \{#identifier} Der Parameter `identifier` wird verwendet, um die Identifikatortypen anzugeben, die das Anmelde- oder Registrierungsformular akzeptiert. Dieser Parameter ist nur anwendbar, wenn der Parameter `first_screen` auf `identifier:sign-in`, `identifier:register` oder `reset_password` gesetzt ist. Unterstützte Werte sind: `username`, `email` und `phone`. Trenne mehrere Werte mit einem Leerzeichen, um mehrere Identifikatortypen zuzulassen. @@ -47,7 +51,7 @@ Nicht unterstützte oder deaktivierte Identifikatortypen werden ignoriert. Wenn ## login_hint \{#login_hint} -Der Parameter `login_hint`, definiert in der Standard-[OpenID Connect-Spezifikation](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint), wird verwendet, um das Anmeldeformular mit dem Identifikator des Benutzers (wie eine E-Mail, Telefonnummer oder Benutzername) vorab auszufüllen. Mit Logto kann er mit anderen Anmeldebildschirm-Parametern kombiniert werden, um das Benutzererlebnis zu verbessern. Dieser Parameter ist besonders nützlich, wenn du ein benutzerdefiniertes Pre-Authentifizierungsformular hast, das den Identifikator des Benutzers im Voraus abfragt, sodass dieser ihn beim Anmelden nicht erneut eingeben muss. +Der Parameter `login_hint`, definiert im Standard der [OpenID Connect-Spezifikation](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint), wird verwendet, um das Anmeldeformular mit dem Identifikator des Benutzers (wie E-Mail, Telefonnummer oder Benutzername) vorab auszufüllen. Mit Logto kann er mit anderen Anmeldebildschirm-Parametern kombiniert werden, um das Benutzererlebnis zu verbessern. Dieser Parameter ist besonders nützlich, wenn du ein benutzerdefiniertes Pre-Authentifizierungsformular hast, das den Identifikator des Benutzers im Voraus abfragt, sodass dieser ihn beim Anmelden nicht erneut eingeben muss. Beispiel: Die gesammelte E-Mail-Adresse im Anmeldeformular vorab ausfüllen: @@ -58,7 +62,7 @@ curl --location \ ## SDK-Unterstützung \{#sdk-support} -In unterstützten Logto SDKs kannst du die Parameter beim Aufruf der `signIn`-Methode setzen: +In unterstützten Logto SDKs kannst du die Parameter beim Aufruf der Methode `signIn` setzen: ```javascript logtoClient.signIn({ @@ -70,7 +74,7 @@ logtoClient.signIn({ ``` :::note -Wir fügen nach und nach Unterstützung für die Parameter `first_screen`, `identifier` und `login_hint` zu allen Logto SDKs hinzu. Wenn du sie in deinem SDK nicht findest, öffne bitte ein Issue oder kontaktiere uns. +Wir fügen nach und nach Unterstützung für die Parameter `first_screen`, `identifier` und `login_hint` in allen Logto SDKs hinzu. Wenn du sie in deinem SDK nicht findest, öffne bitte ein Issue oder kontaktiere uns. -Für [Logto OSS](/logto-oss)-Nutzer sind diese Parameter seit Version 1.15.0 unterstützt. Wenn du eine ältere Version verwendest, [aktualisiere](/logto-oss/upgrading-oss-version) bitte auf die neueste Version. +Für [Logto OSS](/logto-oss)-Nutzer werden diese Parameter seit Version 1.15.0 unterstützt. Wenn du eine ältere Version verwendest, führe bitte ein [Upgrade](/logto-oss/upgrading-oss-version) auf die neueste Version durch. ::: diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index ce9253ef6a6..b9e769d3913 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -4,19 +4,20 @@ sidebar_position: 1 # UI-Sprachen -Logto unterstützt den standardmäßigen OIDC-Authentifizierungsparameter `ui_locales`, um die Sprache der Anmeldeerfahrung (Sign-in Experience) und nachgelagerter Kommunikation für eine bestimmte Interaktion zu steuern. +Logto unterstützt den Standard-OIDC-Authentifizierungsparameter `ui_locales`, um die Sprache der Anmeldeerfahrung und nachgelagerter Kommunikation für eine bestimmte Interaktion zu steuern. ## Was es bewirkt \{#what-it-does} - Bestimmt zur Laufzeit die UI-Sprache der von Logto gehosteten Anmeldeerfahrung. Logto wählt das erste Sprach-Tag in `ui_locales`, das in der Sprachbibliothek deines Mandanten unterstützt wird. -- Beeinflusst die E-Mail-Lokalisierung für Nachrichten, die durch die Interaktion ausgelöst werden (z. B. Verifizierungscode-E-Mails). Siehe [E-Mail-Vorlagen-Lokalisierung](/connectors/email-connectors/email-templates#email-template-localization). -- Stellt den Originalwert als Variable `uiLocales` in E-Mail-Vorlagen zur Verfügung, sodass du ihn bei Bedarf im E-Mail-Betreff / -Inhalt einfügen kannst. +- Beeinflusst die Lokalisierung von E-Mails für Nachrichten, die durch die Interaktion ausgelöst werden (z. B. Verifizierungscode-E-Mails). Siehe [E-Mail-Vorlagen-Lokalisierung](/connectors/email-connectors/email-templates#email-template-localization). +- Stellt den ursprünglichen Wert als Variable `uiLocales` in E-Mail-Vorlagen zur Verfügung, sodass du ihn bei Bedarf im E-Mail-Betreff / -Inhalt einfügen kannst. +- Setzt die Standard-Ländervorwahl für Telefonnummern in der Anmeldeerfahrung. Zum Beispiel: Wenn `ui_locales=fr` gesetzt ist, wird das Telefonnummern-Eingabefeld standardmäßig auf Frankreich (+33) gesetzt. Das ist nützlich, wenn du die Standard-Ländervorwahl programmatisch für bestimmte Benutzergruppen oder Regionen steuern möchtest. ## Parameterformat \{#parameter-format} - Name: `ui_locales` - Typ: `string` -- Wert: Durch Leerzeichen getrennte Liste von BCP 47 Sprach-Tags, z. B. `fr-CA fr en`. +- Wert: Durch Leerzeichen getrennte Liste von BCP 47-Sprachtags, z. B. `fr-CA fr en`. - Referenz: [OpenID Connect Core - ui_locales](https://openid.net/specs/openid-connect-core-1_0.html) ## Auflösungsreihenfolge und Priorität \{#resolution-order-and-precedence} @@ -25,13 +26,13 @@ Bei der Bestimmung der UI-Sprache für die Anmeldeerfahrung und zugehörige E-Ma 1. `ui_locales` aus der aktuellen Authentifizierungsanfrage (das erste unterstützte Tag gewinnt). 2. Andernfalls `Accept-Language`-Header (Experience APIs / User Account APIs) oder `messagePayload.locale` (Management APIs wie Organisationseinladungen). -3. Andernfalls die in der Sign-in Experience konfigurierte Standardsprache des Mandanten. +3. Andernfalls die in der Anmeldeerfahrung konfigurierte Standardsprache des Mandanten. Dieses Verhalten ändert deine Spracheinstellungen nicht dauerhaft; es gilt nur für die aktuelle Interaktion. ## SDK-Verwendung \{#sdk-usage} -Wenn du ein Logto SDK verwendest, übergib `ui_locales` über die `extraParams` des Sign-in-Aufrufs, damit es an die Autorisierungsanfrage weitergeleitet wird: +Wenn du ein Logto SDK verwendest, übergib `ui_locales` über die `extraParams` des Anmeldeaufrufs, damit es an die Autorisierungsanfrage weitergeleitet wird: ```ts await logtoClient.signIn({ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index 720f689f2dc..9ea24dce82a 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -2,45 +2,46 @@ sidebar_position: 2 --- -# E-Mail / Telefon / Benutzername Anmeldung +# Anmeldung mit E-Mail / Telefonnummer / Benutzername -## Konfiguriere den Identifikator-Anmeldefluss \{#configure-the-identifier-sign-in-flow} +## Den Identifier-Anmeldefluss konfigurieren \{#configure-the-identifier-sign-in-flow} -Wie bereits erwähnt, können verschiedene Identifikatortypen von Benutzern während des [Registrierungsflusses](/end-user-flows/sign-up-and-sign-in/sign-up) oder [direkter Kontoerstellung in Logto](/user-management/manage-users#add-users) erfasst werden. Darüber hinaus können Benutzer zusätzliche Informationen eingeben und vervollständigen, während sie das Produkt erkunden und nutzen. Diese Identifikatoren können verwendet werden, um Benutzer im Logto-System eindeutig zu identifizieren und ihnen die Authentifizierung und Anmeldung bei den mit Logto integrierten Anwendungen zu ermöglichen. +Wie bereits erwähnt, können verschiedene Identifikatortypen von Benutzern während des [Registrierungsprozesses](/end-user-flows/sign-up-and-sign-in/sign-up) oder bei der [direkten Kontoerstellung in Logto](/user-management/manage-users#add-users) erfasst werden. Zusätzlich können Benutzer weitere Informationen eingeben und vervollständigen, während sie das Produkt erkunden und nutzen. Diese Identifier können verwendet werden, um Benutzer im System von Logto eindeutig zu identifizieren und ihnen die Authentifizierung sowie die Anmeldung bei den mit Logto integrierten Anwendungen zu ermöglichen. -Egal, ob du die von Logto gehostete vorgefertigte Anmeldeseite verwenden oder [deine eigene benutzerdefinierte Anmelde-UI erstellen](/customization#custom-ui) möchtest, du musst die verfügbaren Anmeldemethoden und Verifizierungseinstellungen für deine Endbenutzer konfigurieren. +Egal, ob du die von Logto gehostete vorgefertigte Anmeldeseite verwendest oder planst, [deine eigene benutzerdefinierte Anmeldeoberfläche zu erstellen](/customization#custom-ui), musst du die verfügbaren Anmeldemethoden und Verifizierungseinstellungen für deine Endbenutzer konfigurieren. -## Richte die Identifikator- und Authentifizierungseinstellungen ein \{#set-up-the-identifier-and-authentication-settings} +## Identifier- und Authentifizierungseinstellungen festlegen \{#set-up-the-identifier-and-authentication-settings} -### 1. Lege die unterstützten Anmeldeidentifikatoren fest \{#1-set-the-supported-sign-in-identifiers} +### 1. Unterstützte Anmelde-Identifier festlegen \{#1-set-the-supported-sign-in-identifiers} -Du kannst mehrere unterstützte Identifikatoren aus der Dropdown-Liste als aktivierte Anmeldemethoden für Endbenutzer hinzufügen. Die verfügbaren Optionen sind: +Du kannst mehrere unterstützte Identifier aus der Dropdown-Liste als aktivierte Anmeldemethoden für Endbenutzer hinzufügen. Die verfügbaren Optionen sind: - **Benutzername** - **E-Mail-Adresse** - **Telefonnummer** -Das Neuanordnen der Identifikatoren ändert die Reihenfolge, in der sie auf der Anmeldeseite angezeigt werden. Der erste Identifikator wird die primäre Anmeldemethode für Benutzer sein. +Durch das Umordnen der Identifier änderst du die Reihenfolge, in der sie auf der Anmeldeseite angezeigt werden. Der erste Identifier ist die primäre Anmeldemethode für Benutzer. -### 2. Lege die Authentifizierungseinstellungen fest \{#2-set-the-authentication-settings} +### 2. Authentifizierungseinstellungen festlegen \{#2-set-the-authentication-settings} -Für jeden Anmeldeidentifikator musst du mindestens einen effektiven Verifizierungsfaktor konfigurieren, um die Identität des Benutzers zu überprüfen. Es gibt zwei Faktoren, aus denen du wählen kannst: +Für jeden Anmelde-Identifier musst du mindestens einen effektiven Verifizierungsfaktor konfigurieren, um die Identität des Benutzers zu überprüfen. Es stehen zwei Faktoren zur Auswahl: -- **Passwort**: Verfügbar für alle Arten von Anmeldeidentifikatoren. Sobald aktiviert, müssen Benutzer ein Passwort angeben, um den Anmeldeprozess abzuschließen. -- **Verifizierungscode**: Nur verfügbar für **E-Mail-Adresse** und **Telefonnummer** Identifikatoren. Sobald aktiviert, müssen Benutzer einen Verifizierungscode eingeben, der an ihre E-Mail oder Telefonnummer gesendet wird, um den Anmeldeprozess abzuschließen. +- **Passwort**: Verfügbar für alle Arten von Anmelde-Identifiern. Nach der Aktivierung müssen Benutzer ein Passwort angeben, um den Anmeldevorgang abzuschließen. +- **Verifizierungscode**: Nur verfügbar für **E-Mail-Adresse** und **Telefonnummer** Identifier. Nach der Aktivierung müssen Benutzer einen Verifizierungscode eingeben, der an ihre E-Mail-Adresse oder Telefonnummer gesendet wird, um den Anmeldevorgang abzuschließen. -Wenn beide Faktoren aktiviert sind, können Benutzer eine der Methoden wählen, um den Anmeldeprozess abzuschließen. Du kannst auch die Faktoren neu anordnen, um die Reihenfolge zu ändern, in der sie auf der Anmeldeseite angezeigt werden. Der erste Faktor wird als primäre Verifizierungsmethode für Benutzer verwendet und der zweite wird als alternativer Link angezeigt. +Wenn beide Faktoren aktiviert sind, können Benutzer eine der beiden Methoden wählen, um den Anmeldevorgang abzuschließen. Du kannst die Faktoren auch umsortieren, um die Reihenfolge zu ändern, in der sie auf der Anmeldeseite angezeigt werden. Der erste Faktor wird als primäre Verifizierungsmethode für Benutzer verwendet und der zweite als alternative Option angezeigt. -## Benutzererfahrung im Identifikator-Anmeldefluss \{#identifier-sign-in-flow-user-experience} +## Benutzererlebnis beim Identifier-Anmeldefluss \{#identifier-sign-in-flow-user-experience} -Die Anmeldeerfahrung passt sich basierend auf dem gewählten Identifikator und den verfügbaren Authentifizierungsfaktoren an. +Das Anmeldeerlebnis passt sich je nach gewähltem Identifier und verfügbaren Authentifizierungsfaktoren an. -- **Intelligente Eingabe für mehrere Identifikatoren:** - Wenn mehr als eine Anmeldeidentifikator-Methode aktiviert ist, erkennt die integrierte Anmeldeseite von Logto automatisch den vom Benutzer eingegebenen Identifikatortyp und zeigt die entsprechenden Verifizierungsoptionen an. Wenn beispielsweise sowohl **E-Mail-Adresse** als auch **Telefonnummer** aktiviert sind, erkennt die Anmeldeseite automatisch den vom Benutzer eingegebenen Identifikatortyp und zeigt die entsprechenden Verifizierungsoptionen an. Sie wechselt zu einem Telefonnummernformat mit Regionscode, wenn Zahlen nacheinander eingegeben werden, oder zu einem E-Mail-Format, wenn ein „@“-Symbol verwendet wird. +- **Intelligente Eingabe für mehrere Identifier:** + Wenn mehr als eine Identifier-Anmeldemethode aktiviert ist, erkennt die integrierte Anmeldeseite von Logto automatisch den vom Benutzer eingegebenen Identifikatortyp und zeigt die entsprechenden Verifizierungsoptionen an. Wenn beispielsweise sowohl **E-Mail-Adresse** als auch **Telefonnummer** aktiviert sind, erkennt die Anmeldeseite automatisch den vom Benutzer eingegebenen Identifikatortyp und zeigt die entsprechenden Verifizierungsoptionen an. Sie wechselt zu einem Telefonnummernformat mit Regionscode, wenn Zahlen hintereinander eingegeben werden, oder zu einem E-Mail-Format, wenn ein "@"-Symbol verwendet wird. + - Die Ländervorwahl der Telefonnummer wird standardmäßig anhand der Browsersprache des Benutzers gesetzt; Benutzer können sie manuell ändern. Du kannst den [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) Parameter verwenden, um einen bestimmten Standard-Ländercode festzulegen. Siehe [Lokalisierte Sprachen](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience) für weitere Details. - **Aktivierte Verifizierungsfaktoren:** - - **Nur Passwort:** Sowohl das Identifikator- als auch das Passwortfeld werden auf dem ersten Bildschirm angezeigt. - - **Nur Verifizierungscode:** Das Identifikatorfeld erscheint auf dem ersten Bildschirm, gefolgt vom Verifizierungscodefeld auf dem zweiten Bildschirm. - - **Passwort und Verifizierungscode:** Das Identifikatorfeld wird zunächst auf dem ersten Bildschirm eingegeben, gefolgt von Schritten zur Eingabe des Passworts oder Verifizierungscodes auf dem zweiten Bildschirm basierend auf der Verifizierungsreihenfolge. Ein Umschaltlink wird bereitgestellt, um Benutzern das Wechseln zwischen den beiden Verifizierungsmethoden zu ermöglichen. + - **Nur Passwort:** Sowohl das Identifier- als auch das Passwortfeld werden auf dem ersten Bildschirm angezeigt. + - **Nur Verifizierungscode:** Das Identifierfeld erscheint auf dem ersten Bildschirm, gefolgt vom Verifizierungscodefeld auf dem zweiten Bildschirm. + - **Passwort und Verifizierungscode:** Das Identifierfeld wird zunächst auf dem ersten Bildschirm eingegeben, gefolgt von Schritten zur Eingabe des Passworts oder Verifizierungscodes auf dem zweiten Bildschirm, je nach Verifizierungsreihenfolge. Ein Umschaltlink ermöglicht es Benutzern, zwischen den beiden Verifizierungsmethoden zu wechseln. ### Beispiele \{#examples} @@ -51,7 +52,7 @@ Die Anmeldeerfahrung passt sich basierend auf dem gewählten Identifikator und d -Füge die **E-Mail-Adresse** als Anmeldeidentifikator hinzu und aktiviere den **Passwort**-Faktor zur Verifizierung. +Füge die **E-Mail-Adresse** als Anmelde-Identifier hinzu und aktiviere den **Passwort**-Faktor zur Verifizierung. E-Mail-Adresse mit Passwortverifizierung @@ -60,47 +61,47 @@ Füge die **E-Mail-Adresse** als Anmeldeidentifikator hinzu und aktiviere den **
-### Beispiel 2: E-Mail / Telefon mit Passwort (primär) und Verifizierungscode (alternativ) Verifizierung aktiviert \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} +### Beispiel 2: E-Mail/Telefon mit Passwort (primär) und Verifizierungscode (alternativ) aktiviert \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} -Füge sowohl **E-Mail-Adresse** als auch **Telefonnummer** als Anmeldeidentifikatoren hinzu. -Aktiviere die **Passwort**- und **Verifizierungscode**-Faktoren für beide Identifikatoren. +Füge sowohl **E-Mail-Adresse** als auch **Telefonnummer** als Anmelde-Identifier hinzu. +Aktiviere die Faktoren **Passwort** und **Verifizierungscode** für beide Identifier. E-Mail / Telefon mit Passwort und Verifizierungscode Verifizierung
-## Zusätzliche Benutzerprofile bei der Anmeldung erfassen \{#collect-additional-user-profile-on-sign-in} +## Zusätzliche Benutzerprofile beim Anmelden erfassen \{#collect-additional-user-profile-on-sign-in} -Im Anmeldefluss von Logto kann ein Profil-Erfüllungsprozess ausgelöst werden, wenn die Registrierungsidentifikatoreinstellungen aktualisiert werden. Dies stellt sicher, dass alle Benutzer, einschließlich bestehender, alle neu erforderlichen Identifikatoren bereitstellen. +Im Anmeldefluss von Logto kann ein Profil-Vervollständigungsprozess ausgelöst werden, wenn die Einstellungen für die Registrierungs-Identifier aktualisiert werden. Dies stellt sicher, dass alle Benutzer, einschließlich bestehender, alle neu erforderlichen Identifier angeben. -Wenn ein Entwickler einen neuen Identifikator (wie eine E-Mail-Adresse) hinzufügt, wird er für alle Benutzer obligatorisch. Wenn sich ein zurückkehrender Benutzer mit einem bestehenden Identifikator (wie einem Benutzernamen) anmeldet, wird er aufgefordert, den neuen Identifikator bereitzustellen und zu verifizieren, wenn er in seinem Profil fehlt. Erst nach Abschluss dieses Schritts kann er auf die Anwendung zugreifen, was einen reibungslosen und konsistenten Übergang zu den aktualisierten Anforderungen gewährleistet. +Wenn ein Entwickler einen neuen Identifier (wie eine E-Mail-Adresse) hinzufügt, wird dieser für alle Benutzer verpflichtend. Meldet sich ein zurückkehrender Benutzer mit einem bestehenden Identifier (z. B. einem Benutzernamen) an, wird er aufgefordert, den neuen Identifier anzugeben und zu verifizieren, falls dieser in seinem Profil fehlt. Erst nach Abschluss dieses Schritts erhält er Zugriff auf die Anwendung, was einen reibungslosen und konsistenten Übergang zu den aktualisierten Anforderungen gewährleistet. -Aufschlüsselung des Prozesses: +Der Prozess im Überblick: -1. **Benutzername** wurde zuvor als Registrierungsidentifikator mit der Einstellung **Erstelle dein Passwort** automatisch aktiviert. -2. **E-Mail-Adresse** wird später als Registrierungsidentifikator festgelegt. Der **E-Mail-Adresse**-Identifikator wird automatisch als aktivierte Anmeldeoption hinzugefügt. +1. **Benutzername** wurde zuvor als Registrierungs-Identifier mit automatisch aktivierter **Passwort erstellen**-Einstellung festgelegt. +2. **E-Mail-Adresse** wird später als Registrierungs-Identifier festgelegt. Der **E-Mail-Adresse** Identifier wird automatisch als aktivierte Anmeldeoption hinzugefügt. 3. Ein zurückkehrender Benutzer meldet sich mit seinem Benutzernamen und Passwort an. -4. Der Benutzer wird aufgefordert, nach seinem ersten Anmeldeschritt eine E-Mail-Adresse bereitzustellen und zu verifizieren. +4. Der Benutzer wird nach dem ersten Anmeldeschritt aufgefordert, eine E-Mail-Adresse anzugeben und zu verifizieren. ```mermaid flowchart TD - A[Besuche Anmeldeseite] --> B[Gib Benutzername und Passwort ein] + A[Anmeldeseite besuchen] --> B[Benutzername und Passwort eingeben] B -.-> C{{E-Mail-Adresse erforderlich und fehlt?}} - C -->|Ja| D[Gib E-Mail-Adresse ein] - D --> E[Gib Verifizierungscode ein] + C -->|Ja| D[E-Mail-Adresse eingeben] + D --> E[Verifizierungscode eingeben] E --> F[Erfolgreiche Anmeldung] C --> |Nein| F ``` -Der gleiche Prozess gilt auch für die **Erstelle dein Passwort**-Registrierungseinstellungen. Wenn die **Erstelle dein Passwort**-Einstellungen im Registrierungsfluss neu aktiviert werden, wird der **Passwort**-Faktor automatisch für alle von dir gewählten Anmeldeidentifikatoren aktiviert. Alle zurückkehrenden Benutzer ohne Passwort werden während des Anmeldeprozesses aufgefordert, eines zu erstellen. +Der gleiche Prozess gilt auch für die **Passwort erstellen**-Einstellungen bei der Registrierung. Wenn die **Passwort erstellen**-Einstellung im Registrierungsprozess neu aktiviert wird, wird der **Passwort**-Faktor automatisch für alle von dir gewählten Anmelde-Identifier aktiviert. Alle zurückkehrenden Benutzer ohne Passwort werden während des Anmeldevorgangs aufgefordert, eines zu erstellen. :::note -Hinweis: Für benutzerdefinierte Anmeldeflüsse, siehe das Feature von [Bring your UI](/customization/bring-your-ui/). +Hinweis: Für benutzerdefinierte Anmeldeflüsse siehe die Funktion [Bring your UI](/customization/bring-your-ui/). ::: ## FAQs \{#faqs} @@ -108,20 +109,20 @@ Hinweis: Für benutzerdefinierte Anmeldeflüsse, siehe das Feature von [Bring yo
-### Selbstgehostete Anmeldeerfahrung (eingebettete Anmeldung) \{#self-hosted-sign-in-experience-embedded-sign-in} +### Self-hosted Anmeldeerlebnis (eingebettete Anmeldung) \{#self-hosted-sign-in-experience-embedded-sign-in} -Logto unterstützt derzeit keine Headless-API für Anmeldung und Registrierung. Du kannst jedoch unser [Bring your UI](/customization/bring-your-ui/) Feature verwenden, um dein benutzerdefiniertes Anmeldeformular bei Logto hochzuladen. Wir unterstützen auch mehrere Anmeldeparameter, die du verwenden kannst, um das Anmeldeformular mit Benutzeridentifikatoren aus deiner Anwendung vorab auszufüllen oder direkt mit einem Drittanbieter-SSO-Anbieter oder einem Unternehmens-SSO-Anbieter anzumelden. Erfahre mehr unter [Authentifizierungsparameter](/end-user-flows/authentication-parameters/). +Logto unterstützt derzeit keine Headless-API für Anmeldung und Registrierung. Du kannst jedoch unsere [Bring your UI](/customization/bring-your-ui/) Funktion nutzen, um dein eigenes Anmeldeformular bei Logto hochzuladen. Wir unterstützen außerdem mehrere Anmeldeparameter, mit denen du das Anmeldeformular mit einem in deiner Anwendung erfassten Benutzer-Identifier vorausfüllen oder dich direkt mit einem Drittanbieter für soziale oder Enterprise SSO anmelden kannst. Mehr dazu unter [Authentifizierungsparameter](/end-user-flows/authentication-parameters/).
## Verwandte Ressourcen \{#related-resources} - E-Mail-Registrierungs- und Anmeldeerfahrung + E-Mail-Registrierungs- und Anmeldeerlebnis - Benutzername Registrierungs- und Anmeldeerfahrung + Benutzername-Registrierungs- und Anmeldeerlebnis diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index c68b221c16d..655d12e0f39 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -4,35 +4,45 @@ sidebar_position: 1 # E-Mail / Telefon / Benutzername Registrierung -Die Benutzerregistrierung ist der erste Schritt, damit sich Nutzer mit deiner Anwendung beschäftigen. Logto unterstützt verschiedene Registrierungsarten, darunter Benutzername und Passwort, E-Mail- oder Telefonnummern-Verifizierung, [soziale Registrierung](/end-user-flows/sign-up-and-sign-in/social-sign-in) und [Enterprise SSO](/end-user-flows/enterprise-sso). Du kannst die Registrierungsarten einrichten, die am besten zu den Anforderungen deiner Anwendung passen. +Die Benutzerregistrierung ist der erste Schritt, damit Nutzer mit deiner Anwendung interagieren können. Logto unterstützt eine Vielzahl von Registrierungsverfahren, darunter Benutzername-Passwort, E-Mail- oder Telefonnummer-Verifizierung, [soziale Registrierung](/end-user-flows/sign-up-and-sign-in/social-sign-in) und [Enterprise SSO](/end-user-flows/enterprise-sso). Du kannst die Registrierungsverfahren einrichten, die am besten zu den Anforderungen deiner Anwendung passen. -Gehe zu Konsole > Anmeldeerlebnis > Registrierung und Anmeldung, um den Identifier-Registrierungsablauf zu konfigurieren. +Gehe zu Konsole > Anmeldeerlebnis > Registrierung und Anmeldung, um mit der Konfiguration des Identifikator-Registrierungsablaufs zu beginnen. Registrierungseinstellung -## Registrierungs-Identifier einrichten \{#set-up-the-sign-up-identifier} +## Registrierungsidentifikator einrichten \{#set-up-the-sign-up-identifier} -Um erfolgreich ein neues Benutzerkonto in Logto zu erstellen, müssen Nutzer mindestens einen **Identifier** angeben, der sie innerhalb des Logto-Systems eindeutig identifiziert. Wähle im ersten Schritt die Identifier aus, die Nutzer während des Registrierungsprozesses angeben müssen. Die verfügbaren Optionen sind: +Um erfolgreich ein neues Benutzerkonto in Logto zu erstellen, müssen Nutzer mindestens einen **Identifikator** angeben, der sie innerhalb des Logto-Systems eindeutig identifiziert. Wähle im ersten Schritt die Identifikatoren aus, die Nutzer während des Registrierungsprozesses angeben müssen. Die verfügbaren Optionen sind: - **Benutzername**: Ein eindeutiger [Benutzername](/user-management/user-data#username), mit dem sich der Nutzer bei der Anwendung anmelden kann. - **E-Mail-Adresse**: Eine gültige [E-Mail-Adresse](/user-management/user-data#primary_email), mit der sich der Nutzer bei der Anwendung anmelden kann. - **Telefonnummer**: Eine gültige [Telefonnummer](/user-management/user-data#primary_phone), mit der sich der Nutzer bei der Anwendung anmelden kann. - **E-Mail-Adresse oder Telefonnummer**: Erlaube Nutzern, sich entweder mit einer gültigen E-Mail-Adresse oder Telefonnummer zu registrieren. -Alle während des Registrierungsprozesses erfassten Identifier müssen innerhalb eines Tenants eindeutig sein. Sie werden im [Benutzerprofil](/user-management/user-data#user-profile) gespeichert und können zur Anmeldung bei Anwendungen verwendet werden, die mit Logto integriert sind. +Alle während des Registrierungsprozesses erfassten Identifikatoren müssen innerhalb eines Tenants eindeutig sein. Sie werden im [Benutzerprofil](/user-management/user-data#user-profile) gespeichert und können zur Anmeldung bei Anwendungen verwendet werden, die mit Logto integriert sind. -Wenn keine Identifier ausgewählt sind, gilt dies für die [soziale](/end-user-flows/sign-up-and-sign-in/social-sign-in)- oder [Enterprise SSO](/end-user-flows/enterprise-sso)-only Registrierungsarten. +Wenn keine Identifikatoren ausgewählt sind, gilt dies für die [soziale](/end-user-flows/sign-up-and-sign-in/social-sign-in)- oder [Enterprise SSO](/end-user-flows/enterprise-sso)-exklusive Registrierungsmethoden. -Du kannst die Reihenfolge der Registrierungs-Identifier anpassen, um zu priorisieren, welchen Nutzer zuerst angeben sollen. Diese Reihenfolge spiegelt sich im Registrierungsprozess wider, wobei der erste Identifier auf dem ersten Registrierungsbildschirm erscheint und die restlichen in den folgenden Schritten abgefragt werden. +Du kannst die Reihenfolge der Registrierungsidentifikatoren anpassen, um denjenigen zu priorisieren, den Nutzer zuerst angeben sollen. Diese Reihenfolge spiegelt sich im Registrierungsprozess wider: Der erste Identifikator erscheint auf dem ersten Registrierungsbildschirm, die weiteren werden in den nächsten Schritten abgefragt. -## Verifizierungseinstellungen für die Registrierung einrichten \{#set-up-the-sign-up-verification-settings} +:::tip +Um bestimmte Arten von E-Mail-Adressen während der Registrierung zu blockieren (z. B. Wegwerf-E-Mails, Subaddressing mit Pluszeichen (+), bestimmte E-Mail-Adressen oder ganze Domains), verwende die **Blocklist**-Funktion im Bereich Sicherheit. Siehe [Blocklist](/security/blocklist) für weitere Details. +::: + +:::tip +Die **Ländervorwahl** der Telefonnummer wird standardmäßig anhand der Browsersprache des Nutzers gesetzt. Ist die Browsersprache z. B. auf `fr` eingestellt, wird die Ländervorwahl auf Frankreich (+33) gesetzt. + +Du kannst auch den [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) Authentifizierungsparameter verwenden, um die Sprache des Anmeldeerlebnisses festzulegen, was ebenfalls die Standard-Ländervorwahl bestimmt. +::: + +## Einstellungen zur Registrierungsverifizierung einrichten \{#set-up-the-sign-up-verification-settings} -Um die Sicherheit der Benutzerregistrierung und des zukünftigen Anmeldeprozesses zu gewährleisten, musst du auch die Verifizierungseinstellungen für die während der Registrierung erfassten Identifier konfigurieren. Die verfügbaren Einstellungen sind: +Um die Sicherheit der Benutzerregistrierung und des zukünftigen Anmeldeprozesses zu gewährleisten, musst du auch die Verifizierungseinstellungen für die während der Registrierung erfassten Identifikatoren konfigurieren. Die verfügbaren Einstellungen sind: -- **Eigenes Passwort erstellen:** Nutzer müssen während der Registrierung ein Passwort erstellen, das der in deinen Anmeldeerlebnis-Einstellungen konfigurierten Passwort-Richtlinie entspricht. Dieses Passwort dient zusammen mit dem Identifier des Nutzers als Anmelde-Credential für die Anwendung. Wenn du **Benutzername** als Registrierungs-Identifier festlegst, wird diese Anforderung automatisch aktiviert, da der **Benutzername** nur mit einem Passwort zur effektiven Verifizierung der Nutzeridentität verwendet werden kann. Die [Passwort-Richtlinie](/security/password-policy) kann an deine Sicherheitsanforderungen angepasst werden. -- **Bei Registrierung verifizieren**: Nutzer müssen ihre E-Mail-Adresse oder Telefonnummer während der Registrierung verifizieren. Aktuell akzeptiert Logto nur verifizierte E-Mails und Telefonnummern als Identifier. Diese Einstellung wird automatisch aktiviert, wenn eine **E-Mail-Adresse** oder **Telefonnummer** als Registrierungs-Identifier verwendet wird. Nutzer müssen den Besitz bestätigen, indem sie während der Registrierung einen an ihre E-Mail oder Telefonnummer gesendeten Verifizierungscode eingeben. +- **Eigenes Passwort erstellen:** Nutzer müssen während der Registrierung ein Passwort erstellen, das der in den Anmeldeeinstellungen konfigurierten Passwort-Richtlinie entspricht. Dieses Passwort dient zusammen mit dem Identifikator als Anmeldeinformation für die Anwendung. Wenn du **Benutzername** als Registrierungsidentifikator festlegst, ist diese Anforderung automatisch aktiviert, da der **Benutzername** nur mit einem Passwort zur effektiven Identitätsprüfung verwendet werden kann. Die [Passwort-Richtlinie](/security/password-policy) kann an deine Sicherheitsanforderungen angepasst werden. +- **Bei Registrierung verifizieren**: Nutzer müssen ihre E-Mail-Adresse oder Telefonnummer während der Registrierung verifizieren. Aktuell akzeptiert Logto nur verifizierte E-Mails und Telefonnummern als Identifikatoren. Diese Einstellung ist automatisch aktiviert, wenn **E-Mail-Adresse** oder **Telefonnummer** als Registrierungsidentifikator verwendet wird. Nutzer müssen den Besitz bestätigen, indem sie einen Verifizierungscode eingeben, der während der Registrierung an ihre E-Mail-Adresse oder Telefonnummer gesendet wird. -| Identifier | Eigenes Passwort erstellen | Bei Registrierung verifizieren | +| Identifikator | Eigenes Passwort erstellen | Bei Registrierung verifizieren | | ------------------- | -------------------------- | ------------------------------ | | Benutzername | Optional | N/A | | E-Mail-Adresse | Optional | Erforderlich | @@ -48,7 +58,7 @@ Um die Sicherheit der Benutzerregistrierung und des zukünftigen Anmeldeprozesse -Wähle den **Benutzernamen** als Registrierungs-Identifier. Eigenes Passwort erstellen ist automatisch aktiviert. +Wähle **Benutzername** als Registrierungsidentifikator. Eigenes Passwort erstellen ist automatisch aktiviert. -Wähle **E-Mail-Adresse oder Telefonnummer** als Registrierungs-Identifier. **Bei Registrierung verifizieren** ist zwingend aktiviert. +Wähle **E-Mail-Adresse oder Telefonnummer** als Registrierungsidentifikator. **Bei Registrierung verifizieren** ist zwingend aktiviert. -Wähle die **E-Mail-Adresse** als Registrierungs-Identifier. **Bei Registrierung verifizieren** ist zwingend aktiviert. Aktiviere **Eigenes Passwort erstellen**, um Nutzer während der Registrierung zur Passworterstellung zu verpflichten. (Gilt analog für den Telefonnummer-Registrierungsablauf) +Wähle **E-Mail-Adresse** als Registrierungsidentifikator. **Bei Registrierung verifizieren** ist zwingend aktiviert. Aktiviere **Eigenes Passwort erstellen**, um Nutzer zur Passworterstellung während der Registrierung zu verpflichten. (Gleiches gilt für den Telefonnummer-Registrierungsablauf) -Wähle **E-Mail-Adresse** und **Benutzername** als Registrierungs-Identifier. **Bei Registrierung verifizieren** ist zwingend aktiviert. Aktiviere **Eigenes Passwort erstellen**, um Nutzer während der Registrierung zur Passworterstellung zu verpflichten. +Wähle **E-Mail-Adresse** und **Benutzername** als Registrierungsidentifikatoren. **Bei Registrierung verifizieren** ist zwingend aktiviert. Aktiviere **Eigenes Passwort erstellen**, um Nutzer zur Passworterstellung während der Registrierung zu verpflichten. Konsole > Anmeldeerlebnis > Benutzerprofil erfassen ein, um aus vorkonfigurierten Basisdatenfeldern zu wählen oder eigene Felder mit flexibler Validierung zu erstellen. Mehr erfahren: [Benutzerprofil erfassen](/end-user-flows/collect-user-profile) -**Option 2: Selbst gehostete Onboarding-Flows** +**Option 2: Selbst gehostete Onboarding-Abläufe** -Leite Nutzer nach erfolgreicher Registrierung zu deinem eigenen, individuellen Onboarding-Flow weiter, um die Datenerfassung vollständig anzupassen. Dieser Ansatz gibt dir die volle Kontrolle über das Nutzererlebnis und ermöglicht komplexe, mehrstufige Onboarding-Prozesse. +Leite Nutzer nach erfolgreicher Registrierung zu deinem eigenen, individuellen Onboarding-Ablauf weiter, um die Datenerfassung vollständig anzupassen. Dieser Ansatz gibt dir die volle Kontrolle über das Nutzererlebnis und ermöglicht komplexe, mehrstufige Onboarding-Prozesse. Verwende die [Account API](/end-user-flows/account-settings/by-account-api), um Benutzerdaten programmatisch zu verwalten. @@ -153,7 +163,7 @@ Erfahre, wie du den [Einladung-Only-Registrierungsablauf](/end-user-flows/sign-u -Logto unterstützt derzeit keine Headless API für Anmeldung und Registrierung. Du kannst die Funktion [Bring your UI](/customization/bring-your-ui/) nutzen, um dein eigenes Registrierungsformular bei Logto hochzuladen oder die Anmeldeparameter verwenden, um Nutzerinformationen von deiner Website an Logto zu übergeben. Mehr zur Identifier-Übertragung findest du unter [Authentifizierungsparameter](/end-user-flows/authentication-parameters/). +Logto unterstützt derzeit keine Headless API für Anmeldung und Registrierung. Du kannst die [Bring your UI](/customization/bring-your-ui/) Funktion nutzen, um dein eigenes Registrierungsformular bei Logto hochzuladen oder die Anmeldeparameter verwenden, um Benutzerdaten von deiner Website an Logto zu übermitteln. Mehr zur Übermittlung von Benutzeridentifikatoren findest du unter [Authentifizierungsparameter](/end-user-flows/authentication-parameters/).
@@ -175,7 +185,7 @@ Abonniere das `User.Created` Webhook-Event, um eine Willkommens-E-Mail an neue N -Derzeit unterstützt Logto nur verifizierte E-Mails und Telefonnummern als Identifier. Der Verifizierungsprozess ist erforderlich, um die Sicherheit und den Besitz des Nutzer-Identifiers zu gewährleisten. +Aktuell unterstützt Logto nur verifizierte E-Mails und Telefonnummern als Identifikatoren. Der Verifizierungsprozess ist erforderlich, um die Sicherheit und den Besitz des Nutzeridentifikators zu gewährleisten. Die Unterstützung für nicht verifizierte E-Mails oder Telefonnummern steht auf unserer [Roadmap](https://feedback.logto.io/roadmap). Bleib dran für Updates! @@ -183,9 +193,9 @@ Die Unterstützung für nicht verifizierte E-Mails oder Telefonnummern steht auf ## Verwandte Ressourcen \{#related-resources} - E-Mail Registrierung und Anmeldung Erlebnis + E-Mail Registrierung und Anmeldeerlebnis - Benutzername Registrierung und Anmeldung Erlebnis + Benutzername Registrierung und Anmeldeerlebnis diff --git a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index ba6d3455297..499cec3ae8a 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,5 +1,5 @@ --- -description: Verweise auf wichtige Anwendungsparameter für die OIDC-Authentifizierungsintegration, einschließlich Redirect-URIs, Endpunkte, Auffrischungstokens, Backchannel-Logout usw. +description: Siehe wichtige Anwendungsparameter für die OIDC-Authentifizierungsintegration, einschließlich Redirect-URIs, Endpunkte, Auffrischungstokens, Backchannel-Logout usw. sidebar_position: 6 --- @@ -7,36 +7,41 @@ sidebar_position: 6 ## Einführung \{#introduction} -In Logto bezieht sich eine _Anwendung_ auf ein spezifisches Softwareprogramm oder einen Dienst, der bei der Logto-Plattform registriert ist und die Berechtigung erhalten hat, auf Benutzerinformationen zuzugreifen oder Aktionen im Namen eines Benutzers auszuführen. Anwendungen werden verwendet, um die Quelle von Anfragen an die Logto API zu identifizieren und den Authentifizierungs- und Autorisierungsprozess für Benutzer zu verwalten, die auf diese Anwendungen zugreifen. +In Logto bezeichnet eine _Anwendung_ ein bestimmtes Softwareprogramm oder einen Dienst, der bei der Logto-Plattform registriert ist und die Autorisierung erhalten hat, auf Benutzerinformationen zuzugreifen oder Aktionen im Namen eines Benutzers auszuführen. Anwendungen werden verwendet, um die Quelle von Anfragen an die Logto API zu identifizieren sowie den Authentifizierungs- und Autorisierungsprozess für Benutzer, die auf diese Anwendungen zugreifen, zu verwalten. -Die Verwendung von Anwendungen in Logtos Anmeldeerfahrung ermöglicht es Benutzern, einfach auf ihre autorisierten Anwendungen zuzugreifen und diese von einem einzigen Ort aus zu verwalten, mit einem konsistenten und sicheren Authentifizierungsprozess. Dies hilft, die Benutzererfahrung zu optimieren und sicherzustellen, dass nur autorisierte Personen auf sensible Informationen zugreifen oder im Namen der Organisation handeln. +Die Verwendung von Anwendungen in der Logto-Anmeldeerfahrung ermöglicht es Benutzern, ihre autorisierten Anwendungen einfach von einem zentralen Ort aus zu verwalten und darauf zuzugreifen – mit einem konsistenten und sicheren Authentifizierungsprozess. Dies trägt dazu bei, die Benutzererfahrung zu optimieren und sicherzustellen, dass nur autorisierte Personen auf sensible Informationen zugreifen oder im Namen der Organisation handeln. -Anwendungen werden auch in Logtos Prüfprotokollen verwendet, um Benutzeraktivitäten zu verfolgen und potenzielle Sicherheitsbedrohungen oder -verletzungen zu identifizieren. Durch die Zuordnung spezifischer Aktionen zu einer bestimmten Anwendung kann Logto detaillierte Einblicke in den Zugriff und die Nutzung von Daten bieten, sodass Organisationen ihre Sicherheits- und Compliance-Anforderungen besser verwalten können. Wenn du deine Anwendung mit Logto integrieren möchtest, siehe [Logto integrieren](/integrate-logto). +Anwendungen werden auch in den Logto-Audit-Logs verwendet, um Benutzeraktivitäten zu verfolgen und potenzielle Sicherheitsbedrohungen oder -verletzungen zu identifizieren. Durch die Zuordnung bestimmter Aktionen zu einer bestimmten Anwendung kann Logto detaillierte Einblicke darüber geben, wie Daten abgerufen und verwendet werden, sodass Organisationen ihre Sicherheits- und Compliance-Anforderungen besser verwalten können. +Wenn du deine Anwendung mit Logto integrieren möchtest, siehe [Logto integrieren](/integrate-logto). ## Eigenschaften \{#properties} ### Anwendungs-ID \{#application-id} -_Anwendungs-ID_ ist ein einzigartiger, automatisch generierter Schlüssel, um deine Anwendung in Logto zu identifizieren, und wird in OAuth 2.0 als [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) referenziert. +_Die Anwendungs-ID_ ist ein eindeutiger, automatisch generierter Schlüssel zur Identifizierung deiner Anwendung in Logto und wird in OAuth 2.0 als [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) bezeichnet. ### Anwendungstypen \{#application-types} Eine _Anwendung_ kann einer der folgenden Anwendungstypen sein: -- **Native App** ist eine App, die in einer nativen Umgebung läuft. Z.B. iOS-App, Android-App. -- **Single Page App** ist eine App, die in einem Webbrowser läuft und die Seite mit neuen Daten vom Server aktualisiert, ohne ganze neue Seiten zu laden. Z.B. React DOM App, Vue App. -- **Traditionelle Web-App** ist eine App, die Seiten ausschließlich vom Webserver rendert und aktualisiert. Z.B. JSP, PHP. -- **Maschine-zu-Maschine (M2M) App** ist eine Anwendung, die in einer Maschinenumgebung für direkte Dienst-zu-Dienst-Kommunikation ohne Benutzerinteraktion läuft. +- **Native App** ist eine App, die in einer nativen Umgebung läuft. Z. B. iOS-App, Android-App. +- **Single Page App** ist eine App, die in einem Webbrowser läuft und die Seite mit neuen Daten vom Server aktualisiert, ohne ganze neue Seiten zu laden. Z. B. React DOM App, Vue App. +- **Traditionelle Web-App** ist eine App, die Seiten ausschließlich durch den Webserver rendert und aktualisiert. Z. B. JSP, PHP. +- **Maschine-zu-Maschine (M2M) App** ist eine Anwendung, die in einer Maschinenumgebung für direkte Service-zu-Service-Kommunikation ohne Benutzerinteraktion läuft. ### Anwendungsschlüssel \{#application-secret} -_Anwendungsschlüssel_ ist ein Schlüssel, der zur Authentifizierung der Anwendung im Authentifizierungssystem verwendet wird, speziell für private Clients (Traditionelle Web- und M2M-Apps) als private Sicherheitsbarriere. +_Der Anwendungsschlüssel_ ist ein Schlüssel, der zur Authentifizierung der Anwendung im Authentifizierungssystem verwendet wird, speziell für private Clients (traditionelle Web- und M2M-Apps) als private Sicherheitsbarriere. + +:::tip +Single Page Apps (SPAs) und Native Apps stellen keinen App-Schlüssel bereit. SPAs und Native Apps sind "öffentliche Clients" und können keine Geheimnisse bewahren (Browser-Code oder App-Bundles sind einsehbar). Statt eines App-Schlüssels schützt Logto sie mit PKCE, strikter Redirect-URI/CORS-Validierung, kurzlebigen Zugangstokens und Auffrischungstoken-Rotation. +::: ### Anwendungsname \{#application-name} -_Anwendungsname_ ist ein menschenlesbarer Name der Anwendung und wird in der Admin-Konsole angezeigt. +_Der Anwendungsname_ ist ein menschenlesbarer Name der Anwendung und wird in der Admin-Konsole angezeigt. -Der _Anwendungsname_ ist ein wichtiger Bestandteil der Verwaltung von Anwendungen in Logto, da er Administratoren ermöglicht, die Aktivität einzelner Anwendungen innerhalb der Plattform leicht zu identifizieren und zu verfolgen. +Der _Anwendungsname_ ist ein wichtiger Bestandteil der Anwendungsverwaltung in Logto, da Administratoren damit einzelne Anwendungen innerhalb der Plattform leicht identifizieren und deren Aktivitäten verfolgen können. :::note Es ist wichtig zu beachten, dass der _Anwendungsname_ sorgfältig gewählt werden sollte, da er für alle Benutzer sichtbar ist, die Zugriff auf die Admin-Konsole haben. Er sollte den Zweck und die Funktion der Anwendung genau widerspiegeln und gleichzeitig leicht verständlich und erkennbar sein. @@ -44,101 +49,102 @@ Es ist wichtig zu beachten, dass der _Anwendungsname_ sorgfältig gewählt werde ### Beschreibung \{#description} -Eine kurze Beschreibung der Anwendung wird auf der Detailseite der Admin-Konsole angezeigt. Die Beschreibung soll Administratoren zusätzliche Informationen über die Anwendung bieten, wie ihren Zweck, ihre Funktionalität und andere relevante Details. +Eine kurze Beschreibung der Anwendung wird auf der Detailseite der Anwendung in der Admin-Konsole angezeigt. Die Beschreibung soll Administratoren zusätzliche Informationen über die Anwendung liefern, wie z. B. ihren Zweck, ihre Funktionalität und andere relevante Details. ### Redirect-URIs \{#redirect-uris} -_Redirect-URIs_ sind eine Liste gültiger Redirect-URIs, die für eine Anwendung vorkonfiguriert wurden. Wenn sich ein Benutzer bei Logto anmeldet und versucht, auf die Anwendung zuzugreifen, wird er zu einer der in den Anwendungseinstellungen angegebenen erlaubten URIs umgeleitet. +_Redirect-URIs_ sind eine Liste gültiger Redirect-URIs, die für eine Anwendung vorkonfiguriert wurden. Wenn sich ein Benutzer bei Logto anmeldet und versucht, auf die Anwendung zuzugreifen, wird er zu einer der in den Anwendungseinstellungen angegebenen erlaubten URIs weitergeleitet. -Die Liste der erlaubten URIs wird verwendet, um die Redirect-URI zu validieren, die in der Autorisierungsanfrage enthalten ist, die von der Anwendung während des Authentifizierungsprozesses an Logto gesendet wird. Wenn die in der Autorisierungsanfrage angegebene Redirect-URI mit einer der erlaubten URIs in den Anwendungseinstellungen übereinstimmt, wird der Benutzer nach erfolgreicher Authentifizierung zu dieser URI umgeleitet. Wenn die Redirect-URI nicht auf der erlaubten Liste steht, wird der Benutzer nicht umgeleitet und der Authentifizierungsprozess schlägt fehl. +Die Liste der erlaubten URIs wird verwendet, um die Redirect-URI zu validieren, die in der Autorisierungsanfrage von der Anwendung an Logto während des Authentifizierungsprozesses gesendet wird. Wenn die in der Autorisierungsanfrage angegebene Redirect-URI mit einer der erlaubten URIs in den Anwendungseinstellungen übereinstimmt, wird der Benutzer nach erfolgreicher Authentifizierung zu dieser URI weitergeleitet. Wenn die Redirect-URI nicht auf der erlaubten Liste steht, wird der Benutzer nicht weitergeleitet und der Authentifizierungsprozess schlägt fehl. :::note -Es ist wichtig sicherzustellen, dass alle gültigen Redirect-URIs zur erlaubten Liste für eine Anwendung in Logto hinzugefügt werden, um sicherzustellen, dass Benutzer nach der Authentifizierung erfolgreich auf die Anwendung zugreifen können. +Es ist wichtig sicherzustellen, dass alle gültigen Redirect-URIs zur erlaubten Liste einer Anwendung in Logto hinzugefügt werden, damit Benutzer nach der Authentifizierung erfolgreich auf die Anwendung zugreifen können. ::: -Du kannst den [Redirection Endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) für weitere Informationen einsehen. +Weitere Informationen findest du im [Redirection Endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2). - Verständnis von Redirect-URIs in OIDC mit Authorization Code Flow + Redirect-URIs in OIDC mit Authorization Code Flow verstehen -### Post-Sign-out Redirect-URIs \{#post-sign-out-redirect-uris} +### Post-Sign-out-Redirect-URIs \{#post-sign-out-redirect-uris} -_Post-Sign-out Redirect-URIs_ sind eine Liste gültiger URIs, die für eine Anwendung vorkonfiguriert wurden, um den Benutzer nach dem Abmelden von Logto umzuleiten. +_Post-Sign-out-Redirect-URIs_ sind eine Liste gültiger URIs, die für eine Anwendung vorkonfiguriert wurden, um den Benutzer nach dem Abmelden von Logto weiterzuleiten. -Die Verwendung von erlaubten _Post-Sign-out Redirect-URIs_ für Logout ist Teil der RP-Initiated (Relying Party Initiated) Logout-Spezifikation in OIDC. Diese Spezifikation bietet eine standardisierte Methode für Anwendungen, um eine Abmeldeanforderung für einen Benutzer zu initiieren, die das Umleiten des Benutzers zu einem vorkonfigurierten Endpunkt nach dem Abmelden beinhaltet. +Die Verwendung von erlaubten _Post-Sign-out-Redirect-URIs_ für Logout ist Teil der RP-Initiated (Relying Party Initiated) Logout-Spezifikation in OIDC. Diese Spezifikation bietet eine standardisierte Methode für Anwendungen, eine Logout-Anfrage für einen Benutzer zu initiieren, einschließlich der Weiterleitung des Benutzers zu einem vorkonfigurierten Endpunkt nach dem Abmelden. -Wenn sich ein Benutzer von Logto abmeldet, wird seine Sitzung beendet und er wird zu einer der in den Anwendungseinstellungen angegebenen erlaubten URIs umgeleitet. Dies stellt sicher, dass der Benutzer nur zu autorisierten und gültigen Endpunkten umgeleitet wird, nachdem er sich abgemeldet hat, und hilft, unbefugten Zugriff und Sicherheitsrisiken zu verhindern, die mit der Umleitung von Benutzern zu unbekannten oder nicht verifizierten Endpunkten verbunden sind. +Wenn sich ein Benutzer von Logto abmeldet, wird seine Sitzung beendet und er wird zu einer der in den Anwendungseinstellungen angegebenen erlaubten URIs weitergeleitet. Dies stellt sicher, dass der Benutzer nach dem Abmelden nur zu autorisierten und gültigen Endpunkten weitergeleitet wird, was dazu beiträgt, unbefugten Zugriff und Sicherheitsrisiken im Zusammenhang mit der Weiterleitung zu unbekannten oder nicht verifizierten Endpunkten zu verhindern. -Du kannst den [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) für weitere Informationen einsehen. +Weitere Informationen findest du unter [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout). -### CORS erlaubte Ursprünge \{#cors-allowed-origins} +### CORS-erlaubte Ursprünge \{#cors-allowed-origins} -Die _CORS (Cross-origin resource sharing) erlaubten Ursprünge_ sind eine Liste von erlaubten Ursprüngen, von denen aus eine Anwendung Anfragen an den Logto-Dienst stellen kann. Jeder Ursprung, der nicht in der erlaubten Liste enthalten ist, kann keine Anfragen an den Logto-Dienst stellen. +Die _CORS (Cross-Origin Resource Sharing) erlaubten Ursprünge_ sind eine Liste von erlaubten Ursprüngen, von denen eine Anwendung Anfragen an den Logto-Dienst stellen kann. Jeder Ursprung, der nicht in der erlaubten Liste enthalten ist, kann keine Anfragen an den Logto-Dienst stellen. -Die Liste der CORS erlaubten Ursprünge wird verwendet, um den Zugriff auf den Logto-Dienst von unbefugten Domains zu beschränken und um Cross-Site-Request-Forgery (CSRF)-Angriffe zu verhindern. Durch die Angabe der erlaubten Ursprünge für eine Anwendung in Logto kann der Dienst sicherstellen, dass nur autorisierte Domains Anfragen an den Dienst stellen können. +Die Liste der CORS-erlaubten Ursprünge wird verwendet, um den Zugriff auf den Logto-Dienst von nicht autorisierten Domains einzuschränken und Cross-Site-Request-Forgery (CSRF)-Angriffe zu verhindern. Durch die Angabe der erlaubten Ursprünge für eine Anwendung in Logto kann der Dienst sicherstellen, dass nur autorisierte Domains Anfragen an den Dienst stellen können. :::note -Die Liste der erlaubten Ursprünge sollte den Ursprung enthalten, von dem aus die Anwendung bereitgestellt wird. Dies stellt sicher, dass Anfragen von der Anwendung erlaubt sind, während Anfragen von unbefugten Ursprüngen blockiert werden. +Die Liste der erlaubten Ursprünge sollte den Ursprung enthalten, unter dem die Anwendung bereitgestellt wird. So wird sichergestellt, dass Anfragen von der Anwendung erlaubt sind, während Anfragen von nicht autorisierten Ursprüngen blockiert werden. ::: -### OpenID Provider Konfigurationsendpunkt \{#openid-provider-configuration-endpoint} +### OpenID-Provider-Konfigurationsendpunkt \{#openid-provider-configuration-endpoint} Der Endpunkt für [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest). ### Autorisierungsendpunkt \{#authorization-endpoint} -_Autorisierungsendpunkt_ ist ein OIDC-Begriff und ein erforderlicher Endpunkt, der verwendet wird, um den Authentifizierungsprozess für einen Benutzer zu initiieren. Wenn ein Benutzer versucht, auf eine geschützte Ressource oder Anwendung zuzugreifen, die bei der Logto-Plattform registriert ist, wird er zum _Autorisierungsendpunkt_ umgeleitet, um seine Identität zu authentifizieren und die Berechtigung zum Zugriff auf die angeforderte Ressource zu erhalten. +_Der Autorisierungsendpunkt_ ist ein OIDC-Begriff und ein erforderlicher Endpunkt, der verwendet wird, um den Authentifizierungsprozess für einen Benutzer zu starten. Wenn ein Benutzer versucht, auf eine geschützte Ressource oder Anwendung zuzugreifen, die bei der Logto-Plattform registriert ist, wird er zum _Autorisierungsendpunkt_ weitergeleitet, um seine Identität zu authentifizieren und die Autorisierung für den Zugriff auf die angeforderte Ressource zu erhalten. -Du kannst den [Autorisierungsendpunkt](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) für weitere Informationen einsehen. +Weitere Informationen findest du unter [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). ### Token-Endpunkt \{#token-endpoint} -_Token-Endpunkt_ ist ein OIDC-Begriff, es ist ein Web-API-Endpunkt, der von einem OIDC-Client verwendet wird, um ein Zugangstoken, ein ID-Token oder ein Auffrischungstoken von einem OIDC-Anbieter zu erhalten. +_Der Token-Endpunkt_ ist ein OIDC-Begriff. Es handelt sich um einen Web-API-Endpunkt, der von einem OIDC-Client verwendet wird, um ein Zugangstoken, ein ID-Token oder ein Auffrischungstoken vom OIDC-Provider zu erhalten. Wenn ein OIDC-Client ein Zugangstoken oder ID-Token benötigt, sendet er eine Anfrage an den Token-Endpunkt mit einem Autorisierungsnachweis, der typischerweise ein Autorisierungscode oder ein Auffrischungstoken ist. Der Token-Endpunkt validiert dann den Autorisierungsnachweis und stellt dem Client ein Zugangstoken oder ID-Token aus, wenn der Nachweis gültig ist. -Du kannst den [Token-Endpunkt](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) für weitere Informationen einsehen. +Weitere Informationen findest du unter [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint). ### Userinfo-Endpunkt \{#userinfo-endpoint} -Der OpenID Connect [UserInfo-Endpunkt](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). +Der OpenID Connect [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). ### Immer Auffrischungstoken ausstellen \{#always-issue-refresh-token} _Verfügbarkeit: Traditionelle Web, SPA_ -Wenn aktiviert, wird Logto immer Auffrischungstokens ausstellen, unabhängig davon, ob `prompt=consent` in der Authentifizierungsanfrage präsentiert wird oder `offline_access` in den Berechtigungen vorhanden ist. +Wenn aktiviert, stellt Logto immer Auffrischungstokens aus, unabhängig davon, ob `prompt=consent` in der Authentifizierungsanfrage vorhanden ist oder `offline_access` in den Berechtigungen enthalten ist. -Diese Praxis wird jedoch nicht empfohlen, es sei denn, sie ist notwendig (normalerweise ist sie nützlich für einige Drittanbieter-OAuth-Integrationen, die ein Auffrischungstoken erfordern), da sie nicht mit OpenID Connect kompatibel ist und potenziell Probleme verursachen kann. +Diese Praxis wird jedoch nicht empfohlen, es sei denn, sie ist notwendig (in der Regel nützlich für einige OAuth-Integrationen von Drittanbietern, die ein Auffrischungstoken erfordern), da sie nicht mit OpenID Connect kompatibel ist und potenziell Probleme verursachen kann. ### Auffrischungstoken rotieren \{#rotate-refresh-token} _Standard: `true`_ -Wenn aktiviert, wird Logto unter den folgenden Bedingungen ein neues Auffrischungstoken für Token-Anfragen ausstellen: +Wenn aktiviert, stellt Logto ein neues Auffrischungstoken für Token-Anfragen unter folgenden Bedingungen aus: -- Wenn das Auffrischungstoken rotiert wurde (seine TTL durch die Ausstellung eines neuen verlängert wurde) für ein Jahr; **ODER** -- Wenn das Auffrischungstoken nahe an seiner Ablaufzeit ist (>=70% seiner ursprünglichen Lebensdauer (TTL) vergangen); **ODER** -- Wenn der Client ein öffentlicher Client ist, z.B. Native Anwendung oder Single Page Application (SPA). +- Wenn das Auffrischungstoken rotiert wurde (seine TTL durch die Ausstellung eines neuen Tokens verlängert wurde) und dies seit einem Jahr geschieht; **ODER** +- Wenn das Auffrischungstoken kurz vor dem Ablauf steht (>=70 % seiner ursprünglichen Lebensdauer (TTL) sind vergangen); **ODER** +- Wenn der Client ein öffentlicher Client ist, z. B. Native Anwendung oder Single Page Application (SPA). :::note -Für öffentliche Clients wird, wenn diese Funktion aktiviert ist, immer ein neues Auffrischungstoken ausgestellt, wenn der Client ein neues Zugangstoken mit dem Auffrischungstoken austauscht. Obwohl du die Funktion für diese öffentlichen Clients immer noch deaktivieren kannst, wird dringend empfohlen, sie aus Sicherheitsgründen aktiviert zu lassen. +Für öffentliche Clients wird bei aktivierter Funktion immer ein neues Auffrischungstoken ausgestellt, wenn der Client mit dem Auffrischungstoken ein neues Zugangstoken anfordert. +Obwohl du die Funktion für diese öffentlichen Clients deaktivieren kannst, wird dringend empfohlen, sie aus Sicherheitsgründen aktiviert zu lassen. ::: - Verständnis der Auffrischungstoken-Rotation + Auffrischungstoken-Rotation verstehen -### Auffrischungstoken Lebensdauer (TTL) in Tagen \{#refresh-token-time-to-live-ttl-in-days} +### Auffrischungstoken-Lebensdauer (TTL) in Tagen \{#refresh-token-time-to-live-ttl-in-days} _Verfügbarkeit: Nicht SPA; Standard: 14 Tage_ Die Dauer, für die ein Auffrischungstoken verwendet werden kann, um neue Zugangstokens anzufordern, bevor es abläuft und ungültig wird. Token-Anfragen verlängern die TTL des Auffrischungstokens auf diesen Wert. -Typischerweise wird ein niedrigerer Wert bevorzugt. +In der Regel wird ein niedrigerer Wert bevorzugt. -Hinweis: Die TTL-Auffrischung ist in SPA (Single Page App) aus Sicherheitsgründen nicht verfügbar. Das bedeutet, dass Logto die TTL nicht durch Token-Anfragen verlängert. Um die Benutzererfahrung zu verbessern, kannst du die Funktion "Auffrischungstoken rotieren" aktivieren, sodass Logto bei Bedarf ein neues Auffrischungstoken ausstellt. +Hinweis: Die Verlängerung der TTL ist in SPA (Single Page App) aus Sicherheitsgründen nicht verfügbar. Das bedeutet, dass Logto die TTL nicht durch Token-Anfragen verlängert. Um die Benutzererfahrung zu verbessern, kannst du die Funktion "Auffrischungstoken rotieren" aktivieren, sodass Logto bei Bedarf ein neues Auffrischungstoken ausstellt. ### Backchannel-Logout-URI \{#backchannel-logout-uri} @@ -146,4 +152,4 @@ Der OpenID Connect Backchannel-Logout-Endpunkt. Siehe [Federated sign-out: Back- ### Benutzerdefinierte Daten \{#custom-data} -Zusätzliche benutzerdefinierte Anwendungsinformationen, die nicht in den vordefinierten Anwendungseigenschaften aufgeführt sind. Benutzer können ihre eigenen benutzerdefinierten Datenfelder entsprechend ihren spezifischen Bedürfnissen definieren, wie z.B. geschäftsspezifische Einstellungen und Konfigurationen. +Zusätzliche benutzerdefinierte Anwendungsinformationen, die nicht in den vordefinierten Anwendungseigenschaften aufgeführt sind. Benutzer können eigene benutzerdefinierte Datenfelder entsprechend ihren spezifischen Anforderungen definieren, wie z. B. geschäftsspezifische Einstellungen und Konfigurationen. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index 444d3865b92..2611d4417f6 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -1,5 +1,5 @@ --- -description: Integriere die Authentifizierung deiner Anwendung und Identitätsföderation in wenigen Minuten mit unseren Schnellstart-Anleitungen. +description: Integriere Anwendungs-Authentifizierung und Identitätsföderation in wenigen Minuten mit unseren Schnellstart-Anleitungen. sidebar_position: 1 --- @@ -11,7 +11,7 @@ Folge diesen Schritten, um Authentifizierung zu deinen Anwendungen mit Logto hin 2. Klicke auf „Anwendung erstellen“, um eine neue Anwendung hinzuzufügen -3. Wähle dein [Anwendungs-Framework](/quick-starts) aus, um zu beginnen. Falls du dein Framework nicht findest, klicke auf die Schaltfläche „App ohne Framework erstellen“ unten rechts auf der Seite zur Anwendungserstellung, um eine App durch Auswahl eines [Application type](/integrate-logto/application-data-structure/#application-types) zu erstellen oder reiche einen Feature-Request ein bzw. trage mit einem SDK bei, indem du unseren [SDK-Konventionen](/developers/sdk-conventions) folgst. +3. Wähle dein [Anwendungs-Framework](/quick-starts) aus, um zu beginnen. Falls du dein Framework nicht findest, klicke auf die Schaltfläche „App ohne Framework erstellen“ unten rechts auf der Seite zur Anwendungserstellung, um eine App durch Auswahl eines [Anwendungstyps](/integrate-logto/application-data-structure/#application-types) zu erstellen oder reiche eine Feature-Anfrage ein bzw. trage durch ein SDK bei, indem du unseren [SDK-Konventionen](/developers/sdk-conventions) folgst. 4. Nach Auswahl deines Frameworks siehst du eine Schnellstart-Anleitung für das SDK des Frameworks. Folge den Schritten, um deine Anwendung zu konfigurieren und zu integrieren. Wenn du Hilfe beim Verständnis der im Integrationsprozess beteiligten Konzepte benötigst, kannst du auf [Logto Authentifizierungsablauf verstehen](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) für ein tieferes Verständnis der Integration verweisen. @@ -23,7 +23,22 @@ Die Anleitung in der Konsole dient nur dem Schnellstart mit Logto unter Verwendu Endbenutzer-Flows Autorisierung (Authorization) - Organisationen (Organizations) + Organisationen + +## FAQs \{#faqs} + +
+ + ### Wie kann mein Backend-Service Benutzertokens validieren und Benutzer mit Logto verwalten? + +Um Zugangstokens in deinem Backend-API (z. B. Python, Node.js, Go, Java, PHP usw.) sicher zu validieren und Benutzer programmatisch zu verwalten, siehe die Anleitung: [Wie man Zugangstokens im eigenen API-Service oder Backend validiert](/authorization/validate-access-tokens). + +Diese Dokumentation behandelt: + +- Wie man die Gültigkeit von Bearer-Tokens bei jedem API-Aufruf prüft +- Best Practices für die Integration von Logto mit mehreren Frontend-Apps und einem Backend-Service + +
## Verwandte Ressourcen \{#related-resources} @@ -32,7 +47,7 @@ Die Anleitung in der Konsole dient nur dem Schnellstart mit Logto unter Verwendu - OpenID Connect-Konfiguration erkunden: Wichtige Felder und deren Verwendung + OpenID Connect-Konfiguration erkunden: Schlüsselfelder und deren Verwendung diff --git a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 27a4b7efc25..e16455d874b 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -8,26 +8,26 @@ import CustomizationIcon from '@site/src/assets/customization.svg'; # Drittanbieter-App (OAuth / OIDC) -Die Drittanbieteranwendungs-Integration von Logto ermöglicht es dir, Logto als [Identitätsanbieter (IdP)](https://auth.wiki/identity-provider) für externe Anwendungen zu nutzen. +Die Integration von Drittanbieteranwendungen in Logto ermöglicht es dir, Logto als [Identitätsanbieter (IdP)](https://auth.wiki/identity-provider) für externe Anwendungen zu nutzen. -Ein Identitätsanbieter (IdP) ist ein Dienst, der Benutzeridentitäten überprüft und deren Anmeldeinformationen verwaltet. Nach der Bestätigung der Identität eines Benutzers generiert der IdP Authentifizierungstokens oder -assertions und ermöglicht dem Benutzer den Zugriff auf verschiedene Anwendungen oder Dienste, ohne sich erneut anmelden zu müssen. +Ein Identitätsanbieter (IdP) ist ein Dienst, der Benutzeridentitäten überprüft und deren Anmeldedaten verwaltet. Nach der Bestätigung der Identität eines Benutzers generiert der IdP Authentifizierungstoken oder -aussagen und ermöglicht dem Benutzer den Zugriff auf verschiedene Anwendungen oder Dienste, ohne sich erneut anmelden zu müssen. Im Gegensatz zu den Anwendungen, die du im Leitfaden [Logto in deine Anwendung integrieren](/integrate-logto/integrate-logto-into-your-application) erstellt hast und die von dir entwickelt und vollständig kontrolliert werden, sind Drittanbieteranwendungen unabhängige Dienste, die von externen Entwicklern oder Geschäftspartnern entwickelt wurden. -Dieser Integrationsansatz eignet sich hervorragend für gängige Geschäftsszenarien. Du kannst es Benutzern ermöglichen, mit ihren Logto-Konten auf Partneranwendungen zuzugreifen, ähnlich wie Unternehmensnutzer sich mit Google Workspace bei Slack anmelden. Du kannst auch eine offene Plattform aufbauen, auf der Drittanbieteranwendungen die Funktion „Mit Logto anmelden“ hinzufügen können, ähnlich wie „Mit Google anmelden“. +Dieser Integrationsansatz eignet sich hervorragend für gängige Geschäftsszenarien. Du kannst es Benutzern ermöglichen, mit ihren Logto-Konten auf Partneranwendungen zuzugreifen, ähnlich wie Unternehmensbenutzer sich mit Google Workspace bei Slack anmelden. Du kannst auch eine offene Plattform aufbauen, auf der Drittanbieteranwendungen die Funktion „Mit Logto anmelden“ hinzufügen können, ähnlich wie „Mit Google anmelden“. -Logto ist ein Identitätsdienst, der auf dem [OpenID Connect (OIDC)](https://auth.wiki/openid-connect)-Protokoll basiert und sowohl [Authentifizierung (Authentication)](https://auth.wiki/authentication) als auch [Autorisierung (Authorization)](https://auth.wiki/authorization) bereitstellt. Dadurch ist die Integration einer OIDC-Drittanbieteranwendung genauso unkompliziert wie bei einer klassischen Webanwendung. +Logto ist ein Identitätsdienst, der auf dem [OpenID Connect (OIDC)](https://auth.wiki/openid-connect)-Protokoll basiert und sowohl [Authentifizierung (Authentication)](https://auth.wiki/authentication) als auch [Autorisierung (Authorization)](https://auth.wiki/authorization) bereitstellt. Dadurch wird die Integration einer OIDC-Drittanbieter-App genauso unkompliziert wie bei einer herkömmlichen Webanwendung. Da OIDC auf [OAuth 2.0](https://auth.wiki/oauth-2.0) aufbaut und eine Authentifizierungsschicht hinzufügt, kannst du Drittanbieteranwendungen auch über das OAuth-Protokoll integrieren. ## Drittanbieteranwendung in Logto erstellen \{#create-an-third-party-application-in-logto} -1. Gehe zu Konsole > Anwendungen -2. Wähle „Drittanbieter-App“ als Anwendungstyp und eines der folgenden Integrationsprotokolle: +1. Gehe zu Konsole > Anwendungen. +2. Klicke auf die Schaltfläche „Anwendung erstellen“. Wähle „Drittanbieter-App“ als Anwendungstyp und eines der folgenden Integrationsprotokolle: - OIDC / OAuth -3. Gib einen Namen und eine Beschreibung für deine Anwendung ein und klicke auf die Schaltfläche „Erstellen“. Es wird eine neue Drittanbieteranwendung erstellt. +3. Gib einen Namen und eine Beschreibung für deine Anwendung ein und klicke auf „Erstellen“. Eine neue Drittanbieteranwendung wird erstellt. -Alle erstellten Drittanbieteranwendungen werden auf der Anwendungsseite unter dem Tab „Drittanbieter-Apps“ katalogisiert. Diese Anordnung hilft dir, sie von deinen eigenen Anwendungen zu unterscheiden und alle Anwendungen an einem Ort einfacher zu verwalten. +Alle erstellten Drittanbieteranwendungen werden auf der Anwendungsseite unter dem Tab „Drittanbieter-Apps“ katalogisiert. Diese Anordnung hilft dir, sie von deinen eigenen Anwendungen zu unterscheiden und alle Anwendungen an einem Ort zu verwalten. ## OIDC-Konfigurationen einrichten \{#set-up-the-oidc-configurations} @@ -38,15 +38,15 @@ Bevor du die OIDC-Konfigurationen einrichtest, stelle bitte sicher, dass du [ein 1. Gib die [**Redirect-URI**](/integrate-logto/application-data-structure#redirect-uris) deiner OIDC-Drittanbieteranwendung an. Dies ist die URL, zu der die Drittanbieteranwendung Benutzer weiterleitet, nachdem sie von Logto authentifiziert wurden. Diese Information findest du in der Regel auf der IdP-Verbindungsseite der Drittanbieteranwendung. -2. Rufe die [**Client-ID**](/integrate-logto/application-data-structure#application-id) und das [**Client-Secret**](/integrate-logto/application-data-structure#application-secret) von der Logto-Anwendungsdetailseite ab und trage sie in die IdP-Verbindungseinstellungen deines Dienstanbieters ein. +2. Rufe die [**Client-ID**](/integrate-logto/application-data-structure#application-id) und das [**Client-Secret**](/integrate-logto/application-data-structure#application-secret) von der Logto-Anwendungsdetailseite ab und trage sie in die IdP-Verbindungseinstellungen deines Service-Providers ein. -3. Rufe den [**Autorisierungsendpunkt**](/integrate-logto/application-data-structure#authorization-endpoint) und den [**Token-Endpunkt**](/integrate-logto/application-data-structure#token-endpoint) von der Logto-Anwendungsdetailseite ab und gib sie an deinen Dienstanbieter weiter. - Wenn dein Dienstanbieter OIDC-Discovery unterstützt, kannst du einfach den **Discovery-Endpunkt** von der Logto-Anwendungsdetailseite kopieren und an deinen Dienstanbieter weitergeben. Der Dienstanbieter kann dann alle aktuellen OIDC-Authentifizierungsinformationen automatisch vom Discovery-Endpunkt abrufen. +3. Rufe den [**Autorisierungsendpunkt**](/integrate-logto/application-data-structure#authorization-endpoint) und den [**Token-Endpunkt**](/integrate-logto/application-data-structure#token-endpoint) von der Logto-Anwendungsdetailseite ab und gib sie an deinen Service-Provider weiter. + Wenn dein Service-Provider OIDC-Discovery unterstützt, kannst du einfach den **Discovery-Endpunkt** von der Logto-Anwendungsdetailseite kopieren und an deinen Service-Provider weitergeben. Der Service-Provider kann dann automatisch alle aktuellen OIDC-Authentifizierungsinformationen vom Discovery-Endpunkt abrufen. Andernfalls klicke auf die Schaltfläche **Endpunktdetails anzeigen**, um alle OIDC-Authentifizierungsendpunkte einzusehen. ## Zustimmungsbildschirm für OIDC-Drittanbieteranwendungen \{#consent-screen-for-oidc-third-party-applications} -Aus Sicherheitsgründen werden alle OIDC-Drittanbieteranwendungen nach der Authentifizierung durch Logto zu einem [Zustimmungsbildschirm](/end-user-flows/consent-screen) für die Benutzerautorisierung weitergeleitet. +Aus Sicherheitsgründen werden alle OIDC-Drittanbieteranwendungen nach der Authentifizierung durch Logto zu einem [Zustimmungsbildschirm (Consent screen)](/end-user-flows/consent-screen) für die Benutzerautorisierung weitergeleitet. Alle von Drittanbietern angeforderten [Berechtigungen für Benutzerprofile](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes), [API-Ressourcen-Berechtigungen](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [Organisationsberechtigungen](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) und Informationen zur Organisationsmitgliedschaft werden auf dem Zustimmungsbildschirm angezeigt. @@ -98,14 +98,14 @@ So verwaltest du dies: - Definiere [globale Rollen](/authorization/role-based-access-control) oder [Organisationsrollen](/authorization/organization-template) mit spezifischen Berechtigungen. - Weisen Benutzern Rollen entsprechend ihrem Zugriffsbedarf zu. -- Benutzer erben die Berechtigungen automatisch von ihren Rollen. +- Benutzer erben automatisch die Berechtigungen ihrer Rollen. ## Verwandte Ressourcen \{#related-resources} - Anwendungsfall: Apache Answer integrieren, um eine Community für deine Nutzer zu starten + Anwendungsfall: Integriere Apache Answer, um eine Community für deine Nutzer zu starten diff --git a/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index f98ce6e5c34..d2c13d8a1ff 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,6 +3,7 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Logto Cloud-Dienst @@ -10,7 +11,7 @@ import CustomDomains from '@site/src/assets/search.svg'; Wenn du Fragen zu Cloud-Diensten hast und zusätzliche Unterstützung benötigst, kontaktiere uns bitte. -## Funktionen für den Cloud-Dienst \{#features-for-cloud-service} +## Funktionen für Cloud-Dienste \{#features-for-cloud-service} , }, @@ -49,7 +50,7 @@ Wenn du Fragen zu Cloud-Diensten hast und zusätzliche Unterstützung benötigst label: 'Eigene Domains', href: '/logto-cloud/custom-domain', description: - 'Nutze deine eigene Domain für deinen Logto-Mandanten, um ein konsistentes Branding bei der Anmeldung zu gewährleisten.', + 'Nutze deine eigene Domain für deinen Logto-Mandanten, um ein konsistentes Branding bei der Anmeldeerfahrung zu gewährleisten.', customProps: { icon: , }, @@ -63,5 +64,15 @@ Wenn du Fragen zu Cloud-Diensten hast und zusätzliche Unterstützung benötigst icon: , }, }, + { + type: 'link', + label: 'Systemlimit', + href: '/logto-cloud/system-limit', + description: + 'Verstehe die Systemlimits und den Raten-Schutz für Dev-, Pro- und Enterprise-Mandanten.', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index a44679ac90d..4760b6fe9a6 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -6,12 +6,12 @@ sidebar_position: 4 # Benutzerdefinierte Domain -Dein Logto-Mandant verfügt standardmäßig über eine kostenlose Domain `{{tenant-id}}.app.logto`. Du kannst jedoch das Nutzererlebnis und die Markenbekanntheit steigern, indem du eine benutzerdefinierte Domain wie `auth.example.com` verwendest. +Dein Logto-Mandant verfügt standardmäßig über eine kostenlose Domain `{{tenant-id}}.app.logto`. Du kannst jedoch das Benutzererlebnis und die Markenbekanntheit steigern, indem du eine benutzerdefinierte Domain wie `auth.example.com` verwendest. Deine benutzerdefinierte Domain wird für mehrere Funktionen genutzt: -- URLs der [Anmelde- und Registrierungsseite](/end-user-flows/sign-up-and-sign-in) -- [Passkey](/end-user-flows/mfa/webauthn) Verknüpfungs-URLs (Wenn du die Domain änderst, nachdem Nutzer Passkeys verknüpft haben, kann dies deren Authentifizierung blockieren). +- URLs für [Anmelde- und Registrierungsseite](/end-user-flows/sign-up-and-sign-in) +- [Passkey](/end-user-flows/mfa/webauthn) Verknüpfungs-URLs (Wenn du die Domain änderst, nachdem Benutzer Passkeys verknüpft haben, kann dies deren Authentifizierung blockieren). - Callback-URIs für [soziale Connectors](/connectors/social-connectors) oder [Enterprise SSO Connectors](/connectors/enterprise-connectors). - [SDK-Endpunkt](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) zur Integration von Logto in deine Anwendung. @@ -28,7 +28,7 @@ Um eine neue benutzerdefinierte Domain in der Logto Console hinzuzufügen, folge Domain hinzufügen -3. Kopiere den CNAME-Wert aus der Tabelle und füge ihn bei deinem DNS-Anbieter als Eintrag hinzu. +3. Kopiere den CNAME-Wert aus der Tabelle und gehe zu deinem DNS-Anbieter, um den Eintrag hinzuzufügen. -Wenn du beim Einrichten deiner benutzerdefinierten Domain auf SSL-Zertifikatsprobleme stößt, kann dies an CAA-Einträgen in deiner DNS-Konfiguration liegen. CAA-Einträge legen fest, welche Zertifizierungsstellen (CAs) berechtigt sind, Zertifikate für deine Domain auszustellen. Wenn du CAA-Einträge verwendest, musst du sowohl "letsencrypt.org" als auch "pki.goog" autorisieren, damit Logto SSL-Zertifikate ausstellen kann. +Wenn du beim Einrichten deiner benutzerdefinierten Domain auf SSL-Zertifikatsprobleme stößt, kann dies mit CAA-Einträgen in deiner DNS-Konfiguration zusammenhängen. CAA-Einträge legen fest, welche Zertifizierungsstellen (CAs) berechtigt sind, Zertifikate für deine Domain auszustellen. Wenn du CAA-Einträge verwendest, musst du sowohl "letsencrypt.org" als auch "pki.goog" autorisieren, damit Logto SSL-Zertifikate ausstellen kann. -Um SSL-Zertifikatsprobleme im Zusammenhang mit CAA-Einträgen zu beheben, siehe die [Cloudflare-Dokumentation](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) zu CAA-Einträgen. +Zur Fehlerbehebung und Lösung von SSL-Zertifikatsproblemen im Zusammenhang mit CAA-Einträgen siehe die [Cloudflare-Dokumentation](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) zu CAA-Einträgen.
-### Fehler „Der Hostname ist mit einer gehaltenen Zone verknüpft“ \{#the-hostname-is-associated-with-a-held-zone-error} +### Fehler "The hostname is associated with a held zone" \{#the-hostname-is-associated-with-a-held-zone-error} -Wenn du beim Hinzufügen einer benutzerdefinierten Domain die Fehlermeldung „Der Hostname ist mit einer gehaltenen Zone verknüpft, bitte kontaktiere den Eigentümer, um die Sperre aufzuheben“ erhältst, bedeutet das, dass die Domain bereits in einer Cloudflare-Zone ist und auf den Status „Zone Hold“ gesetzt wurde. Weitere Informationen findest du in dieser [Cloudflare-Dokumentation](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/). +Wenn du beim Hinzufügen einer benutzerdefinierten Domain die Fehlermeldung "The hostname is associated with a held zone, please contact the owner to have the hold removed" erhältst, bedeutet dies, dass die Domain bereits in einer Cloudflare-Zone ist und auf den Status "Zone Hold" gesetzt wurde. Weitere Informationen findest du in dieser [Cloudflare-Dokumentation](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/). -Um dieses Problem zu beheben, musst du die Zonensperre aufheben. Folge dem obigen Link für Anweisungen, wie du die Zonensperre in Cloudflare aufhebst. +Um dieses Problem zu lösen, musst du den Zone Hold aufheben. Folge dem obigen Link für Anweisungen, wie du den Zone Hold in Cloudflare aufhebst.
-### Verbindungstimeout (Fehlercode 522) bei auf Cloudflare gehosteter Domain \{#cloudflare-522-timeout} +### Verbindungstimeout (Fehlercode 522) bei Cloudflare-gehosteter Domain \{#cloudflare-522-timeout} @@ -78,9 +78,40 @@ Wenn deine Domain bei Cloudflare gehostet wird, deaktiviere den Cloudflare-Proxy
+
+ + +### Fehler "Redirect URI does not match" nach Einrichtung der benutzerdefinierten Domain \{#redirect-uri-mismatch} + + + +Wenn du nach dem Hinzufügen deiner benutzerdefinierten Domain den Fehler "redirect URI does not match" erhältst, musst du deine SDK-Konfiguration aktualisieren, damit der Endpunkt die benutzerdefinierte Domain verwendet. + +**Zum Thema "primäre Domain":** + +Es gibt in Logto keine separate Einstellung für eine "primäre Domain". Nach dem Hinzufügen einer benutzerdefinierten Domain bleiben sowohl deine benutzerdefinierte Domain als auch die Standarddomain `{tenant-id}.logto.app` gültig. Die Domain, die du im `endpoint`-Parameter deines SDKs konfigurierst, bestimmt, welche Domain für Authentifizierungsflüsse verwendet wird. + +**Lösung:** + +Aktualisiere den `endpoint`-Parameter bei der Initialisierung deines SDKs, sodass deine benutzerdefinierte Domain verwendet wird: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // Verwende deine benutzerdefinierte Domain + appId: 'your-app-id', + // ... weitere Optionen +}); +``` + +Überprüfe außerdem, ob die in Console → Anwendungen registrierten Redirect-URIs mit der verwendeten Domain übereinstimmen. + +**Hinweis:** Logto stellt SSL-Zertifikate für deine benutzerdefinierte Domain automatisch bereit und verwaltet sie. Du musst keine eigenen Zertifikate konfigurieren. + +
+ ## Benutzerdefinierte Domain verwenden \{#use-custom-domain} -Sobald du deine Einstellungen konfiguriert hast, stehen sowohl dein benutzerdefinierter Domainname als auch der Standard-Logto-Domainname für deinen Mandanten zur Verfügung. Für die Aktivierung deiner benutzerdefinierten Domain sind jedoch bestimmte Konfigurationen erforderlich. +Sobald du deine Einstellungen konfiguriert hast, stehen sowohl dein benutzerdefinierter Domainname als auch der Standard-Logto-Domainname für deinen Mandanten zur Verfügung. Für die Aktivierung des benutzerdefinierten Domainnamens sind jedoch bestimmte Konfigurationen erforderlich. :::note @@ -99,11 +130,11 @@ const client = new LogtoClient({ }); ``` -### Anpassung der Auth-Endpunkte für andere Anwendungen \{#modifying-auth-endpoints-for-other-applications} +### Auth-Endpunkte für andere Anwendungen anpassen \{#modifying-auth-endpoints-for-other-applications} Wenn du Anwendungen hast, die nicht das Logto SDK verwenden, musst du deren Auth-Endpunkte aktualisieren. -Du findest die Auth-Endpunkte unter der Well-known-URL: +Du findest die Auth-Endpunkte unter der Well-Known-URL: ``` https://auth.example.com/oidc/.well-known/openid-configuration @@ -111,6 +142,6 @@ https://auth.example.com/oidc/.well-known/openid-configuration ### Aktualisierung der Callback-URI des Social Connectors \{#updating-the-social-connectors-callback-uri} -Die Callback-URI des Social Connectors wird automatisch aktualisiert, wenn deine Nutzer die benutzerdefinierte Domain verwenden. Du musst jedoch in der Entwicklerkonsole des Social Providers die Callback-URI aktualisieren. +Die Callback-URI des Social Connectors wird automatisch aktualisiert, wenn deine Benutzer die benutzerdefinierte Domain verwenden. Du musst jedoch in der Entwicklerkonsole des Social Providers die Callback-URI aktualisieren. -Wenn deine Nutzer die benutzerdefinierte Domain verwenden, wird die Callback-URI des Social Connectors die neue Domain nutzen. Daher musst du in der Entwicklerkonsole des Social Providers die Callback-URI manuell aktualisieren. +Wenn deine Benutzer die benutzerdefinierte Domain verwenden, wird die Callback-URI des Social Connectors die neue Domain nutzen. Daher musst du in der Entwicklerkonsole des Social Providers die Callback-URI manuell aktualisieren. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..9ed1ca4c408 --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# Systemlimit + +Bei Logto haben wir großzügige Limits für alle Pläne festgelegt und bieten flexible Pay-as-you-go-Optionen, sodass Nutzer nur für das bezahlen, was sie tatsächlich verwenden. + +Du wirst feststellen, dass einige Punkte auf der Preisseite als _unbegrenzt_ oder als _kontinuierliches Pay-as-you-go ohne Obergrenze_ gekennzeichnet sind. Das bedeutet, dass sie im Allgemeinen ohne Einschränkung genutzt werden können, aber Logto behält sich das Recht vor, diese tatsächlichen Limits im Laufe der Zeit anzupassen, um eine faire Nutzung für alle Nutzer zu gewährleisten. Anders gesagt: Entitätslimits sind strikte Obergrenzen, die die allgemeine Gesundheit der Plattform schützen. Sie sind kein Bestandteil der Preisgestaltung, können aber je nach Plan-Gruppe variieren. + +Wenn dein Anwendungsfall vernünftig ist, aber ein Systemlimit erreicht, kannst du uns gerne kontaktieren und uns dein Feedback mitteilen. Das hilft uns, reale Nutzungsmuster besser zu verstehen und die Systemlimits so anzupassen, dass wir unsere treuen Kunden besser unterstützen können. + +## Ratenlimit-Schutz auf Mandantenebene \{#tenant-level-rate-limit-protection} + +### Dev-Mandanten \{#dev-tenants} + +Für Dev-Mandanten können Nutzer die kostenlosen Funktionen und Angebote von Logto nutzen. Um Missbrauch zu verhindern und klare Erwartungen zu setzen, definieren wir bestimmte Systemlimits. Diese Limits helfen uns, unsere Plattform nachhaltig zu betreiben und gleichzeitig kostenlosen Zugang für Test- und Entwicklungszwecke zu bieten. + +Wenn du dein Kontingent erhöhen möchtest, kannst du uns für Unterstützung kontaktieren. Wir empfehlen auch ein Upgrade von **Dev** auf **Pro**, wodurch die Begrenzung aufgehoben wird und du sofort vollen Zugriff erhältst. + +| **Funktion** | **Entitätslimit** | +| ----------------------------------------- | ----------------- | +| **Inklusive Tokens** | 50k pro Monat | +| **Anwendungen** | | +| Gesamtanzahl Anwendungen | 100 | +| Maschine-zu-Maschine-Apps | 100 | +| Drittanbieter-Apps | 100 | +| **API-Ressourcen** | | +| Ressourcenanzahl | 100 | +| **Benutzerauthentifizierung** | | +| Social Connector | 100 | +| Enterprise SSO | 100 | +| **Benutzerverwaltung** | | +| Benutzerrollen | 100 | +| Maschine-zu-Maschine-Rollen | 100 | +| Berechtigung pro Rolle | 100 | +| **Organisationen** | | +| Organisationsanzahl | 5.000 | +| Benutzer pro Organisation | 100k | +| Organisations-Benutzerrollen | 1.000 | +| Organisations-Maschine-zu-Maschine-Rollen | 100 | +| Organisationsberechtigungen | 1.000 | +| **Entwickler und Plattform** | | +| Webhooks | 10 | +| Audit-Log-Aufbewahrung | 14 Tage | +| Mandantenmitglieder | 20 | + +### Pro-Mandant \{#pro-tenant} + +Für Pro-Mandanten definieren Entitätslimits die Obergrenze für Add-ons und andere „unbegrenzte“ Entitäten wie Anwendungen. Die Details der Systemlimits des Pro-Plans sind unten aufgeführt. + +| **Funktion** | **Entitätslimit** | +| ----------------------------------------- | ----------------- | +| **Inklusive Tokens** | 10 Mio. pro Monat | +| **Anwendungen** | | +| Gesamtanzahl Anwendungen | 100 | +| Maschine-zu-Maschine-Apps | 100 | +| OIDC/OAuth Drittanbieter-Apps | 100 | +| SAML-Apps | 100 | +| **API-Ressourcen** | | +| Ressourcenanzahl | 1.000 | +| Berechtigung pro Ressource | 1.000 | +| **Benutzerauthentifizierung** | | +| Social Connectors | 100 | +| Enterprise SSO | 100 | +| **Benutzerverwaltung** | | +| Benutzerrollen | 1.000 | +| Maschine-zu-Maschine-Rollen | 100 | +| **Organisationen** | | +| Organisationsanzahl | 100k | +| Benutzer pro Organisation | 100k | +| Organisations-Benutzerrollen | 1.000 | +| Organisations-Maschine-zu-Maschine-Rollen | 100 | +| Organisationsberechtigungen | 1.000 | +| **Entwickler und Plattform** | | +| Webhooks | 10 | +| Audit-Log-Aufbewahrung | 14 Tage | +| Eigene Domains | 10 | +| Mandantenmitglieder | 100 | + +### Enterprise \{#enterprise} + +Für Enterprise-Pläne sind Limits und Funktionen vollständig anpassbar und werden über den Vertrag verwaltet. Bitte [kontaktiere uns](https://logto.io/contact) für weitere Details. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index 61bde8a89b5..a3dace3b60d 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -13,8 +13,8 @@ Wenn du einen separaten Mandanten für die **Produktions**- (Prod) Umgebung oder Klicke auf „Mandant erstellen“ und dann: - Name für den Mandanten -- Wähle eine [Mandanten-Datenregion](#tenant-region) aus -- Wähle den [Mandantentyp](#tenant-types-dev-vs-prod) (Umgebung) aus +- Wähle eine [Mandanten-Datenregion](#tenant-region) +- Wähle den [Mandantentyp](#tenant-types-dev-vs-prod) (Umgebung) Für einen bestehenden Mandanten gehe zu Konsole > Mandanteneinstellungen > Einstellungen. Hier kannst du: @@ -36,23 +36,23 @@ Wenn du einen Mandanten erstellst, kannst du die Region auswählen, in der die M In der Regel solltest du die Region wählen, die deinen Kunden am nächsten ist, um die Latenz zu minimieren und die Leistung zu verbessern. -Logto nutzt das globale Edge-Netzwerk, um die beste Leistung und Verfügbarkeit für deine Anwendungen zu bieten. Das Routing der Anfragen ist optimiert, damit deine Nutzer immer mit der leistungsstärksten Option verbunden sind. +Logto nutzt das globale Edge-Netzwerk, um die beste Leistung und Verfügbarkeit für deine Anwendungen zu bieten. Das Routing der Anfragen ist optimiert, um sicherzustellen, dass deine Benutzer immer mit der leistungsstärksten Option verbunden sind. :::note -Du suchst eine andere Region? [Kontaktiere uns](https://logto.io/contact), um: +Du suchst nach einer anderen Region? [Kontaktiere uns](https://logto.io/contact), um: -- Eine neue Public-Cloud-Region anzufragen -- Informationen zu einer Logto Private Cloud-Bereitstellung an deinem Wunschstandort zu erhalten +- Eine neue öffentliche Cloud-Region anzufragen +- Dich nach einer Logto Private Cloud-Bereitstellung an deinem bevorzugten Standort zu erkundigen ::: ## Mandantentypen: Dev vs. Prod \{#tenant-types-dev-vs-prod} -Es gibt zwei Arten von Mandanten in Logto Cloud: Entwicklung (Dev) und Produktion (Prod). Mit dieser Unterscheidung kannst du deine Projekte effizienter über verschiedene Umgebungen hinweg verwalten und gleichzeitig den vollen Nutzen von Logto genießen. +Es gibt zwei Arten von Mandanten in Logto Cloud: Entwicklung (Dev) und Produktion (Prod). Mit dieser Mandantendifferenzierung kannst du deine Projekte über verschiedene Umgebungen hinweg effizienter verwalten und gleichzeitig den vollen Nutzen von Logto genießen. Du kannst den Mandantentyp während der Erstellung auswählen. Wenn du bereit bist, in die Produktion zu gehen, gibt es zwei Optionen: -- **Neuen Produktionsmandanten erstellen** - Richte einen neuen Produktionsmandanten ein und konfiguriere ihn von Grund auf neu. Das ist ideal, wenn du Entwicklungs- und Produktionsumgebungen getrennt halten möchtest. +- **Einen neuen Produktionsmandanten erstellen** + Richte einen neuen Produktionsmandanten ein und konfiguriere ihn von Grund auf neu. Dies ist ideal, wenn du Entwicklungs- und Produktionsumgebungen getrennt halten möchtest. - **Deinen aktuellen Dev-Mandanten in Produktion umwandeln** Wenn du die Konfiguration nicht erneut durchführen oder Benutzer migrieren möchtest, kannst du deinen bestehenden Entwicklungsmandanten auf einen kostenpflichtigen Produktionsmandanten upgraden. @@ -65,44 +65,18 @@ Du kannst den Mandantentyp während der Erstellung auswählen. Wenn du bereit bi ### Entwicklung \{#development} -Der Entwicklungsmandant (Dev-Mandant) ist in erster Linie für Testzwecke gedacht und sollte nicht in einer Produktionsumgebung verwendet werden. Diese Mandanten ermöglichen den Zugriff auf Premium- und kostenpflichtige Funktionen, die in kostenpflichtigen Plänen enthalten sind – kostenlos und ohne Abonnement. +Der Entwicklungsmandant (Dev-Mandant) ist in erster Linie für Testzwecke gedacht und sollte nicht in einer Produktionsumgebung verwendet werden. Diese Mandanten ermöglichen den Zugriff auf Premium- und kostenpflichtige Funktionen, die in kostenpflichtigen Plänen enthalten sind, kostenlos und ohne Abonnement. Es gelten jedoch bestimmte Einschränkungen für Entwicklungsmandanten: - Der Dev-Mandant löscht Benutzer automatisch nach 90 Tagen. Siehe die [Dev-Mandanten-Datenspeicherungsrichtlinie](./dev-tenant-data-retention) für Details. -- Während der Anmeldeerfahrung erscheint ein Banner, das anzeigt, dass sich der Mandant im Entwicklungsmodus befindet. -- Entwicklungsmandanten können Quotenbeschränkungen für bestimmte Funktionen haben. Diese Limits werden auf der jeweiligen Funktionsdetailseite erläutert, falls zutreffend. -- Logto kann die Quotenbeschränkungen für Entwicklungsmandanten aktualisieren und wird versuchen, dich im Voraus zu benachrichtigen. - -| Funktion | Entitätslimit | -| ----------------------------- | ------------- | -| **Enthaltene Tokens** | 50k pro Monat | -| **Anwendungen** | -| Gesamtanzahl Anwendungen | 100 | -| Maschine-zu-Maschine-Apps | 100 | -| Drittanbieter-Apps | 100 | -| **API-Ressourcen** | | -| Ressourcenanzahl | 100 | -| **Benutzerauthentifizierung** | | -| Social Connector | 100 | -| Enterprise SSO | 100 | -| **Benutzerverwaltung** | | -| Benutzerrollen | 100 | -| Maschine-zu-Maschine-Rollen | 100 | -| Berechtigung pro Rolle | 100 | -| **Organisationen** | | -| Organisationsanzahl | 5.000 | -| Benutzer pro Organisation | 5.000 | -| Organisationsrollen | 100 | -| Organisationsberechtigungen | 100 | -| **Entwickler und Plattform** | | -| Webhooks | 10 | -| Audit-Log-Aufbewahrung | 14 Tage | -| Mandantenmitglieder | 20 | +- Während der Anmeldeerfahrung erscheint ein Banner, das darauf hinweist, dass sich der Mandant im Entwicklungsmodus befindet. +- Entwicklungsmandanten können Quotenbeschränkungen für bestimmte Funktionen haben. Diese Beschränkungen werden auf der jeweiligen Funktionsdetailseite erläutert, falls zutreffend. Eine vollständige Liste der Einschränkungen des Dev-Plans findest du auf der Seite [Systemlimit](./system-limit). +- Logto kann die Quotenbeschränkungen des Entwicklungsmandanten aktualisieren und wird versuchen, dich im Voraus zu benachrichtigen. ### Produktion \{#production} -Der Produktionsmandant ist der Ort, an dem Endbenutzer auf die Live-App zugreifen und du möglicherweise ein [kostenpflichtiges Abonnement](https://logto.io/pricing) benötigst. Du kannst dich für den Free-Plan oder Pro-Plan anmelden, um einen Produktionsmandanten zu erstellen. Wenn du dich für den Free-Plan entscheidest, kannst du maximal 10 Mandanten erstellen. +Der Produktionsmandant ist der Ort, an dem Endbenutzer auf die Live-App zugreifen und du möglicherweise ein [kostenpflichtiges Abonnement](https://logto.io/pricing) benötigst. Du kannst dich für den Free-Plan oder Pro-Plan anmelden, um einen Produktionsmandanten zu erstellen. Wenn du dich für den Free-Plan anmeldest, kannst du nur bis zu 10 Mandanten erstellen. ## MFA aktivieren \{#enable-mfa} @@ -118,7 +92,7 @@ Um loszulegen, [kontaktiere uns](https://logto.io/contact). Wir helfen dir bei d ## Mandanten verlassen \{#leave-tenant} -Ein Admin kann [weitere Mitglieder](/logto-cloud/tenant-member-management) zu diesem Mandanten einladen. +Ein Admin kann [weitere Mitglieder einladen](/logto-cloud/tenant-member-management) zu diesem Mandanten. Wenn es mindestens einen weiteren **Admin** (Rolle) gibt oder du ein **Mitarbeiter** (Rolle) bist, kannst du den Mandanten verlassen. Nach dem Verlassen bleiben alle Ressourcen im Mandanten erhalten, aber du hast keinen Zugriff mehr darauf. @@ -135,7 +109,7 @@ Wenn du Hilfe benötigst, [kontaktiere uns](https://logto.io/contact) per E-Mail
-### Wie migriere ich zwischen Logto-Mandanten oder zwischen Cloud und OSS oder exportiere alle Benutzerdaten? \{#how-to-migrate-between-logto-tenants-or-between-cloud-and-oss-or-export-all-user-data} +### Wie kann ich zwischen Logto-Mandanten oder zwischen Cloud und OSS migrieren oder alle Benutzerdaten exportieren? \{#how-to-migrate-between-logto-tenants-or-between-cloud-and-oss-or-export-all-user-data} @@ -143,12 +117,12 @@ Du kannst derzeit deinen **Entwicklungs**-Mandanten selbst in einen kostenpflich Eine Self-Service-Migration (alle Konfigurationen und Benutzerdaten) zwischen Logto Cloud und der OSS-Version wird jedoch nicht unterstützt. Wenn du diesen Service benötigst, [kontaktiere das Logto-Team](https://logto.io/contact), um deine Optionen zu besprechen. -Wenn du planst, Logto Cloud für ein Projekt nicht mehr zu nutzen, kann Logto dir beim Export aller Benutzerdaten helfen. Bitte [melde dich bei uns](https://logto.io/contact). +Wenn du planst, Logto Cloud für ein Projekt nicht mehr zu verwenden, kann Logto dir beim Export aller Benutzerdaten helfen. Bitte [melde dich bei uns](https://logto.io/contact).
## Verwandte Ressourcen \{#related-resources} - Schütze deine Identitäten in lokalen Regionen und dedizierten Computing-Ressourcen + Schütze deine Identitäten in lokalen Regionen und dedizierten Rechenressourcen diff --git a/i18n/de/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/de/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index 7316e65099b..918a79b1572 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -17,7 +17,7 @@ import Tabs from '@theme/Tabs'; ## GitPod \{#gitpod} -Um einen Online-GitPod-Arbeitsbereich für Logto zu starten, klicke hier. Warte einen Moment, du wirst eine Nachricht wie diese sehen: +Um einen Online-GitPod-Arbeitsbereich für Logto zu starten, klicke hier. Warte einen Moment, dann siehst du eine Nachricht wie:

-Docker Compose CLI wird normalerweise mit [Docker Desktop](https://www.docker.com/products/docker-desktop) geliefert. +Die Docker Compose CLI ist normalerweise in [Docker Desktop](https://www.docker.com/products/docker-desktop) enthalten. :::caution -Verwende unseren Docker Compose-Befehl nicht für die Produktion! Da wir derzeit eine integrierte Postgres-Datenbank zusammen mit der Logto-App in `docker-compose.yml` gebündelt haben, wird bei jedem erneuten Ausführen des Befehls eine neue Datenbankinstanz erstellt, und alle zuvor gespeicherten Daten gehen verloren. +Verwende unseren Docker Compose-Befehl nicht für die Produktion! Da wir derzeit eine integrierte Postgres-Datenbank zusammen mit der Logto-App in `docker-compose.yml` bündeln, +wird bei jedem erneuten Ausführen des Befehls eine neue Datenbankinstanz erstellt und alle zuvor gespeicherten Daten gehen verloren. ::: ```bash curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | docker compose -p logto -f - up ``` -Nach einer erfolgreichen Komposition wirst du eine Nachricht wie diese sehen: +Nach einer erfolgreichen Komposition siehst du eine Nachricht wie: @@ -62,7 +63,7 @@ Nach einer erfolgreichen Komposition wirst du eine Nachricht wie diese sehen:

Schritt 1

-Bereite eine [PostgreSQL](https://www.postgresql.org/)@^14.0-Instanz vor und verwende [Logto CLI](/logto-oss/using-cli), um eine Datenbank für Logto zu initialisieren: +Bereite eine [PostgreSQL](https://www.postgresql.org/)@^14.0 Instanz vor und verwende die [Logto CLI](/logto-oss/using-cli), um eine Datenbank für Logto zu initialisieren: @@ -96,16 +97,16 @@ docker pull svhd/logto:latest

Schritt 3

-Ordne die Container-Ports der Logto-Kern- und Admin-App zu, z. B. `3001:3001` und `3002:3002`; und setze die folgenden Umgebungsvariablen für den Container: +Mappe die Container-Ports auf Logto Core und Admin App, z. B. `3001:3001` und `3002:3002`; und setze die folgenden Umgebungsvariablen im Container: ```yml TRUST_PROXY_HEADER: 1 # Setze auf 1, wenn du einen HTTPS-Proxy (z. B. Nginx) vor Logto hast -ENDPOINT: https:// # (Optional) Ersetze durch deine Logto-Endpunkt-URL, wenn du eine benutzerdefinierte Domain verwendest -ADMIN_ENDPOINT: https:// # (Optional) Ersetze durch deine Logto-Admin-URL, wenn du eine benutzerdefinierte Domain verwendest -DB_URL: postgres://username:password@your_postgres_url:port/db_name # Ersetze durch deinen Postgres DSN +ENDPOINT: https:// # (Optional) Ersetze durch deine Logto-Endpunkt-URL, wenn du eine eigene Domain verwendest +ADMIN_ENDPOINT: https:// # (Optional) Ersetze durch deine Logto-Admin-URL, wenn du eine eigene Domain verwendest +DB_URL: postgres://username:password@your_postgres_url:port/db_name # Ersetze durch deinen Postgres-DSN ``` -Führe den Container mit allen oben genannten Umgebungsvariablen aus: +Starte den Container mit allen oben genannten Umgebungsvariablen: ```bash docker run \ @@ -121,12 +122,12 @@ docker run \ :::tip -- Wenn du Docker Hub verwendest, verwende `svhd/logto:latest` anstelle von `ghcr.io/logto-io/logto:latest`. +- Wenn du Docker Hub verwendest, nutze `svhd/logto:latest` statt `ghcr.io/logto-io/logto:latest`. - Verwende `host.docker.internal` oder `172.17.0.1` in `DB_URL`, um auf die Host-IP zu verweisen. ::: -Schließlich wirst du eine Nachricht wie diese sehen: +Am Ende siehst du eine Nachricht wie: @@ -137,29 +138,29 @@ Schließlich wirst du eine Nachricht wie diese sehen: - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -Höhere Versionen funktionieren normalerweise, sind aber nicht garantiert. +Höhere Versionen funktionieren in der Regel, sind aber nicht garantiert. -Wir empfehlen die Verwendung einer neuen leeren Datenbank, die für Logto vorgesehen ist, obwohl dies keine zwingende Voraussetzung ist. +Wir empfehlen die Verwendung einer neuen, leeren Datenbank, die ausschließlich für Logto vorgesehen ist, auch wenn dies keine harte Voraussetzung ist. **Herunterladen und starten** -In deinem Terminal: +Im Terminal: ```bash npm init @logto@latest ``` -Sobald du den Initialisierungsprozess abgeschlossen und Logto gestartet hast, wirst du eine Nachricht wie diese sehen: +Sobald du den Initialisierungsprozess abgeschlossen und Logto gestartet hast, siehst du eine Nachricht wie:
```text -Kern-App läuft unter http://localhost:3001 -Kern-App läuft unter https://your-domain-url -Admin-App läuft unter http://localhost:3002 -Admin-App läuft unter https://your-admin-domain-url +Core app is running at http://localhost:3001 +Core app is running at https://your-domain-url +Admin app is running at http://localhost:3002 +Admin app is running at https://your-admin-domain-url ``` Gehe zu `http://localhost:3002/`, um deine Logto-Reise fortzusetzen. Viel Spaß! @@ -168,7 +169,7 @@ Gehe zu `http://localhost:3002/`, um deine Logto-Reise fortzusetzen. Viel Spaß! -### Verwendung einer alternativen URL zum Herunterladen \{#using-an-alternative-url-for-downloading} +### Alternative URL zum Herunterladen verwenden \{#using-an-alternative-url-for-downloading} @@ -178,7 +179,7 @@ Wenn du eine URL für die Logto-Zip-Datei angeben möchtest, verwende die Option npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -Beachte, dass das zusätzliche `--` erforderlich ist, damit NPM die Argumente übergibt. +Beachte, dass das zusätzliche `--` erforderlich ist, damit NPM die Argumente weitergibt. @@ -190,15 +191,15 @@ Beachte, dass das zusätzliche `--` erforderlich ist, damit NPM die Argumente ü -Logto verwendet Umgebungsvariablen für die Konfiguration, zusammen mit der Unterstützung von `.env`-Dateien. Siehe [Konfiguration](/concepts/core-service/configuration) für detaillierte Nutzung und vollständige Variablenliste. +Logto verwendet Umgebungsvariablen für die Konfiguration und unterstützt zusätzlich `.env`-Dateien. Siehe [Konfiguration](/concepts/core-service/configuration) für eine detaillierte Nutzung und die vollständige Variablenliste. -_Schaue dir [Kernservice](/concepts/core-service) an, wenn du mehr erweiterte Steuerungen oder programmatischen Zugriff auf Logto möchtest._ +_Schau dir [Core Service](/concepts/core-service) an, wenn du erweiterte Steuerungen oder programmatischen Zugriff auf Logto möchtest._ ## Hosting-Anbieter \{#hosting-providers} -Diese zuverlässigen Hosting-Anbieter bieten Ein-Klick-Installationsvorlagen für Logto. Mit leicht bereitstellbaren Diensten kannst du dein CIAM-System mit Logto in Sekundenschnelle einrichten und starten. +Diese zuverlässigen Hosting-Anbieter bieten Ein-Klick-Installationsvorlagen für Logto. Mit einfach bereitzustellenden Diensten kannst du dein CIAM-System mit Logto in Sekundenschnelle einrichten und starten. , }, @@ -217,7 +218,7 @@ Diese zuverlässigen Hosting-Anbieter bieten Ein-Klick-Installationsvorlagen fü label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', description: - 'Eine selbsthostbare Heroku/Netlify-Alternative für einfache App- und Datenbankverwaltung.', + 'Eine selbst gehostete Heroku/Netlify-Alternative für einfache App- und Datenbankverwaltung.', customProps: { icon: , }, @@ -236,7 +237,7 @@ Diese zuverlässigen Hosting-Anbieter bieten Ein-Klick-Installationsvorlagen fü type: 'link', label: 'Easypanel', href: 'https://easypanel.io/docs/templates/logto', - description: 'Ein modernes Kontrollpanel zur Verwaltung von Cloud-Servern mit Docker.', + description: 'Ein modernes Control Panel zur Verwaltung von Cloud-Servern mit Docker.', customProps: { icon: , }, @@ -246,7 +247,7 @@ Diese zuverlässigen Hosting-Anbieter bieten Ein-Klick-Installationsvorlagen fü label: 'Elestio', href: 'https://elest.io/open-source/logto', description: - 'Vollständig verwaltete DevOps-Plattform zur Bereitstellung deines Codes und Open-Source-Software.', + 'Vollständig verwaltete DevOps-Plattform zum Bereitstellen deines Codes und Open-Source-Software.', customProps: { icon: , }, @@ -273,11 +274,15 @@ Diese zuverlässigen Hosting-Anbieter bieten Ein-Klick-Installationsvorlagen fü ]} /> -Bitte beachte, dass wir keinen Kundensupport für Drittanbieter-Dienste anbieten. Um auf unsere Support-Kanäle zuzugreifen, stelle bitte auf [Logto Cloud](https://cloud.logto.io) bereit. Danke! +Bitte beachte, dass wir keinen Kundensupport für Drittanbieter-Dienste anbieten. Um auf unsere Support-Kanäle zuzugreifen, verwende bitte [Logto Cloud](https://cloud.logto.io). Vielen Dank! ## Konto erstellen \{#create-an-account} -Sobald du Logto erfolgreich auf deinem Server gehostet hast, klicke auf der Willkommensseite auf "Konto erstellen". Beachte, dass die Open-Source-Version von Logto nur die Erstellung eines Kontos während des ersten Starts erlaubt und keine Unterstützung für mehrere Konten bietet. Der Kontoerstellungsprozess ist auf Kombinationen aus Benutzername und Passwort beschränkt. +Sobald du Logto erfolgreich auf deinem Server gehostet hast, klicke auf der Willkommensseite auf „Konto erstellen“. Beachte, dass die Open-Source-Version von Logto nur die Erstellung eines Kontos beim ersten Start erlaubt und keine Mehrfachkonten unterstützt. Der Kontoerstellungsprozess ist auf Benutzername und Passwort beschränkt. + +:::tip +Logto OSS (self-hosted) unterstützt keine Konfiguration mehrerer Administratoren. Für Teamarbeit und Projekte, die mehrere Admin-Benutzer erfordern, empfehlen wir [Logto Cloud](https://cloud.logto.io), das vollständige Teamverwaltungsfunktionen bietet. +::: ## Verwandte Ressourcen \{#related-resources} diff --git a/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index ca62021a739..ce19a64de63 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot ist ein Web-Framework für Java, das Entwicklern ermöglicht, sichere, schnelle und skalierbare Serveranwendungen mit der Java-Programmiersprache zu erstellen. + description: Spring Boot ist ein Web-Framework für Java, das Entwicklern ermöglicht, sichere, schnelle und skalierbare Serveranwendungen mit der Programmiersprache Java zu erstellen. logoFilename: 'spring-boot.svg' --- @@ -14,28 +14,28 @@ import SignInFlowSummary from '../../fragments/_web-sign-in-flow-summary.mdx'; import ScopesAndClaims from './_scopes-and-claims.mdx'; -# Authentifizierung zu deiner Java Spring Boot-Anwendung hinzufügen +# Authentifizierung zu deiner Java Spring Boot-Anwendung hinzufügen (Add authentication to your Java Spring Boot application) -Dieser Leitfaden zeigt dir, wie du Logto in deine Java Spring Boot-Anwendung integrieren kannst. +Diese Anleitung zeigt dir, wie du Logto in deine Java Spring Boot-Anwendung integrierst. :::tip -- Du findest den Beispielcode für diesen Leitfaden in unserem [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub-Repository. -- Es ist kein offizielles SDK erforderlich, um Logto mit deiner Java Spring Boot-Anwendung zu integrieren. Wir werden die Bibliotheken [Spring Security](https://spring.io/projects/spring-security) und [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) verwenden, um den OIDC-Authentifizierungsfluss mit Logto zu handhaben. +- Du findest den Beispielcode zu dieser Anleitung in unserem [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub-Repository. +- Es ist kein offizielles SDK erforderlich, um Logto mit deiner Java Spring Boot-Anwendung zu integrieren. Wir verwenden die [Spring Security](https://spring.io/projects/spring-security) und [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) Bibliotheken, um den OIDC-Authentifizierungsfluss mit Logto zu handhaben. ::: ## Voraussetzungen \{#prerequisites} -- Ein [Logto Cloud](https://cloud.logto.io) Konto oder ein [selbst gehostetes Logto](/introduction/set-up-logto-oss). -- Unser Beispielcode wurde mit dem Spring Boot [securing web starter](https://spring.io/guides/gs/securing-web) erstellt. Folge den Anweisungen, um eine neue Webanwendung zu starten, falls du noch keine hast. -- In diesem Leitfaden verwenden wir die Bibliotheken [Spring Security](https://spring.io/projects/spring-security) und [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2), um den OIDC-Authentifizierungsfluss mit Logto zu handhaben. Bitte gehe die offizielle Dokumentation durch, um die Konzepte zu verstehen. +- Ein [Logto Cloud](https://cloud.logto.io) Konto oder eine [selbstgehostete Logto](/introduction/set-up-logto-oss) Instanz. +- Unser Beispielcode wurde mit dem Spring Boot [securing web starter](https://spring.io/guides/gs/securing-web) erstellt. Folge der Anleitung, um eine neue Webanwendung zu starten, falls du noch keine hast. +- In dieser Anleitung verwenden wir die [Spring Security](https://spring.io/projects/spring-security) und [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) Bibliotheken, um den OIDC-Authentifizierungsfluss mit Logto zu handhaben. Bitte lies die offizielle Dokumentation, um die Konzepte zu verstehen. ## Konfiguriere deine Java Spring Boot-Anwendung \{#configure-your-java-spring-boot-application} ### Abhängigkeiten hinzufügen \{#adding-dependencies} -Für [gradle](https://spring.io/guides/gs/gradle) Benutzer, füge die folgenden Abhängigkeiten zu deiner `build.gradle` Datei hinzu: +Für [gradle](https://spring.io/guides/gs/gradle) Nutzer, füge die folgenden Abhängigkeiten zu deiner `build.gradle` Datei hinzu: ```groovy title="build.gradle" dependencies { @@ -46,7 +46,7 @@ dependencies { } ``` -Für [maven](https://spring.io/guides/gs/maven) Benutzer, füge die folgenden Abhängigkeiten zu deiner `pom.xml` Datei hinzu: +Für [maven](https://spring.io/guides/gs/maven) Nutzer, füge die folgenden Abhängigkeiten zu deiner `pom.xml` Datei hinzu: ```xml title="pom.xml" @@ -69,7 +69,7 @@ Für [maven](https://spring.io/guides/gs/maven) Benutzer, füge die folgenden Ab ### OAuth2 Client-Konfiguration \{#oauth2-client-configuration} -Registriere eine neue `Java Spring Boot` Anwendung in der Logto-Konsole und erhalte die Client-Anmeldeinformationen und IdP-Konfigurationen für deine Webanwendung. +Registriere eine neue `Java Spring Boot` Anwendung in der Logto-Konsole und erhalte die Client-Credentials und IdP-Konfigurationen für deine Webanwendung. Füge die folgende Konfiguration zu deiner `application.properties` Datei hinzu: @@ -91,15 +91,15 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc -Um Benutzer nach der Anmeldung zurück zu deiner Anwendung umzuleiten, musst du die Redirect-URI mit der Eigenschaft `client.registration.logto.redirect-uri` im vorherigen Schritt festlegen. +Um Benutzer nach der Anmeldung zurück zu deiner Anwendung zu leiten, musst du die Redirect-URI mit der Eigenschaft `client.registration.logto.redirect-uri` im vorherigen Schritt festlegen. - + ### Implementiere die WebSecurityConfig \{#implement-the-websecurityconfig} #### Erstelle eine neue Klasse `WebSecurityConfig` in deinem Projekt \{#create-a-new-class-websecurityconfig-in-your-project} -Die `WebSecurityConfig` Klasse wird verwendet, um die Sicherheitseinstellungen für deine Anwendung zu konfigurieren. Sie ist die Schlüsselklasse, die den Authentifizierungs- und Autorisierungsfluss handhaben wird. Bitte überprüfe die [Spring Security Dokumentation](https://spring.io/guides/topicals/spring-security-architecture) für weitere Details. +Die Klasse `WebSecurityConfig` wird verwendet, um die Sicherheitseinstellungen deiner Anwendung zu konfigurieren. Sie ist die Schlüsselklasse, die den Authentifizierungs- und Autorisierungsfluss steuert. Siehe die [Spring Security Dokumentation](https://spring.io/guides/topicals/spring-security-architecture) für weitere Details. ```java title="WebSecurityConfig.java" package com.example.securingweb; @@ -117,7 +117,7 @@ public class WebSecurityConfig { #### Erstelle einen `idTokenDecoderFactory` Bean \{#create-a-idtokendecoderfactory-bean} -Dies ist erforderlich, da Logto `ES384` als Standardalgorithmus verwendet. Wir müssen den Standard `OidcIdTokenDecoderFactory` überschreiben, um denselben Algorithmus zu verwenden. +Dies ist erforderlich, da Logto `ES384` als Standardalgorithmus verwendet. Wir müssen die Standard-Implementierung von `OidcIdTokenDecoderFactory` überschreiben, um denselben Algorithmus zu verwenden. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -138,9 +138,9 @@ public class WebSecurityConfig { } ``` -#### Erstelle eine LoginSuccessHandler-Klasse, um das Login-Erfolg-Ereignis zu handhaben \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} +#### Erstelle eine LoginSuccessHandler-Klasse zur Behandlung des Login-Erfolgsereignisses \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} -Wir werden den Benutzer nach einem erfolgreichen Login zur `/user` Seite umleiten. +Wir leiten den Benutzer nach erfolgreicher Anmeldung auf die Seite `/user` weiter. ```java title="CustomSuccessHandler.java" package com.example.securingweb; @@ -163,9 +163,9 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { } ``` -#### Erstelle eine LogoutSuccessHandler-Klasse, um das Logout-Erfolg-Ereignis zu handhaben \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} +#### Erstelle eine LogoutSuccessHandler-Klasse zur Behandlung des Logout-Erfolgsereignisses \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} -Lösche die Sitzung und leite den Benutzer zur Startseite um. +Lösche die Session und leite den Benutzer auf die Startseite weiter. ```java title="CustomLogoutHandler.java" package com.example.securingweb; @@ -195,11 +195,11 @@ public class CustomLogoutHandler implements LogoutSuccessHandler { } ``` -#### Aktualisiere die `WebSecurityConfig` Klasse mit einer `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} +#### Aktualisiere die `WebSecurityConfig`-Klasse mit einer `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} [securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) ist eine Kette von Filtern, die für die Verarbeitung der eingehenden Anfragen und Antworten verantwortlich sind. -Wir werden die `securityFilterChain` konfigurieren, um den Zugriff auf die Startseite zu erlauben und für alle anderen Anfragen eine Authentifizierung zu verlangen. Verwende den `CustomSuccessHandler` und `CustomLogoutHandler`, um die Login- und Logout-Ereignisse zu handhaben. +Wir konfigurieren die `securityFilterChain`, um den Zugriff auf die Startseite zu erlauben und für alle anderen Anfragen eine Authentifizierung zu verlangen. Verwende den `CustomSuccessHandler` und `CustomLogoutHandler`, um die Login- und Logout-Ereignisse zu behandeln. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -214,7 +214,7 @@ public class WebSecurityConfig { http .authorizeRequests(authorizeRequests -> authorizeRequests - .antMatchers("/", "/home").permitAll() // Erlaube den Zugriff auf die Startseite + .antMatchers("/", "/home").permitAll() // Zugriff auf die Startseite erlauben .anyRequest().authenticated() // Alle anderen Anfragen erfordern Authentifizierung ) .oauth2Login(oauth2Login -> @@ -251,19 +251,19 @@ public class HomeController { } ``` -Dieser Controller wird den Benutzer zur Benutzerseite umleiten, wenn der Benutzer authentifiziert ist, andernfalls wird die Startseite angezeigt. Füge einen Anmeldelink zur Startseite hinzu. +Dieser Controller leitet den Benutzer auf die Benutzerseite weiter, wenn er authentifiziert ist, andernfalls wird die Startseite angezeigt. Füge einen Anmeldelink zur Startseite hinzu. ```html title="resources/templates/home.html"

Willkommen!

-

Mit Logto anmelden

+

Login mit Logto

``` ### Erstelle eine Benutzerseite \{#create-a-user-page} -Erstelle einen neuen Controller, um die Benutzerseite zu handhaben: +Erstelle einen neuen Controller zur Behandlung der Benutzerseite: ```java title="UserController.java" package com.example.securingweb; @@ -299,9 +299,9 @@ public class UserController { } ``` -Sobald der Benutzer authentifiziert ist, werden wir die `OAuth2User` Daten aus dem authentifizierten Principal-Objekt abrufen. Bitte siehe [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) und [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) für weitere Details. +Sobald der Benutzer authentifiziert ist, lesen wir die `OAuth2User`-Daten aus dem authentifizierten Principal-Objekt aus. Siehe [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) und [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) für weitere Details. -Lese die Benutzerdaten und übergebe sie an das `user.html` Template. +Lese die Benutzerdaten aus und übergebe sie an das `user.html` Template. ```html title="resources/templates/user.html" @@ -315,7 +315,7 @@ Lese die Benutzerdaten und übergebe sie an das `user.html` Template.
- +
``` @@ -326,27 +326,27 @@ Lese die Benutzerdaten und übergebe sie an das `user.html` Template. -Um zusätzliche Benutzerinformationen abzurufen, kannst du zusätzliche Berechtigungen zur `application.properties` Datei hinzufügen. Zum Beispiel, um die `email`, `phone` und `urn:logto:scope:organizations` Berechtigung anzufordern, füge die folgende Zeile zur `application.properties` Datei hinzu: +Um zusätzliche Benutzerinformationen abzurufen, kannst du weitere Berechtigungen (`scopes`) zur Datei `application.properties` hinzufügen. Um zum Beispiel die Berechtigungen `email`, `phone` und `urn:logto:scope:organizations` anzufordern, füge folgende Zeile zur Datei `application.properties` hinzu: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -Dann kannst du auf die zusätzlichen Ansprüche im `OAuth2User` Objekt zugreifen. +Danach kannst du auf die zusätzlichen Ansprüche im `OAuth2User`-Objekt zugreifen. ### Anwendung ausführen und testen \{#run-and-test-the-application} -Führe die Anwendung aus und navigiere zu `http://localhost:8080`. +Starte die Anwendung und öffne `http://localhost:8080`. -- Du wirst die Startseite mit einem Anmeldelink sehen. +- Du siehst die Startseite mit einem Anmeldelink. - Klicke auf den Link, um dich mit Logto anzumelden. -- Nach erfolgreicher Authentifizierung wirst du zur Benutzerseite mit deinen Benutzerdetails weitergeleitet. -- Klicke auf den Abmeldebutton, um dich abzumelden. Du wirst zurück zur Startseite geleitet. +- Nach erfolgreicher Authentifizierung wirst du auf die Benutzerseite mit deinen Benutzerdaten weitergeleitet. +- Klicke auf den Logout-Button, um dich abzumelden. Du wirst zurück auf die Startseite geleitet. -## Berechtigungen und Ansprüche \{#scopes-and-claims} +## Berechtigungen und Ansprüche (Scopes and Claims) \{#scopes-and-claims} -## Weiterführende Lektüre \{#further-readings} +## Weiterführende Literatur \{#further-readings} diff --git a/i18n/de/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/de/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index 4da7e8ee869..c179b6652a3 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -8,139 +8,139 @@ import Availability from '@components/Availability'; -Das Drittanbieter-Token-Set (auch als föderiertes Token-Set bekannt) ist ein Geheimnistyp, der im [Secret Vault](/secret-vault) von Logto gespeichert wird, um Zugriffs- und Auffrischungstokens, die von Drittanbieter-Identitätsanbietern ausgestellt wurden, sicher zu verwalten. Wenn sich ein Benutzer über einen Social- oder Enterprise-SSO-Connector authentifiziert, speichert Logto die ausgestellten Tokens im Vault. Diese Tokens können später abgerufen werden, um im Namen des Benutzers auf Drittanbieter-APIs zuzugreifen, ohne dass eine erneute Authentifizierung erforderlich ist. +Das Drittanbieter-Token-Set (auch bekannt als föderiertes Token-Set) ist ein Geheimnistyp, der im [Secret Vault](/secret-vault) von Logto gespeichert wird, um Zugangstokens (Zugangstoken (Access token)) und Auffrischungstokens (Auffrischungstoken (Refresh token)), die von Drittanbieter-Identitätsanbietern ausgestellt wurden, sicher zu verwalten. Wenn sich ein Benutzer über einen Social- oder Enterprise SSO-Connector authentifiziert, speichert Logto die ausgestellten Tokens im Vault. Diese Tokens können später abgerufen werden, um im Namen des Benutzers auf Drittanbieter-APIs zuzugreifen, ohne dass eine erneute Authentifizierung erforderlich ist. ## Häufige Anwendungsfälle \{#common-use-cases} Diese Fähigkeit ist essenziell für moderne Anwendungen wie KI-Agenten, SaaS-Plattformen, Produktivitätstools und Kundenanwendungen, die im Namen der Benutzer mit Drittanbieterdiensten interagieren müssen. Hier einige praktische Beispiele: -**📅 Kalenderverwaltungs-Apps**: Nachdem sich ein Benutzer mit Google angemeldet hat, kann deine Produktivitäts-App automatisch dessen Kalendereinträge synchronisieren, neue Meetings erstellen und Einladungen versenden, ohne erneut nach einer Authentifizierung zu fragen. +**📅 Kalenderverwaltungs-Apps**: Nachdem sich ein Benutzer mit Google anmeldet, kann deine Produktivitäts-App automatisch seine Kalendereinträge synchronisieren, neue Meetings erstellen und Einladungen versenden, ohne erneut nach einer Authentifizierung zu fragen. -**🤖 KI-Assistenten**: Ein KI-Agent kann auf die GitHub-Repositories eines Benutzers zugreifen, um Code zu analysieren, Pull Requests zu erstellen oder Issues zu verwalten. All dies mit der einmaligen Zustimmung des Benutzers während der Anmeldung oder Kontoverknüpfung. +**🤖 KI-Assistenten**: Ein KI-Agent kann auf die GitHub-Repositories eines Benutzers zugreifen, um Code zu analysieren, Pull Requests zu erstellen oder Issues zu verwalten. Alles mit der einmaligen Zustimmung des Benutzers während der Anmeldung oder Kontoverknüpfung. -**📊 Analyse-Dashboards**: SaaS-Plattformen können Daten aus den verbundenen Social-Media-Konten der Benutzer (Facebook, LinkedIn) abrufen, um Einblicke und Berichte zu generieren, ohne den Arbeitsablauf der Benutzer durch wiederholte Login-Aufforderungen zu unterbrechen. +**📊 Analyse-Dashboards**: SaaS-Plattformen können Daten aus den verbundenen Social-Media-Konten der Benutzer (Facebook, LinkedIn) abrufen, um Einblicke und Berichte zu generieren, ohne den Arbeitsablauf durch wiederholte Login-Aufforderungen zu unterbrechen. ## Drittanbieter-Token-Speicherung aktivieren \{#enable-third-party-token-storage} ### Social Connectors \{#social-connectors} -Diese Funktion ist für [Social Connectors](/connectors/social-connectors) verfügbar, die die Token-Speicherung unterstützen. Drittanbieter-Tokens können während der [sozialen Anmeldung](/end-user-flows/sign-up-and-sign-in/social-sign-in), [sozialen Kontoverknüpfung](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) und [bei der Erneuerung von Tokens für den Drittanbieter-API-Zugriff](/secret-vault/federated-token-set#reauthentication-and-token-renewal) gespeichert werden. Derzeit unterstützte Connectors sind: [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [Standard OAuth 2.0](/integrations/oauth2) und [Standard OIDC](/integrations/oidc). Die Unterstützung für weitere Connectors wird schrittweise eingeführt. +Diese Funktion ist für [Social Connectors](/connectors/social-connectors) verfügbar, die die Token-Speicherung unterstützen. Drittanbieter-Tokens können während der [sozialen Anmeldung](/end-user-flows/sign-up-and-sign-in/social-sign-in), [sozialen Kontoverknüpfung](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) und [beim Erneuern von Tokens für Drittanbieter-API-Zugriff](/secret-vault/federated-token-set#reauthentication-and-token-renewal) gespeichert werden. Aktuell unterstützte Connectors sind: [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [Standard OAuth 2.0](/integrations/oauth2) und [Standard OIDC](/integrations/oidc). Die Unterstützung für weitere Connectors wird schrittweise eingeführt. 1. Navigiere zu Konsole > Connectors > Social Connectors. 2. Wähle den Social Connector aus, für den du die Drittanbieter-Token-Speicherung aktivieren möchtest. -3. Folge den Einrichtungsanleitungen, um den Connector zu konfigurieren, einschließlich der Hinzufügung der erforderlichen Berechtigungen (Scopes) für den Zugriff auf bestimmte Drittanbieter-APIs. +3. Folge den Einrichtungsanleitungen, um den Connector zu konfigurieren, einschließlich der Hinzufügung der erforderlichen Berechtigungen (Scopes), um auf bestimmte Drittanbieter-APIs zuzugreifen. 4. Aktiviere auf der Seite „Einstellungen“ die Option **Tokens für dauerhaften API-Zugriff speichern**. ### Enterprise SSO Connectors \{#enterprise-sso-connectors} -Die Token-Speicherung ist für alle OIDC [Enterprise Connectors](/connectors/enterprise-connectors) verfügbar. Zugriffs- und Auffrischungstokens können während des [Enterprise Single Sign-On](/end-user-flows/enterprise-sso) gespeichert werden. Derzeit unterstützte Connectors sind: [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc), [Okta](/integrations/okta) und [OIDC (Enterprise)](/integrations/oidc-sso). +Die Token-Speicherung ist für alle OIDC [Enterprise Connectors](/connectors/enterprise-connectors) verfügbar. Zugangstokens (Zugangstoken (Access token)) und Auffrischungstokens (Auffrischungstoken (Refresh token)) können während des [Enterprise Single Sign-On](/end-user-flows/enterprise-sso) gespeichert werden. Aktuell unterstützte Connectors sind: [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc), [Okta](/integrations/okta) und [OIDC (Enterprise)](/integrations/oidc-sso). 1. Navigiere zu Konsole > Enterprise SSO. 2. Wähle den Enterprise SSO Connector aus, für den du die Drittanbieter-Token-Speicherung aktivieren möchtest. -3. Folge den Einrichtungsanleitungen, um den Connector zu konfigurieren, einschließlich der Hinzufügung der erforderlichen Berechtigungen (Scopes) für den Zugriff auf bestimmte Drittanbieter-APIs. +3. Folge den Einrichtungsanleitungen, um den Connector zu konfigurieren, einschließlich der Hinzufügung der erforderlichen Berechtigungen (Scopes), um auf bestimmte Drittanbieter-APIs zuzugreifen. 4. Aktiviere im Tab „SSO-Erfahrung“ die Option **Tokens für dauerhaften API-Zugriff speichern**. -Vergiss nicht, deine Änderungen zu speichern. +Stelle sicher, dass du deine Änderungen speicherst. ## Token-Speicherung \{#token-storage} -Sobald die Drittanbieter-Token-Speicherung aktiviert ist, speichert Logto automatisch die Zugriffs- und Auffrischungstokens, die vom föderierten Identitätsanbieter ausgestellt werden, wann immer sich ein Benutzer über einen Social- oder Enterprise-SSO-Connector authentifiziert. Dies umfasst: +Sobald die Drittanbieter-Token-Speicherung aktiviert ist, speichert Logto automatisch die Zugangstokens (Zugangstoken (Access token)) und Auffrischungstokens (Auffrischungstoken (Refresh token)), die vom föderierten Identitätsanbieter ausgestellt wurden, wann immer sich ein Benutzer über einen Social- oder Enterprise SSO-Connector authentifiziert. Dies umfasst: - [Soziale Anmeldung und Registrierung](/end-user-flows/sign-up-and-sign-in/social-sign-in) - [Enterprise SSO Anmeldung und Registrierung](/end-user-flows/enterprise-sso) - [Soziale Kontoverknüpfung über Account API](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -Die gespeicherten Tokens sind mit der Social- oder Enterprise-SSO-Identität des Benutzers verknüpft, sodass sie später für den API-Zugriff abgerufen werden können, ohne dass eine erneute Authentifizierung erforderlich ist. +Die gespeicherten Tokens sind mit der Social- oder Enterprise SSO-Identität des Benutzers verknüpft, sodass sie später für den API-Zugriff abgerufen werden können, ohne dass eine erneute Authentifizierung erforderlich ist. ### Überprüfung des Token-Speicherstatus \{#checking-token-storage-status} Du kannst den Drittanbieter-Token-Speicherstatus eines Benutzers in der Logto-Konsole überprüfen: 1. Navigiere zu Konsole > Benutzer. -2. Klicke auf den Benutzer, den du überprüfen möchtest. Dadurch gelangst du zur Detailseite des Benutzers. -3. Scrolle zum Abschnitt **Verbindungen**. Dieser Bereich listet alle Social- und Enterprise-SSO-Verbindungen auf, die mit dem Benutzer verknüpft sind. +2. Klicke auf den Benutzer, den du überprüfen möchtest. Dies führt dich zur Detailseite des Benutzers. +3. Scrolle zum Abschnitt **Verbindungen**. Dieser Bereich listet alle Social- und Enterprise SSO-Verbindungen auf, die mit dem Benutzer verknüpft sind. 4. Jeder Eintrag zeigt ein Token-Status-Label, das angibt, ob Tokens für diese Verbindung gespeichert sind. -5. Klicke auf den Verbindungseintrag, um weitere Details anzuzeigen, einschließlich der gespeicherten Zugriffs-Token-Metadaten und der Verfügbarkeit eines Auffrischungstokens (falls vorhanden). +5. Klicke auf den Verbindungseintrag, um weitere Details anzuzeigen, einschließlich der gespeicherten Zugangstoken-Metadaten und der Verfügbarkeit eines Auffrischungstokens (falls vorhanden). -Du kannst auch die Drittanbieter-Identitäten und den Token-Speicherstatus eines Benutzers über die Management API prüfen: +Du kannst auch die Drittanbieter-Identitäten und den Token-Speicherstatus eines Benutzers über die Management API überprüfen: -- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`: Ruft die Social-Identität eines Benutzers und den zugehörigen Token-Speicherstatus für einen bestimmten Connector-Target (z. B. `github`, `google` usw.) ab. -- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`: Ruft die Enterprise-SSO-Identität eines Benutzers und den zugehörigen Token-Speicherstatus für eine bestimmte SSO-Connector-ID ab. +- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`: Ruft die Social-Identität eines Benutzers und den damit verbundenen Token-Speicherstatus für einen bestimmten Connector-Target (z. B. `github`, `google` usw.) ab. +- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`: Ruft die Enterprise SSO-Identität eines Benutzers und den damit verbundenen Token-Speicherstatus für eine bestimmte SSO-Connector-ID ab. ### Token-Speicherstatus \{#token-storage-status} -- **Aktiv**: Das Zugangstoken ist gespeichert und aktiv. -- **Abgelaufen**: Das Zugangstoken ist gespeichert, aber abgelaufen. Wenn ein Auffrischungstoken verfügbar ist, kann damit ein neues Zugangstoken abgerufen werden. -- **Inaktiv**: Für diese Verbindung ist kein Zugangstoken gespeichert. Dies kann passieren, wenn der Benutzer sich nicht über diese Verbindung authentifiziert hat oder die Token-Speicherung gelöscht wurde. +- **Aktiv**: Das Zugangstoken (Zugangstoken (Access token)) ist gespeichert und aktiv. +- **Abgelaufen**: Das Zugangstoken (Zugangstoken (Access token)) ist gespeichert, aber abgelaufen. Wenn ein Auffrischungstoken (Auffrischungstoken (Refresh token)) verfügbar ist, kann damit ein neues Zugangstoken (Zugangstoken (Access token)) abgerufen werden. +- **Inaktiv**: Für diese Verbindung ist kein Zugangstoken (Zugangstoken (Access token)) gespeichert. Dies kann passieren, wenn der Benutzer sich nicht über diese Verbindung authentifiziert hat oder die Token-Speicherung gelöscht wurde. - **Nicht anwendbar**: Der Connector unterstützt keine Token-Speicherung. ### Token-Metadaten \{#token-metadata} -Zur Wahrung der Datenintegrität und Sicherheit werden alle Tokens vor der Speicherung im Secret Vault verschlüsselt. Die tatsächlichen Token-Werte sind nur für den Endbenutzer mit entsprechender Autorisierung zugänglich. Entwickler können hingegen nur die Metadaten des Token-Sets abrufen, um den Status der gespeicherten Tokens zu verstehen, ohne sensible Inhalte offenzulegen. +Aus Gründen der Datenintegrität und Sicherheit werden alle Tokens vor der Speicherung im Secret Vault verschlüsselt. Die tatsächlichen Token-Werte sind nur für den Endbenutzer mit entsprechender Autorisierung zugänglich. Entwickler können hingegen nur die Metadaten des Token-Sets abrufen, um den Status der gespeicherten Tokens zu verstehen, ohne sensible Inhalte offenzulegen. - `createdAt`: Der Zeitstempel, zu dem die Verbindung erstmals hergestellt und das Token-Set initial im Secret Vault gespeichert wurde. - `updatedAt`: Der Zeitpunkt der letzten Aktualisierung des Token-Sets. - - Wenn kein Auffrischungstoken verfügbar ist, entspricht dieser Wert **createdAt**. - - Wenn ein Auffrischungstoken vorhanden ist, spiegelt dieser Wert die letzte Aktualisierung des Zugangstokens wider. -- `hasRefreshToken`: Gibt an, ob ein Auffrischungstoken verfügbar ist. - Wenn der Connector Offline-Zugriff unterstützt und die Autorisierungsanfrage entsprechend konfiguriert ist, speichert Logto das Auffrischungstoken, wenn es vom Identitätsanbieter zusammen mit dem Zugangstoken ausgestellt wird. - Wenn das Zugangstoken abläuft und ein gültiges Auffrischungstoken existiert, versucht Logto automatisch, ein neues Zugangstoken mit dem gespeicherten Auffrischungstoken zu erhalten, sobald der Benutzer Zugriff auf den verbundenen Anbieter anfordert. -- `expiresAt`: Die geschätzte Ablaufzeit des Zugangstokens in **Sekunden**. + - Wenn kein Auffrischungstoken (Auffrischungstoken (Refresh token)) verfügbar ist, entspricht dieser Wert **createdAt**. + - Wenn ein Auffrischungstoken (Auffrischungstoken (Refresh token)) vorhanden ist, spiegelt dieser Wert den letzten Zeitpunkt wider, zu dem das Zugangstoken (Zugangstoken (Access token)) erneuert wurde. +- `hasRefreshToken`: Gibt an, ob ein Auffrischungstoken (Auffrischungstoken (Refresh token)) verfügbar ist. + Wenn der Connector Offline-Zugriff unterstützt und die Autorisierungsanfrage entsprechend konfiguriert ist, speichert Logto das Auffrischungstoken (Auffrischungstoken (Refresh token)), wenn es vom Identitätsanbieter zusammen mit dem Zugangstoken (Zugangstoken (Access token)) ausgestellt wird. + Wenn das Zugangstoken (Zugangstoken (Access token)) abläuft und ein gültiges Auffrischungstoken (Auffrischungstoken (Refresh token)) existiert, versucht Logto automatisch, ein neues Zugangstoken (Zugangstoken (Access token)) mit dem gespeicherten Auffrischungstoken (Auffrischungstoken (Refresh token)) zu erhalten, wann immer der Benutzer Zugriff auf den verbundenen Anbieter anfordert. +- `expiresAt`: Die geschätzte Ablaufzeit des Zugangstokens (Zugangstoken (Access token)) in **Sekunden**. Dies wird basierend auf dem `expires_in`-Wert berechnet, der vom Token-Endpunkt des Identitätsanbieters zurückgegeben wird. (Dieses Feld ist nur verfügbar, wenn der Anbieter `expires_in` in der Token-Antwort enthält.) -- `scope`: Die Berechtigung des Zugangstokens, die die vom Identitätsanbieter gewährten Berechtigungen angibt. - Dies ist nützlich, um zu verstehen, welche Aktionen mit dem gespeicherten Zugangstoken durchgeführt werden können. (Dieses Feld ist nur verfügbar, wenn der Anbieter `scope` in der Token-Antwort enthält.) -- `tokenType`: Der Typ des Zugangstokens, typischerweise "Bearer". +- `scope`: Die Berechtigung (Scope) des Zugangstokens (Zugangstoken (Access token)), die die vom Identitätsanbieter gewährten Berechtigungen angibt. + Dies ist nützlich, um zu verstehen, welche Aktionen mit dem gespeicherten Zugangstoken (Zugangstoken (Access token)) durchgeführt werden können. (Dieses Feld ist nur verfügbar, wenn der Anbieter `scope` in der Token-Antwort enthält.) +- `tokenType`: Der Typ des Zugangstokens (Zugangstoken (Access token)), typischerweise "Bearer". (Dieses Feld ist nur verfügbar, wenn der Anbieter `token_type` in der Token-Antwort enthält.) ## Token-Abruf \{#token-retrieval} -Sobald die Token-Speicherung aktiviert und Tokens sicher im Secret Vault von Logto gespeichert sind, können Endbenutzer ihre Drittanbieter-Zugangstokens aus deiner Client-Anwendung abrufen, indem sie die [User Account API](/end-user-flows/account-settings/by-account-api) von Logto integrieren. +Sobald die Token-Speicherung aktiviert und Tokens sicher im Secret Vault von Logto gespeichert sind, können Endbenutzer ihre Drittanbieter-Zugangstokens (Zugangstoken (Access token)) aus deiner Client-Anwendung abrufen, indem sie die [User Account API](/end-user-flows/account-settings/by-account-api) von Logto integrieren. -- `GET /my-account/identities/:target/access-token`: Ruft das Zugangstoken für eine Social-Identität ab, indem der Connector-Target angegeben wird (z. B. github, google). +- `GET /my-account/identities/:target/access-token`: Ruft das Zugangstoken (Zugangstoken (Access token)) für eine Social-Identität ab, indem der Connector-Target angegeben wird (z. B. github, google). -- `GET /my-account/sso-identities/:connectorId/access-token`: Ruft das Zugangstoken für eine Enterprise-SSO-Identität ab, indem die Connector-ID angegeben wird. +- `GET /my-account/sso-identities/:connectorId/access-token`: Ruft das Zugangstoken (Zugangstoken (Access token)) für eine Enterprise SSO-Identität ab, indem die Connector-ID angegeben wird. :::info -Erfahre, wie du die [Account API aktivierst](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) und [auf die Account API mit dem von Logto ausgestellten Zugangstoken zugreifst](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token). +Um Drittanbieter-Zugangstokens (Zugangstoken (Access token)) abzurufen, musst du zuerst die Account API für Endbenutzer unter Konsole > Anmeldung & Konto > Account Center aktivieren. Erfahre, wie du die [Account API aktivierst](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) und [sie mit einem von Logto ausgestellten Zugangstoken (Zugangstoken (Access token)) aufrufst](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token). ::: ### Token-Rotation \{#token-rotation} -Die Token-Abruf-Endpunkte liefern: +Die Endpunkte zum Token-Abruf liefern: -- `200` OK: Wenn das Zugangstoken erfolgreich abgerufen wurde und noch gültig ist. -- `404` Nicht gefunden: Wenn der Benutzer keine Social- oder Enterprise-SSO-Identität mit dem angegebenen Target oder der Connector-ID hat oder wenn das Zugangstoken nicht gespeichert ist. -- `401` Nicht autorisiert: Wenn das Zugangstoken abgelaufen ist. +- `200` OK: Wenn das Zugangstoken (Zugangstoken (Access token)) erfolgreich abgerufen wurde und noch gültig ist. +- `404` Nicht gefunden: Wenn der Benutzer keine Social- oder Enterprise SSO-Identität mit dem angegebenen Target oder der Connector-ID hat oder wenn das Zugangstoken (Zugangstoken (Access token)) nicht gespeichert ist. +- `401` Nicht autorisiert: Wenn das Zugangstoken (Zugangstoken (Access token)) abgelaufen ist. -Wenn das Zugangstoken abgelaufen ist und ein Auffrischungstoken verfügbar ist, versucht Logto automatisch, das Zugangstoken zu erneuern und gibt das neue Zugangstoken in der Antwort zurück. Die Token-Speicherung im Secret Vault wird ebenfalls mit dem neuen Zugangstoken und dessen Metadaten aktualisiert. +Wenn das Zugangstoken (Zugangstoken (Access token)) abgelaufen ist und ein Auffrischungstoken (Auffrischungstoken (Refresh token)) verfügbar ist, versucht Logto automatisch, das Zugangstoken (Zugangstoken (Access token)) zu erneuern und gibt das neue Zugangstoken (Zugangstoken (Access token)) in der Antwort zurück. Die Token-Speicherung im Secret Vault wird ebenfalls mit dem neuen Zugangstoken (Zugangstoken (Access token)) und den zugehörigen Metadaten aktualisiert. ## Token-Speicherung löschen \{#token-storage-deletion} -Die Drittanbieter-Token-Speicherung ist direkt mit den Social- oder Enterprise-SSO-Verbindungen jedes Benutzers verknüpft. Das bedeutet, dass das gespeicherte Token-Set in folgenden Fällen automatisch gelöscht wird: +Die Drittanbieter-Token-Speicherung ist direkt mit den Social- oder Enterprise SSO-Verbindungen jedes Benutzers verknüpft. Das bedeutet, dass das gespeicherte Token-Set in folgenden Fällen automatisch gelöscht wird: -- Die zugehörige Social- oder Enterprise-SSO-Identität wird aus dem Benutzerkonto entfernt. +- Die zugehörige Social- oder Enterprise SSO-Identität wird aus dem Benutzerkonto entfernt. - Das Benutzerkonto wird aus deinem Mandanten gelöscht. -- Der Social- oder Enterprise-SSO-Connector wird aus deinem Mandanten gelöscht. +- Der Social- oder Enterprise SSO-Connector wird aus deinem Mandanten gelöscht. ### Tokens widerrufen \{#revoking-tokens} Du kannst das Drittanbieter-Token-Set eines Benutzers auch manuell löschen, um den Zugriff zu widerrufen: - Über die Konsole: - Navigiere zur Identitätsdetailseite des Benutzers. Scrolle zum Abschnitt **Zugangstoken** (falls Token-Speicherung verfügbar ist) und klicke am Ende des Abschnitts auf die Schaltfläche **Tokens löschen**. + Navigiere zur Identitätsdetailseite des Benutzers. Scrolle zum Abschnitt **Zugangstoken (Zugangstoken (Access token))** (falls Token-Speicherung verfügbar ist) und klicke am Ende des Abschnitts auf die Schaltfläche **Tokens löschen**. - Über die Management API: - `DELETE /api/secret/:id`: Löscht ein bestimmtes Geheimnis anhand seiner ID, die du aus den Identitätsdetails des Benutzers erhältst. -Das Widerrufen des Token-Sets zwingt den Benutzer, sich erneut beim Drittanbieter zu authentifizieren, um ein neues Zugangstoken zu erhalten, bevor er wieder auf Drittanbieter-APIs zugreifen kann. +Das Widerrufen des Token-Sets zwingt den Benutzer, sich erneut beim Drittanbieter zu authentifizieren, um ein neues Zugangstoken (Zugangstoken (Access token)) zu erhalten, bevor er wieder auf Drittanbieter-APIs zugreifen kann. ## Reauthentifizierung und Token-Erneuerung \{#reauthentication-and-token-renewal} -In Szenarien, in denen ein gespeichertes Zugangstoken abgelaufen ist oder eine Anwendung zusätzliche API-Berechtigungen anfordern muss, können Endbenutzer sich beim Drittanbieter erneut authentifizieren, um ein frisches Zugangstoken zu erhalten – ohne sich erneut bei Logto anmelden zu müssen. +In Szenarien, in denen ein gespeichertes Zugangstoken (Zugangstoken (Access token)) abgelaufen ist oder eine Anwendung zusätzliche API-Berechtigungen (Scopes) anfordern muss, können Endbenutzer sich beim Drittanbieter erneut authentifizieren, um ein neues Zugangstoken (Zugangstoken (Access token)) zu erhalten – ohne sich erneut bei Logto anmelden zu müssen. Dies kann über die [Social Verification API](https://openapi.logto.io/operation/operation-createverificationbysocial) von Logto erfolgen, die es Benutzern ermöglicht, einen föderierten Social-Autorisierungsfluss erneut zu starten und ihr gespeichertes Token-Set zu aktualisieren. :::note Das erneute Initiieren der föderierten Autorisierung ist derzeit auf Social Connectors beschränkt. -Für Enterprise-SSO-Connectors erfordern Reauthentifizierung und Token-Erneuerung, dass der Benutzer erneut einen vollständigen Logto-Authentifizierungsfluss startet, da eine direkte Reautorisierung mit dem Enterprise-SSO-Anbieter nach der Anmeldung derzeit nicht unterstützt wird. +Für Enterprise SSO Connectors erfordern Reauthentifizierung und Token-Erneuerung, dass der Benutzer erneut einen vollständigen Logto-Authentifizierungsfluss durchläuft, da eine direkte Reautorisierung mit dem Enterprise SSO-Anbieter nach der Anmeldung derzeit nicht unterstützt wird. ::: ```mermaid @@ -160,7 +160,7 @@ sequenceDiagram User->>Logto: patch /my-account/identities/:target/access-token ``` -1. Der Benutzer initiiert eine Social Verification-Anfrage, indem er den Endpunkt `POST /api/verification/social` aufruft. Der Benutzer kann benutzerdefinierte Berechtigungen (Scopes) angeben, um zusätzliche Berechtigungen vom Drittanbieter anzufordern. +1. Der Benutzer startet eine Social Verification-Anfrage, indem er den Endpunkt `POST /api/verification/social` aufruft. Der Benutzer kann benutzerdefinierte Berechtigungen (Scopes) angeben, um zusätzliche Berechtigungen vom Drittanbieter anzufordern. ```sh curl -X POST https:///api/verification/social \ @@ -174,12 +174,12 @@ sequenceDiagram }' ``` - - **authorization header**: Das vom Logto ausgestellte Zugangstoken des Benutzers. + - **authorization header**: Das vom Logto ausgestellte Zugangstoken (Zugangstoken (Access token)) des Benutzers. - **connectorId**: Die Social Connector ID in Logto. - - **redirectUri**: Die URI, zu der der Benutzer nach der Authentifizierung in deine Anwendung zurückgeleitet wird. Diese URI muss in den Anwendungseinstellungen des Anbieters registriert werden. - - **scope**: (Optional) Benutzerdefinierte Berechtigungen, um zusätzliche Rechte vom Drittanbieter anzufordern. Wenn nicht angegeben, werden die in der Connector-Konfiguration hinterlegten Standard-Berechtigungen verwendet. + - **redirectUri**: Die URI, zu der der Benutzer nach der Authentifizierung zurück zu deiner Anwendung geleitet wird. Diese URI muss in den Anwendungseinstellungen des Anbieters registriert werden. + - **scope**: (Optional) Benutzerdefinierte Berechtigungen (Scopes), um zusätzliche Berechtigungen vom Drittanbieter anzufordern. Wenn nicht angegeben, werden die in der Connector-Konfiguration hinterlegten Standard-Berechtigungen verwendet. -2. Logto erstellt einen neuen Social Verification-Datensatz und gibt die Social Verification ID sowie die Autorisierungs-URL zurück, um den Benutzer zum Drittanbieter zur Authentifizierung weiterzuleiten. +2. Logto erstellt einen neuen Social Verification-Datensatz und gibt die Social Verification ID zusammen mit der Autorisierungs-URL zurück, um den Benutzer zum Drittanbieter zur Authentifizierung weiterzuleiten. Die Antwort sieht wie folgt aus: @@ -210,15 +210,15 @@ sequenceDiagram }' ``` - - **authorization header**: Das vom Logto ausgestellte Zugangstoken des Benutzers. + - **authorization header**: Das vom Logto ausgestellte Zugangstoken (Zugangstoken (Access token)) des Benutzers. - **verificationRecordId**: Die im vorherigen Schritt zurückgegebene Social Verification ID. - - **connectorData**: Der Autorisierungscode und weitere Daten, die vom Drittanbieter beim Callback zurückgegeben wurden. + - **connectorData**: Der Autorisierungscode und alle weiteren Daten, die vom Drittanbieter während des Callbacks zurückgegeben wurden. :::note Vergiss nicht, den `state`-Parameter zu validieren, um CSRF-Angriffe zu verhindern. ::: -6. Logto überprüft den Autorisierungscode und tauscht ihn gegen ein neues Zugangstoken und Auffrischungstoken vom Drittanbieter aus und gibt dann die Social Verification ID in der Antwort zurück. +6. Logto überprüft den Autorisierungscode und tauscht ihn gegen ein neues Zugangstoken (Zugangstoken (Access token)) und Auffrischungstoken (Auffrischungstoken (Refresh token)) vom Drittanbieter aus und gibt dann die Social Verification ID in der Antwort zurück. 7. Aktualisiere abschließend die Token-Speicherung des Benutzers, indem du den Endpunkt `PATCH /my-account/identities/:target/access-token` mit der Social Verification ID aufrufst: @@ -231,9 +231,9 @@ sequenceDiagram }' ``` - - **authorization header**: Das vom Logto ausgestellte Zugangstoken des Benutzers. + - **authorization header**: Das vom Logto ausgestellte Zugangstoken (Zugangstoken (Access token)) des Benutzers. - **socialVerificationId**: Die im vorherigen Schritt zurückgegebene verifizierte Social Verification Record ID. - Dadurch wird das Token-Set des Benutzers im Secret Vault von Logto mit dem neuen Zugangstoken und Auffrischungstoken aktualisiert, sodass der Benutzer auf Drittanbieter-APIs zugreifen kann, ohne sich erneut bei Logto anmelden zu müssen. + Dadurch wird das Token-Set des Benutzers im Secret Vault von Logto mit dem neuen Zugangstoken (Zugangstoken (Access token)) und Auffrischungstoken (Auffrischungstoken (Refresh token)) aktualisiert, sodass der Benutzer auf Drittanbieter-APIs zugreifen kann, ohne sich erneut bei Logto anmelden zu müssen. - Das aktualisierte Zugangstoken wird zurückgegeben. + Das aktualisierte Zugangstoken (Zugangstoken (Access token)) wird zurückgegeben. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/de/docusaurus-plugin-content-docs/current/security/blocklist.md index f084786f8fc..8e0611afcaa 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -8,30 +8,30 @@ sidebar_position: 3 ## E-Mail-Blocklist {#email-blocklist} -Die E-Mail-Blocklist-Richtlinie ermöglicht die Anpassung der E-Mail-Blocklist-Einstellungen, um Missbrauch bei der Kontoerstellung zu verhindern. Sie überwacht E-Mail-Adressen, die für die Registrierung und Kontoeinstellungen verwendet werden. Wenn ein Benutzer versucht, sich zu registrieren oder eine E-Mail-Adresse zu verknüpfen, die gegen eine Blocklist-Regel verstößt, wird die Anfrage vom System abgelehnt. Dies hilft, Spam-Konten zu reduzieren und die allgemeine Kontosicherheit zu erhöhen. +Die E-Mail-Blocklist-Richtlinie ermöglicht die Anpassung der Einstellungen zur E-Mail-Blocklist, um Missbrauch bei der Kontoerstellung zu verhindern. Sie überwacht E-Mail-Adressen, die für die Registrierung und Kontoeinstellungen verwendet werden. Wenn ein Benutzer versucht, sich zu registrieren oder eine E-Mail-Adresse zu verknüpfen, die gegen eine Blocklist-Regel verstößt, wird die Anfrage vom System abgelehnt. Dies hilft, Spam-Konten zu reduzieren und die allgemeine Kontosicherheit zu erhöhen. -Besuche Konsole > Sicherheit > Blocklist, um die Einstellungen der E-Mail-Blocklist zu konfigurieren. +Besuche die Konsole > Sicherheit > Blocklist, um die Einstellungen der E-Mail-Blocklist zu konfigurieren. ### Wegwerf-E-Mail-Adressen blockieren {#block-disposable-email-addresses} -Dies ist eine **nur-Cloud**-Funktion. Sobald sie aktiviert ist, überprüft das System automatisch die Domain der angegebenen E-Mail-Adresse anhand einer Liste bekannter Wegwerf-E-Mail-Domains. Wenn die Domain in der Liste gefunden wird, wird die Anfrage abgelehnt. Die Liste der Wegwerf-E-Mail-Domains wird regelmäßig aktualisiert, um ihre Wirksamkeit sicherzustellen. +Dies ist eine **Cloud-exklusive** Funktion. Sobald sie aktiviert ist, überprüft das System automatisch die Domain der angegebenen E-Mail-Adresse anhand einer Liste bekannter Wegwerf-E-Mail-Domains. Wird die Domain in der Liste gefunden, wird die Anfrage abgelehnt. Die Liste der Wegwerf-E-Mail-Domains wird regelmäßig aktualisiert, um ihre Wirksamkeit sicherzustellen. ### E-Mail-Subaddressing blockieren {#block-email-subaddressing} -E-Mail-Subaddressing ermöglicht es Benutzern, Varianten ihrer E-Mail-Adressen zu erstellen, indem sie ein Pluszeichen (+) gefolgt von zusätzlichen Zeichen hinzufügen (z. B. user+tag@example.com). Diese Funktion kann von böswilligen Benutzern ausgenutzt werden, um Blocklist-Beschränkungen zu umgehen. Durch das Aktivieren der Funktion zum Blockieren von E-Mail-Subaddressing lehnt das System alle Registrierungs- oder Kontoverknüpfungsversuche ab, die Subaddressing-Formate verwenden. +E-Mail-Subaddressing ermöglicht es Benutzern, Varianten ihrer E-Mail-Adressen zu erstellen, indem sie ein Pluszeichen (+) und zusätzliche Zeichen hinzufügen (z. B. user+tag@example.com). Diese Funktion kann von böswilligen Nutzern ausgenutzt werden, um Blocklist-Beschränkungen zu umgehen. Durch das Aktivieren der Funktion zum Blockieren von E-Mail-Subaddressing lehnt das System alle Registrierungs- oder Konto-Verknüpfungsversuche ab, die Subaddressing-Formate verwenden. ### Benutzerdefinierte E-Mail-Blocklist {#custom-email-blocklist} -Du kannst eine benutzerdefinierte E-Mail-Blocklist erstellen, indem du eine Liste von E-Mail-Adressen oder Domains angibst, die blockiert werden sollen. Das System lehnt alle Registrierungs- oder Kontoverknüpfungsversuche ab, die mit diesen Einträgen übereinstimmen. Die Blocklist unterstützt sowohl vollständige E-Mail-Adressen als auch Domain-Übereinstimmungen. +Du kannst eine benutzerdefinierte E-Mail-Blocklist erstellen, indem du eine Liste von E-Mail-Adressen oder Domains angibst, die blockiert werden sollen. Das System lehnt alle Registrierungs- oder Konto-Verknüpfungsversuche ab, die mit diesen Einträgen übereinstimmen. Die Blocklist unterstützt sowohl vollständige E-Mail-Adressen als auch Domain-Übereinstimmungen. Wenn du beispielsweise `@example.com` zur Blocklist hinzufügst, werden alle E-Mail-Adressen mit dieser Domain blockiert. Ebenso wird durch das Hinzufügen von `foo@example.com` genau diese E-Mail-Adresse blockiert. :::note -Wegwerf-E-Mails, Subaddressing und benutzerdefinierte E-Mails sind während der Registrierung und Kontoverknüpfung eingeschränkt. Bestehende Benutzer mit diesen E-Mail-Adressen können sich weiterhin anmelden. +Wegwerf-E-Mails, Subaddressing und benutzerdefinierte E-Mails sind während der [Neuregistrierung von Benutzern](/end-user-flows/sign-up-and-sign-in/sign-up), beim [Verknüpfen von E-Mails während der sozialen Anmeldung](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers) und beim Aktualisieren von E-Mails über die [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email) eingeschränkt. Bestehende Benutzer mit diesen E-Mail-Adressen können sich weiterhin anmelden. -- Admins können "Beschränkungen umgehen", indem sie Benutzer manuell in Konsole > Benutzerverwaltung hinzufügen oder über die [Management API](https://openapi.logto.io/operation/operation-createuser). Zum Beispiel: Erstelle einen Benutzer mit einer Subaddress-E-Mail, wenn Subaddressing blockiert ist. -- Bestehende Konten blockieren, indem du sie in Konsole > Benutzerverwaltung löschst oder sperrst. +- Admins können „Beschränkungen umgehen“, indem sie Benutzer manuell in der Konsole > Benutzerverwaltung hinzufügen oder über die [Management API](https://openapi.logto.io/operation/operation-createuser). Zum Beispiel: Erstelle einen Benutzer mit einer Subaddress-E-Mail, wenn Subaddressing blockiert ist. +- Bestehende Konten können durch Löschen oder Sperren in der Konsole > Benutzerverwaltung blockiert werden. ::: diff --git a/i18n/de/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/de/docusaurus-plugin-content-docs/current/security/password-policy.mdx index 5b5abfe1d7f..6860df18b50 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,12 +6,18 @@ sidebar_position: 1 # Passwort-Richtlinie +Logto wendet die Passwort-Richtlinie auf unterschiedliche Weise an, je nachdem, wie das Passwort erstellt oder aktualisiert wird: + +- Endbenutzer-Flows wie [die sofort einsatzbereite Anmeldeerfahrung](/end-user-flows/sign-up-and-sign-in/sign-up), [die Experience API](/customization/bring-your-ui) und [die Account API](/end-user-flows/account-settings/by-account-api#update-users-password) erzwingen immer die aktuelle [Passwort-Richtlinie](#set-up-password-policy). +- Administratoraktionen über die Management API [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) sind ausgenommen, sodass du Anmeldedaten bereitstellen oder zurücksetzen kannst, ohne die Richtlinie zu überprüfen, wenn dies erforderlich ist. +- Um bestehende Passwörter anhand der aktuellen Regeln zu prüfen, rufe [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) auf und handle entsprechend dem zurückgegebenen Validierungsergebnis. Lies [Passwort-Konformitätsprüfung](#password-compliance-check), um mehr zu erfahren. + ## Passwort-Richtlinie einrichten \{#set-up-password-policy} -Für neue Benutzer oder Benutzer, die ihr Passwort aktualisieren, kannst du eine Passwort-Richtlinie festlegen, um Anforderungen an die Passwortstärke durchzusetzen. Besuche die Konsole > Sicherheit > Passwort-Richtlinie, um die Einstellungen zur Passwort-Richtlinie zu konfigurieren. +Für neue Benutzer oder Benutzer, die ihr Passwort aktualisieren, kannst du eine Passwort-Richtlinie festlegen, um Anforderungen an die Passwortstärke durchzusetzen. Besuche Konsole > Sicherheit > Passwort-Richtlinie, um die Einstellungen für die Passwort-Richtlinie zu konfigurieren. -1. **Minimale Passwortlänge**: Lege die minimale Anzahl an Zeichen fest, die das Passwort enthalten muss. (NIST empfiehlt mindestens 8 [Zeichen](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) -2. **Minimale erforderliche Zeichentypen**: Lege die minimale Anzahl an Zeichentypen fest, die das Passwort enthalten muss. Die verfügbaren Zeichentypen sind: +1. **Minimale Passwortlänge**: Lege die Mindestanzahl an Zeichen für das Passwort fest. (NIST empfiehlt mindestens 8 [Zeichen](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) +2. **Minimale erforderliche Zeichentypen**: Lege die Mindestanzahl an Zeichentypen fest, die das Passwort enthalten muss. Die verfügbaren Zeichentypen sind: 1. Großbuchstaben: `(A-Z)` 2. Kleinbuchstaben: `(a-z)` 3. Zahlen: `(0-9)` @@ -19,16 +25,19 @@ Für neue Benutzer oder Benutzer, die ihr Passwort aktualisieren, kannst du eine 3. **Überprüfung auf Datenpannen**: Aktiviere diese Einstellung, um Passwörter abzulehnen, die bereits in Datenpannen offengelegt wurden. (Bereitgestellt von [Have I Been Pwned](https://haveibeenpwned.com/Passwords)) 4. **Wiederholungsprüfung**: Aktiviere diese Einstellung, um Passwörter abzulehnen, die wiederholende Zeichen enthalten. (z. B. "11111111" oder "password123") 5. **Benutzerinformationsprüfung**: Aktiviere diese Einstellung, um Passwörter abzulehnen, die Benutzerinformationen wie Benutzernamen, E-Mail-Adresse oder Telefonnummer enthalten. -6. **Benutzerdefinierte Wörter**: Gib eine Liste benutzerdefinierter Wörter (Groß- / Kleinschreibung wird ignoriert) an, die du im Passwort ablehnen möchtest. +6. **Benutzerdefinierte Wörter**: Gib eine Liste benutzerdefinierter Wörter (Groß-/Kleinschreibung wird ignoriert) an, die du im Passwort ablehnen möchtest. ## Passwort-Konformitätsprüfung \{#password-compliance-check} Nachdem du die Passwort-Richtlinie in Logto aktualisiert hast, können sich bestehende Benutzer weiterhin mit ihren aktuellen Passwörtern anmelden. Nur neu erstellte Konten müssen die aktualisierte Richtlinie befolgen. -Um eine stärkere Sicherheit durchzusetzen, kannst du die `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) verwenden, um zu überprüfen, ob das Passwort eines Benutzers der aktuellen Richtlinie in der Standard-Anmeldeerfahrung entspricht. Falls nicht, kannst du den Benutzer mit einem eigenen Ablauf über die [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) auffordern, sein Passwort zu aktualisieren. +Um eine stärkere Sicherheit durchzusetzen, kannst du die `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) verwenden, um zu prüfen, ob das Passwort eines Benutzers der aktuellen Richtlinie in der Standard-Anmeldeerfahrung entspricht. Falls nicht, kannst du den Benutzer mit einem benutzerdefinierten Ablauf über die [Account API](/end-user-flows/account-settings/by-account-api) auffordern, sein Passwort zu aktualisieren. ## Verwandte Ressourcen \{#related-resources} +Benutzer verwalten +Registrierung und Anmeldung +Kontoeinstellungen per Account API Gestalte deine Passwort-Richtlinie diff --git a/i18n/de/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/de/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index 950bd43cb32..ac420fd30bd 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -8,22 +8,21 @@ sidebar_position: 2 ### Benutzer durchsuchen und suchen \{#browse-and-search-users} -Um auf die Benutzerverwaltungsfunktion in der Logto Console zuzugreifen, navigiere zu Konsole > Benutzerverwaltung. -Dort siehst du eine Tabellenansicht aller Benutzer. +Um auf die Benutzerverwaltungsfunktion in der Logto Console zuzugreifen, navigiere zu Konsole > Benutzerverwaltung. Dort siehst du eine Tabellenansicht aller Benutzer. Die Tabelle besteht aus drei Spalten: -- **Benutzer**: Zeigt Informationen über den Benutzer an, wie z. B. Avatar, vollständiger Name, Benutzername, Telefonnummer und E-Mail-Adresse. +- **Benutzer**: Zeigt Informationen über den Benutzer an, wie Avatar, vollständiger Name, Benutzername, Telefonnummer und E-Mail-Adresse. - **Von Anwendung**: Zeigt den Namen der Anwendung an, mit der sich der Benutzer ursprünglich registriert hat. - **Letzte Anmeldung**: Zeigt den Zeitstempel der letzten Anmeldung des Benutzers an. -Es wird die Schlüsselwortsuche für [`name`](/user-management/user-data#name), [`id`](/user-management/user-data#id), [`username`](/user-management/user-data#username), [`primary-phone`](/user-management/user-data#primary_phone), [`primary-email`](/user-management/user-data#primary_email) unterstützt. +Es wird die Schlüsselwortzuordnung für [`name`](/user-management/user-data#name), [`id`](/user-management/user-data#id), [`username`](/user-management/user-data#username), [`primary-phone`](/user-management/user-data#primary_phone), [`primary-email`](/user-management/user-data#primary_email) unterstützt. ### Benutzer hinzufügen \{#add-users} Mit der Console können Entwickler neue Konten für Endbenutzer erstellen. Klicke dazu auf die Schaltfläche „Benutzer hinzufügen“ in der oberen rechten Ecke des Bildschirms. -Beim Erstellen eines Benutzers in der Logto Console oder über die Management API (nicht vom Endbenutzer selbst über die UI registriert) musst du mindestens einen Identifikator angeben: `primäre E-Mail`, `primäre Telefonnummer` oder `Benutzername`. Das Feld `Name` ist optional. +Beim Erstellen eines Benutzers in der Logto Console oder über die Management API (nicht vom Endbenutzer selbst über die UI registriert), musst du mindestens einen Identifikator angeben: `primary email`, `primary phone` oder `username`. Das Feld `name` ist optional. Nachdem der Benutzer erstellt wurde, generiert Logto automatisch ein zufälliges Passwort. Das Anfangspasswort wird nur einmal angezeigt, aber du kannst das [Passwort zurücksetzen](./manage-users#reset-user-password) später. Wenn du ein bestimmtes Passwort festlegen möchtest, verwende die Management API `patch /api/users/{userId}/password`, um es nach der Erstellung des Benutzers zu aktualisieren. @@ -31,7 +30,7 @@ Du kannst die **eingegebenen Identifikatoren (E-Mail-Adresse / Telefonnummer / B :::tip -Wenn du eine Registrierung nur auf Einladung implementieren möchtest, empfehlen wir, [Benutzer mit einem Magic Link einzuladen](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended). Dadurch können sich nur auf der Whitelist stehende Benutzer selbst registrieren und ihr eigenes Passwort festlegen. +Wenn du eine Registrierung nur auf Einladung implementieren möchtest, empfehlen wir, [Benutzer mit einem Magic Link einzuladen](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended). So können sich nur zugelassene Benutzer selbst registrieren und ihr eigenes Passwort festlegen. ::: @@ -43,48 +42,61 @@ Um die Details eines Benutzers anzuzeigen, klicke einfach auf die entsprechende - **E-Mail-Adresse** ([primary_email](/user-management/user-data#primary_email)): Bearbeitbar - **Telefonnummer** ([primary_phone](/user-management/user-data#primary_phone)): Bearbeitbar - **Benutzername** ([username](/user-management/user-data#username)): Bearbeitbar - - **Passwort** ([has_password](/user-management/user-data#has_password)): Du kannst ein zufälliges Passwort neu generieren. Erfahre mehr unter "[Benutzerpasswort zurücksetzen](#reset-user-password)". - - **Soziale Verbindungen** ([identities](/user-management/user-data#social-identities)): Verknüpfte soziale Konten und Social-IDs anzeigen. Wenn sich der Benutzer beispielsweise mit seinem Facebook-Konto angemeldet hat, siehst du einen "Facebook"-Eintrag in der Liste. Du kannst eine verknüpfte soziale Identität in der Console entfernen. Du kannst jedoch keine neue im Namen des Endbenutzers verknüpfen. - - **Enterprise SSO-Verbindungen** ([sso_identities](/user-management/user-data#sso-identities)): Verknüpfte Enterprise-Identitäten anzeigen. Du kannst SSO-Identitäten in der Console nicht hinzufügen oder entfernen. + - **Passwort** ([has_password](/user-management/user-data#has_password)): Du kannst ein zufälliges Passwort neu generieren. Mehr dazu unter "[Benutzerpasswort zurücksetzen](#reset-user-password)". - **Multi-Faktor-Authentifizierung (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): Zeige alle Authentifizierungsfaktoren (z. B. Passkeys, Authenticator-Apps, Backup-Codes) an, die dieser Benutzer eingerichtet hat. Faktoren können in der Console entfernt werden. - - **Persönlicher Zugriffstoken**: Erstellen, anzeigen, umbenennen und löschen von [persönlichen Zugriffstokens](/user-management/personal-access-token). -- **Benutzerprofildaten**: Name, Avatar-URL, benutzerdefinierte Daten und zusätzliche OpenID Connect Standard-Claims, die nicht enthalten sind. Alle diese Profilfelder sind bearbeitbar. + - **Personal Access Token**: Erstellen, anzeigen, umbenennen und löschen von [Personal Access Tokens](/user-management/personal-access-token). +- **Verbindung**: + - **Soziale Verbindungen** ([identities](/user-management/user-data#social-identities)): + - Zeige die verknüpften sozialen Konten des Benutzers an, einschließlich Social-IDs und Profildetails, die von den sozialen Anbietern synchronisiert wurden (z. B. erscheint ein „Facebook“-Eintrag, wenn sich der Benutzer über Facebook angemeldet hat). + - Du kannst bestehende soziale Identitäten entfernen, aber keine neuen sozialen Konten im Namen des Benutzers verknüpfen. + - Für Social Connectors mit aktivierter [Token-Speicherung](/secret-vault/federated-token-set) kannst du Zugangs- und Auffrischungstokens auf der Verbindungsdetailseite anzeigen und verwalten. + - **Enterprise SSO-Verbindungen** ([sso_identities](/user-management/user-data#sso-identities)): + - Zeige die verknüpften Enterprise-Identitäten des Benutzers an, einschließlich Enterprise-IDs und Profildetails, die von den Enterprise-Identitätsanbietern synchronisiert wurden. + - Du kannst Enterprise SSO-Identitäten in der Console weder hinzufügen noch entfernen. + - Für OIDC-basierte Enterprise Connectors mit aktivierter [Token-Speicherung](/secret-vault/federated-token-set) kannst du Tokens auf der Verbindungsdetailseite anzeigen und löschen. +- **Benutzerprofildaten**: Name, Avatar-URL, benutzerdefinierte Daten und zusätzliche OpenID Connect Standardansprüche, die nicht enthalten sind. Alle diese Profilfelder sind bearbeitbar. :::warning -Es ist wichtig zu bestätigen, dass der Benutzer eine alternative Anmeldemethode hat, bevor eine soziale Verbindung entfernt wird, z. B. eine weitere soziale Verbindung, Telefonnummer, E-Mail oder Benutzername-mit-Passwort. Wenn der Benutzer keine andere Anmeldemethode hat, kann er nach dem Entfernen der sozialen Verbindung nicht mehr auf sein Konto zugreifen. +Es ist wichtig zu bestätigen, dass der Benutzer eine alternative Anmeldemethode hat, bevor eine soziale Verbindung entfernt wird, wie eine weitere soziale Verbindung, Telefonnummer, E-Mail oder Benutzername-mit-Passwort. Wenn der Benutzer keine andere Anmeldemethode hat, kann er nach dem Entfernen der sozialen Verbindung nicht mehr auf sein Konto zugreifen. ::: ### Benutzeraktivitäten anzeigen \{#view-user-activities} -Um die letzten Aktivitäten eines Benutzers anzuzeigen, navigiere zum Untertab "Benutzerprotokolle" auf der Seite "Benutzerdetails". Hier findest du eine Tabelle, die die letzten Aktivitäten des Benutzers anzeigt, einschließlich der durchgeführten Aktion, des Ergebnisses der Aktion, der zugehörigen Anwendung und der Zeit, zu der der Benutzer gehandelt hat. +Um die letzten Aktivitäten eines Benutzers anzuzeigen, navigiere zum Untertab „Benutzerprotokolle“ auf der Seite „Benutzerdetails“. Hier findest du eine Tabelle, die die letzten Aktivitäten des Benutzers anzeigt, einschließlich der durchgeführten Aktion, des Ergebnisses der Aktion, der zugehörigen Anwendung und der Zeit, zu der der Benutzer gehandelt hat. Klicke auf die Tabellenzeile, um weitere Details im Benutzerprotokoll zu sehen, z. B. IP-Adresse, User Agent, Rohdaten usw. ### Benutzer sperren \{#suspend-user} -Auf der Seite "Benutzerdetails" klicke auf "Drei Punkte" -> "Benutzer sperren". +Auf der Seite „Benutzerdetails“ klicke auf „Drei Punkte“ -> „Benutzer sperren“-Schaltfläche. -Sobald ein Benutzer gesperrt ist, kann er sich nicht mehr bei deiner App anmelden und kein neues Zugangstoken erhalten, nachdem das aktuelle abgelaufen ist. Außerdem schlagen alle von diesem Benutzer durchgeführten API-Anfragen fehl. +Sobald ein Benutzer gesperrt ist, kann er sich nicht mehr bei deiner App anmelden und erhält nach Ablauf des aktuellen Zugangstokens kein neues Zugangstoken mehr. Außerdem schlagen alle API-Anfragen dieses Benutzers fehl. -Wenn du diesen Benutzer wieder aktivieren möchtest, kannst du dies tun, indem du auf "Drei Punkte" -> "Benutzer reaktivieren" klickst. +Wenn du diesen Benutzer wieder aktivieren möchtest, kannst du dies tun, indem du auf „Drei Punkte“ -> „Benutzer reaktivieren“-Schaltfläche klickst. ### Benutzer löschen \{#delete-user} -Auf der Seite "Benutzerdetails" klicke auf "Drei Punkte" -> "Löschen". Das Löschen eines Benutzers kann nicht rückgängig gemacht werden. +Auf der Seite „Benutzerdetails“ klicke auf „Drei Punkte“ -> „Löschen“-Schaltfläche. Das Löschen eines Benutzers kann nicht rückgängig gemacht werden. ### Benutzerpasswort zurücksetzen \{#reset-user-password} -Auf der Seite "Benutzerdetails" klicke auf "Drei Punkte" -> "Passwort zurücksetzen", und Logto generiert automatisch ein neues zufälliges Passwort. +Auf der Seite „Benutzerdetails“ klicke auf „Drei Punkte“ -> „Passwort zurücksetzen“-Schaltfläche, und Logto generiert automatisch ein neues zufälliges Passwort. -Nachdem du das Passwort zurückgesetzt hast, kopiere es und sende es an den Endbenutzer. Sobald das "Passwort zurücksetzen"-Modal geschlossen ist, kannst du das Passwort nicht mehr einsehen. Wenn du es vergessen hast, kannst du es erneut zurücksetzen. +Nachdem du das Passwort zurückgesetzt hast, kopiere es und sende es an den Endbenutzer. Sobald das „Passwort zurücksetzen“-Modal geschlossen ist, kannst du das Passwort nicht mehr einsehen. Wenn du es vergessen hast, kannst du es erneut zurücksetzen. -Du kannst in der Logto Console kein bestimmtes Passwort für Benutzer festlegen, aber du kannst die [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` verwenden, um ein Passwort anzugeben. +Du kannst in der Logto Console kein bestimmtes Passwort für Benutzer festlegen, aber du kannst die [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` verwenden, um ein Passwort zu spezifizieren. + +## Passwort-Konformitätsprüfung \{#password-compliance-check} + +Nachdem du die [Passwortrichtlinie](/security/password-policy) in Logto aktualisiert hast, können sich bestehende Benutzer weiterhin mit ihren aktuellen Passwörtern anmelden. Nur neu erstellte Konten müssen die aktualisierte Passwortrichtlinie befolgen. + +Um eine stärkere Sicherheit durchzusetzen, kannst du die `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) verwenden, um zu prüfen, ob das Passwort eines Benutzers der aktuellen Richtlinie in der Standard-Anmeldeerfahrung entspricht. Falls nicht, kannst du den Benutzer mit einem benutzerdefinierten Ablauf auffordern, sein Passwort mit der [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) zu aktualisieren. ### Rollen von Benutzern verwalten \{#manage-roles-of-users} -Im Tab "Rollen" auf der Seite mit den Benutzerdetails kannst du ganz einfach Rollen zuweisen oder entfernen, um das gewünschte Ergebnis zu erzielen. Siehe [Rollenbasierte Zugangskontrolle (RBAC)](/authorization/role-based-access-control) für Details. +Im Tab „Rollen“ auf der Seite mit den Benutzerdetails kannst du ganz einfach Rollen zuweisen oder entfernen, um das gewünschte Ergebnis zu erzielen. Siehe [Rollenbasierte Zugangskontrolle (RBAC)](/authorization/role-based-access-control) für Details. ### Zugehörige Organisationen des Benutzers anzeigen \{#view-the-organizations-the-user-belongs-to} @@ -92,9 +104,9 @@ Logto unterstützt [Organisationen](/organizations/organization-management) und ## Verwaltung über die Logto Management API \{#manage-via-logto-management-api} -Die [Management API](/concepts/core-service/#management-api) ist eine Sammlung von APIs, die Zugriff auf den Logto-Backend-Service bieten. Wie bereits erwähnt, ist die Benutzer-API ein wichtiger Bestandteil dieses Dienstes und kann eine Vielzahl von Szenarien unterstützen. +[Management API](/concepts/core-service/#management-api) ist eine Sammlung von APIs, die Zugriff auf den Logto-Backend-Service bieten. Wie bereits erwähnt, ist die Benutzer-API ein wichtiger Bestandteil dieses Dienstes und kann eine Vielzahl von Szenarien unterstützen. -Die benutzerbezogenen [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs sind unter `/api/users` verfügbar, mit Ausnahme der Benutzeraktivitäten, d. h. Benutzerprotokolle `/api/logs?userId=:userId`. +Die benutzerbezogenen [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs sind unter `/api/users` verfügbar, mit Ausnahme der Benutzeraktivitäten, d. h. Benutzerprotokolle unter `/api/logs?userId=:userId`. Du kannst Benutzer über die Management API in verschiedenen Anwendungsfällen verwalten, z. B. [erweiterte Benutzersuche](/user-management/advanced-user-search), [Massenkontenerstellung](https://openapi.logto.io/operation/operation-createuser), [Registrierung nur auf Einladung](/end-user-flows/sign-up-and-sign-in/disable-user-registration) usw. @@ -108,7 +120,7 @@ Du kannst Benutzer über die Management API in verschiedenen Anwendungsfällen v -Aufgrund der [Omni-sign-in](https://logto.io/products/omni-sign-in)-Natur von Logto ist es nicht darauf ausgelegt, den Benutzerzugriff auf bestimmte Anwendungen vor der Authentifizierung einzuschränken. +Aufgrund der [Omni-sign-in](https://logto.io/products/omni-sign-in)-Natur von Logto ist es nicht dafür ausgelegt, den Benutzerzugriff auf bestimmte Anwendungen vor der Authentifizierung einzuschränken. Du kannst jedoch weiterhin anwendungsspezifische Benutzerrollen und Berechtigungen entwerfen, um deine API-Ressourcen zu schützen, und Berechtigungen beim API-Zugriff nach erfolgreicher Benutzeranmeldung validieren. Siehe Autorisierung: [Rollenbasierte Zugangskontrolle (RBAC)](/authorization/role-based-access-control) für weitere Informationen. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/de/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index b4373409e6f..52680903511 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -10,10 +10,10 @@ Benutzer sind die Kerneinheiten im Identitätsdienst. In Logto umfassen sie grun Jeder Benutzer hat ein Profil, das [alle Benutzerinformationen](#property-reference) enthält. -Es besteht aus folgenden Datentypen: +Es besteht aus den folgenden Datentypen: -- [Basisdaten](/user-management/user-data#basic-data): sind die Basisinformationen aus dem Benutzerprofil. Sie speichern alle anderen _Benutzer_-Eigenschaften außer sozialen `identities` und `custom_data`, wie Benutzer-ID, Benutzername, E-Mail, Telefonnummer und wann sich der Benutzer zuletzt angemeldet hat. -- [Soziale Identitäten](/user-management/user-data#social-identities): speichert die Benutzerinformationen, die durch Social Sign-in (d. h. Anmeldung mit einem Social Connector) abgerufen wurden, wie Facebook, GitHub und WeChat. +- [Basisdaten](/user-management/user-data#basic-data): sind die Basisinformationen aus dem Benutzerprofil. Sie speichern alle anderen Eigenschaften des _Benutzers_, außer den sozialen `identities` und `custom_data`, wie Benutzer-ID, Benutzername, E-Mail, Telefonnummer und wann sich der Benutzer zuletzt angemeldet hat. +- [Soziale Identitäten](/user-management/user-data#social-identities): speichert die Benutzerinformationen, die durch die soziale Anmeldung (d. h. Anmeldung mit einem Social Connector) abgerufen wurden, wie Facebook, GitHub und WeChat. - [Benutzerdefinierte Daten](/user-management/user-data#custom-data): speichert zusätzliche Benutzerinformationen, die nicht in den vordefinierten Benutzereigenschaften aufgeführt sind, wie bevorzugte Farbe und Sprache des Benutzers. Hier ist ein Beispiel für die Daten eines Benutzers, die durch eine Anmeldung bei Facebook abgerufen wurden: @@ -56,25 +56,29 @@ Gehen wir alle Eigenschaften der _Basisdaten_ eines Benutzers durch. ### id \{#id} -_id_ ist ein eindeutig generierter Schlüssel zur Identifizierung des Benutzers in Logto. +_id_ ist ein eindeutiger, automatisch generierter Schlüssel zur Identifizierung des Benutzers in Logto. ### username \{#username} _username_ wird für die Anmeldung mit _Benutzername_ und Passwort verwendet. -Der Wert stammt vom Benutzernamen, mit dem sich der Benutzer erstmals registriert hat. Er kann `null` sein. Ein nicht-null Wert darf maximal 128 Zeichen lang sein, nur Buchstaben, Zahlen und Unterstriche (`_`) enthalten und NICHT mit einer Zahl beginnen. Die Groß- und Kleinschreibung wird beachtet. +Der Wert stammt vom Benutzernamen, mit dem sich der Benutzer zuerst registriert hat. Er kann `null` sein. Sein nicht-null Wert darf maximal 128 Zeichen lang sein, nur Buchstaben, Zahlen und Unterstriche (`_`) enthalten und NICHT mit einer Zahl beginnen. Die Groß- und Kleinschreibung wird beachtet. ### primary_email \{#primary_email} _primary_email_ ist die E-Mail-Adresse des Benutzers, die für die Anmeldung mit E-Mail und Passwort / Verifizierungscode verwendet wird. -Der Wert stammt in der Regel von der E-Mail-Adresse, mit der sich der Benutzer erstmals registriert hat. Er kann `null` sein. Die maximale Länge beträgt 128. +Der Wert stammt in der Regel von der E-Mail-Adresse, mit der sich der Benutzer zuerst registriert hat. Er kann `null` sein. Die maximale Länge beträgt 128. + +Nur verifizierte E-Mail-Adressen von sozialen oder Enterprise SSO Identitätsanbietern können synchronisiert und als `primary_email` gespeichert werden. ### primary_phone \{#primary_phone} _primary_phone_ ist die Telefonnummer des Benutzers, die für die Anmeldung mit Telefonnummer und Passwort / Verifizierungscode aus SMS verwendet wird. -Der Wert stammt in der Regel von der Telefonnummer, mit der sich der Benutzer erstmals registriert hat. Er kann `null` sein. Ein nicht-null Wert sollte Zahlen enthalten, die mit dem [Ländervorwahl-Code](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (ohne das Pluszeichen `+`) beginnen. +Der Wert stammt in der Regel von der Telefonnummer, mit der sich der Benutzer zuerst registriert hat. Er kann `null` sein. Sein nicht-null Wert sollte Zahlen enthalten, die mit dem [Ländervorwahl-Code](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (ohne das Pluszeichen `+`) beginnen. + +Nur verifizierte Telefonnummern von sozialen oder Enterprise SSO Identitätsanbietern können synchronisiert und als `primary_phone` gespeichert werden. ### name \{#name} @@ -84,19 +88,19 @@ _name_ ist der vollständige Name des Benutzers. Die maximale Länge beträgt 12 _avatar_ ist die URL, die auf das Avatarbild des Benutzers zeigt. Die maximale Länge beträgt 2048. -Wenn sich der Benutzer mit einem Social Connector wie Google oder Facebook registriert, kann der Wert aus den sozialen Benutzerinformationen übernommen werden. +Wenn sich der Benutzer mit einem Social Connector wie Google oder Facebook registriert, kann der Wert aus den sozialen Benutzerinformationen abgerufen werden. :::note -Diese Eigenschaft wird dem `picture`-Anspruch im [OpenID Connect](https://openid.net/connect/)-Standard zugeordnet. +Diese Eigenschaft wird im [OpenID Connect](https://openid.net/connect/)-Standard dem `picture`-Claim zugeordnet. ::: ### profile \{#profile} -_profile_ speichert zusätzliche OpenID Connect [Standardansprüche](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims), die nicht in den Benutzereigenschaften enthalten sind. +_profile_ speichert zusätzliche OpenID Connect [Standard-Claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims), die nicht in den Benutzereigenschaften enthalten sind. -Die Typdefinition findest du in [dieser Datei](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6). Hier eine Kopie der Typdefinition: +Die Typdefinition findest du in [dieser Datei](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6). Hier ist eine Kopie der Typdefinition: ```tsx type UserProfile = Partial<{ @@ -128,11 +132,11 @@ type UserProfile = Partial<{ ::: -Ein Unterschied zu anderen Standardansprüchen ist, dass die Eigenschaften in `profile` nur dann im [ID-Token](https://auth.wiki/id-token) oder in der Antwort des userinfo-Endpunkts enthalten sind, wenn ihre Werte nicht leer sind, während andere Standardansprüche `null` zurückgeben, wenn die Werte leer sind. +Ein Unterschied zu den anderen Standard-Claims besteht darin, dass die Eigenschaften in `profile` nur dann im [ID-Token](https://auth.wiki/id-token) oder in der Antwort des userinfo-Endpunkts enthalten sind, wenn ihre Werte nicht leer sind, während andere Standard-Claims `null` zurückgeben, wenn die Werte leer sind. ### application_id \{#application_id} -Der Wert von _application_id_ stammt von der Anwendung, bei der sich der Benutzer erstmals angemeldet hat. Er kann `null` sein. +Der Wert von _application_id_ stammt von der Anwendung, bei der sich der Benutzer zuerst angemeldet hat. Er kann `null` sein. ### last_sign_in_at \{#last_sign_in_at} @@ -148,21 +152,21 @@ _updated_at_ ist der Zeitstempel mit Zeitzone, wann die Profilinformationen des ### has_password \{#has_password} -_has_password_ ist ein boolescher Wert, der angibt, ob der Benutzer ein Passwort hat. Du kannst diesen Status anzeigen und verwalten, einschließlich Festlegen eines neuen oder Zurücksetzen des Passworts auf der Detailseite von Console > Benutzerverwaltung. +_has_password_ ist ein boolescher Wert, der angibt, ob der Benutzer ein Passwort hat. Du kannst diesen Status anzeigen und verwalten, einschließlich des Setzens eines neuen oder Zurücksetzens des Passworts auf der Detailseite von Console > Benutzerverwaltung. ### password_encrypted \{#password_encrypted} _password_encrypted_ wird verwendet, um das verschlüsselte Passwort des Benutzers zu speichern. -Der Wert stammt vom Passwort, mit dem sich der Benutzer erstmals registriert hat. Er kann `null` sein. Wenn der Wert nicht null ist, sollte der ursprüngliche Inhalt vor der Verschlüsselung mindestens sechs Zeichen lang sein. +Der Wert stammt vom Passwort, mit dem sich der Benutzer zuerst registriert hat. Er kann `null` sein. Wenn der Wert nicht null ist, sollte der ursprüngliche Inhalt vor der Verschlüsselung mindestens sechs Zeichen lang sein. ### password_encryption_method \{#password_encryption_method} -_password_encryption_method_ wird verwendet, um das Passwort des Benutzers zu verschlüsseln. Der Wert wird initialisiert, wenn sich der Benutzer mit Benutzername und Passwort registriert. Er kann `null` sein. +_password_encryption_method_ wird verwendet, um das Passwort des Benutzers zu verschlüsseln. Der Wert wird beim Registrieren mit Benutzername und Passwort initialisiert. Er kann `null` sein. Logto verwendet standardmäßig die [Argon2](https://en.wikipedia.org/wiki/Argon2)-Implementierung [node-argon2](https://github.com/ranisalt/node-argon2) als Verschlüsselungsmethode; siehe die Referenz für Details, falls du interessiert bist. -Beispiel für _password_encrypted_ und _password_encryption_method_ von einem Benutzer, dessen Passwort `123456` ist: +Beispiel für _password_encrypted_ und _password_encryption_method_ eines Benutzers, dessen Passwort `123456` ist: ```json { @@ -187,9 +191,9 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; ## Soziale Identitäten \{#social-identities} -_identities_ enthält die durch [Social Sign-in](/end-user-flows/sign-up-and-sign-in/social-sign-in) (d. h. Anmeldung mit einem [Social Connector](/connectors/social-connectors)) abgerufenen Benutzerinformationen. Die _identities_ jedes Benutzers werden in einem eigenen JSON-Objekt gespeichert. +_identities_ enthält die durch [soziale Anmeldung](/end-user-flows/sign-up-and-sign-in/social-sign-in) (d. h. Anmeldung mit einem [Social Connector](/connectors/social-connectors)) abgerufenen Benutzerinformationen. Die _identities_ jedes Benutzers werden in einem eigenen JSON-Objekt gespeichert. -Die Benutzerinformationen variieren je nach Anbieter sozialer Identitäten (d. h. soziales Netzwerk) und umfassen typischerweise Folgendes: +Die Benutzerinformationen variieren je nach Anbieter der sozialen Identität (d. h. soziales Netzwerk) und umfassen typischerweise Folgendes: - _target_ des Identitätsanbieters, wie "facebook" oder "google" - Eindeutiger Benutzeridentifikator für diesen Anbieter @@ -197,7 +201,7 @@ Die Benutzerinformationen variieren je nach Anbieter sozialer Identitäten (d. h - Verifizierte E-Mail des Benutzers - Avatar des Benutzers -Das Benutzerkonto kann über Social Sign-in mit mehreren Anbietern sozialer Identitäten verknüpft sein; die entsprechenden Benutzerinformationen, die von diesen Anbietern abgerufen werden, werden im _identities_-Objekt gespeichert. +Das Benutzerkonto kann mit mehreren sozialen Identitätsanbietern über soziale Anmeldung verknüpft sein; die entsprechenden Benutzerinformationen, die von diesen Anbietern abgerufen werden, werden im _identities_-Objekt gespeichert. Beispiel für _identities_ eines Benutzers, der sich sowohl mit Google als auch mit Facebook angemeldet hat: @@ -228,7 +232,7 @@ Beispiel für _identities_ eines Benutzers, der sich sowohl mit Google als auch _sso_identities_ enthält die durch [Enterprise SSO](/end-user-flows/enterprise-sso) (d. h. Single Sign-On-Anmeldung mit einem Enterprise Connector](/connectors/enterprise-connectors)) abgerufenen Benutzerinformationen. Die _ssoIdentities_ jedes Benutzers werden in einem eigenen JSON-Objekt gespeichert. -Die von der SSO-Identitätsquelle synchronisierten Daten hängen von den im Enterprise Connector konfigurierten Berechtigungen ab. Hier ist eine Kopie der TypeScript-Typdefinition: +Die von dem SSO-Identitätsanbieter synchronisierten Daten hängen von den im Enterprise Connector konfigurierten Berechtigungen ab. Hier ist eine Kopie der TypeScript-Typdefinition: ```ts type SSOIdentity = { @@ -244,8 +248,8 @@ _custom_data_ speichert zusätzliche Benutzerinformationen, die nicht in den vor Du kannst _custom_data_ für folgende Zwecke verwenden: -- Erfassen, ob bestimmte Aktionen vom Benutzer durchgeführt wurden, z. B. ob die Willkommensseite gesehen wurde. -- Anwendungsspezifische Daten im Benutzerprofil speichern, z. B. bevorzugte Sprache und Erscheinungsbild des Benutzers pro Anwendung. +- Festhalten, ob bestimmte Aktionen vom Benutzer durchgeführt wurden, z. B. ob die Willkommensseite gesehen wurde. +- Anwendungsspezifische Daten im Benutzerprofil speichern, wie die bevorzugte Sprache und das Erscheinungsbild des Benutzers pro Anwendung. - Andere beliebige, benutzerbezogene Daten pflegen. Beispiel für _custom_data_ eines Admin-Benutzers in Logto: @@ -276,17 +280,17 @@ Lege KEINE sensiblen Daten in _custom_data_ ab. Benutzerdefinierte Daten können nach der Benutzeranmeldung über [benutzerdefinierte JWT-Token-Ansprüche](/developers/custom-token-claims) abgerufen werden, und JWT-Tokens sind base64-codiert (nicht verschlüsselt) und werden häufig über Netzwerke übertragen, wodurch sensible Daten leicht offengelegt werden können. -Du kannst ein Benutzerprofil mit _custom_data_ über die [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) abrufen und an Frontend-Apps oder externe Backend-Dienste senden. Daher kann das Ablegen sensibler Informationen in _custom_data_ zu Datenlecks führen. +Du kannst ein Benutzerprofil mit _custom_data_ über die [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) abrufen und an Frontend-Apps oder externe Backend-Services senden. Daher kann das Ablegen sensibler Informationen in _custom_data_ zu Datenlecks führen. -Wenn du dennoch sensible Informationen in _custom_data_ speichern möchtest, empfehlen wir, diese zuerst zu verschlüsseln. Verschlüssele/entschlüssele sie nur in einer vertrauenswürdigen Instanz wie deinen Backend-Diensten und vermeide dies in Frontend-Apps. Dadurch wird der Schaden minimiert, falls die _custom_data_ deiner Benutzer versehentlich offengelegt wird. +Wenn du dennoch sensible Informationen in _custom_data_ speichern möchtest, empfehlen wir, diese vorher zu verschlüsseln. Verschlüssele/entschlüssele sie nur in einer vertrauenswürdigen Instanz wie deinen Backend-Services und vermeide dies in den Frontend-Apps. Dadurch wird der Schaden minimiert, falls die _custom_data_ deiner Benutzer versehentlich offengelegt wird. -**So sammelst und aktualisierst du benutzerdefinierte Daten** +**Wie man benutzerdefinierte Benutzerdaten sammelt und aktualisiert** - Verwende die Funktion [Benutzerprofil erfassen](/end-user-flows/collect-user-profile), um benutzerdefinierte Daten während der Benutzerregistrierung zu sammeln. - Verwende die [Account API](/end-user-flows/account-settings/by-account-api), um Endbenutzerprofil- oder Kontoeinstellungen zu implementieren. - Verwende [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile), um alle Benutzerdaten abzurufen. - Verwende [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile), um die _custom_data_ eines Benutzers zu aktualisieren. -- Verwende die [Management API](/user-management/manage-users/#manage-via-logto-management-api) für Benutzerverwaltung oder erweiterte benutzerdefinierte Abläufe: +- Verwende die [Management API](/user-management/manage-users/#manage-via-logto-management-api) für die Benutzerverwaltung oder fortgeschrittene benutzerdefinierte Abläufe: - Verwende [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser), um alle Benutzerdaten abzurufen. - Verwende [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata), um die _custom_data_ eines Benutzers zu aktualisieren. - Dein Support-Team kann die _custom_data_ eines Benutzers direkt in Console > Benutzerverwaltung aktualisieren. Erfahre mehr über das [Anzeigen und Aktualisieren von Benutzerprofilen](/user-management/manage-users/#view-and-update-the-user-profile). @@ -303,7 +307,7 @@ Wenn dein Eingabewert beim Aufruf der Update-_custom_data_-API wie folgt aussieh } ``` -dann sieht der neue _custom_data_-Wert nach dem Update so aus: +dann sieht der neue _custom_data_-Wert nach dem Aktualisieren so aus: ```json { @@ -313,7 +317,7 @@ dann sieht der neue _custom_data_-Wert nach dem Update so aus: } ``` -Das heißt, der aktualisierte Feldwert hat nichts mehr mit dem vorherigen Wert zu tun. +Das heißt, der aktualisierte Feldwert hat nichts mit dem vorherigen Wert zu tun. ## Eigenschaftsreferenz \{#property-reference} @@ -328,8 +332,8 @@ Die folgenden Spalten der Benutzer-DB-Tabelle (außer _password_encrypted_ und _ | [name](/user-management/user-data#name) | string | Vollständiger Name | ❌ | ❌ | | [avatar](/user-management/user-data#avatar) | string | URL zum Avatarbild des Benutzers | ❌ | ❌ | | [profile](/user-management/user-data#profile) | object | Benutzerprofil | ❌ | ✅ | -| [identities](/user-management/user-data#social-identities) | object | Durch Social Sign-in abgerufene Benutzerinfos | ❌ | ✅ | -| [custom_data](/user-management/user-data#custom-data) | object | Zusätzliche Infos in anpassbaren Feldern | ❌ | ✅ | +| [identities](/user-management/user-data#social-identities) | object | Durch soziale Anmeldung abgerufene Daten | ❌ | ✅ | +| [custom_data](/user-management/user-data#custom-data) | object | Zusätzliche Infos in anpassbaren Eigenschaften | ❌ | ✅ | | [application_id](/user-management/user-data#application_id) | string | Anwendungs-ID, bei der sich der Benutzer zuerst registriert hat | ❌ | ✅ | | [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | Zeitstempel der letzten Anmeldung | ❌ | ✅ | | [password_encrypted](/user-management/user-data#password_encrypted) | string | Verschlüsseltes Passwort | ❌ | ❌ | @@ -343,5 +347,5 @@ Die folgenden Spalten der Benutzer-DB-Tabelle (außer _password_encrypted_ und _ ## Verwandte Ressourcen \{#related-resources} - Sicheres Zentrum für Benutzerdaten in Bewegung + Sicheres Zentrum für Benutzerdaten unterwegs diff --git a/i18n/es/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/es/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index 81836549e53..115aab101d0 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -74,9 +74,9 @@ sequenceDiagram Cliente->>Logto: GET /oidc/auth Logto->>Logto: Redirige al usuario a la página de inicio de sesión Logto->>Cliente: Redirige de vuelta con `authorization_code` - alt Usar el grant de authorization_code + alt Usar grant de authorization_code Cliente->>Logto: POST /oidc/token con `grant_type=authorization_code`
y parámetro `resource` - else Usar el grant de refresh_token + else Usar grant de refresh_token Cliente->>Logto: POST /oidc/token con `grant_type=authorization_code` Logto->>Cliente: Devuelve refresh token Cliente->>Logto: POST /oidc/token con `grant_type=refresh_token`
y parámetro `resource` @@ -87,11 +87,11 @@ sequenceDiagram Logto->>Cliente: Devuelve token de acceso (JSON Web Token) Cliente->>API: Solicitud con token Bearer - API->>API: Valida el token de acceso + API->>API: Valida token de acceso - alt El token es válido + alt Token válido API->>Cliente: Devuelve datos del recurso protegido - else El token no es válido + else Token inválido API->>Cliente: 401 No autorizado end ``` @@ -109,30 +109,30 @@ El parámetro `resource` debe coincidir exactamente con el identificador de API 1. Ve a Consola → Recursos de API. 2. Crea un nuevo recurso de API (por ejemplo, `https://api.yourapp.com/org`) y define sus permisos (alcances). -Para ver los pasos completos de configuración, consulta [Definir recursos de API con permisos](/authorization/role-based-access-control#define-api-resources-with-permissions). +Para ver todos los pasos de configuración, consulta [Definir recursos de API con permisos](/authorization/role-based-access-control#define-api-resources-with-permissions). ### Configura roles globales \{#set-up-global-roles} 1. Ve a Consola → Roles. -2. Crea roles que correspondan a los permisos de tu API (por ejemplo, `read:products`, `write:products`). +2. Crea roles que se correspondan con los permisos de tu API (por ejemplo, `read:products`, `write:products`). 3. Asigna estos roles a los usuarios o clientes que necesiten acceso a la API. -Para ver los pasos completos de configuración, consulta [Usar roles globales](/authorization/role-based-access-control#configure-global-roles). +Para ver todos los pasos de configuración, consulta [Usar roles globales](/authorization/role-based-access-control#configure-global-roles). ### Obtén tokens de acceso para recursos globales de API \{#obtain-access-tokens-for-global-api-resources} -Antes de acceder a un recurso global de API, tu cliente debe obtener un token de acceso. Logto emite [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) como tokens de acceso para recursos globales de API. Esto normalmente se realiza usando el [flujo de código de autorización OAuth 2.0](https://auth.wiki/authorization-code-flow), [flujo de refresh token](https://auth.wiki/refresh-token), o el [flujo de credenciales de cliente](https://auth.wiki/client-credentials-flow). +Antes de acceder a un recurso global de API, tu cliente debe obtener un token de acceso. Logto emite [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) como tokens de acceso para recursos globales de API. Esto normalmente se realiza usando el [flujo de código de autorización OAuth 2.0](https://auth.wiki/authorization-code-flow), [flujo de refresh token](https://auth.wiki/refresh-token), o el [flujo de client credentials](https://auth.wiki/client-credentials-flow). #### Flujo de código de autorización o refresh token \{#authorization-code-or-refresh-token-flow} -Todos los SDK oficiales de Logto admiten la obtención de tokens de acceso para recursos globales de API usando el flujo de refresh token de forma predeterminada. También se puede usar una biblioteca cliente estándar de OAuth 2.0 / OIDC para implementar este flujo. +Todos los SDK oficiales de Logto admiten la obtención de tokens de acceso para recursos globales de API usando el flujo de refresh token de forma predeterminada. También se puede usar una biblioteca estándar de cliente OAuth 2.0 / OIDC para implementar este flujo. -Al inicializar el cliente Logto, añade el indicador de recurso al parámetro `resources` (array), luego añade los permisos deseados (alcances) al parámetro `scopes`. +Al inicializar el cliente de Logto, agrega el indicador de recurso al parámetro `resources` (array), luego agrega los permisos deseados (alcances) al parámetro `scopes`. -Una vez que el usuario está autenticado, pasa el indicador de recurso en el parámetro `resource` o en un parámetro de nombre similar al solicitar el token de acceso (por ejemplo, llamando a `getAccessToken()`). +Una vez que el usuario esté autenticado, pasa el indicador de recurso en el parámetro `resource` o un parámetro de nombre similar al solicitar el token de acceso (por ejemplo, llamando a `getAccessToken()`). Para detalles sobre cada SDK, consulta los [Inicios rápidos](/quick-starts). @@ -141,13 +141,13 @@ Para detalles sobre cada SDK, consulta los [Inicios rápidos](/quick-starts). Al configurar tu cliente OAuth 2.0 o inicializar el flujo de código de autorización, asegúrate de incluir el parámetro `resource` y los alcances deseados en la solicitud de autorización. -Algunas bibliotecas pueden no soportar el parámetro `resource` de forma nativa, pero normalmente permiten pasar parámetros adicionales en la solicitud de autorización. Consulta la documentación de tu biblioteca para más detalles. +Algunas bibliotecas pueden no admitir el parámetro `resource` de forma nativa, pero normalmente permiten pasar parámetros adicionales en la solicitud de autorización. Consulta la documentación de tu biblioteca para más detalles. Aquí tienes un ejemplo no normativo de la solicitud de autorización con los parámetros `resource` y `scope`: -Una vez que el usuario está autenticado, recibirás un authorization code. Intercambia este código por un token de acceso haciendo una solicitud POST al endpoint `/oidc/token` de Logto, incluyendo el parámetro `resource` en el cuerpo de la solicitud. +Una vez que el usuario esté autenticado, recibirás un authorization code. Intercambia este código por un token de acceso haciendo una solicitud POST al endpoint `/oidc/token` de Logto, incluyendo el parámetro `resource` en el cuerpo de la solicitud. Aquí tienes un ejemplo no normativo de la solicitud de token usando el grant type authorization_code: @@ -162,16 +162,16 @@ Aquí tienes un ejemplo no normativo de la solicitud de token usando el grant ty -#### Flujo de credenciales de cliente \{#client-credentials-flow} +#### Flujo de client credentials \{#client-credentials-flow} -Para escenarios máquina a máquina (M2M), puedes usar el flujo de credenciales de cliente para obtener un token de acceso para tu recurso global de API. Haciendo una solicitud POST al endpoint `/oidc/token` de Logto, puedes solicitar un token de acceso usando tu client ID y secret. +Para escenarios máquina a máquina (M2M), puedes usar el flujo de client credentials para obtener un token de acceso para tu recurso global de API. Haciendo una solicitud POST al endpoint `/oidc/token` de Logto, puedes solicitar un token de acceso usando tu client ID y secret. Hay dos parámetros clave que debes incluir en la solicitud: - `resource`: El URI indicador de recurso de la API a la que deseas acceder (por ejemplo, `https://api.yourapp.com`). - `scope`: Los permisos que deseas solicitar para la API (por ejemplo, `read:products write:products`). -Aquí tienes un ejemplo no normativo de la solicitud de token usando el grant type client_credentials: +Aquí tienes un ejemplo no normativo de la solicitud de token usando el grant type client credentials: -### ¿Qué pasa si mi cliente no soporta el parámetro resource? \{#what-if-my-client-doesn-t-support-the-resource-parameter} +### ¿Qué pasa si mi cliente no admite el parámetro resource? \{#what-if-my-client-doesn-t-support-the-resource-parameter} -Configura un recurso de API predeterminado en la Consola de Logto. Los tokens usarán esta audiencia por defecto cuando no se especifique el parámetro resource en la solicitud de token. +Configura un recurso de API predeterminado en la Consola de Logto. Los tokens tendrán esta audiencia por defecto cuando no se especifique el parámetro resource en la solicitud de token. @@ -227,9 +227,9 @@ Configura un recurso de API predeterminado en la Consola de Logto. Los tokens us Verifica los siguientes problemas comunes: -- **Firma del token**: Asegúrate de que tu backend obtiene los JWKs correctos de Logto +- **Firma del token**: Asegúrate de que tu backend esté obteniendo los JWKs correctos de Logto - **Expiración del token**: Verifica que el token no haya expirado (reclamo `exp`) -- **Audiencia**: Confirma que el reclamo `aud` coincide con el indicador de recurso de API registrado +- **Audiencia**: Confirma que el reclamo `aud` coincida con el indicador de recurso de API registrado - **Alcances requeridos**: Verifica que el token contenga los permisos necesarios en el reclamo `scope` @@ -245,11 +245,41 @@ Utiliza un [token de acceso personal](/user-management/personal-access-token) pa -## Lecturas adicionales \{#further-reading} +
+ + +### ¿Puedo usar prefijos de scope o versiones abreviadas al solicitar permisos? \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +No. Los nombres de scope deben **coincidir exactamente** con los nombres de permisos definidos en tu recurso de API. Los prefijos y versiones abreviadas no funcionan como comodines. + +**Ejemplo:** + +Si tu recurso de API define: + +- `read:elections` +- `write:elections` + +Debes solicitar: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +Esto **NO funcionará**: + +```swift +scopes: ["read", "write"] // ❌ No coincide con los nombres de permisos +``` + +
+ +## Más información \{#further-reading} Cómo validar tokens de acceso RBAC en la práctica: Implementando autorización segura para tu aplicación -Personalización de reclamos de tokens +Personalización de reclamos de token RFC 8707: Indicadores de recurso diff --git a/i18n/es/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/es/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index f257795c13f..b11214756ea 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -19,17 +19,17 @@ Personaliza fácilmente la configuración de idioma en Logto Console sin necesid Aquí tienes algunos términos clave para comprender al gestionar idiomas: -| Definición | Descripción | -| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Etiqueta de idioma | La etiqueta de idioma identifica el idioma del contenido. Una etiqueta de idioma se compone de un código de idioma (por ejemplo, en, fr, zh) y un código de país/región (por ejemplo, US, UK, KR) separados por guiones. Ejemplo: en-US. | -| Idioma proporcionado por Logto | El idioma proporcionado por Logto es el idioma oficial de Logto y se almacena en el código fuente original de Logto. | -| Idioma añadido | El idioma añadido es el idioma agregado por los usuarios. | -| Valores fuente de Logto | Los valores fuente de Logto son los valores suministrados por Logto que no han sido personalizados por los usuarios. | -| Valores personalizados | Los valores personalizados son valores que ya han sido personalizados por los usuarios. Los valores fuente de Logto serán sobrescritos. | +| Definición | Descripción | +| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Etiqueta de idioma (Language tag) | La etiqueta de idioma identifica el idioma del contenido. Una etiqueta de idioma se compone de un código de idioma (por ejemplo, en, fr, zh) y un código de país/región (por ejemplo, US, UK, KR) separados por guiones. Una etiqueta de idioma se ve así: en-US. | +| Idioma proporcionado por Logto (Logto provided language) | El idioma proporcionado por Logto es el idioma oficial de Logto y se almacena en el código fuente original de Logto. | +| Idioma añadido (Added language) | El idioma añadido es el idioma agregado por los usuarios. | +| Valores fuente de Logto (Logto source values) | Los valores fuente de Logto son valores suministrados por Logto que no han sido personalizados por los usuarios. | +| Valores personalizados (Custom values) | Los valores personalizados son valores que ya han sido personalizados por los usuarios. Los valores fuente de Logto serán sobrescritos. | ## Personalización usando Management API \{#customization-using-management-api} -Puedes usar el Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) para personalizar las traducciones de idioma. El cuerpo de la solicitud API es un objeto de localización parcial como: +Puedes usar el Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) para personalizar las traducciones de idioma. El cuerpo de la solicitud de la API es un objeto de localización parcial como: ```json { @@ -50,7 +50,7 @@ Puedes usar el Management API [PUT /api/custom-phrases/\{languageTag\}](https:// Consulta [el código fuente](https://github.com/logto-io/logto/blob/master/packages/phrases-experience/src/locales/en/index.ts) para ver todos los contenidos personalizables. -También puedes usar el [PATCH /api/sign-in-exp](https://openapi.logto.io/group/endpoint-sign-in-experience) API para controlar las [políticas de detección de idioma](https://openapi.logto.io/operation/operation-getsigninexp#operation-getsigninexp-200-body-application-json-languageinfo). +También puedes usar la API [PATCH /api/sign-in-exp](https://openapi.logto.io/group/endpoint-sign-in-experience) para controlar las [políticas de detección de idioma](https://openapi.logto.io/operation/operation-getsigninexp#operation-getsigninexp-200-body-application-json-languageinfo). ## Resolución de idioma en tiempo de ejecución \{#runtime-language-resolution} @@ -58,9 +58,9 @@ En tiempo de ejecución, el idioma de la experiencia de inicio de sesión se res 1. Parámetro OIDC `ui_locales` de la solicitud de autenticación actual (se usa la primera etiqueta compatible). Consulta [ui_locales](/end-user-flows/authentication-parameters/ui-locales). 2. De lo contrario, si la "detección automática" está habilitada, el idioma detectado del cliente del usuario (por ejemplo, del encabezado HTTP `Accept-Language`). -3. De lo contrario, el idioma predeterminado del inquilino en la Experiencia de inicio de sesión. +3. De lo contrario, el idioma predeterminado del inquilino en la Experiencia de Inicio de Sesión. -Esta resolución también afecta la localización de correos electrónicos para los mensajes desencadenados por la interacción. Más información: [Localización de plantillas de correo electrónico](/connectors/email-connectors/email-templates#email-template-localization). +Esta resolución también afecta la localización de correos electrónicos para los mensajes activados por la interacción. Más información: [Localización de plantillas de correo electrónico](/connectors/email-connectors/email-templates#email-template-localization). ## Casos de uso \{#use-cases} @@ -94,13 +94,26 @@ Junto a la etiqueta de idioma a la izquierda, aparecerá una etiqueta de idioma -Lo que ven los usuarios finales es el resultado de la fusión de ambas columnas. -Supón que solo quieres hacer ajustes en un subconjunto de los textos originales proporcionados por Logto. La única diferencia entre tu pantalla de registro y la proporcionada por Logto serán las claves que editaste. El resto del contenido permanecerá sin cambios. +Lo que ven los usuarios finales es el resultado de la fusión de las dos columnas. +Supón que solo quieres hacer ajustes en un subconjunto de los textos originales que Logto suministró. La única diferencia entre tu pantalla de registro y la proporcionada por Logto serán las claves que editaste. El resto del contenido permanecerá sin cambios. + + + +
+ + +### ¿Cómo puedo establecer un código de país de teléfono predeterminado para la experiencia de inicio de sesión? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +El código de país del número de teléfono en la [experiencia de inicio de sesión](/end-user-flows/sign-up-and-sign-in/sign-up) se establece por defecto según la configuración regional del navegador del usuario. Por ejemplo, si el idioma del navegador de un usuario está configurado en `fr`, el código de país predeterminado será Francia (+33). + +Para controlar programáticamente el código de país predeterminado para usuarios o regiones específicas, puedes usar el parámetro de autenticación [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales). Por ejemplo, establecer `ui_locales=ja` hará que el código de país predeterminado sea Japón (+81).
## Recursos relacionados \{#related-resources} - Soporte para árabe y diseño de idioma RTL (de derecha a izquierda) en tu aplicación + Compatibilidad con árabe y diseño de idioma RTL (de derecha a izquierda) en tu aplicación diff --git a/i18n/es/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/es/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index 544069c93d5..51a3be7c00c 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -8,19 +8,19 @@ sidebar_position: 1 Personaliza el aspecto y la sensación de tu página de inicio de sesión navegando a Consola > Experiencia de inicio de sesión > Marca. Esta sección te permite ajustar fácilmente los elementos clave de la marca. -**Color de marca** +### Color de la marca \{#brand-color} Define el color principal utilizado en toda la experiencia de inicio de sesión, incluidos los botones principales, enlaces y otros componentes. Sustituye el color púrpura predeterminado de Logto por el color de tu marca. Para el modo oscuro, se puede especificar un color de marca diferente. -**Logo de la empresa** +### Logotipo de la empresa \{#company-logo} -El logo se mostrará en la página principal de inicio de sesión, la página principal de registro, la página de carga y otras interfaces con nuestra expansión. +El logotipo se mostrará en la página principal de inicio de sesión, la página principal de registro, la página de carga y otras interfaces con nuestra expansión. - Hay algunas limitaciones para las imágenes: deben ser menores de 500KB y estar en formato SVG, PNG, JPG, JPEG o ICO. -- Si dejas el campo del logo en blanco, el logo no se mostrará en la interfaz. -- También se puede cargar una versión del logo para el modo oscuro. +- Si dejas el campo del logotipo en blanco, el logotipo no se mostrará en la interfaz. +- También se puede cargar una versión del logotipo para el modo oscuro. -**Favicon** +### Favicon \{#favicon} Un favicon es un pequeño icono que representa un sitio web y se muestra en la pestaña del navegador, marcadores y otras áreas de la interfaz del navegador. @@ -28,37 +28,41 @@ Un favicon es un pequeño icono que representa un sitio web y se muestra en la p - También se puede cargar una versión del favicon para el modo oscuro. - Además, ahora se utiliza el título del navegador para los diferentes flujos (Iniciar sesión / Registrarse / Olvidé mi contraseña, etc.) en lugar de un título personalizado. -**Modo oscuro** +### Modo oscuro \{#dark-mode} Activa el modo oscuro para ajustar automáticamente la apariencia de la página de inicio de sesión según las preferencias del sistema del usuario. +### Ocultar la marca Logto \{#hide-logto-branding} + +Por defecto, las páginas de experiencia de inicio de sesión listas para usar muestran "Powered by Logto" en la parte inferior. Activa la opción "Ocultar la marca Logto" para eliminar la marca de Logto y crear una experiencia de inicio de sesión limpia y profesional que muestre exclusivamente la identidad de tu propia marca. + ## Personalización específica de la aplicación \{#app-specific-branding} Si tu negocio multi-aplicación necesita experiencias de inicio de sesión a nivel de aplicación, puedes configurarlo en la página de detalles de la aplicación. Navega a Consola > Aplicaciones. -Al activar la "Experiencia de inicio de sesión a nivel de aplicación", puedes configurar logos de marca específicos, favicons, colores e incluso [CSS personalizado](/customization/custom-css) para cada aplicación. Cuando se inicia un inicio de sesión desde una aplicación con la personalización a nivel de aplicación habilitada, la experiencia de inicio de sesión se personalizará según la configuración de marca de la aplicación; de lo contrario, se utilizarán los ajustes predeterminados de la experiencia de inicio de sesión omni. +Al activar "Experiencia de inicio de sesión a nivel de aplicación", puedes configurar logotipos, favicons, colores e incluso [CSS personalizado](/customization/custom-css) específicos para cada aplicación. Cuando se inicia un inicio de sesión desde una aplicación con la personalización a nivel de aplicación habilitada, la experiencia de inicio de sesión se personalizará según la configuración de la aplicación; de lo contrario, se utilizarán los ajustes predeterminados de la experiencia de inicio de sesión omni. Tanto los ajustes de modo claro como de modo oscuro están disponibles para la personalización a nivel de aplicación. Los ajustes de modo oscuro solo tendrán efecto cuando el modo oscuro esté habilitado en la [experiencia de inicio de sesión omni](#omni-sign-in-experience). ## Personalización específica de la organización \{#organization-specific-branding} -Para mostrar dinámicamente el logo de la organización de tu cliente en la experiencia de inicio de sesión, puedes subir los logos de la organización en la página de configuración de la organización. Navega a Consola > Organizaciones. +Para mostrar dinámicamente el logotipo de la organización de tu cliente en la experiencia de inicio de sesión, puedes cargar los logotipos de la organización en la página de configuración de la organización. Navega a Consola > Organizaciones. -Al activar la "Experiencia de inicio de sesión a nivel de organización", al igual que la personalización a nivel de aplicación, también puedes configurar logos de marca específicos, favicons, colores y [CSS personalizado](/customization/custom-css) para cada organización. +Al activar "Experiencia de inicio de sesión a nivel de organización", al igual que la personalización a nivel de aplicación, también puedes configurar logotipos, favicons, colores y [CSS personalizado](/customization/custom-css) específicos para cada organización. -Luego, al iniciar un inicio de sesión, puedes pasar el ID de la organización en el parámetro `organization_id` para indicar a Logto qué logo de organización mostrar. Por ejemplo, para mostrar el logo de la organización con ID `123456`: +Luego, al iniciar un inicio de sesión, puedes pasar el ID de la organización en el parámetro `organization_id` para indicar a Logto qué logotipo de organización mostrar. Por ejemplo, para mostrar el logotipo de la organización con ID `123456`: -- Si utilizas el SDK de Logto, puedes pasar el parámetro `organization_id` en el objeto `extraParams` del método `signIn`. +- Si utilizas Logto SDK, puedes pasar el parámetro `organization_id` en el objeto `extraParams` del método `signIn`. - Si utilizas un cliente OIDC, puedes pasar el parámetro `organization_id` al solicitar el [endpoint de autorización](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). Tanto los ajustes de modo claro como de modo oscuro están disponibles para la personalización a nivel de organización. Los ajustes de modo oscuro solo tendrán efecto cuando el modo oscuro esté habilitado en la [experiencia de inicio de sesión omni](#omni-sign-in-experience). :::note -Si tanto la personalización a nivel de aplicación como la personalización a nivel de organización están habilitadas, la personalización a nivel de organización tendrá prioridad. El orden completo de precedencia es: +Si tanto la personalización a nivel de aplicación como la de organización están habilitadas, la personalización a nivel de organización tendrá prioridad. El orden de precedencia completo es: Personalización a nivel de organización -> Personalización a nivel de aplicación -> Experiencia de inicio de sesión omni ::: -Aquí tienes un ejemplo de cómo pasar el parámetro `organization_id` en el método `signIn` usando el [SDK de navegador de Logto](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out): +Aquí tienes un ejemplo de cómo pasar el parámetro `organization_id` en el método `signIn` usando el [Logto browser SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out): **index.ts** diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index 0140589eb76..4613af0342f 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -7,16 +7,16 @@ sidebar_position: 1 ## ¿Qué es la Account API de Logto? \{#what-is-logto-account-api} -La Account API de Logto es un conjunto completo de APIs que otorga a los usuarios finales acceso directo a la API sin necesidad de pasar por la Management API. Aquí tienes los aspectos destacados: +La Account API de Logto es un conjunto completo de APIs que otorga a los usuarios finales acceso directo a la API sin necesidad de pasar por la Management API. Aquí tienes los aspectos más destacados: -- Acceso directo: La Account API permite a los usuarios finales acceder y gestionar directamente sus propios perfiles de cuenta sin requerir el uso intermedio de la Management API. +- Acceso directo: La Account API permite a los usuarios finales acceder y gestionar directamente sus propios perfiles de cuenta sin requerir el uso de la Management API. - Gestión de perfil de usuario e identidades: Los usuarios pueden gestionar completamente sus perfiles y configuraciones de seguridad, incluyendo la capacidad de actualizar información de identidad como correo electrónico, teléfono y contraseña, así como gestionar conexiones sociales. El soporte para MFA y SSO estará disponible próximamente. - Control de acceso global: Los administradores tienen control total y global sobre la configuración de acceso y pueden personalizar cada campo. -- Autorización sin fricciones: ¡La autorización es más fácil que nunca! Simplemente usa `client.getAccessToken()` para obtener un token de acceso opaco para OP (Logto), y adjúntalo al encabezado Authorization como `Bearer `. +- Autorización sin complicaciones: ¡La autorización es más fácil que nunca! Simplemente usa `client.getAccessToken()` para obtener un token de acceso opaco para OP (Logto), y adjúntalo al encabezado Authorization como `Bearer `. Con la Account API de Logto, puedes construir un sistema personalizado de gestión de cuentas como una página de perfil totalmente integrada con Logto. -Algunos casos de uso frecuentes se listan a continuación: +Algunos casos de uso frecuentes se enumeran a continuación: - Recuperar el perfil de usuario - Actualizar el perfil de usuario @@ -28,7 +28,7 @@ Para obtener más información sobre las APIs disponibles, visita [Referencia de :::note -Las funciones de visualización de cuentas SSO y eliminación de cuentas están actualmente disponibles a través de las Management APIs de Logto. Consulta [Configuración de cuenta mediante Management API](/end-user-flows/account-settings/by-management-api) para detalles de implementación. +Las funciones de visualización de cuentas SSO y eliminación de cuentas están disponibles actualmente a través de las Management APIs de Logto. Consulta [Configuración de cuenta mediante Management API](/end-user-flows/account-settings/by-management-api) para detalles de implementación. ::: @@ -43,11 +43,11 @@ Una vez habilitada, configura los permisos por campo para identificadores, datos 1. **Campos de seguridad**: - Los campos incluyen: correo electrónico principal, teléfono principal, identidades sociales, contraseña y MFA. - Antes de que los usuarios finales editen estos campos, deben verificar su identidad mediante contraseña, correo electrónico o SMS para obtener un ID de registro de verificación válido por 10 minutos. Consulta [Obtener un ID de registro de verificación](#get-a-verification-record-id). - - Para usar claves de acceso WebAuthn para MFA, añade los dominios de tu aplicación front-end a **WebAuthn Related Origins** para que el centro de cuentas y la experiencia de inicio de sesión puedan compartir claves de acceso. Consulta [Vincular una nueva clave de acceso WebAuthn](#link-a-new-webauthn-passkey). + - Para usar claves de acceso WebAuthn para MFA, añade los dominios de tu app front-end a **WebAuthn Related Origins** para que el centro de cuentas y la experiencia de inicio de sesión puedan compartir claves de acceso. Consulta [Vincular una nueva clave de acceso WebAuthn](#link-a-new-webauthn-passkey). 2. **Campos de perfil**: - Los campos incluyen: nombre de usuario, nombre, avatar, [perfil](/user-management/user-data#profile) (otros atributos estándar de perfil) y [datos personalizados](/user-management/user-data#custom-data). - Los usuarios finales pueden editar estos campos sin verificación adicional. -3. **Secret vault**: Para conectores sociales y empresariales OIDC u OAuth, el [secret vault](/secret-vault/federated-token-set) de Logto almacena de forma segura los tokens de acceso y actualización de terceros después de la autenticación. Las aplicaciones pueden entonces llamar a APIs externas, como sincronizar eventos de Google Calendar, sin pedir a los usuarios que inicien sesión de nuevo. La recuperación de tokens estará disponible automáticamente una vez que la Account API esté habilitada. +3. **Secret vault**: Para conectores sociales y empresariales OIDC u OAuth, el [secret vault](/secret-vault/federated-token-set) de Logto almacena de forma segura los tokens de acceso y actualización de terceros tras la autenticación. Las aplicaciones pueden entonces llamar a APIs externas, como sincronizar eventos de Google Calendar, sin pedir a los usuarios que inicien sesión de nuevo. La recuperación de tokens estará disponible automáticamente una vez que la Account API esté habilitada. ## Cómo acceder a la Account API \{#how-to-access-account-api} @@ -61,7 +61,7 @@ import { type LogtoConfig, UserScope } from '@logto/js'; const config: LogtoConfig = { // ...otras opciones - // Añade los alcances apropiados que se ajusten a tus casos de uso. + // Añade los alcances apropiados según tus casos de uso. scopes: [ UserScope.Email, // Para las APIs `{POST,DELETE} /api/my-account/primary-email` UserScope.Phone, // Para las APIs `{POST,DELETE} /api/my-account/primary-phone` @@ -77,9 +77,9 @@ const config: LogtoConfig = { ### Obtener un token de acceso \{#fetch-an-access-token} -Después de configurar el SDK en tu aplicación, puedes usar el método `client.getAccessToken()` para obtener un token de acceso. Este token es un token opaco (token opaco) que puede usarse para acceder a la Account API. +Después de configurar el SDK en tu aplicación, puedes usar el método `client.getAccessToken()` para obtener un token de acceso. Este token es un token opaco que puede usarse para acceder a la Account API. -Si no estás usando el SDK oficial, debes establecer el `resource` como vacío para la solicitud de concesión de token de acceso a `/oidc/token`. +Si no estás usando el SDK oficial, debes establecer el `resource` como vacío en la solicitud de concesión de token de acceso a `/oidc/token`. ### Acceder a la Account API usando el token de acceso \{#access-account-api-using-access-token} @@ -169,7 +169,7 @@ El cuerpo de la respuesta sería así: #### Verificar enviando un código de verificación al correo electrónico o teléfono del usuario \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} :::note -Para usar este método, necesitas [configurar el conector de correo electrónico](/connectors/email-connectors/) o [conector de SMS](/connectors/sms-connectors/), y asegurarte de que la plantilla `UserPermissionValidation` esté configurada. +Para usar este método, necesitas [configurar el conector de correo electrónico](/connectors/email-connectors/) o [conector SMS](/connectors/sms-connectors/), y asegurarte de que la plantilla `UserPermissionValidation` esté configurada. ::: Tomando el correo electrónico como ejemplo, solicita un nuevo código de verificación y obtén el ID de registro de verificación: @@ -219,6 +219,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +Al igual que las contraseñas creadas durante el registro, las contraseñas establecidas mediante la Account API deben cumplir con la [política de contraseñas](/security/password-policy) que configuraste en Consola > Seguridad > Política de contraseñas. Logto devuelve resultados de validación detallados y mensajes de error si la contraseña no cumple la política. +::: + ### Actualizar o vincular un nuevo correo electrónico \{#update-or-link-new-email} :::note @@ -245,7 +249,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}' ``` -Después de verificar el código, ahora puedes llamar a [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) para actualizar el correo electrónico del usuario, estableciendo el `verificationId` en el cuerpo de la solicitud como `newIdentifierVerificationRecordId`. +Después de verificar el código, ahora puedes llamar a [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) para actualizar el correo del usuario, estableciendo el `verificationId` en el cuerpo de la solicitud como `newIdentifierVerificationRecordId`. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -255,6 +259,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +Al igual que los correos electrónicos recogidos durante el registro, cualquier correo vinculado mediante la Account API debe pasar la verificación de la [lista de bloqueo](/security/blocklist) que configuraste en Consola > Seguridad > Lista de bloqueo. Logto rechazará la solicitud y devolverá un error detallado si el correo viola la política. +::: + ### Eliminar el correo electrónico del usuario \{#remove-the-users-email} Para eliminar el correo electrónico del usuario, puedes usar el endpoint [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail). @@ -268,10 +276,10 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### Gestionar teléfono \{#manage-phone} :::note -Para usar este método, necesitas [configurar el conector de SMS](/connectors/sms-connectors/), y asegurarte de que la plantilla `BindNewIdentifier` esté configurada. +Para usar este método, necesitas [configurar el conector SMS](/connectors/sms-connectors/), y asegurarte de que la plantilla `BindNewIdentifier` esté configurada. ::: -Similar a la actualización de correo electrónico, puedes usar el endpoint [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) para actualizar o vincular un nuevo teléfono. Y usa el endpoint [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) para eliminar el teléfono del usuario. +De manera similar a la actualización de correo electrónico, puedes usar el endpoint [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) para actualizar o vincular un nuevo teléfono. Y usar el endpoint [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) para eliminar el teléfono del usuario. ### Vincular una nueva conexión social \{#link-a-new-social-connection} @@ -288,7 +296,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ - `redirectUri`: La URI de redirección después de que el usuario autorice la aplicación; debes alojar una página web en esta URL y capturar el callback. - `state`: El estado que se devolverá después de que el usuario autorice la aplicación; es una cadena aleatoria que se utiliza para prevenir ataques CSRF. -En la respuesta, encontrarás un `verificationRecordId`, guárdalo para uso posterior. +En la respuesta, encontrarás un `verificationRecordId`, guárdalo para su uso posterior. Después de que el usuario autorice la aplicación, recibirás un callback en el `redirectUri` con el parámetro `state`. Luego puedes usar el endpoint [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) para verificar la conexión social. @@ -299,7 +307,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -El `connectorData` es la información devuelta por el conector social después de que el usuario autoriza la aplicación; necesitas analizar y obtener los parámetros de consulta del `redirectUri` en tu página de callback y envolverlos como JSON en el campo `connectorData`. +El `connectorData` son los datos devueltos por el conector social después de que el usuario autoriza la aplicación; necesitas analizar y obtener los parámetros de consulta del `redirectUri` en tu página de callback y envolverlos como un JSON como valor del campo `connectorData`. Finalmente, puedes usar el endpoint [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) para vincular la conexión social. @@ -335,11 +343,11 @@ Para usar este método, necesitas habilitar el campo `mfa` en la [configuración Las claves de acceso WebAuthn están vinculadas a un hostname específico llamado **Relying Party ID (RP ID)**. Solo las aplicaciones alojadas en el origen del RP ID pueden registrar o autenticar con esas claves de acceso. -Dado que tu aplicación front-end llama a la Account API desde un dominio diferente al de las páginas de autenticación de Logto, necesitas configurar **Related Origins** para permitir operaciones de claves de acceso entre orígenes. +Dado que tu aplicación front-end llama a la Account API desde un dominio diferente al de las páginas de autenticación de Logto, necesitas configurar **Related Origins** para permitir operaciones de claves de acceso entre dominios. **Cómo determina Logto el RP ID:** -- **Configuración por defecto**: Si solo usas el dominio por defecto de Logto `https://[tenant-id].logto.app`, el RP ID es `[tenant-id].logto.app` +- **Configuración predeterminada**: Si solo usas el dominio predeterminado de Logto `https://[tenant-id].logto.app`, el RP ID es `[tenant-id].logto.app` - **Dominio personalizado**: Si has configurado un [dominio personalizado](/logto-cloud/custom-domain) como `https://auth.example.com`, el RP ID será `auth.example.com` **Configura Related Origins:** @@ -353,7 +361,17 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -Para obtener más información sobre los orígenes relacionados, consulta la documentación de [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/). +:::note + +WebAuthn admite hasta 5 etiquetas únicas eTLD+1 para Related Origins. El eTLD+1 (dominio de nivel superior efectivo más una etiqueta) es la parte registrable del dominio. Por ejemplo: + +- `https://example.com`, `https://app.example.com` y `https://auth.example.com` cuentan como **una** etiqueta (`example.com`) +- `https://shopping.com`, `https://shopping.co.uk` y `https://shopping.co.jp` también cuentan como **una** etiqueta (`shopping`) +- `https://example.com` y `https://another.com` cuentan como **dos** etiquetas + +Si necesitas admitir más de 5 dominios diferentes como Related Origins, consulta la documentación de [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) para más detalles. + +::: **Paso 2: Solicita nuevas opciones de registro** @@ -386,7 +404,7 @@ import { startRegistration } from '@simplewebauthn/browser'; const response = await startRegistration({ optionsJSON: registrationOptions, // Los datos devueltos por el servidor en el paso 1 }); -// Guarda la respuesta para usarla más adelante +// Guarda la respuesta para su uso posterior ``` **Paso 4: Verifica el registro de la clave de acceso** @@ -417,7 +435,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"WebAuthn","newIdentifierVerificationRecordId":"..."}' ``` -- `verification_record_id`: un ID de registro de verificación válido, otorgado al verificar el factor existente del usuario; puedes consultar la sección [Obtener un ID de registro de verificación](#get-a-verification-record-id) para más detalles. +- `verification_record_id`: un ID de registro de verificación válido, obtenido al verificar el factor existente del usuario; puedes consultar la sección [Obtener un ID de registro de verificación](#get-a-verification-record-id) para más detalles. - `type`: el tipo de factor MFA, actualmente solo se admite `WebAuthn`. - `newIdentifierVerificationRecordId`: el ID de registro de verificación devuelto por el servidor en el paso 1. @@ -509,7 +527,7 @@ otpauth://totp/[Issuer]:[Account]?secret=[Secret]&issuer=[Issuer] Ejemplo: ``` -otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp +otpauth://totp/TuApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=TuApp ``` **Paso 3: Vincula el factor TOTP** @@ -524,7 +542,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"Totp","secret":"..."}' ``` -- `verification_record_id`: un ID de registro de verificación válido, otorgado al verificar el factor existente del usuario. Puedes consultar la sección [Obtener un ID de registro de verificación](#get-a-verification-record-id) para más detalles. +- `verification_record_id`: un ID de registro de verificación válido, obtenido al verificar el factor existente del usuario. Puedes consultar la sección [Obtener un ID de registro de verificación](#get-a-verification-record-id) para más detalles. - `type`: debe ser `Totp`. - `secret`: el secreto TOTP generado en el paso 1. @@ -562,14 +580,14 @@ El cuerpo de la respuesta sería así: **Paso 2: Muestra los códigos de respaldo al usuario** -Antes de vincular los códigos de respaldo a la cuenta del usuario, debes mostrárselos y recomendarle que: +Antes de vincular los códigos de respaldo a la cuenta del usuario, debes mostrárselos y pedirle que: - Descargue o anote estos códigos inmediatamente - Los almacene en un lugar seguro - Entienda que cada código solo puede usarse una vez - Sepa que estos códigos son su último recurso si pierde acceso a sus métodos MFA principales -Debes mostrar los códigos en un formato claro y fácil de copiar, y considerar ofrecer una opción de descarga (por ejemplo, como archivo de texto o PDF). +Debes mostrar los códigos en un formato claro y fácil de copiar y considerar ofrecer una opción de descarga (por ejemplo, como archivo de texto o PDF). **Paso 3: Vincula los códigos de respaldo a la cuenta del usuario** @@ -583,13 +601,13 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"BackupCode","codes":["...","...","..."]}' ``` -- `verification_record_id`: un ID de registro de verificación válido, otorgado al verificar el factor existente del usuario. Puedes consultar la sección [Obtener un ID de registro de verificación](#get-a-verification-record-id) para más detalles. +- `verification_record_id`: un ID de registro de verificación válido, obtenido al verificar el factor existente del usuario. Puedes consultar la sección [Obtener un ID de registro de verificación](#get-a-verification-record-id) para más detalles. - `type`: debe ser `BackupCode`. - `codes`: el array de códigos de respaldo generados en el paso anterior. :::note -- Un usuario solo puede tener un conjunto de códigos de respaldo a la vez. Si se han usado todos los códigos, el usuario debe generar y vincular nuevos códigos. +- Un usuario solo puede tener un conjunto de códigos de respaldo a la vez. Si todos los códigos han sido usados, el usuario debe generar y vincular nuevos códigos. - Los códigos de respaldo no pueden ser el único factor MFA. El usuario debe tener al menos otro factor MFA (como WebAuthn o TOTP) habilitado. - Cada código de respaldo solo puede usarse una vez. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index a8de7632ec6..c6bb0334964 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -14,25 +14,29 @@ Un conjunto de parámetros de autenticación personalizados que te permiten adap El parámetro `first_screen` es el parámetro clave que determina la primera pantalla que los usuarios verán cuando sean redirigidos a la página de inicio de sesión de Logto. Por defecto, se mostrará el formulario universal de inicio de sesión. Utiliza este parámetro para personalizar la primera pantalla según los requisitos de tu aplicación. Los valores admitidos son: -- `sign_in`: Muestra el formulario de inicio de sesión. (Por defecto) +- `sign_in` (Predeterminado): Muestra el formulario de inicio de sesión. - `register`: Muestra el formulario de registro. - `reset_password`: Muestra el formulario de restablecimiento de contraseña. -- `single_sign_on`: Muestra el formulario de inicio de sesión de SSO empresarial. (Se solicitará una dirección de correo electrónico para determinar los proveedores de SSO habilitados) -- `identifier:sign-in`: Muestra un formulario de inicio de sesión específico por identificador. El tipo de identificador se puede especificar usando el parámetro `identifier`. Esto es útil cuando tienes habilitados varios métodos de inicio de sesión por identificador. -- `identifier:register`: Muestra un formulario de registro específico por identificador. El tipo de identificador se puede especificar usando el parámetro `identifier`. Esto es útil cuando tienes habilitados varios métodos de registro por identificador. +- `single_sign_on`: Muestra el formulario de inicio de sesión SSO empresarial. (Se solicitará una dirección de correo electrónico para determinar los proveedores de SSO habilitados) +- `identifier:sign-in`: Muestra un formulario de inicio de sesión específico por identificador. El tipo de identificador puede especificarse usando el parámetro `identifier` (opcional). Esto es útil cuando tienes habilitados varios métodos de inicio de sesión por identificador. +- `identifier:register`: Muestra un formulario de registro específico por identificador. El tipo de identificador puede especificarse usando el parámetro `identifier` (opcional). Esto es útil cuando tienes habilitados varios métodos de registro por identificador. Parámetro de la primera pantalla -Por ejemplo, enviar a los usuarios directamente al formulario de inicio de sesión de SSO empresarial: +Por ejemplo, enviar a los usuarios directamente al formulario de inicio de sesión SSO empresarial: ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +La primera pantalla seguirá la configuración establecida en Consola > Experiencia de inicio de sesión. Debes habilitar primero los métodos de autenticación requeridos y configurar la personalización de marca, los términos y políticas de privacidad, y la internacionalización (i18n). Ten en cuenta que solo las páginas de `sign-in` y `register` muestran el logotipo por defecto. +::: + ## identifier \{#identifier} -El parámetro `identifier` se utiliza para especificar los tipos de identificador que aceptará el formulario de inicio de sesión o registro. Este parámetro solo es aplicable cuando el parámetro `first_screen` está configurado como `identifier:sign-in`, `identifier:register` o `reset_password`. Los valores admitidos son: `username`, `email` y `phone`. Separa varios valores con un espacio vacío para permitir múltiples tipos de identificador. +El parámetro `identifier` se utiliza para especificar los tipos de identificador que aceptará el formulario de inicio de sesión o registro. Este parámetro solo es aplicable cuando el parámetro `first_screen` está configurado como `identifier:sign-in`, `identifier:register` o `reset_password`. Los valores admitidos son: `username`, `email` y `phone`. Separa varios valores con un espacio para permitir múltiples tipos de identificador. Por ejemplo, enviar a los usuarios directamente a la página de registro por correo electrónico o número de teléfono: @@ -56,7 +60,7 @@ curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=identifier:sign_in&identifier=email&login_hint=example@logto.io ``` -## Soporte en SDK \{#sdk-support} +## Compatibilidad con SDK \{#sdk-support} En los SDK de Logto compatibles, puedes establecer los parámetros al llamar al método `signIn`: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index 7a54cf11fa1..8c9ae55b37c 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -2,15 +2,16 @@ sidebar_position: 1 --- -# Idiomas de la interfaz de usuario (UI locales) +# Idiomas de la interfaz de usuario Logto admite el parámetro estándar de autenticación OIDC `ui_locales` para controlar el idioma de la experiencia de inicio de sesión y las comunicaciones posteriores para una interacción determinada. ## Qué hace \{#what-it-does} -- Determina el idioma de la interfaz de usuario de la experiencia de inicio de sesión alojada por Logto en tiempo de ejecución. Logto selecciona la primera etiqueta de idioma en `ui_locales` que sea compatible con la biblioteca de idiomas de tu inquilino. -- Afecta la localización de los correos electrónicos para los mensajes activados por la interacción (por ejemplo, correos electrónicos de código de verificación). Consulta [Localización de plantillas de correo electrónico](/connectors/email-connectors/email-templates#email-template-localization). +- Determina el idioma de la interfaz de usuario de la experiencia de inicio de sesión alojada por Logto en tiempo de ejecución. Logto selecciona la primera etiqueta de idioma en `ui_locales` que sea compatible con la biblioteca de idiomas de tu tenant. +- Afecta la localización de correos electrónicos para los mensajes desencadenados por la interacción (por ejemplo, correos electrónicos de código de verificación). Consulta [Localización de plantillas de correo electrónico](/connectors/email-connectors/email-templates#email-template-localization). - Expone el valor original a las plantillas de correo electrónico como una variable `uiLocales`, lo que te permite incluirlo en el asunto/contenido del correo si es necesario. +- Establece el código de país predeterminado para el número de teléfono en la experiencia de inicio de sesión. Por ejemplo, si `ui_locales=fr`, el campo de entrada del número de teléfono tendrá por defecto Francia (+33). Esto es útil cuando deseas controlar el código de país predeterminado de forma programática para grupos de usuarios o regiones específicas. ## Formato del parámetro \{#parameter-format} @@ -19,15 +20,15 @@ Logto admite el parámetro estándar de autenticación OIDC `ui_locales` para co - Valor: Lista separada por espacios de etiquetas de idioma BCP 47, por ejemplo, `fr-CA fr en`. - Referencia: [OpenID Connect Core - ui_locales](https://openid.net/specs/openid-connect-core-1_0.html) -## Orden y precedencia de resolución \{#resolution-order-and-precedence} +## Orden de resolución y precedencia \{#resolution-order-and-precedence} Al determinar el idioma de la interfaz de usuario para la experiencia de inicio de sesión y los correos electrónicos relacionados, Logto resuelve el idioma del usuario final en este orden: 1. `ui_locales` de la solicitud de autenticación actual (gana la primera etiqueta compatible). -2. De lo contrario, la cabecera `Accept-Language` (Experience APIs / User Account APIs) o `messagePayload.locale` (Management APIs como invitaciones de organización). -3. De lo contrario, el idioma predeterminado del inquilino configurado en la Experiencia de inicio de sesión. +2. De lo contrario, la cabecera `Accept-Language` (Experience APIs / User Account APIs) o `messagePayload.locale` (Management APIs como invitaciones a organizaciones). +3. De lo contrario, el idioma predeterminado del tenant configurado en la Experiencia de Inicio de Sesión. -Este comportamiento no cambia permanentemente la configuración de idioma; solo se aplica a la interacción actual. +Este comportamiento no cambia permanentemente tu configuración de idioma; solo se aplica a la interacción actual. ## Uso en SDK \{#sdk-usage} @@ -44,8 +45,8 @@ await logtoClient.signIn({ ## Ejemplos \{#examples} -- `ui_locales=fr-CA fr en` → Si `fr-CA` existe en tu biblioteca de idiomas, la interfaz de inicio de sesión se muestra en francés (Canadá); de lo contrario, recurre a `fr`, luego a `en`. -- `ui_locales=ja` pero el japonés no está habilitado → Recurre a `Accept-Language` o al idioma predeterminado del inquilino. +- `ui_locales=fr-CA fr en` → Si `fr-CA` existe en tu biblioteca de idiomas, la interfaz de inicio de sesión se muestra en francés (Canadá); de lo contrario, pasa a `fr`, luego a `en`. +- `ui_locales=ja` pero el japonés no está habilitado → Pasa a `Accept-Language` o al idioma predeterminado del tenant. ## Relacionado \{#related} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index 3809ca0ee58..b90e25da9c7 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -6,15 +6,15 @@ sidebar_position: 2 ## Configura el flujo de inicio de sesión por identificador \{#configure-the-identifier-sign-in-flow} -Como se mencionó anteriormente, se pueden recopilar varios tipos de identificadores de los usuarios a lo largo del [flujo de registro](/end-user-flows/sign-up-and-sign-in/sign-up) o [creación directa de cuentas en Logto](/user-management/manage-users#add-users). Además, los usuarios pueden ingresar y completar información adicional a medida que exploran y utilizan el producto. Esos identificadores se pueden usar para identificar de manera única a los usuarios en el sistema de Logto y permitirles autenticarse e iniciar sesión en las aplicaciones integradas con Logto. +Como se indicó anteriormente, se pueden recopilar varios tipos de identificadores de los usuarios a lo largo del [flujo de registro](/end-user-flows/sign-up-and-sign-in/sign-up) o mediante la [creación directa de cuentas en Logto](/user-management/manage-users#add-users). Además, los usuarios pueden ingresar y completar información adicional a medida que exploran y utilizan el producto. Estos identificadores pueden usarse para identificar de manera única a los usuarios en el sistema de Logto y permitir que sean autenticados e inicien sesión en las aplicaciones integradas con Logto. -Ya sea que elijas usar la página de inicio de sesión preconstruida alojada por Logto o planees [construir tu propia interfaz de inicio de sesión personalizada](/customization#custom-ui), necesitarás configurar los métodos de inicio de sesión disponibles y las configuraciones de verificación para tus usuarios finales. +Ya sea que elijas usar la página de inicio de sesión preconstruida alojada por Logto o planees [construir tu propia interfaz de inicio de sesión personalizada](/customization#custom-ui), deberás configurar los métodos de inicio de sesión disponibles y los ajustes de verificación para tus usuarios finales. ## Configura los ajustes de identificador y autenticación \{#set-up-the-identifier-and-authentication-settings} ### 1. Establece los identificadores de inicio de sesión admitidos \{#1-set-the-supported-sign-in-identifiers} -Puedes agregar múltiples identificadores admitidos desde la lista desplegable como métodos de inicio de sesión habilitados para los usuarios finales. Las opciones disponibles son: +Puedes agregar varios identificadores admitidos desde la lista desplegable como métodos de inicio de sesión habilitados para los usuarios finales. Las opciones disponibles son: - **Nombre de usuario** - **Dirección de correo electrónico** @@ -24,38 +24,39 @@ Reordenar los identificadores cambiará el orden en que se muestran en la págin ### 2. Establece los ajustes de autenticación \{#2-set-the-authentication-settings} -Para cada identificador de inicio de sesión, necesitarás configurar al menos un factor de verificación efectivo para verificar la identidad del usuario. Hay dos factores entre los que puedes elegir: +Para cada identificador de inicio de sesión, deberás configurar al menos un factor de verificación efectivo para verificar la identidad del usuario. Hay dos factores entre los que puedes elegir: - **Contraseña**: Disponible para todos los tipos de identificadores de inicio de sesión. Una vez habilitado, los usuarios deben proporcionar una contraseña para completar el proceso de inicio de sesión. -- **Código de verificación**: Disponible solo para los identificadores de **Dirección de correo electrónico** y **Número de teléfono**. Una vez habilitado, los usuarios deben ingresar un código de verificación enviado a su correo electrónico o número de teléfono para completar el proceso de inicio de sesión. +- **Código de verificación**: Disponible solo para los identificadores **Dirección de correo electrónico** y **Número de teléfono**. Una vez habilitado, los usuarios deben ingresar un código de verificación enviado a su correo electrónico o número de teléfono para completar el proceso de inicio de sesión. -Si ambos factores están habilitados, los usuarios pueden elegir cualquiera de los métodos para completar el proceso de inicio de sesión. También puedes reordenar los factores para cambiar el orden en que se muestran en la página de inicio de sesión. El primer factor se usará como el método de verificación principal para los usuarios y el segundo se mostrará como un enlace alternativo. +Si ambos factores están habilitados, los usuarios pueden elegir cualquiera de los métodos para completar el proceso de inicio de sesión. También puedes reordenar los factores para cambiar el orden en que se muestran en la página de inicio de sesión. El primer factor se usará como el método principal de verificación para los usuarios y el segundo se mostrará como un enlace alternativo. ## Experiencia de usuario del flujo de inicio de sesión por identificador \{#identifier-sign-in-flow-user-experience} La experiencia de inicio de sesión se adapta según el identificador elegido y los factores de autenticación disponibles. - **Entrada inteligente para múltiples identificadores:** - Si se habilita más de un método de inicio de sesión por identificador, la página de inicio de sesión integrada de Logto detectará automáticamente el tipo de identificador ingresado por el usuario y mostrará las opciones de verificación correspondientes. Por ejemplo, si se habilitan tanto **Dirección de correo electrónico** como **Número de teléfono**, la página de inicio de sesión detectará automáticamente el tipo de identificador ingresado por el usuario y mostrará las opciones de verificación correspondientes. Cambia a un formato de número de teléfono con código de región si se ingresan números consecutivamente o a un formato de correo electrónico cuando se usa un símbolo “@”. + Si hay más de un método de inicio de sesión por identificador habilitado, la página de inicio de sesión incorporada de Logto detectará automáticamente el tipo de identificador ingresado por el usuario y mostrará las opciones de verificación correspondientes. Por ejemplo, si están habilitados tanto **Dirección de correo electrónico** como **Número de teléfono**, la página de inicio de sesión detectará automáticamente el tipo de identificador ingresado por el usuario y mostrará las opciones de verificación correspondientes. Cambia a un formato de número de teléfono con código de región si se ingresan números consecutivos o a un formato de correo electrónico cuando se utiliza el símbolo "@". + - El código de país del número de teléfono se establece por defecto según la configuración regional del navegador del usuario; los usuarios pueden cambiarlo manualmente. Puedes usar el parámetro [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) para establecer un código de país predeterminado específico. Consulta [Idiomas localizados](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience) para más detalles. - **Factores de verificación habilitados:** - - **Solo contraseña:** Tanto el campo de identificador como el de contraseña se mostrarán en la primera pantalla. + - **Solo contraseña:** Se mostrarán los campos de identificador y contraseña en la primera pantalla. - **Solo código de verificación:** El campo de identificador aparece en la primera pantalla, seguido del campo de código de verificación en la segunda pantalla. - - **Contraseña y código de verificación:** El campo de identificador se ingresa inicialmente en la primera pantalla, seguido de pasos para ingresar la contraseña o el código de verificación en la segunda pantalla según el orden de verificación. Se proporciona un enlace de cambio para permitir a los usuarios cambiar entre los dos métodos de verificación. + - **Contraseña y código de verificación:** El campo de identificador se ingresa inicialmente en la primera pantalla, seguido de los pasos para ingresar la contraseña o el código de verificación en la segunda pantalla según el orden de verificación. Se proporciona un enlace para que los usuarios puedan cambiar entre los dos métodos de verificación. ### Ejemplos \{#examples}
-### Ejemplo 1: Dirección de correo electrónico con verificación de contraseña \{#example-1-email-address-with-password-verification} +### Ejemplo 1: Dirección de correo electrónico con verificación por contraseña \{#example-1-email-address-with-password-verification} -Agrega la **Dirección de correo electrónico** como el identificador de inicio de sesión y habilita el factor **Contraseña** para la verificación. +Agrega la **Dirección de correo electrónico** como identificador de inicio de sesión y habilita el factor **Contraseña** para la verificación. Dirección de correo electrónico con verificación de contraseña
@@ -67,43 +68,43 @@ Agrega la **Dirección de correo electrónico** como el identificador de inicio -Agrega tanto **Dirección de correo electrónico** como **Número de teléfono** como los identificadores de inicio de sesión. +Agrega tanto **Dirección de correo electrónico** como **Número de teléfono** como identificadores de inicio de sesión. Habilita los factores **Contraseña** y **Código de verificación** para ambos identificadores. Correo electrónico / Teléfono con verificación de contraseña y código de verificación -## Recopilar perfil de usuario adicional en el inicio de sesión \{#collect-additional-user-profile-on-sign-in} +## Recopila información adicional del perfil de usuario al iniciar sesión \{#collect-additional-user-profile-on-sign-in} -En el flujo de inicio de sesión de Logto, se puede activar un proceso de cumplimiento de perfil si se actualizan las configuraciones de identificador de registro. Esto asegura que todos los usuarios, incluidos los existentes, proporcionen cualquier identificador nuevo requerido. +En el flujo de inicio de sesión de Logto, se puede activar un proceso de cumplimiento de perfil si se actualizan los ajustes de identificadores de registro. Esto garantiza que todos los usuarios, incluidos los existentes, proporcionen cualquier identificador nuevo requerido. -Cuando un desarrollador agrega un nuevo identificador (como una dirección de correo electrónico), se vuelve obligatorio para todos los usuarios. Si un usuario que regresa inicia sesión con un identificador existente (como un nombre de usuario), se le pedirá que proporcione y verifique el nuevo identificador si falta en su perfil. Solo después de completar este paso podrán acceder a la aplicación, asegurando una transición fluida y consistente a los requisitos actualizados. +Cuando un desarrollador agrega un nuevo identificador (como una dirección de correo electrónico), se vuelve obligatorio para todos los usuarios. Si un usuario recurrente inicia sesión con un identificador existente (como un nombre de usuario), se le pedirá que proporcione y verifique el nuevo identificador si falta en su perfil. Solo después de completar este paso podrá acceder a la aplicación, asegurando una transición fluida y coherente a los nuevos requisitos. -Desglosando el proceso: +Desglose del proceso: -1. **Nombre de usuario** se estableció previamente como el identificador de registro con la configuración de **Crear tu contraseña** habilitada automáticamente. -2. **Dirección de correo electrónico** se establece más tarde como el identificador de registro. El identificador de **Dirección de correo electrónico** se agrega automáticamente como una opción de inicio de sesión habilitada. -3. Un usuario que regresa inicia sesión con su nombre de usuario y contraseña. +1. **Nombre de usuario** se estableció previamente como identificador de registro con la configuración **Crea tu contraseña** habilitada automáticamente. +2. Posteriormente, se establece **Dirección de correo electrónico** como identificador de registro. El identificador **Dirección de correo electrónico** se agrega automáticamente como opción de inicio de sesión habilitada. +3. Un usuario recurrente inicia sesión con su nombre de usuario y contraseña. 4. Se le solicita al usuario que proporcione y verifique una dirección de correo electrónico después de su paso inicial de inicio de sesión. ```mermaid flowchart TD - A[Visitar página de inicio de sesión] --> B[Ingresar nombre de usuario y contraseña] - B -.-> C{{¿Dirección de correo electrónico requerida y faltante?}} + A[Visitar la página de inicio de sesión] --> B[Ingresar nombre de usuario y contraseña] + B -.-> C{{¿Se requiere dirección de correo electrónico y falta?}} C -->|Sí| D[Ingresar dirección de correo electrónico] D --> E[Ingresar código de verificación] E --> F[Inicio de sesión exitoso] C --> |No| F ``` -El mismo proceso se aplica a las configuraciones de registro de **Crear tu contraseña** también. Si las configuraciones de **Crear tu contraseña** se habilitan recientemente en el flujo de registro, el factor **Contraseña** se habilitará automáticamente para todos los identificadores de inicio de sesión que elijas. Todos los usuarios que regresen sin una contraseña se les pedirá que creen una durante el proceso de inicio de sesión. +El mismo proceso se aplica también a la configuración de registro **Crea tu contraseña**. Si la configuración **Crea tu contraseña** se habilita recientemente en el flujo de registro, el factor **Contraseña** se habilitará automáticamente para todos los identificadores de inicio de sesión que elijas. Todos los usuarios recurrentes sin contraseña deberán crear una durante el proceso de inicio de sesión. :::note -Nota: Para flujos de inicio de sesión personalizados, consulta la función de [Trae tu UI](/customization/bring-your-ui/). +Nota: Para flujos de inicio de sesión personalizados, consulta la función de [Trae tu propia interfaz](/customization/bring-your-ui/). ::: ## Preguntas frecuentes \{#faqs} @@ -111,11 +112,11 @@ Nota: Para flujos de inicio de sesión personalizados, consulta la función de [
-### Experiencia de inicio de sesión autoalojada (inicio de sesión incrustado) \{#self-hosted-sign-in-experience-embedded-sign-in} +### Experiencia de inicio de sesión autohospedada (inicio de sesión embebido) \{#self-hosted-sign-in-experience-embedded-sign-in} -Logto actualmente no admite API sin interfaz para inicio de sesión y registro. Sin embargo, puedes usar nuestra función de [Trae tu UI](/customization/bring-your-ui/) para cargar tu formulario de inicio de sesión personalizado en Logto. También admitimos múltiples parámetros de inicio de sesión que puedes usar para prellenar el formulario de inicio de sesión con el identificador de usuario recopilado de tu aplicación o iniciar sesión directamente con un proveedor de SSO social o empresarial de terceros. Aprende más en [Parámetros de autenticación](/end-user-flows/authentication-parameters/). +Logto actualmente no admite API sin interfaz para inicio de sesión y registro. Sin embargo, puedes usar nuestra función [Trae tu propia interfaz](/customization/bring-your-ui/) para cargar tu formulario de inicio de sesión personalizado en Logto. También admitimos múltiples parámetros de inicio de sesión que puedes usar para rellenar previamente el formulario de inicio de sesión con el identificador de usuario recopilado desde tu aplicación o iniciar sesión directamente con un proveedor de inicio de sesión social o SSO empresarial de terceros. Obtén más información en [Parámetros de autenticación](/end-user-flows/authentication-parameters/).
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index 2a14b216c2b..8dff879ce4d 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -8,31 +8,41 @@ El registro de usuario es el primer paso para que los usuarios interactúen con Visita Consola > Experiencia de inicio de sesión > Registro e inicio de sesión para comenzar a configurar el flujo de registro por identificador. -configuración de registro +Configuración de registro ## Configura el identificador de registro \{#set-up-the-sign-up-identifier} -Para crear con éxito una nueva cuenta de usuario en Logto, los usuarios deben proporcionar al menos un **identificador** que los identifique de manera única dentro del sistema de Logto. Como primer paso, selecciona los identificadores que los usuarios deben proporcionar durante el proceso de registro. Las opciones disponibles son: +Para crear correctamente una nueva cuenta de usuario en Logto, los usuarios deben proporcionar al menos un **identificador** que los identifique de manera única dentro del sistema de Logto. Como primer paso, selecciona los identificadores que los usuarios deben proporcionar durante el proceso de registro. Las opciones disponibles son: -- **Nombre de usuario**: Un [nombre de usuario](/user-management/user-data#username) único que el usuario puede usar para iniciar sesión en la aplicación. -- **Dirección de correo electrónico**: Una [dirección de correo electrónico](/user-management/user-data#primary_email) válida que el usuario puede usar para iniciar sesión en la aplicación. -- **Número de teléfono**: Un [número de teléfono](/user-management/user-data#primary_phone) válido que el usuario puede usar para iniciar sesión en la aplicación. -- **Dirección de correo electrónico o número de teléfono**: Permite a los usuarios registrarse con una dirección de correo electrónico válida o un número de teléfono. +- **Nombre de usuario (Username)**: Un [nombre de usuario](/user-management/user-data#username) único que el usuario puede usar para iniciar sesión en la aplicación. +- **Dirección de correo electrónico (Email address)**: Una [dirección de correo electrónico](/user-management/user-data#primary_email) válida que el usuario puede usar para iniciar sesión en la aplicación. +- **Número de teléfono (Phone number)**: Un [número de teléfono](/user-management/user-data#primary_phone) válido que el usuario puede usar para iniciar sesión en la aplicación. +- **Dirección de correo electrónico o número de teléfono (Email address or phone number)**: Permite a los usuarios registrarse con una dirección de correo electrónico válida o un número de teléfono. Todos los identificadores recopilados durante el proceso de registro deben ser únicos entre los usuarios bajo el mismo tenant. Se almacenarán en el [perfil del usuario](/user-management/user-data#user-profile) y podrán usarse para iniciar sesión en las aplicaciones integradas con Logto. -Si no se seleccionan identificadores, esto aplica para los métodos de registro [solo social](/end-user-flows/sign-up-and-sign-in/social-sign-in) o [solo SSO empresarial](/end-user-flows/enterprise-sso). +Si no se seleccionan identificadores, se aplica a los métodos de registro [solo social](/end-user-flows/sign-up-and-sign-in/social-sign-in) o [solo SSO empresarial](/end-user-flows/enterprise-sso). Puedes ajustar el orden de los identificadores de registro para priorizar el que deseas que los usuarios proporcionen primero durante el registro. Este orden se refleja en el proceso de registro, donde el primer identificador aparece en la pantalla inicial de registro y el resto se recopila en los pasos siguientes. +:::tip +Para bloquear tipos específicos de direcciones de correo electrónico durante el registro (como correos desechables, subdirecciones con signos más (+), direcciones de correo específicas o dominios completos), utiliza la función de **lista de bloqueo** en la sección de Seguridad. Consulta [Lista de bloqueo](/security/blocklist) para más detalles. +::: + +:::tip +El **código de país** del número de teléfono se establece por defecto según la configuración regional del navegador del usuario. Por ejemplo, si el idioma del navegador del usuario está configurado en `fr`, el código de país predeterminado será Francia (+33). + +También puedes usar el parámetro de autenticación [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) para establecer el idioma de la experiencia de inicio de sesión, lo que también determinará el código de país predeterminado. +::: + ## Configura los ajustes de verificación de registro \{#set-up-the-sign-up-verification-settings} -Para garantizar la seguridad del registro y del futuro proceso de inicio de sesión, también debes configurar los ajustes de verificación para los identificadores que recopilas durante el registro. Las opciones disponibles son: +Para garantizar la seguridad del registro y del futuro proceso de inicio de sesión del usuario, también necesitas configurar los ajustes de verificación para los identificadores que recopilas durante el registro. Los ajustes disponibles son: -- **Crear tu contraseña:** Requiere que los usuarios creen una contraseña durante el registro que cumpla con la política de contraseñas configurada en la experiencia de inicio de sesión. Esta contraseña, junto con el identificador del usuario, sirve como credencial para iniciar sesión en la aplicación. Si configuras **Nombre de usuario** como identificador de registro, este requisito se habilita automáticamente, ya que el **Nombre de usuario** solo puede usarse con una contraseña para verificar eficazmente la identidad del usuario. La [política de contraseñas](/security/password-policy) puede personalizarse para cumplir con tus requisitos de seguridad. -- **Verificar al registrarse**: Requiere que los usuarios verifiquen su dirección de correo electrónico o número de teléfono durante el registro. Actualmente, Logto solo acepta correos electrónicos y números de teléfono verificados como identificadores. Esta opción se habilita automáticamente cuando se utiliza una **Dirección de correo electrónico** o **Número de teléfono** como identificador de registro. Los usuarios deben confirmar la propiedad ingresando un código de verificación enviado a su correo electrónico o número de teléfono durante el proceso de registro. +- **Crear tu contraseña:** Requiere que los usuarios creen una contraseña durante el registro que cumpla con la política de contraseñas configurada en los ajustes de experiencia de inicio de sesión. Esta contraseña, junto con el identificador del usuario, sirve como credencial para iniciar sesión en la aplicación. Si configuras **Nombre de usuario** como identificador de registro, este requisito se habilita automáticamente, ya que el **Nombre de usuario** solo puede usarse con una contraseña para verificar eficazmente la identidad del usuario. La [política de contraseñas](/security/password-policy) puede personalizarse para cumplir con tus requisitos de seguridad. +- **Verificar en el registro**: Requiere que los usuarios verifiquen su dirección de correo electrónico o número de teléfono durante el registro. Actualmente, Logto solo acepta correos electrónicos y números de teléfono verificados como identificadores. Esta configuración se habilita automáticamente cuando se utiliza una **Dirección de correo electrónico** o **Número de teléfono** como identificador de registro. Los usuarios deben confirmar la propiedad ingresando un código de verificación enviado a su correo electrónico o número de teléfono durante el proceso de registro. -| Identificador | Crear contraseña de usuario | Verificar al registrarse | +| Identificador | Crear contraseña de usuario | Verificar en el registro | | ------------------- | --------------------------- | ------------------------ | | Nombre de usuario | Opcional | N/A | | Dirección de correo | Opcional | Obligatorio | @@ -64,7 +74,7 @@ Selecciona **Nombre de usuario** como identificador de registro. Crear tu contra -Selecciona **Dirección de correo electrónico o número de teléfono** como identificador de registro. **Verificar al registrarse** se fuerza a estar habilitado. +Selecciona **Dirección de correo electrónico o número de teléfono** como identificador de registro. **Verificar en el registro** se fuerza a estar habilitado. -Selecciona **Dirección de correo electrónico** como identificador de registro. **Verificar al registrarse** se fuerza a estar habilitado. Habilita **Crear tu contraseña** para requerir que los usuarios creen una contraseña durante el registro. (Lo mismo aplica para el flujo de registro por número de teléfono) +Selecciona **Dirección de correo electrónico** como identificador de registro. **Verificar en el registro** se fuerza a estar habilitado. Habilita **Crear tu contraseña** para requerir que los usuarios creen una contraseña durante el registro. (Lo mismo aplica para el flujo de registro por número de teléfono) Registro por correo electrónico con verificación y creación de contraseña @@ -96,30 +106,30 @@ Selecciona **Dirección de correo electrónico** como identificador de registro. -Selecciona **Dirección de correo electrónico** y **Nombre de usuario** como identificadores de registro. **Verificar al registrarse** se fuerza a estar habilitado. Habilita **Crear tu contraseña** para requerir que los usuarios creen una contraseña durante el registro. +Selecciona **Dirección de correo electrónico** y **Nombre de usuario** como identificadores de registro. **Verificar en el registro** se fuerza a estar habilitado. Habilita **Crear tu contraseña** para requerir que los usuarios creen una contraseña durante el registro. Registro con correo electrónico y nombre de usuario, verificación y creación de contraseña ## Registro con social o SSO empresarial \{#sign-up-with-social-or-enterprise-sso} -Además de estos métodos tradicionales de registro por identificador, Logto también admite el registro sin contraseña con proveedores de identidad social y SSO empresarial, haciendo que el proceso de incorporación sea más fluido y amigable para el usuario. +Además de estos métodos tradicionales de registro por identificador, Logto también admite el registro sin contraseña con proveedores de identidad social y SSO empresarial, haciendo que el proceso de incorporación sea más fluido y fácil para el usuario. Una vez que un [conector social](/connectors/social-connectors) o un [conector SSO empresarial](/connectors/enterprise-connectors) está configurado y habilitado en Logto, los usuarios pueden registrarse fácilmente usando su identidad social o empresarial existente proporcionada por el conector. Los métodos de registro social y SSO empresarial permiten a los usuarios omitir pasos adicionales como crear una contraseña o verificar su correo electrónico o número de teléfono. Logto sincronizará automáticamente la información del usuario a través de su identidad social o empresarial verificada y la almacenará en el perfil del usuario. Consulta las secciones de [inicio de sesión social](/end-user-flows/sign-up-and-sign-in/social-sign-in/) y [SSO empresarial](/end-user-flows/enterprise-sso/) para obtener más información sobre el flujo de registro con conectores sociales y SSO empresarial. :::note -Nota: Para flujos de registro personalizados, consulta la función de [Trae tu propia UI](/customization/bring-your-ui/). +Nota: Para flujos de registro personalizados, consulta la función de [Trae tu propia interfaz (Bring your UI)](/customization/bring-your-ui/). ::: -## Recopila información adicional del usuario al registrarse \{#collect-additional-user-info-on-sign-up} +## Recopila información adicional del usuario en el registro \{#collect-additional-user-info-on-sign-up} -Para recopilar información adicional del perfil del usuario (por ejemplo, Nombre completo, Fecha de nacimiento, Nombre de la empresa) durante el registro, tienes dos opciones flexibles: +Para recopilar información adicional del perfil del usuario (por ejemplo, nombre completo, fecha de nacimiento, nombre de la empresa) durante el registro, tienes dos opciones flexibles: **Opción 1: Recopilar perfil de usuario** @@ -127,9 +137,9 @@ Agrega el paso preconstruido de Logto "Cuéntanos sobre ti" directamente en el f Configura la recopilación de perfil a través de Consola > Experiencia de inicio de sesión > Recopilar perfil de usuario para elegir entre campos de datos básicos preconfigurados o crear campos personalizados con validación flexible. Más información: [Recopilar perfil de usuario](/end-user-flows/collect-user-profile) -**Opción 2: Flujos de incorporación autogestionados** +**Opción 2: Flujos de incorporación autoalojados** -Redirige a los usuarios a tu propio flujo de incorporación personalizado después de un registro exitoso para una recopilación de datos totalmente personalizable. Este enfoque te da control total sobre la experiencia del usuario y permite procesos de incorporación complejos y de varios pasos. +Redirige a los usuarios a tu propio flujo de incorporación personalizado después del registro exitoso para una recopilación de datos totalmente personalizable. Este enfoque te da control total sobre la experiencia del usuario y permite procesos de incorporación complejos y de varios pasos. Utiliza la [Account API](/end-user-flows/account-settings/by-account-api) para gestionar los datos del perfil de usuario de forma programática. @@ -153,7 +163,7 @@ Aprende cómo implementar el [flujo de registro solo por invitación.](/end-user -Logto actualmente no admite API headless para inicio de sesión y registro. Puedes usar la función de [Trae tu propia UI](/customization/bring-your-ui/) para subir tu propio formulario de registro a Logto o usar los parámetros de inicio de sesión para enviar información del usuario desde tu sitio web a Logto. Más información sobre la población de identificadores de usuario en [Parámetros de autenticación](/end-user-flows/authentication-parameters/). +Logto actualmente no admite API headless para inicio de sesión y registro. Puedes usar la función de [Trae tu propia interfaz (Bring your UI)](/customization/bring-your-ui/) para subir tu propio formulario de registro a Logto o usar los parámetros de inicio de sesión para enviar información del usuario desde tu sitio web a Logto. Más información sobre la población de identificadores de usuario en [Parámetros de autenticación](/end-user-flows/authentication-parameters/). @@ -171,12 +181,12 @@ Suscríbete al evento webhook `User.Created` para activar un correo de bienvenid
-### Omitir la verificación de correo electrónico al registrarse \{#skip-email-verification-on-sign-up} +### Omitir la verificación de correo electrónico en el registro \{#skip-email-verification-on-sign-up} Actualmente, Logto solo admite correos electrónicos y números de teléfono verificados como identificadores. El proceso de verificación es obligatorio para garantizar la seguridad y la propiedad del identificador del usuario. -El soporte para correos electrónicos o números de teléfono no verificados está en nuestra [hoja de ruta](https://feedback.logto.io/roadmap). ¡Mantente atento a las novedades! +El soporte para correos electrónicos o números de teléfono no verificados está en nuestro [roadmap](https://feedback.logto.io/roadmap). ¡Mantente atento a las actualizaciones!
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 776c3277c98..b97e4590c17 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,5 +1,5 @@ --- -description: Consulta los parámetros clave de la aplicación para la integración de autenticación OIDC, incluidos los URIs de redirección, endpoints, tokens de actualización, cierre de sesión por canal posterior, etc. +description: Consulta los parámetros clave de la aplicación para la integración de autenticación OIDC, incluidos los URI de redirección, endpoints, tokens de actualización, cierre de sesión backchannel, etc. sidebar_position: 6 --- @@ -7,37 +7,41 @@ sidebar_position: 6 ## Introducción \{#introduction} -En Logto, una _aplicación_ se refiere a un programa de software o servicio específico que está registrado en la plataforma Logto y ha sido autorizado para acceder a la información del usuario o realizar acciones en nombre de un usuario. Las aplicaciones se utilizan para identificar la fuente de las solicitudes realizadas a la API de Logto, así como para gestionar el proceso de autenticación y autorización para los usuarios que acceden a esas aplicaciones. +En Logto, una _aplicación_ se refiere a un programa o servicio de software específico que está registrado en la plataforma Logto y ha recibido autorización para acceder a la información del usuario o realizar acciones en nombre de un usuario. Las aplicaciones se utilizan para identificar la fuente de las solicitudes realizadas a la API de Logto, así como para gestionar el proceso de autenticación y autorización para los usuarios que acceden a esas aplicaciones. -El uso de aplicaciones en la experiencia de inicio de sesión de Logto permite a los usuarios acceder y gestionar fácilmente sus aplicaciones autorizadas desde un único lugar, con un proceso de autenticación coherente y seguro. Esto ayuda a simplificar la experiencia del usuario y garantiza que solo las personas autorizadas accedan a información sensible o realicen acciones en nombre de la organización. +El uso de aplicaciones en la experiencia de inicio de sesión de Logto permite a los usuarios acceder y gestionar fácilmente sus aplicaciones autorizadas desde una sola ubicación, con un proceso de autenticación coherente y seguro. Esto ayuda a agilizar la experiencia del usuario y garantiza que solo las personas autorizadas accedan a información sensible o realicen acciones en nombre de la organización. -Las aplicaciones también se utilizan en los registros de auditoría de Logto para rastrear la actividad del usuario e identificar cualquier amenaza o violación de seguridad potencial. Al asociar acciones específicas con una aplicación particular, Logto puede proporcionar información detallada sobre cómo se accede y utiliza la información, lo que permite a las organizaciones gestionar mejor sus requisitos de seguridad y cumplimiento. +Las aplicaciones también se utilizan en los registros de auditoría de Logto para rastrear la actividad del usuario e identificar posibles amenazas o brechas de seguridad. Al asociar acciones específicas con una aplicación en particular, Logto puede proporcionar información detallada sobre cómo se accede y utiliza la información, permitiendo a las organizaciones gestionar mejor sus requisitos de seguridad y cumplimiento. Si deseas integrar tu aplicación con Logto, consulta [Integrar Logto](/integrate-logto). ## Propiedades \{#properties} ### ID de la aplicación \{#application-id} -El _ID de la aplicación_ es una clave única generada automáticamente para identificar tu aplicación en Logto, y se referencia como [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) en OAuth 2.0. +_Application ID_ es una clave única autogenerada para identificar tu aplicación en Logto, y se referencia como [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) en OAuth 2.0. ### Tipos de aplicación \{#application-types} -Una _Aplicación_ puede ser uno de los siguientes tipos de aplicación: +Una _aplicación_ puede ser uno de los siguientes tipos de aplicación: -- **Aplicación nativa** es una aplicación que se ejecuta en un entorno nativo. Por ejemplo, aplicación iOS, aplicación Android. -- **Aplicación de una sola página** es una aplicación que se ejecuta en un navegador web, que actualiza la página con los nuevos datos del servidor sin cargar páginas completas nuevas. Por ejemplo, aplicación React DOM, aplicación Vue. -- **Aplicación web tradicional** es una aplicación que renderiza y actualiza páginas solo por el servidor web. Por ejemplo, JSP, PHP. -- **Aplicación máquina a máquina (M2M)** es una aplicación que se ejecuta en un entorno de máquina para comunicación directa de servicio a servicio sin interacción del usuario. +- **Aplicación nativa** es una aplicación que se ejecuta en un entorno nativo. Ejemplo: aplicación iOS, aplicación Android. +- **Aplicación de una sola página (SPA)** es una aplicación que se ejecuta en un navegador web, que actualiza la página con nuevos datos del servidor sin cargar páginas completas nuevas. Ejemplo: aplicación React DOM, aplicación Vue. +- **Aplicación web tradicional** es una aplicación que renderiza y actualiza páginas únicamente por el servidor web. Ejemplo: JSP, PHP. +- **Aplicación máquina a máquina (M2M)** es una aplicación que se ejecuta en un entorno de máquina para la comunicación directa entre servicios sin interacción del usuario. ### Secreto de la aplicación \{#application-secret} -El _secreto de la aplicación_ es una clave utilizada para autenticar la aplicación en el sistema de autenticación, específicamente para clientes privados (aplicaciones web tradicionales y M2M) como una barrera de seguridad privada. +_Application secret_ es una clave utilizada para autenticar la aplicación en el sistema de autenticación, específicamente para clientes privados (aplicaciones web tradicionales y aplicaciones M2M) como una barrera de seguridad privada. + +:::tip +Las aplicaciones de una sola página (SPA) y las aplicaciones nativas no proporcionan secreto de aplicación. Las SPA y las aplicaciones nativas son "clientes públicos" y no pueden mantener secretos (el código del navegador o los paquetes de la aplicación son inspeccionables). En lugar de un secreto de aplicación, Logto las protege con PKCE, validación estricta de URI de redirección / CORS, tokens de acceso de corta duración y rotación de tokens de actualización. +::: ### Nombre de la aplicación \{#application-name} -El _nombre de la aplicación_ es un nombre legible por humanos de la aplicación y se mostrará en la consola de administración. +_Application name_ es el nombre legible por humanos de la aplicación y se mostrará en la consola de administración. -El _nombre de la aplicación_ es un componente importante para gestionar aplicaciones en Logto, ya que permite a los administradores identificar y rastrear fácilmente la actividad de aplicaciones individuales dentro de la plataforma. +El _nombre de la aplicación_ es un componente importante para la gestión de aplicaciones en Logto, ya que permite a los administradores identificar y rastrear fácilmente la actividad de aplicaciones individuales dentro de la plataforma. :::note Es importante tener en cuenta que el _nombre de la aplicación_ debe elegirse cuidadosamente, ya que será visible para todos los usuarios que tengan acceso a la consola de administración. Debe reflejar con precisión el propósito y la función de la aplicación, además de ser fácil de entender y reconocer. @@ -45,43 +49,42 @@ Es importante tener en cuenta que el _nombre de la aplicación_ debe elegirse cu ### Descripción \{#description} -Una breve descripción de la aplicación se mostrará en la página de detalles de la aplicación en la consola de administración. La descripción está destinada a proporcionar a los administradores información adicional sobre la aplicación, como su propósito, funcionalidad y cualquier otro detalle relevante. +Una breve descripción de la aplicación se mostrará en la página de detalles de la aplicación en la consola de administración. La descripción tiene como objetivo proporcionar a los administradores información adicional sobre la aplicación, como su propósito, funcionalidad y cualquier otro detalle relevante. -### URIs de redirección \{#redirect-uris} +### URI de redirección \{#redirect-uris} -_Los URIs de redirección_ son una lista de URIs de redirección válidos que han sido preconfigurados para una aplicación. Cuando un usuario inicia sesión en Logto e intenta acceder a la aplicación, se le redirige a uno de los URIs permitidos especificados en la configuración de la aplicación. +_Redirect URIs_ son una lista de URI de redirección válidos que se han preconfigurado para una aplicación. Cuando un usuario inicia sesión en Logto e intenta acceder a la aplicación, es redirigido a uno de los URI permitidos especificados en la configuración de la aplicación. -La lista de URIs permitidos se utiliza para validar el URI de redirección que se incluye en la solicitud de Autorización (Authorization) enviada por la aplicación a Logto durante el proceso de autenticación. Si el URI de redirección especificado en la solicitud de Autorización (Authorization) coincide con uno de los URIs permitidos en la configuración de la aplicación, el usuario es redirigido a ese URI después de una autenticación exitosa. Si el URI de redirección no está en la lista permitida, el usuario no será redirigido y el proceso de autenticación fallará. +La lista de URI permitidos se utiliza para validar el URI de redirección que se incluye en la solicitud de autorización enviada por la aplicación a Logto durante el proceso de autenticación. Si el URI de redirección especificado en la solicitud de autorización coincide con uno de los URI permitidos en la configuración de la aplicación, el usuario es redirigido a ese URI después de una autenticación exitosa. Si el URI de redirección no está en la lista permitida, el usuario no será redirigido y el proceso de autenticación fallará. :::note -Es importante asegurarse de que todos los URIs de redirección válidos se agreguen a la lista permitida para una aplicación en Logto, para garantizar que los usuarios puedan acceder exitosamente a la aplicación después de la autenticación. +Es importante asegurarse de que todos los URI de redirección válidos se agreguen a la lista permitida para una aplicación en Logto, para garantizar que los usuarios puedan acceder correctamente a la aplicación después de la autenticación. ::: -Puedes consultar el [Endpoint de redirección](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) para obtener más información. +Puedes consultar el [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) para más información. - Comprendiendo los URIs de redirección en OIDC con el flujo de código de Autorización - (Authorization) + Comprendiendo los URI de redirección en OIDC con Authorization Code Flow -### URIs de redirección después del cierre de sesión \{#post-sign-out-redirect-uris} +### URI de redirección después de cerrar sesión \{#post-sign-out-redirect-uris} -Los _URIs de redirección después del cierre de sesión_ son una lista de URIs válidos que han sido preconfigurados para una aplicación para redirigir al usuario después de que haya cerrado sesión en Logto. +_Post sign-out redirect URIs_ son una lista de URI válidos que se han preconfigurado para una aplicación para redirigir al usuario después de que haya cerrado sesión en Logto. -El uso de _URIs de redirección permitidos después del cierre de sesión_ es parte de la especificación de cierre de sesión iniciado por la parte confiable (RP-Initiated Logout) en OIDC. Esta especificación proporciona un método estandarizado para que las aplicaciones inicien una solicitud de cierre de sesión para un usuario, lo que incluye redirigir al usuario a un endpoint preconfigurado después de que haya cerrado sesión. +El uso de _Post Sign-out Redirect URIs_ permitidos para el cierre de sesión forma parte de la especificación de cierre de sesión iniciado por el RP (Relying Party Initiated) en OIDC. Esta especificación proporciona un método estandarizado para que las aplicaciones inicien una solicitud de cierre de sesión para un usuario, lo que incluye redirigir al usuario a un endpoint preconfigurado después de que haya cerrado sesión. -Cuando un usuario cierra sesión en Logto, su sesión se termina y se le redirige a uno de los URIs permitidos especificados en la configuración de la aplicación. Esto asegura que el usuario sea dirigido solo a endpoints autorizados y válidos después de haber cerrado sesión, ayudando a prevenir el acceso no autorizado y los riesgos de seguridad asociados con redirigir a los usuarios a endpoints desconocidos o no verificados. +Cuando un usuario cierra sesión en Logto, su sesión se termina y es redirigido a uno de los URI permitidos especificados en la configuración de la aplicación. Esto garantiza que el usuario solo sea dirigido a endpoints autorizados y válidos después de cerrar sesión, ayudando a prevenir accesos no autorizados y riesgos de seguridad asociados con la redirección de usuarios a endpoints desconocidos o no verificados. -Puedes consultar el [Cierre de sesión iniciado por la parte confiable](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) para obtener más información. +Puedes consultar el [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) para más información. ### Orígenes permitidos por CORS \{#cors-allowed-origins} -Los _orígenes permitidos por CORS (compartición de recursos de origen cruzado)_ son una lista de orígenes permitidos desde los cuales una aplicación puede realizar solicitudes al servicio Logto. Cualquier origen que no esté incluido en la lista permitida no podrá realizar solicitudes al servicio Logto. +_Los orígenes permitidos por CORS (Cross-origin resource sharing)_ son una lista de orígenes permitidos desde los cuales una aplicación puede realizar solicitudes al servicio Logto. Cualquier origen que no esté incluido en la lista permitida no podrá realizar solicitudes al servicio Logto. La lista de orígenes permitidos por CORS se utiliza para restringir el acceso al servicio Logto desde dominios no autorizados y para ayudar a prevenir ataques de falsificación de solicitudes entre sitios (CSRF). Al especificar los orígenes permitidos para una aplicación en Logto, el servicio puede garantizar que solo los dominios autorizados puedan realizar solicitudes al servicio. :::note -La lista de orígenes permitidos debe contener el origen donde se servirá la aplicación. Esto asegura que las solicitudes de la aplicación sean permitidas, mientras que las solicitudes de orígenes no autorizados sean bloqueadas. +La lista de orígenes permitidos debe contener el origen donde se servirá la aplicación. Esto garantiza que las solicitudes de la aplicación estén permitidas, mientras que las solicitudes de orígenes no autorizados sean bloqueadas. ::: ### Endpoint de configuración del proveedor OpenID \{#openid-provider-configuration-endpoint} @@ -90,63 +93,63 @@ El endpoint para [OpenID Connect Discovery](https://openid.net/specs/openid-conn ### Endpoint de autorización \{#authorization-endpoint} -El _Endpoint de autorización_ es un término de OIDC, y es un endpoint requerido que se utiliza para iniciar el proceso de autenticación para un usuario. Cuando un usuario intenta acceder a un recurso o aplicación protegida que ha sido registrada en la plataforma Logto, será redirigido al _Endpoint de autorización_ para autenticar su identidad y obtener autorización para acceder al recurso solicitado. +_Authorization Endpoint_ es un término de OIDC, y es un endpoint requerido que se utiliza para iniciar el proceso de autenticación para un usuario. Cuando un usuario intenta acceder a un recurso protegido o una aplicación que ha sido registrada en la plataforma Logto, será redirigido al _Authorization Endpoint_ para autenticar su identidad y obtener autorización para acceder al recurso solicitado. -Puedes consultar el [Endpoint de autorización](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) para obtener más información. +Puedes consultar el [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) para más información. ### Endpoint de token \{#token-endpoint} -El _Endpoint de token_ es un término de OIDC, es un endpoint de API web que se utiliza por un cliente OIDC para obtener un token de acceso, un token de ID o un token de actualización de un proveedor OIDC. +_Token Endpoint_ es un término de OIDC, es un endpoint de API web que utiliza un cliente OIDC para obtener un token de acceso, un token de ID o un token de actualización de un proveedor OIDC. -Cuando un cliente OIDC necesita obtener un token de acceso o un token de ID, envía una solicitud al Endpoint de token con una concesión de autorización, que generalmente es un código de autorización o un token de actualización. El Endpoint de token luego valida la concesión de autorización y emite un token de acceso o un token de ID al cliente si la concesión es válida. +Cuando un cliente OIDC necesita obtener un token de acceso o un token de ID, envía una solicitud al Token Endpoint con una concesión de autorización, que normalmente es un código de autorización o un token de actualización. El Token Endpoint valida la concesión de autorización y emite un token de acceso o un token de ID al cliente si la concesión es válida. -Puedes consultar el [Endpoint de token](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) para obtener más información. +Puedes consultar el [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) para más información. -### Endpoint de información del usuario \{#userinfo-endpoint} +### Endpoint de Userinfo \{#userinfo-endpoint} -El [Endpoint de información del usuario](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) de OpenID Connect. +El endpoint [UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) de OpenID Connect. -### Emitir siempre Token de actualización (Refresh token) \{#always-issue-refresh-token} +### Emitir siempre token de actualización \{#always-issue-refresh-token} -_Disponibilidad: Web tradicional, SPA_ +_Disponibilidad: web tradicional, SPA_ -Cuando está habilitado, Logto siempre emitirá tokens de actualización, independientemente de si `prompt=consent` se presenta en la solicitud de autenticación, ni `offline_access` se presenta en los alcances. +Cuando está habilitado, Logto siempre emitirá tokens de actualización, independientemente de si `prompt=consent` está presente en la solicitud de autenticación, o si `offline_access` está presente en los alcances. -Sin embargo, esta práctica no se recomienda a menos que sea necesario (generalmente es útil para algunas integraciones de OAuth de terceros que requieren Token de actualización (Refresh token)), ya que no es compatible con OpenID Connect y puede causar problemas potencialmente. +Sin embargo, esta práctica no se recomienda a menos que sea necesario (normalmente es útil para algunas integraciones OAuth de terceros que requieren token de actualización), ya que no es compatible con OpenID Connect y puede causar problemas. -### Rotar Token de actualización (Refresh token) \{#rotate-refresh-token} +### Rotar token de actualización \{#rotate-refresh-token} _Predeterminado: `true`_ -Cuando está habilitado, Logto emitirá un nuevo Token de actualización (Refresh token) para solicitudes de token bajo las siguientes condiciones: +Cuando está habilitado, Logto emitirá un nuevo token de actualización para solicitudes de token bajo las siguientes condiciones: -- Si el token de actualización ha sido rotado (ha prolongado su TTL emitiendo uno nuevo) durante un año; **O** -- Si el token de actualización está cerca de su tiempo de expiración (>=70% de su Tiempo de Vida (TTL) original ha pasado); **O** -- Si el cliente es un cliente público, por ejemplo, aplicación nativa o aplicación de una sola página (SPA). +- Si el token de actualización ha sido rotado (se ha prolongado su TTL emitiendo uno nuevo) durante un año; **O** +- Si el token de actualización está cerca de su tiempo de expiración (>=70% de su Tiempo de Vida (TTL) original transcurrido); **O** +- Si el cliente es un cliente público, por ejemplo, una aplicación nativa o una aplicación de una sola página (SPA). :::note -Para clientes públicos, cuando esta función está habilitada, siempre se emitirá un nuevo Token de actualización (Refresh token) cuando el cliente esté intercambiando por un nuevo Token de acceso (Access token) usando el Token de actualización (Refresh token). +Para clientes públicos, cuando esta función está habilitada, siempre se emitirá un nuevo token de actualización cuando el cliente intercambie por un nuevo token de acceso usando el token de actualización. Aunque aún puedes desactivar la función para esos clientes públicos, se recomienda encarecidamente mantenerla habilitada por razones de seguridad. ::: - Comprendiendo la rotación de Token de actualización (Refresh token) + Comprendiendo la rotación de tokens de actualización -### Tiempo de vida (TTL) del Token de actualización (Refresh token) en días \{#refresh-token-time-to-live-ttl-in-days} +### Tiempo de vida (TTL) del token de actualización en días \{#refresh-token-time-to-live-ttl-in-days} -_Disponibilidad: No SPA; Predeterminado: 14 días_ +_Disponibilidad: no SPA; Predeterminado: 14 días_ -La duración durante la cual un Token de actualización (Refresh token) puede usarse para solicitar nuevos Tokens de acceso (Access tokens) antes de que expire y se vuelva inválido. Las solicitudes de token extenderán el TTL del Token de actualización (Refresh token) a este valor. +La duración durante la cual un token de actualización puede utilizarse para solicitar nuevos tokens de acceso antes de que expire y se vuelva inválido. Las solicitudes de token extenderán el TTL del token de actualización a este valor. -Típicamente, se prefiere un valor más bajo. +Normalmente, se prefiere un valor más bajo. -Nota: La actualización del TTL no está disponible en SPA (aplicación de una sola página) por razones de seguridad. Esto significa que Logto no extenderá el TTL a través de solicitudes de token. Para mejorar la experiencia del usuario, puedes habilitar la función "Rotar token de actualización", permitiendo a Logto emitir un nuevo token de actualización cuando sea necesario. +Nota: La actualización del TTL no está disponible en SPA (aplicación de una sola página) por razones de seguridad. Esto significa que Logto no extenderá el TTL a través de solicitudes de token. Para mejorar la experiencia del usuario, puedes habilitar la función "Rotar token de actualización", permitiendo que Logto emita un nuevo token de actualización cuando sea necesario. -### URI de cierre de sesión por canal posterior \{#backchannel-logout-uri} +### URI de cierre de sesión backchannel \{#backchannel-logout-uri} -El endpoint de cierre de sesión por canal posterior de OpenID Connect. Consulta [Cierre de sesión federado: Cierre de sesión por canal posterior](#) para obtener más información. +El endpoint de cierre de sesión backchannel de OpenID Connect. Consulta [Cierre de sesión federado: Back-channel logout](#) para más información. ### Datos personalizados \{#custom-data} -Información adicional personalizada de la aplicación no listada en las propiedades predefinidas de la aplicación, los usuarios pueden definir sus propios campos de datos personalizados según sus necesidades específicas, como configuraciones y ajustes específicos del negocio. +Información adicional personalizada de la aplicación que no figura en las propiedades predefinidas de la aplicación; los usuarios pueden definir sus propios campos de datos personalizados según sus necesidades específicas, como configuraciones y ajustes específicos del negocio. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index 86b657c31bf..71392300c0f 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -1,17 +1,17 @@ --- -description: Integra la autenticación de aplicaciones y la federación de identidad en minutos con nuestras guías de inicio rápido. +description: Integra la autenticación de aplicaciones y la federación de identidades en minutos con nuestras guías de inicio rápido. sidebar_position: 1 --- # Integra Logto en tu aplicación -Sigue estos pasos para añadir autenticación a tus aplicaciones con Logto, ya sea una app orientada a usuarios o un servicio máquina a máquina: +Sigue estos pasos para añadir autenticación a tus aplicaciones con Logto, ya sea una aplicación orientada a usuarios o un servicio máquina a máquina: 1. Navega a Consola > Aplicaciones 2. Haz clic en "Crear aplicación" para añadir una nueva aplicación -3. Elige tu [framework de aplicación](/quick-starts) para comenzar. Si no encuentras tu framework, haz clic en el botón "Crear app sin framework" en la esquina inferior derecha de la página de creación de la aplicación para crear una app seleccionando un [tipo de aplicación](/integrate-logto/application-data-structure/#application-types) o presenta una solicitud de función o contribuye con un SDK siguiendo nuestras [convenciones de SDK](/developers/sdk-conventions). +3. Elige tu [framework de aplicación](/quick-starts) para comenzar. Si no encuentras tu framework, haz clic en el botón "Crear app sin framework" en la esquina inferior derecha de la página de creación de aplicaciones para crear una app seleccionando un [tipo de aplicación](/integrate-logto/application-data-structure/#application-types) o presenta una solicitud de función o contribuye con un SDK siguiendo nuestras [convenciones de SDK](/developers/sdk-conventions). 4. Después de seleccionar tu framework, verás una guía de inicio rápido para el SDK del framework. Sigue los pasos para configurar e integrar tu aplicación. Si necesitas ayuda para entender los conceptos involucrados en el proceso de integración, puedes consultar [Comprender el flujo de autenticación de Logto](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) para una comprensión más profunda de la integración. @@ -25,6 +25,21 @@ La guía en la consola es solo para un inicio rápido con Logto usando nuestro S Autorización (Authorization) Organizaciones (Organizations) +## Preguntas frecuentes \{#faqs} + +
+ + ### ¿Cómo puede mi servicio backend validar los tokens de usuario y gestionar usuarios con Logto? + +Para validar de forma segura los tokens de acceso en tu API backend (por ejemplo, Python, Node.js, Go, Java, PHP, etc.), y para gestionar usuarios de forma programática, consulta la guía: [Cómo validar tokens de acceso en tu servicio API o backend](/authorization/validate-access-tokens). + +Esta documentación cubre: + +- Cómo comprobar la validez de los tokens bearer en cada llamada a la API +- Mejores prácticas para integrar Logto con múltiples aplicaciones frontend y un servicio backend + +
+ ## Recursos relacionados \{#related-resources} @@ -36,7 +51,7 @@ La guía en la consola es solo para un inicio rápido con Logto usando nuestro S - ¿Por qué necesitamos distinguir entre estos diferentes tipos de apps al usar Logto? + ¿Por qué necesitamos distinguir entre estos diferentes tipos de aplicaciones al usar Logto? diff --git a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index add86e1cce5..9f82be492d5 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -1,5 +1,5 @@ --- -description: Usa Logto para crear tu propio Proveedor de Identidad y habilitar SSO para aplicaciones de terceros. Integra fácilmente aplicaciones OIDC / OAuth. +description: Utiliza Logto para crear tu propio Proveedor de Identidad y habilitar SSO para aplicaciones de terceros. Integra fácilmente aplicaciones OIDC / OAuth. sidebar_position: 4 --- @@ -14,16 +14,16 @@ Un Proveedor de Identidad (IdP) es un servicio que verifica las identidades de l A diferencia de las aplicaciones que creaste en la guía [Integra Logto en tu aplicación](/integrate-logto/integrate-logto-into-your-application) que son desarrolladas y totalmente controladas por ti, las aplicaciones de terceros son servicios independientes desarrollados por desarrolladores externos o socios comerciales. -Este enfoque de integración es ideal para escenarios empresariales comunes. Puedes permitir que los usuarios accedan a aplicaciones de socios usando sus cuentas de Logto, tal como los usuarios empresariales inician sesión en Slack con Google Workspace. También puedes construir una plataforma abierta donde las aplicaciones de terceros puedan añadir la funcionalidad "Iniciar sesión con Logto", similar a "Iniciar sesión con Google". +Este enfoque de integración es ideal para escenarios empresariales comunes. Puedes permitir que los usuarios accedan a aplicaciones de socios utilizando sus cuentas de Logto, al igual que los usuarios empresariales inician sesión en Slack con Google Workspace. También puedes construir una plataforma abierta donde las aplicaciones de terceros puedan añadir la funcionalidad "Iniciar sesión con Logto", similar a "Iniciar sesión con Google". Logto es un servicio de identidad construido sobre el protocolo [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), proporcionando capacidades tanto de [autenticación (Authentication)](https://auth.wiki/authentication) como de [autorización (Authorization)](https://auth.wiki/authorization). Esto hace que integrar una aplicación de terceros OIDC sea tan sencillo como una aplicación web tradicional. Así, debido a que OIDC se basa en [OAuth 2.0](https://auth.wiki/oauth-2.0) añadiendo una capa de autenticación, también puedes integrar aplicaciones de terceros utilizando el protocolo OAuth. -## Crear una aplicación de terceros en Logto \{#create-an-third-party-application-in-logto} +## Crea una aplicación de terceros en Logto \{#create-an-third-party-application-in-logto} -1. Ve a Consola > Aplicaciones -2. Selecciona "Aplicación de terceros" como el tipo de aplicación y elige uno de los siguientes protocolos de integración: +1. Ve a Consola > Aplicaciones. +2. Haz clic en el botón "Crear aplicación". Selecciona "Aplicación de terceros" como tipo de aplicación y elige uno de los siguientes protocolos de integración: - OIDC / OAuth 3. Ingresa un nombre y una descripción para tu aplicación y haz clic en el botón “Crear”. Se creará una nueva aplicación de terceros. @@ -32,28 +32,28 @@ Todas las aplicaciones de terceros creadas se catalogarán en la página de Apli ## Configura las configuraciones OIDC \{#set-up-the-oidc-configurations} :::note -Antes de configurar las opciones de OIDC, asegúrate de haber [creado una aplicación de terceros OIDC](/quick-starts/third-party-oidc). +Antes de configurar las opciones OIDC, asegúrate de haber [creado una aplicación de terceros OIDC](/quick-starts/third-party-oidc). ::: -1. Proporciona la [**URI de redirección**](/integrate-logto/application-data-structure#redirect-uris) de tu aplicación de terceros OIDC. Esta es la URL a la que la aplicación de terceros redirigirá a los usuarios después de que sean autenticados por Logto. +1. Proporciona el [**redirect URI**](/integrate-logto/application-data-structure#redirect-uris) de tu aplicación de terceros OIDC. Esta es la URL a la que la aplicación de terceros redirigirá a los usuarios después de ser autenticados por Logto. Normalmente puedes encontrar esta información en la página de configuración de conexión IdP de la aplicación de terceros. -2. Recupera el [**ID de cliente**](/integrate-logto/application-data-structure#application-id) y el [**secreto de cliente**](/integrate-logto/application-data-structure#application-secret) desde la página de detalles de la aplicación Logto e ingrésalos en la página de configuración de conexión IdP de tu proveedor de servicios. +2. Recupera el [**client ID**](/integrate-logto/application-data-structure#application-id) y el [**client secret**](/integrate-logto/application-data-structure#application-secret) desde la página de detalles de la aplicación Logto e ingrésalos en la página de configuración de conexión IdP de tu proveedor de servicios. -3. Recupera el [**endpoint de autorización**](/integrate-logto/application-data-structure#authorization-endpoint) y el [**endpoint de token**](/integrate-logto/application-data-structure#token-endpoint) desde la página de detalles de la aplicación Logto y proporciónalos a tu proveedor de servicios. - Si tu proveedor de servicios admite la detección OIDC, simplemente puedes copiar el **endpoint de descubrimiento** desde la página de detalles de la aplicación Logto y proporcionárselo a tu proveedor de servicios. El proveedor de servicios podrá recuperar automáticamente toda la información de autenticación OIDC actualizada desde el endpoint de descubrimiento. - De lo contrario, haz clic en el botón **Mostrar detalles de endpoints** para ver todos los endpoints de autenticación OIDC. +3. Recupera el [**authorization endpoint**](/integrate-logto/application-data-structure#authorization-endpoint) y el [**token endpoint**](/integrate-logto/application-data-structure#token-endpoint) desde la página de detalles de la aplicación Logto y proporciónalos a tu proveedor de servicios. + Si tu proveedor de servicios admite la detección OIDC, simplemente puedes copiar el **discovery endpoint** desde la página de detalles de la aplicación Logto y proporcionárselo a tu proveedor de servicios. El proveedor de servicios podrá recuperar automáticamente toda la información de autenticación OIDC actualizada desde el discovery endpoint. + De lo contrario, haz clic en el botón **Mostrar detalles de endpoint** para ver todos los endpoints de autenticación OIDC. ## Pantalla de consentimiento para aplicaciones de terceros OIDC \{#consent-screen-for-oidc-third-party-applications} Por razones de seguridad, todas las aplicaciones de terceros OIDC serán redirigidas a una [pantalla de consentimiento (Consent screen)](/end-user-flows/consent-screen) para la autorización del usuario después de ser autenticadas por Logto. -Todos los [permisos de perfil de usuario](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) solicitados por terceros, [alcances de recursos de API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [permisos de organización](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) e información de membresía de la organización se mostrarán en la pantalla de consentimiento. +Todos los [permisos de perfil de usuario](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) solicitados por terceros, [alcances de recursos de API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [permisos de organización](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) y la información de membresía de la organización se mostrarán en la pantalla de consentimiento. Estos permisos solicitados solo se otorgarán a las aplicaciones de terceros después de que el usuario haga clic en el botón "Autorizar".
- consent screen + pantalla de consentimiento
## Acciones adicionales \{#further-actions} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index cbc08281ca2..3d7a5b6d970 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,14 +3,15 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Servicio en la nube de Logto -[Logto Cloud](https://cloud.logto.io) ofrece una variedad de servicios de gestión y operación para ayudarte a administrar identidades y recursos de manera fluida y sencilla. Alojado por Logto, incluye funciones como [soporte multirregión](/logto-cloud/tenant-settings#tenant-region), gestión de inquilinos, [facturación y precios](/logto-cloud/billing-and-pricing), [gestión de miembros](/logto-cloud/tenant-member-management) y control de acceso basado en roles en la consola. +[Logto Cloud](https://cloud.logto.io) ofrece una variedad de servicios de gestión y operación para ayudarte a administrar identidades y recursos de manera fluida y sencilla. Alojado por Logto, incluye características como [soporte multirregional](/logto-cloud/tenant-settings#tenant-region), gestión de inquilinos, [facturación y precios](/logto-cloud/billing-and-pricing), [gestión de miembros](/logto-cloud/tenant-member-management) y control de acceso basado en roles en la consola. Si tienes alguna pregunta sobre los servicios en la nube y necesitas soporte adicional, por favor contáctanos. -## Funciones del servicio en la nube \{#features-for-cloud-service} +## Funcionalidades del servicio en la nube \{#features-for-cloud-service} , }, @@ -49,7 +50,7 @@ Si tienes alguna pregunta sobre los servicios en la nube y necesitas soporte adi label: 'Dominios personalizados', href: '/logto-cloud/custom-domain', description: - 'Utiliza tu propio dominio para tu inquilino de Logto y mantén la coherencia de la marca en tu experiencia de inicio de sesión.', + 'Utiliza tu propio dominio para tu inquilino de Logto y mantén la coherencia de la marca en la experiencia de inicio de sesión.', customProps: { icon: , }, @@ -63,5 +64,15 @@ Si tienes alguna pregunta sobre los servicios en la nube y necesitas soporte adi icon: , }, }, + { + type: 'link', + label: 'Límite del sistema', + href: '/logto-cloud/system-limit', + description: + 'Comprende los límites del sistema y la protección de tasas para inquilinos Dev, Pro y Enterprise.', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index 600050f59b0..1ae0a1b834b 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -10,13 +10,13 @@ Tu tenant de Logto viene con un dominio gratuito predeterminado `{{tenant-id}}.a Tu dominio personalizado se utiliza para varias funciones: -- URLs de [página de inicio de sesión y registro](/end-user-flows/sign-up-and-sign-in) +- URLs de la [página de inicio de sesión y registro](/end-user-flows/sign-up-and-sign-in) - URLs de vinculación de [Passkey](/end-user-flows/mfa/webauthn) (Cambiar el dominio después de que los usuarios hayan vinculado Passkeys puede bloquear su autenticación). - URIs de callback para [conectores sociales](/connectors/social-connectors) o [conectores de SSO empresarial](/connectors/enterprise-connectors). -- [Endpoint de SDK](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) para integrar Logto con tu aplicación. +- [Endpoint del SDK](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) para integrar Logto con tu aplicación. :::note -Cambiar el dominio después de publicar tu servicio puede causar problemas porque el código de tu aplicación y las integraciones podrían seguir haciendo referencia al dominio antiguo. Para asegurar una transición sin problemas, **configura tu dominio personalizado al principio** durante la creación del tenant de Producción. +Cambiar el dominio después de publicar tu servicio puede causar problemas porque el código de tu aplicación y las integraciones podrían seguir haciendo referencia al dominio antiguo. Para garantizar una transición sin problemas, **configura tu dominio personalizado al principio** durante la creación del tenant de Producción. ::: ## Configurar dominio personalizado en la Consola \{#configure-custom-domain-in-console} @@ -24,7 +24,7 @@ Cambiar el dominio después de publicar tu servicio puede causar problemas porqu Para añadir un nuevo dominio personalizado en la Consola de Logto, sigue estos pasos: 1. Navega a Consola > Configuración > Dominios. -2. En la sección "Dominio personalizado", ingresa tu nombre de dominio y haz clic en "añadir dominio". +2. En la sección "Dominio personalizado", introduce tu nombre de dominio y haz clic en "añadir dominio". Añadir dominio @@ -33,8 +33,8 @@ Para añadir un nuevo dominio personalizado en la Consola de Logto, sigue estos Procesando dominio personalizado 4. Espera la verificación y el proceso de SSL. - 1. Verificaremos automáticamente tus registros cada 10 segundos hasta que se añada el dominio personalizado. Solo asegúrate de que el nombre de dominio ingresado o los registros DNS sean correctos. - 2. La verificación normalmente toma unos minutos, pero puede tardar hasta 24 horas, dependiendo del proveedor DNS. Puedes navegar fuera durante el proceso. + 1. Verificaremos automáticamente tus registros cada 10 segundos hasta que se añada el dominio personalizado. Solo asegúrate de que el nombre de dominio introducido o los registros DNS sean correctos. + 2. La verificación suele tardar unos minutos, pero puede demorar hasta 24 horas, dependiendo del proveedor DNS. Puedes navegar fuera durante el proceso si lo deseas. ## Solución de problemas \{#troubleshooting} @@ -45,7 +45,7 @@ Para añadir un nuevo dominio personalizado en la Consola de Logto, sigue estos -Si encuentras problemas con el certificado SSL al configurar tu dominio personalizado, puede estar relacionado con los registros CAA en la configuración DNS. Los registros CAA especifican qué Autoridades Certificadoras (CAs) están autorizadas para emitir certificados para tu dominio. Si estás usando registros CAA, necesitarás autorizar tanto a "letsencrypt.org" como a "pki.goog" para que Logto pueda emitir certificados SSL. +Si encuentras problemas con el certificado SSL al configurar tu dominio personalizado, puede estar relacionado con los registros CAA en tu configuración DNS. Los registros CAA especifican qué Autoridades Certificadoras (CAs) están autorizadas para emitir certificados para tu dominio. Si estás utilizando registros CAA, deberás autorizar tanto a "letsencrypt.org" como a "pki.goog" para que Logto pueda emitir certificados SSL. Para solucionar y resolver problemas de certificados SSL relacionados con registros CAA, consulta la [documentación de Cloudflare](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) sobre registros CAA. @@ -54,13 +54,13 @@ Para solucionar y resolver problemas de certificados SSL relacionados con regist
-### Error "The hostname is associated with a held zone" \{#the-hostname-is-associated-with-a-held-zone-error} +### Error "El nombre de host está asociado a una zona retenida" \{#the-hostname-is-associated-with-a-held-zone-error} -Si encuentras el mensaje de error "The hostname is associated with a held zone, please contact the owner to have the hold removed" al añadir un dominio personalizado, significa que el dominio ya está en una zona de Cloudflare y está configurado en estado "Zone Hold". Consulta esta [documentación de Cloudflare](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/) para más información. +Si encuentras el mensaje de error "El nombre de host está asociado a una zona retenida, por favor contacta al propietario para que elimine la retención" al añadir un dominio personalizado, significa que el dominio ya está en la zona de Cloudflare y está configurado con el estado "Zone Hold". Consulta esta [documentación de Cloudflare](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/) para más información. -Para resolver este problema, deberás liberar el "zone hold". Sigue el enlace anterior para obtener instrucciones sobre cómo liberar el "zone hold" en Cloudflare. +Para resolver este problema, deberás liberar la retención de la zona. Sigue el enlace anterior para obtener instrucciones sobre cómo liberar la retención de zona en Cloudflare.
@@ -75,6 +75,37 @@ Si tu dominio está alojado en Cloudflare, desactiva el proxy de Cloudflare para +
+ + +### Error "Redirect URI does not match" después de configurar el dominio personalizado \{#redirect-uri-mismatch} + + + +Si recibes un error "redirect URI does not match" después de añadir tu dominio personalizado, necesitas actualizar la configuración de tu SDK para usar el dominio personalizado como endpoint. + +**Sobre el "dominio principal":** + +No existe una configuración separada de "dominio principal" en Logto. Después de añadir un dominio personalizado, tanto tu dominio personalizado como el dominio predeterminado `{tenant-id}.logto.app` siguen siendo válidos. El dominio que configures en el parámetro `endpoint` de tu SDK determina qué dominio se utilizará para los flujos de autenticación. + +**Solución:** + +Actualiza el parámetro `endpoint` en la inicialización de tu SDK para usar tu dominio personalizado: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // Usa tu dominio personalizado + appId: 'your-app-id', + // ... otras opciones +}); +``` + +Verifica también que los URIs de redirección registrados en Consola → Aplicaciones coincidan con el dominio que estás utilizando. + +**Nota:** Logto aprovisiona y gestiona automáticamente los certificados SSL para tu dominio personalizado. No necesitas configurar tus propios certificados. + +
+ ## Usar dominio personalizado \{#use-custom-domain} Una vez que hayas configurado tus ajustes, tanto tu nombre de dominio personalizado como el nombre de dominio predeterminado de Logto estarán disponibles para tu tenant. Sin embargo, se requieren ciertas configuraciones para activar tu nombre de dominio personalizado. @@ -98,7 +129,7 @@ const client = new LogtoClient({ ### Modificar los endpoints de autenticación para otras aplicaciones \{#modifying-auth-endpoints-for-other-applications} -Si tienes aplicaciones que no usan el SDK de Logto, es necesario actualizar sus endpoints de autenticación. +Si tienes aplicaciones que no utilizan el SDK de Logto, es necesario actualizar sus endpoints de autenticación. Puedes encontrar los endpoints de autenticación en la URL well-known: @@ -108,6 +139,6 @@ https://auth.example.com/oidc/.well-known/openid-configuration ### Actualizar el URI de callback del conector social \{#updating-the-social-connectors-callback-uri} -El URI de callback del conector social se actualizará automáticamente si tus usuarios están usando el dominio personalizado. Debes ir a la consola de desarrollador del proveedor social para actualizar el URI de callback. +El URI de callback del conector social se actualizará automáticamente si tus usuarios están utilizando el dominio personalizado. Debes ir a la consola de desarrollador del proveedor social para actualizar el URI de callback. -Cuando tus usuarios estén usando el dominio personalizado, el URI de callback del conector social utilizará el nuevo dominio. Por lo tanto, debes navegar a la consola de desarrollador del proveedor social para actualizar manualmente el URI de callback. +Cuando tus usuarios estén utilizando el dominio personalizado, el URI de callback del conector social usará el nuevo dominio. Por lo tanto, debes navegar a la consola de desarrollador del proveedor social para actualizar manualmente el URI de callback. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..51096ceaa21 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# Límite del sistema + +En Logto, hemos establecido límites generosos en todos los planes y ofrecemos opciones flexibles de pago por uso, para que los usuarios solo paguen por lo que realmente utilizan. + +Puede que notes que algunos elementos en la página de precios están marcados como _ilimitados_ o como _pago por uso continuo sin tope_. Esto significa que generalmente pueden usarse sin restricción, pero Logto se reserva el derecho de ajustar estos límites reales con el tiempo para mantener un uso justo para todos los usuarios. En otras palabras, los límites de entidad son topes estrictos que protegen la salud general de la plataforma. No forman parte de los precios, aunque pueden variar entre diferentes grupos de planes. + +Si tu caso de uso es razonable pero alcanza un límite del sistema, no dudes en contactarnos y compartir tus comentarios. Esto nos ayuda a comprender mejor los patrones de uso en el mundo real y ajustar los límites del sistema para apoyar mejor a nuestros clientes leales. + +## Protección de límite de velocidad a nivel de tenant \{#tenant-level-rate-limit-protection} + +### Tenants de desarrollo \{#dev-tenants} + +Para los tenants de desarrollo, los usuarios pueden aprovechar las funciones y ofertas gratuitas de Logto. Para prevenir abusos y establecer expectativas claras, definimos ciertos límites del sistema. Estos límites nos ayudan a gestionar nuestra plataforma de manera sostenible mientras seguimos proporcionando acceso gratuito para pruebas y desarrollo. + +Si deseas aumentar tu cuota, puedes contactarnos para recibir asistencia. También recomendamos actualizar de **Dev** a **Pro**, lo que elimina el límite y te da acceso completo de inmediato. + +| **Funcionalidad** | **Límite de entidad** | +| ---------------------------------------- | --------------------- | +| **Tokens incluidos** | 50k por mes | +| **Aplicaciones** | | +| Total de aplicaciones | 100 | +| Aplicaciones máquina a máquina | 100 | +| Aplicaciones de terceros | 100 | +| **Recursos de API (API resources)** | | +| Cantidad de recursos | 100 | +| **Autenticación de usuario** | | +| Conector social | 100 | +| SSO empresarial | 100 | +| **Gestión de usuarios** | | +| Roles de usuario | 100 | +| Roles máquina a máquina | 100 | +| Permisos por rol | 100 | +| **Organizaciones (Organizations)** | | +| Cantidad de organizaciones | 5,000 | +| Usuarios por organización | 100k | +| Roles de usuario por organización | 1,000 | +| Roles máquina a máquina por organización | 100 | +| Permisos de la organización | 1,000 | +| **Desarrolladores y plataforma** | | +| Webhooks | 10 | +| Retención de registro de auditoría | 14 días | +| Miembros del tenant | 20 | + +### Tenant Pro \{#pro-tenant} + +Para los tenants Pro, los límites de entidad definen el tope máximo para complementos y otras entidades "ilimitadas" como las aplicaciones. Los detalles de los límites del sistema del plan Pro se enumeran a continuación. + +| **Funcionalidad** | **Límite de entidad** | +| ---------------------------------------- | --------------------- | +| **Tokens incluidos** | 10M por mes | +| **Aplicaciones** | | +| Total de aplicaciones | 100 | +| Aplicaciones máquina a máquina | 100 | +| Aplicaciones OIDC/OAuth de terceros | 100 | +| Aplicaciones SAML | 100 | +| **Recursos de API (API resources)** | | +| Cantidad de recursos | 1,000 | +| Permisos por recurso | 1,000 | +| **Autenticación de usuario** | | +| Conectores sociales | 100 | +| SSO empresarial | 100 | +| **Gestión de usuarios** | | +| Roles de usuario | 1,000 | +| Roles máquina a máquina | 100 | +| **Organizaciones (Organizations)** | | +| Cantidad de organizaciones | 100k | +| Usuarios por organización | 100k | +| Roles de usuario por organización | 1,000 | +| Roles máquina a máquina por organización | 100 | +| Permisos de la organización | 1,000 | +| **Desarrolladores y plataforma** | | +| Webhooks | 10 | +| Retención de registro de auditoría | 14 días | +| Dominios personalizados | 10 | +| Miembros del tenant | 100 | + +### Enterprise \{#enterprise} + +Para los planes Enterprise, los límites y funcionalidades son totalmente personalizables y se gestionan a través del contrato. Por favor, [contáctanos](https://logto.io/contact) para más detalles. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index 10d72270755..7051f97edd0 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -36,7 +36,7 @@ Cuando creas un tenant, puedes elegir la región donde se almacenarán los datos Normalmente, deberías elegir la región más cercana a tus clientes para minimizar la latencia y mejorar el rendimiento. -Logto aprovecha la red global edge para ofrecer el mejor rendimiento y disponibilidad para tus aplicaciones. El enrutamiento de solicitudes está optimizado para garantizar que tus usuarios siempre estén conectados con la mejor opción disponible. +Logto aprovecha la red global edge para ofrecer el mejor rendimiento y disponibilidad para tus aplicaciones. El enrutamiento de solicitudes está optimizado para garantizar que tus usuarios siempre estén conectados con la opción de mejor rendimiento. :::note ¿Buscas otra región? [Ponte en contacto con nosotros](https://logto.io/contact) para: @@ -53,14 +53,14 @@ Puedes elegir el tipo de tenant durante la creación. Cuando estés listo para p - **Crear un nuevo tenant de Producción** Configura un tenant de producción desde cero. Esto es ideal si deseas mantener separados los entornos de desarrollo y producción. -- **Convertir tu tenant Dev actual en Producción** +- **Convertir tu tenant Dev actual a Producción** Si prefieres no rehacer la configuración ni migrar usuarios, puedes actualizar tu tenant de Desarrollo existente a un tenant de Producción de pago. - **Convertir a un plan Pro**: Ve a Consola > Configuración del tenant > Configuración, luego haz clic en "Convertir" para actualizar por autoservicio. Cualquier función de pago que hayas usado en el tenant dev se trasladará al checkout de Stripe. - **Convertir a un plan Enterprise**: [Contáctanos](https://logto.io/contact) y te ayudaremos a completar la actualización. :::note - Una vez convertido, el tenant no puede volver a un entorno Dev; por favor, confirma que estás listo antes de proceder. + Una vez convertido, el tenant no puede volver a un entorno Dev; por favor, confirma que estás listo antes de continuar. ::: ### Desarrollo \{#development} @@ -71,48 +71,22 @@ Sin embargo, existen ciertas limitaciones que se aplican a los tenants de desarr - El tenant dev eliminará automáticamente usuarios después de 90 días. Consulta la [política de retención de datos del tenant Dev](./dev-tenant-data-retention) para más detalles. - Aparece un banner durante la experiencia de inicio de sesión, indicando que el tenant está en modo desarrollo. -- Los tenants de desarrollo pueden tener límites de cuota en funciones específicas. Estos límites se explican en la página de detalles de la función, si corresponde. -- Logto puede actualizar los límites de cuota del tenant de desarrollo, y trataremos de notificarte con antelación. - -| Función | Límite de entidad | -| ---------------------------------- | ----------------- | -| **Tokens incluidos** | 50k por mes | -| **Aplicaciones** | | -| Aplicaciones totales | 100 | -| Aplicaciones máquina a máquina | 100 | -| Aplicaciones de terceros | 100 | -| **Recursos de API** | | -| Cantidad de recursos | 100 | -| **Autenticación de usuario** | | -| Conector social | 100 | -| SSO empresarial | 100 | -| **Gestión de usuarios** | | -| Roles de usuario | 100 | -| Roles máquina a máquina | 100 | -| Permisos por rol | 100 | -| **Organizaciones** | | -| Cantidad de organizaciones | 5,000 | -| Usuarios por organización | 5,000 | -| Roles de organización | 100 | -| Permisos de organización | 100 | -| **Desarrolladores y plataforma** | | -| Webhooks | 10 | -| Retención de registro de auditoría | 14 días | -| Miembros del tenant | 20 | +- Los tenants de desarrollo pueden tener límites de cuota en funciones específicas. Estos límites se explican en la página de detalles de la función, si corresponde. Para una lista completa de limitaciones del plan Dev, consulta la página de [Límite del sistema](./system-limit). +- Logto puede actualizar los límites de cuota del tenant de desarrollo, y haremos todo lo posible por notificarte con antelación. ### Producción \{#production} -El tenant de producción es donde los usuarios finales acceden a la aplicación en vivo y es posible que necesites una [suscripción de pago](https://logto.io/pricing). Puedes suscribirte al plan Free o Pro para crear un tenant de producción. Si te suscribes al plan Free, solo puedes crear hasta 10 tenants. +El tenant de producción es donde los usuarios finales acceden a la aplicación en vivo y es posible que necesites una [suscripción de pago](https://logto.io/pricing). Puedes suscribirte al plan Free o al plan Pro para crear un tenant de producción. Si te suscribes al plan Free, solo puedes crear hasta 10 tenants. ## Habilitar MFA \{#enable-mfa} -Mejora la seguridad de tu espacio de trabajo exigiendo la Autenticación Multifactor (MFA) para todos los miembros de tu tenant Logto Pro / Enterprise. +Mejora la seguridad de tu espacio de trabajo exigiendo la Autenticación Multifactor (MFA) para todos los miembros de tu tenant Logto Pro/Enterprise. Como el autoservicio aún no está disponible, por favor [contáctanos](https://logto.io/contact) para habilitar esta función. ## Habilitar SSO empresarial \{#enable-enterprise-sso} -Logto Cloud admite la integración de inicio de sesión único empresarial para tenants del Plan Enterprise, incluyendo proveedores como Google Workspace, Okta, Azure AD y más. +Logto Cloud admite la integración de inicio de sesión único empresarial (Enterprise SSO) para tenants del Plan Enterprise, incluidos proveedores como Google Workspace, Okta, Azure AD y más. Para comenzar, por favor [contáctanos](https://logto.io/contact). Te ayudaremos a configurarlo rápidamente. @@ -120,9 +94,9 @@ Para comenzar, por favor [contáctanos](https://logto.io/contact). Te ayudaremos Un administrador puede [invitar miembros adicionales](/logto-cloud/tenant-member-management) a este tenant. -Si hay al menos otro **admin** (rol), o si eres un **colaborador** (rol), puedes elegir abandonar el tenant. Después de salir, todos los recursos del tenant permanecerán, pero ya no tendrás acceso a ellos. +Si hay al menos otro **admin** (rol), o si eres un **colaborador** (rol), puedes optar por abandonar el tenant. Después de salir, todos los recursos del tenant permanecerán, pero ya no tendrás acceso a ellos. -Si eres el último administrador, debes asignar a otro colaborador como administrador antes de poder salir. +Si eres el último admin, debes asignar a otro colaborador como admin antes de poder salir. ## Eliminar tenant \{#delete-tenant} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/es/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index ba60476c203..9350754640b 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -1,5 +1,5 @@ --- -description: Guías de inicio rápido para la inicialización del servicio de código abierto (OSS) de Logto. +description: Guías de inicio rápido para la inicialización del servicio Logto open-source (OSS). sidebar_position: 1 --- @@ -17,12 +17,12 @@ import Tabs from '@theme/Tabs'; ## GitPod \{#gitpod} -Para iniciar un espacio de trabajo en línea de GitPod para Logto, haz clic aquí. Espera unos momentos, verás un mensaje como: +Para iniciar un espacio de trabajo en línea de GitPod para Logto, haz clic aquí. Espera unos momentos y verás un mensaje como:

Gitpod está en funcionamiento @@ -30,7 +30,7 @@ Para iniciar un espacio de trabajo en línea de GitPod para Logto, -Docker Compose CLI generalmente viene con [Docker Desktop](https://www.docker.com/products/docker-desktop). +La CLI de Docker Compose normalmente viene con [Docker Desktop](https://www.docker.com/products/docker-desktop). :::caution -¡No uses nuestro comando de docker compose para producción! Dado que actualmente tenemos una base de datos Postgres integrada junto con la aplicación Logto en `docker-compose.yml`, cada vez que vuelvas a ejecutar el comando se creará una nueva instancia de base de datos, y cualquier dato persistido previamente se perderá. +¡No uses nuestro comando docker compose para producción! Ya que actualmente tenemos una base de datos Postgres integrada junto con la app Logto en `docker-compose.yml`, +cada vez que vuelvas a ejecutar el comando se creará una nueva instancia de base de datos y se perderán todos los datos persistidos previamente. ::: ```bash @@ -62,7 +63,7 @@ Después de una composición exitosa, verás un mensaje como:

Paso 1

-Prepara una instancia de [PostgreSQL](https://www.postgresql.org/)@^14.0, y usa [Logto CLI](/logto-oss/using-cli) para sembrar una base de datos para Logto: +Prepara una instancia de [PostgreSQL](https://www.postgresql.org/)@^14.0 y utiliza la [CLI de Logto](/logto-oss/using-cli) para sembrar una base de datos para Logto: @@ -96,12 +97,12 @@ docker pull svhd/logto:latest

Paso 3

-Mapea los puertos del contenedor al núcleo de Logto y la aplicación de administración, por ejemplo, `3001:3001` y `3002:3002`; y establece las siguientes variables de entorno en el contenedor: +Mapea los puertos del contenedor al núcleo de Logto y la app de administración, por ejemplo, `3001:3001` y `3002:3002`; y establece las siguientes variables de entorno en el contenedor: ```yml -TRUST_PROXY_HEADER: 1 # Establece en 1 si tienes un proxy HTTPS (por ejemplo, Nginx) frente a Logto -ENDPOINT: https:// # (Opcional) Reemplaza con tu URL de endpoint de Logto si estás usando un dominio personalizado -ADMIN_ENDPOINT: https:// # (Opcional) Reemplaza con tu URL de administración de Logto si estás usando un dominio personalizado +TRUST_PROXY_HEADER: 1 # Establece en 1 si tienes un proxy HTTPS (por ejemplo, Nginx) delante de Logto +ENDPOINT: https:// # (Opcional) Reemplaza con la URL de tu endpoint Logto si usas un dominio personalizado +ADMIN_ENDPOINT: https:// # (Opcional) Reemplaza con la URL de administración de Logto si usas un dominio personalizado DB_URL: postgres://username:password@your_postgres_url:port/db_name # Reemplaza con tu DSN de Postgres ``` @@ -121,7 +122,7 @@ docker run \ :::tip -- Si estás usando Docker Hub, usa `svhd/logto:latest` en lugar de `ghcr.io/logto-io/logto:latest`. +- Si usas Docker Hub, utiliza `svhd/logto:latest` en lugar de `ghcr.io/logto-io/logto:latest`. - Usa `host.docker.internal` o `172.17.0.1` en `DB_URL` para referirte a la IP del host. ::: @@ -132,16 +133,16 @@ Finalmente, verás un mensaje como: -**Requisitos previos** +**Prerrequisitos** - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -Las versiones superiores generalmente funcionan pero no están garantizadas. +Las versiones superiores suelen funcionar pero no están garantizadas. -Recomendamos usar una nueva base de datos vacía dedicada a Logto, aunque no es un requisito estricto. +Recomendamos usar una base de datos nueva y vacía dedicada para Logto, aunque no es un requisito estricto. -**Descargar e iniciar** +**Descarga e inicia** En tu terminal: @@ -149,36 +150,36 @@ En tu terminal: npm init @logto@latest ``` -Una vez que completes el proceso de inicialización y comiences Logto, verás un mensaje como: +Una vez completes el proceso de inicialización e inicies Logto, verás un mensaje como:
```text -La aplicación principal se está ejecutando en http://localhost:3001 -La aplicación principal se está ejecutando en https://your-domain-url -La aplicación de administración se está ejecutando en http://localhost:3002 -La aplicación de administración se está ejecutando en https://your-admin-domain-url +La app principal se está ejecutando en http://localhost:3001 +La app principal se está ejecutando en https://your-domain-url +La app de administración se está ejecutando en http://localhost:3002 +La app de administración se está ejecutando en https://your-admin-domain-url ``` -Dirígete a `http://localhost:3002/` para continuar tu viaje con Logto. ¡Disfruta! +Dirígete a `http://localhost:3002/` para continuar tu experiencia con Logto. ¡Disfruta!
-### Usar una URL alternativa para descargar \{#using-an-alternative-url-for-downloading} +### Usar una URL alternativa para la descarga \{#using-an-alternative-url-for-downloading} -Si deseas especificar una URL para el archivo zip de Logto, usa la opción `--download-url`. Por ejemplo: +Si deseas especificar una URL para el archivo zip de Logto, utiliza la opción `--download-url`. Por ejemplo: ``` npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -Ten en cuenta que se necesita el `--` extra para que NPM pase los argumentos. +Ten en cuenta que el `--` extra es necesario para que NPM pase los argumentos.
@@ -196,9 +197,9 @@ Logto utiliza variables de entorno para la configuración, junto con soporte par _Consulta [Servicio principal](/concepts/core-service) si deseas controles más avanzados o acceso programático a Logto._ -## Proveedores de alojamiento \{#hosting-providers} +## Proveedores de hosting \{#hosting-providers} -Estos proveedores de alojamiento confiables ofrecen plantillas de instalación con un solo clic para Logto. Con servicios fácilmente desplegables, puedes configurar y lanzar tu sistema CIAM usando Logto en segundos. +Estos proveedores de hosting confiables ofrecen plantillas de instalación con un solo clic para Logto. Con servicios fácilmente desplegables, puedes configurar y lanzar tu sistema CIAM usando Logto en segundos. , }, @@ -217,7 +218,7 @@ Estos proveedores de alojamiento confiables ofrecen plantillas de instalación c label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', description: - 'Una alternativa auto-hospedable a Heroku/Netlify para una fácil gestión de aplicaciones y bases de datos.', + 'Una alternativa autoalojable a Heroku/Netlify para una gestión sencilla de apps y bases de datos.', customProps: { icon: , }, @@ -226,7 +227,7 @@ Estos proveedores de alojamiento confiables ofrecen plantillas de instalación c type: 'link', label: 'Dokploy', href: 'https://docs.dokploy.com/docs/core', - description: 'Herramienta ligera para desplegar aplicaciones en tu propia infraestructura.', + description: 'Herramienta ligera para desplegar apps en tu propia infraestructura.', customProps: { icon: , }, @@ -245,7 +246,7 @@ Estos proveedores de alojamiento confiables ofrecen plantillas de instalación c label: 'Elestio', href: 'https://elest.io/open-source/logto', description: - 'Plataforma DevOps totalmente gestionada para desplegar tu código y software de código abierto.', + 'Plataforma DevOps totalmente gestionada para desplegar tu código y software open-source.', customProps: { icon: , }, @@ -254,7 +255,7 @@ Estos proveedores de alojamiento confiables ofrecen plantillas de instalación c type: 'link', label: 'Railway', href: 'https://railway.com/template/07_f_Z', - description: 'Simplifica el despliegue de aplicaciones y la gestión de infraestructura.', + description: 'Simplifica el despliegue de apps y la gestión de infraestructura.', customProps: { icon: , }, @@ -263,8 +264,7 @@ Estos proveedores de alojamiento confiables ofrecen plantillas de instalación c type: 'link', label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', - description: - 'Simplifica el despliegue, escalado y monitoreo de aplicaciones para desarrolladores.', + description: 'Simplifica el despliegue, escalado y monitoreo de apps para desarrolladores.', customProps: { icon: , }, @@ -272,12 +272,16 @@ Estos proveedores de alojamiento confiables ofrecen plantillas de instalación c ]} /> -Ten en cuenta que no proporcionamos soporte al cliente para proveedores de servicios de terceros. Para acceder a nuestros canales de soporte, despliega en [Logto Cloud](https://cloud.logto.io). ¡Gracias! +Ten en cuenta que no proporcionamos soporte al cliente para proveedores de servicios de terceros. Para acceder a nuestros canales de soporte, por favor despliega en [Logto Cloud](https://cloud.logto.io). ¡Gracias! ## Crear una cuenta \{#create-an-account} -Una vez que hayas alojado exitosamente Logto en tu servidor, haz clic en "Crear cuenta" en la página de bienvenida. Ten en cuenta que la versión de código abierto de Logto solo permite la creación de una cuenta durante el lanzamiento inicial y no admite múltiples cuentas. El proceso de creación de cuentas se limita a combinaciones de nombre de usuario y contraseña. +Una vez que hayas alojado Logto con éxito en tu servidor, haz clic en "Crear cuenta" en la página de bienvenida. Ten en cuenta que la versión open-source de Logto solo permite la creación de una cuenta durante el lanzamiento inicial y no admite múltiples cuentas. El proceso de creación de cuenta está limitado a combinaciones de nombre de usuario y contraseña. + +:::tip +Logto OSS (autoalojado) no admite la configuración de múltiples administradores. Para colaboración en equipo y proyectos que requieran varios usuarios administradores, recomendamos usar [Logto Cloud](https://cloud.logto.io), que proporciona funciones completas de gestión de equipos. +::: ## Recursos relacionados \{#related-resources} -Tratando con el desarrollo local de HTTPS +Trabajando con desarrollo HTTPS local diff --git a/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index efee85cfdb2..f04583f2878 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot es un framework web para Java que permite a los desarrolladores construir aplicaciones de servidor seguras, rápidas y escalables con el lenguaje de programación Java. + description: Spring Boot es un framework web para Java que permite a los desarrolladores crear aplicaciones de servidor seguras, rápidas y escalables con el lenguaje de programación Java. logoFilename: 'spring-boot.svg' --- @@ -14,28 +14,28 @@ import SignInFlowSummary from '../../fragments/_web-sign-in-flow-summary.mdx'; import ScopesAndClaims from './_scopes-and-claims.mdx'; -# Añade autenticación a tu aplicación Java Spring Boot +# Añade autenticación a tu aplicación Java Spring Boot (Add authentication to your Java Spring Boot application) Esta guía te mostrará cómo integrar Logto en tu aplicación Java Spring Boot. :::tip - Puedes encontrar el código de ejemplo para esta guía en nuestro repositorio de github [spring-boot-sample](https://github.com/logto-io/spring-boot-sample). -- No se requiere un SDK oficial para integrar Logto con tu aplicación Java Spring Boot. Usaremos las bibliotecas [Spring Security](https://spring.io/projects/spring-security) y [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para manejar el flujo de autenticación OIDC con Logto. +- No se requiere un SDK oficial para integrar Logto con tu aplicación Java Spring Boot. Usaremos las librerías [Spring Security](https://spring.io/projects/spring-security) y [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para manejar el flujo de autenticación OIDC con Logto. ::: -## Prerrequisitos \{#prerequisites} +## Requisitos previos \{#prerequisites} - Una cuenta de [Logto Cloud](https://cloud.logto.io) o un [Logto autoalojado](/introduction/set-up-logto-oss). -- Nuestro código de ejemplo fue creado usando el [securing web starter](https://spring.io/guides/gs/securing-web) de Spring Boot. Sigue las instrucciones para iniciar una nueva aplicación web si no tienes una. -- En esta guía, usaremos las bibliotecas [Spring Security](https://spring.io/projects/spring-security) y [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para manejar el flujo de autenticación OIDC con Logto. Asegúrate de revisar la documentación oficial para entender los conceptos. +- Nuestro código de ejemplo fue creado usando el [securing web starter](https://spring.io/guides/gs/securing-web) de Spring Boot. Sigue las instrucciones para crear una nueva aplicación web si aún no tienes una. +- En esta guía, usaremos las librerías [Spring Security](https://spring.io/projects/spring-security) y [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para manejar el flujo de autenticación OIDC con Logto. Por favor, revisa la documentación oficial para comprender los conceptos. ## Configura tu aplicación Java Spring Boot \{#configure-your-java-spring-boot-application} ### Añadiendo dependencias \{#adding-dependencies} -Para los usuarios de [gradle](https://spring.io/guides/gs/gradle), añade las siguientes dependencias a tu archivo `build.gradle`: +Para usuarios de [gradle](https://spring.io/guides/gs/gradle), añade las siguientes dependencias a tu archivo `build.gradle`: ```groovy title="build.gradle" dependencies { @@ -46,7 +46,7 @@ dependencies { } ``` -Para los usuarios de [maven](https://spring.io/guides/gs/maven), añade las siguientes dependencias a tu archivo `pom.xml`: +Para usuarios de [maven](https://spring.io/guides/gs/maven), añade las siguientes dependencias a tu archivo `pom.xml`: ```xml title="pom.xml" @@ -67,9 +67,9 @@ Para los usuarios de [maven](https://spring.io/guides/gs/maven), añade las sigu ``` -### Configuración del Cliente OAuth2 \{#oauth2-client-configuration} +### Configuración del cliente OAuth2 \{#oauth2-client-configuration} -Registra una nueva aplicación `Java Spring Boot` en Logto Console y obtén las credenciales del cliente y las configuraciones de IdP para tu aplicación web. +Registra una nueva aplicación `Java Spring Boot` en Logto Console y obtén las credenciales de cliente y configuraciones de IdP para tu aplicación web. Añade la siguiente configuración a tu archivo `application.properties`: @@ -91,15 +91,15 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc -Para redirigir a los usuarios de vuelta a tu aplicación después de que inicien sesión, necesitas establecer el URI de redirección usando la propiedad `client.registration.logto.redirect-uri` en el paso anterior. +Para redirigir a los usuarios de vuelta a tu aplicación después de iniciar sesión, necesitas establecer el URI de redirección usando la propiedad `client.registration.logto.redirect-uri` en el paso anterior. - + ### Implementa el WebSecurityConfig \{#implement-the-websecurityconfig} #### Crea una nueva clase `WebSecurityConfig` en tu proyecto \{#create-a-new-class-websecurityconfig-in-your-project} -La clase `WebSecurityConfig` se utilizará para configurar los ajustes de seguridad de tu aplicación. Es la clase clave que manejará el flujo de autenticación y autorización. Por favor, consulta la [documentación de Spring Security](https://spring.io/guides/topicals/spring-security-architecture) para más detalles. +La clase `WebSecurityConfig` se usará para configurar los ajustes de seguridad de tu aplicación. Es la clase clave que manejará el flujo de autenticación y autorización. Consulta la [documentación de Spring Security](https://spring.io/guides/topicals/spring-security-architecture) para más detalles. ```java title="WebSecurityConfig.java" package com.example.securingweb; @@ -117,7 +117,7 @@ public class WebSecurityConfig { #### Crea un bean `idTokenDecoderFactory` \{#create-a-idtokendecoderfactory-bean} -Esto es necesario porque Logto usa `ES384` como el algoritmo predeterminado, necesitamos sobrescribir el `OidcIdTokenDecoderFactory` predeterminado para usar el mismo algoritmo. +Esto es necesario porque Logto utiliza `ES384` como algoritmo predeterminado, necesitamos sobrescribir el `OidcIdTokenDecoderFactory` predeterminado para usar el mismo algoritmo. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -138,7 +138,7 @@ public class WebSecurityConfig { } ``` -#### Crea una clase LoginSuccessHandler para manejar el evento de éxito de inicio de sesión \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} +#### Crea una clase LoginSuccessHandler para manejar el evento de inicio de sesión exitoso \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} Redirigiremos al usuario a la página `/user` después de un inicio de sesión exitoso. @@ -163,7 +163,7 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { } ``` -#### Crea una clase LogoutSuccessHandler para manejar el evento de éxito de cierre de sesión \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} +#### Crea una clase LogoutSuccessHandler para manejar el evento de cierre de sesión exitoso \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} Limpia la sesión y redirige al usuario a la página de inicio. @@ -197,9 +197,9 @@ public class CustomLogoutHandler implements LogoutSuccessHandler { #### Actualiza la clase `WebSecurityConfig` con un `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} -[securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) es una cadena de filtros que son responsables de procesar las solicitudes y respuestas entrantes. +[securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) es una cadena de filtros responsables de procesar las solicitudes y respuestas entrantes. -Configuraremos el `securityFilterChain` para permitir el acceso a la página de inicio y requerir autenticación para todas las demás solicitudes. Usa el `CustomSuccessHandler` y el `CustomLogoutHandler` para manejar los eventos de inicio y cierre de sesión. +Configuraremos el `securityFilterChain` para permitir el acceso a la página de inicio y requerir autenticación para todas las demás solicitudes. Usa `CustomSuccessHandler` y `CustomLogoutHandler` para manejar los eventos de inicio y cierre de sesión. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -251,7 +251,7 @@ public class HomeController { } ``` -Este controlador redirigirá al usuario a la página de usuario si el usuario está autenticado, de lo contrario, mostrará la página de inicio. Añade un enlace de inicio de sesión a la página de inicio. +Este controlador redirigirá al usuario a la página de usuario si está autenticado, de lo contrario, mostrará la página de inicio. Añade un enlace de inicio de sesión a la página de inicio. ```html title="resources/templates/home.html" @@ -299,13 +299,13 @@ public class UserController { } ``` -Una vez que el usuario está autenticado, recuperaremos los datos del `OAuth2User` del objeto principal autenticado. Por favor, consulta [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) y [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) para más detalles. +Una vez que el usuario esté autenticado, recuperaremos los datos de `OAuth2User` del objeto principal autenticado. Consulta [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) y [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) para más detalles. Lee los datos del usuario y pásalos a la plantilla `user.html`. ```html title="resources/templates/user.html" -

Detalles del Usuario

+

Detalles del usuario

nombre:
@@ -326,24 +326,24 @@ Lee los datos del usuario y pásalos a la plantilla `user.html`. -Para recuperar información adicional del usuario, puedes añadir alcances extra al archivo `application.properties`. Por ejemplo, para solicitar el alcance `email`, `phone`, y `urn:logto:scope:organizations`, añade la siguiente línea al archivo `application.properties`: +Para recuperar información adicional del usuario, puedes añadir alcances extra al archivo `application.properties`. Por ejemplo, para solicitar los alcances `email`, `phone` y `urn:logto:scope:organizations`, añade la siguiente línea al archivo `application.properties`: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -Luego puedes acceder a los reclamos adicionales en el objeto `OAuth2User`. +Luego podrás acceder a los reclamos adicionales en el objeto `OAuth2User`. ### Ejecuta y prueba la aplicación \{#run-and-test-the-application} Ejecuta la aplicación y navega a `http://localhost:8080`. -- Verás la página de inicio con un enlace de inicio de sesión. +- Verás la página de inicio con un enlace para iniciar sesión. - Haz clic en el enlace para iniciar sesión con Logto. -- Después de una autenticación exitosa, serás redirigido a la página de usuario con los detalles de tu usuario. +- Tras una autenticación exitosa, serás redirigido a la página de usuario con los detalles de tu usuario. - Haz clic en el botón de cerrar sesión para salir. Serás redirigido de vuelta a la página de inicio. -## Alcances y Reclamos \{#scopes-and-claims} +## Alcances y Reclamos (Scopes and Claims) \{#scopes-and-claims} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/es/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index 9157297a749..fa196cb03a1 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -8,13 +8,13 @@ import Availability from '@components/Availability'; -El conjunto de tokens de terceros (también conocido como conjunto de tokens federados) es un tipo de secreto almacenado en la [bóveda de secretos](/secret-vault) de Logto, utilizado para gestionar de forma segura los tokens de acceso y actualización emitidos por proveedores de identidad de terceros. Cuando un usuario se autentica a través de un conector social o SSO empresarial, Logto almacena los tokens emitidos en la bóveda. Estos tokens pueden recuperarse posteriormente para acceder a APIs de terceros en nombre del usuario, sin requerir una nueva autenticación. +El conjunto de tokens de terceros (también conocido como conjunto de tokens federados) es un tipo de secreto almacenado en el [bóveda de secretos](/secret-vault) de Logto, utilizado para gestionar de forma segura los tokens de acceso y actualización emitidos por proveedores de identidad de terceros. Cuando un usuario se autentica a través de un conector social o de SSO empresarial, Logto almacena los tokens emitidos en la bóveda. Estos tokens pueden recuperarse posteriormente para acceder a APIs de terceros en nombre del usuario, sin requerir una nueva autenticación. ## Casos de uso comunes \{#common-use-cases} Esta capacidad es esencial para aplicaciones modernas como agentes de IA, plataformas SaaS, herramientas de productividad y aplicaciones para clientes que necesitan interactuar con servicios de terceros en nombre de los usuarios. Aquí tienes algunos ejemplos prácticos: -**📅 Aplicaciones de gestión de calendarios**: Después de que un usuario inicie sesión con Google, tu app de productividad puede sincronizar automáticamente sus eventos de calendario, crear nuevas reuniones y enviar invitaciones sin pedirle que se autentique de nuevo. +**📅 Aplicaciones de gestión de calendarios**: Después de que un usuario inicie sesión con Google, tu aplicación de productividad puede sincronizar automáticamente sus eventos de calendario, crear nuevas reuniones y enviar invitaciones sin pedirle que se autentique de nuevo. **🤖 Asistentes de IA**: Un agente de IA puede acceder a los repositorios de GitHub de un usuario para analizar código, crear pull requests o gestionar incidencias. Todo con el consentimiento único del usuario durante el inicio de sesión o la vinculación de cuentas. @@ -31,12 +31,12 @@ Esta función está disponible para [conectores sociales](/connectors/social-con 3. Sigue los tutoriales de configuración para configurar el conector, incluyendo la adición de los alcances necesarios para acceder a APIs de terceros específicas. 4. En la página "Configuración", habilita la opción **Almacenar tokens para acceso persistente a API**. -### Conectores SSO empresariales \{#enterprise-sso-connectors} +### Conectores de SSO empresarial \{#enterprise-sso-connectors} El almacenamiento de tokens está disponible para todos los [conectores empresariales OIDC](/connectors/enterprise-connectors). Los tokens de acceso y actualización pueden almacenarse durante el [inicio de sesión único empresarial](/end-user-flows/enterprise-sso). Los conectores actualmente soportados incluyen: [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc), [Okta](/integrations/okta) y [OIDC (Enterprise)](/integrations/oidc-sso). 1. Navega a Consola > SSO empresarial. -2. Selecciona el conector SSO empresarial para el que deseas habilitar el almacenamiento de tokens de terceros. +2. Selecciona el conector de SSO empresarial para el que deseas habilitar el almacenamiento de tokens de terceros. 3. Sigue los tutoriales de configuración para configurar el conector, incluyendo la adición de los alcances necesarios para acceder a APIs de terceros específicas. 4. En la pestaña "Experiencia SSO", habilita la opción **Almacenar tokens para acceso persistente a API**. @@ -44,13 +44,13 @@ Asegúrate de guardar los cambios. ## Almacenamiento de tokens \{#token-storage} -Una vez habilitado el almacenamiento de tokens de terceros, Logto almacena automáticamente los tokens de acceso y actualización emitidos por el proveedor de identidad federado cada vez que un usuario se autentica a través de un conector social o SSO empresarial. Esto incluye: +Una vez habilitado el almacenamiento de tokens de terceros, Logto almacena automáticamente los tokens de acceso y actualización emitidos por el proveedor de identidad federado cada vez que un usuario se autentica a través de un conector social o de SSO empresarial. Esto incluye: - [Inicio de sesión y registro social](/end-user-flows/sign-up-and-sign-in/social-sign-in) - [Inicio de sesión y registro SSO empresarial](/end-user-flows/enterprise-sso) - [Vinculación de cuentas sociales a través de Account API](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -Los tokens almacenados se adjuntan a la identidad social o SSO empresarial del usuario, permitiéndole recuperarlos posteriormente para acceder a APIs sin requerir una nueva autenticación. +Los tokens almacenados se adjuntan a la identidad social o de SSO empresarial del usuario, permitiéndole recuperarlos posteriormente para acceder a APIs sin requerir una nueva autenticación. ### Comprobación del estado de almacenamiento de tokens \{#checking-token-storage-status} @@ -58,9 +58,9 @@ Puedes comprobar el estado de almacenamiento de tokens de terceros de un usuario 1. Navega a Consola > Usuarios. 2. Haz clic en el usuario que deseas inspeccionar. Esto te llevará a la página de detalles del usuario. -3. Desplázate hasta la sección **Conexiones**. Esta área muestra todas las conexiones sociales y SSO empresariales asociadas al usuario. -4. Cada entrada de conexión muestra una etiqueta de estado de token que indica si hay tokens almacenados para esa conexión. -5. Haz clic en la entrada de conexión para ver más detalles, incluyendo los metadatos del token de acceso almacenado y la disponibilidad del token de actualización (si está disponible). +3. Desplázate hasta la sección **Conexiones**. Esta área muestra todas las conexiones sociales y de SSO empresarial asociadas al usuario. +4. Cada entrada de conexión muestra una etiqueta de estado de token que indica si los tokens están almacenados para esa conexión. +5. Haz clic en la entrada de la conexión para ver más detalles, incluyendo los metadatos del token de acceso almacenado y la disponibilidad del token de actualización (si está disponible). También puedes comprobar las identidades de terceros del usuario y el estado de almacenamiento de tokens a través de la Management API: @@ -76,32 +76,32 @@ También puedes comprobar las identidades de terceros del usuario y el estado de ### Metadatos del token \{#token-metadata} -Por integridad y seguridad de los datos, todos los tokens se cifran antes de almacenarse en la bóveda de secretos. Los valores reales de los tokens solo son accesibles para el usuario final con la autorización adecuada. Los desarrolladores, por su parte, solo pueden recuperar los metadatos del conjunto de tokens para conocer el estado de los tokens almacenados sin exponer contenido sensible. +Para la integridad y seguridad de los datos, todos los tokens se cifran antes de almacenarse en la bóveda de secretos. Los valores reales de los tokens solo son accesibles para el usuario final con la autorización adecuada. Los desarrolladores, por otro lado, solo pueden recuperar los metadatos del conjunto de tokens para comprender el estado de los tokens almacenados sin exponer contenido sensible. -- `createdAt`: Marca de tiempo cuando se estableció la conexión por primera vez y el conjunto de tokens se almacenó inicialmente en la bóveda de secretos. -- `updatedAt`: Última vez que se actualizó el conjunto de tokens. +- `createdAt`: La marca de tiempo cuando se estableció la conexión por primera vez y el conjunto de tokens se almacenó inicialmente en la bóveda de secretos. +- `updatedAt`: La última vez que se actualizó el conjunto de tokens. - Si no hay token de actualización disponible, este valor será igual a **createdAt**. - Si hay un token de actualización presente, este valor refleja la última vez que se actualizó el token de acceso. - `hasRefreshToken`: Indica si hay un token de actualización disponible. Si el conector admite acceso offline y la solicitud de autorización está correctamente configurada, Logto almacena el token de actualización cuando es emitido por el proveedor de identidad junto con el token de acceso. Cuando el token de acceso expira y existe un token de actualización válido, Logto intenta automáticamente obtener un nuevo token de acceso usando el token de actualización almacenado cada vez que el usuario solicita acceso al proveedor conectado. -- `expiresAt`: Hora estimada de expiración del token de acceso en **segundos**. - Esto se calcula en base al valor `expires_in` devuelto por el endpoint de tokens del proveedor de identidad. (Este campo solo está disponible si el proveedor incluye `expires_in` en la respuesta de tokens). -- `scope`: El alcance del token de acceso, indicando los permisos otorgados por el proveedor de identidad. - Esto es útil para entender qué acciones pueden realizarse con el token de acceso almacenado. (Este campo solo está disponible si el proveedor incluye `scope` en la respuesta de tokens). +- `expiresAt`: El tiempo estimado de expiración del token de acceso en **segundos**. + Esto se calcula en base al valor `expires_in` devuelto por el endpoint de tokens del proveedor de identidad. (Este campo solo está disponible si el proveedor incluye `expires_in` en la respuesta del token.) +- `scope`: El alcance del token de acceso, indicando los permisos concedidos por el proveedor de identidad. + Esto es útil para entender qué acciones pueden realizarse con el token de acceso almacenado. (Este campo solo está disponible si el proveedor incluye `scope` en la respuesta del token.) - `tokenType`: El tipo de token de acceso, normalmente "Bearer". - (Este campo solo está disponible si el proveedor incluye `token_type` en la respuesta de tokens). + (Este campo solo está disponible si el proveedor incluye `token_type` en la respuesta del token.) ## Recuperación de tokens \{#token-retrieval} -Una vez habilitado el almacenamiento de tokens y almacenados de forma segura en la bóveda de secretos de Logto, los usuarios finales pueden recuperar sus tokens de acceso de terceros desde tu aplicación cliente integrándose con la [Account API](/end-user-flows/account-settings/by-account-api) de Logto. +Una vez habilitado el almacenamiento de tokens y los tokens estén almacenados de forma segura en la bóveda de secretos de Logto, los usuarios finales pueden recuperar sus tokens de acceso de terceros desde tu aplicación cliente integrándose con la [Account API](/end-user-flows/account-settings/by-account-api) de Logto. - `GET /my-account/identities/:target/access-token`: Recupera el token de acceso para una identidad social especificando el conector (por ejemplo, github, google). - `GET /my-account/sso-identities/:connectorId/access-token`: Recupera el token de acceso para una identidad SSO empresarial especificando el ID del conector. :::info -Aprende cómo [habilitar](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) y [acceder](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) a la Account API usando el token de acceso emitido por Logto. +Para recuperar tokens de acceso de terceros, primero debes habilitar la Account API para usuarios finales en Consola > Inicio de sesión y cuenta > Centro de cuentas. Aprende cómo [habilitar la Account API](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) y [acceder a ella usando un token de acceso emitido por Logto](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token). ::: ### Rotación de tokens \{#token-rotation} @@ -116,11 +116,11 @@ Si el token de acceso ha expirado y hay un token de actualización disponible, L ## Eliminación del almacenamiento de tokens \{#token-storage-deletion} -El almacenamiento de tokens de terceros está directamente vinculado a cada conexión social o SSO empresarial del usuario. Esto significa que el conjunto de tokens almacenado se eliminará automáticamente en los siguientes casos: +El almacenamiento de tokens de terceros está directamente vinculado a cada conexión social o de SSO empresarial del usuario. Esto significa que el conjunto de tokens almacenado se eliminará automáticamente en los siguientes casos: -- Se elimina la identidad social o SSO empresarial asociada de la cuenta del usuario. -- Se elimina la cuenta del usuario de tu tenant. -- Se elimina el conector social o SSO empresarial de tu tenant. +- Se elimina la identidad social o de SSO empresarial asociada de la cuenta del usuario. +- Se elimina la cuenta de usuario de tu tenant. +- Se elimina el conector social o de SSO empresarial de tu tenant. ### Revocación de tokens \{#revoking-tokens} @@ -135,12 +135,12 @@ Revocar el conjunto de tokens obligará al usuario a autenticarse de nuevo con e ## Reautenticación y renovación de tokens \{#reauthentication-and-token-renewal} -En escenarios donde un token de acceso almacenado ha expirado o cuando una aplicación necesita solicitar alcances adicionales de API, los usuarios finales pueden reautenticarse con el proveedor de terceros para obtener un nuevo token de acceso, sin necesidad de iniciar sesión de nuevo en Logto. +En escenarios donde un token de acceso almacenado ha expirado o cuando una aplicación necesita solicitar alcances adicionales de API, los usuarios finales pueden reautenticarse con el proveedor de terceros para obtener un nuevo token de acceso, sin necesidad de iniciar sesión en Logto nuevamente. Esto puede lograrse a través de la [API de verificación social](https://openapi.logto.io/operation/operation-createverificationbysocial) de Logto, que permite a los usuarios reiniciar un flujo de autorización social federada y actualizar su conjunto de tokens almacenado. :::note La reiniciación de la autorización federada está actualmente limitada a conectores sociales. -Para conectores SSO empresariales, la reautenticación y renovación de tokens requiere que el usuario inicie de nuevo un flujo completo de autenticación Logto, ya que la reautorización directa con el proveedor SSO empresarial no está soportada tras el inicio de sesión. +Para conectores de SSO empresarial, la reautenticación y renovación de tokens requieren que el usuario inicie un flujo completo de autenticación de Logto nuevamente, ya que la reautorización directa con el proveedor de SSO empresarial no está soportada tras el inicio de sesión. ::: ```mermaid @@ -176,7 +176,7 @@ sequenceDiagram - **authorization header**: El token de acceso del usuario emitido por Logto. - **connectorId**: El ID del conector social en Logto. - - **redirectUri**: La URI a la que redirigir al usuario de vuelta a tu aplicación tras la autenticación. Deberás registrar esta URI en la configuración de la aplicación del proveedor. + - **redirectUri**: El URI al que redirigir al usuario de vuelta a tu aplicación después de la autenticación. Deberás registrar este URI en la configuración de la aplicación del proveedor. - **scope**: (Opcional) Alcances personalizados para solicitar permisos adicionales al proveedor de terceros. Si no se especifica, se usarán los alcances predeterminados configurados en el conector. 2. Logto crea un nuevo registro de verificación social y devuelve el ID de verificación social junto con la URL de autorización para redirigir al usuario al proveedor de terceros para autenticación. @@ -191,11 +191,11 @@ sequenceDiagram } ``` -3. Redirige al usuario a la URL de autorización. El usuario se autentica con el proveedor de terceros y otorga permisos. +3. Redirige al usuario a la URL de autorización. El usuario se autentica con el proveedor de terceros y concede permisos. 4. El proveedor de terceros redirige al usuario de vuelta a tu aplicación cliente con un código de autorización. -5. Gestiona el callback de autorización reenviando el código de autorización al endpoint de verificación de Logto: +5. Maneja el callback de autorización reenviando el código de autorización al endpoint de verificación de Logto: ```sh curl -X POST https:///api/verification/social/verify \ @@ -234,6 +234,6 @@ sequenceDiagram - **authorization header**: El token de acceso del usuario emitido por Logto. - **socialVerificationId**: El ID de registro de verificación social verificado devuelto en el paso anterior. - Esto actualizará el almacenamiento del conjunto de tokens del usuario en la bóveda de secretos de Logto con el nuevo token de acceso y token de actualización, permitiendo al usuario acceder a APIs de terceros sin necesidad de iniciar sesión de nuevo en Logto. + Esto actualizará el almacenamiento del conjunto de tokens del usuario en la bóveda de secretos de Logto con el nuevo token de acceso y token de actualización, permitiendo al usuario acceder a APIs de terceros sin necesidad de iniciar sesión en Logto nuevamente. El token de acceso actualizado será devuelto. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/es/docusaurus-plugin-content-docs/current/security/blocklist.md index 929aaf498aa..79168e681c4 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/es/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -4,13 +4,13 @@ sidebar_label: Lista de bloqueo sidebar_position: 3 --- -# Lista de bloqueo (Blocklist) +# Lista de bloqueo -## Lista de bloqueo de correos electrónicos {#email-blocklist} +## Lista de bloqueo de correo electrónico {#email-blocklist} -La política de lista de bloqueo de correos electrónicos permite personalizar la configuración de la lista de bloqueo para evitar el abuso en el registro de cuentas. Supervisa las direcciones de correo electrónico utilizadas para el registro y la configuración de cuentas. Si un usuario intenta registrarse o vincular una dirección de correo electrónico que infringe alguna regla de la lista de bloqueo, el sistema rechazará la solicitud, ayudando a mitigar cuentas de spam y mejorar la seguridad general de las cuentas. +La política de lista de bloqueo de correo electrónico permite la personalización de la configuración de la lista de bloqueo para prevenir el abuso en el registro de cuentas. Supervisa las direcciones de correo electrónico utilizadas para el registro y la configuración de cuentas. Si un usuario intenta registrarse o vincular una dirección de correo electrónico que infringe alguna regla de la lista de bloqueo, el sistema rechazará la solicitud, ayudando a mitigar cuentas de spam y mejorar la seguridad general de las cuentas. -Visita Consola > Seguridad > Lista de bloqueo para configurar los ajustes de la lista de bloqueo de correos electrónicos. +Visita Consola > Seguridad > Lista de bloqueo para configurar los ajustes de la lista de bloqueo de correo electrónico. ### Bloquear direcciones de correo electrónico desechables {#block-disposable-email-addresses} @@ -18,17 +18,17 @@ Esta es una función **solo en la nube**. Una vez habilitada, el sistema validar ### Bloquear subdireccionamiento de correo electrónico {#block-email-subaddressing} -El subdireccionamiento de correo electrónico permite a los usuarios crear variaciones de sus direcciones de correo agregando un signo más (+) seguido de caracteres adicionales (por ejemplo, usuario+etiqueta@ejemplo.com). Esta función puede ser explotada por usuarios malintencionados para eludir las restricciones de la lista de bloqueo. Al habilitar la función de bloqueo de subdireccionamiento de correo electrónico, el sistema rechazará cualquier intento de registro o vinculación de cuenta que utilice formatos de correo electrónico con subdireccionamiento. +El subdireccionamiento de correo electrónico permite a los usuarios crear variaciones de sus direcciones de correo electrónico agregando un signo más (+) seguido de caracteres adicionales (por ejemplo, usuario+etiqueta@ejemplo.com). Esta función puede ser explotada por usuarios malintencionados para eludir las restricciones de la lista de bloqueo. Al habilitar la función de bloqueo de subdireccionamiento de correo electrónico, el sistema rechazará cualquier intento de registro o vinculación de cuenta que utilice formatos de correo electrónico con subdireccionamiento. -### Lista de bloqueo de correos electrónicos personalizada {#custom-email-blocklist} +### Lista de bloqueo de correo electrónico personalizada {#custom-email-blocklist} -Puedes crear una lista de bloqueo de correos electrónicos personalizada especificando una lista de direcciones de correo electrónico o dominios a bloquear. El sistema rechazará cualquier intento de registro o vinculación de cuenta que coincida con estas entradas. La lista de bloqueo admite coincidencia tanto de direcciones de correo electrónico completas como de dominios. +Puedes crear una lista de bloqueo de correo electrónico personalizada especificando una lista de direcciones de correo electrónico o dominios a bloquear. El sistema rechazará cualquier intento de registro o vinculación de cuenta que coincida con estas entradas. La lista de bloqueo admite tanto la coincidencia de direcciones de correo electrónico completas como de dominios. Por ejemplo, agregar `@example.com` a la lista de bloqueo bloqueará todas las direcciones de correo electrónico con ese dominio. De manera similar, agregar `foo@example.com` bloqueará específicamente esa dirección de correo electrónico. :::note -Los correos electrónicos desechables, el subdireccionamiento y los correos electrónicos personalizados están restringidos durante el registro y la vinculación de cuentas. Los usuarios existentes con estas direcciones de correo electrónico aún pueden iniciar sesión. +Los correos electrónicos desechables, el subdireccionamiento y los correos electrónicos personalizados están restringidos durante el [registro de nuevos usuarios](/end-user-flows/sign-up-and-sign-in/sign-up), [vinculación de correo electrónico durante el inicio de sesión social](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers), y la actualización de correos electrónicos a través de [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email). Los usuarios existentes con estas direcciones de correo electrónico aún pueden iniciar sesión. - Los administradores pueden "omitir restricciones" agregando usuarios manualmente en Consola > Gestión de usuarios, o mediante [Management API](https://openapi.logto.io/operation/operation-createuser). Por ejemplo, crear un usuario con un correo electrónico con subdireccionamiento cuando el subdireccionamiento está bloqueado. - Bloquea cuentas existentes eliminándolas o suspendiéndolas en Consola > Gestión de usuarios. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/es/docusaurus-plugin-content-docs/current/security/password-policy.mdx index 3e85ef12466..ec20557a2aa 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,9 +6,15 @@ sidebar_position: 1 # Política de contraseñas +Logto aplica la política de contraseñas de diferentes maneras dependiendo de cómo se crea o actualiza la contraseña: + +- Los flujos de usuario final como [la experiencia de inicio de sesión lista para usar](/end-user-flows/sign-up-and-sign-in/sign-up), [la Experience API](/customization/bring-your-ui) y [la Account API](/end-user-flows/account-settings/by-account-api#update-users-password) siempre aplican la [política de contraseñas](#set-up-password-policy) actual. +- Las acciones de administrador a través de la Management API [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) están exentas, lo que te permite aprovisionar o restablecer credenciales sin comprobaciones de la política cuando sea necesario. +- Para auditar contraseñas existentes según las reglas actuales, llama a [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) y actúa según el resultado de la validación devuelto. Lee [Comprobación de cumplimiento de contraseñas](#password-compliance-check) para obtener más información. + ## Configurar la política de contraseñas \{#set-up-password-policy} -Para nuevos usuarios o usuarios que están actualizando su contraseña, puedes establecer una política de contraseñas para hacer cumplir los requisitos de fortaleza de la contraseña. Visita Consola > Seguridad > Política de contraseñas para configurar los ajustes de la política de contraseñas. +Para nuevos usuarios o usuarios que están actualizando su contraseña, puedes establecer una política de contraseñas para exigir requisitos de fortaleza. Visita Consola > Seguridad > Política de contraseñas para configurar los ajustes de la política de contraseñas. 1. **Longitud mínima de la contraseña**: Establece el número mínimo de caracteres requeridos para la contraseña. (NIST sugiere usar al menos 8 [caracteres](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) 2. **Tipos mínimos de caracteres requeridos**: Establece el número mínimo de tipos de caracteres requeridos para la contraseña. Los tipos de caracteres disponibles son: @@ -16,19 +22,24 @@ Para nuevos usuarios o usuarios que están actualizando su contraseña, puedes e 2. Letras minúsculas: `(a-z)` 3. Números: `(0-9)` 4. Caracteres especiales: ``(!"#$%&'()\*+,-./:;<>=?@[]^\_`|{}~ )`` -3. **Verificación de historial de brechas**: Activa esta opción para rechazar contraseñas que hayan sido expuestas previamente en filtraciones de datos. (Impulsado por [Have I Been Pwned](https://haveibeenpwned.com/Passwords)) -4. **Verificación de repetición**: Activa esta opción para rechazar contraseñas que contengan caracteres repetitivos. (por ejemplo, "11111111" o "password123") -5. **Verificación de información del usuario**: Activa esta opción para rechazar contraseñas que contengan información del usuario como nombre de usuario, dirección de correo electrónico o número de teléfono. +3. **Comprobación de historial de brechas**: Activa esta opción para rechazar contraseñas que hayan sido expuestas previamente en brechas de datos. (Impulsado por [Have I Been Pwned](https://haveibeenpwned.com/Passwords)) +4. **Comprobación de repetición**: Activa esta opción para rechazar contraseñas que contengan caracteres repetitivos. (por ejemplo, "11111111" o "password123") +5. **Comprobación de información del usuario**: Activa esta opción para rechazar contraseñas que contengan información del usuario como nombre de usuario, dirección de correo electrónico o número de teléfono. 6. **Palabras personalizadas**: Proporciona una lista de palabras personalizadas (no distingue mayúsculas de minúsculas) que deseas rechazar en la contraseña. -## Verificación de cumplimiento de la contraseña \{#password-compliance-check} +## Comprobación de cumplimiento de contraseñas \{#password-compliance-check} -Después de actualizar la política de contraseñas en Logto, los usuarios existentes aún podrán iniciar sesión con sus contraseñas actuales. Solo las cuentas creadas recientemente deberán seguir la política actualizada. +Después de actualizar la política de contraseñas en Logto, los usuarios existentes aún pueden iniciar sesión con sus contraseñas actuales. Solo las cuentas recién creadas deberán seguir la política actualizada. -Para aplicar una seguridad más fuerte, puedes usar el `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) para comprobar si la contraseña de un usuario cumple con la política actual definida en la experiencia de inicio de sesión predeterminada. Si no la cumple, puedes solicitar al usuario que actualice su contraseña con un flujo personalizado usando [Account API](/end-user-flows/account-settings/by-management-api#user-password-management). +Para aplicar una seguridad más fuerte, puedes usar la [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) `POST /api/sign-in-exp/default/check-password` para comprobar si la contraseña de un usuario cumple con la política actual definida en la experiencia de inicio de sesión predeterminada. Si no la cumple, puedes solicitar al usuario que actualice su contraseña con un flujo personalizado usando la [Account API](/end-user-flows/account-settings/by-account-api). ## Recursos relacionados \{#related-resources} +Gestionar usuarios +Registro e inicio de sesión + + Configuración de cuenta por Account API + Diseña tu política de contraseñas diff --git a/i18n/es/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/es/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index 6e154d4dba2..af96ff9cda5 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -8,8 +8,7 @@ sidebar_position: 2 ### Navegar y buscar usuarios \{#browse-and-search-users} -Para acceder a la funcionalidad de gestión de usuarios en Logto Console, navega a Consola > Gestión de usuarios. -Una vez allí, verás una vista en tabla de todos los usuarios. +Para acceder a la funcionalidad de gestión de usuarios en Logto Console, navega a Console > Gestión de usuarios. Una vez allí, verás una vista en tabla de todos los usuarios. La tabla consta de tres columnas: @@ -21,9 +20,9 @@ Admite mapeo de palabras clave para [`name`](/user-management/user-data#name), [ ### Añadir usuarios \{#add-users} -Usando la Consola, los desarrolladores pueden crear nuevas cuentas para los usuarios finales. Para hacerlo, haz clic en el botón "Añadir usuario" en la esquina superior derecha de la pantalla. +Usando la Console, los desarrolladores pueden crear nuevas cuentas para los usuarios finales. Para hacerlo, haz clic en el botón "Añadir usuario" en la esquina superior derecha de la pantalla. -Al crear un usuario en Logto Console o mediante la Management API (no auto-registrado por el usuario final a través de la interfaz), debes proporcionar al menos un identificador: `primary email`, `primary phone` o `username`. El campo `name` es opcional. +Al crear un usuario en Logto Console o mediante la Management API (no auto-registrado por el usuario final a través de la UI), debes proporcionar al menos un identificador: `primary email`, `primary phone` o `username`. El campo `name` es opcional. Después de crear el usuario, Logto generará automáticamente una contraseña aleatoria. La contraseña inicial solo aparecerá una vez, pero puedes [restablecer la contraseña](./manage-users#reset-user-password) más adelante. Si deseas establecer una contraseña específica, utiliza la Management API `patch /api/users/{userId}/password` para actualizarla después de que el usuario haya sido creado. @@ -44,11 +43,18 @@ Para ver los detalles de un usuario, simplemente haz clic en la fila correspondi - **Número de teléfono** ([primary_phone](/user-management/user-data#primary_phone)): Editable - **Nombre de usuario** ([username](/user-management/user-data#username)): Editable - **Contraseña** ([has_password](/user-management/user-data#has_password)): Puedes regenerar una contraseña aleatoria. Aprende más sobre "[Restablecer contraseña de usuario](#reset-user-password)". - - **Conexiones sociales** ([identities](/user-management/user-data#social-identities)): Ver cuentas sociales vinculadas e IDs sociales. Por ejemplo, si el usuario ha iniciado sesión usando su cuenta de Facebook, verás un elemento "Facebook" en la lista. Puedes eliminar una identidad social vinculada en la Consola. Pero no puedes vincular una nueva en nombre del usuario final. - - **Conexiones SSO empresariales** ([sso_identities](/user-management/user-data#sso-identities)): Ver identidades empresariales vinculadas. No puedes añadir ni eliminar identidades SSO en la Consola. - - **Autenticación multifactor (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): Ver todos los factores de autenticación (por ejemplo, passkeys, apps autenticadoras, códigos de respaldo) que este usuario ha configurado. Los factores pueden eliminarse en la Consola. - - **Token de acceso personal**: Crear, ver, renombrar y eliminar [tokens de acceso personal](/user-management/personal-access-token). -- **Datos del perfil del usuario**: nombre, URL del avatar, datos personalizados y reclamos estándar adicionales de OpenID Connect que no están incluidos. Todos estos campos del perfil son editables. + - **Autenticación multifactor (Multi-factor authentication)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): Visualiza todos los factores de autenticación (por ejemplo, passkeys, aplicaciones autenticadoras, códigos de respaldo) que este usuario ha configurado. Los factores pueden eliminarse en la Console. + - **Token de acceso personal (Personal access token)**: Crea, visualiza, renombra y elimina [tokens de acceso personal](/user-management/personal-access-token). +- **Conexión**: + - **Conexiones sociales** ([identities](/user-management/user-data#social-identities)): + - Visualiza las cuentas sociales vinculadas del usuario, incluidos los IDs sociales y los detalles del perfil sincronizados desde sus proveedores sociales (por ejemplo, aparecerá una entrada "Facebook" si el usuario inició sesión a través de Facebook). + - Puedes eliminar identidades sociales existentes, pero no puedes vincular nuevas cuentas sociales en nombre del usuario. + - Para conectores sociales con [almacenamiento de tokens](/secret-vault/federated-token-set) habilitado, puedes ver y gestionar tokens de acceso y tokens de actualización en la página de detalles de la conexión. + - **Conexiones SSO empresariales (Enterprise SSO connections)** ([sso_identities](/user-management/user-data#sso-identities)): + - Visualiza las identidades empresariales vinculadas del usuario, incluidos los IDs empresariales y los detalles del perfil sincronizados desde sus proveedores de identidad empresarial. + - No puedes añadir ni eliminar identidades SSO empresariales en la Console. + - Para conectores empresariales basados en OIDC con [almacenamiento de tokens](/secret-vault/federated-token-set) habilitado, puedes ver y eliminar tokens en la página de detalles de la conexión. +- **Datos del perfil del usuario**: nombre, URL del avatar, datos personalizados y reclamos estándar adicionales de OpenID Connect que no están incluidos. Todos estos campos de perfil son editables. :::warning @@ -58,9 +64,9 @@ Es importante confirmar que el usuario tenga un método alternativo de inicio de ### Ver actividades del usuario \{#view-user-activities} -Para ver las actividades recientes de un usuario, navega a la subpestaña "Registros de usuario" en la página de detalles del usuario. Aquí puedes encontrar una tabla que muestra las actividades recientes del usuario, incluyendo la acción realizada, el resultado de la acción, la aplicación relacionada y la hora en que el usuario actuó. +Para ver las actividades recientes de un usuario, navega a la subpestaña "Registros de usuario" en la página de detalles del usuario. Aquí encontrarás una tabla que muestra las actividades recientes del usuario, incluyendo la acción realizada, el resultado de la acción, la aplicación relacionada y la hora en que el usuario actuó. -Haz clic en la fila de la tabla para ver más detalles en el registro del usuario, por ejemplo, dirección IP, agente de usuario, datos en bruto, etc. +Haz clic en la fila de la tabla para ver más detalles en el registro del usuario, por ejemplo, dirección IP, agente de usuario, datos sin procesar, etc. ### Suspender usuario \{#suspend-user} @@ -72,23 +78,29 @@ Si deseas reactivar a este usuario, puedes hacerlo haciendo clic en "Tres puntos ### Eliminar usuario \{#delete-user} -En la página de detalles del usuario, haz clic en "Tres puntos" -> botón "Eliminar". Eliminar usuario no se puede deshacer. +En la página de detalles del usuario, haz clic en "Tres puntos" -> botón "Eliminar". Eliminar un usuario no se puede deshacer. ### Restablecer contraseña de usuario \{#reset-user-password} -En la página de detalles del usuario, haz clic en "Tres puntos" -> botón "Restablecer contraseña", y luego Logto regenerará automáticamente una contraseña aleatoria. +En la página de detalles del usuario, haz clic en "Tres puntos" -> botón "Restablecer contraseña", y luego Logto generará automáticamente una contraseña aleatoria. Después de restablecer la contraseña, cópiala y envíala al usuario final. Una vez que se cierre el modal de "Restablecer contraseña", ya no podrás ver la contraseña. Si olvidas guardarla, puedes restablecerla nuevamente. No puedes establecer una contraseña específica para los usuarios en Logto Console, pero puedes usar la [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` para especificar una contraseña. +## Comprobación de cumplimiento de contraseñas \{#password-compliance-check} + +Después de actualizar la [política de contraseñas](/security/password-policy) en Logto, los usuarios existentes aún pueden iniciar sesión con sus contraseñas actuales. Solo las cuentas recién creadas deberán seguir la política de contraseñas actualizada. + +Para aplicar una seguridad más fuerte, puedes usar el `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) para comprobar si la contraseña de un usuario cumple con la política actual definida en la experiencia de inicio de sesión predeterminada. Si no la cumple, puedes solicitar al usuario que actualice su contraseña con un flujo personalizado usando [Account API](/end-user-flows/account-settings/by-management-api#user-password-management). + ### Gestionar roles de los usuarios \{#manage-roles-of-users} -En la pestaña "Roles" de la página de detalles del usuario, puedes asignar o eliminar roles fácilmente para lograr el resultado deseado. Consulta [Control de acceso basado en roles](/authorization/role-based-access-control) para más detalles. +En la pestaña "Roles" de la página de detalles del usuario, puedes asignar o eliminar roles fácilmente para lograr el resultado deseado. Consulta [Control de acceso basado en roles (RBAC)](/authorization/role-based-access-control) para más detalles. ### Ver las organizaciones a las que pertenece el usuario \{#view-the-organizations-the-user-belongs-to} -Logto admite [organizaciones](/organizations/organization-management) y puede gestionar sus miembros. Puedes ver fácilmente los detalles del usuario y a qué organización pertenece. +Logto admite [organizaciones](/organizations/organization-management) y puede gestionar sus miembros. Puedes ver fácilmente los detalles del usuario y ver a qué organización pertenece. ## Gestionar a través de Logto Management API \{#manage-via-logto-management-api} @@ -108,8 +120,8 @@ Puedes gestionar usuarios a través de la Management API en varios casos de uso. -Debido a la naturaleza [Omni-sign-in](https://logto.io/products/omni-sign-in) de Logto, no está diseñado para restringir el acceso de usuarios a ciertas aplicaciones antes de la autenticación. +Debido a la naturaleza de [Omni-sign-in](https://logto.io/products/omni-sign-in) de Logto, no está diseñado para restringir el acceso de usuarios a ciertas aplicaciones antes de la autenticación. Sin embargo, aún puedes diseñar roles y permisos de usuario específicos de la aplicación para proteger tus recursos de API, y validar los permisos en el acceso a la API tras el inicio de sesión exitoso del usuario. -Consulta Autorización: [Control de acceso basado en roles](/authorization/role-based-access-control) para más información. +Consulta Autorización: [Control de acceso basado en roles (RBAC)](/authorization/role-based-access-control) para más información. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/es/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index 950bb184e47..c2d7c0ec508 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -2,7 +2,7 @@ sidebar_position: 1 --- -# Estructura de datos de usuario +# Estructura de datos del usuario Los usuarios son las entidades principales en el servicio de identidad. En Logto, incluyen datos básicos de autenticación basados en el protocolo [OpenID Connect](https://auth.wiki/openid-connect), junto con datos personalizados. @@ -16,7 +16,7 @@ Consiste en los siguientes tipos de datos: - [Identidades sociales](/user-management/user-data#social-identities): almacena la información del usuario obtenida del inicio de sesión social (es decir, inicio de sesión con un conector social), como Facebook, GitHub y WeChat. - [Datos personalizados](/user-management/user-data#custom-data): almacena información adicional del usuario que no está listada en las propiedades predefinidas del usuario, como el color y el idioma preferidos por el usuario. -Aquí tienes un ejemplo de los datos de un usuario obtenidos de un inicio de sesión en Facebook: +Aquí tienes un ejemplo de los datos de un usuario obtenidos tras iniciar sesión con Facebook: ```json { @@ -48,8 +48,7 @@ Aquí tienes un ejemplo de los datos de un usuario obtenidos de un inicio de ses } ``` -Puedes consultar el perfil de usuario usando Logto Console -o Logto Management API, como [`GET /api/users/:userId`](https://openapi.logto.io/operation/operation-getuser). +Puedes consultar el perfil del usuario usando Logto Console o Logto Management API, como [`GET /api/users/:userId`](https://openapi.logto.io/operation/operation-getuser). ## Datos básicos \{#basic-data} @@ -67,16 +66,20 @@ Su valor proviene del nombre de usuario con el que el usuario se registró por p ### primary_email \{#primary_email} -_primary_email_ es la dirección de correo electrónico del usuario, utilizada para iniciar sesión con el correo electrónico y contraseña / código de verificación. +_primary_email_ es la dirección de correo electrónico del usuario, utilizada para iniciar sesión con el correo electrónico y la contraseña / código de verificación. Su valor suele provenir de la dirección de correo electrónico con la que el usuario se registró por primera vez. Puede ser `null`. Su longitud máxima es 128. +Solo las direcciones de correo electrónico verificadas de proveedores de identidad social o SSO empresarial pueden sincronizarse y guardarse como `primary_email`. + ### primary_phone \{#primary_phone} -_primary_phone_ es el número de teléfono del usuario, utilizado para iniciar sesión con el número de teléfono y contraseña / código de verificación por SMS. +_primary_phone_ es el número de teléfono del usuario, utilizado para iniciar sesión con el número de teléfono y la contraseña / código de verificación por SMS. Su valor suele provenir del número de teléfono con el que el usuario se registró por primera vez. Puede ser `null`. Su valor no nulo debe contener números precedidos por el [código de país](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (excluyendo el signo más `+`). +Solo los números de teléfono verificados de proveedores de identidad social o SSO empresarial pueden sincronizarse y guardarse como `primary_phone`. + ### name \{#name} _name_ es el nombre completo del usuario. Su longitud máxima es 128. @@ -95,9 +98,9 @@ Esta propiedad se asigna al reclamo `picture` en el estándar [OpenID Connect](h ### profile \{#profile} -_profile_ almacena reclamos estándar adicionales de OpenID Connect que no están incluidos en las propiedades del usuario. +_profile_ almacena reclamos estándar adicionales de [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) que no están incluidos en las propiedades del usuario. -Su definición de tipo se puede encontrar en [este archivo](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6). Aquí tienes una copia de la definición de tipo: +Su definición de tipo puede encontrarse en [este archivo](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6). Aquí tienes una copia de la definición de tipo: ```tsx type UserProfile = Partial<{ @@ -129,7 +132,7 @@ type UserProfile = Partial<{ ::: -Una diferencia en comparación con otros reclamos estándar es que las propiedades en `profile` solo se incluirán en el [Token de ID (ID token)](https://auth.wiki/id-token) o en la respuesta del endpoint userinfo cuando sus valores no estén vacíos, mientras que otros reclamos estándar devolverán `null` si los valores están vacíos. +Una diferencia respecto a otros reclamos estándar es que las propiedades en `profile` solo se incluirán en el [Token de ID (ID token)](https://auth.wiki/id-token) o en la respuesta del endpoint userinfo cuando sus valores no estén vacíos, mientras que otros reclamos estándar devolverán `null` si los valores están vacíos. ### application_id \{#application_id} @@ -149,7 +152,7 @@ _updated_at_ es la marca de tiempo con la zona horaria cuando la información de ### has_password \{#has_password} -_has_password_ es un valor booleano que indica si el usuario tiene una contraseña. Puedes ver y gestionar este estado, incluyendo establecer una nueva o restablecer la contraseña en la página de detalle de Consola > Gestión de usuarios. +_has_password_ es un valor booleano que indica si el usuario tiene una contraseña. Puedes ver y gestionar este estado, incluyendo establecer una nueva o restablecer la contraseña en la página de detalles de Consola > Gestión de usuarios. ### password_encrypted \{#password_encrypted} @@ -174,13 +177,13 @@ Ejemplo de _password_encrypted_ y _password_encryption_method_ de un usuario cuy ### is_suspended \{#is_suspended} -_is_suspended_ es un valor booleano que indica si un usuario está suspendido o no. El valor puede ser gestionado llamando a la [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) o usando Logto Console. +_is_suspended_ es un valor booleano que indica si un usuario está suspendido o no. El valor puede gestionarse llamando a la [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) o usando Logto Console. -Una vez que un usuario es suspendido, los tokens de actualización previamente otorgados serán revocados inmediatamente y el usuario ya no podrá autenticarse con Logto. +Una vez que un usuario es suspendido, los tokens de actualización previamente otorgados se revocarán inmediatamente y el usuario ya no podrá autenticarse con Logto. ### mfa_verification_factors \{#mfa_verification_factors} -_mfa_verification_factors_ es un array que lista los métodos de [autenticación multifactor (MFA)](/end-user-flows/mfa) asociados a la cuenta del usuario. Los valores posibles incluyen: _Totp_ (OTP de app autenticadora), _WebAuthn_ (Passkey) y _BackupCode_. +_mfa_verification_factors_ es un array que lista los métodos de [autenticación multifactor (MFA)](/end-user-flows/mfa) asociados a la cuenta del usuario. Los valores posibles incluyen: _Totp_ (OTP de aplicación autenticadora), _WebAuthn_ (Passkey) y _BackupCode_. ```tsx mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; @@ -200,7 +203,7 @@ La información del usuario varía según el proveedor de identidad social (es d La cuenta del usuario puede estar vinculada a varios proveedores de identidad social mediante inicio de sesión social; la información correspondiente obtenida de estos proveedores se almacenará en el objeto _identities_. -Ejemplo de _identities_ de un usuario que inició sesión con Google y Facebook: +Ejemplo de _identities_ de un usuario que inició sesión tanto con Google como con Facebook: ```json { @@ -229,7 +232,7 @@ Ejemplo de _identities_ de un usuario que inició sesión con Google y Facebook: _sso_identities_ contiene la información del usuario obtenida del [SSO empresarial](/end-user-flows/enterprise-sso) (es decir, inicio de sesión único con un [conector empresarial](/connectors/enterprise-connectors)). Cada _ssoIdentities_ de usuario se almacena en un objeto JSON individual. -Los datos sincronizados desde el proveedor de identidad SSO dependen de los alcances configurados en el conector empresarial para solicitar. Aquí tienes una copia de la definición de tipo TypeScript: +Los datos sincronizados desde el proveedor de identidad SSO dependen de los alcances configurados en el conector empresarial para solicitar. Aquí tienes una copia de la definición de tipo en TypeScript: ```ts type SSOIdentity = { @@ -275,11 +278,11 @@ NO pongas datos sensibles en _custom_data_. ::: -Los datos personalizados pueden ser accedidos a través de [Reclamos personalizados de token JWT](/developers/custom-token-claims) después del inicio de sesión del usuario, y los tokens JWT están codificados en base64 (no cifrados) y se transmiten frecuentemente a través de redes, lo que hace que cualquier dato sensible sea fácilmente expuesto. +Los datos personalizados pueden accederse a través de [Reclamos personalizados en el token JWT](/developers/custom-token-claims) después del inicio de sesión del usuario, y los tokens JWT están codificados en base64 (no cifrados) y se transmiten frecuentemente a través de redes, lo que hace que cualquier dato sensible sea fácilmente expuesto. -Puedes obtener un perfil de usuario que contenga _custom_data_ usando [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) y enviarlo a las aplicaciones frontend o servicios backend externos. Por lo tanto, poner información sensible en _custom_data_ puede causar filtraciones de datos. +Puedes obtener un perfil de usuario que contenga _custom_data_ usando la [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) y enviarlo a las aplicaciones frontend o servicios backend externos. Por lo tanto, poner información sensible en _custom_data_ puede causar filtraciones de datos. -Si aún deseas poner información sensible en _custom_data_, recomendamos cifrarla primero. Solo cifra/descifra en una parte confiable como tus servicios backend, y evita hacerlo en las aplicaciones frontend. Esto minimizará la pérdida si el _custom_data_ de tus usuarios se filtra por error. +Si aún deseas poner información sensible en _custom_data_, recomendamos cifrarla primero. Solo cifra/descifra en una parte confiable como tus servicios backend y evita hacerlo en las aplicaciones frontend. Esto minimizará la pérdida si los _custom_data_ de tus usuarios se filtran por error. **Cómo recopilar y actualizar datos personalizados del usuario** @@ -290,8 +293,7 @@ Si aún deseas poner información sensible en _custom_data_, recomendamos cifrar - Utiliza la [Management API](/user-management/manage-users/#manage-via-logto-management-api) para la gestión de usuarios o flujos personalizados avanzados: - Usa [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) para obtener todos los datos del usuario. - Usa [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) para actualizar el _custom_data_ de un usuario. -- Tu equipo de soporte puede actualizar directamente el _custom_data_ del usuario en Consola > Gestión de usuarios. - Aprende más sobre [ver y actualizar perfiles de usuario](/user-management/manage-users/#view-and-update-the-user-profile). +- Tu equipo de soporte puede actualizar directamente el _custom_data_ del usuario en Consola > Gestión de usuarios. Aprende más sobre [ver y actualizar perfiles de usuario](/user-management/manage-users/#view-and-update-the-user-profile). Actualiza con cuidado. Actualizar el _custom_data_ de un usuario sobrescribirá completamente su contenido original en el almacenamiento. @@ -305,7 +307,7 @@ Por ejemplo, si tu entrada al llamar a la API de actualización de _custom_data_ } ``` -entonces el nuevo valor de _custom_data_ después de la actualización será: +entonces el nuevo valor de _custom_data_ después de actualizar será: ```json { @@ -319,7 +321,7 @@ Es decir, el valor del campo actualizado no tiene relación con el valor anterio ## Referencia de propiedades \{#property-reference} -Las siguientes columnas de la tabla de usuarios de la base de datos (excepto _password_encrypted_ y _password_encryption_method_) son visibles en el perfil del usuario, lo que significa que puedes consultarlas usando [Management API](https://openapi.logto.io/operation/operation-getuser). +Las siguientes columnas de la tabla de usuarios de la base de datos (excepto _password_encrypted_ y _password_encryption_method_) son visibles en el perfil del usuario, lo que significa que puedes consultarlas usando la [Management API](https://openapi.logto.io/operation/operation-getuser). | Nombre | Tipo | Descripción | Único | Requerido | | ----------------------------------------------------------------------------------- | --------- | ------------------------------------------------------------ | ----- | --------- | @@ -329,11 +331,11 @@ Las siguientes columnas de la tabla de usuarios de la base de datos (excepto _pa | [primary_phone](/user-management/user-data#primary_phone) | string | Número de teléfono principal | ✅ | ❌ | | [name](/user-management/user-data#name) | string | Nombre completo | ❌ | ❌ | | [avatar](/user-management/user-data#avatar) | string | URL del avatar del usuario | ❌ | ❌ | -| [profile](/user-management/user-data#profile) | object | Perfil de usuario | ❌ | ✅ | +| [profile](/user-management/user-data#profile) | object | Perfil del usuario | ❌ | ✅ | | [identities](/user-management/user-data#social-identities) | object | Información obtenida del inicio de sesión social | ❌ | ✅ | | [custom_data](/user-management/user-data#custom-data) | object | Información adicional en propiedades personalizables | ❌ | ✅ | | [application_id](/user-management/user-data#application_id) | string | ID de la aplicación en la que el usuario se registró primero | ❌ | ✅ | -| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | Marca de tiempo del último inicio de sesión | ❌ | ✅ | +| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | Marca de tiempo de la última vez que inició sesión | ❌ | ✅ | | [password_encrypted](/user-management/user-data#password_encrypted) | string | Contraseña cifrada | ❌ | ❌ | | [password_encryption_method](/user-management/user-data#password_encryption_method) | string | Método de cifrado de contraseña | ❌ | ❌ | | [is_suspended](/user-management/user-data#is_suspended) | bool | Marca de suspensión del usuario | ❌ | ✅ | diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index b093aa30d82..5f3a364ac82 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -13,7 +13,7 @@ import Tabs from '@theme/Tabs'; export const resource = 'https://api.your-app.com'; -Protégez les API à l’échelle du produit en utilisant le contrôle d’accès basé sur les rôles (RBAC) dans Logto. Attribuez des rôles et des permissions globales pour contrôler l’accès de tous les utilisateurs et clients à travers votre application. +Protégez les API à l’échelle du produit en utilisant le contrôle d’accès basé sur les rôles (RBAC) dans Logto. Attribuez des rôles et des permissions globaux pour contrôler l’accès de tous les utilisateurs et clients à travers votre application. ## Qu’est-ce qu’une ressource API globale ? \{#what-are-global-api-resources} @@ -29,7 +29,7 @@ Logto vous permet de sécuriser ces API en utilisant OAuth 2.1, combiné à un c ## Fonctionnement dans Logto \{#how-it-works-in-logto} -- **Les ressources API et les permissions sont enregistrées globalement :** Chaque API que vous souhaitez protéger est définie avec un indicateur de ressource unique (URI) et un ensemble de permissions (portées) qui contrôlent l’accès. +- **Les ressources API et permissions sont enregistrées globalement :** Chaque API que vous souhaitez protéger est définie avec un indicateur de ressource unique (URI) et un ensemble de permissions (portées) qui contrôlent l’accès. - **L’accès est contrôlé par des rôles globaux :** Vous pouvez attribuer des permissions à des rôles, qui sont ensuite attribués à des utilisateurs ou des clients. - **Séparé des permissions au niveau de l’organisation :** Les ressources API globales n’ont pas de contexte d’organisation. Cependant, elles peuvent être utilisées en combinaison avec des rôles d’organisation pour fournir une couche de contexte supplémentaire si nécessaire. Pour protéger les API au niveau de l’organisation, voir [Protéger les ressources API au niveau de l’organisation](/authorization/organization-level-api-resources). @@ -45,7 +45,7 @@ Logto vous permet de sécuriser ces API en utilisant OAuth 2.1, combiné à un c ### Comprendre les indicateurs de ressource \{#understanding-resource-indicators} -Logto modélise les ressources API selon [RFC 8707 : Indicateurs de ressource pour OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html). Un **indicateur de ressource** est un URI qui identifie de façon unique l’API ou le service cible demandé. +Logto modélise les ressources API selon [RFC 8707 : Indicateurs de ressource pour OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html). Un **indicateur de ressource** est un URI qui identifie de manière unique l’API ou le service cible demandé. **Points clés** @@ -60,9 +60,9 @@ Logto modélise les ressources API selon [RFC 8707 : Indicateurs de ressource po ### Flux d’autorisation : authentifier et sécuriser votre API \{#authorization-flow-authenticating-and-securing-your-api} -Le flux ci-dessous s’applique à la fois à l’authentification interactive des utilisateurs (navigateur / application) et aux scénarios backend machine à machine (M2M). +Le flux ci-dessous s’applique à la fois à l’authentification interactive de l’utilisateur (navigateur / application) et aux scénarios backend machine à machine (M2M). -Veuillez noter que ce flux ne détaille pas tous les paramètres ou en-têtes requis, mais se concentre sur les étapes clés. Continuez à lire pour voir comment ce flux fonctionne en pratique. +Veuillez noter que ce flux ne détaille pas tous les paramètres ou en-têtes requis, mais se concentre sur les étapes clés. Continuez la lecture pour voir comment ce flux fonctionne en pratique. ```mermaid sequenceDiagram @@ -74,9 +74,9 @@ sequenceDiagram Client->>Logto: GET /oidc/auth Logto->>Logto: Redirige l’utilisateur vers la page de connexion Logto->>Client: Redirige avec `authorization_code` - alt Utiliser le grant authorization_code + alt Utilise le grant authorization_code Client->>Logto: POST /oidc/token avec `grant_type=authorization_code`
et paramètre `resource` - else Utiliser le grant refresh_token + else Utilise le grant refresh_token Client->>Logto: POST /oidc/token avec `grant_type=authorization_code` Logto->>Client: Retourne un jeton de rafraîchissement Client->>Logto: POST /oidc/token avec `grant_type=refresh_token`
et paramètre `resource` @@ -111,17 +111,17 @@ Le paramètre `resource` doit correspondre exactement à l’identifiant API (in Pour toutes les étapes de configuration, voir [Définir des ressources API avec des permissions](/authorization/role-based-access-control#define-api-resources-with-permissions). -### Configurez les rôles globaux \{#set-up-global-roles} +### Configurez des rôles globaux \{#set-up-global-roles} 1. Allez dans Console → Rôles. 2. Créez des rôles correspondant à vos permissions API (par exemple, `read:products`, `write:products`). 3. Attribuez ces rôles aux utilisateurs ou clients qui ont besoin d’accéder à l’API. -Pour toutes les étapes de configuration, voir [Utiliser les rôles globaux](/authorization/role-based-access-control#configure-global-roles). +Pour toutes les étapes de configuration, voir [Utiliser des rôles globaux](/authorization/role-based-access-control#configure-global-roles). ### Obtenez des jetons d’accès pour les ressources API globales \{#obtain-access-tokens-for-global-api-resources} -Avant d’accéder à une ressource API globale, votre client doit obtenir un jeton d’accès. Logto émet des [JSON Web Tokens (JWT)](https://auth.wiki/jwt) comme jetons d’accès pour les ressources API globales. Cela se fait généralement via le [flux d’autorisation OAuth 2.0 code](https://auth.wiki/authorization-code-flow), le [flux de jeton de rafraîchissement](https://auth.wiki/refresh-token), ou le [flux client credentials](https://auth.wiki/client-credentials-flow). +Avant d’accéder à une ressource API globale, votre client doit obtenir un jeton d’accès. Logto émet des [JSON Web Tokens (JWT)](https://auth.wiki/jwt) comme jetons d’accès pour les ressources API globales. Cela se fait généralement via le [flux d’autorisation code OAuth 2.0](https://auth.wiki/authorization-code-flow), le [flux de jeton de rafraîchissement](https://auth.wiki/refresh-token), ou le [flux client credentials](https://auth.wiki/client-credentials-flow). #### Flux authorization code ou refresh token \{#authorization-code-or-refresh-token-flow} @@ -137,11 +137,11 @@ Une fois l’utilisateur authentifié, transmettez l’indicateur de ressource d Pour plus de détails sur chaque SDK, voir les [Démarrages rapides](/quick-starts). - + Lors de la configuration de votre client OAuth 2.0 ou de l’initialisation du flux authorization code, assurez-vous d’inclure le paramètre `resource` et les portées souhaitées dans la requête d’autorisation. -Certaines bibliothèques ne prennent pas en charge nativement le paramètre `resource`, mais permettent généralement de passer des paramètres supplémentaires dans la requête d’autorisation. Consultez la documentation de votre bibliothèque pour plus de détails. +Certaines bibliothèques ne prennent pas en charge nativement le paramètre `resource`, mais permettent généralement de transmettre des paramètres supplémentaires dans la requête d’autorisation. Consultez la documentation de votre bibliothèque pour plus de détails. Voici un exemple non normatif de requête d’autorisation avec les paramètres `resource` et `scope` : @@ -192,7 +192,7 @@ Lorsque votre API reçoit une requête avec un jeton d’accès émis par Logto, Pour des guides étape par étape et spécifiques à chaque langage, voir [Comment valider les jetons d’accès](/authorization/validate-access-tokens). -### Optionnel : Gérer le changement de permission utilisateur \{#optional-handle-user-permission-change} +### Optionnel : Gérer le changement de permissions utilisateur \{#optional-handle-user-permission-change} :::info 👷 Travail en cours. 🚧 @@ -201,7 +201,7 @@ Pour des guides étape par étape et spécifiques à chaque langage, voir [Comme ## Bonnes pratiques et conseils de sécurité \{#best-practices-and-security-tips} - **Gardez les permissions orientées métier :** Utilisez des noms clairs correspondant à des actions réelles. -- **Gardez une expiration de jeton courte :** Réduit le risque en cas de fuite d’un jeton. +- **Gardez une expiration de jeton courte :** Réduit le risque en cas de fuite de jeton. - **Limitez les portées accordées :** Donnez uniquement aux jetons les permissions réellement nécessaires. - **Utilisez la restriction d’audience :** Vérifiez toujours la revendication `aud` pour éviter les abus. @@ -245,6 +245,36 @@ Utilisez un [jeton d’accès personnel](/user-management/personal-access-token) +
+ + +### Puis-je utiliser des préfixes de scope ou des versions abrégées lors de la demande de permissions ? \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +Non. Les noms de scope doivent **correspondre exactement** aux noms de permissions définis dans votre ressource API. Les préfixes et versions abrégées ne fonctionnent pas comme des jokers. + +**Exemple :** + +Si votre ressource API définit : + +- `read:elections` +- `write:elections` + +Vous devez demander : + +```swift +scopes: ["read:elections", "write:elections"] +``` + +Ceci **NE fonctionnera PAS** : + +```swift +scopes: ["read", "write"] // ❌ Ne correspond pas aux noms de permissions +``` + +
+ ## Pour aller plus loin \{#further-reading} Comment valider les jetons d’accès diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index c08149e51bc..876cbe1d900 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -4,7 +4,7 @@ sidebar_position: 4 # Langues localisées -Logto prend en charge un large éventail de langues prédéfinies et propose 113 balises de langue supplémentaires. Cet outil puissant vous permet de personnaliser l'expérience de connexion en créant et en gérant vos propres options linguistiques et traductions. +Logto prend en charge un large éventail de langues prédéfinies et propose 113 balises linguistiques supplémentaires. Cet outil puissant vous permet de personnaliser l’expérience de connexion en créant et en gérant vos propres options linguistiques et traductions. ## Étapes de personnalisation dans la Console Logto \{#customization-steps-in-logto-console} @@ -13,37 +13,37 @@ Personnalisez facilement les paramètres de langue dans la Console Logto sans co 1. **Accédez à** : Console > Expérience de connexion > Contenu > Langues. 2. **Gérer la langue** : Cliquez sur le bouton “Gérer la langue” pour accéder à votre bibliothèque de langues. - **Modifier les langues existantes :** Personnalisez les traductions des langues fournies par Logto. Ces langues ne peuvent pas être supprimées, mais vos modifications remplaceront les valeurs par défaut. - - **Ajouter une nouvelle langue** : Cliquez sur le bouton “Ajouter une langue”, sélectionnez une balise de langue, fournissez vos traductions, puis enregistrez les modifications pour ajouter une nouvelle langue. -3. **Activer la détection automatique** : Lorsqu'elle est activée, la page de connexion s'affiche automatiquement dans la langue préférée de l'utilisateur selon les paramètres de son appareil. -4. **Définir la langue par défaut :** Vous pouvez choisir une langue par défaut dans votre bibliothèque de langues. Elle sera utilisée lorsque la langue détectée de l'utilisateur n'est pas couverte dans la bibliothèque de langues actuelle. + - **Ajouter une nouvelle langue** : Cliquez sur le bouton ”Ajouter une langue”, sélectionnez une balise linguistique, fournissez vos traductions, puis enregistrez les modifications pour ajouter une nouvelle langue. +3. **Activer la détection automatique** : Lorsqu’elle est activée, la page de connexion s’affiche automatiquement dans la langue préférée de l’utilisateur selon les paramètres de son appareil. +4. **Définir la langue par défaut :** Vous pouvez choisir une langue par défaut dans votre bibliothèque de langues. Elle sera utilisée lorsque la langue détectée de l’utilisateur n’est pas couverte dans la bibliothèque de langues actuelle. Voici quelques termes clés à comprendre lors de la gestion des langues : -| Définition | Description | -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Balise de langue | La balise de langue identifie la langue du contenu. Une balise de langue est composée d'un code de langue (par exemple, en, fr, zh) et d'un code de pays / région (par exemple, US, UK, KR) séparés par des tirets. Une balise de langue ressemble à ceci : en-US. | -| Langue fournie par Logto | La langue fournie par Logto est la langue officielle de Logto et est stockée dans le code source original de Logto. | -| Langue ajoutée | La langue ajoutée est la langue ajoutée par les utilisateurs. | -| Valeurs sources Logto | Les valeurs sources Logto sont les valeurs fournies par Logto qui n'ont pas été personnalisées par les utilisateurs. | -| Valeurs personnalisées | Les valeurs personnalisées sont des valeurs déjà personnalisées par les utilisateurs. Les valeurs sources Logto seront écrasées. | +| Définition | Description | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Balise linguistique | La balise linguistique identifie la langue du contenu. Une balise linguistique est composée d’un code de langue (par exemple, en, fr, zh) et d’un code de pays / région (par exemple, US, UK, KR) séparés par des tirets. Exemple : en-US. | +| Langue fournie par Logto | La langue fournie par Logto est une langue officielle de Logto et est stockée dans le code source original de Logto. | +| Langue ajoutée | La langue ajoutée est la langue ajoutée par les utilisateurs. | +| Valeurs sources Logto | Les valeurs sources Logto sont les valeurs fournies par Logto qui n’ont pas été personnalisées par les utilisateurs. | +| Valeurs personnalisées | Les valeurs personnalisées sont des valeurs déjà personnalisées par les utilisateurs. Les valeurs sources Logto seront écrasées. | ## Personnalisation via Management API \{#customization-using-management-api} -Vous pouvez utiliser le Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) pour personnaliser les traductions de langue. Le corps de la requête API est un objet locale partiel comme : +Vous pouvez utiliser le Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) pour personnaliser les traductions linguistiques. Le corps de la requête API est un objet locale partiel comme : ```json { "input": { "username": "Username", "password": "Password" }, "secondary": { - "social_bind_with": "Vous avez déjà un compte ? Connectez-vous pour lier {{methods, list(type: disjunction;)}} à votre identité sociale." + "social_bind_with": "Already had an account? Sign in to link {{methods, list(type: disjunction;)}} with your social identity." }, - "action": { "sign_in": "Se connecter" }, + "action": { "sign_in": "Sign in" }, "error": { - "general_required": "{{types, list(type: disjunction;)}} est requis" + "general_required": "{{types, list(type: disjunction;)}} is required" }, - "list": { "or": "ou" }, + "list": { "or": "or" }, "user_scopes": { - "descriptions": { "custom_data": "Vos données personnalisées" } + "descriptions": { "custom_data": "Your custom data" } } } ``` @@ -57,8 +57,8 @@ Vous pouvez également utiliser l’API [PATCH /api/sign-in-exp](https://openapi À l’exécution, la langue de l’expérience de connexion est résolue selon la priorité suivante : 1. Le paramètre OIDC `ui_locales` de la requête d’authentification en cours (la première balise prise en charge est utilisée). Voir [ui_locales](/end-user-flows/authentication-parameters/ui-locales). -2. Sinon, si la "détection automatique" est activée, la langue client détectée de l’utilisateur (par exemple, à partir de l’en-tête HTTP `Accept-Language`). -3. Sinon, la langue par défaut du tenant dans l’Expérience de connexion. +2. Sinon, si la "détection automatique" est activée, la langue du client utilisateur détectée (par exemple, à partir de l’en-tête HTTP `Accept-Language`). +3. Sinon, la langue par défaut du locataire dans l’Expérience de connexion. Cette résolution affecte également la localisation des e-mails pour les messages déclenchés par l’interaction. En savoir plus : [Localisation des modèles d’e-mails](/connectors/email-connectors/email-templates#email-template-localization). @@ -68,9 +68,9 @@ Comment la langue ajoutée apparaît-elle aux clients finaux ? Supposons que vous ayez un site web où l’anglais est la langue par défaut et que la détection automatique soit activée. Un utilisateur du Japon arrive sur votre site et décide de créer un compte. S’il utilise le japonais comme langue de son application mais que Logto ne prend pas encore en charge cette langue, l’écran de connexion s’affichera en anglais. -L’i18n de l’expérience de connexion Logto rend possible la personnalisation linguistique. +L’internationalisation de l’expérience de connexion Logto rend possible la personnalisation linguistique. -Cliquez sur la balise de langue `ja` pour ajouter votre propre traduction japonaise. +Cliquez sur la balise linguistique `ja` pour ajouter votre propre traduction japonaise. De cette façon, l’utilisateur accédant à votre site depuis le Japon pourra lire le contenu en japonais, que vous venez de traduire depuis l’anglais. @@ -83,7 +83,7 @@ De cette façon, l’utilisateur accédant à votre site depuis le Japon pourra -À côté de la balise de langue à gauche, une étiquette "fournie par Logto" apparaîtra, et la langue que vous avez ajoutée ne pourra plus être supprimée. Les valeurs modifiées continuent de fonctionner et remplacent les valeurs originales de Logto. Effacez les valeurs fournies par l’utilisateur pour utiliser les valeurs de la configuration par défaut de Logto. +À côté de la balise linguistique à gauche, une étiquette "fournie par Logto" apparaîtra, et la langue que vous avez ajoutée ne pourra plus être supprimée. Les valeurs modifiées continuent de fonctionner et remplacent les valeurs originales de Logto. Effacez les valeurs fournies par l’utilisateur pour utiliser les valeurs de la configuration par défaut de Logto. @@ -99,9 +99,21 @@ Supposons que vous ne souhaitiez ajuster qu’un sous-ensemble du contenu origin +
+ + +### Comment puis-je définir un indicatif téléphonique par défaut pour l’expérience de connexion ? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +L’indicatif téléphonique dans l’[expérience de connexion](/end-user-flows/sign-up-and-sign-in/sign-up) est par défaut celui de la locale du navigateur de l’utilisateur. Par exemple, si la langue du navigateur d’un utilisateur est définie sur `fr`, l’indicatif sera celui de la France (+33). + +Pour contrôler de manière programmatique l’indicatif par défaut pour certains utilisateurs ou régions, vous pouvez utiliser le paramètre d’authentification [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales). Par exemple, définir `ui_locales=ja` définira l’indicatif par défaut sur le Japon (+81). + +
+ ## Ressources associées \{#related-resources} - Prise en charge de la disposition des langues arabes et RTL (de droite à gauche) dans votre - application + Prise en charge de l’arabe et de la mise en page RTL (de droite à gauche) dans votre application diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index 29ebcedc910..0fef49bb3fa 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -6,13 +6,13 @@ sidebar_position: 1 ## Expérience de connexion omni \{#omni-sign-in-experience} -Personnalisez l'apparence de votre page de connexion en naviguant vers Console > Expérience de connexion > Personnalisation. Cette section vous permet d'ajuster facilement les principaux éléments de votre marque. +Personnalisez l'apparence de votre page de connexion en naviguant vers Console > Expérience de connexion > Personnalisation. Cette section vous permet d'ajuster facilement les éléments clés de votre identité visuelle. -**Couleur de la marque** +### Couleur de la marque \{#brand-color} Définissez la couleur principale utilisée dans toute l'expérience de connexion, y compris les boutons principaux, les liens et autres composants. Remplacez la couleur violette par défaut de Logto par la couleur de votre marque. Pour le mode sombre, une couleur de marque distincte peut être spécifiée. -**Logo de l'entreprise** +### Logo de l'entreprise \{#company-logo} Le logo sera affiché sur la page d'accueil de connexion, la page d'inscription, la page de chargement et d'autres interfaces avec notre extension. @@ -20,7 +20,7 @@ Le logo sera affiché sur la page d'accueil de connexion, la page d'inscription, - Si vous laissez le champ du logo vide, le logo ne s'affichera pas dans l'interface. - Une version du logo pour le mode sombre peut également être téléchargée. -**Favicon** +### Favicon \{#favicon} Un favicon est une petite icône représentant un site web et s'affiche dans l'onglet du navigateur, les favoris et d'autres zones de l'interface du navigateur. @@ -28,30 +28,34 @@ Un favicon est une petite icône représentant un site web et s'affiche dans l'o - Une version du favicon pour le mode sombre peut également être téléchargée. - De plus, le titre du navigateur pour les différents flux (Connexion / Inscription / Mot de passe oublié, etc.) est désormais utilisé à la place d'un titre personnalisé. -**Mode sombre** +### Mode sombre \{#dark-mode} Activez le mode sombre pour ajuster automatiquement l'apparence de la page de connexion en fonction des préférences système de l'utilisateur. +### Masquer la marque Logto \{#hide-logto-branding} + +Par défaut, les pages d'expérience de connexion prêtes à l'emploi affichent "Propulsé par Logto" en bas. Activez l'option "Masquer la marque Logto" pour supprimer la mention Logto et créer une expérience de connexion propre et professionnelle qui met exclusivement en avant l'identité de votre propre marque. + ## Personnalisation spécifique à l'application \{#app-specific-branding} Si votre activité multi-applications nécessite des expériences de connexion au niveau de l'application, vous pouvez configurer cela dans la page de détails de l'application. Rendez-vous sur Console > Applications. -En activant "Expérience de connexion au niveau de l'application", vous pouvez définir des logos, favicons, couleurs et même [CSS personnalisé](/customization/custom-css) spécifiques pour chaque application. Lorsqu'une connexion est initiée depuis une application avec la personnalisation activée, l'expérience de connexion sera adaptée selon les paramètres de personnalisation de l'application ; sinon, elle reviendra aux paramètres par défaut de l'expérience de connexion omni. +En activant "Expérience de connexion au niveau de l'application", vous pouvez définir des logos, favicons, couleurs et même [CSS personnalisé](/customization/custom-css) spécifiques à chaque application. Lorsqu'une connexion est initiée depuis une application avec la personnalisation activée, l'expérience de connexion sera adaptée selon les paramètres de personnalisation de l'application ; sinon, elle reviendra aux paramètres par défaut de l'expérience de connexion omni. -Les paramètres pour le mode clair et sombre sont disponibles pour la personnalisation au niveau de l'application. Les paramètres du mode sombre ne prendront effet que lorsque le mode sombre est activé dans les paramètres de l’[expérience de connexion omni](#omni-sign-in-experience). +Les paramètres pour les modes clair et sombre sont disponibles pour la personnalisation au niveau de l'application. Les paramètres du mode sombre ne prendront effet que lorsque le mode sombre est activé dans les paramètres de l’[expérience de connexion omni](#omni-sign-in-experience). ## Personnalisation spécifique à l'organisation \{#organization-specific-branding} Pour afficher dynamiquement le logo de l'organisation de votre client dans l'expérience de connexion, vous pouvez télécharger les logos des organisations dans la page des paramètres de l'organisation. Rendez-vous sur Console > Organisations. -En activant "Expérience de connexion au niveau de l'organisation", comme pour la personnalisation au niveau de l'application, vous pouvez également définir des logos, favicons, couleurs et [CSS personnalisé](/customization/custom-css) spécifiques pour chaque organisation. +En activant "Expérience de connexion au niveau de l'organisation", comme pour la personnalisation au niveau de l'application, vous pouvez également définir des logos, favicons, couleurs et [CSS personnalisé](/customization/custom-css) spécifiques à chaque organisation. Ensuite, lors du déclenchement d'une connexion, vous pouvez transmettre l'identifiant de l'organisation dans le paramètre `organization_id` pour indiquer à Logto quel logo d'organisation afficher. Par exemple, pour afficher le logo de l'organisation avec l'identifiant `123456` : - Si vous utilisez le SDK Logto, vous pouvez transmettre le paramètre `organization_id` dans l'objet `extraParams` de la méthode `signIn`. - Si vous utilisez un client OIDC, vous pouvez transmettre le paramètre `organization_id` lors de la demande au [point de terminaison d'autorisation](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). -Les paramètres pour le mode clair et sombre sont disponibles pour la personnalisation au niveau de l'organisation. Les paramètres du mode sombre ne prendront effet que lorsque le mode sombre est activé dans les paramètres de l’[expérience de connexion omni](#omni-sign-in-experience). +Les paramètres pour les modes clair et sombre sont disponibles pour la personnalisation au niveau de l'organisation. Les paramètres du mode sombre ne prendront effet que lorsque le mode sombre est activé dans les paramètres de l’[expérience de connexion omni](#omni-sign-in-experience). :::note Si la personnalisation au niveau de l'application et celle au niveau de l'organisation sont toutes deux activées, la personnalisation au niveau de l'organisation aura la priorité. L'ordre de priorité complet est : diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index ea5b4f9f308..f6fba73a1b7 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -3,18 +3,18 @@ description: Découvrez comment utiliser l’Account API pour gérer l’utilisa sidebar_position: 1 --- -# Paramètres du compte via l’Account API +# Paramètres du compte via Account API -## Qu’est-ce que l’Account API de Logto \{#what-is-logto-account-api} +## Qu’est-ce que Logto Account API \{#what-is-logto-account-api} L’Account API de Logto est un ensemble complet d’API qui donne aux utilisateurs finaux un accès direct à l’API sans avoir besoin de passer par la Management API. Voici les points clés : - Accès direct : L’Account API permet aux utilisateurs finaux d’accéder et de gérer directement leur propre profil de compte sans passer par la Management API. -- Gestion du profil utilisateur et des identités : Les utilisateurs peuvent gérer entièrement leur profil et leurs paramètres de sécurité, y compris la possibilité de mettre à jour les informations d’identité telles que l’e-mail, le téléphone et le mot de passe, ainsi que de gérer les connexions sociales. Le support de MFA et SSO arrive bientôt. +- Gestion du profil utilisateur et des identités : Les utilisateurs peuvent gérer entièrement leur profil et leurs paramètres de sécurité, y compris la possibilité de mettre à jour les informations d’identité comme l’e-mail, le téléphone et le mot de passe, ainsi que de gérer les connexions sociales. Le support de MFA et SSO arrive bientôt. - Contrôle d’accès global : Les administrateurs disposent d’un contrôle global complet sur les paramètres d’accès et peuvent personnaliser chaque champ. -- Autorisation transparente : L’autorisation est plus simple que jamais ! Utilisez simplement `client.getAccessToken()` pour obtenir un jeton opaque d’accès pour OP (Logto), et attachez-le à l’en-tête Authorization sous la forme `Bearer `. +- Autorisation transparente : L’autorisation est plus simple que jamais ! Utilisez simplement `client.getAccessToken()` pour obtenir un jeton d’accès opaque (Jeton opaque) pour OP (Logto), et attachez-le à l’en-tête Authorization sous la forme `Bearer `. -Avec l’Account API de Logto, vous pouvez construire un système de gestion de compte personnalisé, comme une page de profil, entièrement intégré à Logto. +Avec l’Account API de Logto, vous pouvez construire un système de gestion de compte personnalisé comme une page de profil entièrement intégrée à Logto. Voici quelques cas d’utilisation fréquents : @@ -24,30 +24,30 @@ Voici quelques cas d’utilisation fréquents : - Mettre à jour les identités utilisateur, y compris l’e-mail, le téléphone et les connexions sociales - Gérer les facteurs MFA (vérifications) -Pour en savoir plus sur les API disponibles, veuillez consulter la [Référence de l’Account API de Logto](https://openapi.logto.io/group/endpoint-my-account) et la [Référence de l’API de vérification de Logto](https://openapi.logto.io/group/endpoint-verifications). +Pour en savoir plus sur les API disponibles, veuillez consulter la [référence Logto Account API](https://openapi.logto.io/group/endpoint-my-account) et la [référence Logto Verification API](https://openapi.logto.io/group/endpoint-verifications). :::note -Les fonctionnalités de visualisation de compte SSO et de suppression de compte sont actuellement disponibles via les Management APIs de Logto. Voir [Paramètres du compte via la Management API](/end-user-flows/account-settings/by-management-api) pour les détails d’implémentation. +Les fonctionnalités de visualisation de compte SSO et de suppression de compte sont actuellement disponibles via les Management APIs de Logto. Voir [Paramètres du compte via Management API](/end-user-flows/account-settings/by-management-api) pour les détails d’implémentation. ::: ## Comment activer l’Account API \{#how-to-enable-account-api} -Naviguez vers Console > Connexion & compte > Centre de compte. +Accédez à Console > Connexion & compte > Centre de compte. -L’Account API est désactivée par défaut, donc ses contrôles d’accès sont verrouillés. Activez **Activer l’Account API** pour l’allumer. +L’Account API est désactivée par défaut, donc ses contrôles d’accès sont verrouillés. Activez **Activer Account API** pour l’allumer. Une fois activée, configurez les permissions par champ pour les identifiants, les données de profil et l’accès aux jetons tiers. Chaque champ prend en charge `Off`, `ReadOnly` ou `Edit` ; la valeur par défaut est `Off`. 1. **Champs de sécurité** : - Les champs incluent : e-mail principal, téléphone principal, identités sociales, mot de passe et MFA. - - Avant que les utilisateurs finaux n’éditent ces champs, ils doivent vérifier leur identité via mot de passe, e-mail ou SMS pour obtenir un identifiant d’enregistrement de vérification valable 10 minutes. Voir [Obtenir un identifiant d’enregistrement de vérification](#get-a-verification-record-id). - - Pour utiliser les passkeys WebAuthn pour MFA, ajoutez les domaines de votre application front-end à **WebAuthn Related Origins** afin que le centre de compte et l’expérience de connexion puissent partager les passkeys. Voir [Lier une nouvelle passkey WebAuthn](#link-a-new-webauthn-passkey). + - Avant que les utilisateurs finaux n’éditent ces champs, ils doivent vérifier leur identité via mot de passe, e-mail ou SMS pour obtenir un ID d’enregistrement de vérification valable 10 minutes. Voir [Obtenir un ID d’enregistrement de vérification](#get-a-verification-record-id). + - Pour utiliser les passkeys WebAuthn pour MFA, ajoutez les domaines de vos applications front-end à **WebAuthn Related Origins** afin que le centre de compte et l’expérience de connexion puissent partager les passkeys. Voir [Lier une nouvelle passkey WebAuthn](#link-a-new-webauthn-passkey). 2. **Champs de profil** : - - Les champs incluent : nom d’utilisateur, nom, avatar, [profil](/user-management/user-data#profile) (autres attributs standard du profil), et [données personnalisées](/user-management/user-data#custom-data). + - Les champs incluent : nom d’utilisateur, nom, avatar, [profil](/user-management/user-data#profile) (autres attributs standards du profil) et [données personnalisées](/user-management/user-data#custom-data). - Les utilisateurs finaux peuvent éditer ces champs sans vérification supplémentaire. -3. **Secret vault** : Pour les connecteurs sociaux et d’entreprise OIDC ou OAuth, le [secret vault](/secret-vault/federated-token-set) de Logto stocke en toute sécurité les jetons d’accès et de rafraîchissement tiers après authentification. Les applications peuvent alors appeler des APIs externes, comme la synchronisation des événements Google Calendar, sans demander à nouveau la connexion à l’utilisateur. La récupération des jetons devient disponible automatiquement une fois l’Account API activée. +3. **Secret vault** : Pour les connecteurs sociaux et d’entreprise OIDC ou OAuth, le [secret vault](/secret-vault/federated-token-set) de Logto stocke en toute sécurité les jetons d’accès et de rafraîchissement tiers après authentification. Les applications peuvent alors appeler des APIs externes, comme synchroniser des événements Google Calendar, sans demander à l’utilisateur de se reconnecter. La récupération des jetons devient disponible automatiquement une fois l’Account API activée. ## Comment accéder à l’Account API \{#how-to-access-account-api} @@ -61,7 +61,7 @@ import { type LogtoConfig, UserScope } from '@logto/js'; const config: LogtoConfig = { // ...autres options - // Ajoutez les portées appropriées selon vos cas d’utilisation. + // Ajoutez les portées adaptées à vos cas d’usage. scopes: [ UserScope.Email, // Pour les APIs `{POST,DELETE} /api/my-account/primary-email` UserScope.Phone, // Pour les APIs `{POST,DELETE} /api/my-account/primary-phone` @@ -77,11 +77,11 @@ const config: LogtoConfig = { ### Récupérer un jeton d’accès \{#fetch-an-access-token} -Après avoir configuré le SDK dans votre application, vous pouvez utiliser la méthode `client.getAccessToken()` pour récupérer un jeton d’accès. Ce jeton est un jeton opaque qui peut être utilisé pour accéder à l’Account API. +Après avoir configuré le SDK dans votre application, vous pouvez utiliser la méthode `client.getAccessToken()` pour récupérer un jeton d’accès. Ce jeton est un jeton opaque (Jeton opaque) qui peut être utilisé pour accéder à l’Account API. -Si vous n’utilisez pas le SDK officiel, vous devez définir `resource` comme vide pour la requête de jeton d’accès vers `/oidc/token`. +Si vous n’utilisez pas le SDK officiel, vous devez définir le champ `resource` comme vide pour la requête de jeton d’accès vers `/oidc/token`. -### Accéder à l’Account API avec le jeton d’accès \{#access-account-api-using-access-token} +### Accéder à l’Account API avec un jeton d’accès \{#access-account-api-using-access-token} Vous devez inclure le jeton d’accès dans le champ `Authorization` des en-têtes HTTP au format Bearer (`Bearer YOUR_TOKEN`) lors de l’interaction avec l’Account API. @@ -140,13 +140,13 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ ## Gérer les identifiants et autres informations sensibles \{#manage-identifiers-and-other-sensitive-information} -Pour des raisons de sécurité, l’Account API exige une couche supplémentaire d’autorisation pour les opérations impliquant des identifiants et autres informations sensibles. +Pour des raisons de sécurité, l’Account API requiert une couche d’autorisation supplémentaire pour les opérations impliquant des identifiants et autres informations sensibles. -### Obtenir un identifiant d’enregistrement de vérification \{#get-a-verification-record-id} +### Obtenir un ID d’enregistrement de vérification \{#get-a-verification-record-id} -Vous devez d’abord obtenir un **identifiant d’enregistrement de vérification** avec une expiration de 10 minutes (TTL). Cela permet de vérifier l’identité de l’utilisateur avant de mettre à jour des informations sensibles. Cela signifie qu’une fois qu’un utilisateur a vérifié son identité via mot de passe, code de vérification par e-mail ou code de vérification par SMS, il dispose de 10 minutes pour mettre à jour ses données liées à l’authentification, y compris les identifiants, les informations d’identification, le lien de compte social et MFA. +Vous devez d’abord obtenir un **ID d’enregistrement de vérification** avec une expiration de 10 minutes (TTL). Cela permet de vérifier l’identité de l’utilisateur avant de mettre à jour des informations sensibles. Cela signifie qu’une fois qu’un utilisateur a vérifié son identité via mot de passe, code de vérification par e-mail ou code de vérification par SMS, il dispose de 10 minutes pour mettre à jour ses données liées à l’authentification, y compris les identifiants, les identifiants de connexion, le lien de compte social et MFA. -Pour obtenir un identifiant d’enregistrement de vérification, vous pouvez [vérifier le mot de passe de l’utilisateur](#verify-the-users-password) ou [envoyer un code de vérification à l’e-mail ou au téléphone de l’utilisateur](#verify-by-sending-a-verification-code-to-the-users-email-or-phone). +Pour obtenir un ID d’enregistrement de vérification, vous pouvez [vérifier le mot de passe de l’utilisateur](#verify-the-users-password) ou [envoyer un code de vérification à l’e-mail ou au téléphone de l’utilisateur](#verify-by-sending-a-verification-code-to-the-users-email-or-phone). #### Vérifier le mot de passe de l’utilisateur \{#verify-the-users-password} @@ -172,7 +172,7 @@ Le corps de la réponse sera similaire à : Pour utiliser cette méthode, vous devez [configurer le connecteur e-mail](/connectors/email-connectors/) ou [le connecteur SMS](/connectors/sms-connectors/), et vous assurer que le template `UserPermissionValidation` est configuré. ::: -Prenons l’e-mail comme exemple, demandez un nouveau code de vérification et obtenez l’identifiant d’enregistrement de vérification : +Prenons l’e-mail comme exemple, demandez un nouveau code de vérification et obtenez l’ID d’enregistrement de vérification : ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ @@ -199,13 +199,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"123456"}' ``` -Après avoir vérifié le code, vous pouvez maintenant utiliser l’identifiant d’enregistrement de vérification pour mettre à jour l’identifiant de l’utilisateur. +Après avoir vérifié le code, vous pouvez maintenant utiliser l’ID d’enregistrement de vérification pour mettre à jour l’identifiant de l’utilisateur. -Pour en savoir plus sur les vérifications, veuillez consulter [Vérification de sécurité via l’Account API](/end-user-flows/security-verification). +Pour en savoir plus sur les vérifications, veuillez consulter [Vérification de sécurité via Account API](/end-user-flows/security-verification). -### Envoyer une requête avec l’identifiant d’enregistrement de vérification \{#send-request-with-verification-record-id} +### Envoyer une requête avec un ID d’enregistrement de vérification \{#send-request-with-verification-record-id} -Lors de l’envoi d’une requête pour mettre à jour l’identifiant de l’utilisateur, vous devez inclure l’identifiant d’enregistrement de vérification dans l’en-tête de la requête avec le champ `logto-verification-id`. +Lors de l’envoi d’une requête pour mettre à jour l’identifiant de l’utilisateur, vous devez inclure l’ID d’enregistrement de vérification dans l’en-tête de la requête avec le champ `logto-verification-id`. ### Mettre à jour le mot de passe de l’utilisateur \{#update-users-password} @@ -219,10 +219,14 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +Comme pour les mots de passe créés lors de l’inscription, les mots de passe définis via l’Account API doivent respecter la [politique de mot de passe](/security/password-policy) que vous avez configurée dans Console > Sécurité > Politique de mot de passe. Logto retourne des résultats de validation détaillés et des messages d’erreur si le mot de passe ne respecte pas la politique. +::: + ### Mettre à jour ou lier un nouvel e-mail \{#update-or-link-new-email} :::note -Pour utiliser cette méthode, vous devez [configurer le connecteur e-mail](/connectors/email-connectors/), et vous assurer que le template `BindNewIdentifier` est configuré. +Pour utiliser cette méthode, vous devez [configurer le connecteur e-mail](/connectors/email-connectors/) et vous assurer que le template `BindNewIdentifier` est configuré. ::: Pour mettre à jour ou lier un nouvel e-mail, vous devez d’abord prouver la propriété de l’e-mail. @@ -245,7 +249,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}' ``` -Après avoir vérifié le code, vous pouvez maintenant appeler [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) pour mettre à jour l’e-mail de l’utilisateur, en mettant le `verificationId` dans le corps de la requête sous `newIdentifierVerificationRecordId`. +Après avoir vérifié le code, vous pouvez maintenant appeler [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) pour mettre à jour l’e-mail de l’utilisateur, en définissant `verificationId` dans le corps de la requête comme `newIdentifierVerificationRecordId`. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -255,6 +259,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +Comme pour les e-mails collectés lors de l’inscription, tout e-mail lié via l’Account API doit passer la vérification [blocklist](/security/blocklist) que vous avez configurée dans Console > Sécurité > Blocklist. Logto rejettera la requête et retournera une erreur détaillée si l’e-mail viole la politique. +::: + ### Supprimer l’e-mail de l’utilisateur \{#remove-the-users-email} Pour supprimer l’e-mail de l’utilisateur, vous pouvez utiliser l’endpoint [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail). @@ -268,7 +276,7 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### Gérer le téléphone \{#manage-phone} :::note -Pour utiliser cette méthode, vous devez [configurer le connecteur SMS](/connectors/sms-connectors/), et vous assurer que le template `BindNewIdentifier` est configuré. +Pour utiliser cette méthode, vous devez [configurer le connecteur SMS](/connectors/sms-connectors/) et vous assurer que le template `BindNewIdentifier` est configuré. ::: Comme pour la mise à jour de l’e-mail, vous pouvez utiliser l’endpoint [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) pour mettre à jour ou lier un nouveau téléphone. Et utilisez l’endpoint [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) pour supprimer le téléphone de l’utilisateur. @@ -290,7 +298,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ Dans la réponse, vous trouverez un `verificationRecordId`, conservez-le pour une utilisation ultérieure. -Après que l’utilisateur a autorisé l’application, vous recevrez un callback sur le `redirectUri` avec le paramètre `state`. Vous pouvez alors utiliser l’endpoint [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) pour vérifier la connexion sociale. +Après que l’utilisateur a autorisé l’application, vous recevrez un callback à `redirectUri` avec le paramètre `state`. Vous pouvez alors utiliser l’endpoint [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) pour vérifier la connexion sociale. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ @@ -299,7 +307,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -Le `connectorData` est la donnée retournée par le connecteur social après que l’utilisateur a autorisé l’application, vous devez analyser et récupérer les paramètres de requête du `redirectUri` dans votre page de callback, et les encapsuler en JSON comme valeur du champ `connectorData`. +Le `connectorData` est la donnée retournée par le connecteur social après que l’utilisateur a autorisé l’application, vous devez analyser et récupérer les paramètres de requête depuis le `redirectUri` dans votre page de callback, et les encapsuler en JSON comme valeur du champ `connectorData`. Enfin, vous pouvez utiliser l’endpoint [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) pour lier la connexion sociale. @@ -324,7 +332,7 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connecto ### Lier une nouvelle passkey WebAuthn \{#link-a-new-webauthn-passkey} :::note -N’oubliez pas d’[activer MFA et WebAuthn](/end-user-flows/mfa) au préalable. +N’oubliez pas d’[activer MFA et WebAuthn](/end-user-flows/mfa) d’abord. ::: :::note @@ -335,7 +343,7 @@ Pour utiliser cette méthode, vous devez activer le champ `mfa` dans les [param Les passkeys WebAuthn sont liées à un nom d’hôte spécifique appelé **Relying Party ID (RP ID)**. Seules les applications hébergées sur l’origine du RP ID peuvent enregistrer ou s’authentifier avec ces passkeys. -Puisque votre application front-end appelle l’Account API depuis un domaine différent de celui des pages d’authentification de Logto, vous devez configurer les **origines associées** pour permettre les opérations de passkey cross-origin. +Puisque votre application front-end appelle l’Account API depuis un domaine différent de celui des pages d’authentification Logto, vous devez configurer les **origines associées** pour permettre les opérations de passkey cross-origin. **Comment Logto détermine le RP ID :** @@ -353,7 +361,17 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -Pour en savoir plus sur les origines associées, veuillez consulter la documentation [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/). +:::note + +WebAuthn prend en charge jusqu’à 5 étiquettes eTLD+1 uniques pour les origines associées. L’eTLD+1 (effective top-level domain plus un label) est la partie du domaine enregistrable. Par exemple : + +- `https://example.com`, `https://app.example.com` et `https://auth.example.com` comptent pour **une** étiquette (`example.com`) +- `https://shopping.com`, `https://shopping.co.uk` et `https://shopping.co.jp` comptent aussi pour **une** étiquette (`shopping`) +- `https://example.com` et `https://another.com` comptent pour **deux** étiquettes + +Si vous devez prendre en charge plus de 5 domaines différents comme origines associées, consultez la documentation [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) pour plus de détails. + +::: **Étape 2 : Demander de nouvelles options d’enregistrement** @@ -393,7 +411,7 @@ const response = await startRegistration({ Utilisez l’endpoint [`POST /api/verifications/web-authn/registration/verify`](https://openapi.logto.io/operation/operation-verifywebauthnregistration) pour vérifier l’enregistrement de la passkey. -Cette étape vérifie la signature cryptographique générée par l’authentificateur pour s’assurer que la passkey a été créée légitimement et n’a pas été altérée pendant la transmission. +Cette étape vérifie la signature cryptographique générée par l’authenticator pour s’assurer que la passkey a bien été créée et n’a pas été altérée pendant la transmission. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration/verify \ @@ -403,7 +421,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registrat ``` - `payload` : La réponse du navigateur local à l’étape 2. -- `verificationRecordId` : L’identifiant d’enregistrement de vérification retourné par le serveur à l’étape 1. +- `verificationRecordId` : L’ID d’enregistrement de vérification retourné par le serveur à l’étape 1. **Étape 5 : Lier la passkey** @@ -417,9 +435,9 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"WebAuthn","newIdentifierVerificationRecordId":"..."}' ``` -- `verification_record_id` : un identifiant d’enregistrement de vérification valide, obtenu en vérifiant le facteur existant de l’utilisateur, voir la section [Obtenir un identifiant d’enregistrement de vérification](#get-a-verification-record-id) pour plus de détails. +- `verification_record_id` : un ID d’enregistrement de vérification valide, obtenu en vérifiant le facteur existant de l’utilisateur, voir la section [Obtenir un ID d’enregistrement de vérification](#get-a-verification-record-id) pour plus de détails. - `type` : le type du facteur MFA, actuellement seul `WebAuthn` est supporté. -- `newIdentifierVerificationRecordId` : l’identifiant d’enregistrement de vérification retourné par le serveur à l’étape 1. +- `newIdentifierVerificationRecordId` : l’ID d’enregistrement de vérification retourné par le serveur à l’étape 1. ### Gérer les passkeys WebAuthn existantes \{#manage-existing-webauthn-passkeys} @@ -450,7 +468,7 @@ Le corps de la réponse sera similaire à : - `name` : le nom de la passkey, champ optionnel. - `agent` : l’agent utilisateur de la passkey. -Mettez à jour le nom de la passkey en utilisant l’endpoint [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname) : +Mettez à jour le nom de la passkey avec l’endpoint [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname) : ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId}/name \ @@ -460,7 +478,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{ve --data-raw '{"name":"..."}' ``` -Supprimez la passkey en utilisant l’endpoint [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) : +Supprimez la passkey avec l’endpoint [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) : ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId} \ @@ -471,7 +489,7 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{v ### Lier un nouveau TOTP \{#link-a-new-totp} :::note -N’oubliez pas d’[activer MFA et TOTP](/end-user-flows/mfa) au préalable. +N’oubliez pas d’[activer MFA et TOTP](/end-user-flows/mfa) d’abord. ::: :::note @@ -524,7 +542,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"Totp","secret":"..."}' ``` -- `verification_record_id` : un identifiant d’enregistrement de vérification valide, obtenu en vérifiant le facteur existant de l’utilisateur. Voir la section [Obtenir un identifiant d’enregistrement de vérification](#get-a-verification-record-id) pour plus de détails. +- `verification_record_id` : un ID d’enregistrement de vérification valide, obtenu en vérifiant le facteur existant de l’utilisateur. Voir la section [Obtenir un ID d’enregistrement de vérification](#get-a-verification-record-id) pour plus de détails. - `type` : doit être `Totp`. - `secret` : le secret TOTP généré à l’étape 1. @@ -535,7 +553,7 @@ Un utilisateur ne peut avoir qu’un seul facteur TOTP à la fois. Si l’utilis ### Gérer les codes de secours \{#manage-backup-codes} :::note -N’oubliez pas d’[activer MFA et les codes de secours](/end-user-flows/mfa) au préalable. +N’oubliez pas d’[activer MFA et les codes de secours](/end-user-flows/mfa) d’abord. ::: :::note @@ -562,14 +580,14 @@ Le corps de la réponse sera similaire à : **Étape 2 : Afficher les codes de secours à l’utilisateur** -Avant de lier les codes de secours au compte de l’utilisateur, vous devez les afficher à l’utilisateur et lui demander de : +Avant de lier les codes de secours au compte de l’utilisateur, vous devez les afficher à l’utilisateur et lui indiquer de : - Télécharger ou noter ces codes immédiatement - Les stocker dans un endroit sécurisé - Comprendre que chaque code ne peut être utilisé qu’une seule fois - Savoir que ces codes sont leur dernier recours s’ils perdent l’accès à leurs méthodes MFA principales -Vous devez afficher les codes dans un format clair et facile à copier et envisager de proposer une option de téléchargement (par exemple, sous forme de fichier texte ou PDF). +Vous devez afficher les codes dans un format clair et facile à copier et envisager de proposer une option de téléchargement (par exemple, en fichier texte ou PDF). **Étape 3 : Lier les codes de secours au compte utilisateur** @@ -583,7 +601,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"BackupCode","codes":["...","...","..."]}' ``` -- `verification_record_id` : un identifiant d’enregistrement de vérification valide, obtenu en vérifiant le facteur existant de l’utilisateur. Voir la section [Obtenir un identifiant d’enregistrement de vérification](#get-a-verification-record-id) pour plus de détails. +- `verification_record_id` : un ID d’enregistrement de vérification valide, obtenu en vérifiant le facteur existant de l’utilisateur. Voir la section [Obtenir un ID d’enregistrement de vérification](#get-a-verification-record-id) pour plus de détails. - `type` : doit être `BackupCode`. - `codes` : le tableau des codes de secours générés à l’étape précédente. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index 93ab85b821f..6077f50571e 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -2,9 +2,9 @@ sidebar_position: 2 --- -# Paramètres de l’écran initial +# Paramètres de l’écran d’accueil -Un ensemble de paramètres d’authentification personnalisés qui vous permettent d’adapter l’expérience de l’écran initial souhaitée pour les utilisateurs finaux. +Un ensemble de paramètres d’authentification personnalisés qui vous permettent d’adapter l’expérience du premier écran pour les utilisateurs finaux. - `first_screen` : Spécifie le premier écran que l’utilisateur verra. - `identifier` : Spécifie les types d’identifiants que le formulaire de connexion ou d’inscription acceptera. @@ -12,29 +12,33 @@ Un ensemble de paramètres d’authentification personnalisés qui vous permette ## first_screen \{#first_screen} -Le paramètre `first_screen` est le paramètre clé qui détermine le premier écran que les utilisateurs verront lorsqu’ils seront redirigés vers la page de connexion de Logto. Par défaut, le formulaire de connexion universel sera affiché. Utilisez ce paramètre pour personnaliser le premier écran en fonction des besoins de votre application. Les valeurs prises en charge sont : +Le paramètre `first_screen` est le paramètre clé qui détermine le premier écran que les utilisateurs verront lorsqu’ils seront redirigés vers la page de connexion Logto. Par défaut, le formulaire de connexion universel sera affiché. Utilisez ce paramètre pour personnaliser le premier écran selon les besoins de votre application. Les valeurs prises en charge sont : -- `sign_in` : Affiche le formulaire de connexion. (Par défaut) +- `sign_in` (Par défaut) : Affiche le formulaire de connexion. - `register` : Affiche le formulaire d’inscription. - `reset_password` : Affiche le formulaire de réinitialisation du mot de passe. - `single_sign_on` : Affiche le formulaire de connexion SSO d’entreprise. (Une adresse e-mail sera demandée pour déterminer les fournisseurs SSO activés) -- `identifier:sign-in` : Affiche un formulaire de connexion spécifique à un identifiant. Le type d’identifiant peut être spécifié à l’aide du paramètre `identifier`. Ceci est utile lorsque vous avez activé plusieurs méthodes de connexion par identifiant. -- `identifier:register` : Affiche un formulaire d’inscription spécifique à un identifiant. Le type d’identifiant peut être spécifié à l’aide du paramètre `identifier`. Ceci est utile lorsque vous avez activé plusieurs méthodes d’inscription par identifiant. +- `identifier:sign-in` : Affiche un formulaire de connexion spécifique à un identifiant. Le type d’identifiant peut être spécifié à l’aide du paramètre `identifier` (optionnel). Ceci est utile lorsque vous avez activé plusieurs méthodes de connexion par identifiant. +- `identifier:register` : Affiche un formulaire d’inscription spécifique à un identifiant. Le type d’identifiant peut être spécifié à l’aide du paramètre `identifier` (optionnel). Ceci est utile lorsque vous avez activé plusieurs méthodes d’inscription par identifiant. -Paramètre de l’écran initial +Paramètre de l’écran d’accueil -Par exemple, envoyer les utilisateurs directement au formulaire de connexion SSO d’entreprise : +Par exemple, envoyer les utilisateurs directement vers le formulaire de connexion SSO d’entreprise : ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +Le premier écran suivra les paramètres configurés dans Console > Expérience de connexion. Vous devez d’abord activer les méthodes d’authentification requises, puis configurer la personnalisation, les conditions générales, les politiques de confidentialité et l’internationalisation (i18n). Notez que seules les pages `sign-in` et `register` affichent le logo par défaut. +::: + ## identifier \{#identifier} Le paramètre `identifier` est utilisé pour spécifier les types d’identifiants que le formulaire de connexion ou d’inscription acceptera. Ce paramètre n’est applicable que lorsque le paramètre `first_screen` est défini sur `identifier:sign-in`, `identifier:register` ou `reset_password`. Les valeurs prises en charge sont : `username`, `email` et `phone`. Séparez plusieurs valeurs par un espace pour autoriser plusieurs types d’identifiants. -Par exemple, envoyer les utilisateurs directement à la page d’inscription par e-mail ou numéro de téléphone : +Par exemple, envoyer les utilisateurs directement vers la page d’inscription par e-mail ou numéro de téléphone : ```sh curl --location \ @@ -47,7 +51,7 @@ Tout type d’identifiant non pris en charge ou désactivé sera ignoré. Si tou ## login_hint \{#login_hint} -Le paramètre `login_hint`, défini dans la [spécification OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint), est utilisé pour pré-remplir le formulaire de connexion avec l’identifiant de l’utilisateur (comme un e-mail, un numéro de téléphone ou un nom d’utilisateur). Avec Logto, il peut être combiné avec d’autres paramètres d’écran de connexion pour améliorer l’expérience utilisateur. Ce paramètre est particulièrement utile si vous disposez d’un formulaire de pré-authentification personnalisé qui collecte l’identifiant de l’utilisateur à l’avance, lui permettant ainsi d’éviter de le ressaisir lors de la connexion. +Le paramètre `login_hint`, défini dans la [spécification OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint), est utilisé pour pré-remplir le formulaire de connexion avec l’identifiant de l’utilisateur (tel qu’un e-mail, un numéro de téléphone ou un nom d’utilisateur). Avec Logto, il peut être combiné avec d’autres paramètres d’écran de connexion pour améliorer l’expérience utilisateur. Ce paramètre est particulièrement utile si vous disposez d’un formulaire de pré-authentification personnalisé qui collecte l’identifiant de l’utilisateur à l’avance, lui permettant ainsi d’éviter de le ressaisir lors de la connexion. Par exemple, pré-remplir l’adresse e-mail collectée dans le formulaire de connexion : @@ -58,7 +62,7 @@ curl --location \ ## Prise en charge des SDK \{#sdk-support} -Dans les SDK Logto compatibles, vous pouvez définir les paramètres lors de l’appel de la méthode `signIn` : +Dans les SDK Logto pris en charge, vous pouvez définir les paramètres lors de l’appel de la méthode `signIn` : ```javascript logtoClient.signIn({ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index 214d798f15f..27821a639d8 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -2,15 +2,16 @@ sidebar_position: 1 --- -# Locales de l’interface utilisateur +# Langues de l’interface utilisateur -Logto prend en charge le paramètre standard d’authentification OIDC `ui_locales` pour contrôler la langue de l’expérience de connexion et des communications associées pour une interaction donnée. +Logto prend en charge le paramètre standard d’authentification OIDC `ui_locales` pour contrôler la langue de l’expérience de connexion et des communications ultérieures pour une interaction donnée. ## Ce que cela fait \{#what-it-does} -- Détermine la langue de l’interface utilisateur de l’expérience de connexion hébergée par Logto à l’exécution. Logto sélectionne la première balise de langue dans `ui_locales` qui est prise en charge dans la bibliothèque de langues de votre tenant. +- Détermine la langue de l’interface utilisateur de l’expérience de connexion hébergée par Logto à l’exécution. Logto choisit la première balise de langue dans `ui_locales` qui est prise en charge dans la bibliothèque de langues de votre locataire. - Affecte la localisation des e-mails pour les messages déclenchés par l’interaction (par exemple, les e-mails de code de vérification). Voir [Localisation des modèles d’e-mails](/connectors/email-connectors/email-templates#email-template-localization). -- Expose la valeur d’origine aux modèles d’e-mails sous forme de variable `uiLocales`, ce qui vous permet de l’inclure dans l’objet ou le contenu de l’e-mail si nécessaire. +- Expose la valeur d’origine aux modèles d’e-mails sous forme de variable `uiLocales`, vous permettant de l’inclure dans l’objet / contenu de l’e-mail si nécessaire. +- Définit l’indicatif pays par défaut pour les numéros de téléphone dans l’expérience de connexion. Par exemple, si `ui_locales=fr`, le champ de saisie du numéro de téléphone sera par défaut la France (+33). Ceci est utile lorsque vous souhaitez contrôler l’indicatif pays par défaut de manière programmatique pour des groupes d’utilisateurs ou des régions spécifiques. ## Format du paramètre \{#parameter-format} @@ -25,7 +26,7 @@ Lors de la détermination de la langue de l’interface utilisateur pour l’exp 1. `ui_locales` de la requête d’authentification en cours (la première balise prise en charge l’emporte). 2. Sinon, l’en-tête `Accept-Language` (Experience APIs / User Account APIs) ou `messagePayload.locale` (Management APIs comme les invitations d’organisation). -3. Sinon, la langue par défaut du tenant configurée dans l’Expérience de connexion. +3. Sinon, la langue par défaut du locataire configurée dans l’Expérience de connexion. Ce comportement ne modifie pas de façon permanente vos paramètres de langue ; il ne s’applique qu’à l’interaction en cours. @@ -45,7 +46,7 @@ await logtoClient.signIn({ ## Exemples \{#examples} - `ui_locales=fr-CA fr en` → Si `fr-CA` existe dans votre bibliothèque de langues, l’interface de connexion s’affiche en français (Canada) ; sinon, elle passe à `fr`, puis à `en`. -- `ui_locales=ja` mais le japonais n’est pas activé → Bascule vers `Accept-Language` ou la langue par défaut du tenant. +- `ui_locales=ja` mais le japonais n’est pas activé → Bascule vers `Accept-Language` ou la langue par défaut du locataire. ## Liens associés \{#related} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index 661d8c45c2d..f322ec382ec 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -6,41 +6,42 @@ sidebar_position: 2 ## Configurer le flux de connexion par identifiant \{#configure-the-identifier-sign-in-flow} -Comme mentionné précédemment, divers types d'identifiants peuvent être collectés auprès des utilisateurs tout au long du [flux d'inscription](/end-user-flows/sign-up-and-sign-in/sign-up) ou [création directe de compte dans Logto](/user-management/manage-users#add-users). De plus, les utilisateurs peuvent entrer et compléter des informations supplémentaires au fur et à mesure qu'ils explorent et utilisent le produit. Ces identifiants peuvent être utilisés pour identifier de manière unique les utilisateurs dans le système de Logto et leur permettre d'être authentifiés et de se connecter aux applications intégrées à Logto. +Comme indiqué précédemment, différents types d'identifiants peuvent être collectés auprès des utilisateurs tout au long du [flux d'inscription](/end-user-flows/sign-up-and-sign-in/sign-up) ou lors de la [création directe de compte dans Logto](/user-management/manage-users#add-users). De plus, les utilisateurs peuvent saisir et compléter des informations supplémentaires au fur et à mesure qu'ils explorent et utilisent le produit. Ces identifiants peuvent être utilisés pour identifier de manière unique les utilisateurs dans le système de Logto et leur permettre d'être authentifiés et de se connecter aux applications intégrées à Logto. -Que vous choisissiez d'utiliser la page de connexion pré-construite hébergée par Logto ou que vous planifiez de [construire votre propre interface de connexion personnalisée](/customization#custom-ui), vous devrez configurer les méthodes de connexion disponibles et les paramètres de vérification pour vos utilisateurs finaux. +Que vous choisissiez d'utiliser la page de connexion pré-construite hébergée par Logto ou que vous prévoyiez de [créer votre propre interface de connexion personnalisée](/customization#custom-ui), vous devrez configurer les méthodes de connexion disponibles et les paramètres de vérification pour vos utilisateurs finaux. -## Configurer les paramètres d'identifiant et d'authentification \{#set-up-the-identifier-and-authentication-settings} +## Définir les paramètres d'identifiant et d'authentification \{#set-up-the-identifier-and-authentication-settings} ### 1. Définir les identifiants de connexion pris en charge \{#1-set-the-supported-sign-in-identifiers} -Vous pouvez ajouter plusieurs identifiants pris en charge à partir de la liste déroulante en tant que méthodes de connexion activées pour les utilisateurs finaux. Les options disponibles sont : +Vous pouvez ajouter plusieurs identifiants pris en charge à partir de la liste déroulante comme méthodes de connexion activées pour les utilisateurs finaux. Les options disponibles sont : - **Nom d'utilisateur** - **Adresse e-mail** - **Numéro de téléphone** -Réorganiser les identifiants changera l'ordre dans lequel ils sont affichés sur la page de connexion. Le premier identifiant sera la méthode de connexion principale pour les utilisateurs. +Le réordonnancement des identifiants modifiera l'ordre dans lequel ils sont affichés sur la page de connexion. Le premier identifiant sera la méthode de connexion principale pour les utilisateurs. ### 2. Définir les paramètres d'authentification \{#2-set-the-authentication-settings} -Pour chaque identifiant de connexion, vous devrez configurer au moins un facteur de vérification efficace pour vérifier l'identité de l'utilisateur. Il y a deux facteurs parmi lesquels vous pouvez choisir : +Pour chaque identifiant de connexion, vous devrez configurer au moins un facteur de vérification efficace pour vérifier l'identité de l'utilisateur. Deux facteurs sont disponibles : -- **Mot de passe** : Disponible pour tous les types d'identifiants de connexion. Une fois activé, les utilisateurs doivent fournir un mot de passe pour compléter le processus de connexion. -- **Code de vérification** : Disponible uniquement pour les identifiants **Adresse e-mail** et **Numéro de téléphone**. Une fois activé, les utilisateurs doivent entrer un code de vérification envoyé à leur e-mail ou numéro de téléphone pour compléter le processus de connexion. +- **Mot de passe** : Disponible pour tous les types d'identifiants de connexion. Une fois activé, les utilisateurs doivent fournir un mot de passe pour terminer le processus de connexion. +- **Code de vérification** : Disponible uniquement pour les identifiants **Adresse e-mail** et **Numéro de téléphone**. Une fois activé, les utilisateurs doivent saisir un code de vérification envoyé à leur adresse e-mail ou à leur numéro de téléphone pour terminer le processus de connexion. -Si les deux facteurs sont activés, les utilisateurs peuvent choisir l'une ou l'autre méthode pour compléter le processus de connexion. Vous pouvez également réorganiser les facteurs pour changer l'ordre dans lequel ils sont affichés sur la page de connexion. Le premier facteur sera utilisé comme méthode de vérification principale pour les utilisateurs et le second sera affiché comme lien alternatif. +Si les deux facteurs sont activés, les utilisateurs peuvent choisir l'une ou l'autre méthode pour terminer le processus de connexion. Vous pouvez également réorganiser les facteurs pour modifier l'ordre dans lequel ils sont affichés sur la page de connexion. Le premier facteur sera utilisé comme méthode de vérification principale pour les utilisateurs et le second sera affiché comme lien alternatif. ## Expérience utilisateur du flux de connexion par identifiant \{#identifier-sign-in-flow-user-experience} L'expérience de connexion s'adapte en fonction de l'identifiant choisi et des facteurs d'authentification disponibles. - **Saisie intelligente pour plusieurs identifiants :** - Si plus d'une méthode de connexion par identifiant est activée, la page de connexion intégrée de Logto détectera automatiquement le type d'identifiant saisi par l'utilisateur et affichera les options de vérification correspondantes. Par exemple, si les deux **Adresse e-mail** et **Numéro de téléphone** sont activés, la page de connexion détectera automatiquement le type d'identifiant saisi par l'utilisateur et affichera les options de vérification correspondantes. Elle passe à un format de numéro de téléphone avec code régional si des chiffres sont saisis consécutivement ou à un format d'e-mail lorsqu'un symbole "@" est utilisé. + Si plus d'une méthode de connexion par identifiant est activée, la page de connexion intégrée de Logto détectera automatiquement le type d'identifiant saisi par l'utilisateur et affichera les options de vérification correspondantes. Par exemple, si **Adresse e-mail** et **Numéro de téléphone** sont toutes deux activées, la page de connexion détectera automatiquement le type d'identifiant saisi par l'utilisateur et affichera les options de vérification correspondantes. Elle bascule vers un format de numéro de téléphone avec indicatif régional si des chiffres sont saisis consécutivement ou vers un format e-mail lorsqu'un symbole "@" est utilisé. + - L'indicatif pays du numéro de téléphone est défini par défaut selon la langue du navigateur de l'utilisateur ; les utilisateurs peuvent le modifier manuellement. Vous pouvez utiliser le paramètre [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) pour définir un indicatif pays par défaut spécifique. Voir [Langues localisées](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience) pour plus de détails. - **Facteurs de vérification activés :** - - **Mot de passe uniquement :** Les champs d'identifiant et de mot de passe seront affichés sur le premier écran. - - **Code de vérification uniquement :** Le champ d'identifiant apparaît sur le premier écran, suivi du champ de code de vérification sur le deuxième écran. - - **Mot de passe et code de vérification :** Le champ d'identifiant est saisi initialement sur le premier écran, suivi des étapes pour entrer le mot de passe ou le code de vérification sur le deuxième écran en fonction de l'ordre de vérification. Un lien de basculement est fourni pour permettre aux utilisateurs de passer d'une méthode de vérification à l'autre. + - **Mot de passe uniquement :** Les champs identifiant et mot de passe seront affichés sur le premier écran. + - **Code de vérification uniquement :** Le champ identifiant apparaît sur le premier écran, suivi du champ code de vérification sur le second écran. + - **Mot de passe et code de vérification :** Le champ identifiant est saisi initialement sur le premier écran, suivi des étapes pour saisir le mot de passe ou le code de vérification sur le second écran selon l'ordre de vérification. Un lien de bascule est proposé pour permettre aux utilisateurs de passer d'une méthode de vérification à l'autre. ### Exemples \{#examples} @@ -51,7 +52,7 @@ L'expérience de connexion s'adapte en fonction de l'identifiant choisi et des f -Ajoutez l'**Adresse e-mail** comme identifiant de connexion et activez le facteur **Mot de passe** pour la vérification. +Ajoutez **Adresse e-mail** comme identifiant de connexion et activez le facteur **Mot de passe** pour la vérification. E-mail / Téléphone avec mot de passe et vérification par code -## Collecter des informations de profil utilisateur supplémentaires lors de la connexion \{#collect-additional-user-profile-on-sign-in} +## Collecter des informations supplémentaires sur le profil utilisateur lors de la connexion \{#collect-additional-user-profile-on-sign-in} -Dans le flux de connexion de Logto, un processus de remplissage de profil peut être déclenché si les paramètres d'identifiant d'inscription sont mis à jour. Cela garantit que tous les utilisateurs, y compris ceux existants, fournissent les nouveaux identifiants requis. +Dans le flux de connexion de Logto, un processus de complétion du profil peut être déclenché si les paramètres d'identifiant d'inscription sont mis à jour. Cela garantit que tous les utilisateurs, y compris les existants, fournissent les nouveaux identifiants requis. -Lorsqu'un développeur ajoute un nouvel identifiant (comme une adresse e-mail), il devient obligatoire pour tous les utilisateurs. Si un utilisateur de retour se connecte avec un identifiant existant (comme un nom d'utilisateur), il sera invité à fournir et à vérifier le nouvel identifiant s'il manque à son profil. Ce n'est qu'après avoir terminé cette étape qu'il pourra accéder à l'application, garantissant une transition fluide et cohérente vers les nouvelles exigences. +Lorsqu'un développeur ajoute un nouvel identifiant (comme une adresse e-mail), il devient obligatoire pour tous les utilisateurs. Si un utilisateur existant se connecte avec un identifiant existant (comme un nom d'utilisateur), il sera invité à fournir et à vérifier le nouvel identifiant s'il manque à son profil. Ce n'est qu'après avoir terminé cette étape qu'il pourra accéder à l'application, assurant ainsi une transition fluide et cohérente vers les nouvelles exigences. Décomposition du processus : 1. **Nom d'utilisateur** était précédemment défini comme identifiant d'inscription avec le paramètre **Créer votre mot de passe** activé automatiquement. 2. **Adresse e-mail** est ensuite définie comme identifiant d'inscription. L'identifiant **Adresse e-mail** est automatiquement ajouté comme option de connexion activée. -3. Un utilisateur de retour se connecte avec son nom d'utilisateur et son mot de passe. +3. Un utilisateur existant se connecte avec son nom d'utilisateur et son mot de passe. 4. L'utilisateur est invité à fournir et à vérifier une adresse e-mail après sa première étape de connexion. ```mermaid flowchart TD - A[Visiter la page de connexion] --> B[Entrer le nom d'utilisateur et le mot de passe] + A[Visiter la page de connexion] --> B[Saisir le nom d'utilisateur et le mot de passe] B -.-> C{{Adresse e-mail requise et manquante ?}} - C -->|Oui| D[Entrer l'adresse e-mail] - D --> E[Entrer le code de vérification] + C -->|Oui| D[Saisir l'adresse e-mail] + D --> E[Saisir le code de vérification] E --> F[Connexion réussie] C --> |Non| F ``` -Le même processus s'applique également aux paramètres d'inscription **Créer votre mot de passe**. Si les paramètres **Créer votre mot de passe** sont nouvellement activés dans le flux d'inscription, le facteur **Mot de passe** sera automatiquement activé pour tous les identifiants de connexion que vous choisissez. Tous les utilisateurs de retour sans mot de passe seront invités à en créer un lors du processus de connexion. +Le même processus s'applique également aux paramètres d'inscription **Créer votre mot de passe**. Si les paramètres **Créer votre mot de passe** sont nouvellement activés dans le flux d'inscription, le facteur **Mot de passe** sera automatiquement activé pour tous les identifiants de connexion que vous choisissez. Tous les utilisateurs existants sans mot de passe seront invités à en créer un lors du processus de connexion. :::note -Note : Pour des flux de connexion personnalisés, consultez la fonctionnalité [Apportez votre interface utilisateur](/customization/bring-your-ui/). +Remarque : Pour des flux de connexion personnalisés, reportez-vous à la fonctionnalité [Apportez votre interface](/customization/bring-your-ui/). ::: -## FAQs \{#faqs} +## FAQ \{#faqs}
@@ -115,7 +116,7 @@ Note : Pour des flux de connexion personnalisés, consultez la fonctionnalité [ -Logto ne prend actuellement pas en charge l'API sans interface pour la connexion et l'inscription. Cependant, vous pouvez utiliser notre fonctionnalité [Apportez votre interface utilisateur](/customization/bring-your-ui/) pour télécharger votre formulaire de connexion personnalisé sur Logto. Nous prenons également en charge plusieurs paramètres de connexion que vous pouvez utiliser pour pré-remplir le formulaire de connexion avec l'identifiant utilisateur collecté à partir de votre application ou vous connecter directement avec un fournisseur SSO social ou d'entreprise tiers. En savoir plus sur [Paramètres d'authentification](/end-user-flows/authentication-parameters/). +Logto ne prend actuellement pas en charge l'API headless pour la connexion et l'inscription. Cependant, vous pouvez utiliser notre fonctionnalité [Apportez votre interface](/customization/bring-your-ui/) pour téléverser votre formulaire de connexion personnalisé dans Logto. Nous prenons également en charge plusieurs paramètres de connexion que vous pouvez utiliser pour pré-remplir le formulaire de connexion avec l'identifiant utilisateur collecté depuis votre application ou pour vous connecter directement avec un fournisseur social ou SSO d’entreprise tiers. En savoir plus sur [Paramètres d’authentification](/end-user-flows/authentication-parameters/).
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index 1999e0e232d..7aa13e69e96 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -4,7 +4,7 @@ sidebar_position: 1 # Inscription par e-mail / téléphone / nom d'utilisateur -L'inscription des utilisateurs est la première étape pour qu'ils interagissent avec votre application. Logto prend en charge une variété de méthodes d'inscription, y compris le nom d'utilisateur et mot de passe, la vérification par e-mail ou numéro de téléphone, [inscription sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in), et [SSO d’entreprise](/end-user-flows/enterprise-sso). Vous pouvez configurer les méthodes d'inscription qui correspondent le mieux aux besoins de votre application. +L'inscription des utilisateurs est la première étape pour qu'ils interagissent avec votre application. Logto prend en charge une variété de méthodes d'inscription, notamment le nom d'utilisateur et mot de passe, la vérification par e-mail ou numéro de téléphone, [inscription sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in), et [SSO d’entreprise](/end-user-flows/enterprise-sso). Vous pouvez configurer les méthodes d'inscription qui correspondent le mieux aux besoins de votre application. Rendez-vous sur Console > Expérience de connexion > Inscription et connexion pour commencer à configurer le flux d'inscription par identifiant. @@ -12,32 +12,42 @@ Rendez-vous sur Console ## Configurer l'identifiant d'inscription \{#set-up-the-sign-up-identifier} -Pour créer avec succès un nouveau compte utilisateur dans Logto, les utilisateurs doivent fournir au moins un **identifiant** qui les identifie de manière unique dans le système Logto. En première étape, sélectionnez les identifiants que les utilisateurs devront fournir lors du processus d'inscription. Les options disponibles sont : +Pour créer avec succès un nouveau compte utilisateur dans Logto, les utilisateurs doivent fournir au moins un **identifiant** qui les identifie de manière unique dans le système Logto. Comme première étape, sélectionnez les identifiants que les utilisateurs doivent fournir lors du processus d'inscription. Les options disponibles sont : - **Nom d'utilisateur** : Un [nom d'utilisateur](/user-management/user-data#username) unique que l'utilisateur peut utiliser pour se connecter à l'application. - **Adresse e-mail** : Une [adresse e-mail](/user-management/user-data#primary_email) valide que l'utilisateur peut utiliser pour se connecter à l'application. - **Numéro de téléphone** : Un [numéro de téléphone](/user-management/user-data#primary_phone) valide que l'utilisateur peut utiliser pour se connecter à l'application. - **Adresse e-mail ou numéro de téléphone** : Permettre aux utilisateurs de s'inscrire avec une adresse e-mail valide ou un numéro de téléphone. -Tous les identifiants collectés lors du processus d'inscription doivent être uniques pour chaque utilisateur sous le même tenant. Ils seront stockés dans le [profil de l'utilisateur](/user-management/user-data#user-profile) et pourront être utilisés pour se connecter aux applications intégrées à Logto. +Tous les identifiants collectés lors du processus d'inscription doivent être uniques pour chaque utilisateur au sein du même tenant. Ils seront stockés dans le [profil de l'utilisateur](/user-management/user-data#user-profile) et pourront être utilisés pour se connecter aux applications intégrées à Logto. Si aucun identifiant n'est sélectionné, cela s'applique aux méthodes d'inscription [sociales](/end-user-flows/sign-up-and-sign-in/social-sign-in) uniquement ou [SSO d’entreprise](/end-user-flows/enterprise-sso) uniquement. Vous pouvez ajuster l'ordre des identifiants d'inscription pour donner la priorité à celui que vous souhaitez que les utilisateurs fournissent en premier lors de l'inscription. Cet ordre se reflète dans le processus d'inscription, où le premier identifiant apparaît sur l'écran d'inscription initial, et les autres sont collectés dans les étapes suivantes. +:::tip +Pour bloquer certains types d'adresses e-mail lors de l'inscription (telles que les e-mails jetables, le sous-adressage avec des signes plus (+), des adresses e-mail spécifiques ou des domaines entiers), utilisez la fonctionnalité **liste de blocage** dans la section Sécurité. Voir [Liste de blocage](/security/blocklist) pour plus de détails. +::: + +:::tip +Le **code pays** du numéro de téléphone est défini par défaut selon la langue du navigateur de l'utilisateur. Par exemple, si la langue du navigateur de l'utilisateur est `fr`, le code pays sera par défaut la France (+33). + +Vous pouvez également utiliser le paramètre d'authentification [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) pour définir la langue de l'expérience de connexion, ce qui déterminera aussi le code pays par défaut. +::: + ## Configurer les paramètres de vérification à l'inscription \{#set-up-the-sign-up-verification-settings} -Pour garantir la sécurité de l'inscription et des futures connexions, vous devez également configurer les paramètres de vérification pour les identifiants collectés lors de l'inscription. Les paramètres disponibles sont : +Pour garantir la sécurité du processus d'inscription et de connexion futur, vous devez également configurer les paramètres de vérification pour les identifiants collectés lors de l'inscription. Les paramètres disponibles sont : -- **Créer votre mot de passe :** Exiger que les utilisateurs créent un mot de passe lors de l'inscription, conforme à la politique de mot de passe configurée dans vos paramètres d'expérience de connexion. Ce mot de passe, avec l'identifiant de l'utilisateur, sert de justificatif pour se connecter à l'application. Si vous définissez **Nom d'utilisateur** comme identifiant d'inscription, cette exigence est automatiquement activée, car le **Nom d'utilisateur** ne peut être utilisé qu'avec un mot de passe pour vérifier efficacement l'identité de l'utilisateur. La [politique de mot de passe](/security/password-policy) peut être personnalisée selon vos exigences de sécurité. -- **Vérifier à l'inscription** : Exiger que les utilisateurs vérifient leur adresse e-mail ou leur numéro de téléphone lors de l'inscription. Actuellement, Logto n'accepte que les e-mails et numéros de téléphone vérifiés comme identifiants. Ce paramètre est automatiquement activé lorsqu'une **Adresse e-mail** ou un **Numéro de téléphone** est utilisé comme identifiant d'inscription. Les utilisateurs doivent confirmer la propriété en saisissant un code de vérification envoyé à leur e-mail ou numéro de téléphone lors de l'inscription. +- **Créer votre mot de passe :** Exiger que les utilisateurs créent un mot de passe lors de l'inscription, conforme à la politique de mot de passe configurée dans vos paramètres d'expérience de connexion. Ce mot de passe, avec l'identifiant de l'utilisateur, sert de justificatif pour se connecter à l'application. Si vous définissez **Nom d'utilisateur** comme identifiant d'inscription, cette exigence est automatiquement activée, car le **nom d'utilisateur** ne peut être utilisé qu'avec un mot de passe pour vérifier efficacement l'identité de l'utilisateur. La [politique de mot de passe](/security/password-policy) peut être personnalisée selon vos exigences de sécurité. +- **Vérifier à l'inscription** : Exiger que les utilisateurs vérifient leur adresse e-mail ou leur numéro de téléphone lors de l'inscription. Actuellement, Logto n'accepte que les e-mails et numéros de téléphone vérifiés comme identifiants. Ce paramètre est automatiquement activé lorsqu'une **adresse e-mail** ou un **numéro de téléphone** est utilisé comme identifiant d'inscription. Les utilisateurs doivent confirmer la propriété en saisissant un code de vérification envoyé à leur e-mail ou numéro de téléphone lors de l'inscription. | Identifiant | Créer un mot de passe utilisateur | Vérifier à l'inscription | | ------------------- | --------------------------------- | ------------------------ | | Nom d'utilisateur | Optionnel | N/A | -| Adresse e-mail | Optionnel | Requis | -| Numéro de téléphone | Optionnel | Requis | -| E-mail ou téléphone | Optionnel | Requis | +| Adresse e-mail | Optionnel | Obligatoire | +| Numéro de téléphone | Optionnel | Obligatoire | +| E-mail ou téléphone | Optionnel | Obligatoire | ## Exemples de flux d'inscription \{#sign-up-flow-examples} @@ -48,7 +58,7 @@ Pour garantir la sécurité de l'inscription et des futures connexions, vous dev -Sélectionnez le **Nom d'utilisateur** comme identifiant d'inscription. Créer votre mot de passe est activé automatiquement. +Sélectionnez le **nom d'utilisateur** comme identifiant d'inscription. La création du mot de passe est activée automatiquement. -Sélectionnez **Adresse e-mail ou numéro de téléphone** comme identifiant d'inscription. **Vérifier à l'inscription** est obligatoirement activé. +Sélectionnez **adresse e-mail ou numéro de téléphone** comme identifiant d'inscription. **Vérifier à l'inscription** est obligatoirement activé. -Sélectionnez **Adresse e-mail** comme identifiant d'inscription. **Vérifier à l'inscription** est obligatoirement activé. Activez **Créer votre mot de passe** pour exiger que les utilisateurs créent un mot de passe lors de l'inscription. (Il en va de même pour le flux d'inscription par numéro de téléphone) +Sélectionnez **adresse e-mail** comme identifiant d'inscription. **Vérifier à l'inscription** est obligatoirement activé. Activez **Créer votre mot de passe** pour exiger que les utilisateurs créent un mot de passe lors de l'inscription. (Il en va de même pour le flux d'inscription par numéro de téléphone) -Sélectionnez **Adresse e-mail** et **Nom d'utilisateur** comme identifiants d'inscription. **Vérifier à l'inscription** est obligatoirement activé. Activez **Créer votre mot de passe** pour exiger que les utilisateurs créent un mot de passe lors de l'inscription. +Sélectionnez **adresse e-mail** et **nom d'utilisateur** comme identifiants d'inscription. **Vérifier à l'inscription** est obligatoirement activé. Activez **Créer votre mot de passe** pour exiger que les utilisateurs créent un mot de passe lors de l'inscription. -## Inscription avec social ou SSO d’entreprise \{#sign-up-with-social-or-enterprise-sso} +## S'inscrire avec un connecteur social ou SSO d’entreprise \{#sign-up-with-social-or-enterprise-sso} -En plus de ces méthodes d'inscription traditionnelles par identifiant, Logto prend également en charge l'inscription sans mot de passe via des fournisseurs d'identité sociale et SSO d’entreprise, rendant le processus d'intégration plus fluide et convivial. +En plus de ces méthodes d'inscription traditionnelles par identifiant, Logto prend également en charge l'inscription sans mot de passe avec des fournisseurs d'identité sociaux et SSO d’entreprise, rendant le processus d'intégration plus fluide et convivial. -Une fois qu'un [connecteur social](/connectors/social-connectors) ou un [connecteur SSO d’entreprise](/connectors/enterprise-connectors) est configuré et activé dans Logto, les utilisateurs peuvent facilement s'inscrire en utilisant leur identité sociale ou d’entreprise existante fournie par le connecteur. Les méthodes d'inscription sociale et SSO d’entreprise permettent aux utilisateurs de passer outre les étapes supplémentaires telles que la création d'un mot de passe ou la vérification de leur adresse e-mail ou numéro de téléphone. Logto synchronisera automatiquement les informations de l'utilisateur via leur identité sociale ou d’entreprise vérifiée et les stockera dans le profil de l'utilisateur. +Une fois qu'un [connecteur social](/connectors/social-connectors) ou [connecteur SSO d’entreprise](/connectors/enterprise-connectors) est configuré et activé dans Logto, les utilisateurs peuvent facilement s'inscrire en utilisant leur identité sociale ou d’entreprise existante fournie par le connecteur. Les méthodes d'inscription sociale et SSO d’entreprise permettent aux utilisateurs de passer outre les étapes supplémentaires telles que la création d'un mot de passe ou la vérification de leur adresse e-mail ou numéro de téléphone. Logto synchronisera automatiquement les informations de l'utilisateur via leur identité sociale ou d’entreprise vérifiée et les stockera dans le profil de l'utilisateur. Consultez les sections [connexion sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in/) et [SSO d’entreprise](/end-user-flows/enterprise-sso/) pour en savoir plus sur le flux d'inscription avec les connecteurs sociaux et SSO d’entreprise. @@ -121,11 +131,11 @@ Remarque : Pour des flux d'inscription personnalisés, consultez la fonctionnali Pour collecter des informations supplémentaires sur le profil utilisateur (par exemple, nom complet, date de naissance, nom de l'entreprise) lors de l'inscription, vous disposez de deux options flexibles : -**Option 1 : Collecter le profil utilisateur** +**Option 1 : Collecte du profil utilisateur** -Ajoutez l'étape préconstruite "Parlez-nous de vous" de Logto directement dans le flux d'inscription. Les utilisateurs doivent remplir tous les champs obligatoires avant que l'inscription ne soit considérée comme terminée. Cette approche offre une solution sans code et prête à l'emploi. +Ajoutez directement l'étape préconstruite "Parlez-nous de vous" de Logto dans le flux d'inscription. Les utilisateurs doivent remplir tous les champs obligatoires avant que l'inscription ne soit considérée comme terminée. Cette approche offre une solution sans code et prête à l'emploi. -Configurez la collecte de profil via Console > Expérience de connexion > Collecter le profil utilisateur pour choisir parmi des champs de données de base préconfigurés ou créer des champs personnalisés avec une validation flexible. En savoir plus : [Collecter le profil utilisateur](/end-user-flows/collect-user-profile) +Configurez la collecte du profil via Console > Expérience de connexion > Collecter le profil utilisateur pour choisir parmi les champs de données de base préconfigurés ou créer des champs personnalisés avec une validation flexible. En savoir plus : [Collecter le profil utilisateur](/end-user-flows/collect-user-profile) **Option 2 : Flux d'intégration auto-hébergés** @@ -138,7 +148,7 @@ Utilisez l'[Account API](/end-user-flows/account-settings/by-account-api) pour g
-### Utilisateurs créés par l’admin / Utilisateurs invités \{#admin-created-users--invited-users} +### Utilisateurs créés par l'admin / Utilisateurs invités \{#admin-created-users--invited-users} @@ -153,14 +163,14 @@ Découvrez comment mettre en œuvre le [flux d'inscription sur invitation unique -Logto ne prend actuellement pas en charge l'API headless pour la connexion et l'inscription. Vous pouvez utiliser la fonctionnalité [Apportez votre UI](/customization/bring-your-ui/) pour télécharger votre propre formulaire d'inscription sur Logto ou utiliser les paramètres de connexion pour transmettre les informations utilisateur de votre site web à Logto. En savoir plus sur la transmission des identifiants utilisateur dans [Paramètres d'authentification](/end-user-flows/authentication-parameters/). +Logto ne prend actuellement pas en charge l'API headless pour la connexion et l'inscription. Vous pouvez utiliser la fonctionnalité [Apportez votre UI](/customization/bring-your-ui/) pour téléverser votre propre formulaire d'inscription sur Logto ou utiliser les paramètres de connexion pour transmettre les informations utilisateur de votre site web à Logto. En savoir plus sur la transmission des identifiants utilisateur dans [Paramètres d'authentification](/end-user-flows/authentication-parameters/).
-### Envoi d'e-mails de bienvenue aux nouveaux utilisateurs \{#sending-welcome-emails-to-new-users} +### Envoyer des e-mails de bienvenue aux nouveaux utilisateurs \{#sending-welcome-emails-to-new-users} @@ -175,8 +185,8 @@ Abonnez-vous à l'événement webhook `User.Created` pour déclencher un e-mail -Actuellement, Logto ne prend en charge que les e-mails et numéros de téléphone vérifiés comme identifiants. Le processus de vérification est requis pour garantir la sécurité et la propriété de l'identifiant de l'utilisateur. -La prise en charge des e-mails ou numéros de téléphone non vérifiés figure sur notre [roadmap](https://feedback.logto.io/roadmap). Restez à l'écoute pour les mises à jour ! +Actuellement, Logto ne prend en charge que les e-mails et numéros de téléphone vérifiés comme identifiants. Le processus de vérification est requis pour garantir la sécurité et la propriété de l'identifiant utilisateur. +La prise en charge des e-mails ou numéros de téléphone non vérifiés est sur notre [feuille de route](https://feedback.logto.io/roadmap). Restez à l'écoute pour les mises à jour !
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 81d078e8db6..346f17779f2 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -3,149 +3,153 @@ description: Consultez les principaux paramètres d'application pour l'intégrat sidebar_position: 6 --- -# Structure des données de l'application +# Structure des données d’application ## Introduction \{#introduction} -Dans Logto, une _application_ fait référence à un programme ou service logiciel spécifique qui est enregistré sur la plateforme Logto et qui a reçu l'autorisation d'accéder aux informations utilisateur ou d'effectuer des actions au nom d'un utilisateur. Les applications sont utilisées pour identifier la source des requêtes faites à l'API Logto, ainsi que pour gérer le processus d'authentification et d'autorisation pour les utilisateurs accédant à ces applications. +Dans Logto, une _application_ désigne un programme ou service logiciel spécifique qui est enregistré sur la plateforme Logto et qui a reçu l'autorisation d'accéder aux informations utilisateur ou d'effectuer des actions au nom d'un utilisateur. Les applications servent à identifier la source des requêtes faites à l’API Logto, ainsi qu’à gérer le processus d’authentification et d’autorisation pour les utilisateurs accédant à ces applications. -L'utilisation des applications dans l'expérience de connexion de Logto permet aux utilisateurs d'accéder facilement et de gérer leurs applications autorisées à partir d'un emplacement unique, avec un processus d'authentification cohérent et sécurisé. Cela aide à rationaliser l'expérience utilisateur et à garantir que seules les personnes autorisées accèdent aux informations sensibles ou effectuent des actions au nom de l'organisation. +L’utilisation des applications dans l’Expérience de connexion (Sign-in experience) de Logto permet aux utilisateurs d’accéder facilement à leurs applications autorisées et de les gérer depuis un emplacement unique, avec un processus d’authentification cohérent et sécurisé. Cela permet de simplifier l’expérience utilisateur et de garantir que seules les personnes autorisées accèdent à des informations sensibles ou effectuent des actions au nom de l’organisation. -Les applications sont également utilisées dans les journaux d'audit de Logto pour suivre l'activité des utilisateurs et identifier toute menace ou violation de sécurité potentielle. En associant des actions spécifiques à une application particulière, Logto peut fournir des informations détaillées sur la façon dont les données sont accédées et utilisées, permettant aux organisations de mieux gérer leurs exigences de sécurité et de conformité. -Si vous souhaitez intégrer votre application avec Logto, consultez [Intégrer Logto](/integrate-logto). +Les applications sont également utilisées dans les journaux d’audit de Logto pour suivre l’activité des utilisateurs et identifier toute menace ou violation potentielle de la sécurité. En associant des actions spécifiques à une application particulière, Logto peut fournir des informations détaillées sur la façon dont les données sont consultées et utilisées, permettant ainsi aux organisations de mieux gérer leurs exigences en matière de sécurité et de conformité. +Si vous souhaitez intégrer votre application à Logto, consultez [Intégrer Logto](/integrate-logto). ## Propriétés \{#properties} -### ID de l'application \{#application-id} +### ID d’application \{#application-id} -_L'ID de l'application_ est une clé unique générée automatiquement pour identifier votre application dans Logto, et est référencé comme [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) dans OAuth 2.0. +_L’ID d’application_ est une clé unique générée automatiquement pour identifier votre application dans Logto, et est référencée comme [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) dans OAuth 2.0. -### Types d'application \{#application-types} +### Types d’application \{#application-types} -Une _application_ peut être l'un des types d'application suivants : +Une _application_ peut être l’un des types suivants : -- **Application native** est une application qui s'exécute dans un environnement natif. Par exemple, application iOS, application Android. -- **Application à page unique** est une application qui s'exécute dans un navigateur web, qui met à jour la page avec les nouvelles données du serveur sans charger de nouvelles pages entières. Par exemple, application React DOM, application Vue. -- **Application web traditionnelle** est une application qui rend et met à jour les pages uniquement par le serveur web. Par exemple, JSP, PHP. -- **Application machine à machine (M2M)** est une application qui s'exécute dans un environnement machine pour une communication directe de service à service sans interaction utilisateur. +- **Application native** : une application qui s’exécute dans un environnement natif. Par exemple, application iOS, application Android. +- **Application monopage (Single page app)** : une application qui s’exécute dans un navigateur web, qui met à jour la page avec de nouvelles données du serveur sans recharger entièrement la page. Par exemple, application React DOM, application Vue. +- **Application web traditionnelle** : une application qui rend et met à jour les pages uniquement via le serveur web. Par exemple, JSP, PHP. +- **Application machine à machine (M2M)** : une application qui s’exécute dans un environnement machine pour une communication directe service à service sans interaction utilisateur. -### Secret de l'application \{#application-secret} +### Secret d’application \{#application-secret} -_Le secret de l'application_ est une clé utilisée pour authentifier l'application dans le système d'authentification, spécifiquement pour les clients privés (applications Web traditionnelles et M2M) en tant que barrière de sécurité privée. +_Le secret d’application_ est une clé utilisée pour authentifier l’application dans le système d’authentification, spécifiquement pour les clients privés (applications web traditionnelles et M2M) en tant que barrière de sécurité privée. -### Nom de l'application \{#application-name} +:::tip +Les applications monopages (SPA) et les applications natives ne fournissent pas de secret d’application. Les SPA et les applications natives sont des "clients publics" et ne peuvent pas conserver de secrets (le code du navigateur ou les bundles d’application sont inspectables). Au lieu d’un secret d’application, Logto les protège avec PKCE, une validation stricte des URI de redirection / CORS, des jetons d’accès à durée de vie courte et la rotation des jetons de rafraîchissement. +::: + +### Nom de l’application \{#application-name} -_Le nom de l'application_ est un nom lisible par l'homme de l'application et sera affiché dans la console d'administration. +_Le nom de l’application_ est un nom lisible par l’homme de l’application et sera affiché dans la console d’administration. -Le _nom de l'application_ est un composant important de la gestion des applications dans Logto, car il permet aux administrateurs d'identifier facilement et de suivre l'activité des applications individuelles au sein de la plateforme. +Le _nom de l’application_ est un élément important de la gestion des applications dans Logto, car il permet aux administrateurs d’identifier et de suivre facilement l’activité des applications individuelles sur la plateforme. :::note -Il est important de noter que le _nom de l'application_ doit être choisi avec soin, car il sera visible pour tous les utilisateurs ayant accès à la console d'administration. Il doit refléter avec précision le but et la fonction de l'application, tout en étant facile à comprendre et à reconnaître. +Il est important de noter que le _nom de l’application_ doit être choisi avec soin, car il sera visible par tous les utilisateurs ayant accès à la console d’administration. Il doit refléter fidèlement le but et la fonction de l’application, tout en étant facile à comprendre et à reconnaître. ::: ### Description \{#description} -Une brève description de l'application sera affichée sur la page des détails de l'application de la console d'administration. La description est destinée à fournir aux administrateurs des informations supplémentaires sur l'application, telles que son objectif, sa fonctionnalité et tout autre détail pertinent. +Une brève description de l’application sera affichée sur la page de détails de l’application dans la console d’administration. La description vise à fournir aux administrateurs des informations supplémentaires sur l’application, telles que son objectif, ses fonctionnalités et tout autre détail pertinent. ### URI de redirection \{#redirect-uris} -_Les URI de redirection_ sont une liste d'URI de redirection valides qui ont été préconfigurées pour une application. Lorsqu'un utilisateur se connecte à Logto et tente d'accéder à l'application, il est redirigé vers l'une des URI autorisées spécifiées dans les paramètres de l'application. +_Les URI de redirection_ sont une liste d’URI de redirection valides qui ont été préconfigurées pour une application. Lorsqu’un utilisateur se connecte à Logto et tente d’accéder à l’application, il est redirigé vers l’un des URI autorisés spécifiés dans les paramètres de l’application. -La liste des URI autorisées est utilisée pour valider l'URI de redirection qui est incluse dans la requête d'autorisation envoyée par l'application à Logto pendant le processus d'authentification. Si l'URI de redirection spécifiée dans la requête d'autorisation correspond à l'une des URI autorisées dans les paramètres de l'application, l'utilisateur est redirigé vers cette URI après une authentification réussie. Si l'URI de redirection n'est pas sur la liste autorisée, l'utilisateur ne sera pas redirigé et le processus d'authentification échouera. +La liste des URI autorisées est utilisée pour valider l’URI de redirection incluse dans la requête d’autorisation envoyée par l’application à Logto lors du processus d’authentification. Si l’URI de redirection spécifiée dans la requête d’autorisation correspond à l’une des URI autorisées dans les paramètres de l’application, l’utilisateur est redirigé vers cet URI après une authentification réussie. Si l’URI de redirection ne figure pas dans la liste autorisée, l’utilisateur ne sera pas redirigé et le processus d’authentification échouera. :::note -Il est important de s'assurer que toutes les URI de redirection valides sont ajoutées à la liste autorisée pour une application dans Logto, afin de garantir que les utilisateurs peuvent accéder avec succès à l'application après l'authentification. +Il est important de s’assurer que tous les URI de redirection valides sont ajoutés à la liste autorisée pour une application dans Logto, afin de garantir que les utilisateurs puissent accéder à l’application après authentification. ::: -Vous pouvez consulter le [point de terminaison de redirection](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) pour plus d'informations. +Vous pouvez consulter le [point de terminaison de redirection](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) pour plus d’informations. - Comprendre les URI de redirection dans OIDC avec le flux de code d'autorisation + Comprendre les URI de redirection dans OIDC avec le flux de code d’autorisation ### URI de redirection après déconnexion \{#post-sign-out-redirect-uris} -_Les URI de redirection après déconnexion_ sont une liste d'URI valides qui ont été préconfigurées pour une application afin de rediriger l'utilisateur après qu'il se soit déconnecté de Logto. +_Les URI de redirection après déconnexion_ sont une liste d’URI valides qui ont été préconfigurées pour une application afin de rediriger l’utilisateur après sa déconnexion de Logto. -L'utilisation des _URI de redirection après déconnexion autorisées_ pour la déconnexion fait partie de la spécification de déconnexion initiée par le RP (Relying Party) dans OIDC. Cette spécification fournit une méthode standardisée pour les applications afin d'initier une requête de déconnexion pour un utilisateur, ce qui inclut la redirection de l'utilisateur vers un point de terminaison préconfiguré après qu'il se soit déconnecté. +L’utilisation des _URI de redirection après déconnexion_ autorisées pour la déconnexion fait partie de la spécification de déconnexion initiée par la partie utilisatrice (RP-Initiated Logout) dans OIDC. Cette spécification fournit une méthode standardisée permettant aux applications d’initier une demande de déconnexion pour un utilisateur, ce qui inclut la redirection de l’utilisateur vers un point de terminaison préconfiguré après sa déconnexion. -Lorsqu'un utilisateur se déconnecte de Logto, sa session est terminée et il est redirigé vers l'une des URI autorisées spécifiées dans les paramètres de l'application. Cela garantit que l'utilisateur est dirigé uniquement vers des points de terminaison autorisés et valides après qu'il se soit déconnecté, aidant à prévenir l'accès non autorisé et les risques de sécurité associés à la redirection des utilisateurs vers des points de terminaison inconnus ou non vérifiés. +Lorsqu’un utilisateur se déconnecte de Logto, sa session est terminée et il est redirigé vers l’un des URI autorisés spécifiés dans les paramètres de l’application. Cela garantit que l’utilisateur est dirigé uniquement vers des points de terminaison autorisés et valides après sa déconnexion, ce qui aide à prévenir les accès non autorisés et les risques de sécurité associés à la redirection vers des points de terminaison inconnus ou non vérifiés. -Vous pouvez consulter la [déconnexion initiée par le RP](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) pour plus d'informations. +Vous pouvez consulter la [déconnexion initiée par la partie utilisatrice (RP-initiated logout)](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) pour plus d’informations. ### Origines autorisées CORS \{#cors-allowed-origins} -Les _origines autorisées CORS (partage de ressources cross-origin)_ sont une liste d'origines autorisées à partir desquelles une application peut faire des requêtes au service Logto. Toute origine qui n'est pas incluse dans la liste autorisée ne pourra pas faire de requêtes au service Logto. +_Les origines autorisées CORS (Cross-origin resource sharing)_ sont une liste d’origines autorisées à partir desquelles une application peut effectuer des requêtes vers le service Logto. Toute origine qui ne figure pas dans la liste autorisée ne pourra pas effectuer de requêtes vers le service Logto. -La liste des origines autorisées CORS est utilisée pour restreindre l'accès au service Logto à partir de domaines non autorisés, et pour aider à prévenir les attaques par falsification de requêtes intersites (CSRF). En spécifiant les origines autorisées pour une application dans Logto, le service peut s'assurer que seuls les domaines autorisés peuvent faire des requêtes au service. +La liste des origines autorisées CORS est utilisée pour restreindre l’accès au service Logto depuis des domaines non autorisés, et pour aider à prévenir les attaques par falsification de requête inter-sites (CSRF). En spécifiant les origines autorisées pour une application dans Logto, le service peut s’assurer que seuls les domaines autorisés peuvent effectuer des requêtes vers le service. :::note -La liste des origines autorisées doit contenir l'origine où l'application sera servie. Cela garantit que les requêtes de l'application sont autorisées, tandis que les requêtes provenant d'origines non autorisées sont bloquées. +La liste des origines autorisées doit contenir l’origine où l’application sera servie. Cela garantit que les requêtes provenant de l’application sont autorisées, tandis que les requêtes provenant d’origines non autorisées sont bloquées. ::: -### Point de terminaison de configuration du fournisseur OpenID \{#openid-provider-configuration-endpoint} +### Point de configuration du fournisseur OpenID \{#openid-provider-configuration-endpoint} -Le point de terminaison pour [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest). +Le point de terminaison pour la [découverte OpenID Connect](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest). -### Point de terminaison d'autorisation \{#authorization-endpoint} +### Point de terminaison d’autorisation \{#authorization-endpoint} -_Le point de terminaison d'autorisation_ est un terme OIDC, et c'est un point de terminaison requis qui est utilisé pour initier le processus d'authentification pour un utilisateur. Lorsqu'un utilisateur tente d'accéder à une ressource ou application protégée qui a été enregistrée sur la plateforme Logto, il sera redirigé vers le _point de terminaison d'autorisation_ pour authentifier son identité et obtenir l'autorisation d'accéder à la ressource demandée. +_Le point de terminaison d’autorisation_ est un terme OIDC, et c’est un point de terminaison requis utilisé pour initier le processus d’authentification pour un utilisateur. Lorsqu’un utilisateur tente d’accéder à une ressource ou application protégée qui a été enregistrée sur la plateforme Logto, il sera redirigé vers le _point de terminaison d’autorisation_ pour authentifier son identité et obtenir l’autorisation d’accéder à la ressource demandée. -Vous pouvez consulter le [point de terminaison d'autorisation](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) pour plus d'informations. +Vous pouvez consulter le [point de terminaison d’autorisation](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) pour plus d’informations. ### Point de terminaison de jeton \{#token-endpoint} -_Le point de terminaison de jeton_ est un terme OIDC, c'est un point de terminaison d'API web qui est utilisé par un client OIDC pour obtenir un jeton d’accès, un jeton d’identifiant ou un jeton de rafraîchissement d'un fournisseur OIDC. +_Le point de terminaison de jeton_ est un terme OIDC, c’est un point de terminaison d’API web utilisé par un client OIDC pour obtenir un jeton d’accès (Access token), un jeton d’identifiant (ID token) ou un jeton de rafraîchissement (Refresh token) auprès d’un fournisseur OIDC. -Lorsqu'un client OIDC a besoin d'obtenir un jeton d’accès ou un jeton d’identifiant, il envoie une requête au point de terminaison de jeton avec une autorisation, qui est généralement un code d'autorisation ou un jeton de rafraîchissement. Le point de terminaison de jeton valide ensuite l'autorisation et émet un jeton d’accès ou un jeton d’identifiant au client si l'autorisation est valide. +Lorsqu’un client OIDC a besoin d’obtenir un jeton d’accès ou un jeton d’identifiant, il envoie une requête au point de terminaison de jeton avec une autorisation, qui est généralement un code d’autorisation ou un jeton de rafraîchissement. Le point de terminaison de jeton valide alors l’autorisation et délivre un jeton d’accès ou un jeton d’identifiant au client si l’autorisation est valide. -Vous pouvez consulter le [point de terminaison de jeton](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) pour plus d'informations. +Vous pouvez consulter le [point de terminaison de jeton](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) pour plus d’informations. ### Point de terminaison Userinfo \{#userinfo-endpoint} -Le point de terminaison [UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) d'OpenID Connect. +Le [point de terminaison UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) d’OpenID Connect. ### Toujours émettre un jeton de rafraîchissement \{#always-issue-refresh-token} _Disponibilité : Web traditionnel, SPA_ -Lorsqu'il est activé, Logto émettra toujours des jetons de rafraîchissement, que `prompt=consent` soit présenté dans la requête d’authentification ou non, ni `offline_access` soit présenté dans les portées. +Lorsqu’il est activé, Logto émettra toujours des jetons de rafraîchissement (Refresh tokens), que `prompt=consent` soit présent ou non dans la requête d’authentification, ou que `offline_access` soit présent ou non dans les portées (Scopes). -Cependant, cette pratique est déconseillée sauf si nécessaire (elle est généralement utile pour certaines intégrations OAuth tierces qui nécessitent un jeton de rafraîchissement), car elle n'est pas compatible avec OpenID Connect et peut potentiellement causer des problèmes. +Cependant, cette pratique est déconseillée sauf nécessité (elle est généralement utile pour certaines intégrations OAuth tierces qui nécessitent un jeton de rafraîchissement), car elle n’est pas compatible avec OpenID Connect et peut potentiellement causer des problèmes. ### Rotation du jeton de rafraîchissement \{#rotate-refresh-token} _Défaut : `true`_ -Lorsqu'il est activé, Logto émettra un nouveau jeton de rafraîchissement pour les requêtes de jeton dans les conditions suivantes : +Lorsqu’elle est activée, Logto émettra un nouveau jeton de rafraîchissement pour les requêtes de jeton dans les conditions suivantes : -- Si le jeton de rafraîchissement a été tourné (a prolongé sa durée de vie en émettant un nouveau) pendant un an ; **OU** -- Si le jeton de rafraîchissement est proche de son expiration (>=70 % de son temps de vie original (TTL) écoulé) ; **OU** -- Si le client est un client public, par exemple une application native ou une application à page unique (SPA). +- Si le jeton de rafraîchissement a été renouvelé (sa durée de vie prolongée par l’émission d’un nouveau) pendant un an ; **OU** +- Si le jeton de rafraîchissement approche de sa date d’expiration (>=70 % de sa durée de vie initiale écoulée) ; **OU** +- Si le client est un client public, par exemple une application native ou une application monopage (SPA). :::note -Pour les clients publics, lorsque cette fonctionnalité est activée, un nouveau jeton de rafraîchissement sera toujours émis lorsque le client échange pour un nouveau jeton d’accès en utilisant le jeton de rafraîchissement. -Bien que vous puissiez toujours désactiver la fonctionnalité pour ces clients publics, il est fortement recommandé de la garder activée pour des raisons de sécurité. +Pour les clients publics, lorsque cette fonctionnalité est activée, un nouveau jeton de rafraîchissement sera toujours émis lorsque le client échange un nouveau jeton d’accès à l’aide du jeton de rafraîchissement. +Bien que vous puissiez toujours désactiver la fonctionnalité pour ces clients publics, il est fortement recommandé de la laisser activée pour des raisons de sécurité. ::: Comprendre la rotation du jeton de rafraîchissement -### Temps de vie (TTL) du jeton de rafraîchissement en jours \{#refresh-token-time-to-live-ttl-in-days} +### Durée de vie (TTL) du jeton de rafraîchissement en jours \{#refresh-token-time-to-live-ttl-in-days} _Disponibilité : Pas SPA ; Défaut : 14 jours_ -La durée pendant laquelle un jeton de rafraîchissement peut être utilisé pour demander de nouveaux jetons d’accès avant qu'il n'expire et devienne invalide. Les requêtes de jeton prolongeront le TTL du jeton de rafraîchissement à cette valeur. +La durée pendant laquelle un jeton de rafraîchissement peut être utilisé pour demander de nouveaux jetons d’accès avant d’expirer et de devenir invalide. Les requêtes de jeton prolongeront la durée de vie du jeton de rafraîchissement à cette valeur. -En général, une valeur plus basse est préférable. +En général, une valeur plus faible est préférable. -Note : Le rafraîchissement du TTL n'est pas disponible dans SPA (application à page unique) pour des raisons de sécurité. Cela signifie que Logto n'étendra pas le TTL via des requêtes de jeton. Pour améliorer l'expérience utilisateur, vous pouvez activer la fonctionnalité "Rotation du jeton de rafraîchissement", permettant à Logto d'émettre un nouveau jeton de rafraîchissement lorsque nécessaire. +Remarque : Le renouvellement du TTL n’est pas disponible dans les SPA (application monopage) pour des raisons de sécurité. Cela signifie que Logto n’étendra pas la durée de vie via les requêtes de jeton. Pour améliorer l’expérience utilisateur, vous pouvez activer la fonctionnalité "Rotation du jeton de rafraîchissement", permettant à Logto d’émettre un nouveau jeton de rafraîchissement si nécessaire. ### URI de déconnexion backchannel \{#backchannel-logout-uri} -Le point de terminaison de déconnexion backchannel d'OpenID Connect. Voir [Déconnexion fédérée : Déconnexion back-channel](#) pour plus d'informations. +Le point de terminaison de déconnexion backchannel OpenID Connect. Voir [Déconnexion fédérée : Déconnexion back-channel](#) pour plus d’informations. ### Données personnalisées \{#custom-data} -Informations supplémentaires personnalisées sur l'application non répertoriées dans les propriétés d'application prédéfinies, les utilisateurs peuvent définir leurs propres champs de données personnalisées en fonction de leurs besoins spécifiques, tels que les paramètres et configurations spécifiques à l'entreprise. +Informations supplémentaires personnalisées sur l’application non listées dans les propriétés prédéfinies de l’application ; les utilisateurs peuvent définir leurs propres champs de données personnalisées selon leurs besoins spécifiques, tels que des paramètres et configurations propres à leur activité. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index 9fd19c0194f..e7d62357c05 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -21,14 +21,29 @@ Le guide dans la console est uniquement destiné à un démarrage rapide avec Lo 5. Une fois terminé, vous êtes prêt à explorer davantage Logto : - Parcours utilisateur final + Expériences utilisateur Autorisation (Authorization) - Organisations (Organizations) + Organisations + +## FAQ \{#faqs} + +
+ + ### Comment mon service backend peut-il valider les jetons utilisateur et gérer les utilisateurs avec Logto ? + +Pour valider en toute sécurité les jetons d’accès dans votre API backend (par exemple, Python, Node.js, Go, Java, PHP, etc.), et pour gérer les utilisateurs de manière programmatique, veuillez consulter le guide : [Comment valider les jetons d’accès dans votre service API ou backend](/authorization/validate-access-tokens). + +Cette documentation couvre : + +- Comment vérifier la validité des jetons porteurs à chaque appel d’API +- Les meilleures pratiques pour intégrer Logto avec plusieurs applications frontend et un service backend + +
## Ressources associées \{#related-resources} - Guide complet pour intégrer un serveur OIDC dans votre projet + Le guide complet pour intégrer un serveur OIDC dans votre projet diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 313a6c8f041..e86abe536fb 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -14,7 +14,7 @@ Un Fournisseur d’identité (IdP) est un service qui vérifie les identités de Contrairement aux applications que vous avez créées dans le guide [Intégrer Logto à votre application](/integrate-logto/integrate-logto-into-your-application) qui sont développées et entièrement contrôlées par vous, les applications tierces sont des services indépendants développés par des développeurs externes ou des partenaires commerciaux. -Cette approche d'intégration est particulièrement adaptée aux scénarios métier courants. Vous pouvez permettre aux utilisateurs d'accéder à des applications partenaires en utilisant leurs comptes Logto, tout comme les utilisateurs d'entreprise se connectent à Slack avec Google Workspace. Vous pouvez également créer une plateforme ouverte où les applications tierces peuvent ajouter la fonctionnalité "Se connecter avec Logto", similaire à "Se connecter avec Google". +Cette approche d'intégration est bien adaptée aux scénarios métier courants. Vous pouvez permettre aux utilisateurs d'accéder aux applications partenaires en utilisant leurs comptes Logto, tout comme les utilisateurs d'entreprise se connectent à Slack avec Google Workspace. Vous pouvez également créer une plateforme ouverte où les applications tierces peuvent ajouter la fonctionnalité "Se connecter avec Logto", similaire à "Se connecter avec Google". Logto est un service d'identité construit sur le protocole [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), offrant des capacités d’[authentification (Authentication)](https://auth.wiki/authentication) et d’[autorisation (Authorization)](https://auth.wiki/authorization). Cela rend l'intégration d'une application tierce OIDC aussi simple qu'une application web traditionnelle. @@ -22,12 +22,12 @@ Ainsi, puisque OIDC s'appuie sur [OAuth 2.0](https://auth.wiki/oauth-2.0) en ajo ## Créer une application tierce dans Logto \{#create-an-third-party-application-in-logto} -1. Accédez à Console > Applications -2. Sélectionnez "Application tierce" comme type d'application et choisissez l'un des protocoles d'intégration suivants : +1. Allez dans Console > Applications. +2. Cliquez sur le bouton "Créer une application". Sélectionnez "Application tierce" comme type d'application et choisissez l'un des protocoles d'intégration suivants : - OIDC / OAuth -3. Saisissez un nom et une description pour votre application et cliquez sur le bouton “Créer”. Une nouvelle application tierce sera créée. +3. Saisissez un nom et une description pour votre application puis cliquez sur le bouton “Créer”. Une nouvelle application tierce sera créée. -Toutes les applications tierces créées seront répertoriées sur la page Applications sous l'onglet "Applications tierces". Cette organisation vous aide à les distinguer de vos propres applications, facilitant ainsi la gestion de toutes vos applications en un seul endroit. +Toutes les applications tierces créées seront répertoriées sur la page Applications sous l’onglet "Applications tierces". Cette organisation vous aide à les distinguer de vos propres applications, facilitant ainsi la gestion de toutes vos applications au même endroit. ## Configurer les paramètres OIDC \{#set-up-the-oidc-configurations} @@ -38,10 +38,10 @@ Avant de configurer les paramètres OIDC, veuillez vous assurer d’avoir [cré 1. Fournissez l’[**URI de redirection**](/integrate-logto/application-data-structure#redirect-uris) de votre application tierce OIDC. Il s'agit de l'URL vers laquelle l'application tierce redirigera les utilisateurs après leur authentification par Logto. Vous pouvez généralement trouver cette information dans la page des paramètres de connexion IdP de l'application tierce. -2. Récupérez l’[**ID client**](/integrate-logto/application-data-structure#application-id) et le [**secret client**](/integrate-logto/application-data-structure#application-secret) depuis la page de détails de l'application Logto et saisissez-les dans la page des paramètres de connexion IdP de votre fournisseur de service. +2. Récupérez l’[**ID client**](/integrate-logto/application-data-structure#application-id) et le [**secret client**](/integrate-logto/application-data-structure#application-secret) depuis la page de détails de l’application Logto et saisissez-les dans la page des paramètres de connexion IdP de votre fournisseur de service. -3. Récupérez le [**point de terminaison d’autorisation**](/integrate-logto/application-data-structure#authorization-endpoint) et le [**point de terminaison de jeton**](/integrate-logto/application-data-structure#token-endpoint) depuis la page de détails de l'application Logto et fournissez-les à votre fournisseur de service. - Si votre fournisseur de service prend en charge la découverte OIDC, vous pouvez simplement copier le **point de terminaison de découverte** depuis la page de détails de l'application Logto et le fournir à votre fournisseur de service. Le fournisseur pourra alors récupérer automatiquement toutes les informations d’authentification OIDC à jour à partir du point de terminaison de découverte. +3. Récupérez le [**point de terminaison d’autorisation**](/integrate-logto/application-data-structure#authorization-endpoint) et le [**point de terminaison de jeton**](/integrate-logto/application-data-structure#token-endpoint) depuis la page de détails de l’application Logto et fournissez-les à votre fournisseur de service. + Si votre fournisseur de service prend en charge la découverte OIDC, vous pouvez simplement copier le **point de terminaison de découverte** depuis la page de détails de l’application Logto et le fournir à votre fournisseur de service. Le fournisseur pourra alors récupérer automatiquement toutes les informations d’authentification OIDC à jour à partir du point de terminaison de découverte. Sinon, cliquez sur le bouton **Afficher les détails des points de terminaison** pour voir tous les points de terminaison d’authentification OIDC. ## Écran de consentement pour les applications tierces OIDC \{#consent-screen-for-oidc-third-party-applications} @@ -53,10 +53,10 @@ Toutes les [permissions du profil utilisateur](/integrate-logto/third-party-appl Ces permissions demandées ne seront accordées à l’application tierce qu’après que l’utilisateur ait cliqué sur le bouton "Autoriser".
- consent screen + écran de consentement
-## Actions supplémentaires \{#further-actions} +## Actions complémentaires \{#further-actions} -Logto utilise le Contrôle d’accès basé sur les rôles (RBAC) pour gérer les permissions des utilisateurs. Sur l’écran de consentement, seules les portées (permissions) déjà attribuées à l’utilisateur — via ses rôles — seront affichées. Si une application tierce demande des portées que l’utilisateur ne possède pas, celles-ci seront exclues afin d’éviter tout consentement non autorisé. +Logto utilise le contrôle d’accès basé sur les rôles (RBAC) pour gérer les permissions des utilisateurs. Sur l’écran de consentement, seules les portées (permissions) déjà attribuées à l’utilisateur — via ses rôles — seront affichées. Si une application tierce demande des portées que l’utilisateur ne possède pas, celles-ci seront exclues afin d’éviter tout consentement non autorisé. Pour gérer cela : diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index 077b3270610..24db59bde49 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,6 +3,7 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Service cloud Logto @@ -19,7 +20,7 @@ Si vous avez des questions concernant les services cloud et avez besoin d'un sup label: 'Paramètres du locataire', href: '/logto-cloud/tenant-settings', description: - 'Mettre à jour ou modifier le nom du locataire, vérifier les régions, et supprimer ou quitter le locataire.', + 'Mettez à jour ou modifiez le nom du locataire, vérifiez les régions et supprimez ou quittez le locataire.', customProps: { icon: , }, @@ -29,7 +30,7 @@ Si vous avez des questions concernant les services cloud et avez besoin d'un sup label: 'Politique de conservation des données du locataire de développement', href: '/logto-cloud/dev-tenant-data-retention', description: - 'Comprendre la politique de conservation des utilisateurs de 90 jours pour le locataire de développement et comment utiliser efficacement le locataire de développement Logto.', + 'Comprenez la politique de conservation des utilisateurs de 90 jours pour les locataires de développement et comment utiliser efficacement un locataire de développement Logto.', customProps: { icon: , }, @@ -64,5 +65,15 @@ Si vous avez des questions concernant les services cloud et avez besoin d'un sup icon: , }, }, + { + type: 'link', + label: 'Limite du système', + href: '/logto-cloud/system-limit', + description: + 'Comprenez les limites du système et la protection contre les dépassements de taux pour les locataires Dev, Pro et Enterprise.', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index b014f492f47..a9da646f1ff 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -12,11 +12,11 @@ Votre domaine personnalisé est utilisé pour plusieurs fonctions : - URLs de [page de connexion et d'inscription](/end-user-flows/sign-up-and-sign-in) - URLs de liaison [Passkey](/end-user-flows/mfa/webauthn) (Changer le domaine après que les utilisateurs aient lié des Passkeys peut bloquer leur authentification). -- URIs de rappel pour les [connecteurs sociaux](/connectors/social-connectors) ou les [connecteurs SSO d’entreprise](/connectors/enterprise-connectors). +- URI de rappel pour les [connecteurs sociaux](/connectors/social-connectors) ou les [connecteurs SSO d’entreprise](/connectors/enterprise-connectors). - [Point de terminaison SDK](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) pour intégrer Logto à votre application. :::note -Changer le domaine après la publication de votre service peut causer des problèmes car votre code applicatif et vos intégrations pourraient encore référencer l'ancien domaine. Pour assurer une transition en douceur, **configurez votre domaine personnalisé dès le début** lors de la création d'un tenant Production. +Changer le domaine après la publication de votre service peut causer des problèmes car votre code applicatif et vos intégrations pourraient toujours référencer l'ancien domaine. Pour garantir une transition en douceur, **configurez votre domaine personnalisé dès le début** lors de la création d'un tenant Production. ::: ## Configurer un domaine personnalisé dans la Console \{#configure-custom-domain-in-console} @@ -28,7 +28,7 @@ Pour ajouter un nouveau domaine personnalisé dans la Console Logto, suivez ces Ajouter un domaine -3. Copiez la valeur CNAME dans le tableau, puis allez chez votre fournisseur DNS pour ajouter l'enregistrement. +3. Copiez la valeur CNAME dans le tableau, puis rendez-vous chez votre fournisseur DNS pour ajouter l'enregistrement. Traitement du domaine personnalisé @@ -60,14 +60,14 @@ Pour diagnostiquer et résoudre les problèmes de certificat SSL liés aux enreg Si vous rencontrez le message d'erreur "The hostname is associated with a held zone, please contact the owner to have the hold removed" lors de l'ajout d'un domaine personnalisé, cela signifie que le domaine est déjà dans une zone Cloudflare, et qu'il est en statut "Zone Hold". Consultez cette [documentation Cloudflare](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/) pour plus d'informations. -Pour résoudre ce problème, vous devrez libérer le blocage de la zone. Suivez le lien ci-dessus pour obtenir les instructions sur la façon de libérer le blocage de zone dans Cloudflare. +Pour résoudre ce problème, vous devrez lever le blocage de la zone. Suivez le lien ci-dessus pour obtenir les instructions sur la façon de lever le blocage dans Cloudflare.
-### Délai d’attente dépassé (Code d’erreur 522) pour un domaine hébergé chez Cloudflare \{#cloudflare-522-timeout} +### Délai de connexion dépassé (code d’erreur 522) pour un domaine hébergé chez Cloudflare \{#cloudflare-522-timeout} @@ -75,9 +75,40 @@ Si votre domaine est hébergé chez Cloudflare, désactivez le proxy Cloudflare
-## Utiliser un domaine personnalisé \{#use-custom-domain} +
+ + +### Erreur "Redirect URI does not match" après la configuration du domaine personnalisé \{#redirect-uri-mismatch} + + + +Si vous obtenez une erreur "redirect URI does not match" après avoir ajouté votre domaine personnalisé, vous devez mettre à jour la configuration de votre SDK pour utiliser le domaine personnalisé comme point de terminaison. + +**À propos du "domaine principal" :** + +Il n'y a pas de paramètre "domaine principal" distinct dans Logto. Après avoir ajouté un domaine personnalisé, votre domaine personnalisé et le domaine par défaut `{tenant-id}.logto.app` restent valides. Le domaine que vous configurez dans le paramètre `endpoint` de votre SDK détermine quel domaine sera utilisé pour les flux d'authentification. + +**Solution :** + +Mettez à jour le paramètre `endpoint` lors de l'initialisation de votre SDK pour utiliser votre domaine personnalisé : + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // Utilisez votre domaine personnalisé + appId: 'your-app-id', + // ... autres options +}); +``` + +Vérifiez également que les URI de redirection enregistrées dans Console → Applications correspondent au domaine que vous utilisez. + +**Remarque :** Logto provisionne et gère automatiquement les certificats SSL pour votre domaine personnalisé. Vous n'avez pas besoin de configurer vos propres certificats. + +
+ +## Utiliser le domaine personnalisé \{#use-custom-domain} -Une fois vos paramètres configurés, à la fois votre nom de domaine personnalisé et le nom de domaine Logto par défaut seront disponibles pour votre tenant. Cependant, certaines configurations sont requises pour activer votre nom de domaine personnalisé. +Une fois vos paramètres configurés, votre nom de domaine personnalisé et le nom de domaine Logto par défaut seront disponibles pour votre tenant. Cependant, certaines configurations sont nécessaires pour activer votre nom de domaine personnalisé. :::note @@ -108,6 +139,6 @@ https://auth.example.com/oidc/.well-known/openid-configuration ### Mise à jour de l’URI de rappel du connecteur social \{#updating-the-social-connectors-callback-uri} -L’URI de rappel du connecteur social sera mis à jour automatiquement si vos utilisateurs utilisent le domaine personnalisé. Vous devez vous rendre dans la console développeur du fournisseur social pour mettre à jour l’URI de rappel. +L’URI de rappel du connecteur social sera mise à jour automatiquement si vos utilisateurs utilisent le domaine personnalisé. Vous devez vous rendre dans la console développeur du fournisseur social pour mettre à jour l’URI de rappel. -Lorsque vos utilisateurs utilisent le domaine personnalisé, l’URI de rappel du connecteur social utilisera le nouveau domaine. Par conséquent, vous devez accéder à la console développeur du fournisseur social pour mettre à jour manuellement l’URI de rappel. +Lorsque vos utilisateurs utilisent le domaine personnalisé, l’URI de rappel du connecteur social utilisera le nouveau domaine. Par conséquent, vous devez vous rendre dans la console développeur du fournisseur social pour mettre à jour manuellement l’URI de rappel. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..3a4f7d6c344 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# Limite du système + +Chez Logto, nous avons défini des limites généreuses pour tous les forfaits et proposons des options flexibles de paiement à l'utilisation, afin que les utilisateurs ne paient que pour ce qu'ils consomment réellement. + +Vous remarquerez peut-être que certains éléments de la page de tarification sont indiqués comme _illimités_ ou comme _paiement à l'utilisation continu sans plafond_. Cela signifie qu'ils peuvent généralement être utilisés sans restriction, mais Logto se réserve le droit d'ajuster ces limites réelles au fil du temps afin de garantir une utilisation équitable pour tous les utilisateurs. En d'autres termes, les limites d'entités sont des plafonds stricts qui protègent la santé globale de la plateforme. Elles ne font pas partie de la tarification, bien qu'elles puissent varier selon les groupes de forfaits. + +Si votre cas d'utilisation est raisonnable mais atteint une limite du système, n'hésitez pas à nous contacter et à partager vos retours. Cela nous aide à mieux comprendre les usages réels et à ajuster les limites du système pour mieux soutenir nos clients fidèles. + +## Protection contre les limites de débit au niveau du tenant \{#tenant-level-rate-limit-protection} + +### Tenants Dev \{#dev-tenants} + +Pour les tenants Dev, les utilisateurs peuvent profiter des fonctionnalités et offres gratuites de Logto. Pour prévenir les abus et fixer des attentes claires, nous définissons certaines limites système. Ces limites nous aident à gérer notre plateforme de manière durable tout en offrant un accès gratuit pour les tests et le développement. + +Si vous souhaitez augmenter votre quota, vous pouvez nous contacter pour obtenir de l'aide. Nous recommandons également de passer de **Dev** à **Pro**, ce qui supprime le plafond et vous donne un accès complet immédiatement. + +| **Fonctionnalité** | **Limite d'entité** | +| -------------------------------------- | ------------------- | +| **Jetons inclus** | 50k / mois | +| **Applications** | | +| Nombre total d'applications | 100 | +| Applications machine à machine | 100 | +| Applications tierces | 100 | +| **Ressources API** | | +| Nombre de ressources | 100 | +| **Authentification utilisateur** | | +| Connecteur social | 100 | +| SSO d’entreprise | 100 | +| **Gestion des utilisateurs** | | +| Rôles utilisateur | 100 | +| Rôles machine à machine | 100 | +| Permissions par rôle | 100 | +| **Organisations** | | +| Nombre d'organisations | 5 000 | +| Utilisateurs par organisation | 100k | +| Rôles utilisateur d'organisation | 1 000 | +| Rôles machine à machine d'organisation | 100 | +| Permissions d'organisation | 1 000 | +| **Développeurs et plateforme** | | +| Webhooks | 10 | +| Rétention des journaux d'audit | 14 jours | +| Membres du tenant | 20 | + +### Tenant Pro \{#pro-tenant} + +Pour les tenants Pro, les limites d'entités définissent le plafond supérieur pour les modules complémentaires et autres entités "illimitées" telles que les applications. Les détails des limites système du forfait Pro sont listés ci-dessous. + +| **Fonctionnalité** | **Limite d'entité** | +| -------------------------------------- | ------------------- | +| **Jetons inclus** | 10M / mois | +| **Applications** | | +| Nombre total d'applications | 100 | +| Applications machine à machine | 100 | +| Applications OIDC/OAuth tierces | 100 | +| Applications SAML | 100 | +| **Ressources API** | | +| Nombre de ressources | 1 000 | +| Permissions par ressource | 1 000 | +| **Authentification utilisateur** | | +| Connecteurs sociaux | 100 | +| SSO d’entreprise | 100 | +| **Gestion des utilisateurs** | | +| Rôles utilisateur | 1 000 | +| Rôles machine à machine | 100 | +| **Organisations** | | +| Nombre d'organisations | 100k | +| Utilisateurs par organisation | 100k | +| Rôles utilisateur d'organisation | 1 000 | +| Rôles machine à machine d'organisation | 100 | +| Permissions d'organisation | 1 000 | +| **Développeurs et plateforme** | | +| Webhooks | 10 | +| Rétention des journaux d'audit | 14 jours | +| Domaines personnalisés | 10 | +| Membres du tenant | 100 | + +### Entreprise \{#enterprise} + +Pour les forfaits Entreprise, les limites et fonctionnalités sont entièrement personnalisables et gérées via le contrat. Veuillez [nous contacter](https://logto.io/contact) pour plus de détails. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index 0aa975a35df..eaa0e693667 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -36,7 +36,7 @@ Lorsque vous créez un tenant, vous pouvez choisir la région où les données d En général, vous devriez choisir la région la plus proche de vos clients pour minimiser la latence et améliorer les performances. -Logto exploite le réseau mondial edge pour offrir les meilleures performances et disponibilité à vos applications. L'acheminement des requêtes est optimisé pour garantir que vos utilisateurs sont toujours connectés à l'option la plus performante. +Logto exploite le réseau mondial edge pour offrir les meilleures performances et la meilleure disponibilité à vos applications. L'acheminement des requêtes est optimisé pour garantir que vos utilisateurs sont toujours connectés à l'option la plus performante. :::note Vous cherchez une autre région ? [Contactez-nous](https://logto.io/contact) pour : @@ -56,7 +56,7 @@ Vous pouvez choisir le type de tenant lors de la création. Lorsque vous êtes p - **Convertir votre tenant Dev actuel en Production** Si vous préférez ne pas refaire la configuration ou migrer les utilisateurs, vous pouvez mettre à niveau votre tenant Développement existant vers un tenant Production payant. - - **Convertir en offre Pro** : Rendez-vous dans Console > Paramètres du tenant > Paramètres, puis cliquez sur "Convertir" pour effectuer la mise à niveau en libre-service. Toutes les fonctionnalités payantes utilisées dans le tenant dev seront reportées sur le paiement Stripe. + - **Convertir en offre Pro** : Rendez-vous dans Console > Paramètres du tenant > Paramètres, puis cliquez sur "Convertir" pour effectuer la mise à niveau en libre-service. Toutes les fonctionnalités payantes que vous avez utilisées dans le tenant dev seront reportées sur le paiement Stripe. - **Convertir en offre Enterprise** : [Contactez-nous](https://logto.io/contact) et nous vous aiderons à finaliser la mise à niveau. :::note @@ -69,50 +69,24 @@ Le tenant de développement (tenant dev) est principalement destiné aux tests e Cependant, certaines limitations s'appliquent aux tenants de développement : -- Le tenant dev supprimera automatiquement les utilisateurs après 90 jours. Consultez la [politique de conservation des données du tenant dev](./dev-tenant-data-retention) pour plus de détails. +- Le tenant dev supprimera automatiquement les utilisateurs après 90 jours. Consultez la [politique de conservation des données du tenant Dev](./dev-tenant-data-retention) pour plus de détails. - Une bannière apparaît lors de l'expérience de connexion, indiquant que le tenant est en mode développement. -- Les tenants de développement peuvent avoir des limites de quota sur certaines fonctionnalités. Ces limites sont expliquées sur la page de détails de la fonctionnalité, le cas échéant. +- Les tenants de développement peuvent avoir des limites de quota sur certaines fonctionnalités. Ces limites sont expliquées sur la page de détails de la fonctionnalité, le cas échéant. Pour une liste complète des limitations du plan Dev, veuillez consulter la page [Limite du système](./system-limit). - Logto peut mettre à jour les limites de quota du tenant de développement, et nous ferons de notre mieux pour vous en informer à l'avance. -| Fonctionnalité | Limite d'entité | -| -------------------------------- | --------------- | -| **Jetons inclus** | 50k / mois | -| **Applications** | -| Applications totales | 100 | -| Applications M2M | 100 | -| Applications tierces | 100 | -| **Ressources API** | | -| Nombre de ressources | 100 | -| **Authentification utilisateur** | | -| Connecteur social | 100 | -| SSO d’entreprise | 100 | -| **Gestion des utilisateurs** | | -| Rôles utilisateur | 100 | -| Rôles machine à machine | 100 | -| Permissions par rôle | 100 | -| **Organisations** | | -| Nombre d'organisations | 5 000 | -| Utilisateurs par organisation | 5 000 | -| Rôles d'organisation | 100 | -| Permissions d'organisation | 100 | -| **Développeurs et plateforme** | | -| Webhooks | 10 | -| Rétention des logs d’audit | 14 jours | -| Membres du tenant | 20 | - ### Production \{#production} -Le tenant de production est l'endroit où les utilisateurs finaux accèdent à l'application en direct et où vous pourriez avoir besoin d'un [abonnement payant](https://logto.io/pricing). Vous pouvez souscrire à l'offre Free ou Pro pour créer un tenant de production. Si vous choisissez l'offre Free, vous ne pouvez créer que jusqu'à 10 tenants. +Le tenant de production est celui où les utilisateurs finaux accèdent à l'application en direct et vous pourriez avoir besoin d'un [abonnement payant](https://logto.io/pricing). Vous pouvez souscrire à l'offre Free ou Pro pour créer un tenant de production. Si vous souscrivez à l'offre Free, vous ne pouvez créer que jusqu'à 10 tenants. ## Activer MFA \{#enable-mfa} -Renforcez la sécurité de votre espace de travail en exigeant l'authentification multi-facteurs (MFA) pour tous les membres de votre tenant Logto Pro / Enterprise. +Renforcez la sécurité de votre espace de travail en exigeant l'authentification multi-facteurs (MFA) pour tous les membres de votre tenant Logto Pro/Enterprise. Comme l'activation en libre-service n'est pas encore disponible, veuillez [nous contacter](https://logto.io/contact) pour activer cette fonctionnalité. ## Activer le SSO d’entreprise \{#enable-enterprise-sso} -Logto Cloud prend en charge l'intégration de l’authentification unique d’entreprise pour les tenants Enterprise Plan, y compris des fournisseurs comme Google Workspace, Okta, Azure AD, et plus encore. +Logto Cloud prend en charge l'intégration de l’authentification unique d’entreprise (SSO d’entreprise) pour les tenants Enterprise Plan, y compris des fournisseurs comme Google Workspace, Okta, Azure AD, et plus encore. Pour commencer, veuillez [nous contacter](https://logto.io/contact). Nous vous aiderons à le configurer rapidement. @@ -120,13 +94,13 @@ Pour commencer, veuillez [nous contacter](https://logto.io/contact). Nous vous a Un administrateur peut [inviter d'autres membres](/logto-cloud/tenant-member-management) sur ce tenant. -S'il y a au moins un autre **administrateur** (rôle), ou si vous êtes un **collaborateur** (rôle), vous pouvez choisir de quitter le tenant. Après votre départ, toutes les ressources du tenant resteront, mais vous n'y aurez plus accès. +S'il y a au moins un autre **admin** (rôle), ou si vous êtes un **collaborateur** (rôle), vous pouvez choisir de quitter le tenant. Après votre départ, toutes les ressources du tenant resteront, mais vous n'y aurez plus accès. -Si vous êtes le dernier administrateur, vous devez désigner un autre collaborateur comme administrateur avant de pouvoir quitter. +Si vous êtes le dernier admin, vous devez désigner un autre collaborateur comme admin avant de pouvoir quitter. ## Supprimer le tenant \{#delete-tenant} -Les [administrateurs](/logto-cloud/tenant-member-management#invite-collaborators) peuvent supprimer un tenant Logto. La suppression d'un tenant supprime définitivement toutes les données utilisateur et configurations associées. Cette action NE PEUT PAS être annulée. Logto vous demandera de saisir le nom du tenant pour confirmer et éviter toute suppression accidentelle. +Les [admins](/logto-cloud/tenant-member-management#invite-collaborators) peuvent supprimer un tenant Logto. La suppression d'un tenant supprime définitivement toutes les données utilisateur et configurations associées. Cette action NE PEUT PAS être annulée. Logto vous demandera de saisir le nom du tenant pour confirmer et éviter toute suppression accidentelle. Si vous avez besoin d'aide, veuillez [nous contacter](https://logto.io/contact) par e-mail. @@ -139,7 +113,7 @@ Si vous avez besoin d'aide, veuillez [nous contacter](https://logto.io/contact) -Vous pouvez actuellement convertir vous-même votre tenant **Développement** en tenant **Production** avec une offre payante. [En savoir plus](#tenant-types-dev-vs-prod) +Vous pouvez actuellement convertir vous-même votre tenant **Développement** en tenant **Production** avec un plan payant. [En savoir plus](#tenant-types-dev-vs-prod) Cependant, la migration en libre-service (toutes les configurations et données utilisateur) entre Logto Cloud et la version OSS n'est pas prise en charge. Si vous avez besoin de ce service, veuillez [contacter l'équipe Logto](https://logto.io/contact) pour discuter de vos options. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index 7798d2e4a9b..e38e36cd768 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -1,5 +1,5 @@ --- -description: Guides de démarrage rapide pour l'initialisation du service open-source (OSS) de Logto. +description: Guides de démarrage rapide pour l'initialisation du service open-source Logto (OSS). sidebar_position: 1 --- @@ -17,7 +17,7 @@ import Tabs from '@theme/Tabs'; ## GitPod \{#gitpod} -Pour démarrer un espace de travail GitPod en ligne pour Logto,
cliquez ici. Attendez quelques instants, vous verrez le message suivant : +Pour démarrer un espace de travail GitPod en ligne pour Logto, cliquez ici. Patientez quelques instants, vous verrez un message tel que :

-Docker Compose CLI est généralement fourni avec [Docker Desktop](https://www.docker.com/products/docker-desktop). +L’interface en ligne de commande Docker Compose est généralement incluse avec [Docker Desktop](https://www.docker.com/products/docker-desktop). :::caution -N'utilisez pas notre commande docker compose pour la production ! Étant donné que nous avons actuellement une base de données Postgres intégrée avec l'application Logto dans `docker-compose.yml`, chaque fois que vous réexécutez la commande, une nouvelle instance de base de données sera créée, et toutes les données précédemment enregistrées seront perdues. +N’utilisez pas notre commande docker compose en production ! Puisque nous avons actuellement une base de données Postgres intégrée avec l’application Logto dans `docker-compose.yml`, +à chaque nouvelle exécution de la commande, une nouvelle instance de base de données sera créée et toutes les données précédemment enregistrées seront perdues. ::: ```bash curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | docker compose -p logto -f - up ``` -Après une composition réussie, vous verrez le message suivant : +Après une composition réussie, vous verrez un message tel que : @@ -62,7 +63,7 @@ Après une composition réussie, vous verrez le message suivant :

Étape 1

-Préparez une instance [PostgreSQL](https://www.postgresql.org/)@^14.0, et utilisez [Logto CLI](/logto-oss/using-cli) pour initialiser une base de données pour Logto : +Préparez une instance [PostgreSQL](https://www.postgresql.org/)@^14.0, puis utilisez [Logto CLI](/logto-oss/using-cli) pour initialiser une base de données pour Logto : @@ -85,7 +86,7 @@ npx @logto/cli db seed

Étape 2

-Récupérez l'image : +Récupérez l’image : ```bash # ghcr @@ -96,16 +97,16 @@ docker pull svhd/logto:latest

Étape 3

-Mappez les ports du conteneur vers le noyau et l'application d'administration de Logto, par exemple, `3001:3001` et `3002:3002`; et définissez les variables d'environnement suivantes pour le conteneur : +Mappez les ports du conteneur vers Logto core et l’application admin, par exemple, `3001:3001` et `3002:3002` ; et définissez les variables d’environnement suivantes dans le conteneur : ```yml -TRUST_PROXY_HEADER: 1 # Réglez sur 1 si vous avez un proxy HTTPS (par exemple, Nginx) devant Logto -ENDPOINT: https:// # (Optionnel) Remplacez par votre URL de point de terminaison Logto si vous utilisez un domaine personnalisé -ADMIN_ENDPOINT: https:// # (Optionnel) Remplacez par votre URL d'administration Logto si vous utilisez un domaine personnalisé +TRUST_PROXY_HEADER: 1 # Mettez à 1 si vous avez un proxy HTTPS (ex. Nginx) devant Logto +ENDPOINT: https:// # (Optionnel) Remplacez par l’URL de votre endpoint Logto si vous utilisez un domaine personnalisé +ADMIN_ENDPOINT: https:// # (Optionnel) Remplacez par l’URL admin de Logto si vous utilisez un domaine personnalisé DB_URL: postgres://username:password@your_postgres_url:port/db_name # Remplacez par votre DSN Postgres ``` -Exécutez le conteneur avec toutes les variables d'environnement ci-dessus : +Lancez le conteneur avec toutes les variables d’environnement ci-dessus : ```bash docker run \ @@ -122,11 +123,11 @@ docker run \ :::tip - Si vous utilisez Docker Hub, utilisez `svhd/logto:latest` au lieu de `ghcr.io/logto-io/logto:latest`. -- Utilisez `host.docker.internal` ou `172.17.0.1` dans `DB_URL` pour faire référence à l'IP de l'hôte. +- Utilisez `host.docker.internal` ou `172.17.0.1` dans `DB_URL` pour référencer l’IP de l’hôte. ::: -Enfin, vous verrez le message suivant : +Enfin, vous verrez un message tel que : @@ -137,9 +138,9 @@ Enfin, vous verrez le message suivant : - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -Les versions supérieures fonctionnent généralement mais ne sont pas garanties. +Des versions supérieures fonctionnent généralement mais ne sont pas garanties. -Nous recommandons d'utiliser une nouvelle base de données vide dédiée à Logto, bien que cela ne soit pas une exigence stricte. +Nous recommandons d’utiliser une nouvelle base de données vide dédiée à Logto, bien que cela ne soit pas une obligation stricte. **Télécharger et démarrer** @@ -149,20 +150,20 @@ Dans votre terminal : npm init @logto@latest ``` -Une fois que vous avez terminé le processus d'initialisation et démarré Logto, vous verrez le message suivant : +Une fois le processus d’initialisation terminé et Logto démarré, vous verrez un message tel que :
```text -L'application principale est en cours d'exécution à http://localhost:3001 -L'application principale est en cours d'exécution à https://your-domain-url -L'application d'administration est en cours d'exécution à http://localhost:3002 -L'application d'administration est en cours d'exécution à https://your-admin-domain-url +L’application principale fonctionne sur http://localhost:3001 +L’application principale fonctionne sur https://your-domain-url +L’application admin fonctionne sur http://localhost:3002 +L’application admin fonctionne sur https://your-admin-domain-url ``` -Rendez-vous sur `http://localhost:3002/` pour continuer votre parcours avec Logto. Profitez-en ! +Rendez-vous sur `http://localhost:3002/` pour poursuivre votre expérience Logto. Profitez-en !
@@ -172,13 +173,13 @@ Rendez-vous sur `http://localhost:3002/` pour continuer votre parcours avec Logt -Si vous souhaitez spécifier une URL pour le fichier zip de Logto, utilisez l'option `--download-url`. Par exemple : +Si vous souhaitez spécifier une URL pour le fichier zip Logto, utilisez l’option `--download-url`. Par exemple : ``` npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -Notez que le `--` supplémentaire est nécessaire pour que NPM passe les arguments. +Notez que le `--` supplémentaire est nécessaire pour que NPM transmette les arguments.
@@ -186,19 +187,19 @@ Notez que le `--` supplémentaire est nécessaire pour que NPM passe les argumen -### Configuration (optionnelle) \{#configuration-optional} +### Configuration (optionnel) \{#configuration-optional} -Logto utilise des variables d'environnement pour la configuration, avec prise en charge des fichiers `.env`. Voir [Configuration](/concepts/core-service/configuration) pour une utilisation détaillée et la liste complète des variables. +Logto utilise des variables d’environnement pour la configuration, avec prise en charge du fichier `.env`. Voir [Configuration](/concepts/core-service/configuration) pour l’utilisation détaillée et la liste complète des variables. -_Consultez [Service principal](/concepts/core-service) si vous souhaitez des contrôles plus avancés ou un accès programmatique à Logto._ +_Consultez [Service principal](/concepts/core-service) si vous souhaitez des contrôles avancés ou un accès programmatique à Logto._ -## Fournisseurs d'hébergement \{#hosting-providers} +## Fournisseurs d’hébergement \{#hosting-providers} -Ces fournisseurs d'hébergement fiables offrent des modèles d'installation en un clic pour Logto. Avec des services facilement déployables, vous pouvez configurer et lancer votre système CIAM en utilisant Logto en quelques secondes. +Ces fournisseurs d’hébergement fiables proposent des modèles d’installation en un clic pour Logto. Avec des services facilement déployables, vous pouvez configurer et lancer votre système CIAM avec Logto en quelques secondes. , }, @@ -245,7 +246,7 @@ Ces fournisseurs d'hébergement fiables offrent des modèles d'installation en u label: 'Elestio', href: 'https://elest.io/open-source/logto', description: - 'Plateforme DevOps entièrement gérée pour déployer votre code et logiciels open-source.', + 'Plateforme DevOps entièrement gérée pour déployer votre code et vos logiciels open-source.', customProps: { icon: , }, @@ -254,7 +255,7 @@ Ces fournisseurs d'hébergement fiables offrent des modèles d'installation en u type: 'link', label: 'Railway', href: 'https://railway.com/template/07_f_Z', - description: "Simplifie le déploiement des applications et la gestion de l'infrastructure.", + description: 'Simplifie le déploiement des applications et la gestion de l’infrastructure.', customProps: { icon: , }, @@ -264,7 +265,7 @@ Ces fournisseurs d'hébergement fiables offrent des modèles d'installation en u label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', description: - "Simplifie le déploiement, la mise à l'échelle et la surveillance des applications pour les développeurs.", + 'Simplifie le déploiement, la montée en charge et la surveillance des applications pour les développeurs.', customProps: { icon: , }, @@ -272,12 +273,16 @@ Ces fournisseurs d'hébergement fiables offrent des modèles d'installation en u ]} /> -Veuillez noter que nous ne fournissons pas de support client pour les fournisseurs de services tiers. Pour accéder à nos canaux de support, veuillez déployer sur [Logto Cloud](https://cloud.logto.io). Merci ! +Veuillez noter que nous n’assurons pas de support client pour les fournisseurs de services tiers. Pour accéder à nos canaux de support, veuillez déployer sur [Logto Cloud](https://cloud.logto.io). Merci ! ## Créer un compte \{#create-an-account} -Une fois que vous avez hébergé Logto avec succès sur votre serveur, cliquez sur "Créer un compte" sur la page d'accueil. Gardez à l'esprit que la version open-source de Logto ne permet la création que d'un seul compte lors du lancement initial et ne prend pas en charge plusieurs comptes. Le processus de création de compte est limité aux combinaisons de nom d'utilisateur et de mot de passe. +Une fois que vous avez hébergé Logto avec succès sur votre serveur, cliquez sur "Créer un compte" sur la page d’accueil. Gardez à l’esprit que la version open-source de Logto ne permet la création que d’un seul compte lors du lancement initial et ne prend pas en charge plusieurs comptes. Le processus de création de compte se limite à une combinaison nom d’utilisateur et mot de passe. + +:::tip +Logto OSS (auto-hébergé) ne prend pas en charge la configuration de plusieurs administrateurs. Pour la collaboration en équipe et les projets nécessitant plusieurs utilisateurs admin, nous recommandons d’utiliser [Logto Cloud](https://cloud.logto.io), qui offre des fonctionnalités complètes de gestion d’équipe. +::: ## Ressources associées \{#related-resources} -Gérer le développement HTTPS local +Gérer le développement HTTPS en local diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index 4621e589f62..33804efbd39 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -14,7 +14,7 @@ import SignInFlowSummary from '../../fragments/_web-sign-in-flow-summary.mdx'; import ScopesAndClaims from './_scopes-and-claims.mdx'; -# Ajoutez l’authentification à votre application Java Spring Boot +# Ajoutez l’authentification à votre application Java Spring Boot (Add authentication to your Java Spring Boot application) Ce guide vous montrera comment intégrer Logto dans votre application Java Spring Boot. @@ -29,11 +29,11 @@ Ce guide vous montrera comment intégrer Logto dans votre application Java Sprin - Un compte [Logto Cloud](https://cloud.logto.io) ou un [Logto auto-hébergé](/introduction/set-up-logto-oss). - Notre code d'exemple a été créé en utilisant le [securing web starter](https://spring.io/guides/gs/securing-web) de Spring Boot. Suivez les instructions pour démarrer une nouvelle application web si vous n'en avez pas. -- Dans ce guide, nous utiliserons les bibliothèques [Spring Security](https://spring.io/projects/spring-security) et [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) pour gérer le flux d'authentification OIDC avec Logto. Veuillez vous assurer de parcourir la documentation officielle pour comprendre les concepts. +- Dans ce guide, nous utiliserons les bibliothèques [Spring Security](https://spring.io/projects/spring-security) et [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) pour gérer le flux d'authentification OIDC avec Logto. Veuillez consulter la documentation officielle pour bien comprendre les concepts. ## Configurez votre application Java Spring Boot \{#configure-your-java-spring-boot-application} -### Ajout de dépendances \{#adding-dependencies} +### Ajout des dépendances \{#adding-dependencies} Pour les utilisateurs de [gradle](https://spring.io/guides/gs/gradle), ajoutez les dépendances suivantes à votre fichier `build.gradle` : @@ -69,7 +69,7 @@ Pour les utilisateurs de [maven](https://spring.io/guides/gs/maven), ajoutez les ### Configuration du client OAuth2 \{#oauth2-client-configuration} -Enregistrez une nouvelle application `Java Spring Boot` dans la Console Logto et obtenez les informations d'identification du client et les configurations IdP pour votre application web. +Enregistrez une nouvelle application `Java Spring Boot` dans la Console Logto et récupérez les identifiants client et les configurations IdP pour votre application web. Ajoutez la configuration suivante à votre fichier `application.properties` : @@ -91,9 +91,9 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc -Pour rediriger les utilisateurs vers votre application après leur connexion, vous devez définir l'URI de redirection en utilisant la propriété `client.registration.logto.redirect-uri` à l'étape précédente. +Afin de rediriger les utilisateurs vers votre application après leur connexion, vous devez définir l'URI de redirection en utilisant la propriété `client.registration.logto.redirect-uri` à l'étape précédente. - + ### Implémentez le WebSecurityConfig \{#implement-the-websecurityconfig} @@ -102,65 +102,23 @@ Pour rediriger les utilisateurs vers votre application après leur connexion, vo La classe `WebSecurityConfig` sera utilisée pour configurer les paramètres de sécurité de votre application. C'est la classe clé qui gérera le flux d'authentification et d'autorisation. Veuillez consulter la [documentation Spring Security](https://spring.io/guides/topicals/spring-security-architecture) pour plus de détails. ```java title="WebSecurityConfig.java" -package com.example.securingweb; - -import org.springframework.context.annotation.Configuration; -import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; - -@Configuration -@EnableWebSecurity - -public class WebSecurityConfig { - // ... -} +// Voir le code ci-dessus, inchangé ``` #### Créez un bean `idTokenDecoderFactory` \{#create-a-idtokendecoderfactory-bean} -Ceci est nécessaire car Logto utilise `ES384` comme algorithme par défaut, nous devons remplacer le `OidcIdTokenDecoderFactory` par défaut pour utiliser le même algorithme. +Ceci est nécessaire car Logto utilise `ES384` comme algorithme par défaut, nous devons donc surcharger le `OidcIdTokenDecoderFactory` par défaut pour utiliser le même algorithme. ```java title="WebSecurityConfig.java" -import org.springframework.context.annotation.Bean; -import org.springframework.security.oauth2.client.oidc.authentication.OidcIdTokenDecoderFactory; -import org.springframework.security.oauth2.client.registration.ClientRegistration; -import org.springframework.security.oauth2.jose.jws.SignatureAlgorithm; -import org.springframework.security.oauth2.jwt.JwtDecoderFactory; - -public class WebSecurityConfig { - // ... - - @Bean - public JwtDecoderFactory idTokenDecoderFactory() { - OidcIdTokenDecoderFactory idTokenDecoderFactory = new OidcIdTokenDecoderFactory(); - idTokenDecoderFactory.setJwsAlgorithmResolver(clientRegistration -> SignatureAlgorithm.ES384); - return idTokenDecoderFactory; - } -} +// Voir le code ci-dessus, inchangé ``` #### Créez une classe LoginSuccessHandler pour gérer l'événement de succès de connexion \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} -Nous redirigerons l'utilisateur vers la page `/user` après une connexion réussie. +Nous allons rediriger l'utilisateur vers la page `/user` après une connexion réussie. ```java title="CustomSuccessHandler.java" -package com.example.securingweb; - -import java.io.IOException; - -import org.springframework.security.core.Authentication; -import org.springframework.security.web.authentication.AuthenticationSuccessHandler; - -import jakarta.servlet.ServletException; -import jakarta.servlet.http.HttpServletRequest; -import jakarta.servlet.http.HttpServletResponse; - -public class CustomSuccessHandler implements AuthenticationSuccessHandler { - @Override - public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, - Authentication authentication) throws IOException, ServletException { - response.sendRedirect("/user"); - } -} +// Voir le code ci-dessus, inchangé ``` #### Créez une classe LogoutSuccessHandler pour gérer l'événement de succès de déconnexion \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} @@ -168,90 +126,28 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { Effacez la session et redirigez l'utilisateur vers la page d'accueil. ```java title="CustomLogoutHandler.java" -package com.example.securingweb; - -import java.io.IOException; - -import org.springframework.security.core.Authentication; -import org.springframework.security.web.authentication.logout.LogoutSuccessHandler; - -import jakarta.servlet.ServletException; -import jakarta.servlet.http.HttpServletRequest; -import jakarta.servlet.http.HttpServletResponse; -import jakarta.servlet.http.HttpSession; - -public class CustomLogoutHandler implements LogoutSuccessHandler { - @Override - public void onLogoutSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) - throws IOException, ServletException { - HttpSession session = request.getSession(); - - if (session != null) { - session.invalidate(); - } - - response.sendRedirect("/home"); - } -} +// Voir le code ci-dessus, inchangé ``` #### Mettez à jour la classe `WebSecurityConfig` avec un `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} [securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) est une chaîne de filtres responsables du traitement des requêtes et réponses entrantes. -Nous allons configurer le `securityFilterChain` pour permettre l'accès à la page d'accueil et exiger une authentification pour toutes les autres requêtes. Utilisez le `CustomSuccessHandler` et le `CustomLogoutHandler` pour gérer les événements de connexion et de déconnexion. +Nous allons configurer le `securityFilterChain` pour autoriser l'accès à la page d'accueil et exiger l'authentification pour toutes les autres requêtes. Utilisez les classes `CustomSuccessHandler` et `CustomLogoutHandler` pour gérer les événements de connexion et de déconnexion. ```java title="WebSecurityConfig.java" -import org.springframework.context.annotation.Bean; -import org.springframework.security.config.annotation.web.builders.HttpSecurity; -import org.springframework.security.web.DefaultSecurityFilterChain; - -public class WebSecurityConfig { - // ... - - @Bean - public DefaultSecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { - http - .authorizeRequests(authorizeRequests -> - authorizeRequests - .antMatchers("/", "/home").permitAll() // Permettre l'accès à la page d'accueil - .anyRequest().authenticated() // Toutes les autres requêtes nécessitent une authentification - ) - .oauth2Login(oauth2Login -> - oauth2Login - .successHandler(new CustomSuccessHandler()) - ) - .logout(logout -> - logout - .logoutSuccessHandler(new CustomLogoutHandler()) - ); - return http.build(); - } -} +// Voir le code ci-dessus, inchangé ``` ### Créez une page d'accueil \{#create-a-home-page} -(Vous pouvez passer cette étape si vous avez déjà une page d'accueil dans votre projet) +(Vous pouvez ignorer cette étape si vous avez déjà une page d'accueil dans votre projet) ```java title="HomeController.java" -package com.example.securingweb; - -import java.security.Principal; - -import org.springframework.stereotype.Controller; -import org.springframework.web.bind.annotation.GetMapping; - -@Controller -public class HomeController { - @GetMapping({ "/", "/home" }) - public String home(Principal principal) { - return principal != null ? "redirect:/user" : "home"; - } -} +// Voir le code ci-dessus, inchangé ``` -Ce contrôleur redirigera l'utilisateur vers la page utilisateur si l'utilisateur est authentifié, sinon, il affichera la page d'accueil. Ajoutez un lien de connexion à la page d'accueil. +Ce contrôleur redirigera l'utilisateur vers la page utilisateur s'il est authentifié, sinon il affichera la page d'accueil. Ajoutez un lien de connexion à la page d'accueil. ```html title="resources/templates/home.html" @@ -266,42 +162,12 @@ Ce contrôleur redirigera l'utilisateur vers la page utilisateur si l'utilisateu Créez un nouveau contrôleur pour gérer la page utilisateur : ```java title="UserController.java" -package com.example.securingweb; - -import java.security.Principal; -import java.util.Map; - -import org.springframework.security.oauth2.client.authentication.OAuth2AuthenticationToken; -import org.springframework.security.oauth2.core.user.OAuth2User; -import org.springframework.stereotype.Controller; -import org.springframework.ui.Model; -import org.springframework.web.bind.annotation.GetMapping; -import org.springframework.web.bind.annotation.RequestMapping; - -@Controller -@RequestMapping("/user") -public class UserController { - - @GetMapping - public String user(Model model, Principal principal) { - if (principal instanceof OAuth2AuthenticationToken) { - OAuth2AuthenticationToken token = (OAuth2AuthenticationToken) principal; - OAuth2User oauth2User = token.getPrincipal(); - Map attributes = oauth2User.getAttributes(); - - model.addAttribute("username", attributes.get("username")); - model.addAttribute("email", attributes.get("email")); - model.addAttribute("sub", attributes.get("sub")); - } - - return "user"; - } -} +// Voir le code ci-dessus, inchangé ``` -Une fois l'utilisateur authentifié, nous récupérerons les données `OAuth2User` à partir de l'objet principal authentifié. Veuillez vous référer à [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) et [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) pour plus de détails. +Une fois l'utilisateur authentifié, nous récupérerons les données `OAuth2User` à partir de l'objet principal authentifié. Veuillez consulter [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) et [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) pour plus de détails. -Lisez les données utilisateur et passez-les au modèle `user.html`. +Lisez les données utilisateur et transmettez-les au template `user.html`. ```html title="resources/templates/user.html" @@ -326,27 +192,27 @@ Lisez les données utilisateur et passez-les au modèle `user.html`. -Pour récupérer des informations utilisateur supplémentaires, vous pouvez ajouter des portées supplémentaires au fichier `application.properties`. Par exemple, pour demander les portées `email`, `phone`, et `urn:logto:scope:organizations`, ajoutez la ligne suivante au fichier `application.properties` : +Pour récupérer des informations utilisateur supplémentaires, vous pouvez ajouter des portées supplémentaires dans le fichier `application.properties`. Par exemple, pour demander les portées `email`, `phone` et `urn:logto:scope:organizations`, ajoutez la ligne suivante dans le fichier `application.properties` : ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -Ensuite, vous pouvez accéder aux revendications supplémentaires dans l'objet `OAuth2User`. +Vous pourrez alors accéder aux revendications supplémentaires dans l'objet `OAuth2User`. ### Exécutez et testez l'application \{#run-and-test-the-application} -Exécutez l'application et accédez à `http://localhost:8080`. +Lancez l'application et accédez à `http://localhost:8080`. - Vous verrez la page d'accueil avec un lien de connexion. - Cliquez sur le lien pour vous connecter avec Logto. -- Après une authentification réussie, vous serez redirigé vers la page utilisateur avec vos détails utilisateur. +- Après une authentification réussie, vous serez redirigé vers la page utilisateur avec vos informations. - Cliquez sur le bouton de déconnexion pour vous déconnecter. Vous serez redirigé vers la page d'accueil. -## Portées et Revendications \{#scopes-and-claims} +## Portées et revendications (Scopes and Claims) \{#scopes-and-claims} -## Lectures complémentaires \{#further-readings} +## Pour aller plus loin \{#further-readings} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index dcacff3ed2f..9f48515afe8 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -18,17 +18,17 @@ Cette fonctionnalité est essentielle pour les applications modernes telles que **🤖 Assistants IA** : Un agent IA peut accéder aux dépôts GitHub d'un utilisateur pour analyser du code, créer des pull requests ou gérer des tickets. Tout cela avec le consentement unique de l'utilisateur lors de la connexion ou de la liaison de compte. -**📊 Tableaux de bord analytiques** : Les plateformes SaaS peuvent extraire des données des comptes de réseaux sociaux connectés des utilisateurs (Facebook, LinkedIn) pour générer des analyses et des rapports sans interrompre leur flux de travail avec des demandes de connexion répétées. +**📊 Tableaux de bord analytiques** : Les plateformes SaaS peuvent extraire des données des comptes de réseaux sociaux connectés des utilisateurs (Facebook, LinkedIn) pour générer des rapports et des analyses sans interrompre leur flux de travail avec des demandes de connexion répétées. ## Activer le stockage de jetons tiers \{#enable-third-party-token-storage} ### Connecteurs sociaux \{#social-connectors} -Cette fonctionnalité est disponible pour les [connecteurs sociaux](/connectors/social-connectors) qui prennent en charge le stockage des jetons. Les jetons tiers peuvent être stockés lors de la [connexion sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in), de la [liaison de compte social](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection), et [lors du renouvellement des jetons pour l'accès à l'API tierce](/secret-vault/federated-token-set#reauthentication-and-token-renewal). Les connecteurs actuellement pris en charge incluent : [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [OAuth 2.0 standard](/integrations/oauth2), et [OIDC standard](/integrations/oidc). La prise en charge d'autres connecteurs sera déployée progressivement. +Cette fonctionnalité est disponible pour les [connecteurs sociaux](/connectors/social-connectors) qui prennent en charge le stockage des jetons. Les jetons tiers peuvent être stockés lors de la [connexion sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in), de la [liaison de compte social](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection), et [lors du renouvellement des jetons pour l'accès API tiers](/secret-vault/federated-token-set#reauthentication-and-token-renewal). Les connecteurs actuellement pris en charge incluent : [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [OAuth 2.0 standard](/integrations/oauth2), et [OIDC standard](/integrations/oidc). La prise en charge d'autres connecteurs sera déployée progressivement. 1. Accédez à Console > Connecteurs > Connecteurs sociaux. 2. Sélectionnez le connecteur social pour lequel vous souhaitez activer le stockage de jetons tiers. -3. Suivez les tutoriels de configuration pour configurer le connecteur, y compris l'ajout des portées nécessaires pour accéder à des API tierces spécifiques. +3. Suivez les tutoriels de configuration pour paramétrer le connecteur, y compris l’ajout des portées nécessaires pour accéder aux API tierces spécifiques. 4. Dans la page "Paramètres", activez l’option **Stocker les jetons pour un accès API persistant**. ### Connecteurs SSO d’entreprise \{#enterprise-sso-connectors} @@ -37,10 +37,10 @@ Le stockage des jetons est disponible pour tous les [connecteurs d’entreprise 1. Accédez à Console > SSO d’entreprise. 2. Sélectionnez le connecteur SSO d’entreprise pour lequel vous souhaitez activer le stockage de jetons tiers. -3. Suivez les tutoriels de configuration pour configurer le connecteur, y compris l'ajout des portées nécessaires pour accéder à des API tierces spécifiques. +3. Suivez les tutoriels de configuration pour paramétrer le connecteur, y compris l’ajout des portées nécessaires pour accéder aux API tierces spécifiques. 4. Dans l’onglet "Expérience SSO", activez l’option **Stocker les jetons pour un accès API persistant**. -N'oubliez pas d'enregistrer vos modifications. +N’oubliez pas d’enregistrer vos modifications. ## Stockage des jetons \{#token-storage} @@ -50,35 +50,35 @@ Une fois le stockage de jetons tiers activé, Logto stocke automatiquement les j - [Connexion et inscription SSO d’entreprise](/end-user-flows/enterprise-sso) - [Liaison de compte social via Account API](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -Les jetons stockés sont attachés à l'identité sociale ou SSO d’entreprise de l'utilisateur, ce qui leur permet de récupérer les jetons ultérieurement pour accéder à l’API sans nécessiter une nouvelle authentification. +Les jetons stockés sont attachés à l'identité sociale ou SSO d’entreprise de l'utilisateur, ce qui leur permet de récupérer les jetons ultérieurement pour accéder aux API sans nécessiter une nouvelle authentification. -### Vérifier le statut du stockage de jetons \{#checking-token-storage-status} +### Vérifier le statut du stockage des jetons \{#checking-token-storage-status} Vous pouvez vérifier le statut du stockage de jetons tiers d’un utilisateur dans la Console Logto : 1. Accédez à Console > Utilisateurs. -2. Cliquez sur l'utilisateur que vous souhaitez inspecter. Cela vous amènera à la page de détails de l'utilisateur. -3. Faites défiler jusqu'à la section **Connexions**. Cette zone répertorie toutes les connexions sociales et SSO d’entreprise associées à l'utilisateur. +2. Cliquez sur l'utilisateur que vous souhaitez inspecter. Cela vous amènera à la page de détails de l’utilisateur. +3. Faites défiler jusqu’à la section **Connexions**. Cette zone liste toutes les connexions sociales et SSO d’entreprise associées à l’utilisateur. 4. Chaque entrée de connexion affiche une étiquette de statut de jeton indiquant si des jetons sont stockés pour cette connexion. -5. Cliquez sur l'entrée de connexion pour afficher plus de détails, y compris les métadonnées du jeton d’accès stocké et la disponibilité du jeton de rafraîchissement (le cas échéant). +5. Cliquez sur l’entrée de connexion pour afficher plus de détails, y compris les métadonnées du jeton d’accès stocké et la disponibilité du jeton de rafraîchissement (le cas échéant). -Vous pouvez également vérifier les identités tierces de l'utilisateur et le statut du stockage de jetons via la Management API : +Vous pouvez également vérifier les identités tierces de l’utilisateur et le statut du stockage des jetons via la Management API : -- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true` : Récupérer l'identité sociale d'un utilisateur et le statut du stockage de jetons associé à l'identité par un connecteur donné (par exemple, `github`, `google`, etc.). -- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true` : Récupérer l'identité SSO d’entreprise d'un utilisateur et le statut du stockage de jetons associé à l'identité par un ID de connecteur SSO donné. +- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true` : Récupérer l'identité sociale d’un utilisateur et le statut du stockage de jetons associé à l'identité par un connecteur donné (ex : `github`, `google`, etc.). +- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true` : Récupérer l'identité SSO d’entreprise d’un utilisateur et le statut du stockage de jetons associé à l'identité par un ID de connecteur SSO donné. -### Statut du stockage de jetons \{#token-storage-status} +### Statut du stockage des jetons \{#token-storage-status} -- **Actif** : Le jeton d’accès (Access token) est stocké et actif. +- **Actif** : Le jeton d’accès est stocké et actif. - **Expiré** : Le jeton d’accès est stocké mais a expiré. Si un jeton de rafraîchissement est disponible, il peut être utilisé pour obtenir un nouveau jeton d’accès. -- **Inactif** : Aucun jeton d’accès n’est stocké pour cette connexion. Cela peut se produire si l'utilisateur ne s'est pas authentifié via cette connexion ou si le stockage du jeton a été supprimé. +- **Inactif** : Aucun jeton d’accès n’est stocké pour cette connexion. Cela peut se produire si l’utilisateur ne s’est pas authentifié via cette connexion ou si le stockage du jeton a été supprimé. - **Non applicable** : Le connecteur ne prend pas en charge le stockage des jetons. ### Métadonnées du jeton \{#token-metadata} -Pour l'intégrité et la sécurité des données, tous les jetons sont chiffrés avant d'être stockés dans le coffre-fort de secrets. Les valeurs réelles des jetons ne sont accessibles qu'à l'utilisateur final avec la bonne autorisation. Les développeurs, quant à eux, ne peuvent récupérer que les métadonnées de l'ensemble de jetons pour comprendre l'état des jetons stockés sans exposer de contenu sensible. +Pour l'intégrité et la sécurité des données, tous les jetons sont chiffrés avant d’être stockés dans le coffre-fort de secrets. Les valeurs réelles des jetons ne sont accessibles qu’à l’utilisateur final avec la bonne autorisation. Les développeurs, quant à eux, ne peuvent récupérer que les métadonnées de l’ensemble de jetons pour comprendre l’état des jetons stockés sans exposer de contenu sensible. -- `createdAt` : L’horodatage de la première création de la connexion et du stockage initial de l’ensemble de jetons dans le coffre-fort. +- `createdAt` : L’horodatage de la première connexion et du stockage initial de l’ensemble de jetons dans le coffre-fort. - `updatedAt` : La dernière fois que l’ensemble de jetons a été mis à jour. - Si aucun jeton de rafraîchissement n’est disponible, cette valeur sera identique à **createdAt**. - Si un jeton de rafraîchissement est présent, cette valeur reflète la dernière fois où le jeton d’accès a été rafraîchi. @@ -86,7 +86,7 @@ Pour l'intégrité et la sécurité des données, tous les jetons sont chiffrés Si le connecteur prend en charge l’accès hors ligne et que la requête d’autorisation est correctement configurée, Logto stocke le jeton de rafraîchissement lorsqu’il est émis par le fournisseur d’identité en même temps que le jeton d’accès. Lorsque le jeton d’accès expire et qu’un jeton de rafraîchissement valide existe, Logto tente automatiquement d’obtenir un nouveau jeton d’accès à l’aide du jeton de rafraîchissement stocké chaque fois que l’utilisateur demande l’accès au fournisseur connecté. - `expiresAt` : L’heure d’expiration estimée du jeton d’accès en **secondes**. - Ceci est calculé à partir de la valeur `expires_in` renvoyée par le point de terminaison de jeton du fournisseur d’identité. (Ce champ n’est disponible que si le fournisseur inclut `expires_in` dans la réponse du jeton.) + Elle est calculée à partir de la valeur `expires_in` renvoyée par le point de terminaison de jeton du fournisseur d’identité. (Ce champ n’est disponible que si le fournisseur inclut `expires_in` dans la réponse du jeton.) - `scope` : La portée (Scope) du jeton d’accès, indiquant les permissions accordées par le fournisseur d’identité. Ceci est utile pour comprendre quelles actions peuvent être effectuées avec le jeton d’accès stocké. (Ce champ n’est disponible que si le fournisseur inclut `scope` dans la réponse du jeton.) - `tokenType` : Le type du jeton d’accès, généralement "Bearer". @@ -94,19 +94,19 @@ Pour l'intégrité et la sécurité des données, tous les jetons sont chiffrés ## Récupération des jetons \{#token-retrieval} -Une fois le stockage de jetons activé et les jetons stockés en toute sécurité dans le coffre-fort de secrets de Logto, les utilisateurs finaux peuvent récupérer leurs jetons d’accès tiers depuis votre application cliente en intégrant l’[Account API](/end-user-flows/account-settings/by-account-api) de Logto. +Une fois le stockage des jetons activé et les jetons stockés en toute sécurité dans le coffre-fort de secrets de Logto, les utilisateurs finaux peuvent récupérer leurs jetons d’accès tiers depuis votre application cliente en intégrant l’[Account API](/end-user-flows/account-settings/by-account-api) de Logto. -- `GET /my-account/identities/:target/access-token` : Récupérer le jeton d’accès pour une identité sociale en spécifiant le connecteur cible (par exemple, github, google). +- `GET /my-account/identities/:target/access-token` : Récupérer le jeton d’accès pour une identité sociale en spécifiant le connecteur cible (ex : github, google). - `GET /my-account/sso-identities/:connectorId/access-token` : Récupérer le jeton d’accès pour une identité SSO d’entreprise en spécifiant l’ID du connecteur. :::info -Découvrez comment [activer](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) et [accéder](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) à l’Account API en utilisant le jeton d’accès émis par Logto. +Pour récupérer les jetons d’accès tiers, vous devez d’abord activer l’Account API pour les utilisateurs finaux dans Console > Connexion & Compte > Centre de compte. Apprenez à [activer l’Account API](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) et [y accéder à l’aide d’un jeton d’accès émis par Logto](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token). ::: ### Rotation des jetons \{#token-rotation} -Les points de terminaison de récupération de jetons renvoient : +Les points de terminaison de récupération des jetons renvoient : - `200` OK : Si le jeton d’accès est récupéré avec succès et est toujours valide. - `404` Not Found : Si l’utilisateur ne possède pas d’identité sociale ou SSO d’entreprise associée à la cible ou à l’ID de connecteur spécifié, ou si le jeton d’accès n’est pas stocké. @@ -114,11 +114,11 @@ Les points de terminaison de récupération de jetons renvoient : Si le jeton d’accès est expiré et qu’un jeton de rafraîchissement est disponible, Logto tente automatiquement de rafraîchir le jeton d’accès et renvoie le nouveau jeton d’accès dans la réponse. Le stockage du jeton dans le coffre-fort de secrets est également mis à jour avec le nouveau jeton d’accès et ses métadonnées. -## Suppression du stockage de jetons \{#token-storage-deletion} +## Suppression du stockage des jetons \{#token-storage-deletion} Le stockage de jetons tiers est directement lié à chaque connexion sociale ou SSO d’entreprise de l’utilisateur. Cela signifie que l’ensemble de jetons stocké sera automatiquement supprimé dans les cas suivants : -- L’identité sociale ou SSO d’entreprise associée est supprimée du compte utilisateur. +- L’identité sociale ou SSO d’entreprise associée est supprimée du compte de l’utilisateur. - Le compte utilisateur est supprimé de votre tenant. - Le connecteur social ou SSO d’entreprise est supprimé de votre tenant. @@ -127,7 +127,7 @@ Le stockage de jetons tiers est directement lié à chaque connexion sociale ou Vous pouvez également supprimer manuellement l’ensemble de jetons tiers d’un utilisateur pour révoquer l’accès : - Depuis la Console : - Accédez à la page de détails de l’identité de l’utilisateur. Faites défiler jusqu’à la section **Jeton d’accès** (si le stockage de jetons est disponible) et cliquez sur le bouton **Supprimer les jetons** à la fin de la section. + Accédez à la page de détails de l’identité de l’utilisateur. Faites défiler jusqu’à la section **Jeton d’accès** (si le stockage des jetons est disponible) et cliquez sur le bouton **Supprimer les jetons** à la fin de la section. - Via la Management API : - `DELETE /api/secret/:id` : Supprimer un secret spécifique par son ID, qui peut être obtenu à partir des détails de l’identité utilisateur. @@ -135,12 +135,12 @@ La révocation de l’ensemble de jetons obligera l’utilisateur à se réauthe ## Réauthentification et renouvellement des jetons \{#reauthentication-and-token-renewal} -Dans les scénarios où un jeton d’accès stocké a expiré ou lorsqu’une application doit demander des portées API supplémentaires, les utilisateurs finaux peuvent se réauthentifier auprès du fournisseur tiers pour obtenir un nouveau jeton d’accès — sans avoir besoin de se connecter à Logto à nouveau. -Cela peut être réalisé via l’[API de vérification sociale](https://openapi.logto.io/operation/operation-createverificationbysocial) de Logto, qui permet aux utilisateurs de réinitier un flux d’autorisation sociale fédérée et de mettre à jour leur ensemble de jetons stocké. +Dans les scénarios où un jeton d’accès stocké a expiré ou lorsqu’une application doit demander des portées API supplémentaires, les utilisateurs finaux peuvent se réauthentifier auprès du fournisseur tiers pour obtenir un nouveau jeton d’accès — sans avoir besoin de se reconnecter à Logto. +Cela peut être réalisé via l’[API de vérification sociale](https://openapi.logto.io/operation/operation-createverificationbysocial) de Logto, qui permet aux utilisateurs de relancer un flux d’autorisation sociale fédérée et de mettre à jour leur ensemble de jetons stocké. :::note -La réinitialisation de l’autorisation fédérée est actuellement limitée aux connecteurs sociaux. -Pour les connecteurs SSO d’entreprise, la réauthentification et le renouvellement des jetons nécessitent que l’utilisateur initie à nouveau un flux d’authentification Logto complet, car la réautorisation directe auprès du fournisseur SSO d’entreprise n’est actuellement pas prise en charge après la connexion. +La relance de l’autorisation fédérée est actuellement limitée aux connecteurs sociaux. +Pour les connecteurs SSO d’entreprise, la réauthentification et le renouvellement des jetons nécessitent que l’utilisateur initie à nouveau un flux d’authentification Logto complet, car la réautorisation directe auprès du fournisseur SSO d’entreprise n’est pas encore prise en charge après la connexion. ::: ```mermaid @@ -195,7 +195,7 @@ sequenceDiagram 4. Le fournisseur tiers redirige l’utilisateur vers votre application cliente avec un code d’autorisation. -5. Gérez le rappel d’autorisation en transmettant le code d’autorisation au point de terminaison de vérification de Logto : +5. Gérez le callback d’autorisation en transmettant le code d’autorisation au point de terminaison de vérification de Logto : ```sh curl -X POST https:///api/verification/social/verify \ @@ -212,7 +212,7 @@ sequenceDiagram - **authorization header** : Le jeton d’accès de l’utilisateur émis par Logto. - **verificationRecordId** : L’ID de vérification sociale retourné à l’étape précédente. - - **connectorData** : Le code d’autorisation et toute autre donnée retournée par le fournisseur tiers lors du rappel. + - **connectorData** : Le code d’autorisation et toute autre donnée retournée par le fournisseur tiers lors du callback. :::note N’oubliez pas de valider le paramètre `state` pour prévenir les attaques CSRF. @@ -232,7 +232,7 @@ sequenceDiagram ``` - **authorization header** : Le jeton d’accès de l’utilisateur émis par Logto. - - **socialVerificationId** : L’ID d’enregistrement de vérification sociale vérifié retourné à l’étape précédente. + - **socialVerificationId** : L’ID d’enregistrement de vérification sociale retourné à l’étape précédente. Cela mettra à jour l’ensemble de jetons de l’utilisateur dans le coffre-fort de secrets de Logto avec le nouveau jeton d’accès et le jeton de rafraîchissement, permettant à l’utilisateur d’accéder aux API tierces sans avoir à se reconnecter à Logto. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/fr/docusaurus-plugin-content-docs/current/security/blocklist.md index b8a68652732..876cb9e5b87 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/fr/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -8,7 +8,7 @@ sidebar_position: 3 ## Liste de blocage des e-mails {#email-blocklist} -La politique de liste de blocage des e-mails permet de personnaliser les paramètres de blocage afin de prévenir les abus lors de la création de comptes. Elle surveille les adresses e-mail utilisées pour l'inscription et la gestion des comptes. Si un utilisateur tente de s'inscrire ou de lier une adresse e-mail qui enfreint l'une des règles de la liste de blocage, le système rejettera la demande, ce qui aide à limiter les comptes indésirables et à renforcer la sécurité globale des comptes. +La politique de liste de blocage des e-mails permet de personnaliser les paramètres de blocage afin de prévenir les abus lors de la création de comptes. Elle surveille les adresses e-mail utilisées pour l'inscription et les paramètres de compte. Si un utilisateur tente de s'inscrire ou de lier une adresse e-mail qui enfreint une règle de la liste de blocage, le système rejettera la demande, ce qui aide à limiter les comptes indésirables et à renforcer la sécurité globale des comptes. Rendez-vous dans Console > Sécurité > Liste de blocage pour configurer les paramètres de la liste de blocage des e-mails. @@ -18,19 +18,19 @@ Il s'agit d'une fonctionnalité **cloud uniquement**. Une fois activée, le syst ### Bloquer le sous-adressage des e-mails {#block-email-subaddressing} -Le sous-adressage des e-mails permet aux utilisateurs de créer des variantes de leur adresse e-mail en ajoutant un signe plus (+) suivi de caractères supplémentaires (ex. : utilisateur+tag@example.com). Cette fonctionnalité peut être exploitée par des utilisateurs malveillants pour contourner les restrictions de la liste de blocage. En activant la fonction de blocage du sous-adressage, le système rejettera toute tentative d'inscription ou de liaison de compte utilisant ce format d'adresse e-mail. +Le sous-adressage des e-mails permet aux utilisateurs de créer des variantes de leur adresse e-mail en ajoutant un signe plus (+) suivi de caractères supplémentaires (par exemple, utilisateur+tag@example.com). Cette fonctionnalité peut être exploitée par des utilisateurs malveillants pour contourner les restrictions de la liste de blocage. En activant la fonction de blocage du sous-adressage, le système rejettera toute tentative d'inscription ou de liaison de compte utilisant un format d'e-mail sous-adressé. -### Liste de blocage personnalisée des e-mails {#custom-email-blocklist} +### Liste de blocage des e-mails personnalisée {#custom-email-blocklist} -Vous pouvez créer une liste de blocage personnalisée en spécifiant une liste d'adresses e-mail ou de domaines à bloquer. Le système rejettera toute tentative d'inscription ou de liaison de compte correspondant à ces entrées. La liste de blocage prend en charge la correspondance sur l'adresse e-mail complète ou sur le domaine. +Vous pouvez créer une liste de blocage personnalisée en spécifiant une liste d'adresses e-mail ou de domaines à bloquer. Le système rejettera toute tentative d'inscription ou de liaison de compte correspondant à ces entrées. La liste de blocage prend en charge la correspondance complète d'adresse e-mail et de domaine. Par exemple, ajouter `@example.com` à la liste de blocage bloquera toutes les adresses e-mail de ce domaine. De même, ajouter `foo@example.com` bloquera spécifiquement cette adresse e-mail. :::note -Les e-mails jetables, le sous-adressage et les e-mails personnalisés sont restreints lors de l'inscription et de la liaison de compte. Les utilisateurs existants avec ces adresses e-mail peuvent toujours se connecter. +Les e-mails jetables, le sous-adressage et les e-mails personnalisés sont restreints lors de [l'inscription d'un nouvel utilisateur](/end-user-flows/sign-up-and-sign-in/sign-up), [la liaison d'un e-mail lors d'une connexion sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers), et la mise à jour des e-mails via [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email). Les utilisateurs existants avec ces adresses e-mail peuvent toujours se connecter. -- Les administrateurs peuvent "contourner les restrictions" en ajoutant manuellement des utilisateurs dans Console > Gestion des utilisateurs, ou via [Management API](https://openapi.logto.io/operation/operation-createuser). Par exemple, créer un utilisateur avec une adresse e-mail en sous-adressage lorsque le sous-adressage est bloqué. +- Les administrateurs peuvent "contourner les restrictions" en ajoutant manuellement des utilisateurs dans Console > Gestion des utilisateurs, ou via [Management API](https://openapi.logto.io/operation/operation-createuser). Par exemple, créer un utilisateur avec une adresse e-mail sous-adressée alors que le sous-adressage est bloqué. - Bloquez les comptes existants en les supprimant ou en les suspendant dans Console > Gestion des utilisateurs. ::: diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/security/password-policy.mdx index b442334efd9..d56c6f769f9 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,9 +6,15 @@ sidebar_position: 1 # Politique de mot de passe +Logto applique la politique de mot de passe de différentes manières selon la façon dont le mot de passe est créé ou mis à jour : + +- Les flux utilisateur finaux tels que [l'expérience de connexion prête à l'emploi](/end-user-flows/sign-up-and-sign-in/sign-up), [l’Experience API](/customization/bring-your-ui) et [l’Account API](/end-user-flows/account-settings/by-account-api#update-users-password) appliquent toujours la [politique de mot de passe](#set-up-password-policy) actuelle. +- Les actions administrateur via la Management API [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) sont exemptées, ce qui vous permet de provisionner ou de réinitialiser des identifiants sans vérification de la politique si nécessaire. +- Pour auditer les mots de passe existants selon les règles actuelles, appelez [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) et agissez selon le résultat de validation retourné. Lisez [Vérification de la conformité du mot de passe](#password-compliance-check) pour en savoir plus. + ## Configurer la politique de mot de passe \{#set-up-password-policy} -Pour les nouveaux utilisateurs ou les utilisateurs qui mettent à jour leur mot de passe, vous pouvez définir une politique de mot de passe afin d'appliquer des exigences de robustesse. Rendez-vous dans le Console > Sécurité > Politique de mot de passe pour configurer les paramètres de la politique de mot de passe. +Pour les nouveaux utilisateurs ou ceux qui mettent à jour leur mot de passe, vous pouvez définir une politique de mot de passe afin d’imposer des exigences de robustesse. Rendez-vous dans le Console > Sécurité > Politique de mot de passe pour configurer les paramètres de la politique. 1. **Longueur minimale du mot de passe** : Définissez le nombre minimal de caractères requis pour le mot de passe. (Le NIST recommande d'utiliser au moins 8 [caractères](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) 2. **Nombre minimal de types de caractères requis** : Définissez le nombre minimal de types de caractères requis pour le mot de passe. Les types de caractères disponibles sont : @@ -16,19 +22,24 @@ Pour les nouveaux utilisateurs ou les utilisateurs qui mettent à jour leur mot 2. Lettres minuscules : `(a-z)` 3. Chiffres : `(0-9)` 4. Caractères spéciaux : ``(!"#$%&'()\*+,-./:;<>=?@[]^\_`|{}~ )`` -3. **Vérification de l'historique des violations** : Activez ce paramètre pour rejeter les mots de passe ayant déjà été exposés lors de violations de données. (Propulsé par [Have I Been Pwned](https://haveibeenpwned.com/Passwords)) -4. **Vérification des répétitions** : Activez ce paramètre pour rejeter les mots de passe contenant des caractères répétitifs. (ex. : "11111111" ou "password123") +3. **Vérification de l’historique de violation** : Activez ce paramètre pour rejeter les mots de passe ayant déjà été exposés lors de violations de données. (Propulsé par [Have I Been Pwned](https://haveibeenpwned.com/Passwords)) +4. **Vérification de répétition** : Activez ce paramètre pour rejeter les mots de passe contenant des caractères répétitifs. (ex. : "11111111" ou "password123") 5. **Vérification des informations utilisateur** : Activez ce paramètre pour rejeter les mots de passe contenant des informations utilisateur telles que le nom d'utilisateur, l'adresse e-mail ou le numéro de téléphone. 6. **Mots personnalisés** : Fournissez une liste de mots personnalisés (insensibles à la casse) que vous souhaitez rejeter dans le mot de passe. -## Vérification de conformité du mot de passe \{#password-compliance-check} +## Vérification de la conformité du mot de passe \{#password-compliance-check} Après avoir mis à jour la politique de mot de passe dans Logto, les utilisateurs existants peuvent toujours se connecter avec leur mot de passe actuel. Seuls les nouveaux comptes créés devront respecter la politique mise à jour. -Pour renforcer la sécurité, vous pouvez utiliser l’[API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) `POST /api/sign-in-exp/default/check-password` pour vérifier si le mot de passe d’un utilisateur respecte la politique actuelle définie dans l’expérience de connexion par défaut. Si ce n’est pas le cas, vous pouvez inviter l’utilisateur à mettre à jour son mot de passe via un flux personnalisé en utilisant [Account API](/end-user-flows/account-settings/by-management-api#user-password-management). +Pour renforcer la sécurité, vous pouvez utiliser l’API `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) pour vérifier si le mot de passe d’un utilisateur respecte la politique actuelle définie dans l'expérience de connexion par défaut. Si ce n’est pas le cas, vous pouvez inviter l’utilisateur à mettre à jour son mot de passe via un flux personnalisé utilisant l’[Account API](/end-user-flows/account-settings/by-account-api). ## Ressources associées \{#related-resources} +Gérer les utilisateurs +Inscription et connexion + + Paramètres du compte via Account API + - Concevez votre politique de mot de passe + Concevoir votre politique de mot de passe diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index f817f531db3..d2a7ad5dc50 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -4,12 +4,11 @@ sidebar_position: 2 # Gérer les utilisateurs -## Gérer via la Console Logto \{#manage-via-logto-console} +## Gérer via Logto Console \{#manage-via-logto-console} ### Parcourir et rechercher des utilisateurs \{#browse-and-search-users} -Pour accéder à la fonctionnalité de gestion des utilisateurs dans la Console Logto, accédez à Console > Gestion des utilisateurs. -Une fois sur place, vous verrez une vue en tableau de tous les utilisateurs. +Pour accéder à la fonctionnalité de gestion des utilisateurs dans la Console Logto, accédez à Console > Gestion des utilisateurs. Une fois sur place, vous verrez une vue en tableau de tous les utilisateurs. Le tableau se compose de trois colonnes : @@ -23,7 +22,7 @@ La recherche prend en charge la correspondance par mot-clé pour [`name`](/user- À l'aide de la Console, les développeurs peuvent créer de nouveaux comptes pour les utilisateurs finaux. Pour ce faire, cliquez sur le bouton "Ajouter un utilisateur" dans le coin supérieur droit de l'écran. -Lors de la création d'un utilisateur dans la Console Logto ou via le Management API (et non par auto-inscription de l'utilisateur final via l'interface), vous devez fournir au moins un identifiant : `primary email`, `primary phone` ou `username`. Le champ `name` est facultatif. +Lors de la création d'un utilisateur dans la Console Logto ou via le Management API (et non par auto-inscription de l'utilisateur via l'interface), vous devez fournir au moins un identifiant : `primary email`, `primary phone` ou `username`. Le champ `name` est facultatif. Après la création de l'utilisateur, Logto générera automatiquement un mot de passe aléatoire. Le mot de passe initial n'apparaîtra qu'une seule fois, mais vous pouvez [réinitialiser le mot de passe](./manage-users#reset-user-password) ultérieurement. Si vous souhaitez définir un mot de passe spécifique, utilisez le Management API `patch /api/users/{userId}/password` pour le mettre à jour après la création de l'utilisateur. @@ -37,22 +36,29 @@ Si vous souhaitez mettre en place une inscription sur invitation uniquement, nou ### Voir et mettre à jour le profil utilisateur \{#view-and-update-the-user-profile} -Pour afficher les détails d'un utilisateur, cliquez simplement sur la ligne correspondante dans le tableau des utilisateurs. Cela vous amènera à la page "**Détails de l'utilisateur**" où vous trouverez les informations de profil de l'utilisateur, notamment : +Pour afficher les détails d'un utilisateur, cliquez simplement sur la ligne correspondante dans le tableau des utilisateurs. Cela vous mènera à la page "**Détails de l'utilisateur**" où vous trouverez les informations du profil de l'utilisateur, y compris : - **Données liées à l'authentification** : - **Adresse e-mail** ([primary_email](/user-management/user-data#primary_email)) : Modifiable - **Numéro de téléphone** ([primary_phone](/user-management/user-data#primary_phone)) : Modifiable - **Nom d'utilisateur** ([username](/user-management/user-data#username)) : Modifiable - **Mot de passe** ([has_password](/user-management/user-data#has_password)) : Vous pouvez régénérer un mot de passe aléatoire. En savoir plus sur "[Réinitialiser le mot de passe utilisateur](#reset-user-password)". - - **Connexions sociales** ([identities](/user-management/user-data#social-identities)) : Voir les comptes sociaux liés et les identifiants sociaux. Par exemple, si l'utilisateur s'est connecté avec son compte Facebook, vous verrez un élément "Facebook" dans la liste. Vous pouvez supprimer une identité sociale liée dans la Console. Mais vous ne pouvez pas en lier une nouvelle au nom de l'utilisateur final. - - **Connexions SSO d’entreprise** ([sso_identities](/user-management/user-data#sso-identities)) : Voir les identités d'entreprise liées. Vous ne pouvez pas ajouter ou supprimer des identités SSO dans la Console. - - **Authentification multi-facteurs (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)) : Voir tous les facteurs d'authentification (par exemple, passkeys, applications d'authentification, codes de secours) que cet utilisateur a configurés. Les facteurs peuvent être supprimés dans la Console. - - **Jeton d’accès personnel** : Créer, voir, renommer et supprimer des [jetons d’accès personnels](/user-management/personal-access-token). -- **Données de profil utilisateur** : nom, URL de l'avatar, données personnalisées et revendications standard OpenID Connect supplémentaires qui ne sont pas incluses. Tous ces champs de profil sont modifiables. + - **Authentification multi-facteurs (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)) : Affichez tous les facteurs d'authentification (par exemple, passkeys, applications d'authentification, codes de secours) que cet utilisateur a configurés. Les facteurs peuvent être supprimés dans la Console. + - **Jeton d’accès personnel** : Créez, affichez, renommez et supprimez les [jetons d’accès personnels](/user-management/personal-access-token). +- **Connexion** : + - **Connexions sociales** ([identities](/user-management/user-data#social-identities)) : + - Affichez les comptes sociaux liés de l'utilisateur, y compris les identifiants sociaux et les détails du profil synchronisés depuis leurs fournisseurs sociaux (par exemple, une entrée "Facebook" apparaîtra si l'utilisateur s'est connecté via Facebook). + - Vous pouvez supprimer les identités sociales existantes, mais vous ne pouvez pas lier de nouveaux comptes sociaux au nom de l'utilisateur. + - Pour les connecteurs sociaux avec [stockage de jetons](/secret-vault/federated-token-set) activé, vous pouvez afficher et gérer les jetons d’accès et les jetons de rafraîchissement dans la page de détail de la connexion. + - **Connexions SSO d’entreprise** ([sso_identities](/user-management/user-data#sso-identities)) : + - Affichez les identités d’entreprise liées de l'utilisateur, y compris les identifiants d’entreprise et les détails du profil synchronisés depuis leurs fournisseurs d'identité d’entreprise. + - Vous ne pouvez pas ajouter ou supprimer des identités SSO d’entreprise dans la Console. + - Pour les connecteurs d’entreprise basés sur OIDC avec [stockage de jetons](/secret-vault/federated-token-set) activé, vous pouvez afficher et supprimer les jetons dans la page de détail de la connexion. +- **Données du profil utilisateur** : nom, URL de l'avatar, données personnalisées et revendications standard OpenID Connect supplémentaires qui ne sont pas incluses. Tous ces champs de profil sont modifiables. :::warning -Il est important de vérifier que l'utilisateur dispose d'une méthode de connexion alternative avant de supprimer une connexion sociale, comme une autre connexion sociale, un numéro de téléphone, un e-mail ou un nom d'utilisateur avec mot de passe. Si l'utilisateur ne dispose d'aucune autre méthode de connexion, il ne pourra plus accéder à son compte une fois la connexion sociale supprimée. +Il est important de vérifier que l'utilisateur dispose d'une méthode de connexion alternative avant de supprimer une connexion sociale, telle qu'une autre connexion sociale, un numéro de téléphone, une adresse e-mail ou un nom d'utilisateur avec mot de passe. Si l'utilisateur ne dispose d'aucune autre méthode de connexion, il ne pourra plus accéder à son compte une fois la connexion sociale supprimée. ::: @@ -60,43 +66,49 @@ Il est important de vérifier que l'utilisateur dispose d'une méthode de connex Pour consulter les activités récentes d'un utilisateur, accédez à l'onglet secondaire "Journaux utilisateur" sur la page des détails de l'utilisateur. Vous y trouverez un tableau affichant les activités récentes de l'utilisateur, y compris l'action effectuée, le résultat de l'action, l'application concernée et l'heure à laquelle l'utilisateur a agi. -Cliquez sur la ligne du tableau pour voir plus de détails dans le journal utilisateur, par exemple, l'adresse IP, l'agent utilisateur, les données brutes, etc. +Cliquez sur la ligne du tableau pour voir plus de détails dans le journal utilisateur, par exemple l'adresse IP, l'agent utilisateur, les données brutes, etc. ### Suspendre un utilisateur \{#suspend-user} -Sur la page des détails de l'utilisateur, cliquez sur "Trois points" -> bouton "Suspendre l'utilisateur". +Sur la page "Détails de l'utilisateur", cliquez sur "Trois points" -> bouton "Suspendre l'utilisateur". -Une fois qu'un utilisateur est suspendu, il ne pourra plus se connecter à votre application et ne pourra plus obtenir un nouveau jeton d’accès après l'expiration de l'actuel. De plus, toute requête API effectuée par cet utilisateur échouera. +Une fois qu'un utilisateur est suspendu, il ne pourra plus se connecter à votre application et ne pourra plus obtenir de nouveau jeton d’accès après l'expiration de l'actuel. De plus, toute requête API effectuée par cet utilisateur échouera. Si vous souhaitez réactiver cet utilisateur, vous pouvez le faire en cliquant sur "Trois points" -> bouton "Réactiver l'utilisateur". ### Supprimer un utilisateur \{#delete-user} -Sur la page des détails de l'utilisateur, cliquez sur "Trois points" -> bouton "Supprimer". La suppression d'un utilisateur est irréversible. +Sur la page "Détails de l'utilisateur", cliquez sur "Trois points" -> bouton "Supprimer". La suppression d'un utilisateur est irréversible. ### Réinitialiser le mot de passe utilisateur \{#reset-user-password} -Sur la page des détails de l'utilisateur, cliquez sur "Trois points" -> bouton "Réinitialiser le mot de passe", puis Logto régénérera automatiquement un mot de passe aléatoire. +Sur la page "Détails de l'utilisateur", cliquez sur "Trois points" -> bouton "Réinitialiser le mot de passe", puis Logto régénérera automatiquement un mot de passe aléatoire. -Après avoir réinitialisé le mot de passe, copiez-le et envoyez-le à l'utilisateur final. Une fois la fenêtre modale "Réinitialiser le mot de passe" fermée, vous ne pourrez plus voir le mot de passe. Si vous oubliez de le conserver, vous pouvez le réinitialiser à nouveau. +Après avoir réinitialisé le mot de passe, copiez-le et envoyez-le à l'utilisateur final. Une fois la fenêtre modale "Réinitialiser le mot de passe" fermée, vous ne pourrez plus consulter le mot de passe. Si vous oubliez de le conserver, vous pouvez le réinitialiser à nouveau. Vous ne pouvez pas définir un mot de passe spécifique pour les utilisateurs dans la Console Logto, mais vous pouvez utiliser le [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` pour spécifier un mot de passe. +## Vérification de la conformité des mots de passe \{#password-compliance-check} + +Après avoir mis à jour la [politique de mot de passe](/security/password-policy) dans Logto, les utilisateurs existants peuvent toujours se connecter avec leurs mots de passe actuels. Seuls les nouveaux comptes créés devront respecter la nouvelle politique de mot de passe. + +Pour renforcer la sécurité, vous pouvez utiliser l’[API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) `POST /api/sign-in-exp/default/check-password` pour vérifier si le mot de passe d'un utilisateur respecte la politique actuelle définie dans l'expérience de connexion par défaut. Si ce n'est pas le cas, vous pouvez inviter l'utilisateur à mettre à jour son mot de passe via un flux personnalisé utilisant [Account API](/end-user-flows/account-settings/by-management-api#user-password-management). + ### Gérer les rôles des utilisateurs \{#manage-roles-of-users} -Dans l'onglet "Rôles" de la page des détails de l'utilisateur, vous pouvez facilement attribuer ou retirer des rôles selon le résultat souhaité. Consultez [Contrôle d’accès basé sur les rôles (RBAC)](/authorization/role-based-access-control) pour plus de détails. +Dans l'onglet "Rôles" de la page des détails de l'utilisateur, vous pouvez facilement attribuer ou retirer des rôles selon vos besoins. Consultez [Contrôle d’accès basé sur les rôles (RBAC)](/authorization/role-based-access-control) pour plus de détails. -### Voir les organisations auxquelles appartient l'utilisateur \{#view-the-organizations-the-user-belongs-to} +### Voir les organisations auxquelles l'utilisateur appartient \{#view-the-organizations-the-user-belongs-to} -Logto prend en charge les [organisations](/organizations/organization-management) et peut gérer leurs membres. Vous pouvez facilement consulter les détails de l'utilisateur et voir à quelle organisation il appartient. +Logto prend en charge les [organisations](/organizations/organization-management) et peut gérer leurs membres. Vous pouvez facilement consulter les détails d'un utilisateur et voir à quelle organisation il appartient. -## Gérer via le Management API Logto \{#manage-via-logto-management-api} +## Gérer via Logto Management API \{#manage-via-logto-management-api} -Le [Management API](/concepts/core-service/#management-api) est un ensemble d'API qui donnent accès au service backend Logto. Comme mentionné précédemment, l'API utilisateur est un composant essentiel de ce service et peut prendre en charge un large éventail de scénarios. +Le [Management API](/concepts/core-service/#management-api) est un ensemble d'API qui donnent accès au service backend de Logto. Comme mentionné précédemment, l'API utilisateur est un composant essentiel de ce service et peut prendre en charge un large éventail de scénarios. -Les [API RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) liées aux utilisateurs sont montées sur `/api/users` à l'exception des activités utilisateur, c'est-à-dire les journaux utilisateur `/api/logs?userId=:userId`. +Les API [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) liées aux utilisateurs sont montées sur `/api/users` à l'exception des activités utilisateur, c'est-à-dire les journaux utilisateur `/api/logs?userId=:userId`. -Vous pouvez gérer les utilisateurs via le Management API dans plusieurs cas d'utilisation. Par exemple, [recherche avancée d'utilisateurs](/user-management/advanced-user-search), [création de comptes en masse](https://openapi.logto.io/operation/operation-createuser), [inscription sur invitation uniquement](/end-user-flows/sign-up-and-sign-in/disable-user-registration), etc. +Vous pouvez gérer les utilisateurs via le Management API dans plusieurs cas d'utilisation, tels que [recherche avancée d'utilisateurs](/user-management/advanced-user-search), [création de comptes en masse](https://openapi.logto.io/operation/operation-createuser), [inscription sur invitation uniquement](/end-user-flows/sign-up-and-sign-in/disable-user-registration), etc. ## FAQ \{#faqs} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index ded7f107770..9dd5125223c 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -12,11 +12,11 @@ Chaque utilisateur possède un profil contenant [toutes les informations utilisa Il se compose des types de données suivants : -- [Données de base](/user-management/user-data#basic-data) : il s'agit des informations de base du profil utilisateur. Elles stockent toutes les autres propriétés de l’_utilisateur_ à l’exception des `identities` sociales et des `custom_data`, telles que l’identifiant utilisateur, le nom d’utilisateur, l’e-mail, le numéro de téléphone et la date de dernière connexion de l’utilisateur. -- [Identités sociales](/user-management/user-data#social-identities) : stocke les informations utilisateur récupérées lors de la connexion sociale (c’est-à-dire la connexion avec un connecteur social), telles que Facebook, GitHub et WeChat. -- [Données personnalisées](/user-management/user-data#custom-data) : stocke des informations utilisateur supplémentaires non listées dans les propriétés prédéfinies de l’utilisateur, telles que la couleur et la langue préférées de l’utilisateur. +- [Données de base](/user-management/user-data#basic-data) : il s'agit des informations de base du profil utilisateur. Elles stockent toutes les autres propriétés de l’_utilisateur_ à l’exception des `identities` sociales et des `custom_data`, telles que l'identifiant utilisateur, le nom d'utilisateur, l'e-mail, le numéro de téléphone et la date de dernière connexion de l'utilisateur. +- [Identités sociales](/user-management/user-data#social-identities) : stocke les informations utilisateur récupérées lors de la connexion sociale (c’est-à-dire la connexion avec un connecteur social), comme Facebook, GitHub et WeChat. +- [Données personnalisées](/user-management/user-data#custom-data) : stocke des informations utilisateur supplémentaires non listées dans les propriétés prédéfinies, telles que la couleur et la langue préférées de l'utilisateur. -Voici un exemple de données utilisateur récupérées lors d’une connexion à Facebook : +Voici un exemple de données utilisateur récupérées lors d'une connexion à Facebook : ```json { @@ -52,39 +52,43 @@ Vous pouvez interroger le profil utilisateur via Logto Co ## Données de base \{#basic-data} -Passons en revue toutes les propriétés des _données de base_ de l’utilisateur. +Passons en revue toutes les propriétés des _données de base_ de l'utilisateur. ### id \{#id} -_id_ est une clé unique générée automatiquement pour identifier l’utilisateur dans Logto. +_id_ est une clé unique générée automatiquement pour identifier l'utilisateur dans Logto. ### username \{#username} _username_ est utilisé pour la connexion avec _username_ et mot de passe. -Sa valeur provient du nom d’utilisateur avec lequel l’utilisateur s’est inscrit pour la première fois. Elle peut être `null`. Sa valeur non nulle ne doit pas dépasser 128 caractères, ne contenir que des lettres, des chiffres et des underscores (`_`), et NE PAS commencer par un chiffre. Elle est sensible à la casse. +Sa valeur provient du nom d'utilisateur avec lequel l'utilisateur s'est inscrit pour la première fois. Elle peut être `null`. Sa valeur non nulle ne doit pas dépasser 128 caractères, ne contenir que des lettres, des chiffres et des underscores (`_`), et NE PAS commencer par un chiffre. Elle est sensible à la casse. ### primary_email \{#primary_email} -_primary_email_ est l’adresse e-mail de l’utilisateur, utilisée pour la connexion avec l’e-mail et le mot de passe / code de vérification. +_primary_email_ est l'adresse e-mail de l'utilisateur, utilisée pour la connexion avec l'e-mail et le mot de passe / code de vérification. -Sa valeur provient généralement de l’adresse e-mail avec laquelle l’utilisateur s’est inscrit pour la première fois. Elle peut être `null`. Sa longueur maximale est de 128. +Sa valeur provient généralement de l'adresse e-mail avec laquelle l'utilisateur s'est inscrit pour la première fois. Elle peut être `null`. Sa longueur maximale est de 128. + +Seules les adresses e-mail vérifiées provenant de fournisseurs d'identité sociale ou SSO d’entreprise peuvent être synchronisées et enregistrées comme `primary_email`. ### primary_phone \{#primary_phone} -_primary_phone_ est le numéro de téléphone de l’utilisateur, utilisé pour la connexion avec le numéro de téléphone et le mot de passe / code de vérification reçu par SMS. +_primary_phone_ est le numéro de téléphone de l'utilisateur, utilisé pour la connexion avec le numéro de téléphone et le mot de passe / code de vérification par SMS. + +Sa valeur provient généralement du numéro de téléphone avec lequel l'utilisateur s'est inscrit pour la première fois. Elle peut être `null`. Sa valeur non nulle doit contenir des chiffres précédés de l’[indicatif téléphonique du pays](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (sans le signe plus `+`). -Sa valeur provient généralement du numéro de téléphone avec lequel l’utilisateur s’est inscrit pour la première fois. Elle peut être `null`. Sa valeur non nulle doit contenir des chiffres précédés de l’[indicatif téléphonique du pays](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (sans le signe plus `+`). +Seuls les numéros de téléphone vérifiés provenant de fournisseurs d'identité sociale ou SSO d’entreprise peuvent être synchronisés et enregistrés comme `primary_phone`. ### name \{#name} -_name_ est le nom complet de l’utilisateur. Sa longueur maximale est de 128. +_name_ est le nom complet de l'utilisateur. Sa longueur maximale est de 128. ### avatar \{#avatar} -_avatar_ est l’URL pointant vers l’image de l’avatar de l’utilisateur. Sa longueur maximale est de 2048. +_avatar_ est l’URL pointant vers l’image d’avatar de l’utilisateur. Sa longueur maximale est de 2048. -Si l’utilisateur s’inscrit avec un connecteur social comme Google ou Facebook, sa valeur peut être récupérée à partir des informations sociales de l’utilisateur. +Si l'utilisateur s'inscrit avec un connecteur social comme Google ou Facebook, sa valeur peut être récupérée à partir des informations sociales de l'utilisateur. :::note @@ -94,9 +98,9 @@ Cette propriété est mappée à la revendication `picture` dans la norme [OpenI ### profile \{#profile} -_profile_ stocke les [revendications standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) OpenID Connect supplémentaires qui ne sont pas incluses dans les propriétés de l’utilisateur. +_profile_ stocke des [revendications standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) OpenID Connect supplémentaires qui ne sont pas incluses dans les propriétés utilisateur. -Sa définition de type peut être trouvée dans [ce fichier](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6). Voici une copie de la définition de type : +Sa définition de type se trouve dans [ce fichier](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6). Voici une copie de la définition de type : ```tsx type UserProfile = Partial<{ @@ -128,11 +132,11 @@ type UserProfile = Partial<{ ::: -Une différence par rapport aux autres revendications standard est que les propriétés dans `profile` ne seront incluses dans le [jeton d’identifiant (ID token)](https://auth.wiki/id-token) ou la réponse de l’endpoint userinfo que si leurs valeurs ne sont pas vides, tandis que les autres revendications standard retourneront `null` si les valeurs sont vides. +Une différence par rapport aux autres revendications standard est que les propriétés dans `profile` ne seront incluses dans le [Jeton d’identifiant (ID token)](https://auth.wiki/id-token) ou la réponse de l’endpoint userinfo que si leurs valeurs ne sont pas vides, tandis que les autres revendications standard retourneront `null` si les valeurs sont vides. ### application_id \{#application_id} -La valeur de _application_id_ provient de l’application à laquelle l’utilisateur s’est connecté pour la première fois. Elle peut être `null`. +La valeur de _application_id_ provient de l'application à laquelle l'utilisateur s'est connecté pour la première fois. Elle peut être `null`. ### last_sign_in_at \{#last_sign_in_at} @@ -144,23 +148,23 @@ _created_at_ est l’horodatage avec le fuseau horaire lors de l’inscription d ### updated_at \{#updated_at} -_updated_at_ est l’horodatage avec le fuseau horaire lors de la dernière mise à jour des informations du profil utilisateur. +_updated_at_ est l’horodatage avec le fuseau horaire de la dernière mise à jour des informations du profil utilisateur. ### has_password \{#has_password} -_has_password_ est une valeur booléenne qui indique si l’utilisateur possède un mot de passe. Vous pouvez consulter et gérer ce statut, y compris définir ou réinitialiser le mot de passe sur la page de détail de Console > Gestion des utilisateurs. +_has_password_ est une valeur booléenne qui indique si l'utilisateur possède un mot de passe. Vous pouvez consulter et gérer ce statut, y compris définir ou réinitialiser le mot de passe sur la page de détail de Console > Gestion des utilisateurs. ### password_encrypted \{#password_encrypted} -_password_encrypted_ est utilisé pour stocker le mot de passe chiffré de l’utilisateur. +_password_encrypted_ est utilisé pour stocker le mot de passe chiffré de l'utilisateur. -Sa valeur provient du mot de passe avec lequel l’utilisateur s’est inscrit pour la première fois. Elle peut être `null`. Si sa valeur est non nulle, son contenu original avant chiffrement doit comporter au moins six caractères. +Sa valeur provient du mot de passe avec lequel l'utilisateur s'est inscrit pour la première fois. Elle peut être `null`. Si sa valeur est non nulle, son contenu original avant chiffrement doit comporter au moins six caractères. ### password_encryption_method \{#password_encryption_method} -_password_encryption_method_ est utilisé pour chiffrer le mot de passe de l’utilisateur. Sa valeur est initialisée lors de l’inscription de l’utilisateur avec un nom d’utilisateur et un mot de passe. Elle peut être `null`. +_password_encryption_method_ est utilisé pour chiffrer le mot de passe de l'utilisateur. Sa valeur est initialisée lors de l'inscription de l'utilisateur avec un nom d'utilisateur et un mot de passe. Elle peut être `null`. -Logto utilise par défaut l’implémentation [node-argon2](https://github.com/ranisalt/node-argon2) d’[Argon2](https://en.wikipedia.org/wiki/Argon2) comme méthode de chiffrement ; voir la référence pour plus de détails si cela vous intéresse. +Logto utilise par défaut l’implémentation [Argon2](https://en.wikipedia.org/wiki/Argon2) [node-argon2](https://github.com/ranisalt/node-argon2) comme méthode de chiffrement ; consultez la référence pour plus de détails si cela vous intéresse. Exemple de _password_encrypted_ et _password_encryption_method_ pour un utilisateur dont le mot de passe est `123456` : @@ -175,7 +179,7 @@ Exemple de _password_encrypted_ et _password_encryption_method_ pour un utilisat _is_suspended_ est une valeur booléenne qui indique si un utilisateur est suspendu ou non. La valeur peut être gérée en appelant la [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) ou en utilisant Logto Console. -Une fois qu’un utilisateur est suspendu, les jetons de rafraîchissement préalablement accordés seront immédiatement révoqués et l’utilisateur ne pourra plus être authentifié par Logto. +Une fois qu'un utilisateur est suspendu, les jetons de rafraîchissement préalablement accordés seront immédiatement révoqués et l'utilisateur ne pourra plus être authentifié par Logto. ### mfa_verification_factors \{#mfa_verification_factors} @@ -187,17 +191,17 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; ## Identités sociales \{#social-identities} -_identities_ contient les informations utilisateur récupérées lors de la [connexion sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in) (c’est-à-dire la connexion avec un [connecteur social](/connectors/social-connectors)). Les _identities_ de chaque utilisateur sont stockées dans un objet JSON individuel. +_identities_ contient les informations utilisateur récupérées lors de la [connexion sociale](/end-user-flows/sign-up-and-sign-in/social-sign-in) (c’est-à-dire connexion avec un [connecteur social](/connectors/social-connectors)). Chaque _identities_ d’utilisateur est stocké dans un objet JSON individuel. -Les informations utilisateur varient selon le fournisseur d’identité sociale (c’est-à-dire la plateforme de réseau social), et incluent généralement les éléments suivants : +Les informations utilisateur varient selon le fournisseur d'identité sociale (c’est-à-dire la plateforme de réseau social), et incluent généralement : -- _target_ du fournisseur d’identité, tel que "facebook" ou "google" -- Identifiant unique de l’utilisateur pour ce fournisseur -- Nom de l’utilisateur -- E-mail vérifié de l’utilisateur -- Avatar de l’utilisateur +- _target_ du fournisseur d'identité, comme "facebook" ou "google" +- Identifiant unique de l'utilisateur pour ce fournisseur +- Nom de l'utilisateur +- E-mail vérifié de l'utilisateur +- Avatar de l'utilisateur -Le compte de l’utilisateur peut être lié à plusieurs fournisseurs d’identité sociale via la connexion sociale ; les informations utilisateur correspondantes récupérées auprès de ces fournisseurs seront stockées dans l’objet _identities_. +Le compte utilisateur peut être lié à plusieurs fournisseurs d'identité sociale via la connexion sociale ; les informations correspondantes récupérées auprès de ces fournisseurs seront stockées dans l'objet _identities_. Exemple d’_identities_ pour un utilisateur connecté à la fois avec Google et Facebook : @@ -226,9 +230,9 @@ Exemple d’_identities_ pour un utilisateur connecté à la fois avec Google et ## Identités SSO \{#sso-identities} -_sso_identities_ contient les informations utilisateur récupérées lors du [SSO d’entreprise](/end-user-flows/enterprise-sso) (c’est-à-dire connexion Single Sign-On avec un [connecteur d’entreprise](/connectors/enterprise-connectors)). Les _ssoIdentities_ de chaque utilisateur sont stockées dans un objet JSON individuel. +_sso_identities_ contient les informations utilisateur récupérées lors du [SSO d’entreprise](/end-user-flows/enterprise-sso) (c’est-à-dire connexion Single Sign-On avec un [connecteur d’entreprise](/connectors/enterprise-connectors)). Chaque _ssoIdentities_ d’utilisateur est stocké dans un objet JSON individuel. -Les données synchronisées depuis le fournisseur d’identité SSO dépendent des portées configurées dans le connecteur d’entreprise à demander. Voici une copie de la définition de type TypeScript : +Les données synchronisées depuis le fournisseur d'identité SSO dépendent des portées configurées dans le connecteur d’entreprise. Voici une copie de la définition de type TypeScript : ```ts type SSOIdentity = { @@ -240,12 +244,12 @@ type SSOIdentity = { ## Données personnalisées \{#custom-data} -_custom_data_ stocke des informations utilisateur supplémentaires non listées dans les propriétés prédéfinies de l’utilisateur. +_custom_data_ stocke des informations utilisateur supplémentaires non listées dans les propriétés prédéfinies. -Vous pouvez utiliser _custom_data_ pour faire les choses suivantes : +Vous pouvez utiliser _custom_data_ pour : -- Enregistrer si des actions spécifiques ont été effectuées par l’utilisateur, comme avoir vu la page d’accueil. -- Stocker des données spécifiques à l’application dans le profil utilisateur, telles que la langue et l’apparence préférées de l’utilisateur par application. +- Enregistrer si des actions spécifiques ont été effectuées par l'utilisateur, comme avoir vu la page de bienvenue. +- Stocker des données spécifiques à l’application dans le profil utilisateur, telles que la langue et l’apparence préférées par application. - Maintenir d’autres données arbitraires liées à l’utilisateur. Exemple de _custom_data_ pour un utilisateur administrateur dans Logto : @@ -266,7 +270,7 @@ Exemple de _custom_data_ pour un utilisateur administrateur dans Logto : } ``` -Les _custom_data_ de chaque utilisateur sont stockées dans un objet JSON individuel. +Chaque _custom_data_ d’utilisateur est stocké dans un objet JSON individuel. :::note @@ -274,26 +278,26 @@ NE METTEZ PAS de données sensibles dans _custom_data_. ::: -Les données personnalisées peuvent être accessibles via les [revendications personnalisées du jeton JWT](/developers/custom-token-claims) après la connexion de l’utilisateur, et les jetons JWT sont encodés en base64 (non chiffrés) et fréquemment transmis sur les réseaux, ce qui rend toute donnée sensible facilement exposée. +Les données personnalisées peuvent être accessibles via les [revendications personnalisées de jeton JWT](/developers/custom-token-claims) après la connexion de l'utilisateur, et les jetons JWT sont encodés en base64 (non chiffrés) et fréquemment transmis sur les réseaux, ce qui rend toute donnée sensible facilement exposée. -Vous pouvez récupérer un profil utilisateur contenant _custom_data_ via la [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) et l’envoyer aux applications frontend ou aux services backend externes. Par conséquent, mettre des informations sensibles dans _custom_data_ peut entraîner des fuites de données. +Vous pouvez récupérer un profil utilisateur contenant _custom_data_ via la [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) et l’envoyer aux applications frontend ou à des services backend externes. Par conséquent, mettre des informations sensibles dans _custom_data_ peut entraîner des fuites de données. -Si vous souhaitez tout de même placer des informations sensibles dans _custom_data_, nous recommandons de les chiffrer au préalable. Chiffrez/déchiffrez-les uniquement dans une partie de confiance comme vos services backend, et évitez de le faire dans les applications frontend. Cela minimisera les pertes si les _custom_data_ de vos utilisateurs sont divulguées par erreur. +Si vous souhaitez tout de même placer des informations sensibles dans _custom_data_, nous recommandons de les chiffrer au préalable. Chiffrez/déchiffrez uniquement dans une partie de confiance comme vos services backend, et évitez de le faire dans les applications frontend. Cela minimisera les pertes si le _custom_data_ de vos utilisateurs est divulgué par erreur. **Comment collecter et mettre à jour les données personnalisées utilisateur** -- Utilisez la fonctionnalité [Collecter le profil utilisateur](/end-user-flows/collect-user-profile) pour recueillir des données personnalisées lors de l’inscription de l’utilisateur. +- Utilisez la fonctionnalité [Collecte du profil utilisateur](/end-user-flows/collect-user-profile) pour recueillir des données personnalisées lors de l’inscription. - Utilisez l’[Account API](/end-user-flows/account-settings/by-account-api) pour implémenter le profil utilisateur ou les paramètres de compte côté utilisateur final. - Utilisez [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) pour récupérer toutes les données utilisateur. - - Utilisez [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) pour mettre à jour les _custom_data_ d’un utilisateur. + - Utilisez [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) pour mettre à jour le _custom_data_ d’un utilisateur. - Utilisez la [Management API](/user-management/manage-users/#manage-via-logto-management-api) pour la gestion des utilisateurs ou des flux personnalisés avancés : - Utilisez [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) pour récupérer toutes les données utilisateur. - - Utilisez [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) pour mettre à jour les _custom_data_ d’un utilisateur. -- Votre équipe support peut directement mettre à jour les _custom_data_ utilisateur dans Console > Gestion des utilisateurs. En savoir plus sur [la consultation et la mise à jour des profils utilisateur](/user-management/manage-users/#view-and-update-the-user-profile). + - Utilisez [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) pour mettre à jour le _custom_data_ d’un utilisateur. +- Votre équipe support peut directement mettre à jour le _custom_data_ utilisateur dans Console > Gestion des utilisateurs. En savoir plus sur [la consultation et la mise à jour des profils utilisateur](/user-management/manage-users/#view-and-update-the-user-profile). -Mettez à jour avec précaution. La mise à jour des _custom_data_ d’un utilisateur écrasera complètement son contenu original dans le stockage. +Mettez à jour avec précaution. La mise à jour du _custom_data_ d’un utilisateur écrasera complètement son contenu original dans le stockage. -Par exemple, si votre entrée lors de l’appel de l’API de mise à jour _custom_data_ ressemble à ceci (supposons que le _custom_data_ original soit l’exemple de données précédent) : +Par exemple, si votre entrée lors de l’appel de l’API de mise à jour _custom_data_ ressemble à ceci (en supposant que le _custom_data_ original est celui de l’exemple précédent) : ```json { @@ -322,7 +326,7 @@ Les colonnes suivantes de la table utilisateur en base de données (sauf _passwo | Nom | Type | Description | Unique | Requis | | ----------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------- | ------ | ------ | | [id](/user-management/user-data#id) | string | Identifiant unique | ✅ | ✅ | -| [username](/user-management/user-data#username) | string | Nom d’utilisateur pour la connexion | ✅ | ❌ | +| [username](/user-management/user-data#username) | string | Nom d'utilisateur pour la connexion | ✅ | ❌ | | [primary_email](/user-management/user-data#primary_email) | string | E-mail principal | ✅ | ❌ | | [primary_phone](/user-management/user-data#primary_phone) | string | Numéro de téléphone principal | ✅ | ❌ | | [name](/user-management/user-data#name) | string | Nom complet | ❌ | ❌ | @@ -330,11 +334,11 @@ Les colonnes suivantes de la table utilisateur en base de données (sauf _passwo | [profile](/user-management/user-data#profile) | object | Profil utilisateur | ❌ | ✅ | | [identities](/user-management/user-data#social-identities) | object | Infos utilisateur issues de la connexion sociale | ❌ | ✅ | | [custom_data](/user-management/user-data#custom-data) | object | Infos supplémentaires dans les propriétés personnalisables | ❌ | ✅ | -| [application_id](/user-management/user-data#application_id) | string | ID de l’application à laquelle l’utilisateur s’est inscrit | ❌ | ✅ | +| [application_id](/user-management/user-data#application_id) | string | ID de l’application à la première inscription | ❌ | ✅ | | [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | Horodatage de la dernière connexion | ❌ | ✅ | | [password_encrypted](/user-management/user-data#password_encrypted) | string | Mot de passe chiffré | ❌ | ❌ | | [password_encryption_method](/user-management/user-data#password_encryption_method) | string | Méthode de chiffrement du mot de passe | ❌ | ❌ | -| [is_suspended](/user-management/user-data#is_suspended) | bool | Marque de suspension de l’utilisateur | ❌ | ✅ | +| [is_suspended](/user-management/user-data#is_suspended) | bool | Marque de suspension utilisateur | ❌ | ✅ | | [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | Facteurs de vérification MFA | ❌ | ✅ | - **Unique** : Garantit l’[unicité](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS) des valeurs saisies dans une propriété d’une table de base de données. diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index 4421d1f9f2c..5fde7cd9e9a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -17,7 +17,7 @@ Logto のロールベースのアクセス制御 (RBAC) を使用して、プロ ## グローバル API リソースとは? \{#what-are-global-api-resources} -グローバル API リソースとは、組織やテナントに関係なく、すべてのユーザーがアクセスできるアプリケーション内のエンドポイントやサービスです。これらは通常、パブリック向け API やコアプロダクトサービス、特定の組織に限定されないエンドポイントです。 +グローバル API リソースとは、組織やテナントに関係なく、すべてのユーザーがアクセスできるアプリケーション内のエンドポイントやサービスです。これらは通常、パブリック向け API、コアプロダクトサービス、または特定の組織に限定されないエンドポイントです。 **ユースケース例** @@ -29,9 +29,9 @@ Logto では、OAuth 2.1 と柔軟なロールベースのアクセス制御を ## Logto での仕組み \{#how-it-works-in-logto} -- **API リソースと権限はグローバルに登録される:** 保護したい各 API は、一意のリソースインジケーター(URI)とアクセスを制御する権限(スコープ)のセットで定義します。 -- **アクセスはグローバルロールで制御:** 権限をロールに割り当て、さらにそのロールをユーザーやクライアントに割り当てます。 -- **組織レベルの権限とは分離:** グローバル API リソースには組織のコンテキストがありません。ただし、必要に応じて組織ロールと組み合わせて追加のコンテキストを提供することも可能です。組織レベルの API を保護する場合は、[組織レベル API リソースの保護](/authorization/organization-level-api-resources) を参照してください。 +- **API リソースと権限はグローバルに登録される:** 保護したい各 API は、一意のリソースインジケーター(URI)とアクセスを制御する権限(スコープ)のセットで定義されます。 +- **アクセスはグローバルロールで制御:** 権限をロールに割り当て、それをユーザーやクライアントに割り当てます。 +- **組織レベルの権限とは分離:** グローバル API リソースには組織の文脈がありません。ただし、必要に応じて組織ロールと組み合わせて追加の文脈を提供することも可能です。組織レベルの API を保護するには、[組織レベルの API リソースの保護](/authorization/organization-level-api-resources) を参照してください。 グローバル API リソース RBAC @@ -40,8 +40,8 @@ Logto では、OAuth 2.1 と柔軟なロールベースのアクセス制御を 1. **API リソースを登録**し、Logto でその権限を定義します。 2. **API へのアクセスに必要な権限を持つロールを定義**します。 3. **ロールをユーザーやクライアントに割り当て**ます。 -4. **OAuth 2.0 認可フロー**を使用して API 用のアクセス トークンを取得します(resource パラメーターは登録した API 識別子と一致する必要があります)。 -5. **API 内でアクセス トークンを検証**し、権限を強制します。 +4. **OAuth 2.0 認可フローを使用して** API 用のアクセス トークンを取得します(resource パラメーターは登録した API 識別子と一致させる必要があります)。 +5. **API でアクセス トークンを検証**し、権限を強制します。 ### リソースインジケーターの理解 \{#understanding-resource-indicators} @@ -60,9 +60,9 @@ Logto は [RFC 8707: OAuth 2.0 のリソースインジケーター](https://www ### 認可フロー:API の認証と保護 \{#authorization-flow-authenticating-and-securing-your-api} -以下のフローは、インタラクティブなユーザー認証(ブラウザ/アプリ)とバックエンドのマシン間通信 (M2M) シナリオの両方に適用されます。 +以下のフローは、インタラクティブなユーザー認証(ブラウザ / アプリ)とバックエンドのマシン間通信 (M2M) シナリオの両方に適用されます。 -このフローは必要なパラメーターやヘッダーの詳細を網羅しているわけではなく、主要なステップに焦点を当てています。実際の動作例はこの後の説明を参照してください。 +このフローは必要なパラメーターやヘッダーの詳細をすべて網羅しているわけではなく、主要なステップに焦点を当てています。実際のフローの動作については、引き続きお読みください。 ```mermaid sequenceDiagram @@ -96,24 +96,24 @@ sequenceDiagram end ``` -_ユーザー認証 = ブラウザ/アプリ。M2M = クライアントクレデンシャルを使うバックエンドサービスやスクリプト。_ +_ユーザー認証 = ブラウザ / アプリ。M2M = クライアント認証を使うバックエンドサービスやスクリプト。_ :::note -`resource` パラメーターは、Logto で登録した API 識別子(リソースインジケーター)と完全に一致する必要があります。 +`resource` パラメーターは、Logto で登録した API 識別子(リソースインジケーター)と完全に一致している必要があります。 ::: ## 実装手順 \{#implementation-steps} ### API リソースの登録 \{#register-your-api-resources} -1. コンソール → API リソース にアクセスします。 +1. コンソール → API リソース に移動します。 2. 新しい API リソース(例: `https://api.yourapp.com/org`)を作成し、その権限(スコープ)を定義します。 詳細な設定手順は [権限付き API リソースの定義](/authorization/role-based-access-control#define-api-resources-with-permissions) を参照してください。 ### グローバルロールの設定 \{#set-up-global-roles} -1. コンソール → ロール にアクセスします。 +1. コンソール → ロール に移動します。 2. API 権限に対応するロール(例: `read:products`、 `write:products`)を作成します。 3. これらのロールを API へのアクセスが必要なユーザーやクライアントに割り当てます。 @@ -121,18 +121,18 @@ _ユーザー認証 = ブラウザ/アプリ。M2M = クライアントクレ ### グローバル API リソース用のアクセス トークンの取得 \{#obtain-access-tokens-for-global-api-resources} -グローバル API リソースへアクセスする前に、クライアントはアクセス トークンを取得する必要があります。Logto はグローバル API リソース用の [JSON Web Token (JWT)](https://auth.wiki/jwt) をアクセス トークンとして発行します。これは通常、[OAuth 2.0 認可コードフロー](https://auth.wiki/authorization-code-flow)、[リフレッシュ トークンフロー](https://auth.wiki/refresh-token)、または [クライアントクレデンシャルフロー](https://auth.wiki/client-credentials-flow) を使用して行われます。 +グローバル API リソースにアクセスする前に、クライアントはアクセス トークンを取得する必要があります。Logto はグローバル API リソース用の [JSON Web Token (JWT)](https://auth.wiki/jwt) をアクセス トークンとして発行します。これは通常、[OAuth 2.0 認可コードフロー](https://auth.wiki/authorization-code-flow)、[リフレッシュ トークンフロー](https://auth.wiki/refresh-token)、または [クライアント認証フロー](https://auth.wiki/client-credentials-flow) を使用して行われます。 #### 認可コードまたはリフレッシュ トークンフロー \{#authorization-code-or-refresh-token-flow} -すべての Logto 公式 SDK は、リフレッシュ トークンフローを使ったグローバル API リソース用のアクセス トークン取得を標準でサポートしています。標準的な OAuth 2.0 / OIDC クライアントライブラリでもこのフローを実装できます。 +Logto 公式 SDK はすべて、リフレッシュ トークンフローを利用したグローバル API リソース用のアクセス トークン取得をサポートしています。標準的な OAuth 2.0 / OIDC クライアントライブラリでもこのフローを実装できます。 -Logto クライアント初期化時に、`resources` パラメーター(配列)へリソースインジケーターを追加し、`scopes` パラメーターに必要な権限(スコープ)を追加します。 +Logto クライアントの初期化時に、`resources` パラメーター(配列)にリソースインジケーターを追加し、`scopes` パラメーターに必要な権限(スコープ)を追加します。 -ユーザーが認証 (Authentication) された後、アクセス トークンをリクエストする際に `resource` パラメーターまたは同様のパラメーターでリソースインジケーターを渡します(例: `getAccessToken()` の呼び出し時)。 +ユーザーが認証された後、`getAccessToken()` などでアクセス トークンをリクエストする際に、`resource` パラメーターまたは同様のパラメーターでリソースインジケーターを渡します。 各 SDK の詳細は [クイックスタート](/quick-starts) を参照してください。 @@ -141,19 +141,19 @@ Logto クライアント初期化時に、`resources` パラメーター(配 OAuth 2.0 クライアントの設定や認可コードフローの初期化時に、`resource` パラメーターと必要なスコープを認可リクエストに含めてください。 -一部のライブラリは `resource` パラメーターをネイティブにサポートしていませんが、多くの場合、追加パラメーターとして認可リクエストに渡すことができます。詳細はライブラリのドキュメントを確認してください。 +一部のライブラリは `resource` パラメーターをネイティブにサポートしていませんが、通常は追加パラメーターとして認可リクエストに渡すことができます。詳細はご利用のライブラリのドキュメントを確認してください。 -`resource` および `scope` パラメーターを含む認可リクエストの非公式例: +`resource` および `scope` パラメーターを含む認可リクエストの非公式例を示します: -ユーザーが認証 (Authentication) されると、認可コードが返されます。このコードを Logto の `/oidc/token` エンドポイントへ POST し、リクエストボディに `resource` パラメーターを含めてアクセス トークンと交換します。 +ユーザーが認証されると、認可コードを受け取ります。このコードを Logto の `/oidc/token` エンドポイントに POST し、リクエストボディに `resource` パラメーターを含めてアクセス トークンと交換します。 認可コードグラントタイプを使ったトークンリクエストの非公式例: -また、`refresh_token` グラントタイプを使ってユーザー操作なしで新しいアクセス トークンを取得することもできます(リクエストに `resource` パラメーターを含める必要があります)。 +また、`refresh_token` グラントタイプを使えば、ユーザー操作なしで新しいアクセス トークンを取得できます(リクエストに `resource` パラメーターを含める必要があります)。 リフレッシュ トークングラントタイプを使ったトークンリクエストの非公式例: @@ -162,16 +162,16 @@ OAuth 2.0 クライアントの設定や認可コードフローの初期化時 -#### クライアントクレデンシャルフロー \{#client-credentials-flow} +#### クライアント認証フロー \{#client-credentials-flow} -マシン間通信 (M2M) シナリオでは、クライアントクレデンシャルフローを使ってグローバル API リソース用のアクセス トークンを取得できます。Logto の `/oidc/token` エンドポイントへ POST リクエストを送り、クライアント ID とシークレットでアクセス トークンをリクエストします。 +マシン間通信 (M2M) シナリオでは、クライアント認証フローを使ってグローバル API リソース用のアクセス トークンを取得できます。Logto の `/oidc/token` エンドポイントに POST リクエストを送り、クライアント ID とシークレットを使ってアクセス トークンをリクエストします。 -リクエストに含める主なパラメーターは 2 つです: +リクエストに含めるべき主なパラメーターは 2 つです: - `resource`: アクセスしたい API のリソースインジケーター URI(例: `https://api.yourapp.com`) -- `scope`: API に要求する権限(例: `read:products write:products`) +- `scope`: API にリクエストしたい権限(例: `read:products write:products`) -クライアントクレデンシャルグラントタイプを使ったトークンリクエストの非公式例: +クライアント認証グラントタイプを使ったトークンリクエストの非公式例: -Logto コンソールでデフォルトの API リソースを設定してください。トークンリクエストで resource パラメーターが指定されていない場合、このオーディエンスがデフォルトで使用されます。 +Logto コンソールでデフォルトの API リソースを設定してください。トークンリクエストで resource パラメーターが指定されていない場合、このオーディエンスがデフォルトになります。
-### API から 401 Unauthorized が返る理由は? \{#why-do-i-get-401-unauthorized-from-my-api} +### API から 401 Unauthorized が返される理由は? \{#why-do-i-get-401-unauthorized-from-my-api} -以下の一般的な問題を確認してください: +次の一般的な問題を確認してください: - **トークン署名**:バックエンドが Logto から正しい JWKs を取得しているか確認 -- **トークン有効期限**:トークンが期限切れでないか(`exp` クレーム) +- **トークンの有効期限**:トークンが有効期限切れでないか(`exp` クレーム) - **オーディエンス**:`aud` クレームが登録した API リソースインジケーターと一致しているか - **必要なスコープ**:トークンの `scope` クレームに必要な権限が含まれているか @@ -241,7 +241,37 @@ Logto コンソールでデフォルトの API リソースを設定してくだ -[パーソナルアクセストークン](/user-management/personal-access-token) を使って認証済みリクエストをシミュレートできます。これにより、クライアントアプリケーションで完全な OAuth フローを実装せずに API エンドポイントのテストが可能です。 +[パーソナルアクセストークン](/user-management/personal-access-token) を使って認証済みコールをシミュレートできます。これにより、クライアントアプリケーションで完全な OAuth フローを実装せずに API エンドポイントのテストが可能です。 + +
+ +
+ + +### 権限リクエスト時にスコープのプレフィックスや短縮形は使えますか? \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +いいえ。スコープ名は API リソースで定義した権限名と**完全一致**している必要があります。プレフィックスや短縮形はワイルドカードとして機能しません。 + +**例:** + +API リソースで次のように定義している場合: + +- `read:elections` +- `write:elections` + +リクエスト時は次のように指定する必要があります: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +これは**動作しません**: + +```swift +scopes: ["read", "write"] // ❌ 権限名と一致しません +```
@@ -249,7 +279,7 @@ Logto コンソールでデフォルトの API リソースを設定してくだ アクセス トークンの検証方法 - RBAC 実践例:アプリケーションの安全な認可 (Authorization) 実装 + RBAC 実践:アプリケーションの安全な認可 (Authorization) 実装 トークンクレームのカスタマイズ RFC 8707: リソースインジケーター diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index 14a29125b13..a7f0047edd1 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -4,38 +4,38 @@ sidebar_position: 4 # ローカライズ言語 -Logto は幅広い事前定義済み言語をサポートしており、さらに 113 の追加言語タグを提供しています。この強力なツールにより、サインイン体験をカスタマイズし、独自の言語オプションや翻訳を作成・管理できます。 +Logto は幅広い事前定義された言語をサポートしており、さらに 113 の追加言語タグを提供しています。この強力なツールにより、サインイン体験をカスタマイズし、独自の言語オプションや翻訳を作成・管理できます。 ## Logto コンソールでのカスタマイズ手順 \{#customization-steps-in-logto-console} Logto コンソールでコーディング不要で簡単に言語設定をカスタマイズできます。 -1. **移動先**: コンソール > サインイン体験 > コンテンツ > 言語。 -2. **言語の管理**: 「言語を管理」ボタンをクリックして言語ライブラリにアクセスします。 - - **既存言語の編集**:Logto が提供する言語の翻訳をカスタマイズできます。これらの言語は削除できませんが、変更内容はデフォルト値を上書きします。 +1. **移動先**:コンソール > サインイン体験 > コンテンツ > 言語 +2. **言語の管理**:「言語を管理」ボタンをクリックして言語ライブラリにアクセスします。 + - **既存言語の編集**:Logto が提供する言語の翻訳をカスタマイズできます。これらの言語は削除できませんが、変更内容がデフォルト値を上書きします。 - **新しい言語の追加**:「言語を追加」ボタンをクリックし、言語タグを選択、翻訳を入力して保存すると新しい言語が追加されます。 3. **自動検出の有効化**:有効にすると、ユーザーのデバイス設定に基づいてサインインページが自動的にユーザーの優先言語で表示されます。 4. **デフォルト言語の設定**:言語ライブラリからデフォルト言語を選択できます。検出されたユーザー言語が現在の言語ライブラリに含まれていない場合に使用されます。 -言語管理時に理解しておくべき主な用語は以下の通りです: +言語を管理する際に理解しておきたい主な用語は以下の通りです: -| 定義 | 説明 | -| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 言語タグ | 言語タグはコンテンツの言語を識別します。言語タグは言語コード(例: en, fr, zh)と国/地域コード(例: US, UK, KR)をハイフンで区切って構成されます。例: en-US のようになります。 | -| Logto 提供言語 | Logto 提供言語は Logto 公式の言語であり、Logto のオリジナルコードベースに保存されています。 | -| 追加言語 | 追加言語はユーザーによって追加された言語です。 | -| Logto ソース値 | Logto ソース値は、ユーザーによってカスタマイズされていない Logto から提供された値です。 | -| カスタム値 | カスタム値は、ユーザーによってすでにカスタマイズされた値です。Logto ソース値は上書きされます。 | +| 定義 | 説明 | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 言語タグ | 言語タグはコンテンツの言語を識別します。言語タグは言語コード(例:en, fr, zh)と国/地域コード(例:US, UK, KR)をハイフンで区切って構成されます。例:en-US のようになります。 | +| Logto 提供言語 | Logto 提供言語は Logto 公式の言語であり、Logto のオリジナルコードベースに保存されています。 | +| 追加言語 | 追加言語はユーザーによって追加された言語です。 | +| Logto ソース値 | Logto ソース値は、ユーザーによってカスタマイズされていない Logto から提供された値です。 | +| カスタム値 | カスタム値は、ユーザーによってすでにカスタマイズされた値です。Logto ソース値は上書きされます。 | ## Management API を使ったカスタマイズ \{#customization-using-management-api} -Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) を利用して言語翻訳をカスタマイズできます。API リクエストボディは次のような部分的なロケールオブジェクトです: +Management API の [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) を利用して言語翻訳をカスタマイズできます。API リクエストボディは次のような部分的なロケールオブジェクトです: ```json { "input": { "username": "Username", "password": "Password" }, "secondary": { - "social_bind_with": "すでにアカウントをお持ちですか?ソーシャルアイデンティティで {{methods, list(type: disjunction;)}} をリンクしてサインインしてください。" + "social_bind_with": "すでにアカウントをお持ちですか?サインインして {{methods, list(type: disjunction;)}} をソーシャルアイデンティティと連携しましょう。" }, "action": { "sign_in": "サインイン" }, "error": { @@ -54,13 +54,13 @@ Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.i ## 実行時の言語解決 \{#runtime-language-resolution} -実行時、サインイン体験の言語は次の優先順位で決定されます: +実行時には、サインイン体験の言語は次の優先順位で決定されます: 1. 現在の認証リクエストの `ui_locales` OIDC パラメーター(最初にサポートされているタグが使用されます)。詳しくは [ui_locales](/end-user-flows/authentication-parameters/ui-locales) を参照してください。 -2. それ以外の場合、「自動検出」が有効なら、検出されたユーザークライアント言語(例:HTTP `Accept-Language` ヘッダーから)。 +2. それ以外の場合、「自動検出」が有効なら、ユーザークライアントの検出された言語(例:HTTP `Accept-Language` ヘッダーから)。 3. それ以外の場合、サインイン体験のテナントのデフォルト言語。 -この解決方法は、インタラクションによってトリガーされるメッセージのメールローカライズにも影響します。詳しくは [メールテンプレートのローカライズ](/connectors/email-connectors/email-templates#email-template-localization) をご覧ください。 +この解決方法は、インタラクションによってトリガーされるメッセージのメールローカライズにも影響します。詳しくは:[メールテンプレートのローカライズ](/connectors/email-connectors/email-templates#email-template-localization) をご覧ください。 ## ユースケース \{#use-cases} @@ -72,7 +72,7 @@ Logto のサインイン体験 i18n により、カスタマイズした言語 `ja` 言語タグをクリックして独自の日本語翻訳を追加してください。 -このようにして、日本からアクセスするユーザーは、英語から翻訳した日本語のコンテンツを読むことができるようになります。 +このようにして、日本からアクセスするユーザーは、英語から翻訳した日本語のコンテンツを読むことができます。 ## よくある質問 \{#faqs} @@ -83,7 +83,7 @@ Logto のサインイン体験 i18n により、カスタマイズした言語 -左側の言語タグの隣に Logto 提供タグが表示され、追加した言語は削除できなくなります。変更した値は引き続き有効で、元の Logto 値を置き換えます。Logto のデフォルト設定値を使用したい場合は、ユーザーが入力した値を消去してください。 +左側の言語タグの横に Logto 提供タグが表示され、追加した言語は削除できなくなります。変更した値は引き続き有効で、元の Logto 値を置き換えます。Logto のデフォルト設定値を使用したい場合は、ユーザーが入力した値を消去してください。 @@ -95,12 +95,25 @@ Logto のサインイン体験 i18n により、カスタマイズした言語 最終的にユーザーが目にするのは、2 つのカラムがマージされた結果です。 -Logto が提供する元のコンテンツの一部だけを調整したい場合、サインアップ画面と Logto が提供する画面の違いは編集したキーのみとなります。他のコンテンツは変更されません。 +Logto が提供した元のコンテンツの一部だけを調整したい場合、サインアップ画面と Logto が提供する画面の違いは編集したキーのみとなり、それ以外の内容は変更されません。 + + + +
+ + +### サインイン体験でデフォルトの電話番号国コードを設定するには? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +[サインイン体験](/end-user-flows/sign-up-and-sign-in/sign-up) の電話番号国コードは、ユーザーのブラウザロケールがデフォルトになります。例えば、ユーザーのブラウザ言語が `fr` の場合、国コードはフランス(+33)になります。 + +特定のユーザーや地域向けにデフォルト国コードをプログラムで制御したい場合は、[`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 認証パラメーターを利用できます。例えば、`ui_locales=ja` を設定すると国コードは日本(+81)になります。
## 関連リソース \{#related-resources} - アプリケーションでアラビア語および RTL(右から左)言語レイアウトをサポートする + アプリケーションでアラビア語や RTL(右から左)言語レイアウトをサポートする diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index 5086d7cb8e7..83f4735d812 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -8,11 +8,11 @@ sidebar_position: 1 サインインページの見た目や雰囲気をカスタマイズするには、コンソール > サインイン体験 > ブランディング に移動してください。このセクションでは、主要なブランディング要素を簡単に調整できます。 -**ブランドカラー** +### ブランドカラー \{#brand-color} -サインイン体験全体で使用されるプライマリカラーを定義します。プライマリボタン、リンク、その他のコンポーネントに適用されます。デフォルトの Logto パープルカラーをブランドカラーに置き換えましょう。ダークモード用には別のブランドカラーも指定できます。 +サインイン体験全体で使用される主要カラーを定義します。プライマリーボタン、リンク、その他のコンポーネントに適用されます。デフォルトの Logto パープルを自社ブランドの色に置き換えられます。ダークモード用には別のブランドカラーも指定できます。 -**会社ロゴ** +### 会社ロゴ \{#company-logo} ロゴはサインインホームページ、サインアップホーム、ローディングページ、その他のインターフェースで表示されます。 @@ -20,45 +20,49 @@ sidebar_position: 1 - ロゴ欄を空白にすると、インターフェースにロゴは表示されません。 - ダークモード用のロゴもアップロードできます。 -**ファビコン** +### ファビコン \{#favicon} -ファビコンはウェブサイトを表す小さなアイコンで、ブラウザのタブやブックマーク、その他のブラウザインターフェースで表示されます。 +ファビコンはウェブサイトを表す小さなアイコンで、ブラウザのタブやブックマーク、その他のブラウザインターフェースに表示されます。 - 画像は 500KB 未満で、SVG、PNG、JPG、JPEG、ICO 形式である必要があります。見栄えを良くするために正方形の画像をアップロードすることを推奨します。 - ダークモード用のファビコンもアップロードできます。 -- また、各フロー(サインイン / サインアップ / パスワード忘れなど)でブラウザタイトルがカスタムタイトルの代わりに使用されます。 +- また、異なるフロー(サインイン / サインアップ / パスワード忘れなど)ではカスタムタイトルの代わりにブラウザタイトルが使用されます。 -**ダークモード** +### ダークモード \{#dark-mode} ダークモードを有効にすると、ユーザーのシステム設定に基づいてサインインページの外観が自動的に調整されます。 +### Logto ブランディングを非表示 \{#hide-logto-branding} + +デフォルトでは、標準のサインイン体験ページの下部に「Powered by Logto」が表示されます。「Logto ブランディングを非表示」オプションを有効にすると、Logto のマークを削除し、自社ブランドのみを強調したクリーンでプロフェッショナルなサインイン体験を実現できます。 + ## アプリ固有のブランディング \{#app-specific-branding} -複数アプリを展開している場合、アプリごとにサインイン体験を設定できます。アプリケーション詳細ページで設定可能です。コンソール > アプリケーション に移動してください。 +複数アプリを展開するビジネスでアプリごとのサインイン体験が必要な場合は、アプリケーション詳細ページで設定できます。コンソール > アプリケーション に移動してください。 -「アプリレベルのサインイン体験」をオンにすると、各アプリごとに特定のブランドロゴ、ファビコン、カラー、さらには [カスタム CSS](/customization/custom-css) まで設定できます。アプリレベルのブランディングが有効なアプリからサインインが開始された場合、そのアプリのブランディング設定に従ってサインイン体験がカスタマイズされます。そうでない場合は、デフォルトのオムニサインイン体験設定が適用されます。 +「アプリレベルのサインイン体験」をオンにすると、各アプリごとに特定のブランディングロゴ、ファビコン、カラー、さらには [カスタム CSS](/customization/custom-css) まで設定できます。アプリレベルのブランディングが有効なアプリからサインインが開始された場合、そのアプリのブランディング設定に従ってサインイン体験がカスタマイズされます。そうでない場合は、デフォルトのオムニサインイン体験設定が適用されます。 -アプリレベルのブランディングには、ライトモードとダークモードの両方の設定が利用可能です。ダークモードの設定は、[オムニサインイン体験](#omni-sign-in-experience) 設定でダークモードが有効な場合のみ反映されます。 +アプリレベルのブランディングには、ライトモードとダークモードの両方の設定が利用できます。ダークモード設定は、[オムニサインイン体験](#omni-sign-in-experience) でダークモードが有効な場合のみ反映されます。 ## 組織固有のブランディング \{#organization-specific-branding} クライアントの組織ロゴをサインイン体験で動的に表示するには、組織設定ページでロゴをアップロードできます。コンソール > 組織 に移動してください。 -「組織レベルのサインイン体験」をオンにすると、アプリレベルのブランディングと同様に、各組織ごとに特定のブランドロゴ、ファビコン、カラー、[カスタム CSS](/customization/custom-css) を設定できます。 +「組織レベルのサインイン体験」をオンにすると、アプリレベルのブランディングと同様に、各組織ごとに特定のブランディングロゴ、ファビコン、カラー、[カスタム CSS](/customization/custom-css) を設定できます。 -その後、サインインをトリガーする際に `organization_id` パラメーターで組織 ID を渡すことで、どの組織ロゴを表示するか Logto に伝えることができます。たとえば、組織 ID `123456` のロゴを表示したい場合: +その後、サインインをトリガーする際に `organization_id` パラメーターで組織 ID を渡すことで、どの組織ロゴを表示するか Logto に伝えることができます。例えば、組織 ID `123456` のロゴを表示したい場合: -- Logto SDK を利用している場合は、`signIn` メソッドの `extraParams` オブジェクトに `organization_id` パラメーターを渡せます。 -- OIDC クライアントを利用している場合は、[認可エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) へのリクエスト時に `organization_id` パラメーターを渡せます。 +- Logto SDK を使用している場合は、`signIn` メソッドの `extraParams` オブジェクトに `organization_id` パラメーターを渡せます。 +- OIDC クライアントを使用している場合は、[認可エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) へのリクエスト時に `organization_id` パラメーターを渡せます。 -組織レベルのブランディングにも、ライトモードとダークモードの両方の設定が利用可能です。ダークモードの設定は、[オムニサインイン体験](#omni-sign-in-experience) 設定でダークモードが有効な場合のみ反映されます。 +組織レベルのブランディングにも、ライトモードとダークモードの両方の設定が利用できます。ダークモード設定は、[オムニサインイン体験](#omni-sign-in-experience) でダークモードが有効な場合のみ反映されます。 :::note -アプリレベルのブランディングと組織レベルのブランディングの両方が有効な場合、組織レベルのブランディングが優先されます。優先順位は以下の通りです: +アプリレベルのブランディングと組織レベルのブランディングの両方が有効な場合は、組織レベルのブランディングが優先されます。優先順位は以下の通りです: 組織レベルのブランディング → アプリレベルのブランディング → オムニサインイン体験 ::: -[Logto ブラウザ SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out) を使って `signIn` メソッドで `organization_id` パラメーターを渡す例を紹介します: +[Logto ブラウザ SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out) で `signIn` メソッドに `organization_id` パラメーターを渡す例を示します: **index.ts** @@ -74,7 +78,7 @@ logtoClient.signIn({ :::note -`extraParams` 機能は順次すべての Logto SDK に展開中です。まだ SDK に表示されていない場合は、お問い合わせください。 +`extraParams` 機能は順次すべての Logto SDK に展開中です。まだ SDK で利用できない場合は、お問い合わせください。 ::: diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index c0ad423d1e0..363efb2e17b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -1,34 +1,34 @@ --- -description: アカウント API を使用してユーザーを管理する方法を学ぶ +description: Account API を使用してユーザーを管理する方法を学ぶ sidebar_position: 1 --- -# アカウント設定(Account API による) +# Account API によるアカウント設定 ## Logto Account API とは \{#what-is-logto-account-api} -Logto Account API は、エンドユーザーが Management API を経由せずに直接 API アクセスできる包括的な API セットです。主な特徴は以下の通りです: +Logto Account API は、エンドユーザーが Management API を経由せずに直接 API アクセスできる包括的な API 群です。主な特徴は以下の通りです: -- 直接アクセス:Account API により、エンドユーザーは Management API を介さずに自分のアカウントプロファイルへ直接アクセスし管理できます。 -- ユーザープロファイルとアイデンティティ管理:ユーザーはメール、電話、パスワードなどのアイデンティティ情報の更新やソーシャル連携の管理など、プロファイルやセキュリティ設定を完全に管理できます。MFA や SSO のサポートも近日追加予定です。 +- 直接アクセス:Account API により、エンドユーザーは Management API の中継なしで自身のアカウントプロファイルへ直接アクセス・管理できます。 +- ユーザープロファイルとアイデンティティ管理:ユーザーは自身のプロファイルやセキュリティ設定を完全に管理でき、メール・電話・パスワードなどのアイデンティティ情報の更新やソーシャル連携の管理が可能です。多要素認証 (MFA) やシングルサインオン (SSO) のサポートも近日公開予定です。 - グローバルアクセス制御:管理者はアクセス設定をグローバルに完全管理でき、各フィールドごとにカスタマイズ可能です。 - シームレスな認可 (Authorization):認可 (Authorization) がこれまで以上に簡単に!`client.getAccessToken()` を使って OP (Logto) 用の不透明トークン (Opaque token) を取得し、`Authorization` ヘッダーに `Bearer ` として付与するだけです。 Logto Account API を使えば、Logto と完全連携したプロフィールページのようなカスタムアカウント管理システムを構築できます。 -よくあるユースケース例: +よくあるユースケースは以下の通りです: - ユーザープロファイルの取得 - ユーザープロファイルの更新 - ユーザーパスワードの更新 -- メール、電話、ソーシャル連携などのユーザーアイデンティティの更新 +- メール・電話・ソーシャル連携などのユーザーアイデンティティの更新 - MFA 要素(認証要素)の管理 -利用可能な API について詳しくは [Logto Account API Reference](https://openapi.logto.io/group/endpoint-my-account) および [Logto Verification API Reference](https://openapi.logto.io/group/endpoint-verifications) をご覧ください。 +利用可能な API について詳しくは [Logto Account API リファレンス](https://openapi.logto.io/group/endpoint-my-account) および [Logto Verification API リファレンス](https://openapi.logto.io/group/endpoint-verifications) をご覧ください。 :::note -SSO アカウントの閲覧やアカウント削除機能は現在 Logto Management API で提供されています。実装の詳細は [Management API によるアカウント設定](/end-user-flows/account-settings/by-management-api) を参照してください。 +SSO アカウントの閲覧やアカウント削除機能は現在 Logto Management API で提供されています。実装の詳細は [Management API によるアカウント設定](/end-user-flows/account-settings/by-management-api) をご参照ください。 ::: @@ -36,26 +36,25 @@ SSO アカウントの閲覧やアカウント削除機能は現在 Logto Manage コンソール > サインイン & アカウント > アカウントセンター - -に移動します。 +
に移動します。 -Account API はデフォルトでオフになっているため、アクセス制御はロックされています。**Account API を有効化** を切り替えてオンにしてください。 +Account API はデフォルトで無効化されており、アクセス制御もロックされています。**Account API を有効化** を切り替えてオンにします。 -有効化後は、識別子、プロファイルデータ、サードパーティトークンアクセスごとにフィールド単位で権限を設定できます。各フィールドは `Off`、`ReadOnly`、`Edit` をサポートし、デフォルトは `Off` です。 +有効化後は、識別子・プロファイルデータ・サードパーティトークンアクセスごとにフィールド単位で権限を設定できます。各フィールドは `Off`、`ReadOnly`、`Edit` をサポートし、デフォルトは `Off` です。 -1. **セキュリティフィールド**: +1. **セキュリティフィールド**: - 対象フィールド:プライマリメール、プライマリ電話、ソーシャルアイデンティティ、パスワード、MFA。 - - エンドユーザーがこれらのフィールドを編集する前に、パスワード・メール・SMS で本人確認を行い、10分間有効な検証レコード ID を取得する必要があります。詳細は [検証レコード ID の取得](#get-a-verification-record-id) を参照してください。 + - エンドユーザーがこれらのフィールドを編集する前に、パスワード・メール・SMS で本人確認を行い、10 分間有効な認証記録 ID を取得する必要があります。詳細は [認証記録 ID の取得](#get-a-verification-record-id) を参照してください。 - MFA 用に WebAuthn パスキーを利用する場合は、フロントエンドアプリのドメインを **WebAuthn 関連オリジン** に追加し、アカウントセンターとサインイン体験でパスキーを共有できるようにします。詳細は [新しい WebAuthn パスキーの連携](#link-a-new-webauthn-passkey) を参照してください。 -2. **プロファイルフィールド**: +2. **プロファイルフィールド**: - 対象フィールド:ユーザー名、名前、アバター、[プロファイル](/user-management/user-data#profile)(その他標準プロファイル属性)、[カスタムデータ](/user-management/user-data#custom-data)。 - - これらは追加の本人確認なしで編集可能です。 -3. **シークレットボールト**:OIDC や OAuth のソーシャル・エンタープライズコネクター用に、Logto の [シークレットボールト](/secret-vault/federated-token-set) が認証後のサードパーティアクセストークン・リフレッシュトークンを安全に保存します。これにより、アプリはユーザーに再度サインインを求めることなく Google カレンダーイベントの同期など外部 API を呼び出せます。Account API を有効化すると自動的にトークン取得が可能になります。 + - これらは追加認証なしでエンドユーザーが編集可能です。 +3. **シークレットボールト**:OIDC や OAuth のソーシャル・エンタープライズコネクター用に、Logto の [シークレットボールト](/secret-vault/federated-token-set) が認証後のサードパーティアクセストークン・リフレッシュトークンを安全に保存します。これにより、アプリはユーザーに再度サインインを求めることなく外部 API(例:Google カレンダーイベントの同期など)を呼び出せます。Account API を有効化すると自動的にトークン取得が可能になります。 ## Account API へのアクセス方法 \{#how-to-access-account-api} :::note -アクセストークンに適切な権限があることを保証するため、Logto 設定で対応するスコープを正しく設定してください。 +アクセストークンに適切な権限が付与されていることを確認するため、Logto 設定で対応するスコープを正しく設定してください。 例えば、`POST /api/my-account/primary-email` API には `email` スコープ、`POST /api/my-account/primary-phone` API には `phone` スコープが必要です。 @@ -64,7 +63,7 @@ import { type LogtoConfig, UserScope } from '@logto/js'; const config: LogtoConfig = { // ...他のオプション - // ユースケースに合ったスコープを追加 + // ユースケースに合った適切なスコープを追加 scopes: [ UserScope.Email, // `{POST,DELETE} /api/my-account/primary-email` 用 UserScope.Phone, // `{POST,DELETE} /api/my-account/primary-phone` 用 @@ -80,9 +79,9 @@ const config: LogtoConfig = { ### アクセストークンの取得 \{#fetch-an-access-token} -アプリケーションで SDK をセットアップした後、`client.getAccessToken()` メソッドでアクセストークンを取得できます。このトークンは Account API へのアクセスに使える不透明トークン (Opaque token) です。 +アプリケーションで SDK をセットアップした後、`client.getAccessToken()` メソッドでアクセストークンを取得できます。このトークンは Account API へのアクセスに利用できる不透明トークン (Opaque token) です。 -公式 SDK を使用しない場合は、アクセストークングラントリクエスト `/oidc/token` の `resource` を空に設定してください。 +公式 SDK を利用しない場合は、アクセストークングラントリクエスト `/oidc/token` の `resource` を空に設定してください。 ### アクセストークンを使った Account API へのアクセス \{#access-account-api-using-access-token} @@ -121,9 +120,9 @@ curl https://[tenant-id].logto.app/api/my-account \ ### 基本的なアカウント情報の更新 \{#update-basic-account-information} -基本的なアカウント情報には、ユーザー名、名前、アバター、カスタムデータ、その他プロファイル情報が含まれます。 +基本的なアカウント情報には、ユーザー名・名前・アバター・カスタムデータ・その他プロファイル情報が含まれます。 -**ユーザー名、名前、アバター、customData** を更新するには、[`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) エンドポイントを利用します。 +**ユーザー名・名前・アバター・customData** を更新するには、[`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) エンドポイントを利用します。 ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account \ @@ -132,7 +131,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account \ --data-raw '{"username":"...","name":"...","avatar":"..."}' ``` -**familyName, givenName, middleName, nickname, profile(プロフィールページ URL), website, gender, birthdate, zoneinfo, locale, address** など他のプロファイル情報を更新するには、[`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) エンドポイントを利用します。 +**familyName, givenName, middleName, nickname, profile (プロフィールページ URL), website, gender, birthdate, zoneinfo, locale, address** など他のプロファイル情報を更新するには、[`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) エンドポイントを利用します。 ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ @@ -143,13 +142,13 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ ## 識別子やその他の機微情報の管理 \{#manage-identifiers-and-other-sensitive-information} -セキュリティ上の理由から、Account API で識別子やその他の機微情報を操作する場合は追加の認可 (Authorization) 層が必要です。 +セキュリティ上の理由から、Account API では識別子やその他の機微情報を扱う操作に追加の認可 (Authorization) 層が必要です。 -### 検証レコード ID の取得 \{#get-a-verification-record-id} +### 認証記録 ID の取得 \{#get-a-verification-record-id} -まず、10分間有効な **検証レコード ID** を取得する必要があります。これは機微情報の更新前にユーザーの本人確認を行うために使います。つまり、ユーザーがパスワード・メール認証コード・SMS 認証コードで本人確認に成功すると、10分間は識別子・認証情報・ソーシャル連携・MFA など認証関連データを更新できます。 +まず、10 分間有効な **認証記録 ID** を取得する必要があります。これは機微情報の更新前にユーザーの本人確認を行うために使用します。つまり、ユーザーがパスワード・メール認証コード・SMS 認証コードで本人確認に成功すると、10 分間は識別子・認証情報・ソーシャル連携・MFA など認証関連データを更新できます。 -検証レコード ID を取得するには、[ユーザーパスワードで認証](#verify-the-users-password) するか、[メールまたは電話に認証コードを送信](#verify-by-sending-a-verification-code-to-the-users-email-or-phone) してください。 +認証記録 ID を取得するには、[ユーザーパスワードで認証](#verify-the-users-password) または [メールや電話に認証コードを送信して認証](#verify-by-sending-a-verification-code-to-the-users-email-or-phone) を利用します。 #### ユーザーパスワードで認証 \{#verify-the-users-password} @@ -169,13 +168,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/password \ } ``` -#### メールまたは電話に認証コードを送信して認証 \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} +#### メールや電話に認証コードを送信して認証 \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} :::note -この方法を利用するには [メールコネクター](/connectors/email-connectors/) または [SMS コネクター](/connectors/sms-connectors/) を設定し、`UserPermissionValidation` テンプレートが設定されていることを確認してください。 +この方法を利用するには、[メールコネクター](/connectors/email-connectors/) または [SMS コネクター](/connectors/sms-connectors/) を設定し、`UserPermissionValidation` テンプレートが設定されていることを確認してください。 ::: -メールを例に、新しい認証コードをリクエストし検証レコード ID を取得します: +メールを例に、新しい認証コードをリクエストし認証記録 ID を取得します: ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ @@ -193,7 +192,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ } ``` -認証コードを受け取ったら、それを使って検証レコードの認証ステータスを更新できます。 +認証コードを受け取ったら、それを使って認証記録の認証ステータスを更新できます。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \ @@ -202,13 +201,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"123456"}' ``` -コード認証後、検証レコード ID を使ってユーザーの識別子を更新できます。 +コード認証後、認証記録 ID を使ってユーザーの識別子を更新できます。 -認証について詳しくは [Account API によるセキュリティ認証](/end-user-flows/security-verification) を参照してください。 +認証について詳しくは [Account API によるセキュリティ認証](/end-user-flows/security-verification) をご参照ください。 -### 検証レコード ID を付与してリクエスト送信 \{#send-request-with-verification-record-id} +### 認証記録 ID を付与してリクエスト送信 \{#send-request-with-verification-record-id} -ユーザーの識別子を更新するリクエストを送信する際は、リクエストヘッダーの `logto-verification-id` フィールドに検証レコード ID を含めてください。 +ユーザー識別子を更新するリクエストを送信する際は、リクエストヘッダーの `logto-verification-id` フィールドに認証記録 ID を含めてください。 ### ユーザーパスワードの更新 \{#update-users-password} @@ -222,10 +221,14 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +サインアップ時と同様、Account API で設定するパスワードも コンソール > セキュリティ > パスワードポリシー で設定した [パスワードポリシー](/security/password-policy) に準拠する必要があります。ポリシー違反時は Logto が詳細なバリデーション結果とエラーメッセージを返します。 +::: + ### 新しいメールの更新・連携 \{#update-or-link-new-email} :::note -この方法を利用するには [メールコネクター](/connectors/email-connectors/) を設定し、`BindNewIdentifier` テンプレートが設定されていることを確認してください。 +この方法を利用するには、[メールコネクター](/connectors/email-connectors/) を設定し、`BindNewIdentifier` テンプレートが設定されていることを確認してください。 ::: 新しいメールを更新・連携するには、まずそのメールの所有権を証明する必要があります。 @@ -239,7 +242,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ --data-raw '{"identifier":{"type":"email","value":"..."}}' ``` -レスポンスで `verificationId` を取得し、メールで認証コードを受け取ったら、それを使ってメールを認証します。 +レスポンスで `verificationId` が返され、メールで認証コードを受け取ります。それを使ってメールを認証します。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \ @@ -248,7 +251,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}' ``` -コード認証後、[`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) を呼び出してユーザーのメールを更新し、`verificationId` をリクエストボディの `newIdentifierVerificationRecordId` として設定します。 +コード認証後、[`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) を呼び出してユーザーのメールを更新し、`verificationId` をリクエストボディの `newIdentifierVerificationRecordId` に設定します。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -258,6 +261,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +サインアップ時と同様、Account API で連携されるメールも コンソール > セキュリティ > ブロックリスト で設定した [ブロックリスト](/security/blocklist) 検証に合格する必要があります。ポリシー違反時は Logto がリクエストを拒否し、詳細なエラーを返します。 +::: + ### ユーザーのメール削除 \{#remove-the-users-email} ユーザーのメールを削除するには、[`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) エンドポイントを利用します。 @@ -271,10 +278,10 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### 電話番号の管理 \{#manage-phone} :::note -この方法を利用するには [SMS コネクター](/connectors/sms-connectors/) を設定し、`BindNewIdentifier` テンプレートが設定されていることを確認してください。 +この方法を利用するには、[SMS コネクター](/connectors/sms-connectors/) を設定し、`BindNewIdentifier` テンプレートが設定されていることを確認してください。 ::: -メールの更新と同様に、[`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) エンドポイントで新しい電話番号の更新・連携、[`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) エンドポイントでユーザーの電話番号削除が可能です。 +メール更新と同様に、[`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) エンドポイントで新しい電話番号の更新・連携、[`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) エンドポイントでユーザーの電話番号削除が可能です。 ### 新しいソーシャル連携の追加 \{#link-a-new-social-connection} @@ -287,13 +294,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ --data-raw '{"connectorId":"...","redirectUri":"...","state":"..."}' ``` -- `connectorId`:[ソーシャルコネクター](/connectors/social-connectors/) の ID -- `redirectUri`:ユーザーがアプリを認可した後のリダイレクト先。ここでコールバックを受け取る Web ページをホストしてください。 -- `state`:認可後に返されるランダムな文字列(CSRF 対策) +- `connectorId`: [ソーシャルコネクター](/connectors/social-connectors/) の ID +- `redirectUri`: ユーザーがアプリを認可した後のリダイレクト先 URL。この URL でコールバックを受け取る必要があります。 +- `state`: 認可後に返されるランダムな文字列で、CSRF 攻撃防止用です。 -レスポンスで `verificationRecordId` を取得し、後で使用します。 +レスポンスで `verificationRecordId` が返されるので、後で利用できるよう保持します。 -ユーザーがアプリを認可すると、`redirectUri` に `state` パラメータ付きでコールバックされます。その後、[`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) エンドポイントでソーシャル連携を認証します。 +ユーザーがアプリを認可すると、`redirectUri` で `state` パラメータ付きのコールバックを受け取ります。その後、[`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) エンドポイントでソーシャル連携を認証します。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ @@ -302,7 +309,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -`connectorData` はソーシャルコネクターから返されたデータで、コールバックページで `redirectUri` のクエリパラメータをパースし、JSON 形式で `connectorData` フィールドに渡します。 +`connectorData` は、ユーザーがアプリを認可した後にソーシャルコネクターから返されるデータです。コールバックページで `redirectUri` のクエリパラメータをパースし、`connectorData` フィールドの値として JSON でラップしてください。 最後に、[`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) エンドポイントでソーシャル連携を追加します。 @@ -327,27 +334,27 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connecto ### 新しい WebAuthn パスキーの連携 \{#link-a-new-webauthn-passkey} :::note -[まず MFA と WebAuthn](/end-user-flows/mfa) を有効にしてください。 +まず [MFA と WebAuthn の有効化](/end-user-flows/mfa) を忘れずに行ってください。 ::: :::note -この方法を利用するには [アカウントセンター設定](#how-to-enable-account-api) で `mfa` フィールドを有効にしてください。 +この方法を利用するには、[アカウントセンター設定](#how-to-enable-account-api) で `mfa` フィールドを有効化する必要があります。 ::: **ステップ 1: フロントエンドアプリのオリジンを関連オリジンに追加** -WebAuthn パスキーは **Relying Party ID (RP ID)** と呼ばれる特定のホスト名に紐づきます。RP ID のオリジンでホストされているアプリのみ、そのパスキーで登録や認証が可能です。 +WebAuthn パスキーは **Relying Party ID (RP ID)** と呼ばれる特定のホスト名に紐づきます。RP ID のオリジンでホストされているアプリケーションのみが、そのパスキーで登録・認証できます。 -フロントエンドアプリが Logto の認証ページとは異なるドメインから Account API を呼び出す場合、**関連オリジン** を設定してクロスオリジンのパスキー操作を許可する必要があります。 +フロントエンドアプリが Logto の認証ページとは異なるドメインから Account API を呼び出す場合、クロスオリジンでパスキー操作を許可するため **関連オリジン** の設定が必要です。 **Logto が RP ID を決定する方法:** -- **デフォルト設定**:Logto のデフォルトドメイン `https://[tenant-id].logto.app` の場合、RP ID は `[tenant-id].logto.app` -- **カスタムドメイン**:[カスタムドメイン](/logto-cloud/custom-domain) 例:`https://auth.example.com` の場合、RP ID は `auth.example.com` +- **デフォルト設定**:Logto のデフォルトドメイン `https://[tenant-id].logto.app` のみを利用する場合、RP ID は `[tenant-id].logto.app` +- **カスタムドメイン**: [カスタムドメイン](/logto-cloud/custom-domain) 例:`https://auth.example.com` を設定した場合、RP ID は `auth.example.com` **関連オリジンの設定方法:** -[`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) エンドポイントでフロントエンドアプリのオリジンを追加します。例:アカウントセンターが `https://account.example.com` で動作している場合 +[`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) エンドポイントでフロントエンドアプリのオリジンを追加します。例:アカウントセンターが `https://account.example.com` で動作している場合: ```bash curl -X PATCH https://[tenant-id].logto.app/api/account-center \ @@ -356,7 +363,17 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -関連オリジンについて詳しくは [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) ドキュメントを参照してください。 +:::note + +WebAuthn では関連オリジンとして最大 5 つのユニークな eTLD+1 ラベルをサポートします。eTLD+1(有効なトップレベルドメイン+1 ラベル)は登録可能なドメイン部分です。例: + +- `https://example.com`、`https://app.example.com`、`https://auth.example.com` は **1** ラベル(`example.com`)としてカウント +- `https://shopping.com`、`https://shopping.co.uk`、`https://shopping.co.jp` も **1** ラベル(`shopping`)としてカウント +- `https://example.com` と `https://another.com` は **2** ラベル + +5 ドメインを超える関連オリジンが必要な場合は、[Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) ドキュメントを参照してください。 + +::: **ステップ 2: 新規登録オプションのリクエスト** @@ -387,7 +404,7 @@ import { startRegistration } from '@simplewebauthn/browser'; // ... const response = await startRegistration({ - optionsJSON: registrationOptions, // サーバーから返されたデータ + optionsJSON: registrationOptions, // ステップ 1 でサーバーから返されたデータ }); // レスポンスを後で利用できるよう保存 ``` @@ -396,7 +413,7 @@ const response = await startRegistration({ [`POST /api/verifications/web-authn/registration/verify`](https://openapi.logto.io/operation/operation-verifywebauthnregistration) エンドポイントでパスキー登録を認証します。 -このステップでは、認証器が生成した暗号署名を検証し、パスキーが正当に作成され転送中に改ざんされていないことを確認します。 +このステップでは、認証器が生成した暗号署名を検証し、パスキーが正当に作成され送信中に改ざんされていないことを確認します。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration/verify \ @@ -405,8 +422,8 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registrat --data-raw '{"payload":"...","verificationRecordId":"..."}' ``` -- `payload`:ステップ 2 のローカルブラウザからのレスポンス -- `verificationRecordId`:ステップ 1 でサーバーから返された検証レコード ID +- `payload`: ステップ 2 のローカルブラウザからのレスポンス +- `verificationRecordId`: ステップ 1 でサーバーから返された認証記録 ID **ステップ 5: パスキーの連携** @@ -420,13 +437,13 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"WebAuthn","newIdentifierVerificationRecordId":"..."}' ``` -- `verification_record_id`:既存要素で認証済みの有効な検証レコード ID。詳細は [検証レコード ID の取得](#get-a-verification-record-id) を参照してください。 -- `type`:MFA 要素のタイプ。現在は `WebAuthn` のみサポート。 -- `newIdentifierVerificationRecordId`:ステップ 1 でサーバーから返された検証レコード ID +- `verification_record_id`: 既存要素の認証で付与された有効な認証記録 ID。詳細は [認証記録 ID の取得](#get-a-verification-record-id) を参照。 +- `type`: MFA 要素のタイプ。現在は `WebAuthn` のみサポート。 +- `newIdentifierVerificationRecordId`: ステップ 1 でサーバーから返された認証記録 ID ### 既存 WebAuthn パスキーの管理 \{#manage-existing-webauthn-passkeys} -既存の WebAuthn パスキーを管理するには、[`GET /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-getmfaverifications) エンドポイントで現在のパスキーや他の MFA 要素を取得できます。 +既存の WebAuthn パスキー管理には、[`GET /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-getmfaverifications) エンドポイントで現在のパスキーや他の MFA 認証要素を取得します。 ```bash curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -448,10 +465,10 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \ ] ``` -- `id`:認証要素の ID -- `type`:認証要素のタイプ。WebAuthn パスキーの場合は `WebAuthn` -- `name`:パスキー名(任意) -- `agent`:パスキーのユーザーエージェント +- `id`: 認証要素の ID +- `type`: 認証要素のタイプ。WebAuthn パスキーの場合は `WebAuthn` +- `name`: パスキー名(任意) +- `agent`: パスキーのユーザーエージェント パスキー名の更新は [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname) エンドポイントで行います: @@ -463,7 +480,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{ve --data-raw '{"name":"..."}' ``` -パスキーの削除は [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) エンドポイントで行います: +パスキー削除は [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) エンドポイントで行います: ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId} \ @@ -474,11 +491,11 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{v ### 新しい TOTP の連携 \{#link-a-new-totp} :::note -[まず MFA と TOTP](/end-user-flows/mfa) を有効にしてください。 +まず [MFA と TOTP の有効化](/end-user-flows/mfa) を忘れずに行ってください。 ::: :::note -この方法を利用するには [アカウントセンター設定](#how-to-enable-account-api) で `mfa` フィールドを有効にしてください。 +この方法を利用するには、[アカウントセンター設定](#how-to-enable-account-api) で `mfa` フィールドを有効化する必要があります。 ::: **ステップ 1: TOTP シークレットの生成** @@ -499,11 +516,11 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp } ``` -**ステップ 2: TOTP シークレットをユーザーに表示** +**ステップ 2: ユーザーに TOTP シークレットを表示** -シークレットを使って QR コードを生成するか、直接ユーザーに表示します。ユーザーは Google Authenticator、Microsoft Authenticator、Authy などの認証アプリに追加してください。 +シークレットを使って QR コードを生成するか、直接ユーザーに表示します。ユーザーはこれを Google Authenticator、Microsoft Authenticator、Authy などの認証アプリに追加します。 -QR コードの URI 形式: +QR コードの URI 形式は: ``` otpauth://totp/[Issuer]:[Account]?secret=[Secret]&issuer=[Issuer] @@ -517,7 +534,7 @@ otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp **ステップ 3: TOTP 要素の連携** -ユーザーが認証アプリにシークレットを追加したら、それを検証しアカウントに連携します。[`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) エンドポイントを利用します。 +ユーザーが認証アプリにシークレットを追加した後、それを認証してアカウントに連携します。[`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) エンドポイントを利用します。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -527,22 +544,22 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"Totp","secret":"..."}' ``` -- `verification_record_id`:既存要素で認証済みの有効な検証レコード ID。詳細は [検証レコード ID の取得](#get-a-verification-record-id) を参照してください。 -- `type`:`Totp` 固定 -- `secret`:ステップ 1 で生成した TOTP シークレット +- `verification_record_id`: 既存要素の認証で付与された有効な認証記録 ID。詳細は [認証記録 ID の取得](#get-a-verification-record-id) を参照。 +- `type`: `Totp` を指定 +- `secret`: ステップ 1 で生成した TOTP シークレット :::note -ユーザーは TOTP 要素を 1 つしか持てません。すでに TOTP 要素がある場合、追加しようとすると 422 エラーになります。 +ユーザーは TOTP 要素を 1 つだけ持つことができます。すでに TOTP 要素がある場合、追加しようとすると 422 エラーになります。 ::: ### バックアップコードの管理 \{#manage-backup-codes} :::note -[まず MFA とバックアップコード](/end-user-flows/mfa) を有効にしてください。 +まず [MFA とバックアップコードの有効化](/end-user-flows/mfa) を忘れずに行ってください。 ::: :::note -この方法を利用するには [アカウントセンター設定](#how-to-enable-account-api) で `mfa` フィールドを有効にしてください。 +この方法を利用するには、[アカウントセンター設定](#how-to-enable-account-api) で `mfa` フィールドを有効化する必要があります。 ::: **ステップ 1: 新しいバックアップコードの生成** @@ -565,18 +582,18 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/back **ステップ 2: バックアップコードをユーザーに表示** -バックアップコードをアカウントに連携する前に、ユーザーに表示し、以下を案内してください: +バックアップコードをユーザーアカウントに連携する前に、必ずユーザーに表示し、以下を案内してください: - すぐにダウンロードまたは書き留めること - 安全な場所に保管すること - 各コードは 1 回しか使えないこと -- プライマリ MFA 手段を失った場合の最後の手段であること +- これらのコードは主要な MFA 手段を失った場合の最後の手段であること -コピーしやすい形式で表示し、ダウンロード(テキストファイルや PDF など)も提供すると良いでしょう。 +コピーしやすい形式で表示し、ダウンロード(テキストファイルや PDF など)も検討してください。 **ステップ 3: バックアップコードの連携** -[`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) エンドポイントでバックアップコードをアカウントに連携します。 +[`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) エンドポイントでバックアップコードをユーザーアカウントに連携します。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -586,15 +603,15 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"BackupCode","codes":["...","...","..."]}' ``` -- `verification_record_id`:既存要素で認証済みの有効な検証レコード ID。詳細は [検証レコード ID の取得](#get-a-verification-record-id) を参照してください。 -- `type`:`BackupCode` 固定 -- `codes`:前ステップで生成したバックアップコード配列 +- `verification_record_id`: 既存要素の認証で付与された有効な認証記録 ID。詳細は [認証記録 ID の取得](#get-a-verification-record-id) を参照。 +- `type`: `BackupCode` を指定 +- `codes`: 前ステップで生成したバックアップコード配列 :::note - ユーザーは 1 セットのバックアップコードしか持てません。すべてのコードを使い切った場合は新たに生成・連携が必要です。 -- バックアップコードだけを MFA 要素にすることはできません。必ず他の MFA 要素(WebAuthn や TOTP など)が有効である必要があります。 -- 各バックアップコードは 1 回しか使えません。 +- バックアップコードだけを MFA 要素とすることはできません。必ず他の MFA 要素(WebAuthn や TOTP など)が有効である必要があります。 +- 各バックアップコードは 1 回のみ利用可能です。 ::: @@ -624,5 +641,5 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes } ``` -- `code`:バックアップコード -- `usedAt`:そのコードが使用された日時。未使用の場合は `null` +- `code`: バックアップコード +- `usedAt`: コードが使用された日時。未使用の場合は `null` diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index fc5665862ff..6184087b17b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -8,33 +8,38 @@ sidebar_position: 2 - `first_screen`: ユーザーが最初に見る画面を指定します。 - `identifier`: サインインまたはサインアップフォームで受け付ける識別子タイプを指定します。 -- `login_hint`: ユーザーのメールアドレスまたはユーザー名で識別子フィールドを自動入力します。(これは OIDC 標準パラメーターです) +- `login_hint`: ユーザーのメールアドレスやユーザー名で識別子フィールドを自動入力します。(これは OIDC 標準パラメーターです) ## first_screen \{#first_screen} -`first_screen` パラメーターは、ユーザーが Logto のサインインページにリダイレクトされたときに最初に表示される画面を決定する主要なパラメーターです。デフォルトでは、ユニバーサルサインインフォームが表示されます。このパラメーターを使用して、アプリケーションの要件に応じて最初の画面をカスタマイズできます。サポートされている値は以下の通りです: +`first_screen` パラメーターは、ユーザーが Logto のサインインページにリダイレクトされた際に最初に表示される画面を決定する主要なパラメーターです。デフォルトではユニバーサルサインインフォームが表示されます。このパラメーターを使って、アプリケーションの要件に応じて最初の画面をカスタマイズできます。サポートされている値は以下の通りです: -- `sign_in`: サインインフォームを表示します。(デフォルト) -- `register`: サインアップフォームを表示します。 -- `reset_password`: パスワードリセットフォームを表示します。 -- `single_sign_on`: エンタープライズ SSO サインインフォームを表示します。(有効な SSO プロバイダーを判定するためにメールアドレスが求められます) -- `identifier:sign-in`: 識別子タイプを指定したサインインフォームを表示します。識別子タイプは `identifier` パラメーターで指定できます。複数の識別子サインイン方法が有効な場合に便利です。 -- `identifier:register`: 識別子タイプを指定したサインアップフォームを表示します。識別子タイプは `identifier` パラメーターで指定できます。複数の識別子サインアップ方法が有効な場合に便利です。 +- `sign_in`(デフォルト):サインインフォームを表示します。 +- `register`:サインアップフォームを表示します。 +- `reset_password`:パスワードリセットフォームを表示します。 +- `single_sign_on`:エンタープライズ SSO サインインフォームを表示します。(有効な SSO プロバイダーを判定するためにメールアドレスが求められます) +- `identifier:sign-in`:識別子タイプを指定したサインインフォームを表示します。識別子タイプは `identifier` パラメーターで指定できます(任意)。複数の識別子サインイン方法を有効にしている場合に便利です。 +- `identifier:register`:識別子タイプを指定したサインアップフォームを表示します。識別子タイプは `identifier` パラメーターで指定できます(任意)。複数の識別子サインアップ方法を有効にしている場合に便利です。 ファーストスクリーンパラメーター -例えば、ユーザーを直接エンタープライズ SSO サインインフォームに遷移させる場合: +例えば、ユーザーを直接エンタープライズ SSO サインインフォームに誘導する場合: ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +最初の画面は コンソール > サインイン体験 +で設定した内容に従います。必要な認証 (Authentication) 方法を有効化し、ブランディング・利用規約・プライバシーポリシー・国際化 (i18n) を設定してください。なお、ロゴがデフォルトで表示されるのは `sign-in` および `register` ページのみです。 +::: + ## identifier \{#identifier} -`identifier` パラメーターは、サインインまたはサインアップフォームで受け付ける識別子タイプを指定するために使用します。このパラメーターは、`first_screen` パラメーターが `identifier:sign-in`、`identifier:register`、または `reset_password` に設定されている場合のみ有効です。サポートされている値は `username`、`email`、`phone` です。複数の識別子タイプを許可する場合は、空白で区切って指定します。 +`identifier` パラメーターは、サインインまたはサインアップフォームで受け付ける識別子タイプを指定するために使用します。このパラメーターは `first_screen` パラメーターが `identifier:sign-in`、`identifier:register`、または `reset_password` に設定されている場合のみ有効です。サポートされている値は `username`、`email`、`phone` です。複数の識別子タイプを許可する場合は空白で区切って指定します。 -例えば、ユーザーをメールアドレスまたは電話番号のサインアップページに直接遷移させる場合: +例えば、ユーザーを直接メールアドレスまたは電話番号のサインアップページに誘導する場合: ```sh curl --location \ @@ -70,7 +75,7 @@ logtoClient.signIn({ ``` :::note -`first_screen`、`identifier`、`login_hint` パラメーターへの対応は、順次すべての Logto SDK に追加されています。SDK にこれらが見当たらない場合は、Issue を立てるかお問い合わせください。 +`first_screen`、`identifier`、`login_hint` パラメーターへの対応は順次すべての Logto SDK に追加中です。SDK にこれらが見当たらない場合は、Issue を立てるかお問い合わせください。 [Logto OSS](/logto-oss) ユーザーの場合、これらのパラメーターはバージョン 1.15.0 以降でサポートされています。古いバージョンをお使いの場合は、[最新版へアップグレード](/logto-oss/upgrading-oss-version) してください。 ::: diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index c352c73425e..84137f1290a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -8,9 +8,10 @@ Logto は、標準の OIDC 認証 (Authentication) パラメーター `ui_locale ## 機能概要 \{#what-it-does} -- Logto ホスト型サインイン体験の UI 言語を実行時に決定します。Logto は、`ui_locales` 内の最初のサポートされている言語タグをテナントの言語ライブラリから選択します。 +- 実行時に Logto ホスト型サインイン体験の UI 言語を決定します。Logto は、`ui_locales` 内の最初のサポートされている言語タグをテナントの言語ライブラリから選択します。 - インタラクションによってトリガーされるメッセージ(例:認証コードメール)のメールローカライズに影響します。詳細は [メールテンプレートのローカライズ](/connectors/email-connectors/email-templates#email-template-localization) を参照してください。 - 元の値をメールテンプレートの変数 `uiLocales` として公開し、必要に応じてメールの件名や内容に含めることができます。 +- サインイン体験での電話番号のデフォルト国コードを設定します。例えば、`ui_locales=fr` の場合、電話番号入力欄はフランス(+33)がデフォルトになります。特定のユーザーグループや地域向けにプログラムでデフォルト国コードを制御したい場合に便利です。 ## パラメーター形式 \{#parameter-format} @@ -31,7 +32,7 @@ Logto は、標準の OIDC 認証 (Authentication) パラメーター `ui_locale ## SDK での利用方法 \{#sdk-usage} -Logto SDK を利用している場合、サインイン呼び出しの `extraParams` 経由で `ui_locales` を渡すことで、認可リクエストに転送されます: +Logto SDK を利用している場合、サインイン呼び出しの `extraParams` 経由で `ui_locales` を渡すことで、認可 (Authorization) リクエストに転送できます: ```ts await logtoClient.signIn({ @@ -44,7 +45,7 @@ await logtoClient.signIn({ ## 使用例 \{#examples} -- `ui_locales=fr-CA fr en` → 言語ライブラリに `fr-CA` が存在すれば、サインイン UI はフランス語(カナダ)で表示されます。なければ `fr`、次に `en` へフォールバックします。 +- `ui_locales=fr-CA fr en` → 言語ライブラリに `fr-CA` が存在すればサインイン UI はフランス語(カナダ)で表示され、なければ `fr`、さらに `en` へフォールバックします。 - `ui_locales=ja` だが日本語が有効でない場合 → `Accept-Language` またはテナントのデフォルトにフォールバックします。 ## 関連情報 \{#related} diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index 28c5e1c7320..e8559f69ba0 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -2,105 +2,106 @@ sidebar_position: 2 --- -# メール / 電話 / ユーザー名でのサインイン +# メール / 電話番号 / ユーザー名でのサインイン ## 識別子サインインフローの設定 \{#configure-the-identifier-sign-in-flow} -前述のように、さまざまな識別子タイプは [サインアップフロー](/end-user-flows/sign-up-and-sign-in/sign-up) または [Logto での直接アカウント作成](/user-management/manage-users#add-users) を通じてユーザーから収集される場合があります。さらに、ユーザーは製品を探索し利用する際に追加情報を入力し完了することがあります。これらの識別子は、Logto のシステムでユーザーを一意に識別し、Logto と統合されたアプリケーションに認証 (Authentication) されサインインできるようにするために使用されます。 +前述の通り、さまざまな識別子タイプは [サインアップフロー](/end-user-flows/sign-up-and-sign-in/sign-up) や [Logto での直接アカウント作成](/user-management/manage-users#add-users) を通じてユーザーから収集できます。さらに、ユーザーは製品を利用する中で追加情報を入力・完了することもあります。これらの識別子は Logto のシステム内でユーザーを一意に識別し、Logto と連携したアプリケーションへの認証 (Authentication) およびサインインを可能にします。 -Logto がホストする事前構築されたサインインページを使用するか、[独自のカスタムサインイン UI を構築する](/customization#custom-ui) 計画を立てるかにかかわらず、エンドユーザーのための利用可能なサインイン方法と検証設定を構成する必要があります。 +Logto がホストする事前構築済みサインインページを利用する場合でも、[独自のカスタムサインイン UI を構築する](/customization#custom-ui)場合でも、エンドユーザー向けの利用可能なサインイン方法と認証設定を構成する必要があります。 -## 識別子と認証 (Authentication) 設定のセットアップ \{#set-up-the-identifier-and-authentication-settings} +## 識別子および認証 (Authentication) 設定のセットアップ \{#set-up-the-identifier-and-authentication-settings} -### 1. サポートされるサインイン識別子の設定 \{#1-set-the-supported-sign-in-identifiers} +### 1. サポートするサインイン識別子の設定 \{#1-set-the-supported-sign-in-identifiers} -ドロップダウンリストから複数のサポートされる識別子をエンドユーザーのための有効なサインイン方法として追加できます。利用可能なオプションは次のとおりです: +ドロップダウンリストから複数の識別子を追加し、エンドユーザー向けの有効なサインイン方法として設定できます。利用可能なオプションは以下の通りです: - **ユーザー名** - **メールアドレス** - **電話番号** -識別子の順序を変更すると、サインインページに表示される順序が変わります。最初の識別子がユーザーの主要なサインイン方法になります。 +識別子の順序を変更すると、サインインページでの表示順も変わります。最初の識別子がユーザーの主要なサインイン方法となります。 -### 2. 認証 (Authentication) 設定の設定 \{#2-set-the-authentication-settings} +### 2. 認証 (Authentication) 設定の構成 \{#2-set-the-authentication-settings} -各サインイン識別子について、ユーザーのアイデンティティを確認するために少なくとも 1 つの有効な検証要素を設定する必要があります。選択できる要素は次の 2 つです: +各サインイン識別子ごとに、ユーザーのアイデンティティを確認するための有効な認証要素を少なくとも 1 つ設定する必要があります。選択できる要素は 2 つあります: -- **パスワード**:すべてのタイプのサインイン識別子で利用可能です。有効にすると、ユーザーはサインインプロセスを完了するためにパスワードを提供する必要があります。 -- **検証コード**:**メールアドレス**および**電話番号**識別子のみで利用可能です。有効にすると、ユーザーはメールまたは電話番号に送信された検証コードを入力してサインインプロセスを完了する必要があります。 +- **パスワード**:すべての識別子タイプで利用可能です。有効化すると、ユーザーはサインイン時にパスワードの入力が必須となります。 +- **認証コード**:**メールアドレス** および **電話番号** 識別子でのみ利用可能です。有効化すると、ユーザーはメールまたは電話番号に送信された認証コードを入力してサインインを完了します。 -両方の要素が有効になっている場合、ユーザーはどちらの方法でもサインインプロセスを完了できます。要素の順序を変更して、サインインページに表示される順序を変更することもできます。最初の要素がユーザーの主要な検証方法として使用され、2 番目の要素が代替リンクとして表示されます。 +両方の要素が有効な場合、ユーザーはどちらかの方法でサインインを完了できます。また、要素の順序を変更することで、サインインページでの表示順も変わります。最初の要素が主要な認証方法として使用され、2 番目の要素は代替リンクとして表示されます。 ## 識別子サインインフローのユーザー体験 \{#identifier-sign-in-flow-user-experience} -サインイン体験は、選択された識別子と利用可能な認証 (Authentication) 要素に基づいて適応します。 +サインイン体験は、選択された識別子と利用可能な認証要素に応じて変化します。 -- **複数の識別子のためのスマート入力:** - 複数の識別子サインイン方法が有効になっている場合、Logto の組み込みサインインページは、ユーザーが入力した識別子のタイプを自動的に検出し、対応する検証オプションを表示します。たとえば、**メールアドレス**と**電話番号**の両方が有効になっている場合、サインインページはユーザーが入力した識別子のタイプを自動的に検出し、対応する検証オプションを表示します。連続して数字が入力された場合は地域コード付きの電話番号形式に、"@" 記号が使用された場合はメール形式に切り替わります。 -- **有効な検証要素:** - - **パスワードのみ:** 識別子とパスワードの両方のフィールドが最初の画面に表示されます。 - - **検証コードのみ:** 識別子フィールドが最初の画面に表示され、その後に検証コードフィールドが 2 番目の画面に表示されます。 - - **パスワードと検証コード:** 識別子フィールドが最初の画面に入力され、その後、検証順に基づいてパスワードまたは検証コードを入力するステップが 2 番目の画面に表示されます。ユーザーが 2 つの検証方法を切り替えることができるようにスイッチリンクが提供されます。 +- **複数識別子のスマート入力:** + 複数の識別子サインイン方法が有効な場合、Logto の組み込みサインインページはユーザーが入力した識別子のタイプを自動的に判別し、対応する認証オプションを表示します。たとえば、**メールアドレス** と **電話番号** の両方が有効な場合、サインインページはユーザーが入力した識別子のタイプを自動判別し、対応する認証オプションを表示します。連続して数字が入力された場合は地域コード付きの電話番号形式に、"@" 記号が使われた場合はメール形式に自動で切り替わります。 + - 電話番号の国コードはユーザーのブラウザロケールをデフォルトとしますが、ユーザーが手動で切り替えることも可能です。特定のデフォルト国コードを設定するには [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) パラメーターを利用できます。詳細は [ローカライズ言語](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience) を参照してください。 +- **有効な認証要素:** + - **パスワードのみ:** 識別子とパスワードの両方の入力欄が最初の画面に表示されます。 + - **認証コードのみ:** 最初の画面に識別子欄が表示され、その後 2 番目の画面で認証コード欄が表示されます。 + - **パスワードと認証コード:** 最初の画面で識別子を入力し、2 番目の画面で認証順に応じてパスワードまたは認証コードを入力します。2 つの認証方法を切り替えるためのリンクも表示されます。 ### 例 \{#examples}
-### 例 1: パスワード検証付きメールアドレス \{#example-1-email-address-with-password-verification} +### 例 1: メールアドレス + パスワード認証 \{#example-1-email-address-with-password-verification} -**メールアドレス**をサインイン識別子として追加し、検証のために**パスワード**要素を有効にします。 +サインイン識別子として **メールアドレス** を追加し、認証要素として **パスワード** を有効化します。 -パスワード検証付きメールアドレス +Email address with password verification
-### 例 2: パスワード(主要)および検証コード(代替)検証が有効なメール / 電話 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} +### 例 2: メール / 電話番号 + パスワード(主要)と認証コード(代替)認証 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} -**メールアドレス**と**電話番号**の両方をサインイン識別子として追加します。 -両方の識別子に対して**パスワード**と**検証コード**要素を有効にします。 +**メールアドレス** と **電話番号** の両方をサインイン識別子として追加します。 +両方の識別子に対して **パスワード** と **認証コード** の要素を有効化します。 パスワードと検証コード検証が有効なメール / 電話
-## サインイン時に追加のユーザープロファイルを収集する \{#collect-additional-user-profile-on-sign-in} +## サインイン時に追加ユーザープロフィールを収集 \{#collect-additional-user-profile-on-sign-in} -Logto のサインインフローでは、サインアップ識別子設定が更新された場合、プロファイルの充足プロセスがトリガーされることがあります。これにより、既存のユーザーを含むすべてのユーザーが新たに必要な識別子を提供することが保証されます。 +Logto のサインインフローでは、サインアップ識別子設定が更新された場合、プロフィール補完プロセスがトリガーされることがあります。これにより、既存ユーザーを含むすべてのユーザーが新たに必須となった識別子を提供することが保証されます。 -開発者が新しい識別子(例えばメールアドレス)を追加すると、それはすべてのユーザーにとって必須になります。既存の識別子(例えばユーザー名)でサインインするユーザーは、プロファイルに欠けている場合、新しい識別子を提供し検証するよう求められます。このステップを完了した後にのみ、アプリケーションにアクセスできるようになり、更新された要件へのスムーズで一貫した移行が保証されます。 +開発者が新しい識別子(例:メールアドレス)を追加すると、すべてのユーザーに必須となります。既存の識別子(例:ユーザー名)でサインインしたユーザーは、プロフィールにその識別子が未登録の場合、新しい識別子の入力と認証を求められます。このステップを完了して初めてアプリケーションにアクセスできるため、要件変更へのスムーズかつ一貫した移行が実現します。 -プロセスの詳細: +プロセスの流れ: -1. **ユーザー名**が以前にサインアップ識別子として設定され、**パスワードを作成する**設定が自動的に有効になっていました。 -2. **メールアドレス**が後にサインアップ識別子として設定されます。**メールアドレス**識別子は、有効なサインインオプションとして自動的に追加されます。 -3. 既存のユーザーがユーザー名とパスワードでサインインします。 -4. ユーザーは、最初のサインインステップの後にメールアドレスを提供し検証するよう求められます。 +1. **ユーザー名** が以前サインアップ識別子として設定され、**パスワード作成** 設定が自動有効化されていました。 +2. 後から **メールアドレス** がサインアップ識別子として設定されます。**メールアドレス** 識別子は自動的に有効なサインインオプションとして追加されます。 +3. 既存ユーザーがユーザー名とパスワードでサインインします。 +4. 初回サインイン後、ユーザーはメールアドレスの入力と認証を求められます。 ```mermaid flowchart TD - A[サインインページを訪問] --> B[ユーザー名とパスワードを入力] - B -.-> C{{メールアドレスが必要で欠けていますか?}} + A[サインインページにアクセス] --> B[ユーザー名とパスワードを入力] + B -.-> C{{メールアドレスが必須かつ未登録か?}} C -->|はい| D[メールアドレスを入力] - D --> E[検証コードを入力] + D --> E[認証コードを入力] E --> F[サインイン成功] C --> |いいえ| F ``` -同じプロセスは、**パスワードを作成する**サインアップ設定にも適用されます。サインアップフローで新たに**パスワードを作成する**設定が有効になった場合、選択したすべてのサインイン識別子に対して**パスワード**要素が自動的に有効になります。パスワードを持たないすべての既存のユーザーは、サインインプロセス中にパスワードを作成するよう求められます。 +同じプロセスは **パスワード作成** サインアップ設定にも適用されます。サインアップフローで新たに **パスワード作成** 設定が有効化された場合、**パスワード** 要素は選択したすべてのサインイン識別子で自動的に有効化されます。パスワード未登録の既存ユーザーは、サインイン時にパスワード作成を求められます。 :::note -注意: カスタムサインインフローについては、[Bring your UI](/customization/bring-your-ui/) 機能を参照してください。 +注:カスタムサインインフローについては、[Bring your UI](/customization/bring-your-ui/) 機能を参照してください。 ::: ## よくある質問 \{#faqs} @@ -112,12 +113,12 @@ flowchart TD -Logto は現在、サインインおよびサインアップのためのヘッドレス API をサポートしていません。ただし、[Bring your UI](/customization/bring-your-ui/) 機能を使用して、カスタムサインインフォームを Logto にアップロードできます。また、アプリケーションから収集したユーザー識別子でサインインフォームを事前入力したり、サードパーティのソーシャルまたはエンタープライズシングルサインオン (SSO) プロバイダーで直接サインインしたりするために使用できる複数のサインインパラメーターをサポートしています。詳細は [認証 (Authentication) パラメーター](/end-user-flows/authentication-parameters/) を参照してください。 +Logto は現在、サインインおよびサインアップ用のヘッドレス API をサポートしていません。ただし、[Bring your UI](/customization/bring-your-ui/) 機能を利用して、独自のサインインフォームを Logto にアップロードできます。また、アプリケーションで収集したユーザー識別子でサインインフォームを事前入力したり、サードパーティのソーシャルやエンタープライズ SSO プロバイダーで直接サインインしたりするための複数のサインインパラメーターもサポートしています。詳細は [認証 (Authentication) パラメーター](/end-user-flows/authentication-parameters/) をご覧ください。 ## 関連リソース \{#related-resources} -メールサインアップとサインイン体験 +メールサインアップ・サインイン体験 -ユーザー名サインアップとサインイン体験 +ユーザー名サインアップ・サインイン体験 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index 943f23aa83b..d12ab22ae53 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -2,40 +2,50 @@ sidebar_position: 1 --- -# メール / 電話番号 / ユーザー名によるサインアップ +# メール / 電話番号 / ユーザー名でのサインアップ -ユーザー登録は、ユーザーがアプリケーションと関わる最初のステップです。Logto は、ユーザー名とパスワード、メールアドレスまたは電話番号の認証、[ソーシャルサインアップ](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[エンタープライズシングルサインオン (SSO)](/end-user-flows/enterprise-sso) など、さまざまなサインアップ方法をサポートしています。アプリケーションの要件に最適なサインアップ方法を設定できます。 +ユーザー登録は、アプリケーションとユーザーの最初の接点です。Logto は、ユーザー名とパスワード、メールアドレスや電話番号の認証、[ソーシャルサインアップ](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[エンタープライズシングルサインオン (SSO)](/end-user-flows/enterprise-sso) など、さまざまなサインアップ方法をサポートしています。アプリケーションの要件に最適なサインアップ方法を設定できます。 コンソール > サインイン体験 > サインアップとサインイン -から、識別子サインアップフローの設定を開始してください。 +から識別子サインアップフローの設定を開始できます。 サインアップ設定 ## サインアップ識別子の設定 \{#set-up-the-sign-up-identifier} -Logto で新しいユーザーアカウントを作成するには、ユーザーが Logto のシステム内で一意に識別される **識別子** を少なくとも 1 つ提供する必要があります。最初のステップとして、サインアップ時にユーザーが提供する必要がある識別子を選択します。利用可能なオプションは次の通りです: +Logto で新しいユーザーアカウントを作成するには、ユーザーが Logto システム内で一意に識別される **識別子** を少なくとも 1 つ提供する必要があります。最初のステップとして、サインアップ時にユーザーが入力する必要がある識別子を選択します。利用可能なオプションは次の通りです: -- **ユーザー名**:[ユーザー名](/user-management/user-data#username) を使ってアプリケーションにサインインできる一意の名前。 -- **メールアドレス**:[メールアドレス](/user-management/user-data#primary_email) を使ってアプリケーションにサインインできる有効なメールアドレス。 -- **電話番号**:[電話番号](/user-management/user-data#primary_phone) を使ってアプリケーションにサインインできる有効な電話番号。 +- **ユーザー名**:[ユーザー名](/user-management/user-data#username) を使ってアプリケーションにサインインできる一意の値。 +- **メールアドレス**:[メールアドレス](/user-management/user-data#primary_email) を使ってアプリケーションにサインインできる有効な値。 +- **電話番号**:[電話番号](/user-management/user-data#primary_phone) を使ってアプリケーションにサインインできる有効な値。 - **メールアドレスまたは電話番号**:有効なメールアドレスまたは電話番号のいずれかでサインアップを許可。 サインアップ時に収集されるすべての識別子は、同じテナント内のユーザー間で一意でなければなりません。これらは [ユーザープロファイル](/user-management/user-data#user-profile) に保存され、Logto と連携したアプリケーションへのサインインに利用できます。 -識別子が選択されていない場合は、[ソーシャル](/end-user-flows/sign-up-and-sign-in/social-sign-in) のみ、または [エンタープライズ SSO](/end-user-flows/enterprise-sso) のみのサインアップ方法が適用されます。 +識別子を選択しない場合は、[ソーシャル](/end-user-flows/sign-up-and-sign-in/social-sign-in) のみ、または [エンタープライズ SSO](/end-user-flows/enterprise-sso) のみのサインアップ方法が適用されます。 -サインアップ識別子の順序を調整して、サインアップ時に最初に入力してほしい項目を優先できます。この順序はサインアッププロセスに反映され、最初の識別子が初回登録画面に表示され、残りは後続のステップで収集されます。 +サインアップ識別子の順序を調整して、サインアップ時に最初に入力してほしい項目を優先できます。この順序はサインアッププロセスに反映され、最初の識別子が登録画面の最初に表示され、残りは後続のステップで収集されます。 + +:::tip +サインアップ時に特定の種類のメールアドレス(使い捨てメール、プラス記号(+)付きのサブアドレス、特定のメールアドレスやドメイン全体など)をブロックしたい場合は、セキュリティセクションの **ブロックリスト** 機能を利用してください。詳細は [ブロックリスト](/security/blocklist) をご覧ください。 +::: + +:::tip +電話番号の **国コード** は、ユーザーのブラウザロケールをデフォルト値として使用します。たとえば、ユーザーのブラウザ言語が `fr` の場合、国コードはフランス(+33)になります。 + +サインイン体験の言語を [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 認証パラメーターで設定することもでき、これによりデフォルトの国コードも決まります。 +::: ## サインアップ認証設定の構成 \{#set-up-the-sign-up-verification-settings} -ユーザーのサインアップおよび今後のサインインプロセスのセキュリティを確保するため、サインアップ時に収集する識別子の認証設定も構成する必要があります。利用可能な設定は次の通りです: +ユーザーのサインアップおよび今後のサインインプロセスのセキュリティを確保するため、サインアップ時に収集する識別子に対して認証設定も構成する必要があります。利用可能な設定は次の通りです: -- **パスワードの作成:** サインアップ時にユーザーにパスワードの作成を求めます。これは、サインイン体験設定で構成されたパスワードポリシーに準拠する必要があります。このパスワードとユーザーの識別子が、アプリケーションへのサインイン資格情報となります。**ユーザー名** をサインアップ識別子として設定した場合、この要件は自動的に有効になります。**ユーザー名** はパスワードと組み合わせてのみユーザーの本人確認が可能なためです。[パスワードポリシー](/security/password-policy) はセキュリティ要件に合わせてカスタマイズできます。 -- **サインアップ時に認証:** サインアップ時にメールアドレスまたは電話番号の認証を必須にします。現在、Logto では認証済みのメールアドレスおよび電話番号のみを識別子として受け付けています。この設定は、**メールアドレス** または **電話番号** をサインアップ識別子として使用する場合、自動的に有効になります。ユーザーは、サインアッププロセス中にメールまたは電話番号に送信された認証コードを入力して所有権を確認する必要があります。 +- **パスワードの作成:** サインアップ時にユーザーにパスワードの作成を求めます。これはサインイン体験設定で構成したパスワードポリシーに準拠する必要があります。このパスワードとユーザーの識別子が、アプリケーションへのサインイン資格情報となります。**ユーザー名** をサインアップ識別子に設定した場合、この要件は自動的に有効になります。**ユーザー名** はパスワードと組み合わせてのみユーザーの本人確認ができるためです。[パスワードポリシー](/security/password-policy) はセキュリティ要件に合わせてカスタマイズできます。 +- **サインアップ時の認証:** サインアップ時にメールアドレスまたは電話番号の認証を必須にします。現在、Logto では認証済みのメールアドレスと電話番号のみを識別子として受け付けています。この設定は **メールアドレス** または **電話番号** をサインアップ識別子にした場合、自動的に有効になります。ユーザーはサインアップ時に、メールまたは電話番号に送信された認証コードを入力して所有権を確認する必要があります。 -| 識別子 | パスワード作成 | サインアップ時に認証 | +| 識別子 | パスワード作成 | サインアップ時の認証 | | -------------------- | -------------- | -------------------- | | ユーザー名 | 任意 | 該当なし | | メールアドレス | 任意 | 必須 | @@ -47,31 +57,28 @@ Logto で新しいユーザーアカウントを作成するには、ユーザ
-### タイプ 1: ユーザー名+パスワード作成 \{#type-1-username-with-password-creation} +### タイプ 1: ユーザー名とパスワード作成 \{#type-1-username-with-password-creation} **ユーザー名** をサインアップ識別子として選択します。パスワード作成は自動的に有効になります。 -ユーザー名とパスワードによるサインアップ +ユーザー名とパスワードでのサインアップ
-### タイプ 2: メールアドレスまたは電話番号+認証フロー \{#type-2-email-address-or-phone-number-with-verification-flow} +### タイプ 2: メールアドレスまたは電話番号での認証フロー \{#type-2-email-address-or-phone-number-with-verification-flow} -**メールアドレスまたは電話番号** をサインアップ識別子として選択します。**サインアップ時に認証** は強制的に有効になります。 +**メールアドレスまたは電話番号** をサインアップ識別子として選択します。**サインアップ時の認証** は強制的に有効になります。 メールまたは電話番号による認証付きサインアップ
@@ -79,15 +86,15 @@ Logto で新しいユーザーアカウントを作成するには、ユーザ
-### タイプ 3: メールアドレス+認証+パスワード作成 \{#type-3-email-address-with-verification-and-password-creation} +### タイプ 3: メールアドレスでの認証とパスワード作成 \{#type-3-email-address-with-verification-and-password-creation} -**メールアドレス** をサインアップ識別子として選択します。**サインアップ時に認証** は強制的に有効になります。**パスワード作成** を有効にして、サインアップ時にパスワード作成を必須にします。(電話番号サインアップフローも同様です) +**メールアドレス** をサインアップ識別子として選択します。**サインアップ時の認証** は強制的に有効になります。**パスワードの作成** を有効にして、サインアップ時にユーザーにパスワード作成を必須にします。(電話番号サインアップフローも同様です) メール認証+パスワード作成付きサインアップ
@@ -95,50 +102,50 @@ Logto で新しいユーザーアカウントを作成するには、ユーザ
-### タイプ 4: メールアドレス+認証+ユーザー名+パスワード作成 \{#type-4-email-address-with-verification-username-and-password-creation} +### タイプ 4: メールアドレス認証、ユーザー名とパスワード作成 \{#type-4-email-address-with-verification-username-and-password-creation} -**メールアドレス** と **ユーザー名** をサインアップ識別子として選択します。**サインアップ時に認証** は強制的に有効になります。**パスワード作成** を有効にして、サインアップ時にパスワード作成を必須にします。 +**メールアドレス** と **ユーザー名** をサインアップ識別子として選択します。**サインアップ時の認証** は強制的に有効になります。**パスワードの作成** を有効にして、サインアップ時にユーザーにパスワード作成を必須にします。 メール+ユーザー名+認証+パスワード作成付きサインアップ
-## ソーシャルまたはエンタープライズ SSO でサインアップ \{#sign-up-with-social-or-enterprise-sso} +## ソーシャルまたはエンタープライズ SSO でのサインアップ \{#sign-up-with-social-or-enterprise-sso} -これらの従来の識別子サインアップ方法に加え、Logto はソーシャルおよびエンタープライズ SSO アイデンティティプロバイダーによるパスワードレスサインアップもサポートしており、オンボーディングプロセスをよりシームレスかつユーザーフレンドリーにします。 +これらの従来型識別子サインアップ方法に加え、Logto はソーシャルおよびエンタープライズ SSO アイデンティティプロバイダーによるパスワードレスサインアップもサポートしており、オンボーディングプロセスをよりシームレスかつユーザーフレンドリーにします。 -Logto で [ソーシャルコネクター](/connectors/social-connectors) または [エンタープライズ SSO コネクター](/connectors/enterprise-connectors) を設定・有効化すると、ユーザーはコネクターが提供する既存のソーシャルまたはエンタープライズアイデンティティを使って簡単にサインアップできます。ソーシャルおよびエンタープライズ SSO サインアップ方法では、パスワード作成やメールアドレス・電話番号の認証などの追加ステップを省略できます。Logto は、認証済みのソーシャルまたはエンタープライズアイデンティティを通じてユーザー情報を自動的に同期し、ユーザープロファイルに保存します。 +Logto で [ソーシャルコネクター](/connectors/social-connectors) または [エンタープライズ SSO コネクター](/connectors/enterprise-connectors) を設定・有効化すると、ユーザーはコネクターが提供する既存のソーシャルまたはエンタープライズアイデンティティで簡単にサインアップできます。ソーシャルおよびエンタープライズ SSO サインアップ方法では、パスワード作成やメールアドレス・電話番号の認証などの追加ステップを省略できます。Logto は認証済みのソーシャルまたはエンタープライズアイデンティティを通じてユーザー情報を自動的に同期し、ユーザープロファイルに保存します。 -ソーシャルおよびエンタープライズ SSO コネクターによるサインアップフローの詳細は、[ソーシャルサインイン](/end-user-flows/sign-up-and-sign-in/social-sign-in/) および [エンタープライズ SSO](/end-user-flows/enterprise-sso/) セクションを参照してください。 +ソーシャルおよびエンタープライズ SSO コネクターによるサインアップフローの詳細は、[ソーシャルサインイン](/end-user-flows/sign-up-and-sign-in/social-sign-in/) および [エンタープライズ SSO](/end-user-flows/enterprise-sso/) セクションをご覧ください。 :::note -注:カスタムサインアップフローについては、[Bring your UI](/customization/bring-your-ui/) 機能を参照してください。 +カスタムサインアップフローについては、[Bring your UI](/customization/bring-your-ui/) 機能を参照してください。 ::: -## サインアップ時に追加ユーザー情報を収集 \{#collect-additional-user-info-on-sign-up} +## サインアップ時に追加ユーザー情報を収集する \{#collect-additional-user-info-on-sign-up} -サインアップ時に追加のユーザープロファイル情報(例:氏名、生年月日、会社名など)を収集するには、2 つの柔軟な方法があります: +サインアップ時に追加のユーザープロファイル情報(例:氏名、生年月日、会社名など)を収集するには、次の 2 つの柔軟な方法があります: -**方法 1: ユーザープロファイルの収集** +**方法 1: ユーザープロファイル収集** -Logto の組み込み「あなたについて教えてください」ステップをサインアップフローに直接追加します。ユーザーは、登録が完了する前にすべての必須項目を入力する必要があります。この方法は、コード不要で簡単に導入できます。 +Logto の組み込み「あなたについて教えてください」ステップをサインアップフローに直接追加します。ユーザーは登録完了前にすべての必須項目を入力する必要があります。この方法はコード不要で簡単に導入できます。 - コンソール > サインイン体験 > ユーザープロファイルの収集 + コンソール > サインイン体験 > ユーザープロファイル収集 から、あらかじめ用意された基本データ項目を選択したり、柔軟なバリデーション付きでカスタム項目を作成できます。詳細は -[ユーザープロファイルの収集](/end-user-flows/collect-user-profile) をご覧ください。 +[ユーザープロファイル収集](/end-user-flows/collect-user-profile) をご覧ください。 **方法 2: 独自ホストのオンボーディングフロー** -サインアップ完了後に独自のカスタムオンボーディングフローへリダイレクトし、完全にカスタマイズ可能なデータ収集を行います。この方法では、ユーザー体験を完全にコントロールでき、複雑なマルチステップのオンボーディングプロセスも実現できます。 +サインアップ完了後に独自のカスタムオンボーディングフローへリダイレクトし、完全にカスタマイズ可能なデータ収集を行います。この方法ではユーザー体験を完全にコントロールでき、複雑な多段階オンボーディングも実現できます。 -[Account API](/end-user-flows/account-settings/by-account-api) を利用して、ユーザープロファイルデータをプログラムで管理できます。 +[Account API](/end-user-flows/account-settings/by-account-api) を利用してユーザープロファイルデータをプログラムで管理できます。 ## よくある質問 \{#faqs} @@ -160,7 +167,7 @@ Logto の組み込み「あなたについて教えてください」ステッ -Logto は現在、サインイン・サインアップ用のヘッドレス API をサポートしていません。[Bring your UI](/customization/bring-your-ui/) 機能を利用して独自のサインアップフォームを Logto にアップロードするか、サインインパラメーターを使って Web サイトからユーザー情報を Logto に渡すことができます。ユーザー識別子の連携については [認証リクエストパラメーター](/end-user-flows/authentication-parameters/) をご覧ください。 +Logto は現在、サインイン・サインアップ用のヘッドレス API をサポートしていません。[Bring your UI](/customization/bring-your-ui/) 機能を使って独自のサインアップフォームを Logto にアップロードするか、サインインパラメーターを利用して Web サイトから Logto へユーザー情報を連携できます。ユーザー識別子の連携については [認証パラメーター](/end-user-flows/authentication-parameters/) をご覧ください。 @@ -178,12 +185,12 @@ Logto は現在、サインイン・サインアップ用のヘッドレス API
-### サインアップ時のメール認証をスキップ \{#skip-email-verification-on-sign-up} +### サインアップ時のメール認証をスキップしたい \{#skip-email-verification-on-sign-up} -現在、Logto では認証済みのメールアドレスおよび電話番号のみを識別子としてサポートしています。認証プロセスは、ユーザー識別子のセキュリティと所有権を確保するために必須です。 -未認証のメールアドレスや電話番号のサポートは [ロードマップ](https://feedback.logto.io/roadmap) にあります。今後のアップデートにご期待ください! +現在、Logto では認証済みのメールアドレスおよび電話番号のみを識別子としてサポートしています。認証プロセスはユーザー識別子のセキュリティと所有権を確保するために必須です。 +未認証のメールアドレスや電話番号のサポートは [ロードマップ](https://feedback.logto.io/roadmap) にあります。今後のアップデートをお待ちください!
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index d85a9806e37..1b47eb93f02 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,5 +1,5 @@ --- -description: リダイレクト URI、エンドポイント、リフレッシュ トークン、バックチャネル ログアウトなど、OIDC 認証 (Authentication) 統合のための主要なアプリケーションパラメーターを参照してください。 +description: OIDC 認証 (Authentication) 統合のための主要なアプリケーションパラメーター(リダイレクト URI、エンドポイント、リフレッシュ トークン、バックチャネルログアウトなど)を参照できます。 sidebar_position: 6 --- @@ -7,12 +7,12 @@ sidebar_position: 6 ## はじめに \{#introduction} -Logto における _アプリケーション_ とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代わりにアクションを実行する権限を与えられた特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API に対するリクエストの発信元を識別し、これらのアプリケーションにアクセスするユーザーの認証 (Authentication) および認可 (Authorization) プロセスを管理するために使用されます。 +Logto における _アプリケーション_ とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代理での操作を行う権限が付与された特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API へのリクエスト元を識別し、ユーザーがそれらのアプリケーションへアクセスする際の認証 (Authentication) および認可 (Authorization) プロセスを管理するために使用されます。 -Logto のサインイン体験におけるアプリケーションの使用により、ユーザーは一元的な場所から簡単に認可されたアプリケーションにアクセスし、管理することができ、一貫性のある安全な認証 (Authentication) プロセスが提供されます。これにより、ユーザー体験が簡素化され、組織の代わりに機密情報にアクセスしたりアクションを実行したりするのが認可された個人のみであることが保証されます。 +Logto のサインイン体験におけるアプリケーションの利用により、ユーザーは一元的な場所から認可されたアプリケーションへ簡単にアクセス・管理でき、統一された安全な認証 (Authentication) プロセスが提供されます。これにより、ユーザー体験が効率化され、認可された人物のみが機密情報へアクセスしたり、組織の代理で操作を行ったりできるようになります。 -アプリケーションはまた、Logto の監査ログでユーザーの活動を追跡し、潜在的なセキュリティ脅威や侵害を特定するためにも使用されます。特定のアクションを特定のアプリケーションに関連付けることにより、Logto はデータがどのようにアクセスされ使用されているかについての詳細な洞察を提供し、組織がセキュリティおよびコンプライアンス要件をより適切に管理できるようにします。 -アプリケーションを Logto と統合したい場合は、[Logto の統合](/integrate-logto) を参照してください。 +また、Logto の監査ログでもアプリケーションが使用され、ユーザーの活動を追跡し、潜在的なセキュリティ脅威や侵害を特定します。特定の操作を特定のアプリケーションと関連付けることで、Logto はデータのアクセスや利用状況について詳細なインサイトを提供し、組織がセキュリティやコンプライアンス要件をより適切に管理できるようにします。 +アプリケーションを Logto と統合したい場合は、 [Logto との統合](/integrate-logto) をご覧ください。 ## プロパティ \{#properties} @@ -22,130 +22,134 @@ _アプリケーション ID_ は、Logto 内でアプリケーションを識 ### アプリケーションタイプ \{#application-types} -_アプリケーション_ は次のいずれかのアプリケーションタイプであることができます: +_アプリケーション_ は、次のいずれかのアプリケーションタイプとなります: -- **ネイティブアプリ** はネイティブ環境で実行されるアプリです。例:iOS アプリ、Android アプリ。 -- **シングルページアプリ** は、ウェブブラウザで実行され、サーバーからの新しいデータでページを更新するアプリです。例:React DOM アプリ、Vue アプリ。 -- **従来のウェブアプリ** は、ウェブサーバーによってページをレンダリングおよび更新するアプリです。例:JSP、PHP。 -- **マシン間通信 (M2M) アプリ** は、ユーザーの操作なしにサービス間の直接通信のためにマシン環境で実行されるアプリケーションです。 +- **ネイティブアプリ**:ネイティブ環境で動作するアプリ。例:iOS アプリ、Android アプリ。 +- **シングルページアプリ (SPA)**:Web ブラウザ上で動作し、サーバーから新しいデータを取得してページ全体を再読み込みせずに更新するアプリ。例:React DOM アプリ、Vue アプリ。 +- **従来型 Web アプリ**:Web サーバーのみでページをレンダリング・更新するアプリ。例:JSP、PHP。 +- **マシン間通信 (M2M) アプリ**:ユーザー操作なしでサービス間通信を直接行うマシン環境で動作するアプリケーション。 ### アプリケーションシークレット \{#application-secret} -_アプリケーションシークレット_ は、認証 (Authentication) システム内でアプリケーションを認証するために使用されるキーであり、特にプライベートクライアント(従来のウェブアプリおよび M2M アプリ)に対するプライベートセキュリティバリアとして機能します。 +_アプリケーションシークレット_ は、認証 (Authentication) システム内でアプリケーションを認証 (Authentication) するためのキーであり、特にプライベートクライアント(従来型 Web および M2M アプリ)におけるプライベートなセキュリティバリアとして機能します。 + +:::tip +シングルページアプリ (SPA) およびネイティブアプリにはアプリシークレットは提供されません。SPA およびネイティブアプリは「パブリッククライアント」であり、シークレットを保持できません(ブラウザコードやアプリバンドルは検査可能なため)。アプリシークレットの代わりに、Logto は PKCE、厳格なリダイレクト URI / CORS 検証、短命なアクセス トークン、リフレッシュ トークンのローテーションで保護します。 +::: ### アプリケーション名 \{#application-name} -_アプリケーション名_ は人間が読みやすいアプリケーションの名前で、管理コンソールに表示されます。 +_アプリケーション名_ は、アプリケーションの人間が読める名称であり、管理コンソールに表示されます。 -_アプリケーション名_ は、Logto でアプリケーションを管理する上で重要な要素であり、管理者がプラットフォーム内の個々のアプリケーションの活動を簡単に識別し追跡できるようにします。 +_アプリケーション名_ は Logto でアプリケーションを管理する上で重要な要素であり、管理者がプラットフォーム内で個々のアプリケーションの活動を簡単に識別・追跡できるようにします。 :::note -_アプリケーション名_ は、管理コンソールにアクセスできるすべてのユーザーに表示されるため、慎重に選択する必要があります。アプリケーションの目的と機能を正確に反映し、理解しやすく認識しやすいものであるべきです。 +_アプリケーション名_ は管理コンソールにアクセスできるすべてのユーザーに表示されるため、慎重に選択することが重要です。アプリケーションの目的や機能を正確に反映し、分かりやすく認識しやすい名称にしてください。 ::: ### 説明 \{#description} -アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的、機能、およびその他の関連する詳細情報を管理者に提供することを目的としています。 +アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的や機能、その他関連情報など、管理者に追加情報を提供することを意図しています。 ### リダイレクト URI \{#redirect-uris} -_リダイレクト URI_ は、アプリケーションのために事前に設定された有効なリダイレクト URI のリストです。ユーザーが Logto にサインインし、アプリケーションにアクセスしようとすると、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。 +_リダイレクト URI_ は、アプリケーションに事前設定された有効なリダイレクト URI のリストです。ユーザーが Logto にサインインしアプリケーションへアクセスしようとすると、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。 -許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto に送信される認可 (Authorization) リクエストに含まれるリダイレクト URI を検証するために使用されます。認可 (Authorization) リクエストで指定されたリダイレクト URI がアプリケーション設定の許可された URI のいずれかと一致する場合、ユーザーは認証 (Authentication) に成功した後、その URI にリダイレクトされます。リダイレクト URI が許可リストにない場合、ユーザーはリダイレクトされず、認証 (Authentication) プロセスは失敗します。 +許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto へ送信される認可 (Authorization) リクエストに含まれるリダイレクト URI を検証するために使用されます。認可 (Authorization) リクエストで指定されたリダイレクト URI がアプリケーション設定の許可リストのいずれかと一致する場合、認証 (Authentication) 成功後にその URI へリダイレクトされます。リダイレクト URI が許可リストにない場合、ユーザーはリダイレクトされず、認証 (Authentication) プロセスは失敗します。 :::note -すべての有効なリダイレクト URI が Logto のアプリケーションの許可リストに追加されていることを確認することが重要です。これにより、ユーザーが認証 (Authentication) 後にアプリケーションに正常にアクセスできるようになります。 +すべての有効なリダイレクト URI を Logto のアプリケーションの許可リストに追加しておくことが重要です。これにより、認証 (Authentication) 後にユーザーが正常にアプリケーションへアクセスできるようになります。 ::: -[Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) を参照して、詳細情報を確認できます。 +詳細は [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) をご覧ください。 - OIDC における認可コードフローでのリダイレクト URI の理解 + OIDC の認可コードフローにおけるリダイレクト URI の理解 -### サインアウト後のリダイレクト URI \{#post-sign-out-redirect-uris} +### サインアウト後リダイレクト URI \{#post-sign-out-redirect-uris} -_サインアウト後のリダイレクト URI_ は、Logto からサインアウトした後にユーザーをリダイレクトするためにアプリケーションに事前に設定された有効な URI のリストです。 +_サインアウト後リダイレクト URI_ は、Logto からサインアウトした後にユーザーをリダイレクトするためにアプリケーションに事前設定された有効な URI のリストです。 -ログアウトのための許可された _サインアウト後のリダイレクト URI_ の使用は、OIDC の RP-Initiated (Relying Party Initiated) Logout 仕様の一部です。この仕様は、ユーザーのログアウトリクエストを開始するための標準化された方法を提供し、ユーザーがサインアウトした後に事前に設定されたエンドポイントにリダイレクトすることを含みます。 +Allowed _Post Sign-out Redirect URIs_ の利用は、OIDC の RP-Initiated (Relying Party Initiated) Logout 仕様の一部です。この仕様は、アプリケーションがユーザーのログアウトリクエストを開始し、サインアウト後にユーザーを事前設定されたエンドポイントへリダイレクトする標準化された方法を提供します。 -ユーザーが Logto からサインアウトすると、そのセッションは終了し、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。これにより、ユーザーがサインアウトした後に認可された有効なエンドポイントにのみ誘導され、未知または未確認のエンドポイントにユーザーをリダイレクトすることに関連する不正アクセスやセキュリティリスクを防ぐことができます。 +ユーザーが Logto からサインアウトすると、そのセッションは終了し、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。これにより、サインアウト後にユーザーが認可された有効なエンドポイントのみに誘導され、未知または未検証のエンドポイントへのリダイレクトによる不正アクセスやセキュリティリスクを防ぎます。 -[RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) を参照して、詳細情報を確認できます。 +詳細は [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) をご覧ください。 ### CORS 許可オリジン \{#cors-allowed-origins} -_CORS (クロスオリジンリソース共有) 許可されたオリジン_ は、アプリケーションが Logto サービスにリクエストを行うことができる許可されたオリジンのリストです。許可リストに含まれていないオリジンは、Logto サービスにリクエストを行うことができません。 +_CORS (クロスオリジンリソースシェアリング) 許可オリジン_ は、アプリケーションが Logto サービスへリクエストを送信できる許可されたオリジンのリストです。許可リストに含まれていないオリジンからは Logto サービスへのリクエストはできません。 -CORS 許可されたオリジンリストは、未承認のドメインからの Logto サービスへのアクセスを制限し、クロスサイトリクエストフォージェリ (CSRF) 攻撃を防ぐのに役立ちます。Logto でアプリケーションの許可されたオリジンを指定することにより、サービスは承認されたドメインのみがサービスにリクエストを行うことができるようにします。 +CORS 許可オリジンリストは、未認可ドメインからの Logto サービスへのアクセスを制限し、クロスサイトリクエストフォージェリ (CSRF) 攻撃を防ぐのに役立ちます。Logto でアプリケーションごとに許可オリジンを指定することで、認可されたドメインのみがサービスへリクエストできるようにします。 :::note -許可されたオリジンリストには、アプリケーションが提供されるオリジンを含める必要があります。これにより、アプリケーションからのリクエストが許可され、未承認のオリジンからのリクエストがブロックされます。 +許可オリジンリストには、アプリケーションが提供されるオリジンを含めてください。これにより、アプリケーションからのリクエストは許可され、未認可オリジンからのリクエストはブロックされます。 ::: -### OpenID プロバイダー設定エンドポイント \{#openid-provider-configuration-endpoint} +### OpenID プロバイダー構成エンドポイント \{#openid-provider-configuration-endpoint} -[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) のエンドポイント。 +[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) のエンドポイントです。 ### 認可 (Authorization) エンドポイント \{#authorization-endpoint} -_認可 (Authorization) エンドポイント_ は OIDC 用語であり、ユーザーの認証 (Authentication) プロセスを開始するために使用される必須のエンドポイントです。Logto プラットフォームに登録された保護されたリソースまたはアプリケーションにユーザーがアクセスしようとすると、_認可 (Authorization) エンドポイント_ にリダイレクトされ、アイデンティティを認証 (Authentication) し、要求されたリソースへのアクセスを認可 (Authorization) します。 +_認可 (Authorization) エンドポイント_ は OIDC 用語であり、ユーザーの認証 (Authentication) プロセスを開始するために使用される必須エンドポイントです。ユーザーが Logto プラットフォームに登録された保護されたリソースやアプリケーションへアクセスしようとすると、_認可 (Authorization) エンドポイント_ へリダイレクトされ、アイデンティティの認証 (Authentication) およびリソースへのアクセス権限の取得が行われます。 -[Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) を参照して、詳細情報を確認できます。 +詳細は [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) をご覧ください。 ### トークンエンドポイント \{#token-endpoint} -_トークンエンドポイント_ は OIDC 用語であり、OIDC クライアントが OIDC プロバイダーからアクセス トークン、ID トークン、またはリフレッシュ トークンを取得するために使用される Web API エンドポイントです。 +_トークンエンドポイント_ は OIDC 用語であり、OIDC クライアントが OIDC プロバイダーからアクセス トークン、ID トークン、リフレッシュ トークンを取得するための Web API エンドポイントです。 -OIDC クライアントがアクセス トークンまたは ID トークンを取得する必要がある場合、通常は認可コードまたはリフレッシュ トークンである認可 (Authorization) グラントを使用してトークンエンドポイントにリクエストを送信します。トークンエンドポイントは認可 (Authorization) グラントを検証し、グラントが有効であればクライアントにアクセス トークンまたは ID トークンを発行します。 +OIDC クライアントがアクセス トークンや ID トークンを取得する必要がある場合、認可 (Authorization) グラント(通常は認可コードまたはリフレッシュ トークン)とともにトークンエンドポイントへリクエストを送信します。トークンエンドポイントは認可 (Authorization) グラントを検証し、有効であればクライアントにアクセス トークンや ID トークンを発行します。 -[Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) を参照して、詳細情報を確認できます。 +詳細は [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) をご覧ください。 -### ユーザー情報エンドポイント \{#userinfo-endpoint} +### Userinfo エンドポイント \{#userinfo-endpoint} -OpenID Connect の [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)。 +OpenID Connect の [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) です。 -### 常にリフレッシュ トークンを発行する \{#always-issue-refresh-token} +### 常にリフレッシュ トークンを発行 \{#always-issue-refresh-token} -_利用可能性: 従来のウェブ、SPA_ +_利用可能:従来型 Web、SPA_ -有効にすると、Logto は `prompt=consent` が認証 (Authentication) リクエストに提示されているかどうか、または `offline_access` がスコープに提示されているかどうかに関係なく、常にリフレッシュ トークンを発行します。 +有効にすると、認証 (Authentication) リクエストで `prompt=consent` やスコープに `offline_access` が指定されていなくても、Logto は常にリフレッシュ トークンを発行します。 -ただし、これは OpenID Connect と互換性がなく、問題を引き起こす可能性があるため、必要でない限り(通常、リフレッシュ トークンを必要とする一部のサードパーティ OAuth 統合に役立ちます)、この方法は推奨されません。 +ただし、この運用は必要な場合(通常はリフレッシュ トークンを必要とする一部のサードパーティ OAuth 統合)を除き推奨されません。OpenID Connect との互換性がなく、問題が発生する可能性があります。 -### リフレッシュ トークンをローテーションする \{#rotate-refresh-token} +### リフレッシュ トークンのローテーション \{#rotate-refresh-token} -_デフォルト: `true`_ +_デフォルト:`true`_ -有効にすると、Logto は次の条件下でトークンリクエストに対して新しいリフレッシュ トークンを発行します: +有効にすると、Logto は次の条件下でトークンリクエスト時に新しいリフレッシュ トークンを発行します: -- リフレッシュ トークンが 1 年間ローテーションされている場合(新しいものを発行して TTL を延長した場合);**または** -- リフレッシュ トークンが有効期限に近い場合(元の Time to Live (TTL) の >=70% が経過した場合);**または** -- クライアントがパブリッククライアントである場合、例:ネイティブアプリケーションまたはシングルページアプリケーション (SPA)。 +- リフレッシュ トークンがローテーションされ(新しいものが発行されて有効期限が延長された)状態で 1 年経過した場合;**または** +- リフレッシュ トークンの有効期限が近い場合(元の有効期間 (TTL) の 70% 以上経過した場合);**または** +- クライアントがパブリッククライアント(例:ネイティブアプリやシングルページアプリ (SPA))の場合。 :::note -パブリッククライアントの場合、この機能が有効になっていると、クライアントがリフレッシュ トークンを使用して新しいアクセス トークンを交換するたびに、新しいリフレッシュ トークンが常に発行されます。 -これらのパブリッククライアントに対して機能をオフにすることもできますが、セキュリティ上の理由から有効にしておくことを強くお勧めします。 +パブリッククライアントの場合、この機能が有効だと、リフレッシュ トークンを使って新しいアクセス トークンを取得するたびに常に新しいリフレッシュ トークンが発行されます。 +パブリッククライアントでもこの機能を無効にできますが、セキュリティ上の理由から有効のままにすることを強く推奨します。 ::: リフレッシュ トークンのローテーションの理解 -### リフレッシュ トークンの有効期間 (TTL) (日単位)\{#refresh-token-time-to-live-ttl-in-days} +### リフレッシュ トークンの有効期間 (TTL) (日数) \{#refresh-token-time-to-live-ttl-in-days} -_利用可能性: SPA 以外; デフォルト: 14 日_ +_利用可能:SPA 以外;デフォルト:14 日_ -リフレッシュ トークンが新しいアクセス トークンを要求するために使用できる期間であり、有効期限が切れて無効になるまでの期間です。トークンリクエストは、リフレッシュ トークンの TTL をこの値に延長します。 +リフレッシュ トークンが新しいアクセス トークンをリクエストできる期間(有効期限)です。トークンリクエストにより、リフレッシュ トークンの TTL はこの値まで延長されます。 -通常、より低い値が好まれます。 +通常は、より低い値が推奨されます。 -注意: セキュリティ上の理由から、SPA(シングルページアプリケーション)では TTL の更新は利用できません。これは、Logto がトークンリクエストを通じて TTL を延長しないことを意味します。ユーザー体験を向上させるために、「リフレッシュ トークンをローテーションする」機能を有効にし、必要に応じて Logto が新しいリフレッシュ トークンを発行できるようにすることができます。 +注意:SPA(シングルページアプリ)ではセキュリティ上の理由から TTL の延長はできません。つまり、Logto はトークンリクエストによる TTL 延長を行いません。ユーザー体験を向上させるため、「リフレッシュ トークンのローテーション」機能を有効にし、必要に応じて新しいリフレッシュ トークンを発行できるようにしてください。 ### バックチャネルログアウト URI \{#backchannel-logout-uri} -OpenID Connect のバックチャネルログアウトエンドポイント。[フェデレーテッドサインアウト: バックチャネルログアウト](#) を参照して、詳細情報を確認できます。 +OpenID Connect のバックチャネルログアウトエンドポイントです。詳細は [フェデレーテッドサインアウト:バックチャネルログアウト](#) をご覧ください。 ### カスタムデータ \{#custom-data} -事前定義されたアプリケーションプロパティにリストされていない追加のカスタムアプリケーション情報であり、ユーザーはビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。 +事前定義されたアプリケーションプロパティに含まれない追加のカスタムアプリケーション情報です。ユーザーは、ビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index 8f42758fab3..69b3f14c1dd 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -5,26 +5,42 @@ sidebar_position: 1 # アプリケーションへの Logto 統合 -Logto を使ってアプリケーション(ユーザー向けアプリやマシン間通信サービス)に認証 (Authentication) 機能を追加するには、以下の手順に従ってください: +Logto を使ってアプリケーション(ユーザー向けアプリやマシン間通信サービス)に認証 (Authentication) 機能を追加するには、次の手順に従ってください: -1. コンソール > アプリケーション に移動します +1. コンソール > アプリケーション + に移動します。 -2. 「アプリケーションを作成」をクリックして新しいアプリケーションを追加します +2. 「アプリケーションを作成」をクリックして新しいアプリケーションを追加します。 -3. [アプリケーションフレームワーク](/quick-starts) を選択して開始します。該当するフレームワークが見つからない場合は、アプリケーション作成ページ右下の「フレームワークなしでアプリを作成」ボタンをクリックし、[アプリケーションタイプ](/integrate-logto/application-data-structure/#application-types) を選択してアプリを作成するか、[SDK 規約](/developers/sdk-conventions) に従って機能リクエストや SDK のコントリビュートを行ってください。 +3. [アプリケーションフレームワーク](/quick-starts) を選択して開始します。該当するフレームワークが見つからない場合は、アプリケーション作成ページ右下の「フレームワークなしでアプリを作成」ボタンをクリックし、[アプリケーションタイプ](/integrate-logto/application-data-structure/#application-types) を選択してアプリを作成するか、[SDK 規約](/developers/sdk-conventions) に従って機能リクエストを提出するか SDK をコントリビュートしてください。 -4. フレームワークを選択すると、そのフレームワークの SDK 用クイックスタートガイドが表示されます。手順に従ってアプリケーションの設定と統合を行ってください。統合プロセスに関わる概念について理解を深めたい場合は、[Logto 認証 (Authentication) フローの理解](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) を参照してください。 +4. フレームワークを選択すると、そのフレームワークの SDK 用クイックスタートガイドが表示されます。手順に従ってアプリケーションの設定と統合を行ってください。統合プロセスに関する概念を詳しく知りたい場合は、[Logto 認証 (Authentication) フローの理解](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) を参照してください。 :::note -コンソール内のガイドは、Logto SDK を使ったクイックスタート用です。高度な SDK 利用を含む完全な統合ガイドは、[クイックスタート](/quick-starts) セクションをご覧ください。 +コンソール内のガイドは、Logto SDK を使ったクイックスタート用です。高度な SDK 利用を含む完全な統合ガイドは [クイックスタート](/quick-starts) セクションをご覧ください。 ::: -5. 統合が完了したら、Logto のさらなる機能を探索できます: +5. 統合が完了したら、Logto のさらなる機能を探索しましょう: エンドユーザーフロー 認可 (Authorization) 組織 (Organizations) +## よくある質問 \{#faqs} + +
+ + ### バックエンドサービスでユーザートークンを検証し、Logto でユーザー管理を行うには? + +バックエンド API(例:Python、Node.js、Go、Java、PHP など)でアクセス トークン (Access token) を安全に検証し、プログラムでユーザー管理を行うには、次のガイドを参照してください:[API サービスやバックエンドでアクセス トークン (Access token) を検証する方法](/authorization/validate-access-tokens)。 + +このドキュメントでは以下を解説しています: + +- すべての API コールでベアラートークンの有効性を確認する方法 +- 複数のフロントエンドアプリとバックエンドサービスで Logto を統合するベストプラクティス + +
+ ## 関連リソース \{#related-resources} @@ -36,7 +52,7 @@ Logto を使ってアプリケーション(ユーザー向けアプリやマ - Logto 利用時に異なるタイプのアプリを区別する理由 + Logto 利用時に異なるアプリタイプを区別する理由 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index a7f64dd3fa6..a20c9e6e952 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -8,26 +8,26 @@ import CustomizationIcon from '@site/src/assets/customization.svg'; # サードパーティアプリ (OAuth / OIDC) -Logto のサードパーティアプリケーション統合により、外部アプリケーション向けに [アイデンティティプロバイダー (IdP)](https://auth.wiki/identity-provider) として Logto を活用できます。 +Logto のサードパーティアプリケーション統合を利用すると、外部アプリケーション向けに [アイデンティティプロバイダー (IdP)](https://auth.wiki/identity-provider) として Logto を活用できます。 -アイデンティティプロバイダー (IdP) とは、ユーザーのアイデンティティを検証し、ログイン認証情報を管理するサービスです。ユーザーのアイデンティティを確認した後、IdP は認証トークンやアサーションを生成し、ユーザーが再度ログインすることなくさまざまなアプリケーションやサービスへアクセスできるようにします。 +アイデンティティプロバイダー (IdP) とは、ユーザーのアイデンティティを検証し、ログイン認証情報を管理するサービスです。ユーザーのアイデンティティを確認した後、IdP は認証 (Authentication) トークンやアサーションを生成し、ユーザーが再度ログインすることなくさまざまなアプリケーションやサービスへアクセスできるようにします。 -[アプリケーションへの Logto 統合](/integrate-logto/integrate-logto-into-your-application) ガイドで作成した、開発・管理が完全に自分でできるアプリケーションとは異なり、サードパーティアプリケーションは外部の開発者やビジネスパートナーによって開発された独立したサービスです。 +[アプリケーションへの Logto 統合](/integrate-logto/integrate-logto-into-your-application) ガイドで作成した、開発・管理が完全に自社で行えるアプリケーションとは異なり、サードパーティアプリケーションは外部の開発者やビジネスパートナーによって開発された独立したサービスです。 この統合アプローチは、一般的なビジネスシナリオに最適です。Logto アカウントを使ってパートナーアプリケーションへアクセスできるようにしたり、エンタープライズユーザーが Google Workspace で Slack にサインインするような体験を提供できます。また、サードパーティアプリケーションが「Logto でサインイン」機能を追加できるオープンプラットフォームを構築することも可能です(「Google でサインイン」と同様)。 -Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコルに基づくアイデンティティサービスであり、[認証 (Authentication)](https://auth.wiki/authentication) と [認可 (Authorization)](https://auth.wiki/authorization) の両方の機能を提供します。これにより、OIDC サードパーティアプリの統合は従来の Web アプリケーションと同じくらい簡単です。 +Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコルに基づいたアイデンティティサービスであり、[認証 (Authentication)](https://auth.wiki/authentication) と [認可 (Authorization)](https://auth.wiki/authorization) の両方の機能を提供します。これにより、OIDC サードパーティアプリの統合は従来の Web アプリケーションと同じくらい簡単です。 -また、OIDC は [OAuth 2.0](https://auth.wiki/oauth-2.0) の上に認証レイヤーを追加したプロトコルであるため、OAuth プロトコルを使ったサードパーティアプリの統合も可能です。 +また、OIDC は [OAuth 2.0](https://auth.wiki/oauth-2.0) の上に認証 (Authentication) レイヤーを追加したプロトコルであるため、OAuth プロトコルを使ったサードパーティアプリの統合も可能です。 ## Logto でサードパーティアプリケーションを作成する \{#create-an-third-party-application-in-logto} 1. コンソール > アプリケーション にアクセスします。 -2. アプリケーションタイプとして「サードパーティアプリ」を選択し、次のいずれかの統合プロトコルを選びます: +2. 「アプリケーションを作成」ボタンをクリックします。アプリケーションタイプとして「サードパーティアプリ」を選択し、次のいずれかの統合プロトコルを選びます: - OIDC / OAuth -3. アプリケーション名と説明を入力し、「作成」ボタンをクリックします。新しいサードパーティアプリケーションが作成されます。 +3. アプリケーションの名前と説明を入力し、「作成」ボタンをクリックします。新しいサードパーティアプリケーションが作成されます。 -作成したすべてのサードパーティアプリケーションは、「サードパーティアプリ」タブのアプリケーションページに一覧表示されます。この仕組みにより、自分で作成したアプリケーションと区別しやすくなり、すべてのアプリケーションを一元管理できます。 +作成したサードパーティアプリケーションはすべて、「アプリケーション」ページの「サードパーティアプリ」タブに一覧表示されます。この構成により、自社アプリケーションと区別しやすくなり、すべてのアプリケーションを一元管理できます。 ## OIDC 設定を行う \{#set-up-the-oidc-configurations} @@ -36,17 +36,17 @@ OIDC 設定を行う前に、[OIDC サードパーティアプリケーション ::: 1. OIDC サードパーティアプリケーションの [**リダイレクト URI**](/integrate-logto/application-data-structure#redirect-uris) を入力します。これは、Logto で認証 (Authentication) された後にサードパーティアプリケーションがユーザーをリダイレクトする URL です。 - この情報は通常、サードパーティアプリケーションの IdP 接続設定ページで確認できます。 + 通常、この情報はサードパーティアプリケーションの IdP 接続設定ページで確認できます。 2. Logto アプリケーション詳細ページから [**クライアント ID**](/integrate-logto/application-data-structure#application-id) と [**クライアントシークレット**](/integrate-logto/application-data-structure#application-secret) を取得し、サービスプロバイダーの IdP 接続設定ページに入力します。 3. Logto アプリケーション詳細ページから [**認可エンドポイント**](/integrate-logto/application-data-structure#authorization-endpoint) と [**トークンエンドポイント**](/integrate-logto/application-data-structure#token-endpoint) を取得し、サービスプロバイダーに提供します。 - サービスプロバイダーが OIDC ディスカバリーに対応している場合は、Logto アプリケーション詳細ページから **ディスカバリーエンドポイント** をコピーしてサービスプロバイダーに提供するだけで、すべての最新 OIDC 認証 (Authentication) 情報を自動的に取得できます。 - そうでない場合は、**エンドポイント詳細を表示** ボタンをクリックして、すべての OIDC 認証 (Authentication) エンドポイントを確認してください。 + サービスプロバイダーが OIDC ディスカバリーに対応している場合は、Logto アプリケーション詳細ページから **ディスカバリーエンドポイント** をコピーしてサービスプロバイダーに提供するだけで、サービスプロバイダーが最新の OIDC 認証 (Authentication) 情報を自動的に取得できます。 + それ以外の場合は、**エンドポイント詳細を表示**ボタンをクリックして、すべての OIDC 認証 (Authentication) エンドポイントを確認してください。 ## OIDC サードパーティアプリケーションの同意画面 (Consent screen) \{#consent-screen-for-oidc-third-party-applications} -セキュリティ上の理由から、すべての OIDC サードパーティアプリケーションは Logto で認証 (Authentication) された後、[同意画面](/end-user-flows/consent-screen) にリダイレクトされ、ユーザーによる認可 (Authorization) が行われます。 +セキュリティ上の理由から、すべての OIDC サードパーティアプリケーションは Logto で認証 (Authentication) された後、ユーザー認可 (Authorization) のために [同意画面](/end-user-flows/consent-screen) にリダイレクトされます。 サードパーティが要求した [ユーザープロファイル権限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API リソーススコープ](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[組織権限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes)、および組織メンバーシップ情報が同意画面に表示されます。 @@ -91,11 +91,11 @@ OIDC 設定を行う前に、[OIDC サードパーティアプリケーション -Logto ではロールベースのアクセス制御 (RBAC) を用いてユーザー権限を管理しています。同意画面には、ユーザーにすでに割り当てられているスコープ(権限)のみが表示されます。サードパーティアプリがユーザーの持たないスコープを要求した場合、それらは除外され、許可されていない同意を防ぎます。 +Logto ではロールベースのアクセス制御 (RBAC) を使ってユーザー権限を管理しています。同意画面には、ユーザーに既に割り当てられているスコープ(権限)のみが表示されます。サードパーティアプリがユーザーの持っていないスコープを要求した場合、それらは除外され、誤った同意が行われないようになっています。 管理方法: -- [グローバルロール](/authorization/role-based-access-control) または [組織ロール](/authorization/organization-template) に特定のスコープを定義します。 +- [グローバルロール](/authorization/role-based-access-control) または [組織ロール](/authorization/organization-template) を特定のスコープで定義します。 - アクセス要件に応じてユーザーにロールを割り当てます。 - ユーザーはロールから自動的にスコープを継承します。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index 2b4e1dc772a..4b8bf4c49b7 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,12 +3,13 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Logto クラウドサービス [Logto Cloud](https://cloud.logto.io) は、アイデンティティやリソースの管理をスムーズかつ簡単に行うためのさまざまな管理・運用サービスを提供しています。Logto によってホストされており、[マルチリージョンサポート](/logto-cloud/tenant-settings#tenant-region)、テナント管理、[請求と価格](/logto-cloud/billing-and-pricing)、[メンバー管理](/logto-cloud/tenant-member-management)、およびコンソールのロールベースのアクセス制御などの機能が含まれています。 -クラウドサービスに関するご質問や追加サポートが必要な場合は、お問い合わせください。 +クラウドサービスについてご質問や追加サポートが必要な場合は、お問い合わせください。 ## クラウドサービスの機能 \{#features-for-cloud-service} @@ -47,7 +48,7 @@ import CustomDomains from '@site/src/assets/search.svg'; label: 'カスタムドメイン', href: '/logto-cloud/custom-domain', description: - 'Logto テナントで独自ドメインを利用し、サインイン体験でブランドを一貫させることができます。', + 'Logto テナントに独自ドメインを利用し、サインイン体験でブランドを一貫させることができます。', customProps: { icon: , }, @@ -61,5 +62,14 @@ import CustomDomains from '@site/src/assets/search.svg'; icon: , }, }, + { + type: 'link', + label: 'システム制限', + href: '/logto-cloud/system-limit', + description: 'Dev、Pro、Enterprise テナントのシステム制限やレート保護について理解できます。', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index 383c33dd0e6..f8b1644ccc0 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -6,17 +6,17 @@ sidebar_position: 4 # カスタムドメイン -Logto テナントには、デフォルトで無料のドメイン `{{tenant-id}}.app.logto` が付与されます。しかし、カスタムドメイン(例:`auth.example.com`)を利用することで、ユーザー体験やブランド認知を向上させることができます。 +Logto テナントには、デフォルトで無料のドメイン `{{tenant-id}}.app.logto` が付与されます。しかし、カスタムドメイン(例:`auth.example.com`)を使用することで、ユーザー体験やブランド認知を向上させることができます。 カスタムドメインは、以下の機能で使用されます: - [サインインおよび登録ページ](/end-user-flows/sign-up-and-sign-in) の URL -- [パスキー](/end-user-flows/mfa/webauthn) 連携用 URL(ユーザーがパスキーを連携した後にドメインを変更すると、認証 (Authentication) ができなくなる場合があります) +- [パスキー](/end-user-flows/mfa/webauthn) リンク用 URL(パスキー連携後にドメインを変更すると、認証 (Authentication) ができなくなる場合があります) - [ソーシャルコネクター](/connectors/social-connectors) や [エンタープライズ SSO コネクター](/connectors/enterprise-connectors) のコールバック URI -- アプリケーションと Logto を統合するための [SDK エンドポイント](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) +- Logto をアプリケーションと統合するための [SDK エンドポイント](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) :::note -サービス公開後にドメインを変更すると、アプリケーションコードや統合先が古いドメインを参照し続けるため、問題が発生する可能性があります。スムーズな移行のために、**本番テナント作成時にカスタムドメインを設定してください**。 +サービス公開後にドメインを変更すると、アプリケーションコードや統合部分が古いドメインを参照している場合があり、問題が発生する可能性があります。スムーズな移行のために、**本番テナント作成時に最初からカスタムドメインを設定してください**。 ::: ## コンソールでカスタムドメインを設定する \{#configure-custom-domain-in-console} @@ -32,9 +32,9 @@ Logto コンソールで新しいカスタムドメインを追加するには Custom domain processing -4. 認証および SSL 処理が完了するまで待ちます。 - 1. カスタムドメインが追加されるまで、10 秒ごとに自動でレコードを検証します。入力したドメイン名や DNS レコードが正確であることを確認してください。 - 2. 検証は通常数分で完了しますが、DNS プロバイダーによっては最大 24 時間かかる場合があります。処理中は他の画面に移動しても問題ありません。 +4. 認証 (Authentication) および SSL 処理が完了するまで待ちます。 + 1. カスタムドメインが追加されるまで、10 秒ごとに自動でレコードを確認します。入力したドメイン名や DNS レコードが正確であることを確認してください。 + 2. 認証 (Authentication) には通常数分かかりますが、DNS プロバイダーによっては最大 24 時間かかる場合があります。処理中は他のページに移動しても問題ありません。 ## トラブルシューティング \{#troubleshooting} @@ -45,9 +45,9 @@ Logto コンソールで新しいカスタムドメインを追加するには -カスタムドメイン設定時に SSL 証明書の問題が発生した場合、DNS 設定の CAA レコードが原因の可能性があります。CAA レコードは、どの認証局 (CA) がドメインの証明書を発行できるかを指定します。CAA レコードを使用している場合は、Logto で SSL 証明書を発行できるように「letsencrypt.org」と「pki.goog」の両方を許可する必要があります。 +カスタムドメイン設定時に SSL 証明書の問題が発生した場合、DNS 設定の CAA レコードが原因の可能性があります。CAA レコードは、どの認証局 (CA) がドメインの証明書を発行できるかを指定します。CAA レコードを使用している場合は、Logto で SSL 証明書を発行できるように "letsencrypt.org" と "pki.goog" の両方を許可する必要があります。 -CAA レコードに関連する SSL 証明書の問題のトラブルシューティングと解決方法については、 [Cloudflare のドキュメント](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) を参照してください。 +CAA レコードに関連する SSL 証明書の問題のトラブルシューティングと解決方法については、[Cloudflare のドキュメント](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) を参照してください。 @@ -67,11 +67,42 @@ CAA レコードに関連する SSL 証明書の問題のトラブルシュー
-### Cloudflare 管理ドメインでの「Connection timed out (エラーコード 522)」 \{#cloudflare-522-timeout} +### Cloudflare ホストドメインでのタイムアウト(エラーコード 522)\{#cloudflare-522-timeout} -ドメインが Cloudflare で管理されている場合、CNAME レコードの Cloudflare プロキシを無効にしてください。 +ドメインが Cloudflare でホストされている場合、CNAME レコードの Cloudflare プロキシを無効にしてください。 + +
+ +
+ + +### カスタムドメイン設定後の「Redirect URI does not match」エラー \{#redirect-uri-mismatch} + + + +カスタムドメイン追加後に「redirect URI does not match」エラーが発生した場合、SDK 設定でエンドポイントとしてカスタムドメインを使用する必要があります。 + +**「プライマリドメイン」について:** + +Logto には「プライマリドメイン」設定はありません。カスタムドメイン追加後も、カスタムドメインとデフォルトの `{tenant-id}.logto.app` ドメインの両方が有効です。SDK の `endpoint` パラメーターで設定したドメインが、認証 (Authentication) フローで使用されるドメインとなります。 + +**解決方法:** + +SDK 初期化時の `endpoint` パラメーターをカスタムドメインに更新してください: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // カスタムドメインを使用 + appId: 'your-app-id', + // ... その他のオプション +}); +``` + +また、コンソール → アプリケーション で登録されているリダイレクト URI が、使用しているドメインと一致しているか確認してください。 + +**注意:** Logto はカスタムドメイン用の SSL 証明書を自動で発行・管理します。独自の証明書を設定する必要はありません。
@@ -81,33 +112,33 @@ CAA レコードに関連する SSL 証明書の問題のトラブルシュー :::note -この記事では、カスタムドメインを `auth.example.com` と仮定します。 +本記事では、カスタムドメインを `auth.example.com` と仮定しています。 ::: -### アプリケーションの SDK エンドポイントを更新する \{#updating-the-sdk-endpoint-for-applications} +### アプリケーション用 SDK エンドポイントの更新 \{#updating-the-sdk-endpoint-for-applications} Logto SDK の初期化コードで、エンドポイントのドメイン名を変更してください。 ```typescript const client = new LogtoClient({ - ...,// 他のオプション + ...,// その他のオプション endpoint: 'https://auth.example.com', }); ``` -### その他のアプリケーションの認証 (Authentication) エンドポイントを変更する \{#modifying-auth-endpoints-for-other-applications} +### その他アプリケーションの認証 (Authentication) エンドポイントの変更 \{#modifying-auth-endpoints-for-other-applications} -Logto SDK を使用していないアプリケーションの場合、認証 (Authentication) エンドポイントを更新する必要があります。 +Logto SDK を使用していないアプリケーションの場合は、認証 (Authentication) エンドポイントを更新する必要があります。 -認証 (Authentication) エンドポイントは、以下の well-known URL で確認できます: +認証 (Authentication) エンドポイントは、次の well-known URL で確認できます: ``` https://auth.example.com/oidc/.well-known/openid-configuration ``` -### ソーシャルコネクターのコールバック URI を更新する \{#updating-the-social-connectors-callback-uri} +### ソーシャルコネクターのコールバック URI の更新 \{#updating-the-social-connectors-callback-uri} ユーザーがカスタムドメインを利用している場合、ソーシャルコネクターのコールバック URI は自動的に新しいドメインに更新されます。ただし、ソーシャルプロバイダーの開発者コンソールでコールバック URI を手動で更新する必要があります。 -カスタムドメイン利用時、ソーシャルコネクターのコールバック URI も新しいドメインとなるため、ソーシャルプロバイダーの開発者コンソールでコールバック URI を必ず手動で更新してください。 +ユーザーがカスタムドメインを利用している場合、ソーシャルコネクターのコールバック URI も新しいドメインとなります。そのため、ソーシャルプロバイダーの開発者コンソールに移動し、コールバック URI を手動で更新してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..f7ca77e2577 --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# システム制限 + +Logto では、すべてのプランで寛大な制限を設けており、柔軟な従量課金オプションも提供しています。そのため、実際に利用した分だけ料金が発生します。 + +料金ページの一部項目には _無制限_ または _上限なしの継続的な従量課金_ と記載されている場合があります。これは、基本的に制限なく利用できることを意味しますが、Logto はすべてのユーザーの公正な利用を維持するため、実際の制限を随時調整する権利を留保します。つまり、エンティティ制限はプラットフォーム全体の健全性を守るための厳格な上限です。これらは料金体系の一部ではありませんが、プランごとに異なる場合があります。 + +利用ケースが合理的であってもシステム制限に達した場合は、ぜひご連絡いただき、ご意見をお聞かせください。これにより、実際の利用パターンをより深く理解し、システム制限を調整してロイヤルカスタマーをより良くサポートできるようになります。 + +## テナントレベルのレート制限保護 \{#tenant-level-rate-limit-protection} + +### Dev テナント \{#dev-tenants} + +Dev テナントでは、Logto の無料機能やサービスを利用できます。悪用防止と明確な期待値設定のため、特定のシステム制限を設けています。これらの制限は、テストや開発目的で無料アクセスを提供しつつ、プラットフォームを持続的に運営するためのものです。 + +クォータの増加を希望する場合は、お気軽にご連絡ください。また、**Dev** から **Pro** へのアップグレードを推奨しています。これにより上限が解除され、すぐにフルアクセスが可能になります。 + +| **機能** | **エンティティ制限** | +| ---------------------------------------- | -------------------- | +| **含まれるトークン** | 月間 50,000 | +| **アプリケーション** | | +| 総アプリケーション数 | 100 | +| マシン間通信アプリ | 100 | +| サードパーティアプリ | 100 | +| **API リソース** | | +| リソース数 | 100 | +| **ユーザー認証 (Authentication)** | | +| ソーシャルコネクター | 100 | +| エンタープライズシングルサインオン (SSO) | 100 | +| **ユーザー管理** | | +| ユーザーロール | 100 | +| マシン間通信ロール | 100 | +| ロールごとの権限 | 100 | +| **組織 (Organizations)** | | +| 組織数 | 5,000 | +| 組織ごとのユーザー数 | 100,000 | +| 組織ユーザーロール | 1,000 | +| 組織マシン間通信ロール | 100 | +| 組織権限 | 1,000 | +| **開発者およびプラットフォーム** | | +| Webhook | 10 | +| 監査ログ保持期間 | 14日間 | +| テナントメンバー | 20 | + +### Pro テナント \{#pro-tenant} + +Pro テナントでは、エンティティ制限がアドオンや「無制限」エンティティ(アプリケーションなど)の上限を定義します。Pro プランのシステム制限の詳細は以下の通りです。 + +| **機能** | **エンティティ制限** | +| ---------------------------------------- | -------------------- | +| **含まれるトークン** | 月間 10,000,000 | +| **アプリケーション** | | +| 総アプリケーション数 | 100 | +| マシン間通信アプリ | 100 | +| OIDC/OAuth サードパーティアプリ | 100 | +| SAML アプリ | 100 | +| **API リソース** | | +| リソース数 | 1,000 | +| リソースごとの権限 | 1,000 | +| **ユーザー認証 (Authentication)** | | +| ソーシャルコネクター | 100 | +| エンタープライズシングルサインオン (SSO) | 100 | +| **ユーザー管理** | | +| ユーザーロール | 1,000 | +| マシン間通信ロール | 100 | +| **組織 (Organizations)** | | +| 組織数 | 100,000 | +| 組織ごとのユーザー数 | 100,000 | +| 組織ユーザーロール | 1,000 | +| 組織マシン間通信ロール | 100 | +| 組織権限 | 1,000 | +| **開発者およびプラットフォーム** | | +| Webhook | 10 | +| 監査ログ保持期間 | 14日間 | +| カスタムドメイン | 10 | +| テナントメンバー | 100 | + +### エンタープライズ \{#enterprise} + +エンタープライズプランでは、制限や機能はすべてカスタマイズ可能で、契約を通じて管理されます。詳細は [こちらからお問い合わせ](https://logto.io/contact) ください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index ec0ed7a0bc0..d05783ce8c4 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -8,7 +8,7 @@ sidebar_position: 1 Logto Cloud に新規登録したユーザーは、自動的に無料の **開発 (Development)** (Dev) 環境テナントにオンボーディングされます。このテナントで全ての機能を試すことができます。 -**本番 (Production)** (Prod) 環境や新しいプロジェクト用に別のテナントを作成したい場合は、画面上部バーの左上にある現在のテナント名をクリックしてください。このメニューでテナントの切り替えや新規作成ができます。 +**本番 (Production)** (Prod) 環境や新しいプロジェクト用に別のテナントを作成したい場合は、画面上部のバーの左上にある現在のテナント名をクリックしてください。このメニューでテナントの切り替えや新規作成ができます。 「テナントを作成」をクリックし、次の情報を入力します: @@ -21,7 +21,7 @@ Logto Cloud に新規登録したユーザーは、自動的に無料の **開 - テナント ID の表示 - テナント名の更新 - [テナントリージョン](#tenant-region) の表示(作成後は変更できません) -- [テナントタイプ](#tenant-types-dev-vs-prod) の表示(必要に応じて Dev テナントを Prod テナントに変換できます) +- [テナントタイプ](#tenant-types-dev-vs-prod) の表示(必要に応じて Dev テナントを Prod テナントに変換可能) - [テナントから退出](#leave-tenant) - [テナントの削除](#delete-tenant) @@ -34,7 +34,7 @@ Logto Cloud に新規登録したユーザーは、自動的に無料の **開 - オーストラリア(オーストラリア東部) - 日本(日本東部) -通常、顧客に最も近いリージョンを選択することで、レイテンシを最小限に抑え、パフォーマンスを向上させることができます。 +通常は、顧客に最も近いリージョンを選択することで、レイテンシを最小限に抑え、パフォーマンスを向上させることができます。 Logto はグローバルエッジネットワークを活用し、アプリケーションに最高のパフォーマンスと可用性を提供します。リクエストルーティングは最適化されており、常にユーザーが最適な接続先にアクセスできるようになっています。 @@ -42,12 +42,12 @@ Logto はグローバルエッジネットワークを活用し、アプリケ 他のリージョンをご希望ですか? [お問い合わせください](https://logto.io/contact): - 新しいパブリッククラウドリージョンのリクエスト -- ご希望の場所での Logto プライベートクラウド導入についてのお問い合わせ +- ご希望の場所での Logto プライベートクラウド導入についてのご相談 ::: ## テナントタイプ:Dev と Prod \{#tenant-types-dev-vs-prod} -Logto Cloud には、開発 (Development, Dev) と本番 (Production, Prod) の 2 種類のテナントがあります。この区分により、異なる環境でプロジェクトを効率的に管理でき、Logto の価値を最大限に活用できます。 +Logto Cloud には「開発 (Development, Dev)」と「本番 (Production, Prod)」の 2 種類のテナントがあります。この区分により、異なる環境でプロジェクトを効率的に管理しつつ、Logto の全機能を活用できます。 テナント作成時にタイプを選択できます。本番運用の準備ができたら、次の 2 つの方法があります: @@ -56,11 +56,11 @@ Logto Cloud には、開発 (Development, Dev) と本番 (Production, Prod) の - **現在の Dev テナントを本番に変換** 設定やユーザーの移行をやり直したくない場合は、既存の開発テナントを有料の本番テナントにアップグレードできます。 - - **Pro プランに変換**:コンソール > テナント設定 > 設定 に移動し、「変換」をクリックしてセルフサービスでアップグレードできます。Dev テナントで利用した有料機能は Stripe チェックアウトに引き継がれます。 - - **エンタープライズプランに変換**:[お問い合わせください](https://logto.io/contact)。アップグレードをサポートします。 + - **Pro プランへ変換**: コンソール > テナント設定 > 設定 に移動し、「変換」をクリックしてセルフサービスでアップグレードできます。Dev テナントで利用していた有料機能は Stripe チェックアウトに引き継がれます。 + - **エンタープライズプランへ変換**: [お問い合わせください](https://logto.io/contact)。アップグレードをサポートします。 :::note - 一度変換すると、テナントを Dev 環境に戻すことはできません。準備ができていることを確認してから進めてください。 + 一度変換すると、テナントを Dev 環境に戻すことはできません。準備ができていることをご確認の上、進めてください。 ::: ### 開発 (Development) \{#development} @@ -69,46 +69,20 @@ Logto Cloud には、開発 (Development, Dev) と本番 (Production, Prod) の ただし、開発テナントには以下の制限があります: -- Dev テナントでは 90 日を超えたユーザーが自動的に削除されます。詳細は [Dev テナントのデータ保持ポリシー](./dev-tenant-data-retention) をご確認ください。 -- サインイン体験時に、テナントが開発モードであることを示すバナーが表示されます。 -- 開発テナントには一部機能にクォータ制限があります。該当する場合は機能詳細ページで説明されています。 +- Dev テナントでは 90 日を超えたユーザーが自動的に削除されます。詳細は [Dev テナントデータ保持ポリシー](./dev-tenant-data-retention) をご確認ください。 +- サインイン体験時に、開発モードであることを示すバナーが表示されます。 +- 開発テナントには一部機能にクォータ制限がある場合があります。該当する場合は機能詳細ページで説明されています。Dev プランの制限一覧は [システム制限](./system-limit) ページをご参照ください。 - Logto は開発テナントのクォータ制限を更新する場合があり、事前に通知するよう努めます。 -| 機能 | エンティティ上限 | -| --------------------------------- | ---------------- | -| **含まれるトークン** | 月あたり 50,000 | -| **アプリケーション** | -| 総アプリケーション数 | 100 | -| マシン間通信アプリ | 100 | -| サードパーティアプリ | 100 | -| **API リソース** | | -| リソース数 | 100 | -| **ユーザー認証 (Authentication)** | | -| ソーシャルコネクター | 100 | -| エンタープライズ SSO | 100 | -| **ユーザー管理** | | -| ユーザーロール | 100 | -| マシン間通信ロール | 100 | -| ロールごとの権限 | 100 | -| **組織 (Organizations)** | | -| 組織数 | 5,000 | -| 組織ごとのユーザー数 | 5,000 | -| 組織ロール | 100 | -| 組織権限 | 100 | -| **開発者・プラットフォーム** | | -| Webhook | 10 | -| 監査ログ保持 | 14 日間 | -| テナントメンバー | 20 | - ### 本番 (Production) \{#production} -本番テナントは、エンドユーザーが実際にアプリを利用する環境であり、[有料サブスクリプション](https://logto.io/pricing) が必要になる場合があります。Free プランまたは Pro プランに加入することで本番テナントを作成できます。Free プランの場合、作成できるテナントは最大 10 個までです。 +本番テナントは、エンドユーザーが実際にアプリを利用する環境です。[有料サブスクリプション](https://logto.io/pricing) が必要になる場合があります。Free プランまたは Pro プランに加入して本番テナントを作成できます。Free プランの場合、作成できるテナントは最大 10 個までです。 ## MFA の有効化 \{#enable-mfa} Logto Pro / Enterprise テナントの全メンバーに多要素認証 (MFA) を必須にすることで、ワークスペースのセキュリティを強化できます。 -セルフサービスはまだ利用できないため、有効化をご希望の場合は [お問い合わせください](https://logto.io/contact)。 +セルフサービスはまだ利用できないため、[お問い合わせください](https://logto.io/contact) でこの機能の有効化をご依頼ください。 ## エンタープライズ SSO の有効化 \{#enable-enterprise-sso} @@ -120,7 +94,7 @@ Logto Cloud は、Enterprise プランテナント向けにエンタープライ 管理者は、このテナントに [追加メンバーを招待](/logto-cloud/tenant-member-management) できます。 -他に少なくとも 1 人の **管理者 (ロール)** がいる場合、または自分が **コラボレーター (ロール)** の場合、テナントから退出できます。退出後もテナント内の全リソースは残りますが、アクセス権は失われます。 +他に少なくとも 1 人の **管理者**(ロール)がいる場合、または自分が **コラボレーター**(ロール)の場合は、テナントから退出できます。退出後もテナント内の全リソースは残りますが、アクセス権は失われます。 最後の管理者である場合は、退出前に他のコラボレーターを管理者に割り当てる必要があります。 @@ -141,14 +115,14 @@ Logto Cloud は、Enterprise プランテナント向けにエンタープライ **開発 (Development)** テナントを有料プランの **本番 (Production)** テナントにセルフサービスで変換できます。[詳細はこちら](#tenant-types-dev-vs-prod) -ただし、Logto Cloud と OSS バージョン間での(全設定・ユーザーデータを含む)セルフサービス移行はサポートされていません。このサービスが必要な場合は、[Logto チームまでご相談ください](https://logto.io/contact)。 +ただし、Logto Cloud と OSS バージョン間での(全設定・ユーザーデータを含む)セルフサービス移行はサポートされていません。このサービスが必要な場合は、[Logto チームにご相談ください](https://logto.io/contact)。 -プロジェクトで Logto Cloud の利用を停止する場合、Logto では全ユーザーデータのエクスポートをサポートしています。[ご連絡ください](https://logto.io/contact)。 +プロジェクトで Logto Cloud の利用を停止する場合、Logto では全ユーザーデータのエクスポートをサポートしています。[ご相談ください](https://logto.io/contact)。 ## 関連リソース \{#related-resources} - ローカルリージョンと専用コンピューティングリソースでアイデンティティを保護する + ローカルリージョンと専用コンピューティングリソースでアイデンティティを保護 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index 3ab0a0c3959..61c2c911a26 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -1,5 +1,5 @@ --- -description: Logto オープンソースサービス (OSS) の初期化に関するクイックスタートガイド。 +description: Logto オープンソースサービス (OSS) 初期化のクイックスタートガイド。 sidebar_position: 1 --- @@ -13,7 +13,7 @@ import ZeaburIcon from '@site/src/assets/oss-zeabur.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; -# OSS を始める +# OSS で始める ## GitPod \{#gitpod} @@ -28,33 +28,34 @@ Logto のオンライン GitPod ワークスペースを開始するには、

-Logto はデフォルトでそのコアサービスにポート `3001` を、インタラクティブな管理コンソールにポート `3002` を使用します。 +Logto は、コアサービスに `3001` ポート、インタラクティブな管理コンソールに `3002` ポートをデフォルトで使用します。 -Logto の旅を続けるには、Ctrl (または Cmd) を押しながら `https://3002-...` で始まるリンクをクリックしてください。お楽しみください! +Logto の利用を続けるには、Ctrl(または Cmd)を押しながら `https://3002-...` で始まるリンクをクリックしてください。お楽しみください! ## ローカル \{#local} -Logto をホスティングするための最小推奨ハードウェア要件は次のとおりです: +Logto をホスティングするための最小推奨ハードウェア要件は以下の通りです: -- **vCPU**: 2 -- **メモリ**: 8 GiB -- **ディスク**: 256 GiB +- **vCPU**:2 +- **メモリ**:8 GiB +- **ディスク**:256 GiB -Docker Compose CLI は通常、[Docker Desktop](https://www.docker.com/products/docker-desktop) に付属しています。 +Docker Compose CLI は通常 [Docker Desktop](https://www.docker.com/products/docker-desktop) に付属しています。 :::caution -本番環境では私たちの docker compose コマンドを使用しないでください!現在、Logto アプリに組み込まれた Postgres データベースが `docker-compose.yml` にバンドルされているため、コマンドを再実行するたびに新しいデータベースインスタンスが作成され、以前に保存されたデータは失われます。 +本番環境では当社の docker compose コマンドを使用しないでください!現在、`docker-compose.yml` で Logto アプリと一緒に組み込みの Postgres データベースがバンドルされているため、 +コマンドを再実行するたびに新しいデータベースインスタンスが作成され、以前に保存されたデータはすべて失われます。 ::: ```bash curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | docker compose -p logto -f - up ``` -成功したコンポジションの後、次のようなメッセージが表示されます: +正常に構成されると、次のようなメッセージが表示されます: @@ -62,7 +63,7 @@ curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.

ステップ 1

-[PostgreSQL](https://www.postgresql.org/)@^14.0 インスタンスを準備し、[Logto CLI](/logto-oss/using-cli) を使用して Logto のデータベースをシードします: +[PostgreSQL](https://www.postgresql.org/)@^14.0 インスタンスを用意し、[Logto CLI](/logto-oss/using-cli) を使って Logto 用のデータベースを初期化します: @@ -85,7 +86,7 @@ npx @logto/cli db seed

ステップ 2

-イメージをプルします: +イメージを取得します: ```bash # ghcr @@ -96,16 +97,16 @@ docker pull svhd/logto:latest

ステップ 3

-コンテナポートを Logto コアと管理アプリにマッピングします。例:`3001:3001` および `3002:3002`。次の環境変数をコンテナに設定します: +コンテナのポートを Logto コアおよび管理アプリにマッピングします(例:`3001:3001` および `3002:3002`)。また、以下の環境変数をコンテナに設定します: ```yml -TRUST_PROXY_HEADER: 1 # Logto の前に HTTPS プロキシ (例:Nginx) がある場合は 1 に設定 -ENDPOINT: https:// # (オプション) カスタムドメインを使用している場合は Logto エンドポイント URL に置き換え -ADMIN_ENDPOINT: https:// # (オプション) カスタムドメインを使用している場合は Logto 管理 URL に置き換え +TRUST_PROXY_HEADER: 1 # Logto の前に HTTPS プロキシ(例:Nginx)がある場合は 1 に設定 +ENDPOINT: https:// # (任意)カスタムドメインを使用する場合は Logto エンドポイント URL に置き換え +ADMIN_ENDPOINT: https:// # (任意)カスタムドメインを使用する場合は Logto 管理 URL に置き換え DB_URL: postgres://username:password@your_postgres_url:port/db_name # Postgres DSN に置き換え ``` -上記のすべての環境変数を使用してコンテナを実行します: +上記すべての環境変数を指定してコンテナを実行します: ```bash docker run \ @@ -121,7 +122,7 @@ docker run \ :::tip -- Docker Hub を使用している場合は、`ghcr.io/logto-io/logto:latest` の代わりに `svhd/logto:latest` を使用してください。 +- Docker Hub を利用する場合は、`ghcr.io/logto-io/logto:latest` の代わりに `svhd/logto:latest` を使用してください。 - `DB_URL` でホスト IP を参照するには `host.docker.internal` または `172.17.0.1` を使用してください。 ::: @@ -137,11 +138,11 @@ docker run \ - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -より高いバージョンは通常動作しますが、保証はありません。 +より高いバージョンでも通常は動作しますが、保証はありません。 -Logto に専用の新しい空のデータベースを使用することをお勧めしますが、これは必須ではありません。 +Logto 専用の新しい空のデータベースを使用することを推奨しますが、必須ではありません。 -**ダウンロードと開始** +**ダウンロードと起動** ターミナルで: @@ -149,7 +150,7 @@ Logto に専用の新しい空のデータベースを使用することをお npm init @logto@latest ``` -初期化プロセスを完了し、Logto を開始すると、次のようなメッセージが表示されます: +初期化プロセスを完了し Logto を起動すると、次のようなメッセージが表示されます: @@ -162,7 +163,7 @@ Admin app is running at http://localhost:3002 Admin app is running at https://your-admin-domain-url ``` -`http://localhost:3002/` にアクセスして Logto の旅を続けてください。お楽しみください! +`http://localhost:3002/` にアクセスして Logto の利用を続けてください。お楽しみください!
@@ -172,13 +173,13 @@ Admin app is running at https://your-admin-domain-url -Logto zip ファイルの URL を指定したい場合は、`--download-url` オプションを使用してください。例: +Logto の zip ファイルの URL を指定したい場合は、`--download-url` オプションを使用してください。例: ``` npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -NPM に引数を渡すために追加の `--` が必要です。 +NPM で引数を渡すためには、追加の `--` が必要です。
@@ -186,19 +187,19 @@ NPM に引数を渡すために追加の `--` が必要です。 -### 設定 (オプション) \{#configuration-optional} +### 設定(オプション) \{#configuration-optional} -Logto は環境変数を使用して設定を行い、`.env` ファイルのサポートもあります。詳細な使用法と完全な変数リストについては、[設定](/concepts/core-service/configuration) を参照してください。 +Logto は環境変数による設定を採用しており、`.env` ファイルにも対応しています。詳細な使い方や全変数リストは [設定](/concepts/core-service/configuration) をご覧ください。 -_Logto に対するより高度な制御やプログラムによるアクセスを希望する場合は、[コアサービス](/concepts/core-service) を確認してください。_ +_より高度な制御やプログラムによる Logto へのアクセスが必要な場合は、[コアサービス](/concepts/core-service) をご確認ください。_ ## ホスティングプロバイダー \{#hosting-providers} -これらの信頼できるホスティングプロバイダーは、Logto のワンクリックインストールテンプレートを提供しています。簡単にデプロイ可能なサービスを使用して、Logto を使用した CIAM システムを数秒でセットアップして起動できます。 +これらの信頼できるホスティングプロバイダーは、Logto のワンクリックインストールテンプレートを提供しています。簡単にデプロイ可能なサービスで、Logto を使った CIAM システムを数秒でセットアップし起動できます。 , }, @@ -216,8 +216,7 @@ _Logto に対するより高度な制御やプログラムによるアクセス type: 'link', label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', - description: - '簡単なアプリとデータベース管理のためのセルフホスト可能な Heroku/Netlify の代替。', + description: 'アプリやデータベース管理が簡単なセルフホスト型 Heroku / Netlify 代替。', customProps: { icon: , }, @@ -226,7 +225,7 @@ _Logto に対するより高度な制御やプログラムによるアクセス type: 'link', label: 'Dokploy', href: 'https://docs.dokploy.com/docs/core', - description: '独自のインフラストラクチャにアプリをデプロイするための軽量ツール。', + description: '独自インフラ上でアプリをデプロイするための軽量ツール。', customProps: { icon: , }, @@ -235,7 +234,7 @@ _Logto に対するより高度な制御やプログラムによるアクセス type: 'link', label: 'Easypanel', href: 'https://easypanel.io/docs/templates/logto', - description: 'Docker を使用してクラウドサーバーを管理するための最新のコントロールパネル。', + description: 'Docker でクラウドサーバーを管理するための最新コントロールパネル。', customProps: { icon: , }, @@ -245,7 +244,7 @@ _Logto に対するより高度な制御やプログラムによるアクセス label: 'Elestio', href: 'https://elest.io/open-source/logto', description: - 'コードとオープンソースソフトウェアをデプロイするための完全管理型 DevOps プラットフォーム。', + 'コードやオープンソースソフトウェアをデプロイできる完全管理型 DevOps プラットフォーム。', customProps: { icon: , }, @@ -254,7 +253,7 @@ _Logto に対するより高度な制御やプログラムによるアクセス type: 'link', label: 'Railway', href: 'https://railway.com/template/07_f_Z', - description: 'アプリのデプロイとインフラストラクチャ管理を簡素化します。', + description: 'アプリのデプロイやインフラ管理を簡素化します。', customProps: { icon: , }, @@ -263,7 +262,7 @@ _Logto に対するより高度な制御やプログラムによるアクセス type: 'link', label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', - description: '開発者のためのアプリのデプロイ、スケーリング、モニタリングを簡素化します。', + description: '開発者向けにアプリのデプロイ・スケーリング・監視を簡素化します。', customProps: { icon: , }, @@ -271,12 +270,16 @@ _Logto に対するより高度な制御やプログラムによるアクセス ]} /> -サードパーティのサービスプロバイダーに対してはカスタマーサポートを提供していないことにご注意ください。私たちのサポートチャネルにアクセスするには、[Logto Cloud](https://cloud.logto.io) にデプロイしてください。ありがとうございます! +サードパーティサービスプロバイダーに関するカスタマーサポートは提供していません。サポートチャネルをご利用の場合は、[Logto Cloud](https://cloud.logto.io) でデプロイしてください。ご了承ください。 + +## アカウント作成 \{#create-an-account} -## アカウントを作成する \{#create-an-account} +Logto のホスティングが完了したら、ウェルカムページで「アカウント作成」をクリックしてください。オープンソース版 Logto では、初回起動時に 1 アカウントのみ作成可能で、複数アカウントには対応していません。アカウント作成はユーザー名とパスワードの組み合わせのみとなります。 -Logto をサーバーに正常にホスティングしたら、ウェルカムページで「アカウントを作成」をクリックしてください。Logto のオープンソースバージョンでは、初回起動時に 1 つのアカウント作成のみが許可されており、複数のアカウントはサポートされていません。アカウント作成プロセスは、ユーザー名とパスワードの組み合わせに限定されています。 +:::tip +Logto OSS(セルフホスト)は複数管理者の設定に対応していません。チームでの共同作業や複数管理者が必要なプロジェクトには、チーム管理機能が充実した [Logto Cloud](https://cloud.logto.io) のご利用をおすすめします。 +::: ## 関連リソース \{#related-resources} -ローカル HTTPS 開発の対処法 +ローカル HTTPS 開発への対応 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index bd93c73f931..d0009a05190 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot は、Java プログラミング言語を使用して、安全で高速かつスケーラブルなサーバーアプリケーションを構築するための Java 用 Web フレームワークです。 + description: Spring Boot は、Java プログラミング言語で安全で高速かつスケーラブルなサーバーアプリケーションを構築できる Java 用の Web フレームワークです。 logoFilename: 'spring-boot.svg' --- @@ -20,22 +20,22 @@ import ScopesAndClaims from './_scopes-and-claims.mdx'; :::tip -- このガイドのサンプルコードは、 [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub リポジトリで見つけることができます。 -- Java Spring Boot アプリケーションに Logto を統合するために公式 SDK は必要ありません。 [Spring Security](https://spring.io/projects/spring-security) と [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) ライブラリを使用して、Logto との OIDC 認証フローを処理します。 +- このガイドのサンプルコードは [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub リポジトリで確認できます。 +- Java Spring Boot アプリケーションに Logto を統合するために公式 SDK は必要ありません。[Spring Security](https://spring.io/projects/spring-security) および [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) ライブラリを使用して、Logto との OIDC 認証 (Authentication) フローを処理します。 ::: ## 前提条件 \{#prerequisites} -- [Logto Cloud](https://cloud.logto.io) アカウントまたは [セルフホスト Logto](/introduction/set-up-logto-oss)。 -- サンプルコードは Spring Boot の [securing web starter](https://spring.io/guides/gs/securing-web) を使用して作成されました。まだ Web アプリケーションを持っていない場合は、指示に従って新しい Web アプリケーションをブートストラップしてください。 -- このガイドでは、 [Spring Security](https://spring.io/projects/spring-security) と [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) ライブラリを使用して Logto との OIDC 認証フローを処理します。概念を理解するために公式ドキュメントを確認してください。 +- [Logto Cloud](https://cloud.logto.io) アカウント、または [セルフホスト Logto](/introduction/set-up-logto-oss)。 +- サンプルコードは Spring Boot の [securing web starter](https://spring.io/guides/gs/securing-web) を使って作成されています。まだ Web アプリケーションがない場合は、手順に従って新規作成してください。 +- このガイドでは、[Spring Security](https://spring.io/projects/spring-security) および [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) ライブラリを使って Logto との OIDC 認証 (Authentication) フローを処理します。公式ドキュメントを参照し、各概念を理解しておきましょう。 ## Java Spring Boot アプリケーションの設定 \{#configure-your-java-spring-boot-application} ### 依存関係の追加 \{#adding-dependencies} -[gradle](https://spring.io/guides/gs/gradle) ユーザーの場合、次の依存関係を `build.gradle` ファイルに追加します: +[gradle](https://spring.io/guides/gs/gradle) ユーザーの場合、`build.gradle` ファイルに次の依存関係を追加します: ```groovy title="build.gradle" dependencies { @@ -46,7 +46,7 @@ dependencies { } ``` -[maven](https://spring.io/guides/gs/maven) ユーザーの場合、次の依存関係を `pom.xml` ファイルに追加します: +[maven](https://spring.io/guides/gs/maven) ユーザーの場合、`pom.xml` ファイルに次の依存関係を追加します: ```xml title="pom.xml" @@ -69,9 +69,9 @@ dependencies { ### OAuth2 クライアント設定 \{#oauth2-client-configuration} -Logto コンソールで新しい `Java Spring Boot` アプリケーションを登録し、Web アプリケーションのクライアント資格情報と IdP 設定を取得します。 +Logto コンソールで新しい `Java Spring Boot` アプリケーションを登録し、Web アプリケーション用のクライアントクレデンシャルと IdP 設定を取得します。 -次の設定を `application.properties` ファイルに追加します: +`application.properties` ファイルに次の設定を追加します: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.client-name=logto @@ -91,15 +91,15 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc -ユーザーがサインイン後にアプリケーションに戻るために、前のステップで `client.registration.logto.redirect-uri` プロパティを使用してリダイレクト URI を設定する必要があります。 +サインイン後にユーザーをアプリケーションへリダイレクトするため、前述の `client.registration.logto.redirect-uri` プロパティでリダイレクト URI を設定してください。 - + ### WebSecurityConfig の実装 \{#implement-the-websecurityconfig} -#### プロジェクトに新しいクラス `WebSecurityConfig` を作成する \{#create-a-new-class-websecurityconfig-in-your-project} +#### プロジェクトに新しいクラス `WebSecurityConfig` を作成 \{#create-a-new-class-websecurityconfig-in-your-project} -`WebSecurityConfig` クラスは、アプリケーションのセキュリティ設定を構成するために使用されます。これは、認証 (Authentication) と認可 (Authorization) フローを処理するキーとなるクラスです。詳細については、 [Spring Security ドキュメント](https://spring.io/guides/topicals/spring-security-architecture) を確認してください。 +`WebSecurityConfig` クラスは、アプリケーションのセキュリティ設定を構成するために使用します。認証 (Authentication) と認可 (Authorization) フローを処理する主要なクラスです。詳細は [Spring Security ドキュメント](https://spring.io/guides/topicals/spring-security-architecture) を参照してください。 ```java title="WebSecurityConfig.java" package com.example.securingweb; @@ -115,9 +115,9 @@ public class WebSecurityConfig { } ``` -#### idTokenDecoderFactory ビーンを作成する \{#create-a-idtokendecoderfactory-bean} +#### `idTokenDecoderFactory` ビーンの作成 \{#create-a-idtokendecoderfactory-bean} -Logto はデフォルトで `ES384` を使用するため、同じアルゴリズムを使用するようにデフォルトの `OidcIdTokenDecoderFactory` を上書きする必要があります。 +Logto はデフォルトで `ES384` アルゴリズムを使用するため、デフォルトの `OidcIdTokenDecoderFactory` を上書きして同じアルゴリズムを使う必要があります。 ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -138,9 +138,9 @@ public class WebSecurityConfig { } ``` -#### ログイン成功イベントを処理するための LoginSuccessHandler クラスを作成する \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} +#### ログイン成功イベントを処理する LoginSuccessHandler クラスの作成 \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} -ログイン成功後、ユーザーを `/user` ページにリダイレクトします。 +ログイン成功後、ユーザーを `/user` ページへリダイレクトします。 ```java title="CustomSuccessHandler.java" package com.example.securingweb; @@ -163,9 +163,9 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { } ``` -#### ログアウト成功イベントを処理するための LogoutSuccessHandler クラスを作成する \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} +#### ログアウト成功イベントを処理する LogoutSuccessHandler クラスの作成 \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} -セッションをクリアし、ユーザーをホームページにリダイレクトします。 +セッションをクリアし、ユーザーをホームページへリダイレクトします。 ```java title="CustomLogoutHandler.java" package com.example.securingweb; @@ -195,11 +195,11 @@ public class CustomLogoutHandler implements LogoutSuccessHandler { } ``` -#### `securityFilterChain` を使用して `WebSecurityConfig` クラスを更新する \{#update-the-websecurityconfig-class-with-a-securityfilterchain} +#### `WebSecurityConfig` クラスに `securityFilterChain` を追加 \{#update-the-websecurityconfig-class-with-a-securityfilterchain} -[securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) は、受信リクエストとレスポンスを処理する責任を持つフィルタのチェーンです。 +[securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) は、リクエストとレスポンスを処理するフィルターチェーンです。 -`securityFilterChain` を構成して、ホームページへのアクセスを許可し、他のすべてのリクエストには認証 (Authentication) を要求します。ログインとログアウトイベントを処理するために `CustomSuccessHandler` と `CustomLogoutHandler` を使用します。 +`securityFilterChain` を設定し、ホームページへのアクセスを許可し、それ以外のリクエストには認証 (Authentication) を要求します。ログイン・ログアウトイベントの処理には `CustomSuccessHandler` と `CustomLogoutHandler` を使用します。 ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -215,7 +215,7 @@ public class WebSecurityConfig { .authorizeRequests(authorizeRequests -> authorizeRequests .antMatchers("/", "/home").permitAll() // ホームページへのアクセスを許可 - .anyRequest().authenticated() // 他のすべてのリクエストには認証 (Authentication) を要求 + .anyRequest().authenticated() // それ以外は認証 (Authentication) 必須 ) .oauth2Login(oauth2Login -> oauth2Login @@ -230,9 +230,9 @@ public class WebSecurityConfig { } ``` -### ホームページを作成する \{#create-a-home-page} +### ホームページの作成 \{#create-a-home-page} -(プロジェクトにすでにホームページがある場合は、このステップをスキップできます) +(すでにホームページがある場合はこの手順をスキップできます) ```java title="HomeController.java" package com.example.securingweb; @@ -251,17 +251,17 @@ public class HomeController { } ``` -このコントローラーは、ユーザーが認証 (Authentication) されている場合はユーザーページにリダイレクトし、そうでない場合はホームページを表示します。ホームページにサインインリンクを追加します。 +このコントローラーは、ユーザーが認証 (Authentication) 済みならユーザーページへリダイレクトし、そうでなければホームページを表示します。ホームページにサインインリンクを追加します。 ```html title="resources/templates/home.html"

Welcome!

-

Login with Logto

+

Logto でログイン

``` -### ユーザーページを作成する \{#create-a-user-page} +### ユーザーページの作成 \{#create-a-user-page} ユーザーページを処理する新しいコントローラーを作成します: @@ -299,13 +299,13 @@ public class UserController { } ``` -ユーザーが認証 (Authentication) されると、認証されたプリンシパルオブジェクトから `OAuth2User` データを取得します。詳細については、 [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) と [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) を参照してください。 +ユーザーが認証 (Authentication) されると、認証済みプリンシパルオブジェクトから `OAuth2User` データを取得します。詳細は [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) および [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) を参照してください。 -ユーザーデータを読み取り、 `user.html` テンプレートに渡します。 +ユーザーデータを読み取り、`user.html` テンプレートに渡します。 ```html title="resources/templates/user.html" -

User Details

+

ユーザー詳細

name:
@@ -315,38 +315,38 @@ public class UserController {
- +
``` -#### 追加のクレームを要求する \{#request-additional-claims} +#### 追加のクレーム (Claims) をリクエストする \{#request-additional-claims} -追加のユーザー情報を取得するには、 `application.properties` ファイルに追加のスコープを追加できます。例えば、 `email`、 `phone`、および `urn:logto:scope:organizations` スコープを要求するには、次の行を `application.properties` ファイルに追加します: +追加のユーザー情報を取得するには、`application.properties` ファイルにスコープを追加します。たとえば、`email`、`phone`、`urn:logto:scope:organizations` スコープをリクエストする場合、次の行を `application.properties` に追加します: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -その後、 `OAuth2User` オブジェクトで追加のクレームにアクセスできます。 +その後、`OAuth2User` オブジェクトで追加のクレーム (Claims) にアクセスできます。 ### アプリケーションの実行とテスト \{#run-and-test-the-application} -アプリケーションを実行し、 `http://localhost:8080` にアクセスします。 +アプリケーションを実行し、`http://localhost:8080` にアクセスします。 -- サインインリンクがあるホームページが表示されます。 +- サインインリンク付きのホームページが表示されます。 - リンクをクリックして Logto でサインインします。 -- 認証 (Authentication) に成功すると、ユーザーページにリダイレクトされ、ユーザーの詳細が表示されます。 -- ログアウトボタンをクリックしてサインアウトします。ホームページにリダイレクトされます。 +- 認証 (Authentication) に成功すると、ユーザーページにリダイレクトされ、ユーザー情報が表示されます。 +- ログアウトボタンをクリックするとサインアウトし、ホームページに戻ります。 -## スコープとクレーム \{#scopes-and-claims} +## スコープ (Scopes) とクレーム (Claims) \{#scopes-and-claims} -## さらなる読み物 \{#further-readings} +## さらに読む \{#further-readings} diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index 0e3029feeaf..02b861a6928 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -1,33 +1,33 @@ --- id: federated-token-set -title: サードパーティトークンの保存 & API アクセス -sidebar_label: サードパーティトークンの保存 +title: サードパーティートークンの保存 & API アクセス +sidebar_label: サードパーティートークンの保存 --- import Availability from '@components/Availability'; -サードパーティトークンセット(別名:フェデレーテッドトークンセット)は、Logto の [シークレットボールト](/secret-vault) に保存されるシークレットタイプであり、サードパーティのアイデンティティプロバイダーによって発行された アクセス トークン (Access token) および リフレッシュ トークン (Refresh token) を安全に管理するために使用されます。ユーザーがソーシャルまたはエンタープライズシングルサインオン (SSO) コネクター経由で認証 (Authentication) すると、Logto は発行されたトークンをボールトに保存します。これらのトークンは後で取得でき、再認証なしでユーザーの代理としてサードパーティ API にアクセスできます。 +サードパーティートークンセット(別名:フェデレーテッドトークンセット)は、Logto の [シークレットボールト](/secret-vault) に保存されるシークレットタイプであり、サードパーティのアイデンティティプロバイダーによって発行された アクセス トークン (Access token) および リフレッシュ トークン (Refresh token) を安全に管理するために使用されます。ユーザーがソーシャルまたはエンタープライズシングルサインオン (SSO) コネクター経由で認証 (Authentication) すると、Logto は発行されたトークンをボールトに保存します。これらのトークンは後で取得でき、ユーザーに再認証 (Authentication) を求めることなく、ユーザーの代理でサードパーティ API へアクセスできます。 ## 主なユースケース \{#common-use-cases} -この機能は、AI エージェント、SaaS プラットフォーム、生産性ツール、顧客向けアプリケーションなど、ユーザーの代理でサードパーティサービスと連携する必要がある現代的なアプリケーションに不可欠です。実際の例をいくつか紹介します: +この機能は、AI エージェント、SaaS プラットフォーム、生産性ツール、顧客向けアプリケーションなど、ユーザーの代理でサードパーティサービスと連携する必要がある最新アプリケーションに不可欠です。実際の例をいくつか紹介します: -**📅 カレンダー管理アプリ**:ユーザーが Google でサインインした後、生産性アプリが自動的にカレンダーイベントを同期し、新しい会議を作成し、招待状を送信できます。再度認証 (Authentication) を求める必要はありません。 +**📅 カレンダー管理アプリ**:ユーザーが Google でサインインした後、生産性アプリはカレンダーイベントを自動で同期し、新しい会議を作成し、招待を送信できます。再度認証 (Authentication) を求める必要はありません。 -**🤖 AI アシスタント**:AI エージェントがユーザーの GitHub リポジトリにアクセスし、コードを分析したり、プルリクエストを作成したり、課題を管理したりできます。すべてサインインやアカウント連携時の一度きりの同意で実現します。 +**🤖 AI アシスタント**:AI エージェントがユーザーの GitHub リポジトリへアクセスし、コード分析やプルリクエスト作成、課題管理などを行えます。すべてサインインやアカウント連携時の一度きりの同意で実現します。 -**📊 分析ダッシュボード**:SaaS プラットフォームがユーザーの接続済みソーシャルメディアアカウント(Facebook、LinkedIn など)からデータを取得し、ワークフローを中断することなくインサイトやレポートを生成できます。 +**📊 分析ダッシュボード**:SaaS プラットフォームは、ユーザーが接続したソーシャルメディアアカウント(Facebook、LinkedIn など)からデータを取得し、ワークフローを中断することなくインサイトやレポートを生成できます。 -## サードパーティトークンの保存を有効化する \{#enable-third-party-token-storage} +## サードパーティートークンの保存を有効化する \{#enable-third-party-token-storage} ### ソーシャルコネクター \{#social-connectors} -この機能は、トークン保存をサポートする [ソーシャルコネクター](/connectors/social-connectors) で利用できます。サードパーティトークンは、[ソーシャルサインイン](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[ソーシャルアカウント連携](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection)、および [サードパーティ API アクセス用トークンの更新時](/secret-vault/federated-token-set#reauthentication-and-token-renewal) に保存できます。現在サポートされているコネクターは:[GitHub](/integrations/github)、[Google](/integrations/google)、[Facebook](/integrations/facebook)、[標準 OAuth 2.0](/integrations/oauth2)、[標準 OIDC](/integrations/oidc) です。今後、他のコネクターへの対応も順次拡大予定です。 +この機能は、トークン保存をサポートする [ソーシャルコネクター](/connectors/social-connectors) で利用できます。サードパーティートークンは、[ソーシャルサインイン](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[ソーシャルアカウント連携](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection)、および [サードパーティ API アクセス用のトークン更新時](/secret-vault/federated-token-set#reauthentication-and-token-renewal) に保存できます。現在サポートされているコネクターは:[GitHub](/integrations/github)、[Google](/integrations/google)、[Facebook](/integrations/facebook)、[標準 OAuth 2.0](/integrations/oauth2)、[標準 OIDC](/integrations/oidc) です。今後さらに多くのコネクターが順次サポートされます。 1. コンソール > コネクター > ソーシャルコネクター に移動します。 -2. サードパーティトークンの保存を有効にしたいソーシャルコネクターを選択します。 +2. サードパーティートークン保存を有効にしたいソーシャルコネクターを選択します。 3. コネクターのセットアップチュートリアルに従い、特定のサードパーティ API へアクセスするために必要なスコープを追加します。 4. 「設定」ページで **永続的な API アクセスのためにトークンを保存** オプションを有効にします。 @@ -36,7 +36,7 @@ import Availability from '@components/Availability'; トークン保存は、すべての OIDC [エンタープライズコネクター](/connectors/enterprise-connectors) で利用できます。アクセス トークン (Access token) および リフレッシュ トークン (Refresh token) は、[エンタープライズシングルサインオン (SSO)](/end-user-flows/enterprise-sso) 時に保存できます。現在サポートされているコネクターは:[Google Workspace](/integrations/google-workspace)、[Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc)、[Okta](/integrations/okta)、[OIDC (Enterprise)](/integrations/oidc-sso) です。 1. コンソール > エンタープライズ SSO に移動します。 -2. サードパーティトークンの保存を有効にしたいエンタープライズ SSO コネクターを選択します。 +2. サードパーティートークン保存を有効にしたいエンタープライズ SSO コネクターを選択します。 3. コネクターのセットアップチュートリアルに従い、特定のサードパーティ API へアクセスするために必要なスコープを追加します。 4. 「SSO 体験」タブで **永続的な API アクセスのためにトークンを保存** オプションを有効にします。 @@ -44,50 +44,50 @@ import Availability from '@components/Availability'; ## トークンの保存 \{#token-storage} -サードパーティトークンの保存を有効化すると、ユーザーがソーシャルまたはエンタープライズ SSO コネクター経由で認証 (Authentication) するたびに、Logto はフェデレーテッドアイデンティティプロバイダーによって発行された アクセス トークン (Access token) および リフレッシュ トークン (Refresh token) を自動的に保存します。これには以下が含まれます: +サードパーティートークン保存を有効にすると、ユーザーがソーシャルまたはエンタープライズシングルサインオン (SSO) コネクター経由で認証 (Authentication) するたびに、Logto はフェデレーテッドアイデンティティプロバイダーから発行された アクセス トークン (Access token) および リフレッシュ トークン (Refresh token) を自動的に保存します。これには以下が含まれます: - [ソーシャルサインイン・サインアップ](/end-user-flows/sign-up-and-sign-in/social-sign-in) - [エンタープライズ SSO サインイン・サインアップ](/end-user-flows/enterprise-sso) - [アカウント API 経由のソーシャルアカウント連携](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -保存されたトークンはユーザーのソーシャルまたはエンタープライズ SSO アイデンティティに紐づけられ、再認証なしで後から API アクセス用に取得できます。 +保存されたトークンは、ユーザーのソーシャルまたはエンタープライズ SSO アイデンティティに紐付けられ、再認証 (Authentication) を求めることなく後で API アクセス用に取得できます。 ### トークン保存状況の確認 \{#checking-token-storage-status} -Logto コンソールでユーザーのサードパーティトークン保存状況を確認できます: +Logto コンソールでユーザーのサードパーティートークン保存状況を確認できます: 1. コンソール > ユーザー に移動します。 -2. 調べたいユーザーをクリックします。ユーザー詳細ページに移動します。 -3. **接続** セクションまでスクロールします。ここにはユーザーに紐づくすべてのソーシャルおよびエンタープライズ SSO 接続が一覧表示されます。 -4. 各接続エントリには、その接続にトークンが保存されているかどうかを示すトークンステータスラベルが表示されます。 -5. 接続エントリをクリックすると、保存された アクセス トークン (Access token) のメタデータや リフレッシュ トークン (Refresh token) の有無(利用可能な場合)など、詳細を確認できます。 +2. 確認したいユーザーをクリックします。ユーザー詳細ページに移動します。 +3. **接続** セクションまでスクロールします。このエリアには、ユーザーに関連付けられたすべてのソーシャルおよびエンタープライズ SSO 接続が一覧表示されます。 +4. 各接続エントリーには、その接続にトークンが保存されているかどうかを示すトークンステータスラベルが表示されます。 +5. 接続エントリーをクリックすると、保存された アクセス トークン (Access token) のメタデータや リフレッシュ トークン (Refresh token) の有無(利用可能な場合)など、詳細を確認できます。 また、管理 API を通じてユーザーのサードパーティアイデンティティおよびトークン保存状況を確認できます: -- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`:指定したコネクターターゲット(例:`github`、`google` など)に紐づくユーザーのソーシャルアイデンティティとトークン保存状況を取得します。 -- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`:指定した SSO コネクター ID に紐づくユーザーのエンタープライズ SSO アイデンティティとトークン保存状況を取得します。 +- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`:指定したコネクターターゲット(例:`github`、`google` など)でユーザーのソーシャルアイデンティティおよびトークン保存状況を取得します。 +- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`:指定した SSO コネクター ID でユーザーのエンタープライズ SSO アイデンティティおよびトークン保存状況を取得します。 ### トークン保存ステータス \{#token-storage-status} - **アクティブ**:アクセス トークン (Access token) が保存されており有効です。 - **期限切れ**:アクセス トークン (Access token) は保存されていますが、期限切れです。リフレッシュ トークン (Refresh token) が利用可能な場合、新しいアクセス トークン (Access token) を取得できます。 -- **非アクティブ**:この接続にアクセス トークン (Access token) は保存されていません。ユーザーがこの接続で認証 (Authentication) していない場合や、トークン保存が削除された場合に発生します。 +- **非アクティブ**:この接続にアクセス トークン (Access token) が保存されていません。ユーザーがこの接続で認証 (Authentication) していない場合や、トークン保存が削除された場合に発生します。 - **該当なし**:コネクターがトークン保存をサポートしていません。 ### トークンメタデータ \{#token-metadata} -データの整合性とセキュリティのため、すべてのトークンはシークレットボールトに保存される前に暗号化されます。実際のトークン値は、適切な認可 (Authorization) を持つエンドユーザーのみがアクセスできます。開発者は、機密情報を公開せずに保存されたトークンの状態を把握するために、トークンセットのメタデータのみ取得できます。 +データの整合性とセキュリティのため、すべてのトークンはシークレットボールトに保存される前に暗号化されます。実際のトークン値は、適切な認可 (Authorization) を持つエンドユーザーのみがアクセスできます。一方、開発者はトークンセットのメタデータのみを取得でき、機密情報を露出せずに保存されたトークンの状態を把握できます。 -- `createdAt`:接続が初めて確立され、トークンセットがシークレットボールトに保存されたタイムスタンプ。 +- `createdAt`:接続が初めて確立され、トークンセットがシークレットボールトに最初に保存されたタイムスタンプ。 - `updatedAt`:トークンセットが最後に更新された時刻。 - リフレッシュ トークン (Refresh token) がない場合、この値は **createdAt** と同じです。 - リフレッシュ トークン (Refresh token) がある場合、この値はアクセス トークン (Access token) が最後にリフレッシュされた時刻を示します。 - `hasRefreshToken`:リフレッシュ トークン (Refresh token) が利用可能かどうかを示します。 - コネクターがオフラインアクセスをサポートし、認可リクエストが正しく構成されている場合、Logto はアイデンティティプロバイダーから発行されたリフレッシュ トークン (Refresh token) をアクセス トークン (Access token) と一緒に保存します。 - アクセス トークン (Access token) の有効期限が切れ、かつ有効なリフレッシュ トークン (Refresh token) が存在する場合、ユーザーが接続先プロバイダーへのアクセスを要求するたびに、Logto は保存されたリフレッシュ トークン (Refresh token) を使って新しいアクセス トークン (Access token) の取得を自動的に試みます。 + コネクターがオフラインアクセスをサポートし、認可 (Authorization) リクエストが正しく構成されていれば、Logto はアイデンティティプロバイダーから発行されたリフレッシュ トークン (Refresh token) をアクセス トークン (Access token) と一緒に保存します。 + アクセス トークン (Access token) が期限切れで有効なリフレッシュ トークン (Refresh token) が存在する場合、ユーザーが接続先プロバイダーへのアクセスを要求するたびに、Logto は保存されたリフレッシュ トークン (Refresh token) を使って新しいアクセス トークン (Access token) の取得を自動的に試みます。 - `expiresAt`:アクセス トークン (Access token) の推定有効期限(**秒単位**)。 これは、アイデンティティプロバイダーのトークンエンドポイントから返される `expires_in` 値に基づいて計算されます。(このフィールドは、プロバイダーがトークンレスポンスに `expires_in` を含めている場合のみ利用可能です。) -- `scope`:アクセス トークン (Access token) のスコープであり、アイデンティティプロバイダーによって付与された権限 (Permissions) を示します。 +- `scope`:アクセス トークン (Access token) のスコープであり、アイデンティティプロバイダーによって付与された 権限 (Permissions) を示します。 保存されたアクセス トークン (Access token) でどのような操作が可能かを把握するのに役立ちます。(このフィールドは、プロバイダーがトークンレスポンスに `scope` を含めている場合のみ利用可能です。) - `tokenType`:アクセス トークン (Access token) のタイプ。通常は "Bearer" です。 (このフィールドは、プロバイダーがトークンレスポンスに `token_type` を含めている場合のみ利用可能です。) @@ -101,46 +101,46 @@ Logto コンソールでユーザーのサードパーティトークン保存 - `GET /my-account/sso-identities/:connectorId/access-token`:コネクター ID を指定してエンタープライズ SSO アイデンティティのアクセス トークン (Access token) を取得します。 :::info -Logto 発行のアクセス トークン (Access token) を使って [アカウント API を有効化](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) および [アクセス](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) する方法を学べます。 +サードパーティのアクセス トークン (Access token) を取得するには、まずエンドユーザー向けにアカウント API を有効化する必要があります。コンソール > サインイン & アカウント > アカウントセンター で設定できます。[アカウント API の有効化方法](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) および [Logto 発行のアクセス トークン (Access token) でのアクセス方法](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) もご覧ください。 ::: ### トークンローテーション \{#token-rotation} -トークン取得エンドポイントは以下を返します: +トークン取得エンドポイントは以下のレスポンスを返します: -- `200` OK:アクセス トークン (Access token) の取得に成功し、かつ有効な場合。 -- `404` Not Found:指定したターゲットまたはコネクター ID に紐づくソーシャルまたはエンタープライズ SSO アイデンティティが存在しない場合、またはアクセス トークン (Access token) が保存されていない場合。 -- `401` Unauthorized:アクセス トークン (Access token) の有効期限が切れている場合。 +- `200` OK:アクセス トークン (Access token) の取得に成功し、まだ有効な場合。 +- `404` Not Found:指定したターゲットまたはコネクター ID に紐付くソーシャルまたはエンタープライズ SSO アイデンティティが存在しない場合、またはアクセス トークン (Access token) が保存されていない場合。 +- `401` Unauthorized:アクセス トークン (Access token) が期限切れの場合。 -アクセス トークン (Access token) の有効期限が切れており、リフレッシュ トークン (Refresh token) が利用可能な場合、Logto は自動的にアクセス トークン (Access token) のリフレッシュを試み、新しいアクセス トークン (Access token) をレスポンスで返します。シークレットボールト内のトークン保存も新しいアクセス トークン (Access token) とそのメタデータで更新されます。 +アクセス トークン (Access token) が期限切れでリフレッシュ トークン (Refresh token) が利用可能な場合、Logto は自動的にアクセス トークン (Access token) のリフレッシュを試み、新しいアクセス トークン (Access token) をレスポンスで返します。シークレットボールト内のトークン保存も新しいアクセス トークン (Access token) とそのメタデータで更新されます。 ## トークン保存の削除 \{#token-storage-deletion} -サードパーティトークンの保存は、各ユーザーのソーシャルまたはエンタープライズ SSO 接続に直接紐づいています。つまり、以下の場合に保存されたトークンセットは自動的に削除されます: +サードパーティートークン保存は、各ユーザーのソーシャルまたはエンタープライズ SSO 接続に直接紐付いています。つまり、以下の場合に保存されたトークンセットは自動的に削除されます: -- 関連するソーシャルまたはエンタープライズ SSO アイデンティティがユーザーアカウントから削除された場合。 +- 関連付けられたソーシャルまたはエンタープライズ SSO アイデンティティがユーザーアカウントから削除された場合。 - ユーザーアカウントがテナントから削除された場合。 - ソーシャルまたはエンタープライズ SSO コネクターがテナントから削除された場合。 ### トークンの失効 \{#revoking-tokens} -ユーザーのサードパーティトークンセットを手動で削除し、アクセスを失効させることもできます: +ユーザーのサードパーティートークンセットを手動で削除してアクセスを失効させることもできます: - コンソールから: ユーザーのアイデンティティ詳細ページに移動します。**アクセス トークン (Access token)** セクション(トークン保存が利用可能な場合)までスクロールし、セクション末尾の **トークンを削除** ボタンをクリックします。 - 管理 API 経由: - - `DELETE /api/secret/:id`:ユーザーアイデンティティ詳細から取得できる ID を指定して特定のシークレットを削除します。 + - `DELETE /api/secret/:id`:ユーザーアイデンティティ詳細から取得できる ID で特定のシークレットを削除します。 -トークンセットを失効させると、ユーザーは再度サードパーティプロバイダーで認証 (Authentication) し、新しいアクセス トークン (Access token) を取得する必要があります。 +トークンセットを失効させると、ユーザーは再度サードパーティプロバイダーで認証 (Authentication) し、新しいアクセス トークン (Access token) ) を取得しない限り、サードパーティ API へアクセスできなくなります。 ## 再認証とトークンの更新 \{#reauthentication-and-token-renewal} -保存されたアクセス トークン (Access token) の有効期限が切れた場合や、アプリケーションが追加の API スコープを要求する必要がある場合、エンドユーザーはサードパーティプロバイダーで再認証し、新しいアクセス トークン (Access token) を取得できます—Logto への再サインインは不要です。 +保存されたアクセス トークン (Access token) の有効期限が切れた場合や、アプリケーションが追加の API スコープを要求する必要がある場合、エンドユーザーはサードパーティプロバイダーで再認証 (Authentication) し、新しいアクセス トークン (Access token) を取得できます—Logto への再サインインは不要です。 これは Logto の [ソーシャル認証 API](https://openapi.logto.io/operation/operation-createverificationbysocial) を通じて実現でき、ユーザーはフェデレーテッドソーシャル認可 (Authorization) フローを再開し、保存されたトークンセットを更新できます。 :::note フェデレーテッド認可 (Authorization) の再開は現在ソーシャルコネクターに限定されています。 -エンタープライズ SSO コネクターの場合、再認証とトークンの更新にはユーザーが再度 Logto の認証 (Authentication) フロー全体を開始する必要があります。サインイン後のエンタープライズ SSO プロバイダーとの直接再認可 (Authorization) は現在サポートされていません。 +エンタープライズ SSO コネクターの場合、再認証 (Authentication) およびトークンの更新には、ユーザーが再度 Logto の認証 (Authentication) フローを開始する必要があります。サインイン後にエンタープライズ SSO プロバイダーと直接再認可 (Authorization) することは現在サポートされていません。 ::: ```mermaid @@ -154,13 +154,13 @@ sequenceDiagram User->>Logto: post /api/verification/social Logto->>User: サードパーティプロバイダーへリダイレクト User->>Provider: 認証 (Authentication) および認可 (Authorization) - Provider->>User: 認可コード付きでリダイレクトバック - User->>Logto: post /api/verification/social/verify(認可コード付き) - Logto->>User: ソーシャル認証 ID を返却 + Provider->>User: 認可コードでリダイレクトバック + User->>Logto: post /api/verification/social/verify with 認可コード + Logto->>User: ソーシャル認証 ID を返す User->>Logto: patch /my-account/identities/:target/access-token ``` -1. ユーザーは `POST /api/verification/social` エンドポイントを呼び出してソーシャル認証リクエストを開始します。追加の権限 (Permissions) を要求するためにカスタムスコープを指定することもできます。 +1. ユーザーは `POST /api/verification/social` エンドポイントを呼び出してソーシャル認証リクエストを開始します。追加の 権限 (Permissions) を要求するためにカスタムスコープを指定することもできます。 ```sh curl -X POST https:///api/verification/social \ @@ -174,12 +174,12 @@ sequenceDiagram }' ``` - - **authorization header**:Logto によって発行されたユーザーのアクセス トークン (Access token)。 + - **authorization header**:Logto によって発行されたユーザーの アクセス トークン (Access token)。 - **connectorId**:Logto 内のソーシャルコネクター ID。 - - **redirectUri**:認証 (Authentication) 後にユーザーをアプリケーションに戻すための URI。この URI をプロバイダーのアプリケーション設定に登録する必要があります。 - - **scope**:(任意)サードパーティプロバイダーから追加の権限 (Permissions) を要求するためのカスタムスコープ。指定しない場合はコネクターで設定されたデフォルトスコープが使用されます。 + - **redirectUri**:認証 (Authentication) 後にユーザーをアプリケーションへリダイレクトする URI。この URI をプロバイダーのアプリケーション設定に登録する必要があります。 + - **scope**:(オプション)サードパーティプロバイダーから追加の 権限 (Permissions) を要求するためのカスタムスコープ。指定しない場合はコネクターで設定されたデフォルトスコープが使用されます。 -2. Logto は新しいソーシャル認証レコードを作成し、認証 (Authentication) 用の認可 (Authorization) URL とともにソーシャル認証 ID を返します。 +2. Logto は新しいソーシャル認証レコードを作成し、ユーザーをサードパーティプロバイダーへリダイレクトするための認可 (Authorization) URL とともにソーシャル認証 ID を返します。 レスポンス例: @@ -191,11 +191,11 @@ sequenceDiagram } ``` -3. ユーザーを認可 (Authorization) URL へリダイレクトします。ユーザーはサードパーティプロバイダーで認証 (Authentication) し、権限 (Permissions) を付与します。 +3. ユーザーを認可 (Authorization) URL へリダイレクトします。ユーザーはサードパーティプロバイダーで認証 (Authentication) し、 権限 (Permissions) を付与します。 -4. サードパーティプロバイダーは認可コード付きでユーザーをクライアントアプリケーションにリダイレクトします。 +4. サードパーティプロバイダーは認可コードを付与してユーザーをクライアントアプリケーションへリダイレクトします。 -5. 認可 (Authorization) コールバックを処理し、認可コードを Logto の認証エンドポイントに転送します: +5. 認可 (Authorization) コールバックを処理し、認可コードを Logto の認証エンドポイントへ転送します: ```sh curl -X POST https:///api/verification/social/verify \ @@ -210,7 +210,7 @@ sequenceDiagram }' ``` - - **authorization header**:Logto によって発行されたユーザーのアクセス トークン (Access token)。 + - **authorization header**:Logto によって発行されたユーザーの アクセス トークン (Access token)。 - **verificationRecordId**:前のステップで返されたソーシャル認証 ID。 - **connectorData**:認可コードや、コールバック時にサードパーティプロバイダーから返されたその他のデータ。 @@ -218,9 +218,9 @@ sequenceDiagram CSRF 攻撃を防ぐため、`state` パラメーターの検証を忘れないでください。 ::: -6. Logto は認可コードを検証し、サードパーティプロバイダーから新しいアクセス トークン (Access token) およびリフレッシュ トークン (Refresh token) を取得し、レスポンスでソーシャル認証 ID を返します。 +6. Logto は認可コードを検証し、サードパーティプロバイダーから新しい アクセス トークン (Access token) および リフレッシュ トークン (Refresh token) を取得し、レスポンスでソーシャル認証 ID を返します。 -7. 最後に、`PATCH /my-account/identities/:target/access-token` エンドポイントにソーシャル認証 ID を指定して呼び出し、ユーザーのトークン保存を更新します: +7. 最後に、`PATCH /my-account/identities/:target/access-token` エンドポイントにソーシャル認証 ID を指定してユーザーのトークン保存を更新します: ```sh curl -X PATCH https:///my-account/identities//access-token \ @@ -231,9 +231,9 @@ sequenceDiagram }' ``` - - **authorization header**:Logto によって発行されたユーザーのアクセス トークン (Access token)。 + - **authorization header**:Logto によって発行されたユーザーの アクセス トークン (Access token)。 - **socialVerificationId**:前のステップで返された認証済みソーシャル認証レコード ID。 - これにより、Logto のシークレットボールト内のユーザーのトークンセット保存が新しいアクセス トークン (Access token) およびリフレッシュ トークン (Refresh token) で更新され、ユーザーは再度 Logto にサインインすることなくサードパーティ API にアクセスできるようになります。 + これにより、Logto のシークレットボールト内のユーザーのトークンセット保存が新しい アクセス トークン (Access token) および リフレッシュ トークン (Refresh token) で更新され、ユーザーは再度 Logto にサインインすることなくサードパーティ API へアクセスできるようになります。 更新されたアクセス トークン (Access token) が返されます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/ja/docusaurus-plugin-content-docs/current/security/blocklist.md index a80aacb390a..1c2eaf2b60b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -8,29 +8,30 @@ sidebar_position: 3 ## メールブロックリスト {#email-blocklist} -メールブロックリストポリシーでは、アカウント登録の悪用を防ぐためにメールブロックリスト設定をカスタマイズできます。サインアップやアカウント設定で使用されるメールアドレスを監視します。ユーザーがブロックリストルールに違反するメールアドレスでサインアップやリンクを試みた場合、システムはリクエストを拒否し、スパムアカウントの軽減やアカウント全体のセキュリティ向上に役立ちます。 +メールブロックリストポリシーでは、アカウント登録の悪用を防ぐためにメールブロックリスト設定をカスタマイズできます。サインアップやアカウント設定で使用されるメールアドレスを監視します。ユーザーがブロックリストルールに違反するメールアドレスでサインアップまたはリンクしようとした場合、システムはリクエストを拒否し、スパムアカウントの抑制やアカウント全体のセキュリティ向上に役立ちます。 -コンソール > セキュリティ > ブロックリスト でメールブロックリスト設定を構成できます。 +コンソール > セキュリティ > ブロックリスト +でメールブロックリスト設定を構成できます。 ### 使い捨てメールアドレスのブロック {#block-disposable-email-addresses} -これは **クラウド限定** 機能です。有効化すると、システムは提供されたメールアドレスのドメインを既知の使い捨てメールドメインリストと自動的に照合します。ドメインがリストに含まれている場合、リクエストは拒否されます。使い捨てメールドメインのリストは、効果を維持するため定期的に更新されます。 +これは **クラウド限定** の機能です。有効にすると、システムは提供されたメールアドレスのドメインを既知の使い捨てメールドメインリストと自動的に照合します。ドメインがリストに含まれている場合、リクエストは拒否されます。使い捨てメールドメインリストは定期的に更新され、その有効性が維持されます。 ### メールサブアドレッシングのブロック {#block-email-subaddressing} -メールサブアドレッシングでは、ユーザーがプラス記号(+)と追加の文字(例:user+tag@example.com)を付けてメールアドレスのバリエーションを作成できます。この機能は、悪意のあるユーザーによってブロックリスト制限を回避するために悪用される可能性があります。メールサブアドレッシングのブロック機能を有効にすると、サブアドレス形式のメールを利用したサインアップやアカウントリンクの試みはシステムによって拒否されます。 +メールサブアドレッシングでは、ユーザーがプラス記号(+)と追加の文字(例:user+tag@example.com)を使ってメールアドレスのバリエーションを作成できます。この機能は、悪意のあるユーザーによってブロックリスト制限を回避するために悪用される可能性があります。メールサブアドレッシングのブロック機能を有効にすると、サブアドレス形式のメールを利用したサインアップやアカウントリンクの試みはシステムによって拒否されます。 ### カスタムメールブロックリスト {#custom-email-blocklist} ブロックしたいメールアドレスやドメインのリストを指定することで、カスタムメールブロックリストを作成できます。これらのエントリに一致するサインアップやアカウントリンクの試みはシステムによって拒否されます。ブロックリストは、完全なメールアドレスとドメインの両方の一致をサポートしています。 -例えば、`@example.com` をブロックリストに追加すると、そのドメインのすべてのメールアドレスがブロックされます。同様に、`foo@example.com` を追加すると、そのメールアドレスのみがブロックされます。 +例えば、`@example.com` をブロックリストに追加すると、そのドメインのすべてのメールアドレスがブロックされます。同様に、`foo@example.com` を追加すると、そのメールアドレスのみが特定してブロックされます。 :::note -使い捨てメール、サブアドレッシング、カスタムメールは、登録およびアカウントリンク時に制限されます。これらのメールアドレスを持つ既存ユーザーは引き続きサインインできます。 +使い捨てメール、サブアドレッシング、カスタムメールは、[新規ユーザー登録](/end-user-flows/sign-up-and-sign-in/sign-up)、[ソーシャルサインイン時のメールリンク](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers)、[Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email) 経由でのメール更新時に制限されます。これらのメールアドレスを持つ既存ユーザーは引き続きサインインできます。 -- 管理者は コンソール > ユーザー管理 で手動でユーザーを追加したり、[Management API](https://openapi.logto.io/operation/operation-createuser) を利用することで「制限をバイパス」できます。例:サブアドレスメールがブロックされている場合でも、そのメールでユーザーを作成可能。 +- 管理者は コンソール > ユーザー管理 で手動でユーザーを追加したり、[Management API](https://openapi.logto.io/operation/operation-createuser) を利用することで「制限をバイパス」できます。例:サブアドレスメールがブロックされている場合でも、そのメールでユーザーを作成可能です。 - 既存アカウントをブロックするには、コンソール > ユーザー管理 で削除または停止してください。 ::: diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/security/password-policy.mdx index ebfbc11258b..fc76aa95c78 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,9 +6,16 @@ sidebar_position: 1 # パスワードポリシー +Logto では、パスワードの作成や更新方法に応じてパスワードポリシーの適用方法が異なります: + +- [標準のサインイン体験](/end-user-flows/sign-up-and-sign-in/sign-up)、[体験 API](/customization/bring-your-ui)、[Account API](/end-user-flows/account-settings/by-account-api#update-users-password) などのエンドユーザーフローでは、常に現在の [パスワードポリシー](#set-up-password-policy) が適用されます。 +- 管理者が Management API の [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) を通じて操作する場合は例外となり、必要に応じてポリシーチェックなしで資格情報のプロビジョニングやリセットが可能です。 +- 既存のパスワードが現在のルールに準拠しているか監査するには、[`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) を呼び出し、返されたバリデーション結果に基づいて対応します。詳細は [パスワード準拠チェック](#password-compliance-check) をご覧ください。 + ## パスワードポリシーの設定 \{#set-up-password-policy} -新規ユーザーやパスワードを更新するユーザーに対して、パスワードの強度要件を強制するためのパスワードポリシーを設定できます。 コンソール > セキュリティ > パスワードポリシー でパスワードポリシーの設定を行ってください。 +新規ユーザーやパスワードを更新するユーザーに対して、パスワードの強度要件を強制するためのパスワードポリシーを設定できます。 コンソール > セキュリティ > パスワードポリシー +でパスワードポリシーの設定を行ってください。 1. **最小パスワード長**:パスワードに必要な最小文字数を設定します。(NIST は少なくとも 8 [文字](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5) を推奨しています) 2. **必要な文字種の最小数**:パスワードに必要な文字種の最小数を設定します。利用可能な文字種は以下の通りです: @@ -16,17 +23,20 @@ sidebar_position: 1 2. 小文字:`(a-z)` 3. 数字:`(0-9)` 4. 記号:``(!"#$%&'()\*+,-./:;<>=?@[]^\_`|{}~ )`` -3. **漏洩履歴チェック**:この設定を有効にすると、過去にデータ漏洩で公開されたパスワードを拒否します。( [Have I Been Pwned](https://haveibeenpwned.com/Passwords) により提供) +3. **漏洩履歴チェック**:この設定を有効にすると、過去にデータ漏洩で公開されたパスワードを拒否します。([Have I Been Pwned](https://haveibeenpwned.com/Passwords) により提供) 4. **繰り返しチェック**:この設定を有効にすると、同じ文字が繰り返されているパスワードを拒否します。(例:「11111111」や「password123」など) 5. **ユーザー情報チェック**:この設定を有効にすると、ユーザー名、メールアドレス、電話番号などのユーザー情報を含むパスワードを拒否します。 -6. **カスタムワード**:パスワードに含めたくないカスタムワード(大文字・小文字を区別しない)のリストを指定できます。 +6. **カスタムワード**:パスワードに含めたくないカスタムワード(大文字小文字を区別しない)をリストで指定できます。 ## パスワード準拠チェック \{#password-compliance-check} -Logto でパスワードポリシーを更新した後も、既存ユーザーは現在のパスワードでサインインできます。新しく作成されたアカウントのみが、更新されたポリシーに従う必要があります。 +Logto でパスワードポリシーを更新した後も、既存ユーザーは現在のパスワードでサインインできます。新規作成されたアカウントのみが更新されたポリシーに従う必要があります。 -より強力なセキュリティを強制するために、`POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) を利用して、ユーザーのパスワードがデフォルトのサインイン体験で定義された現在のポリシーを満たしているかどうかを確認できます。満たしていない場合は、 [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) を使ったカスタムフローでユーザーにパスワードの更新を促すことができます。 +より強力なセキュリティを実現するために、`POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) を利用して、ユーザーのパスワードがデフォルトのサインイン体験で定義された現在のポリシーを満たしているか確認できます。満たしていない場合は、[Account API](/end-user-flows/account-settings/by-account-api) を使ったカスタムフローでパスワードの更新を促すことができます。 ## 関連リソース \{#related-resources} +ユーザー管理 +サインアップ / サインイン +Account API によるアカウント設定 パスワードポリシーの設計 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index 469693ce4ab..af5e216d703 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -4,61 +4,67 @@ sidebar_position: 2 # ユーザー管理 -## Logto コンソールで管理する \{#manage-via-logto-console} +## Logto Console で管理する \{#manage-via-logto-console} ### ユーザーの閲覧と検索 \{#browse-and-search-users} -Logto コンソールでユーザー管理機能にアクセスするには、コンソール > ユーザー管理 -に移動します。そこでは、すべてのユーザーのテーブルビューが表示されます。 +Logto Console でユーザー管理機能にアクセスするには、コンソール > ユーザー管理 に移動します。そこでは、すべてのユーザーのテーブルビューが表示されます。 -テーブルは 3 つのカラムで構成されています: +テーブルは 3 列で構成されています: -- **ユーザー**:ユーザーのアバター、氏名、ユーザー名、電話番号、メールアドレスなどの情報を表示します +- **ユーザー**:アバター、氏名、ユーザー名、電話番号、メールアドレスなど、ユーザーに関する情報を表示します - **アプリケーションから**:ユーザーが最初に登録したアプリケーション名を表示します -- **最新のサインイン**:ユーザーの直近のサインイン時刻を表示します。 +- **最新のサインイン**:ユーザーの最新サインインのタイムスタンプを表示します。 -[`name`](/user-management/user-data#name)、[`id`](/user-management/user-data#id)、[`username`](/user-management/user-data#username)、[`primary-phone`](/user-management/user-data#primary_phone)、[`primary-email`](/user-management/user-data#primary_email) のキーワードマッピングに対応しています。 +キーワードマッピングは、[`name`](/user-management/user-data#name)、[`id`](/user-management/user-data#id)、[`username`](/user-management/user-data#username)、[`primary-phone`](/user-management/user-data#primary_phone)、[`primary-email`](/user-management/user-data#primary_email) に対応しています。 ### ユーザーの追加 \{#add-users} -コンソールを使って、開発者はエンドユーザーの新しいアカウントを作成できます。そのためには、画面右上の「ユーザー追加」ボタンをクリックします。 +Console を使用して、開発者はエンドユーザーの新しいアカウントを作成できます。画面右上の「ユーザー追加」ボタンをクリックしてください。 -Logto コンソールまたは Management API でユーザーを作成する場合(UI からのエンドユーザー自身による登録ではない場合)、少なくとも 1 つの識別子(`primary email`、`primary phone`、`username`)を指定する必要があります。`name` フィールドは任意です。 +Logto Console または Management API でユーザーを作成する場合(UI からのエンドユーザー自身による登録ではない場合)、少なくとも 1 つの識別子(`primary email`、`primary phone`、または `username`)を指定する必要があります。`name` フィールドは任意です。 ユーザー作成後、Logto は自動的にランダムなパスワードを生成します。初期パスワードは一度だけ表示されますが、後から [パスワードをリセット](./manage-users#reset-user-password) できます。特定のパスワードを設定したい場合は、Management API の `patch /api/users/{userId}/password` を使ってユーザー作成後に更新してください。 -**入力した識別子(メールアドレス / 電話番号 / ユーザー名)** と **初期パスワード** はワンクリックでコピーでき、新しいユーザーにこれらの認証情報を簡単に共有してサインイン・利用開始できます。 +**入力した識別子(メールアドレス / 電話番号 / ユーザー名)** と **初期パスワード** はワンクリックでコピーでき、新しいユーザーにこれらの認証情報を簡単に共有してサインインを開始できます。 :::tip -招待制登録を実装したい場合は、[マジックリンクでユーザーを招待する](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended) 方法を推奨します。これにより、ホワイトリストに登録されたユーザーのみが自己登録し、自分のパスワードを設定できます。 +招待制登録を実装したい場合は、[マジックリンクでユーザーを招待](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended) する方法を推奨します。これにより、ホワイトリストに登録されたユーザーのみが自己登録し、自分でパスワードを設定できます。 ::: ### ユーザープロファイルの閲覧と更新 \{#view-and-update-the-user-profile} -ユーザーの詳細を表示するには、ユーザーテーブルの該当行をクリックします。これにより「**ユーザー詳細**」ページに移動し、ユーザーのプロファイル情報を確認できます。内容は以下の通りです: +ユーザーの詳細を表示するには、ユーザーテーブルの該当行をクリックしてください。「**ユーザー詳細**」ページに移動し、ユーザーのプロファイル情報を確認できます。内容は以下の通りです: - **認証 (Authentication) 関連データ**: - **メールアドレス**([primary_email](/user-management/user-data#primary_email)):編集可能 - **電話番号**([primary_phone](/user-management/user-data#primary_phone)):編集可能 - **ユーザー名**([username](/user-management/user-data#username)):編集可能 - **パスワード**([has_password](/user-management/user-data#has_password)):ランダムパスワードを再生成できます。「[ユーザーパスワードのリセット](#reset-user-password)」を参照してください。 - - **ソーシャル連携**([identities](/user-management/user-data#social-identities)):連携済みのソーシャルアカウントやソーシャル ID を表示します。たとえば、Facebook アカウントでサインインした場合、「Facebook」項目がリストに表示されます。コンソールで連携済みソーシャル ID を削除できますが、新しい連携を代理で追加することはできません。 - - **エンタープライズシングルサインオン (SSO) 連携**([sso_identities](/user-management/user-data#sso-identities)):連携済みのエンタープライズ ID を表示します。コンソールで SSO ID の追加や削除はできません。 - - **多要素認証 (MFA)**([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)):このユーザーが設定したすべての認証要素(パスキー、認証アプリ、バックアップコードなど)を表示します。要素はコンソールで削除できます。 + - **多要素認証 (MFA)**([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)):このユーザーが設定したすべての認証要素(パスキー、認証アプリ、バックアップコードなど)を表示できます。要素は Console で削除可能です。 - **パーソナルアクセストークン**:[パーソナルアクセストークン](/user-management/personal-access-token) の作成、表示、名前変更、削除ができます。 -- **ユーザープロファイルデータ**:名前、アバター URL、カスタムデータ、その他 OpenID Connect 標準クレーム(未含分)。これらのプロファイル項目はすべて編集可能です。 +- **接続**: + - **ソーシャル接続**([identities](/user-management/user-data#social-identities)): + - ユーザーが連携しているソーシャルアカウント(ソーシャル ID やプロファイル情報)を表示します(例:Facebook でサインインした場合は「Facebook」エントリが表示されます)。 + - 既存のソーシャル ID は削除できますが、ユーザーの代わりに新しいソーシャルアカウントを連携することはできません。 + - [トークン保存](/secret-vault/federated-token-set) が有効なソーシャルコネクターの場合、接続詳細ページでアクセス トークンおよびリフレッシュ トークンを表示・管理できます。 + - **エンタープライズ SSO 接続**([sso_identities](/user-management/user-data#sso-identities)): + - ユーザーが連携しているエンタープライズ ID やプロファイル情報を表示します。 + - Console でエンタープライズ SSO ID の追加や削除はできません。 + - OIDC ベースのエンタープライズコネクターで [トークン保存](/secret-vault/federated-token-set) が有効な場合、接続詳細ページでトークンの表示・削除が可能です。 +- **ユーザープロファイルデータ**:名前、アバター URL、カスタムデータ、および追加の OpenID Connect 標準クレーム(未含分)。これらのプロファイル項目はすべて編集可能です。 :::warning -ソーシャル連携を削除する前に、ユーザーが他のサインイン方法(別のソーシャル連携、電話番号、メールアドレス、ユーザー名+パスワードなど)を持っていることを必ず確認してください。他のサインイン方法がない場合、ソーシャル連携を削除するとアカウントに再度アクセスできなくなります。 +ソーシャル接続を削除する前に、他のサインイン方法(別のソーシャル接続、電話番号、メールアドレス、ユーザー名+パスワードなど)があることを必ず確認してください。他のサインイン方法がない場合、ソーシャル接続を削除するとアカウントに再度アクセスできなくなります。 ::: ### ユーザーアクティビティの閲覧 \{#view-user-activities} -ユーザーの最近のアクティビティを確認するには、「ユーザー詳細」ページの「ユーザーログ」サブタブに移動します。ここでは、ユーザーが行ったアクション、結果、関連アプリケーション、実行時刻などがテーブルで表示されます。 +ユーザーの最近のアクティビティを確認するには、「ユーザー詳細」ページの「ユーザーログ」サブタブに移動します。ここでは、ユーザーが行った操作、結果、関連アプリケーション、操作時刻などが表示されます。 テーブル行をクリックすると、ユーザーログの詳細(IP アドレス、ユーザーエージェント、生データなど)を確認できます。 @@ -66,25 +72,31 @@ Logto コンソールまたは Management API でユーザーを作成する場 「ユーザー詳細」ページで「三点リーダー」→「ユーザーを一時停止」ボタンをクリックします。 -ユーザーが一時停止されると、そのユーザーはアプリにサインインできなくなり、現在のアクセストークンの有効期限後は新しいアクセストークンも取得できません。また、このユーザーによる API リクエストも失敗します。 +ユーザーが一時停止されると、アプリへのサインインができなくなり、現在のアクセス トークンの有効期限が切れた後は新しいアクセス トークンを取得できません。また、このユーザーによる API リクエストも失敗します。 このユーザーを再有効化したい場合は、「三点リーダー」→「ユーザーを再有効化」ボタンをクリックしてください。 ### ユーザーの削除 \{#delete-user} -「ユーザー詳細」ページで「三点リーダー」→「削除」ボタンをクリックします。ユーザーの削除は元に戻せません。 +「ユーザー詳細」ページで「三点リーダー」→「削除」ボタンをクリックします。ユーザー削除は元に戻せません。 ### ユーザーパスワードのリセット \{#reset-user-password} 「ユーザー詳細」ページで「三点リーダー」→「パスワードをリセット」ボタンをクリックすると、Logto が自動的にランダムなパスワードを再生成します。 -パスワードをリセットした後は、そのパスワードをコピーしてエンドユーザーに送信してください。「パスワードリセット」モーダルを閉じるとパスワードは再表示できません。控え忘れた場合は再度リセットできます。 +パスワードをリセットした後は、そのパスワードをコピーしてエンドユーザーに送信してください。「パスワードをリセット」モーダルを閉じるとパスワードは再表示できません。控え忘れた場合は再度リセットできます。 -Logto コンソールではユーザーの特定パスワードを設定できませんが、[Management API](/integrate-logto/interact-with-management-api) の `PATCH /api/users/{userId}/password` を使って指定できます。 +Logto Console でユーザーに特定のパスワードを設定することはできませんが、[Management API](/integrate-logto/interact-with-management-api) の `PATCH /api/users/{userId}/password` を使って指定できます。 + +## パスワードコンプライアンスチェック \{#password-compliance-check} + +Logto で [パスワードポリシー](/security/password-policy) を更新した後も、既存ユーザーは現在のパスワードでサインインできます。新規作成アカウントのみが更新後のパスワードポリシーに従う必要があります。 + +より強力なセキュリティを強制するには、`POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) を使って、ユーザーのパスワードがデフォルトのサインイン体験で定義された現在のポリシーに適合しているか確認できます。適合していない場合は、[Account API](/end-user-flows/account-settings/by-management-api#user-password-management) を使ったカスタムフローでパスワード更新を促すことができます。 ### ユーザーのロール管理 \{#manage-roles-of-users} -ユーザー詳細ページの「ロール」タブで、ロールの割り当てや削除が簡単にできます。詳細は [ロールベースのアクセス制御 (RBAC)](/authorization/role-based-access-control) を参照してください。 +ユーザー詳細ページの「ロール」タブで、ロールの割り当てや削除が簡単にできます。詳細は [ロールベースのアクセス制御](/authorization/role-based-access-control) を参照してください。 ### ユーザーが所属する組織の確認 \{#view-the-organizations-the-user-belongs-to} @@ -92,11 +104,11 @@ Logto は [組織](/organizations/organization-management) をサポートして ## Logto Management API で管理する \{#manage-via-logto-management-api} -[Management API](/concepts/core-service/#management-api) は、Logto バックエンドサービスへのアクセスを提供する API 群です。前述の通り、ユーザー API はこのサービスの重要なコンポーネントであり、幅広いシナリオに対応できます。 +[Management API](/concepts/core-service/#management-api) は、Logto バックエンドサービスへのアクセスを提供する API 群です。前述の通り、ユーザー API はこのサービスの重要なコンポーネントであり、さまざまなシナリオに対応できます。 ユーザー関連の [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API は `/api/users` にマウントされています(ユーザーアクティビティ、すなわちユーザーログ `/api/logs?userId=:userId` を除く)。 -Management API を通じて、[高度なユーザー検索](/user-management/advanced-user-search)、[アカウントの一括作成](https://openapi.logto.io/operation/operation-createuser)、[招待制サインアップ](/end-user-flows/sign-up-and-sign-in/disable-user-registration) など、さまざまな用途でユーザー管理が可能です。 +Management API を使って、[高度なユーザー検索](/user-management/advanced-user-search)、[アカウントの一括作成](https://openapi.logto.io/operation/operation-createuser)、[招待制サインアップ](/end-user-flows/sign-up-and-sign-in/disable-user-registration) など、さまざまな用途でユーザー管理が可能です。 ## よくある質問 \{#faqs} @@ -108,8 +120,8 @@ Management API を通じて、[高度なユーザー検索](/user-management/adv -Logto の [Omni-sign-in](https://logto.io/products/omni-sign-in) の性質上、認証 (Authentication) 前に特定のアプリケーションへのユーザーアクセスを制限する設計にはなっていません。 -ただし、アプリケーション固有のユーザーロールや権限を設計し、API リソースを保護し、ユーザーサインイン後に API アクセス時に権限を検証することは可能です。 -詳細は認可 (Authorization):[ロールベースのアクセス制御 (RBAC)](/authorization/role-based-access-control) を参照してください。 +Logto の [Omni-sign-in](https://logto.io/products/omni-sign-in) の特性上、認証 (Authentication) 前に特定のアプリケーションへのユーザーアクセスを制限する設計にはなっていません。 +ただし、アプリケーション固有のユーザーロールや権限を設計し、API リソースを保護することは可能です。ユーザーがサインインした後、API アクセス時に権限を検証してください。 +詳細は認可 (Authorization):[ロールベースのアクセス制御](/authorization/role-based-access-control) を参照してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index 523c980f318..727870de1e3 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -12,11 +12,11 @@ sidebar_position: 1 これは次の種類のデータで構成されています: -- [基本データ](/user-management/user-data#basic-data):ユーザープロファイルからの基本情報です。ソーシャル `identities` および `custom_data` を除くすべての _ユーザー_ のプロパティ(ユーザー ID、ユーザー名、メールアドレス、電話番号、最終サインイン日時など)を保存します。 -- [ソーシャルアイデンティティ](/user-management/user-data#social-identities):Facebook、GitHub、WeChat などのソーシャルコネクターによるサインインから取得したユーザー情報を保存します。 -- [カスタムデータ](/user-management/user-data#custom-data):ユーザーが好む色や言語など、事前定義されたユーザープロパティに含まれていない追加情報を保存します。 +- [基本データ](/user-management/user-data#basic-data):ユーザープロファイルからの基本情報です。ユーザー ID、ユーザー名、メールアドレス、電話番号、最終サインイン日時など、ソーシャル `identities` および `custom_data` を除くすべての _ユーザー_ のプロパティを格納します。 +- [ソーシャルアイデンティティ](/user-management/user-data#social-identities):Facebook、GitHub、WeChat などのソーシャルコネクターによるサインインから取得したユーザー情報を格納します。 +- [カスタムデータ](/user-management/user-data#custom-data):ユーザーが好む色や言語など、事前定義されたユーザープロパティに含まれていない追加情報を格納します。 -以下は Facebook でサインインしたユーザーから取得したデータのサンプルです: +以下は Facebook でサインインした際に取得されるユーザーデータのサンプルです: ```json { @@ -62,7 +62,7 @@ _id_ は Logto 内でユーザーを識別するための一意な自動生成 _username_ は _ユーザー名_ とパスワードによるサインインに使用されます。 -値はユーザーが最初に登録したユーザー名から取得されます。`null` の場合もあります。非 null の場合は 128 文字以内で、英数字とアンダースコア(`_`)のみを含み、数字で始まってはいけません。大文字小文字は区別されます。 +値はユーザーが最初に登録したユーザー名から取得されます。`null` の場合もあります。非 null の場合、128 文字以内で、英数字とアンダースコア(`_`)のみを含み、数字で始まってはいけません。大文字小文字は区別されます。 ### primary_email \{#primary_email} @@ -70,11 +70,15 @@ _primary_email_ はユーザーのメールアドレスで、メールアドレ 値は通常、ユーザーが最初に登録したメールアドレスから取得されます。`null` の場合もあります。最大長は 128 です。 +ソーシャルまたはエンタープライズ SSO アイデンティティプロバイダーからの認証済みメールアドレスのみが `primary_email` として同期・保存されます。 + ### primary_phone \{#primary_phone} -_primary_phone_ はユーザーの電話番号で、電話番号とパスワード / SMS の認証コードによるサインインに使用されます。 +_primary_phone_ はユーザーの電話番号で、電話番号とパスワード / SMS 認証コードによるサインインに使用されます。 + +値は通常、ユーザーが最初に登録した電話番号から取得されます。`null` の場合もあります。非 null の場合、 [国番号](https://en.wikipedia.org/wiki/List_of_country_calling_codes)(プラス記号 `+` を除く)で始まる数字を含む必要があります。 -値は通常、ユーザーが最初に登録した電話番号から取得されます。`null` の場合もあります。非 null の場合は [国番号](https://en.wikipedia.org/wiki/List_of_country_calling_codes)(プラス記号 `+` を除く)で始まる数字を含む必要があります。 +ソーシャルまたはエンタープライズ SSO アイデンティティプロバイダーからの認証済み電話番号のみが `primary_phone` として同期・保存されます。 ### name \{#name} @@ -84,19 +88,19 @@ _name_ はユーザーのフルネームです。最大長は 128 です。 _avatar_ はユーザーのアバター画像を指す URL です。最大長は 2048 です。 -Google や Facebook などのソーシャルコネクターで登録した場合、その値はソーシャルユーザー情報から取得されることがあります。 +ユーザーが Google や Facebook などのソーシャルコネクターで登録した場合、その値はソーシャルユーザー情報から取得されることがあります。 :::note -このプロパティは [OpenID Connect](https://openid.net/connect/) 標準の `picture` クレーム (Claim) にマッピングされます。 +このプロパティは [OpenID Connect](https://openid.net/connect/) 標準の `picture` クレーム (Claim) にマッピングされています。 ::: ### profile \{#profile} -_profile_ には、ユーザーのプロパティに含まれていない OpenID Connect [標準クレーム (Claim)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) の追加情報が保存されます。 +_profile_ には、ユーザーのプロパティに含まれていない追加の OpenID Connect [標準クレーム (Claim)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) が格納されます。 -型定義は [このファイル](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6) で確認できます。以下は型定義のコピーです: +型定義は [こちらのファイル](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6) で確認できます。以下は型定義のコピーです: ```tsx type UserProfile = Partial<{ @@ -124,11 +128,11 @@ type UserProfile = Partial<{ :::note -`Partial` はすべてのプロパティが任意であることを意味します。 +`Partial` はすべてのプロパティがオプションであることを意味します。 ::: -他の標準クレーム (Claim) との違いは、`profile` 内のプロパティは値が空でない場合のみ [ID トークン](https://auth.wiki/id-token) または userinfo エンドポイントのレスポンスに含まれる点です。他の標準クレーム (Claim) は値が空の場合 `null` を返します。 +他の標準クレーム (Claim) との違いとして、`profile` 内のプロパティは値が空でない場合のみ [ID トークン](https://auth.wiki/id-token) または userinfo エンドポイントのレスポンスに含まれます。他の標準クレーム (Claim) は値が空の場合 `null` を返します。 ### application_id \{#application_id} @@ -148,21 +152,21 @@ _updated_at_ は、ユーザーのプロファイル情報が最後に更新さ ### has_password \{#has_password} -_has_password_ は、ユーザーがパスワードを持っているかどうかを示すブール値です。コンソール > ユーザー管理 の詳細ページでこの状態の確認や新規設定・リセットが可能です。 +_has_password_ は、ユーザーがパスワードを持っているかどうかを示すブール値です。このステータスは コンソール > ユーザー管理 の詳細ページで新規設定やリセットを含めて確認・管理できます。 ### password_encrypted \{#password_encrypted} -_password_encrypted_ はユーザーの暗号化されたパスワードを保存します。 +_password_encrypted_ は、ユーザーの暗号化されたパスワードを保存するために使用されます。 値はユーザーが最初に登録したパスワードから取得されます。`null` の場合もあります。非 null の場合、暗号化前の元の内容は 6 文字以上である必要があります。 ### password_encryption_method \{#password_encryption_method} -_password_encryption_method_ はユーザーのパスワードを暗号化するために使用されます。値はユーザーがユーザー名とパスワードで登録したときに初期化されます。`null` の場合もあります。 +_password_encryption_method_ は、ユーザーのパスワードを暗号化するために使用されます。値はユーザーがユーザー名とパスワードで登録した際に初期化されます。`null` の場合もあります。 Logto はデフォルトで [Argon2](https://en.wikipedia.org/wiki/Argon2) の実装 [node-argon2](https://github.com/ranisalt/node-argon2) を暗号化方式として使用しています。詳細はリファレンスを参照してください。 -パスワードが `123456` のユーザーからの _password_encrypted_ と _password_encryption_method_ のサンプル: +パスワードが `123456` のユーザーからの _password_encrypted_ および _password_encryption_method_ のサンプル: ```json { @@ -173,13 +177,13 @@ Logto はデフォルトで [Argon2](https://en.wikipedia.org/wiki/Argon2) の ### is_suspended \{#is_suspended} -_is_suspended_ はユーザーが停止されているかどうかを示すブール値です。この値は [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) の呼び出しや Logto コンソールで管理できます。 +_is_suspended_ は、ユーザーが停止されているかどうかを示すブール値です。この値は [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) を呼び出すか、Logto コンソールで管理できます。 -ユーザーが停止されると、事前に付与されたリフレッシュ トークン (Refresh token) は即座に失効し、Logto で認証 (Authentication) できなくなります。 +ユーザーが停止されると、事前に発行されたリフレッシュ トークンは即座に失効し、そのユーザーは Logto で認証 (Authentication) できなくなります。 ### mfa_verification_factors \{#mfa_verification_factors} -_mfa_verification_factors_ は、ユーザーアカウントに関連付けられた [多要素認証 (MFA)](/end-user-flows/mfa) の方法を列挙する配列です。値には _Totp_(認証アプリ OTP)、_WebAuthn_(パスキー)、_BackupCode_ があります。 +_mfa_verification_factors_ は、ユーザーアカウントに紐づく [多要素認証 (MFA)](/end-user-flows/mfa) の方式を列挙した配列です。値には _Totp_(認証アプリ OTP)、_WebAuthn_(パスキー)、_BackupCode_ があります。 ```tsx mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; @@ -187,17 +191,17 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; ## ソーシャルアイデンティティ \{#social-identities} -_identities_ には [ソーシャルサインイン](/end-user-flows/sign-up-and-sign-in/social-sign-in)([ソーシャルコネクター](/connectors/social-connectors) でのサインイン)から取得したユーザー情報が含まれます。各ユーザーの _identities_ は個別の JSON オブジェクトで保存されます。 +_identities_ には、 [ソーシャルサインイン](/end-user-flows/sign-up-and-sign-in/social-sign-in)([ソーシャルコネクター](/connectors/social-connectors) でのサインイン)から取得したユーザー情報が格納されます。各ユーザーの _identities_ は個別の JSON オブジェクトで保存されます。 ユーザー情報はソーシャルアイデンティティプロバイダー(ソーシャルネットワークプラットフォーム)によって異なりますが、通常は以下を含みます: - アイデンティティプロバイダーの _target_(例:"facebook" や "google") -- このプロバイダーでのユーザーの一意な識別子 +- このプロバイダーでのユーザーの一意識別子 - ユーザー名 -- ユーザーの認証済みメールアドレス +- ユーザーの認証済みメール - ユーザーのアバター -ユーザーアカウントはソーシャルサインインを通じて複数のソーシャルアイデンティティプロバイダーにリンクされる場合があり、これらのプロバイダーから取得した対応するユーザー情報は _identities_ オブジェクトに保存されます。 +ユーザーアカウントはソーシャルサインインを通じて複数のソーシャルアイデンティティプロバイダーと連携できます。これらのプロバイダーから取得した対応するユーザー情報は _identities_ オブジェクトに保存されます。 Google と Facebook の両方でサインインしたユーザーの _identities_ サンプル: @@ -226,9 +230,9 @@ Google と Facebook の両方でサインインしたユーザーの _identities ## SSO アイデンティティ \{#sso-identities} -_sso_identities_ には [エンタープライズシングルサインオン (SSO)](/end-user-flows/enterprise-sso)(エンタープライズコネクターによるシングルサインオン)から取得したユーザー情報が含まれます。各ユーザーの _ssoIdentities_ は個別の JSON オブジェクトで保存されます。 +_sso_identities_ には、 [エンタープライズシングルサインオン (SSO)](/end-user-flows/enterprise-sso)([エンタープライズコネクター](/connectors/enterprise-connectors) でのシングルサインオン)から取得したユーザー情報が格納されます。各ユーザーの _ssoIdentities_ は個別の JSON オブジェクトで保存されます。 -SSO アイデンティティプロバイダーから同期されるデータは、エンタープライズコネクターでリクエストするスコープによって異なります。以下は TypeScript の型定義です: +SSO アイデンティティプロバイダーから同期されるデータは、エンタープライズコネクターで設定されたスコープによって異なります。TypeScript 型定義のコピーは以下の通りです: ```ts type SSOIdentity = { @@ -240,13 +244,13 @@ type SSOIdentity = { ## カスタムデータ \{#custom-data} -_custom_data_ には、事前定義されたユーザープロパティに含まれていない追加のユーザー情報が保存されます。 +_custom_data_ には、事前定義されたユーザープロパティに含まれていない追加のユーザー情報が格納されます。 -_custom_data_ を使って次のことができます: +_custom_data_ を使って以下のことができます: -- ユーザーが特定のアクション(例:ウェルカムページを見たかどうか)を行ったかどうかを記録する +- ユーザーが特定のアクション(例:ウェルカムページを見たかどうか)を実行したか記録する - アプリケーションごとにユーザーの好みの言語や外観など、アプリ固有のデータをユーザープロファイルに保存する -- ユーザーに関連するその他の任意のデータを管理する +- ユーザーに関連するその他任意のデータを管理する Logto の管理者ユーザーの _custom_data_ サンプル: @@ -270,23 +274,23 @@ Logto の管理者ユーザーの _custom_data_ サンプル: :::note -_custom_data_ に機密データを保存しないでください。 +_custom_data_ に機密データを入れないでください。 ::: -カスタムデータはユーザーサインイン後に [カスタム JWT トークンクレーム (Claim)](/developers/custom-token-claims) を通じてアクセスできますが、JWT トークンは base64 エンコード(暗号化されていない)されており、ネットワーク上で頻繁に送信されるため、機密データが簡単に漏洩する可能性があります。 +カスタムデータは、ユーザーサインイン後に [カスタム JWT トークンクレーム (Claim)](/developers/custom-token-claims) を通じてアクセスできます。JWT トークンは base64 エンコード(暗号化ではありません)され、ネットワーク上で頻繁に送信されるため、機密データが簡単に漏洩する可能性があります。 -[Management API](https://openapi.logto.io/operation/operation-listusercustomdata) で _custom_data_ を含むユーザープロファイルを取得し、フロントエンドアプリや外部バックエンドサービスに送信することもできます。そのため、_custom_data_ に機密情報を入れるとデータ漏洩の原因になります。 +[Management API](https://openapi.logto.io/operation/operation-listusercustomdata) を使って _custom_data_ を含むユーザープロファイルを取得し、フロントエンドアプリや外部バックエンドサービスに送信することもできます。そのため、_custom_data_ に機密情報を入れるとデータ漏洩の原因となります。 -それでも _custom_data_ に機密情報を保存したい場合は、事前に暗号化することを推奨します。暗号化 / 復号はバックエンドサービスなど信頼できる場所でのみ行い、フロントエンドアプリでは避けてください。これにより、万が一ユーザーの _custom_data_ が漏洩した場合の損失を最小限に抑えられます。 +それでも _custom_data_ に機密情報を入れたい場合は、まず暗号化することを推奨します。暗号化 / 復号は信頼できるバックエンドサービスなどでのみ行い、フロントエンドアプリでは避けてください。これにより、万が一ユーザーの _custom_data_ が漏洩した場合の損失を最小限に抑えられます。 **ユーザーカスタムデータの収集と更新方法** -- [ユーザープロファイルの収集](/end-user-flows/collect-user-profile) 機能を使って、ユーザーサインアップ時にカスタムデータを収集できます。 -- [Account API](/end-user-flows/account-settings/by-account-api) を使ってエンドユーザープロファイルやアカウント設定を実装できます。 +- [ユーザープロファイル収集](/end-user-flows/collect-user-profile) 機能を使って、ユーザーサインアップ時にカスタムデータを収集する +- [Account API](/end-user-flows/account-settings/by-account-api) を使って、エンドユーザープロファイルやアカウント設定を実装する - [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) で全ユーザーデータを取得 - [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) でユーザーの _custom_data_ を更新 -- [Management API](/user-management/manage-users/#manage-via-logto-management-api) を使ってユーザー管理や高度なカスタムフローを実現できます: +- [Management API](/user-management/manage-users/#manage-via-logto-management-api) を使ってユーザー管理や高度なカスタムフローを実装する - [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) で全ユーザーデータを取得 - [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) でユーザーの _custom_data_ を更新 - サポートチームは コンソール > ユーザー管理 で直接ユーザーの _custom_data_ を更新できます。[ユーザープロファイルの閲覧と更新](/user-management/manage-users/#view-and-update-the-user-profile) も参照してください。 @@ -317,31 +321,29 @@ _custom_data_ に機密データを保存しないでください。 ## プロパティリファレンス \{#property-reference} -次の DB ユーザーテーブルカラム(_password_encrypted_ および _password_encryption_method_ を除く)はユーザープロファイルで表示されます。つまり、 [Management API](https://openapi.logto.io/operation/operation-getuser) で取得できます。 - -| 名前 | 型 | 説明 | 一意 | 必須 | -| ----------------------------------------------------------------------------------- | --------- | -------------------------------------------- | ---- | ---- | -| [id](/user-management/user-data#id) | string | 一意な識別子 | ✅ | ✅ | -| [username](/user-management/user-data#username) | string | サインイン用ユーザー名 | ✅ | ❌ | -| [primary_email](/user-management/user-data#primary_email) | string | メインメールアドレス | ✅ | ❌ | -| [primary_phone](/user-management/user-data#primary_phone) | string | メイン電話番号 | ✅ | ❌ | -| [name](/user-management/user-data#name) | string | フルネーム | ❌ | ❌ | -| [avatar](/user-management/user-data#avatar) | string | ユーザーのアバター画像の URL | ❌ | ❌ | -| [profile](/user-management/user-data#profile) | object | ユーザープロファイル | ❌ | ✅ | -| [identities](/user-management/user-data#social-identities) | object | ソーシャルサインインから取得したユーザー情報 | ❌ | ✅ | -| [custom_data](/user-management/user-data#custom-data) | object | カスタマイズ可能な追加情報 | ❌ | ✅ | -| [application_id](/user-management/user-data#application_id) | string | ユーザーが最初に登録したアプリケーション ID | ❌ | ✅ | -| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | ユーザーが最後にサインインした日時 | ❌ | ✅ | -| [password_encrypted](/user-management/user-data#password_encrypted) | string | 暗号化されたパスワード | ❌ | ❌ | -| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | パスワード暗号化方式 | ❌ | ❌ | -| [is_suspended](/user-management/user-data#is_suspended) | bool | ユーザー停止マーク | ❌ | ✅ | -| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 検証要素 | ❌ | ✅ | - -- **一意**:データベーステーブルのプロパティに入力された値の [一意性](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS) を保証します。 -- **必須**:データベーステーブルのプロパティに入力された値が `null` であってはならないことを保証します。 +次の DB ユーザーテーブルのカラム(_password_encrypted_ および _password_encryption_method_ を除く)はユーザープロファイルで表示されます。つまり、 [Management API](https://openapi.logto.io/operation/operation-getuser) で取得できます。 + +| Name | Type | Description | Unique | Required | +| ----------------------------------------------------------------------------------- | --------- | -------------------------------------------- | ------ | -------- | +| [id](/user-management/user-data#id) | string | 一意識別子 | ✅ | ✅ | +| [username](/user-management/user-data#username) | string | サインイン用ユーザー名 | ✅ | ❌ | +| [primary_email](/user-management/user-data#primary_email) | string | プライマリメールアドレス | ✅ | ❌ | +| [primary_phone](/user-management/user-data#primary_phone) | string | プライマリ電話番号 | ✅ | ❌ | +| [name](/user-management/user-data#name) | string | フルネーム | ❌ | ❌ | +| [avatar](/user-management/user-data#avatar) | string | ユーザーのアバター画像の URL | ❌ | ❌ | +| [profile](/user-management/user-data#profile) | object | ユーザープロファイル | ❌ | ✅ | +| [identities](/user-management/user-data#social-identities) | object | ソーシャルサインインから取得したユーザー情報 | ❌ | ✅ | +| [custom_data](/user-management/user-data#custom-data) | object | カスタマイズ可能なプロパティの追加情報 | ❌ | ✅ | +| [application_id](/user-management/user-data#application_id) | string | ユーザーが最初に登録したアプリケーション ID | ❌ | ✅ | +| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | ユーザーが最後にサインインした日時 | ❌ | ✅ | +| [password_encrypted](/user-management/user-data#password_encrypted) | string | 暗号化されたパスワード | ❌ | ❌ | +| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | パスワード暗号化方式 | ❌ | ❌ | +| [is_suspended](/user-management/user-data#is_suspended) | bool | ユーザー停止マーク | ❌ | ✅ | +| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 検証要素 | ❌ | ✅ | + +- **Unique**:データベーステーブルのプロパティ値の [一意性](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS) を保証します。 +- **Required**:データベーステーブルのプロパティ値が `null` であってはならないことを保証します。 ## 関連リソース \{#related-resources} - - ユーザーデータ移動のためのセキュアハブ - +ユーザーデータ移動時のセキュアハブ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index ac930e5fd56..722be432aeb 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -13,35 +13,35 @@ import Tabs from '@theme/Tabs'; export const resource = 'https://api.your-app.com'; -Logto에서 역할 기반 접근 제어 (RBAC)를 사용하여 제품 전체 API를 보호하세요. 모든 사용자와 클라이언트에 대해 글로벌 역할과 권한을 할당하여 애플리케이션 전반의 접근을 제어할 수 있습니다. +Logto에서 역할 기반 접근 제어 (RBAC)를 사용하여 제품 전체의 API를 보호하세요. 글로벌 역할과 권한을 할당하여 애플리케이션 전반의 모든 사용자와 클라이언트에 대한 접근을 제어할 수 있습니다. -## 글로벌 API 리소스란? \{#what-are-global-api-resources} +## 글로벌 API 리소스란 무엇인가요? \{#what-are-global-api-resources} -글로벌 API 리소스는 조직이나 테넌트와 상관없이 모든 사용자가 접근할 수 있는 애플리케이션 내 엔드포인트 또는 서비스입니다. 일반적으로 공개 API, 핵심 제품 서비스, 또는 특정 조직에 한정되지 않은 엔드포인트가 이에 해당합니다. +글로벌 API 리소스는 조직 또는 테넌트와 상관없이 모든 사용자가 접근할 수 있는 애플리케이션 내 엔드포인트 또는 서비스입니다. 일반적으로 공개 API, 핵심 제품 서비스, 또는 특정 조직에 한정되지 않은 엔드포인트가 이에 해당합니다. **사용 사례 예시** -- 사용자 전체에 공유되는 공개 API 또는 엔드포인트 -- 다중 테넌시에 묶이지 않은 마이크로서비스 +- 사용자 기반 전체에 공유되는 공개 API 또는 엔드포인트 +- 다중 테넌시와 연결되지 않은 마이크로서비스 - 모든 고객이 사용하는 핵심 애플리케이션 API (예: `/api/users`, `/api/products`) -Logto는 OAuth 2.1과 유연한 역할 기반 접근 제어를 결합하여 이러한 API를 안전하게 보호할 수 있도록 합니다. +Logto는 OAuth 2.1과 유연한 역할 기반 접근 제어를 결합하여 이러한 API를 안전하게 보호할 수 있도록 지원합니다. ## Logto에서의 동작 방식 \{#how-it-works-in-logto} -- **API 리소스와 권한은 전역적으로 등록됩니다:** 보호하려는 각 API는 고유한 리소스 지표 (URI)와 접근을 제어하는 권한(스코프) 집합으로 정의됩니다. +- **API 리소스와 권한은 글로벌하게 등록됩니다:** 보호하려는 각 API는 고유한 리소스 지표 (URI)와 접근을 제어하는 권한(스코프) 집합으로 정의됩니다. - **접근은 글로벌 역할로 제어됩니다:** 권한을 역할에 할당하고, 이 역할을 사용자 또는 클라이언트에 할당할 수 있습니다. - **조직 수준 권한과는 별개입니다:** 글로벌 API 리소스는 조직 컨텍스트가 없습니다. 필요하다면 조직 역할과 함께 사용하여 추가적인 컨텍스트를 제공할 수 있습니다. 조직 수준 API 보호는 [조직 수준 API 리소스 보호하기](/authorization/organization-level-api-resources)를 참고하세요. -Global API resources RBAC +글로벌 API 리소스 RBAC ### 구현 개요 \{#implementation-overview} -1. **API 리소스를 등록**하고 Logto에서 해당 권한을 정의하세요. -2. **API 접근에 필요한 권한을 가진 역할을 정의**하세요. -3. **역할을 사용자 또는 클라이언트에 할당**하세요. -4. **OAuth 2.0 인가 플로우**를 사용하여 API에 대한 액세스 토큰을 획득하세요 (resource 파라미터는 등록한 API 식별자와 일치해야 합니다). -5. **API에서 액세스 토큰을 검증**하여 권한을 적용하세요. +1. **API 리소스를 등록**하고 Logto에서 해당 권한을 정의합니다. +2. **API 접근에 필요한 권한을 가진 역할을 정의**합니다. +3. **역할을 사용자 또는 클라이언트에 할당**합니다. +4. **OAuth 2.0 인가 플로우**를 사용하여 API용 액세스 토큰을 획득합니다 (resource 파라미터는 등록된 API 식별자와 일치해야 합니다). +5. **API에서 액세스 토큰을 검증**하여 권한을 적용합니다. ### 리소스 지표 이해하기 \{#understanding-resource-indicators} @@ -62,21 +62,21 @@ Logto는 [RFC 8707: OAuth 2.0을 위한 리소스 지표](https://www.rfc-editor 아래 플로우는 상호작용 사용자 인증 (브라우저/앱)과 백엔드 기계 간 (M2M) 시나리오 모두에 적용됩니다. -이 플로우는 필수 파라미터나 헤더에 대한 모든 세부 정보를 포함하지 않으며, 주요 단계에 초점을 맞추고 있습니다. 실제 플로우가 어떻게 동작하는지 계속 읽어보세요. +이 플로우는 필수 파라미터나 헤더에 대한 모든 세부사항을 포함하지 않으며, 주요 단계에 초점을 맞추고 있습니다. 실제 동작 방식은 아래 내용을 계속 읽어보세요. ```mermaid sequenceDiagram - participant Client - participant Logto + participant Client as 클라이언트 + participant Logto as Logto participant API as API 리소스 alt 사용자 인증 Client->>Logto: GET /oidc/auth Logto->>Logto: 사용자를 로그인 페이지로 리디렉션 Logto->>Client: `authorization_code`와 함께 다시 리디렉션 - alt authorization_code grant 사용 + alt authorization_code 그랜트 사용 Client->>Logto: POST /oidc/token, `grant_type=authorization_code`
및 `resource` 파라미터 포함 - else refresh_token grant 사용 + else refresh_token 그랜트 사용 Client->>Logto: POST /oidc/token, `grant_type=authorization_code` Logto->>Client: 리프레시 토큰 반환 Client->>Logto: POST /oidc/token, `grant_type=refresh_token`
및 `resource` 파라미터 포함 @@ -92,7 +92,7 @@ sequenceDiagram alt 토큰이 유효함 API->>Client: 보호된 리소스 데이터 반환 else 토큰이 유효하지 않음 - API->>Client: 401 Unauthorized + API->>Client: 401 인가되지 않음 end ``` @@ -106,16 +106,16 @@ _사용자 인증 = 브라우저/앱. M2M = 클라이언트 자격 증명을 사 ### API 리소스 등록하기 \{#register-your-api-resources} -1. 콘솔 → API 리소스로 이동하세요. -2. 새 API 리소스 (예: `https://api.yourapp.com/org`)를 생성하고 권한(스코프)을 정의하세요. +1. 콘솔 → API 리소스로 이동합니다. +2. 새 API 리소스 (예: `https://api.yourapp.com/org`)를 생성하고, 해당 권한(스코프)을 정의합니다. 전체 설정 단계는 [권한과 함께 API 리소스 정의하기](/authorization/role-based-access-control#define-api-resources-with-permissions)를 참고하세요. ### 글로벌 역할 설정하기 \{#set-up-global-roles} -1. 콘솔 → 역할로 이동하세요. -2. API 권한에 매핑되는 역할을 생성하세요 (예: `read:products`, `write:products`). -3. 해당 역할을 API 접근이 필요한 사용자 또는 클라이언트에 할당하세요. +1. 콘솔 → 역할로 이동합니다. +2. API 권한에 매핑되는 역할을 생성합니다 (예: `read:products`, `write:products`). +3. 이 역할을 API 접근이 필요한 사용자 또는 클라이언트에 할당합니다. 전체 설정 단계는 [글로벌 역할 사용하기](/authorization/role-based-access-control#configure-global-roles)를 참고하세요. @@ -132,30 +132,30 @@ _사용자 인증 = 브라우저/앱. M2M = 클라이언트 자격 증명을 사 Logto 클라이언트 초기화 시, `resources` 파라미터(배열)에 리소스 지표를 추가하고, `scopes` 파라미터에 원하는 권한(스코프)을 추가하세요. -사용자가 인증되면, 액세스 토큰을 요청할 때 `resource` 파라미터 또는 유사한 파라미터에 리소스 지표를 전달하세요 (예: `getAccessToken()` 호출). +사용자가 인증되면, 액세스 토큰을 요청할 때 `resource` 파라미터(또는 유사한 파라미터)에 리소스 지표를 전달하세요 (예: `getAccessToken()` 호출). 각 SDK별 자세한 내용은 [빠른 시작](/quick-starts)을 참고하세요. -OAuth 2.0 클라이언트 설정 또는 인가 코드 플로우 초기화 시, 인가 요청에 `resource` 파라미터와 원하는 스코프를 반드시 포함하세요. +OAuth 2.0 클라이언트 구성 또는 인가 코드 플로우 초기화 시, 인가 요청에 `resource` 파라미터와 원하는 스코프를 반드시 포함하세요. -일부 라이브러리는 `resource` 파라미터를 기본 지원하지 않을 수 있지만, 일반적으로 인가 요청에 추가 파라미터를 전달할 수 있습니다. 자세한 내용은 라이브러리 문서를 참고하세요. +일부 라이브러리는 `resource` 파라미터를 기본 지원하지 않을 수 있지만, 일반적으로 인가 요청에 추가 파라미터를 전달할 수 있습니다. 자세한 내용은 사용 중인 라이브러리의 문서를 참고하세요. -다음은 `resource` 및 `scope` 파라미터가 포함된 인가 요청의 비공식 예시입니다: +다음은 `resource` 및 `scope` 파라미터가 포함된 인가 요청의 비표준 예시입니다: -사용자가 인증되면 인가 코드를 받게 됩니다. 이 코드를 Logto의 `/oidc/token` 엔드포인트에 POST 요청하여 액세스 토큰으로 교환하세요. 이때 요청 본문에 `resource` 파라미터를 포함해야 합니다. +사용자가 인증되면, 인가 코드를 받게 됩니다. 이 코드를 Logto의 `/oidc/token` 엔드포인트에 POST 요청하여 액세스 토큰으로 교환하세요. 이때 요청 본문에 `resource` 파라미터를 포함해야 합니다. -다음은 authorization code grant 타입을 사용하는 토큰 요청의 비공식 예시입니다: +다음은 authorization_code 그랜트 타입을 사용하는 토큰 요청의 비표준 예시입니다: -사용자 상호작용 없이 새로운 액세스 토큰을 획득하려면, `refresh_token` grant 타입을 사용할 수 있습니다. 이때도 `resource` 파라미터를 요청에 포함해야 합니다. +사용자 상호작용 없이 새로운 액세스 토큰을 얻으려면, `refresh_token` 그랜트 타입을 사용할 수 있습니다. 이때도 요청에 `resource` 파라미터를 포함해야 합니다. -다음은 refresh token grant 타입을 사용하는 토큰 요청의 비공식 예시입니다: +다음은 refresh_token 그랜트 타입을 사용하는 토큰 요청의 비표준 예시입니다: @@ -171,7 +171,7 @@ OAuth 2.0 클라이언트 설정 또는 인가 코드 플로우 초기화 시, - `resource`: 접근하려는 API의 리소스 지표 URI (예: `https://api.yourapp.com`) - `scope`: API에 요청할 권한 (예: `read:products write:products`) -다음은 클라이언트 자격 증명 grant 타입을 사용하는 토큰 요청의 비공식 예시입니다: +다음은 클라이언트 자격 증명 그랜트 타입을 사용하는 토큰 요청의 비표준 예시입니다: @@ -245,6 +245,36 @@ Logto 콘솔에서 기본 API 리소스를 설정하세요. 토큰 요청에 res +
+ + +### 권한 요청 시 스코프 접두사나 축약형을 사용할 수 있나요? \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +아니요. 스코프 이름은 API 리소스에 정의된 권한 이름과 **정확히 일치해야** 합니다. 접두사나 축약형은 와일드카드로 동작하지 않습니다. + +**예시:** + +API 리소스에 다음이 정의되어 있다면: + +- `read:elections` +- `write:elections` + +다음과 같이 요청해야 합니다: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +이렇게 하면 **동작하지 않습니다**: + +```swift +scopes: ["read", "write"] // ❌ 권한 이름과 일치하지 않음 +``` + +
+ ## 추가 자료 \{#further-reading} 액세스 토큰 검증 방법 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index 0938f755880..f78d8a3a97d 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -6,16 +6,16 @@ sidebar_position: 4 Logto는 다양한 사전 정의된 언어를 지원하며, 113개의 추가 언어 태그를 제공합니다. 이 강력한 도구를 통해 로그인 경험을 맞춤화하고, 직접 언어 옵션과 번역을 생성 및 관리할 수 있습니다. -## Logto 콘솔에서의 맞춤화 단계 \{#customization-steps-in-logto-console} +## Logto Console에서의 맞춤화 단계 \{#customization-steps-in-logto-console} -코딩 없이 Logto 콘솔에서 언어 설정을 쉽게 맞춤화할 수 있습니다. +코딩 없이 Logto Console에서 언어 설정을 쉽게 맞춤화할 수 있습니다. -1. **이동 경로**: 콘솔 > 로그인 경험 > 콘텐츠 > 언어. +1. **이동 경로**: Console > 로그인 경험 > 콘텐츠 > 언어. 2. **언어 관리**: “언어 관리” 버튼을 클릭하여 언어 라이브러리에 접근하세요. - - **기존 언어 편집:** Logto에서 제공하는 언어의 번역을 맞춤화할 수 있습니다. 이 언어들은 삭제할 수 없지만, 변경 사항이 기본값을 덮어씁니다. + - **기존 언어 편집:** Logto에서 제공하는 언어의 번역을 맞춤화할 수 있습니다. 이 언어들은 삭제할 수 없지만, 변경 사항이 기본 값을 덮어씁니다. - **새 언어 추가:** ”언어 추가” 버튼을 클릭하고, 언어 태그를 선택한 뒤 번역을 입력하고 저장하면 새 언어가 추가됩니다. -3. **자동 감지 활성화:** 활성화 시, 사용자의 기기 설정을 기반으로 로그인 페이지가 자동으로 선호 언어로 표시됩니다. -4. **기본 언어 설정:** 언어 라이브러리에서 기본 언어를 선택할 수 있습니다. 감지된 사용자 언어가 현재 라이브러리에 없을 때 기본 언어가 사용됩니다. +3. **자동 감지 활성화:** 활성화 시, 사용자의 기기 설정에 따라 로그인 페이지가 자동으로 선호 언어로 표시됩니다. +4. **기본 언어 설정:** 언어 라이브러리에서 기본 언어를 선택할 수 있습니다. 감지된 사용자 언어가 현재 라이브러리에 없을 때 이 언어가 사용됩니다. 언어를 관리할 때 알아두면 좋은 주요 용어는 다음과 같습니다: @@ -25,9 +25,9 @@ Logto는 다양한 사전 정의된 언어를 지원하며, 113개의 추가 언 | Logto 제공 언어 | Logto 제공 언어는 Logto 공식 언어이며, Logto의 원본 코드 베이스에 저장되어 있습니다. | | 추가된 언어 | 추가된 언어는 사용자가 직접 추가한 언어입니다. | | Logto 소스 값 | Logto 소스 값은 사용자가 맞춤화하지 않은 Logto에서 제공된 값입니다. | -| 맞춤 값 | 맞춤 값은 사용자가 이미 맞춤화한 값입니다. Logto 소스 값은 덮어써집니다. | +| 맞춤 값 | 맞춤 값은 사용자가 이미 맞춤화한 값입니다. Logto 소스 값이 덮어써집니다. | -## Management API를 통한 맞춤화 \{#customization-using-management-api} +## Management API를 이용한 맞춤화 \{#customization-using-management-api} Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase)를 사용하여 언어 번역을 맞춤화할 수 있습니다. API 요청 본문은 다음과 같은 부분적 로케일 객체입니다: @@ -39,7 +39,7 @@ Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.i }, "action": { "sign_in": "로그인" }, "error": { - "general_required": "{{types, list(type: disjunction;)}}는 필수 항목입니다" + "general_required": "{{types, list(type: disjunction;)}} 필수 항목입니다" }, "list": { "or": "또는" }, "user_scopes": { @@ -56,21 +56,21 @@ Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.i 런타임 시, 로그인 경험의 언어는 다음 우선순위로 결정됩니다: -1. 현재 인증 요청의 `ui_locales` OIDC 파라미터 (지원되는 첫 번째 태그가 사용됨). 자세한 내용은 [ui_locales](/end-user-flows/authentication-parameters/ui-locales) 참고. -2. 그렇지 않으면, "자동 감지"가 활성화된 경우, 감지된 사용자 클라이언트 언어(예: HTTP `Accept-Language` 헤더에서). +1. 현재 인증 요청의 `ui_locales` OIDC 파라미터 (지원되는 첫 번째 태그 사용). 자세한 내용은 [ui_locales](/end-user-flows/authentication-parameters/ui-locales) 참고. +2. 그렇지 않으면, "자동 감지"가 활성화된 경우, 감지된 사용자 클라이언트 언어 (예: HTTP `Accept-Language` 헤더에서). 3. 그렇지 않으면, 로그인 경험의 테넌트 기본 언어. -이 결정 방식은 상호작용으로 트리거된 메시지의 이메일 현지화에도 영향을 미칩니다. 자세히 알아보기: [이메일 템플릿 현지화](/connectors/email-connectors/email-templates#email-template-localization). +이 결정 방식은 상호작용으로 트리거되는 메시지의 이메일 현지화에도 영향을 미칩니다. 자세히 알아보기: [이메일 템플릿 현지화](/connectors/email-connectors/email-templates#email-template-localization). ## 사용 사례 \{#use-cases} -추가된 언어가 최종 고객에게 어떻게 보일까요? +추가된 언어는 최종 고객에게 어떻게 보이나요? -예를 들어, 영어가 기본 언어이고 자동 감지가 켜진 웹사이트가 있다고 가정해봅시다. 일본에서 온 사용자가 사이트에 접속해 계정을 만들려고 합니다. 만약 그가 앱 언어로 일본어를 사용하지만 Logto에서 아직 해당 언어를 지원하지 않는다면, 로그인 화면은 영어로 표시됩니다. +예를 들어, 영어가 기본 언어이고 자동 감지가 켜진 웹사이트가 있다고 가정해봅시다. 일본에서 온 사용자가 사이트를 방문해 계정을 생성하려고 합니다. 만약 그 사용자가 앱 언어로 일본어를 사용하지만 Logto에서 아직 해당 언어를 지원하지 않는다면, 로그인 화면은 영어로 표시됩니다. Logto 로그인 경험 i18n을 통해 맞춤 언어가 가능합니다. -`ja` 언어 태그를 클릭해 직접 일본어 번역을 추가하세요. +`ja` 언어 태그를 클릭하여 직접 일본어 번역을 추가하세요. 이렇게 하면, 일본에서 접속한 사용자는 영어에서 번역한 일본어로 콘텐츠를 볼 수 있습니다. @@ -83,7 +83,7 @@ Logto 로그인 경험 i18n을 통해 맞춤 언어가 가능합니다. -왼쪽 언어 태그 옆에 Logto 제공 태그가 표시되며, 추가한 언어는 더 이상 삭제할 수 없습니다. 수정한 값은 계속 동작하며 원래 Logto 값을 대체합니다. Logto의 기본 설정에서 제공하는 값을 사용하려면 사용자가 입력한 값을 지우면 됩니다. +왼쪽 언어 태그 옆에 Logto 제공 태그가 표시되며, 추가한 언어는 더 이상 삭제할 수 없습니다. 수정한 값은 계속 동작하며, 원래 Logto 값을 대체합니다. Logto의 기본 설정에서 제공하는 값을 사용하려면, 사용자가 입력한 값을 삭제하세요. @@ -95,7 +95,20 @@ Logto 로그인 경험 i18n을 통해 맞춤 언어가 가능합니다. 최종 사용자가 보는 것은 두 컬럼이 병합된 결과입니다. -Logto에서 제공한 원본 콘텐츠 중 일부만 조정하고 싶을 때, 회원가입 화면에서 Logto가 제공한 것과의 차이는 편집한 키만 다릅니다. 나머지 콘텐츠는 변경되지 않습니다. +Logto에서 제공한 원본 콘텐츠 중 일부만 수정하고 싶을 때, 회원가입 화면에서 Logto가 제공한 것과의 차이는 수정한 키만 반영됩니다. 나머지 콘텐츠는 변경되지 않습니다. + + + +
+ + +### 로그인 경험에서 기본 전화번호 국가 코드는 어떻게 설정하나요? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +[로그인 경험](/end-user-flows/sign-up-and-sign-in/sign-up)에서 전화번호 국가 코드는 사용자의 브라우저 로케일을 기본값으로 사용합니다. 예를 들어, 사용자의 브라우저 언어가 `fr`로 설정되어 있다면, 국가 코드는 프랑스(+33)로 기본 설정됩니다. + +특정 사용자 또는 지역에 대해 기본 국가 코드를 프로그래밍 방식으로 제어하려면, [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 인증 파라미터를 사용할 수 있습니다. 예를 들어, `ui_locales=ja`로 설정하면 국가 코드가 일본(+81)으로 기본 설정됩니다.
diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index c8a5f93659f..7a42f8d41a8 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -7,22 +7,22 @@ sidebar_position: 1 ## 옴니 로그인 경험 \{#omni-sign-in-experience} 콘솔 > 로그인 경험 > 브랜딩으로 이동하여 -로그인 페이지의 외관과 느낌을 맞춤화하세요. 이 섹션에서는 주요 브랜딩 요소를 손쉽게 조정할 수 +로그인 페이지의 외관과 느낌을 맞춤화하세요. 이 섹션에서는 주요 브랜딩 요소를 쉽게 조정할 수 있습니다. -**브랜드 색상** +### 브랜드 색상 \{#brand-color} -로그인 경험 전반에 사용되는 기본 색상을 정의하세요. 기본 Logto 보라색을 브랜드의 색상으로 교체할 수 있습니다. 다크 모드의 경우 별도의 브랜드 색상을 지정할 수 있습니다. +로그인 경험 전반에 사용되는 기본 색상을 정의하세요. 기본 버튼, 링크, 기타 컴포넌트에 적용됩니다. 기본 Logto 보라색을 브랜드 색상으로 교체할 수 있습니다. 다크 모드의 경우 별도의 브랜드 색상을 지정할 수 있습니다. -**회사 로고** +### 회사 로고 \{#company-logo} -로고는 로그인 홈, 회원가입 홈, 로딩 페이지 및 기타 확장된 인터페이스에 표시됩니다. +로고는 로그인 홈, 회원가입 홈, 로딩 페이지 및 기타 인터페이스에 표시됩니다. - 이미지에는 몇 가지 제한이 있습니다: 500KB 이하, SVG, PNG, JPG, JPEG, ICO 형식이어야 합니다. - 로고 필드를 비워두면 인터페이스에 로고가 표시되지 않습니다. - 다크 모드 버전의 로고도 업로드할 수 있습니다. -**파비콘** +### 파비콘 \{#favicon} 파비콘은 웹사이트를 대표하는 작은 아이콘으로, 브라우저 탭, 즐겨찾기, 기타 브라우저 인터페이스 영역에 표시됩니다. @@ -30,30 +30,34 @@ sidebar_position: 1 - 다크 모드 버전의 파비콘도 업로드할 수 있습니다. - 또한, 다양한 플로우(로그인/회원가입/비밀번호 찾기 등)에서는 이제 커스텀 타이틀 대신 브라우저 타이틀이 사용됩니다. -**다크 모드** +### 다크 모드 \{#dark-mode} 다크 모드를 활성화하면 사용자의 시스템 환경설정에 따라 로그인 페이지의 외관이 자동으로 조정됩니다. +### Logto 브랜딩 숨기기 \{#hide-logto-branding} + +기본적으로, 기본 제공 로그인 경험 페이지 하단에는 "Powered by Logto"가 표시됩니다. "Logto 브랜딩 숨기기" 옵션을 활성화하면 Logto 마크가 제거되어 오직 귀사의 브랜드 아이덴티티만을 보여주는 깔끔하고 전문적인 로그인 경험을 만들 수 있습니다. + ## 앱별 브랜딩 \{#app-specific-branding} -여러 앱을 운영하는 비즈니스에서 앱 단위의 로그인 경험이 필요하다면, 애플리케이션 상세 페이지에서 이를 설정할 수 있습니다. 콘솔 > 애플리케이션으로 이동하세요. +여러 앱을 운영하는 비즈니스에서 앱 단위의 로그인 경험이 필요하다면, 애플리케이션 상세 페이지에서 설정할 수 있습니다. 콘솔 > 애플리케이션으로 이동하세요. -"앱 단위 로그인 경험"을 활성화하면 각 앱별로 브랜딩 로고, 파비콘, 색상, 심지어 [커스텀 CSS](/customization/custom-css)까지 설정할 수 있습니다. 앱 단위 브랜딩이 활성화된 앱에서 로그인을 시작하면, 로그인 경험이 해당 앱의 브랜딩 설정에 따라 맞춤화됩니다. 그렇지 않은 경우 기본 옴니 로그인 경험 설정이 적용됩니다. +"앱 단위 로그인 경험"을 켜면, 각 앱별로 브랜딩 로고, 파비콘, 색상, 심지어 [커스텀 CSS](/customization/custom-css)까지 설정할 수 있습니다. 앱 단위 브랜딩이 활성화된 앱에서 로그인을 시작하면, 해당 앱의 브랜딩 설정에 따라 로그인 경험이 맞춤화됩니다. 그렇지 않으면 기본 옴니 로그인 경험 설정이 적용됩니다. -앱 단위 브랜딩에도 라이트 모드와 다크 모드 설정이 모두 제공됩니다. 다크 모드 설정은 [옴니 로그인 경험](#omni-sign-in-experience) 설정에서 다크 모드가 활성화된 경우에만 적용됩니다. +앱 단위 브랜딩에도 라이트 모드와 다크 모드 설정이 모두 제공됩니다. 다크 모드 설정은 [옴니 로그인 경험](#omni-sign-in-experience)에서 다크 모드가 활성화된 경우에만 적용됩니다. ## 조직별 브랜딩 \{#organization-specific-branding} 클라이언트의 조직 로고를 로그인 경험에 동적으로 표시하려면, 조직 설정 페이지에서 조직 로고를 업로드할 수 있습니다. 콘솔 > 조직으로 이동하세요. -"조직 단위 로그인 경험"을 활성화하면, 앱 단위 브랜딩과 마찬가지로 각 조직별로 브랜딩 로고, 파비콘, 색상, [커스텀 CSS](/customization/custom-css)까지 설정할 수 있습니다. +"조직 단위 로그인 경험"을 켜면, 앱별 브랜딩과 마찬가지로 각 조직별로 브랜딩 로고, 파비콘, 색상, [커스텀 CSS](/customization/custom-css)까지 설정할 수 있습니다. 이후 로그인을 트리거할 때, `organization_id` 파라미터에 조직 ID를 전달하여 Logto에 어떤 조직 로고를 표시할지 지정할 수 있습니다. 예를 들어, 조직 ID가 `123456`인 조직의 로고를 표시하려면: - Logto SDK를 사용하는 경우, `signIn` 메서드의 `extraParams` 객체에 `organization_id` 파라미터를 전달할 수 있습니다. - OIDC 클라이언트를 사용하는 경우, [인가 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 요청 시 `organization_id` 파라미터를 전달할 수 있습니다. -조직 단위 브랜딩에도 라이트 모드와 다크 모드 설정이 모두 제공됩니다. 다크 모드 설정은 [옴니 로그인 경험](#omni-sign-in-experience) 설정에서 다크 모드가 활성화된 경우에만 적용됩니다. +조직 단위 브랜딩에도 라이트 모드와 다크 모드 설정이 모두 제공됩니다. 다크 모드 설정은 [옴니 로그인 경험](#omni-sign-in-experience)에서 다크 모드가 활성화된 경우에만 적용됩니다. :::note 앱 단위 브랜딩과 조직 단위 브랜딩이 모두 활성화된 경우, 조직 단위 브랜딩이 우선 적용됩니다. 전체 우선순위는 다음과 같습니다: @@ -76,7 +80,7 @@ logtoClient.signIn({ :::note -`extraParams` 기능은 모든 Logto SDK에 점진적으로 적용되고 있습니다. 아직 사용 중인 SDK에서 보이지 않는다면 문의해 주세요. +`extraParams` 기능은 모든 Logto SDK에 점진적으로 적용되고 있습니다. 아직 해당 기능이 SDK에 보이지 않는다면, 문의해 주세요. ::: diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index f98ac8f9c07..9829a2a9425 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -7,12 +7,12 @@ sidebar_position: 1 ## Logto Account API란? \{#what-is-logto-account-api} -Logto Account API는 최종 사용자가 Management API를 거치지 않고 직접 API에 접근할 수 있도록 하는 포괄적인 API 세트입니다. 주요 특징은 다음과 같습니다: +Logto Account API는 엔드 유저가 Management API를 거치지 않고 직접 API에 접근할 수 있도록 하는 포괄적인 API 세트입니다. 주요 특징은 다음과 같습니다: -- 직접 접근: Account API는 최종 사용자가 Management API를 거치지 않고 자신의 계정 프로필을 직접 접근 및 관리할 수 있도록 합니다. -- 사용자 프로필 및 아이덴티티 관리: 사용자는 이메일, 전화번호, 비밀번호 등 아이덴티티 정보를 업데이트하고 소셜 연결을 관리하는 등 자신의 프로필과 보안 설정을 완전히 관리할 수 있습니다. MFA 및 SSO 지원도 곧 제공될 예정입니다. +- 직접 접근: Account API는 엔드 유저가 Management API를 거치지 않고 자신의 계정 프로필에 직접 접근하고 관리할 수 있도록 합니다. +- 사용자 프로필 및 아이덴티티 관리: 사용자는 이메일, 전화번호, 비밀번호 등 아이덴티티 정보를 업데이트하고, 소셜 연결을 관리하는 등 프로필과 보안 설정을 완전히 관리할 수 있습니다. MFA 및 SSO 지원도 곧 제공될 예정입니다. - 글로벌 접근 제어: 관리자는 접근 설정을 전역적으로 완전히 제어할 수 있으며, 각 필드를 맞춤 설정할 수 있습니다. -- 원활한 인가 (Authorization): 인가 (Authorization)가 그 어느 때보다 쉬워졌습니다! `client.getAccessToken()`을 사용하여 OP (Logto)용 불투명 토큰 (Opaque token)을 얻고, 이를 `Bearer ` 형식으로 Authorization 헤더에 첨부하세요. +- 원활한 인가 (Authorization): 인가 (Authorization)가 그 어느 때보다 쉬워졌습니다! `client.getAccessToken()`을 사용하여 OP (Logto)용 불투명 토큰 (Opaque token)을 얻고, 이를 Authorization 헤더에 `Bearer ` 형식으로 첨부하세요. Logto Account API를 사용하면 Logto와 완전히 통합된 프로필 페이지와 같은 맞춤형 계정 관리 시스템을 구축할 수 있습니다. @@ -21,14 +21,14 @@ Logto Account API를 사용하면 Logto와 완전히 통합된 프로필 페이 - 사용자 프로필 조회 - 사용자 프로필 업데이트 - 사용자 비밀번호 변경 -- 이메일, 전화번호, 소셜 연결 등 사용자 아이덴티티 정보 업데이트 +- 이메일, 전화번호, 소셜 연결 등 사용자 아이덴티티 업데이트 - MFA 요소(인증) 관리 사용 가능한 API에 대해 더 알아보려면 [Logto Account API Reference](https://openapi.logto.io/group/endpoint-my-account) 및 [Logto Verification API Reference](https://openapi.logto.io/group/endpoint-verifications)를 방문하세요. :::note -SSO 계정 조회 및 계정 삭제 기능은 현재 Logto Management API를 통해 제공됩니다. 구현 세부 사항은 [Management API로 계정 설정하기](/end-user-flows/account-settings/by-management-api)를 참고하세요. +SSO 계정 조회 및 계정 삭제 기능은 현재 Logto Management API를 통해 제공됩니다. 구현 방법은 [Management API로 계정 설정하기](/end-user-flows/account-settings/by-management-api)를 참고하세요. ::: @@ -39,21 +39,21 @@ SSO 계정 조회 및 계정 삭제 기능은 현재 Logto Management API를 통 Account API는 기본적으로 비활성화되어 있으므로 접근 제어가 잠겨 있습니다. **Account API 활성화**를 토글하여 켜세요. -활성화 후, 식별자, 프로필 데이터, 서드파티 토큰 접근에 대한 필드별 권한을 설정할 수 있습니다. 각 필드는 `Off`, `ReadOnly`, `Edit` 중 하나를 지원하며, 기본값은 `Off`입니다. +활성화 후, 식별자, 프로필 데이터, 서드파티 토큰 접근에 대해 필드별 권한을 설정할 수 있습니다. 각 필드는 `Off`, `ReadOnly`, `Edit` 중 하나를 지원하며, 기본값은 `Off`입니다. 1. **보안 필드**: - - 필드: 기본 이메일, 기본 전화번호, 소셜 아이덴티티, 비밀번호, MFA. - - 최종 사용자가 이 필드를 수정하기 전, 비밀번호, 이메일 또는 SMS를 통해 본인 인증을 해야 하며, 10분 유효의 인증 기록 ID를 받아야 합니다. [인증 기록 ID 받기](#get-a-verification-record-id)를 참고하세요. - - MFA용 WebAuthn 패스키를 사용하려면, 프론트엔드 앱 도메인을 **WebAuthn 관련 Origin**에 추가하여 계정 센터와 로그인 경험이 패스키를 공유할 수 있도록 하세요. [새 WebAuthn 패스키 연결하기](#link-a-new-webauthn-passkey)를 참고하세요. + - 필드에는 기본 이메일, 기본 전화번호, 소셜 아이덴티티, 비밀번호, MFA가 포함됩니다. + - 엔드 유저가 이 필드를 수정하기 전에, 비밀번호, 이메일, SMS를 통해 본인 인증을 거쳐 10분 유효의 인증 기록 ID를 받아야 합니다. [인증 기록 ID 받기](#get-a-verification-record-id)를 참고하세요. + - MFA용 WebAuthn 패스키를 사용하려면, 프론트엔드 앱 도메인을 **WebAuthn 관련 Origin**에 추가하여 계정 센터와 로그인 경험이 패스키를 공유할 수 있도록 하세요. [새 WebAuthn 패스키 연결](#link-a-new-webauthn-passkey)을 참고하세요. 2. **프로필 필드**: - - 필드: 사용자명, 이름, 아바타, [프로필](/user-management/user-data#profile) (기타 표준 프로필 속성), [커스텀 데이터](/user-management/user-data#custom-data). - - 최종 사용자는 추가 인증 없이 이 필드를 수정할 수 있습니다. -3. **시크릿 볼트**: OIDC 또는 OAuth 소셜 및 엔터프라이즈 커넥터의 경우, Logto [시크릿 볼트](/secret-vault/federated-token-set)는 인증 후 서드파티 액세스 및 리프레시 토큰을 안전하게 저장합니다. 앱은 이후 외부 API(예: Google 캘린더 동기화 등)를 호출할 수 있으며, 사용자는 다시 로그인할 필요가 없습니다. Account API가 활성화되면 토큰 조회가 자동으로 가능해집니다. + - 필드에는 사용자명, 이름, 아바타, [프로필](/user-management/user-data#profile) (기타 표준 프로필 속성), [커스텀 데이터](/user-management/user-data#custom-data)가 포함됩니다. + - 엔드 유저는 추가 인증 없이 이 필드를 수정할 수 있습니다. +3. **시크릿 볼트**: OIDC 또는 OAuth 소셜 및 엔터프라이즈 커넥터의 경우, Logto [시크릿 볼트](/secret-vault/federated-token-set)는 인증 후 서드파티 액세스 및 리프레시 토큰을 안전하게 저장합니다. 앱은 이후 사용자가 다시 로그인하지 않아도 외부 API(예: Google Calendar 이벤트 동기화 등)를 호출할 수 있습니다. Account API가 활성화되면 토큰 조회가 자동으로 가능해집니다. ## Account API 접근 방법 \{#how-to-access-account-api} :::note -액세스 토큰에 적절한 권한이 포함되어 있는지 확인하려면, Logto 설정에서 해당 스코프를 올바르게 구성해야 합니다. +액세스 토큰에 적절한 권한이 포함되도록 Logto 설정에서 해당 스코프를 올바르게 구성해야 합니다. 예를 들어, `POST /api/my-account/primary-email` API를 사용하려면 `email` 스코프를, `POST /api/my-account/primary-phone` API를 사용하려면 `phone` 스코프를 구성해야 합니다. @@ -86,7 +86,7 @@ const config: LogtoConfig = { Account API와 통신할 때는 HTTP 헤더의 `Authorization` 필드에 Bearer 형식(`Bearer YOUR_TOKEN`)으로 액세스 토큰을 포함해야 합니다. -사용자 계정 정보를 조회하는 예시는 다음과 같습니다: +사용자 계정 정보를 가져오는 예시는 다음과 같습니다: ```bash curl https://[tenant-id].logto.app/api/my-account \ @@ -97,7 +97,7 @@ curl https://[tenant-id].logto.app/api/my-account \ ### 사용자 계정 정보 조회 \{#retrieve-user-account-information} -사용자 데이터를 조회하려면 [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) 엔드포인트를 사용할 수 있습니다. +사용자 데이터를 가져오려면 [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) 엔드포인트를 사용할 수 있습니다. ```bash curl https://[tenant-id].logto.app/api/my-account \ @@ -141,13 +141,13 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ ## 식별자 및 기타 민감 정보 관리 \{#manage-identifiers-and-other-sensitive-information} -보안상의 이유로, Account API는 식별자 및 기타 민감 정보와 관련된 작업에 대해 추가 인가 (Authorization) 계층을 요구합니다. +보안상의 이유로, Account API는 식별자 및 기타 민감 정보와 관련된 작업에 대해 추가 인가 (Authorization) 절차를 요구합니다. ### 인증 기록 ID 받기 \{#get-a-verification-record-id} -먼저, 10분 유효기간(TTL)의 **인증 기록 ID**를 받아야 합니다. 이는 민감 정보 업데이트 전 사용자의 신원을 확인하는 데 사용됩니다. 즉, 사용자가 비밀번호, 이메일 인증 코드, SMS 인증 코드로 본인 인증에 성공하면, 10분 동안 인증 관련 데이터(식별자, 자격 증명, 소셜 계정 연결, MFA 등)를 업데이트할 수 있습니다. +먼저, 10분 유효기간(TTL)의 **인증 기록 ID**를 받아야 합니다. 이는 민감 정보 업데이트 전에 사용자의 신원을 확인하는 데 사용됩니다. 즉, 사용자가 비밀번호, 이메일 인증 코드, SMS 인증 코드로 본인 인증에 성공하면, 10분 동안 인증 관련 데이터(식별자, 자격 증명, 소셜 계정 연결, MFA 등)를 업데이트할 수 있습니다. -인증 기록 ID를 받으려면 [사용자 비밀번호 인증](#verify-the-users-password) 또는 [사용자 이메일/전화번호로 인증 코드 전송](#verify-by-sending-a-verification-code-to-the-users-email-or-phone)을 사용할 수 있습니다. +인증 기록 ID를 받으려면 [사용자 비밀번호 인증](#verify-the-users-password) 또는 [이메일/전화번호로 인증 코드 전송](#verify-by-sending-a-verification-code-to-the-users-email-or-phone)을 사용할 수 있습니다. #### 사용자 비밀번호 인증 \{#verify-the-users-password} @@ -167,13 +167,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/password \ } ``` -#### 사용자 이메일/전화번호로 인증 코드 전송 \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} +#### 이메일 또는 전화번호로 인증 코드 전송 \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} :::note 이 방법을 사용하려면 [이메일 커넥터](/connectors/email-connectors/) 또는 [SMS 커넥터](/connectors/sms-connectors/)를 구성하고, `UserPermissionValidation` 템플릿이 설정되어 있어야 합니다. ::: -이메일을 예로 들면, 새 인증 코드를 요청하고 인증 기록 ID를 받으세요: +이메일을 예로 들어, 새 인증 코드를 요청하고 인증 기록 ID를 받으세요: ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ @@ -206,7 +206,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v ### 인증 기록 ID와 함께 요청 보내기 \{#send-request-with-verification-record-id} -사용자 식별자를 업데이트하는 요청을 보낼 때는, 요청 헤더의 `logto-verification-id` 필드에 인증 기록 ID를 포함해야 합니다. +사용자 식별자를 업데이트하는 요청을 보낼 때, 요청 헤더의 `logto-verification-id` 필드에 인증 기록 ID를 포함해야 합니다. ### 사용자 비밀번호 변경 \{#update-users-password} @@ -220,6 +220,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +회원가입 시 생성된 비밀번호와 마찬가지로, Account API를 통해 설정된 비밀번호도 콘솔 > 보안 > 비밀번호 정책에서 구성한 [비밀번호 정책](/security/password-policy)을 준수해야 합니다. 정책에 위배될 경우 Logto는 상세한 검증 결과와 오류 메시지를 반환합니다. +::: + ### 새 이메일 업데이트 또는 연결 \{#update-or-link-new-email} :::note @@ -246,7 +250,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}' ``` -코드 인증 후, [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail)로 사용자의 이메일을 업데이트할 수 있으며, `verificationId`를 요청 본문의 `newIdentifierVerificationRecordId`로 설정하세요. +코드 인증 후, [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail)을 호출하여 사용자의 이메일을 업데이트할 수 있습니다. `verificationId`를 요청 본문의 `newIdentifierVerificationRecordId`로 설정하세요. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -256,6 +260,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +회원가입 시 수집된 이메일과 마찬가지로, Account API를 통해 연결된 모든 이메일은 콘솔 > 보안 > 차단 목록에서 구성한 [차단 목록](/security/blocklist) 검증을 통과해야 합니다. 정책 위반 시 Logto는 요청을 거부하고 상세 오류를 반환합니다. +::: + ### 사용자 이메일 삭제 \{#remove-the-users-email} 사용자 이메일을 삭제하려면 [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) 엔드포인트를 사용할 수 있습니다. @@ -276,7 +284,7 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### 새 소셜 연결 추가 \{#link-a-new-social-connection} -새 소셜 연결을 추가하려면, 먼저 [`POST /api/verifications/social`](https://openapi.logto.io/operation/operation-createverificationbysocial)로 인증 URL을 요청해야 합니다. +새 소셜 연결을 추가하려면, 먼저 [`POST /api/verifications/social`](https://openapi.logto.io/operation/operation-createverificationbysocial)로 인가 (Authorization) URL을 요청해야 합니다. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social \ @@ -285,13 +293,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ --data-raw '{"connectorId":"...","redirectUri":"...","state":"..."}' ``` -- `connectorId`: [소셜 커넥터](/connectors/social-connectors/)의 ID. -- `redirectUri`: 사용자가 애플리케이션을 인증한 후 리디렉션될 URI. 이 URL에 웹 페이지를 호스팅하고 콜백을 받아야 합니다. -- `state`: 인증 후 반환될 상태값. CSRF 공격 방지를 위한 임의 문자열입니다. +- `connectorId`: [소셜 커넥터](/connectors/social-connectors/)의 ID +- `redirectUri`: 사용자가 애플리케이션 인가 (Authorization) 후 리디렉션될 URI. 이 URL에 웹 페이지를 호스팅하고 콜백을 받아야 합니다. +- `state`: 인가 (Authorization) 후 반환될 상태값. CSRF 공격 방지를 위한 임의 문자열입니다. -응답에서 `verificationRecordId`를 확인하고, 이후에 사용할 수 있도록 저장하세요. +응답에서 `verificationRecordId`를 확인하고, 이후 단계에서 사용하세요. -사용자가 애플리케이션을 인증하면, `redirectUri`로 `state` 파라미터와 함께 콜백을 받게 됩니다. 이후 [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) 엔드포인트로 소셜 연결을 인증할 수 있습니다. +사용자가 애플리케이션을 인가 (Authorization)하면, `redirectUri`로 `state` 파라미터와 함께 콜백을 받게 됩니다. 이후 [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) 엔드포인트로 소셜 연결을 인증할 수 있습니다. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ @@ -300,7 +308,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -`connectorData`는 사용자가 애플리케이션을 인증한 후 소셜 커넥터에서 반환된 데이터입니다. 콜백 페이지에서 `redirectUri`의 쿼리 파라미터를 파싱하여 JSON으로 감싸 `connectorData` 필드 값으로 전달해야 합니다. +`connectorData`는 사용자가 애플리케이션을 인가 (Authorization)한 후 소셜 커넥터에서 반환된 데이터입니다. 콜백 페이지에서 `redirectUri`의 쿼리 파라미터를 파싱하여 JSON으로 감싸 `connectorData` 필드 값으로 전달해야 합니다. 마지막으로, [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) 엔드포인트로 소셜 연결을 추가할 수 있습니다. @@ -336,14 +344,14 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connecto WebAuthn 패스키는 **Relying Party ID (RP ID)**라 불리는 특정 호스트네임에 바인딩됩니다. 해당 Origin에서 호스팅되는 애플리케이션만 해당 패스키로 등록/인증할 수 있습니다. -프론트엔드 애플리케이션이 Logto 인증 페이지와 다른 도메인에서 Account API를 호출하는 경우, **Related Origins**를 구성하여 교차 Origin 패스키 작업을 허용해야 합니다. +프론트엔드 애플리케이션이 Logto 인증 페이지와 다른 도메인에서 Account API를 호출하는 경우, **관련 Origin**을 구성하여 교차 Origin 패스키 작업을 허용해야 합니다. -**Logto의 RP ID 결정 방식:** +**Logto가 RP ID를 결정하는 방법:** - **기본 설정**: Logto의 기본 도메인 `https://[tenant-id].logto.app`만 사용하는 경우, RP ID는 `[tenant-id].logto.app`입니다. - **커스텀 도메인**: [커스텀 도메인](/logto-cloud/custom-domain) `https://auth.example.com`을 구성한 경우, RP ID는 `auth.example.com`이 됩니다. -**Related Origins 구성:** +**관련 Origin 구성:** [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) 엔드포인트로 프론트엔드 앱의 Origin을 추가하세요. 예를 들어, 앱의 계정 센터가 `https://account.example.com`에서 동작한다면: @@ -354,11 +362,21 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -관련 Origin에 대해 더 알아보려면 [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) 문서를 참고하세요. +:::note + +WebAuthn은 관련 Origin으로 최대 5개의 고유 eTLD+1 레이블을 지원합니다. eTLD+1(유효 최상위 도메인 + 1)은 등록 가능한 도메인 부분입니다. 예시: + +- `https://example.com`, `https://app.example.com`, `https://auth.example.com`은 **하나**의 레이블(`example.com`)로 간주 +- `https://shopping.com`, `https://shopping.co.uk`, `https://shopping.co.jp`도 **하나**의 레이블(`shopping`)로 간주 +- `https://example.com`과 `https://another.com`은 **두 개**의 레이블로 간주 -**2단계: 새 등록 옵션 요청** +관련 Origin으로 5개 이상의 도메인을 지원해야 한다면 [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) 문서를 참고하세요. -[`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) 엔드포인트로 새 패스키 등록을 요청하세요. Logto는 각 사용자 계정에 여러 패스키 등록을 허용합니다. +::: + +**2단계: 신규 등록 옵션 요청** + +[`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) 엔드포인트로 새 패스키 등록을 요청하세요. Logto는 각 사용자 계정에 여러 개의 패스키 등록을 허용합니다. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration \ @@ -403,8 +421,8 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registrat --data-raw '{"payload":"...","verificationRecordId":"..."}' ``` -- `payload`: 2단계에서 로컬 브라우저가 반환한 응답. -- `verificationRecordId`: 1단계에서 서버가 반환한 인증 기록 ID. +- `payload`: 2단계에서 로컬 브라우저가 반환한 응답 +- `verificationRecordId`: 1단계에서 서버가 반환한 인증 기록 ID **5단계: 패스키 연결** @@ -418,9 +436,9 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"WebAuthn","newIdentifierVerificationRecordId":"..."}' ``` -- `verification_record_id`: 사용자의 기존 요소 인증을 통해 부여된 유효한 인증 기록 ID. 자세한 내용은 [인증 기록 ID 받기](#get-a-verification-record-id) 섹션을 참고하세요. -- `type`: MFA 요소 유형, 현재는 `WebAuthn`만 지원됩니다. -- `newIdentifierVerificationRecordId`: 1단계에서 서버가 반환한 인증 기록 ID. +- `verification_record_id`: 사용자의 기존 요소 인증을 통해 부여받은 유효한 인증 기록 ID. 자세한 내용은 [인증 기록 ID 받기](#get-a-verification-record-id) 섹션을 참고하세요. +- `type`: MFA 요소 타입, 현재는 `WebAuthn`만 지원 +- `newIdentifierVerificationRecordId`: 1단계에서 서버가 반환한 인증 기록 ID ### 기존 WebAuthn 패스키 관리 \{#manage-existing-webauthn-passkeys} @@ -431,7 +449,7 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \ -H 'authorization: Bearer ' ``` -응답 본문 예시: +응답 예시: ```json [ @@ -446,10 +464,10 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \ ] ``` -- `id`: 인증 요소의 ID. -- `type`: 인증 요소 유형, WebAuthn 패스키의 경우 `WebAuthn`. -- `name`: 패스키 이름(선택 필드). -- `agent`: 패스키의 사용자 에이전트. +- `id`: 인증 요소의 ID +- `type`: 인증 요소 타입, WebAuthn 패스키의 경우 `WebAuthn` +- `name`: 패스키 이름(선택) +- `agent`: 패스키의 사용자 에이전트 패스키 이름을 업데이트하려면 [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname) 엔드포인트를 사용하세요: @@ -489,7 +507,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp -H 'content-type: application/json' ``` -응답 본문 예시: +응답 예시: ```json { @@ -504,7 +522,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp QR 코드의 URI 형식은 다음과 같습니다: ``` -otpauth://totp/[Issuer]:[Account]?secret=[Secret]&issuer=[Issuer] +otpauth://totp/[발급자]:[계정]?secret=[시크릿]&issuer=[발급자] ``` 예시: @@ -525,9 +543,9 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"Totp","secret":"..."}' ``` -- `verification_record_id`: 사용자의 기존 요소 인증을 통해 부여된 유효한 인증 기록 ID. 자세한 내용은 [인증 기록 ID 받기](#get-a-verification-record-id) 섹션을 참고하세요. +- `verification_record_id`: 사용자의 기존 요소 인증을 통해 부여받은 유효한 인증 기록 ID. 자세한 내용은 [인증 기록 ID 받기](#get-a-verification-record-id) 섹션을 참고하세요. - `type`: 반드시 `Totp`여야 합니다. -- `secret`: 1단계에서 생성한 TOTP 시크릿. +- `secret`: 1단계에서 생성한 TOTP 시크릿 :::note 사용자는 한 번에 하나의 TOTP 요소만 가질 수 있습니다. 이미 TOTP 요소가 있는 경우, 추가 시도 시 422 오류가 발생합니다. @@ -553,7 +571,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/back -H 'content-type: application/json' ``` -응답 본문 예시: +응답 예시: ```json { @@ -563,18 +581,18 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/back **2단계: 사용자에게 백업 코드 표시** -백업 코드를 사용자 계정에 바인딩하기 전에, 반드시 사용자에게 코드를 표시하고 다음을 안내하세요: +백업 코드를 사용자 계정에 바인딩하기 전에, 사용자에게 코드를 표시하고 다음을 안내해야 합니다: -- 즉시 다운로드하거나 적어두세요 +- 즉시 코드를 다운로드하거나 적어두세요 - 안전한 장소에 보관하세요 - 각 코드는 한 번만 사용할 수 있습니다 -- 주 MFA 수단을 잃어버렸을 때 마지막 수단임을 인지하세요 +- 주요 MFA 수단을 잃어버린 경우 마지막 수단임을 인지하세요 -코드는 복사하기 쉽고 명확하게 표시하고, 다운로드 옵션(예: 텍스트 파일, PDF 등)도 제공하는 것이 좋습니다. +코드를 명확하고 복사하기 쉬운 형식으로 표시하고, 다운로드 옵션(예: 텍스트 파일, PDF 등)도 제공하는 것이 좋습니다. **3단계: 백업 코드를 사용자 계정에 바인딩** -[`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 엔드포인트로 백업 코드를 계정에 바인딩하세요. +[`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 엔드포인트로 백업 코드를 사용자 계정에 바인딩하세요. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -584,13 +602,13 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"BackupCode","codes":["...","...","..."]}' ``` -- `verification_record_id`: 사용자의 기존 요소 인증을 통해 부여된 유효한 인증 기록 ID. 자세한 내용은 [인증 기록 ID 받기](#get-a-verification-record-id) 섹션을 참고하세요. +- `verification_record_id`: 사용자의 기존 요소 인증을 통해 부여받은 유효한 인증 기록 ID. 자세한 내용은 [인증 기록 ID 받기](#get-a-verification-record-id) 섹션을 참고하세요. - `type`: 반드시 `BackupCode`여야 합니다. -- `codes`: 이전 단계에서 생성한 백업 코드 배열. +- `codes`: 이전 단계에서 생성한 백업 코드 배열 :::note -- 사용자는 한 번에 한 세트의 백업 코드만 가질 수 있습니다. 모든 코드를 사용한 경우, 새 코드를 생성하고 바인딩해야 합니다. +- 사용자는 한 번에 한 세트의 백업 코드만 가질 수 있습니다. 모든 코드를 사용한 경우, 새 코드를 생성하여 바인딩해야 합니다. - 백업 코드는 유일한 MFA 요소가 될 수 없습니다. 사용자는 최소 하나 이상의 다른 MFA 요소(WebAuthn 또는 TOTP 등)를 활성화해야 합니다. - 각 백업 코드는 한 번만 사용할 수 있습니다. @@ -605,7 +623,7 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes -H 'authorization: Bearer ' ``` -응답 본문 예시: +응답 예시: ```json { @@ -622,5 +640,5 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes } ``` -- `code`: 백업 코드. -- `usedAt`: 코드가 사용된 시각. 아직 사용되지 않았다면 `null`입니다. +- `code`: 백업 코드 +- `usedAt`: 코드가 사용된 시각, 아직 사용되지 않았다면 `null` diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index 1ff76ad2e9d..075a1b37159 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -4,7 +4,7 @@ sidebar_position: 2 # 첫 화면 파라미터 -최종 사용자에게 원하는 첫 화면 경험을 맞춤화할 수 있도록 하는 인증 (Authentication) 파라미터 세트입니다. +엔드 유저에게 원하는 첫 화면 경험을 맞춤화할 수 있도록 하는 인증 (Authentication) 파라미터 세트입니다. - `first_screen`: 사용자가 처음 보게 될 화면을 지정합니다. - `identifier`: 로그인 또는 회원가입 폼에서 허용할 식별자 유형을 지정합니다. @@ -14,25 +14,29 @@ sidebar_position: 2 `first_screen` 파라미터는 사용자가 Logto의 로그인 페이지로 리디렉션될 때 처음 보게 될 화면을 결정하는 핵심 파라미터입니다. 기본적으로는 범용 로그인 폼이 표시됩니다. 이 파라미터를 사용하여 애플리케이션의 요구 사항에 따라 첫 화면을 맞춤화할 수 있습니다. 지원되는 값은 다음과 같습니다: -- `sign_in`: 로그인 폼을 표시합니다. (기본값) +- `sign_in` (기본값): 로그인 폼을 표시합니다. - `register`: 회원가입 폼을 표시합니다. - `reset_password`: 비밀번호 재설정 폼을 표시합니다. - `single_sign_on`: 엔터프라이즈 싱글 사인온 (SSO) 로그인 폼을 표시합니다. (활성화된 SSO 제공자를 결정하기 위해 이메일 주소를 요청합니다) -- `identifier:sign-in`: 특정 식별자 로그인 폼을 표시합니다. 식별자 유형은 `identifier` 파라미터로 지정할 수 있습니다. 여러 식별자 로그인 방식을 활성화한 경우 유용합니다. -- `identifier:register`: 특정 식별자 회원가입 폼을 표시합니다. 식별자 유형은 `identifier` 파라미터로 지정할 수 있습니다. 여러 식별자 회원가입 방식을 활성화한 경우 유용합니다. +- `identifier:sign-in`: 특정 식별자 로그인 폼을 표시합니다. 식별자 유형은 `identifier` 파라미터로 지정할 수 있습니다 (선택 사항). 여러 식별자 로그인 방식을 활성화한 경우 유용합니다. +- `identifier:register`: 특정 식별자 회원가입 폼을 표시합니다. 식별자 유형은 `identifier` 파라미터로 지정할 수 있습니다 (선택 사항). 여러 식별자 회원가입 방식을 활성화한 경우 유용합니다. 첫 화면 파라미터 -예를 들어, 사용자를 엔터프라이즈 싱글 사인온 (SSO) 로그인 폼으로 바로 보내는 경우: +예를 들어, 사용자를 엔터프라이즈 SSO 로그인 폼으로 바로 보내는 경우: ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +첫 화면은 콘솔 > 로그인 경험에서 설정한 구성에 따릅니다. 먼저 필요한 인증 (Authentication) 방식을 활성화하고, 브랜딩, 약관 및 개인정보 처리방침, 국제화(i18n)를 설정해야 합니다. 기본적으로 `sign-in` 및 `register` 페이지에만 로고가 표시됩니다. +::: + ## identifier \{#identifier} -`identifier` 파라미터는 로그인 또는 회원가입 폼에서 사용할 식별자 유형을 지정하는 데 사용됩니다. 이 파라미터는 `first_screen` 파라미터가 `identifier:sign-in`, `identifier:register`, 또는 `reset_password`로 설정된 경우에만 적용됩니다. 지원되는 값은 `username`, `email`, `phone`입니다. 여러 값을 허용하려면 공백으로 구분하세요. +`identifier` 파라미터는 로그인 또는 회원가입 폼에서 사용할 식별자 유형을 지정하는 데 사용됩니다. 이 파라미터는 `first_screen` 파라미터가 `identifier:sign-in`, `identifier:register` 또는 `reset_password`로 설정된 경우에만 적용됩니다. 지원되는 값은 `username`, `email`, `phone`입니다. 여러 값을 허용하려면 공백으로 구분하세요. 예를 들어, 사용자를 이메일 또는 전화번호 회원가입 페이지로 바로 보내는 경우: @@ -43,13 +47,13 @@ curl --location \ 이 파라미터에 지정된 모든 식별자 유형은 Logto 콘솔의 로그인 또는 회원가입 설정에서 활성화되어 있어야 합니다. -지원되지 않거나 비활성화된 식별자 유형은 무시됩니다. 지정된 모든 식별자가 지원되지 않는 경우, 기본 로그인 경험 설정이 사용됩니다. +지원되지 않거나 비활성화된 식별자 유형은 무시됩니다. 지정한 모든 식별자가 지원되지 않는 경우, 기본 로그인 경험 구성이 사용됩니다. ## login_hint \{#login_hint} -`login_hint` 파라미터는 표준 [OpenID Connect 사양](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint)에 정의되어 있으며, 로그인 폼에 사용자의 식별자(이메일, 전화번호 또는 사용자 이름 등)를 미리 채우는 데 사용됩니다. Logto에서는 다른 로그인 화면 파라미터와 결합하여 사용자 경험을 향상시킬 수 있습니다. 이 파라미터는 사전에 사용자의 식별자를 수집하는 맞춤형 사전 인증 (Authentication) 폼이 있는 경우, 로그인 시 다시 입력하지 않아도 되도록 할 때 특히 유용합니다. +[OpenID Connect 사양](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint)에 정의된 `login_hint` 파라미터는 로그인 폼의 식별자(이메일, 전화번호 또는 사용자 이름 등)를 미리 채우는 데 사용됩니다. Logto에서는 이 파라미터를 다른 로그인 화면 파라미터와 결합하여 사용자 경험을 향상시킬 수 있습니다. 이 파라미터는 사전에 사용자의 식별자를 수집하는 맞춤형 사전 인증 (Authentication) 폼이 있는 경우, 로그인 시 재입력을 건너뛸 수 있어 특히 유용합니다. -예를 들어, 수집된 이메일 주소를 로그인 폼에 미리 채우는 경우: +예를 들어, 수집한 이메일 주소를 로그인 폼에 미리 채우는 경우: ```sh curl --location \ @@ -70,7 +74,7 @@ logtoClient.signIn({ ``` :::note -`first_screen`, `identifier`, `login_hint` 파라미터에 대한 지원을 모든 Logto SDK에 점진적으로 추가하고 있습니다. 해당 파라미터가 SDK에 보이지 않는 경우, 이슈를 등록하거나 문의해 주세요. +`first_screen`, `identifier`, `login_hint` 파라미터에 대한 지원을 모든 Logto SDK에 점진적으로 추가하고 있습니다. SDK에서 해당 파라미터가 보이지 않는 경우, 이슈를 등록하거나 문의해 주세요. [Logto OSS](/logto-oss) 사용자의 경우, 이 파라미터들은 1.15.0 버전부터 지원됩니다. 이전 버전을 사용 중이라면 [최신 버전으로 업그레이드](/logto-oss/upgrading-oss-version)해 주세요. ::: diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index 2418ec86be8..2dde383920f 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -11,12 +11,13 @@ Logto는 표준 OIDC 인증 (Authentication) 파라미터인 `ui_locales`를 지 - 런타임에 Logto 호스팅 로그인 경험의 UI 언어를 결정합니다. Logto는 `ui_locales`에 있는 언어 태그 중 테넌트의 언어 라이브러리에서 지원되는 첫 번째 태그를 선택합니다. - 상호작용에 의해 트리거된 메시지(예: 인증 코드 이메일)의 이메일 현지화에 영향을 줍니다. 자세한 내용은 [이메일 템플릿 현지화](/connectors/email-connectors/email-templates#email-template-localization)를 참고하세요. - 원래 값을 이메일 템플릿의 변수 `uiLocales`로 노출하여, 필요하다면 이메일 제목/내용에 포함할 수 있습니다. +- 로그인 경험에서 기본 전화번호 국가 코드를 설정합니다. 예를 들어, `ui_locales=fr`이면 전화번호 입력란의 기본값이 프랑스 (+33)로 설정됩니다. 이는 특정 사용자 그룹이나 지역에 대해 기본 국가 코드를 프로그래밍적으로 제어하고자 할 때 유용합니다. ## 파라미터 형식 \{#parameter-format} - 이름: `ui_locales` - 타입: `string` -- 값: BCP 47 언어 태그의 공백으로 구분된 목록, 예시: `fr-CA fr en` +- 값: 공백으로 구분된 BCP 47 언어 태그 목록, 예시: `fr-CA fr en` - 참고: [OpenID Connect Core - ui_locales](https://openid.net/specs/openid-connect-core-1_0.html) ## 결정 순서 및 우선순위 \{#resolution-order-and-precedence} @@ -25,7 +26,7 @@ Logto는 표준 OIDC 인증 (Authentication) 파라미터인 `ui_locales`를 지 1. 현재 인증 (Authentication) 요청의 `ui_locales` (지원되는 첫 번째 태그가 우선). 2. 그렇지 않으면, `Accept-Language` 헤더 (경험 (Experience) API / 사용자 계정 (Account) API) 또는 `messagePayload.locale` (조직 초대와 같은 Management API). -3. 그렇지 않으면, 로그인 경험에 설정된 테넌트의 기본 언어. +3. 그렇지 않으면, 로그인 경험에서 설정된 테넌트의 기본 언어. 이 동작은 언어 설정을 영구적으로 변경하지 않으며, 현재 상호작용에만 적용됩니다. @@ -44,7 +45,7 @@ await logtoClient.signIn({ ## 예시 \{#examples} -- `ui_locales=fr-CA fr en` → 언어 라이브러리에 `fr-CA`가 있으면 로그인 UI가 프랑스어(캐나다)로 표시됩니다. 없으면 `fr`, 그다음 `en` 순으로 대체됩니다. +- `ui_locales=fr-CA fr en` → 언어 라이브러리에 `fr-CA`가 있으면 로그인 UI가 프랑스어(캐나다)로 표시됩니다. 없으면 `fr`, 그 다음 `en` 순으로 대체됩니다. - `ui_locales=ja`이지만 일본어가 활성화되어 있지 않으면 → `Accept-Language` 또는 테넌트 기본값으로 대체됩니다. ## 관련 문서 \{#related} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index 1ef3a0a74e3..c2f00394fde 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -2,105 +2,106 @@ sidebar_position: 2 --- -# 이메일 / 전화번호 / 사용자 이름 로그인 +# 이메일 / 전화번호 / 사용자명 로그인 -## 식별자 로그인 흐름 구성 \{#configure-the-identifier-sign-in-flow} +## 식별자 로그인 플로우 구성하기 \{#configure-the-identifier-sign-in-flow} -앞서 언급했듯이, 다양한 식별자 유형은 [가입 흐름](/end-user-flows/sign-up-and-sign-in/sign-up) 또는 [Logto에서의 직접 계정 생성](/user-management/manage-users#add-users) 중에 사용자로부터 수집될 수 있습니다. 또한, 사용자가 제품을 탐색하고 활용하면서 추가 정보를 입력하고 완료할 수 있습니다. 이러한 식별자는 Logto 시스템에서 사용자를 고유하게 식별하고, Logto와 통합된 애플리케이션에 인증 및 로그인을 허용하는 데 사용될 수 있습니다. +앞서 언급했듯이, 다양한 식별자 유형은 [회원가입 플로우](/end-user-flows/sign-up-and-sign-in/sign-up) 또는 [Logto에서 직접 계정 생성](/user-management/manage-users#add-users) 과정에서 사용자로부터 수집될 수 있습니다. 또한, 사용자는 제품을 탐색하고 활용하는 과정에서 추가 정보를 입력하고 완료할 수 있습니다. 이러한 식별자는 Logto 시스템에서 사용자를 고유하게 식별하고, Logto와 통합된 애플리케이션에 인증 (Authentication) 및 로그인을 할 수 있도록 해줍니다. -Logto가 호스팅하는 사전 구축된 로그인 페이지를 사용하든 [사용자 정의 로그인 UI를 구축](/customization#custom-ui)하든, 최종 사용자에게 제공할 로그인 방법 및 인증 설정을 구성해야 합니다. +Logto에서 호스팅하는 기본 로그인 페이지를 사용할지, 아니면 [맞춤형 로그인 UI를 직접 구축](/customization#custom-ui)할지에 관계없이, 최종 사용자에게 제공할 로그인 방식과 인증 설정을 구성해야 합니다. -## 식별자 및 인증 설정 구성 \{#set-up-the-identifier-and-authentication-settings} +## 식별자 및 인증 설정하기 \{#set-up-the-identifier-and-authentication-settings} -### 1. 지원되는 로그인 식별자 설정 \{#1-set-the-supported-sign-in-identifiers} +### 1. 지원하는 로그인 식별자 설정하기 \{#1-set-the-supported-sign-in-identifiers} -드롭다운 목록에서 여러 지원 식별자를 최종 사용자를 위한 활성화된 로그인 방법으로 추가할 수 있습니다. 사용 가능한 옵션은 다음과 같습니다: +드롭다운 목록에서 여러 개의 지원 식별자를 추가하여 최종 사용자를 위한 로그인 방식으로 활성화할 수 있습니다. 사용 가능한 옵션은 다음과 같습니다: -- **사용자 이름** +- **사용자명** - **이메일 주소** - **전화번호** -식별자의 순서를 변경하면 로그인 페이지에 표시되는 순서가 변경됩니다. 첫 번째 식별자는 사용자의 기본 로그인 방법이 됩니다. +식별자의 순서를 변경하면 로그인 페이지에 표시되는 순서가 바뀝니다. 첫 번째 식별자가 사용자의 기본 로그인 방식이 됩니다. -### 2. 인증 설정 구성 \{#2-set-the-authentication-settings} +### 2. 인증 설정 구성하기 \{#2-set-the-authentication-settings} -각 로그인 식별자에 대해 사용자의 아이덴티티를 확인하기 위한 최소한의 효과적인 인증 요소를 구성해야 합니다. 선택할 수 있는 두 가지 요소가 있습니다: +각 로그인 식별자에 대해, 사용자의 신원을 확인할 수 있는 최소 한 개의 유효한 인증 요소를 구성해야 합니다. 선택할 수 있는 두 가지 요소는 다음과 같습니다: -- **비밀번호**: 모든 유형의 로그인 식별자에 사용할 수 있습니다. 활성화되면 사용자는 로그인 과정을 완료하기 위해 비밀번호를 제공해야 합니다. -- **인증 코드**: **이메일 주소** 및 **전화번호** 식별자에만 사용할 수 있습니다. 활성화되면 사용자는 이메일 또는 전화번호로 전송된 인증 코드를 입력하여 로그인 과정을 완료해야 합니다. +- **비밀번호**: 모든 유형의 로그인 식별자에 사용할 수 있습니다. 활성화하면 사용자는 로그인 과정에서 비밀번호를 입력해야 합니다. +- **인증 코드**: **이메일 주소** 및 **전화번호** 식별자에서만 사용할 수 있습니다. 활성화하면 사용자는 이메일 또는 전화번호로 전송된 인증 코드를 입력해야 로그인할 수 있습니다. -두 요소가 모두 활성화된 경우, 사용자는 로그인 과정을 완료하기 위해 두 방법 중 하나를 선택할 수 있습니다. 요소의 순서를 변경하여 로그인 페이지에 표시되는 순서를 변경할 수 있습니다. 첫 번째 요소는 사용자의 기본 인증 방법으로 사용되며, 두 번째 요소는 대체 링크로 표시됩니다. +두 요소가 모두 활성화된 경우, 사용자는 두 가지 방법 중 하나를 선택하여 로그인할 수 있습니다. 또한 요소의 순서를 변경하여 로그인 페이지에 표시되는 순서를 바꿀 수 있습니다. 첫 번째 요소가 사용자의 기본 인증 방식이 되며, 두 번째 요소는 대체 링크로 표시됩니다. -## 식별자 로그인 흐름 사용자 경험 \{#identifier-sign-in-flow-user-experience} +## 식별자 로그인 플로우 사용자 경험 \{#identifier-sign-in-flow-user-experience} -로그인 경험은 선택한 식별자와 사용 가능한 인증 요소에 따라 조정됩니다. +로그인 경험은 선택한 식별자와 사용 가능한 인증 요소에 따라 달라집니다. -- **다중 식별자를 위한 스마트 입력:** - 하나 이상의 식별자 로그인 방법이 활성화된 경우, Logto 내장 로그인 페이지는 사용자가 입력한 식별자 유형을 자동으로 감지하고 해당 인증 옵션을 표시합니다. 예를 들어, **이메일 주소**와 **전화번호**가 모두 활성화된 경우, 로그인 페이지는 사용자가 입력한 식별자 유형을 자동으로 감지하고 해당 인증 옵션을 표시합니다. 숫자가 연속적으로 입력되면 지역 코드가 포함된 전화번호 형식으로 전환되거나 "@" 기호가 사용되면 이메일 형식으로 전환됩니다. +- **여러 식별자에 대한 스마트 입력:** + 둘 이상의 식별자 로그인 방식이 활성화된 경우, Logto 기본 로그인 페이지는 사용자가 입력한 식별자 유형을 자동으로 감지하여 해당 인증 옵션을 표시합니다. 예를 들어, **이메일 주소**와 **전화번호**가 모두 활성화된 경우, 로그인 페이지는 사용자가 입력한 식별자 유형을 자동으로 감지하여 해당 인증 옵션을 표시합니다. 연속된 숫자가 입력되면 국가 코드가 포함된 전화번호 형식으로, "@" 기호가 입력되면 이메일 형식으로 전환됩니다. + - 전화번호 국가 코드는 사용자의 브라우저 로케일을 기본값으로 사용합니다. 사용자는 수동으로 변경할 수 있습니다. [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 파라미터를 사용하여 특정 기본 국가 코드를 설정할 수 있습니다. 자세한 내용은 [현지화 언어](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience)를 참고하세요. - **활성화된 인증 요소:** - - **비밀번호만:** 첫 번째 화면에 식별자와 비밀번호 필드가 표시됩니다. - - **인증 코드만:** 첫 번째 화면에 식별자 필드가 나타나고, 두 번째 화면에 인증 코드 필드가 나타납니다. - - **비밀번호와 인증 코드:** 첫 번째 화면에 식별자 필드가 입력되고, 두 번째 화면에서 인증 순서에 따라 비밀번호 또는 인증 코드를 입력하는 단계가 이어집니다. 사용자가 두 가지 인증 방법 간에 전환할 수 있도록 전환 링크가 제공됩니다. + - **비밀번호만 사용:** 첫 화면에 식별자와 비밀번호 입력란이 모두 표시됩니다. + - **인증 코드만 사용:** 첫 화면에 식별자 입력란이, 두 번째 화면에 인증 코드 입력란이 표시됩니다. + - **비밀번호와 인증 코드 모두 사용:** 첫 화면에 식별자 입력란이 표시되고, 두 번째 화면에서 인증 순서에 따라 비밀번호 또는 인증 코드 입력 단계로 이동합니다. 두 인증 방식 간 전환할 수 있는 링크가 제공됩니다. ### 예시 \{#examples}
-### 예시 1: 비밀번호 인증이 있는 이메일 주소 \{#example-1-email-address-with-password-verification} +### 예시 1: 이메일 주소 + 비밀번호 인증 \{#example-1-email-address-with-password-verification} -**이메일 주소**를 로그인 식별자로 추가하고 **비밀번호** 요소를 인증에 사용하도록 활성화합니다. +**이메일 주소**를 로그인 식별자로 추가하고, 인증 요소로 **비밀번호**를 활성화하세요. -비밀번호 인증이 있는 이메일 주소 +비밀번호 인증이 적용된 이메일 주소
-### 예시 2: 비밀번호(기본) 및 인증 코드(대체) 인증이 활성화된 이메일/전화번호 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} +### 예시 2: 이메일/전화번호 + 비밀번호(기본) 및 인증 코드(대체) 인증 활성화 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} -**이메일 주소**와 **전화번호**를 모두 로그인 식별자로 추가합니다. -두 식별자에 대해 **비밀번호** 및 **인증 코드** 요소를 활성화합니다. +**이메일 주소**와 **전화번호**를 모두 로그인 식별자로 추가하세요. +두 식별자 모두에 대해 **비밀번호**와 **인증 코드** 요소를 활성화하세요. 비밀번호 및 인증 코드 인증이 있는 이메일/전화번호
-## 로그인 시 추가 사용자 프로필 수집 \{#collect-additional-user-profile-on-sign-in} +## 로그인 시 추가 사용자 프로필 수집하기 \{#collect-additional-user-profile-on-sign-in} -Logto의 로그인 흐름에서는 가입 식별자 설정이 업데이트되면 프로필 이행 과정이 시작될 수 있습니다. 이는 기존 사용자를 포함하여 모든 사용자가 새로 요구되는 식별자를 제공하도록 보장합니다. +Logto의 로그인 플로우에서는 회원가입 식별자 설정이 변경된 경우 프로필 보완 과정이 트리거될 수 있습니다. 이를 통해 기존 사용자를 포함한 모든 사용자가 새롭게 요구되는 식별자를 반드시 입력하도록 보장합니다. -개발자가 새로운 식별자 (예: 이메일 주소)를 추가하면 모든 사용자에게 필수 사항이 됩니다. 기존 식별자 (예: 사용자 이름)로 로그인하는 사용자는 프로필에 누락된 경우 새 식별자를 제공하고 인증하도록 요청받습니다. 이 단계를 완료한 후에야 애플리케이션에 접근할 수 있으며, 업데이트된 요구 사항으로의 원활하고 일관된 전환을 보장합니다. +예를 들어, 개발자가 새로운 식별자(예: 이메일 주소)를 추가하면, 모든 사용자에게 해당 식별자가 필수로 요구됩니다. 기존 식별자(예: 사용자명)로 로그인하는 기존 사용자는 프로필에 해당 식별자가 없다면 추가 입력 및 인증을 요구받게 됩니다. 이 단계를 완료해야만 애플리케이션에 접근할 수 있으므로, 변경된 요구사항으로의 전환이 원활하고 일관되게 이루어집니다. -과정을 세분화하면: +과정 요약: -1. **사용자 이름**이 이전에 **비밀번호 생성** 설정과 함께 가입 식별자로 설정되었습니다. -2. **이메일 주소**가 나중에 가입 식별자로 설정됩니다. **이메일 주소** 식별자는 자동으로 활성화된 로그인 옵션으로 추가됩니다. -3. 기존 사용자가 사용자 이름과 비밀번호로 로그인합니다. -4. 사용자는 초기 로그인 단계 후 이메일 주소를 제공하고 인증하도록 요청받습니다. +1. **사용자명**이 기존 회원가입 식별자로 설정되어 있고, **비밀번호 생성** 설정이 자동 활성화되어 있습니다. +2. 이후 **이메일 주소**가 회원가입 식별자로 추가됩니다. **이메일 주소** 식별자는 자동으로 활성화된 로그인 옵션으로 추가됩니다. +3. 기존 사용자가 사용자명과 비밀번호로 로그인합니다. +4. 로그인 후, 사용자는 이메일 주소 입력 및 인증을 요구받습니다. ```mermaid flowchart TD - A[로그인 페이지 방문] --> B[사용자 이름과 비밀번호 입력] - B -.-> C{{이메일 주소가 필요하고 누락되었습니까?}} + A[로그인 페이지 방문] --> B[사용자명과 비밀번호 입력] + B -.-> C{{이메일 주소가 필요하지만 없음?}} C -->|예| D[이메일 주소 입력] D --> E[인증 코드 입력] E --> F[로그인 성공] C --> |아니오| F ``` -이 과정은 **비밀번호 생성** 가입 설정에도 동일하게 적용됩니다. 가입 흐름에서 **비밀번호 생성** 설정이 새로 활성화되면, **비밀번호** 요소는 선택한 모든 로그인 식별자에 대해 자동으로 활성화됩니다. 비밀번호가 없는 모든 기존 사용자는 로그인 과정에서 비밀번호를 생성하라는 메시지를 받게 됩니다. +동일한 과정은 **비밀번호 생성** 회원가입 설정에도 적용됩니다. 회원가입 플로우에서 **비밀번호 생성** 설정이 새롭게 활성화되면, 선택한 모든 로그인 식별자에 대해 **비밀번호** 요소가 자동으로 활성화됩니다. 비밀번호가 없는 기존 사용자는 로그인 과정에서 비밀번호를 생성하도록 안내받게 됩니다. :::note -참고: 사용자 정의 로그인 흐름에 대해서는 [UI 가져오기](/customization/bring-your-ui/) 기능을 참조하세요. +참고: 맞춤형 로그인 플로우의 경우, [Bring your UI](/customization/bring-your-ui/) 기능을 참고하세요. ::: ## 자주 묻는 질문 \{#faqs} @@ -112,12 +113,12 @@ flowchart TD -Logto는 현재 로그인 및 가입을 위한 헤드리스 API를 지원하지 않습니다. 그러나 [UI 가져오기](/customization/bring-your-ui/) 기능을 사용하여 사용자 정의 로그인 양식을 Logto에 업로드할 수 있습니다. 또한, 애플리케이션에서 수집한 사용자 식별자로 로그인 양식을 미리 채우거나 타사 소셜 또는 엔터프라이즈 SSO 제공자로 직접 로그인할 수 있는 여러 로그인 매개변수를 지원합니다. 자세한 내용은 [인증 매개변수](/end-user-flows/authentication-parameters/)를 참조하세요. +Logto는 현재 로그인 및 회원가입을 위한 헤드리스 API를 지원하지 않습니다. 하지만, [Bring your UI](/customization/bring-your-ui/) 기능을 사용하여 맞춤형 로그인 폼을 Logto에 업로드할 수 있습니다. 또한, 애플리케이션에서 수집한 사용자 식별자를 미리 입력하거나, 소셜 또는 엔터프라이즈 SSO 제공자를 통해 직접 로그인할 수 있도록 여러 로그인 파라미터를 지원합니다. 자세한 내용은 [인증 (Authentication) 파라미터](/end-user-flows/authentication-parameters/)를 참고하세요. ## 관련 리소스 \{#related-resources} -이메일 가입 및 로그인 경험 +이메일 회원가입 및 로그인 경험 -사용자 이름 가입 및 로그인 경험 +사용자명 회원가입 및 로그인 경험 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index d2af10b1410..a0311493e4c 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -15,25 +15,35 @@ sidebar_position: 1 ## 회원가입 식별자 설정하기 \{#set-up-the-sign-up-identifier} -Logto에서 새 사용자 계정을 성공적으로 생성하려면, 사용자는 Logto 시스템 내에서 자신을 고유하게 식별할 수 있는 **식별자**를 최소 하나 제공해야 합니다. 첫 단계로, 회원가입 과정에서 사용자가 반드시 입력해야 하는 식별자를 선택하세요. 선택 가능한 옵션은 다음과 같습니다: +Logto에서 새 사용자 계정을 성공적으로 생성하려면, 사용자는 Logto 시스템 내에서 자신을 고유하게 식별할 수 있는 최소 하나의 **식별자**를 제공해야 합니다. 첫 단계로, 회원가입 과정에서 사용자가 반드시 제공해야 하는 식별자를 선택하세요. 선택 가능한 옵션은 다음과 같습니다: - **사용자명**: 사용자가 애플리케이션에 로그인할 때 사용할 수 있는 고유한 [사용자명](/user-management/user-data#username). - **이메일 주소**: 사용자가 애플리케이션에 로그인할 때 사용할 수 있는 유효한 [이메일 주소](/user-management/user-data#primary_email). - **전화번호**: 사용자가 애플리케이션에 로그인할 때 사용할 수 있는 유효한 [전화번호](/user-management/user-data#primary_phone). -- **이메일 주소 또는 전화번호**: 사용자가 유효한 이메일 주소 또는 전화번호 중 하나로 회원가입할 수 있도록 허용. +- **이메일 주소 또는 전화번호**: 사용자가 유효한 이메일 주소 또는 전화번호 중 하나로 회원가입할 수 있도록 허용합니다. -회원가입 과정에서 수집된 모든 식별자는 동일한 테넌트 내의 사용자 간에 고유해야 합니다. 이 정보는 [사용자 프로필](/user-management/user-data#user-profile)에 저장되며, Logto와 연동된 애플리케이션 로그인에 사용할 수 있습니다. +회원가입 과정에서 수집된 모든 식별자는 동일 테넌트 내 사용자 간에 고유해야 합니다. 이 정보는 [사용자 프로필](/user-management/user-data#user-profile)에 저장되며, Logto와 연동된 애플리케이션 로그인에 사용할 수 있습니다. 식별자를 선택하지 않으면, [소셜](/end-user-flows/sign-up-and-sign-in/social-sign-in) 전용 또는 [엔터프라이즈 SSO](/end-user-flows/enterprise-sso) 전용 회원가입 방식에 적용됩니다. -회원가입 식별자의 순서를 조정하여 사용자가 회원가입 시 가장 먼저 입력해야 하는 항목을 우선순위로 둘 수 있습니다. 이 순서는 회원가입 과정에 반영되어, 첫 번째 식별자가 초기 등록 화면에 표시되고 나머지는 이후 단계에서 수집됩니다. +회원가입 식별자의 순서를 조정하여 사용자가 회원가입 시 가장 먼저 입력해야 하는 항목을 우선순위로 둘 수 있습니다. 이 순서는 회원가입 과정에 반영되어, 첫 번째 식별자가 초기 등록 화면에 표시되고, 나머지는 이후 단계에서 수집됩니다. + +:::tip +회원가입 시 특정 유형의 이메일 주소(일회용 이메일, 플러스(+) 기호가 포함된 서브어드레싱, 특정 이메일 주소 또는 전체 도메인 등)를 차단하려면, 보안 섹션의 **차단 목록** 기능을 사용하세요. 자세한 내용은 [차단 목록](/security/blocklist)을 참고하세요. +::: + +:::tip +전화번호 **국가 코드**는 사용자의 브라우저 로케일을 기본값으로 사용합니다. 예를 들어, 사용자의 브라우저 언어가 `fr`로 설정되어 있다면, 국가 코드는 프랑스 (+33)로 기본 설정됩니다. + +[`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 인증 (Authentication) 파라미터를 사용하여 로그인 경험 언어를 설정할 수도 있으며, 이 값에 따라 기본 국가 코드가 결정됩니다. +::: ## 회원가입 인증 설정하기 \{#set-up-the-sign-up-verification-settings} -사용자 회원가입 및 향후 로그인 과정의 보안을 위해, 회원가입 과정에서 수집한 식별자에 대한 인증 설정도 구성해야 합니다. 선택 가능한 설정은 다음과 같습니다: +사용자 회원가입 및 향후 로그인 과정의 보안을 위해, 회원가입 과정에서 수집한 식별자에 대한 인증 설정도 구성해야 합니다. 사용 가능한 설정은 다음과 같습니다: -- **비밀번호 생성:** 사용자가 회원가입 시 비밀번호를 생성하도록 요구합니다. 이 비밀번호는 로그인 경험 설정에서 구성한 비밀번호 정책을 따라야 합니다. 이 비밀번호와 사용자의 식별자가 애플리케이션 로그인 자격 증명으로 사용됩니다. **사용자명**을 회원가입 식별자로 설정하면, **사용자명**은 비밀번호와 함께만 사용하여 사용자의 신원을 효과적으로 인증할 수 있으므로 이 요구 사항이 자동으로 활성화됩니다. [비밀번호 정책](/security/password-policy)은 보안 요구 사항에 맞게 커스터마이즈할 수 있습니다. -- **회원가입 시 인증:** 사용자가 회원가입 과정에서 이메일 주소 또는 전화번호를 인증하도록 요구합니다. 현재 Logto는 인증된 이메일 및 전화번호만 식별자로 허용합니다. 이 설정은 **이메일 주소** 또는 **전화번호**가 회원가입 식별자로 사용될 때 자동으로 활성화됩니다. 사용자는 회원가입 과정에서 이메일 또는 전화번호로 전송된 인증 코드를 입력하여 소유권을 확인해야 합니다. +- **비밀번호 생성:** 회원가입 시 사용자가 비밀번호를 생성하도록 요구합니다. 이 비밀번호는 로그인 경험 설정에서 구성한 비밀번호 정책을 따라야 합니다. 이 비밀번호와 사용자의 식별자는 애플리케이션 로그인 시 자격 증명으로 사용됩니다. **사용자명**을 회원가입 식별자로 설정하면, 이 요구 사항이 자동으로 활성화됩니다. **사용자명**은 비밀번호와 함께 사용해야만 사용자의 신원을 효과적으로 인증할 수 있기 때문입니다. [비밀번호 정책](/security/password-policy)은 보안 요구 사항에 맞게 커스터마이즈할 수 있습니다. +- **회원가입 시 인증:** 회원가입 과정에서 사용자의 이메일 주소 또는 전화번호 인증을 요구합니다. 현재 Logto는 인증된 이메일 및 전화번호만 식별자로 허용합니다. 이 설정은 **이메일 주소** 또는 **전화번호**가 회원가입 식별자로 사용될 때 자동으로 활성화됩니다. 사용자는 회원가입 과정에서 이메일 또는 전화번호로 전송된 인증 코드를 입력하여 소유권을 확인해야 합니다. | 식별자 | 비밀번호 생성 | 회원가입 시 인증 | | -------------------- | ------------- | ---------------- | @@ -94,7 +104,7 @@ Logto에서 새 사용자 계정을 성공적으로 생성하려면, 사용자 이메일 및 사용자명 인증, 비밀번호 생성 회원가입 @@ -103,21 +113,21 @@ Logto에서 새 사용자 계정을 성공적으로 생성하려면, 사용자 이러한 전통적인 식별자 회원가입 방식 외에도, Logto는 소셜 및 엔터프라이즈 SSO 아이덴티티 제공자를 통한 비밀번호 없는 회원가입도 지원하여 온보딩 과정을 더욱 원활하고 사용자 친화적으로 만듭니다. -[소셜 커넥터](/connectors/social-connectors) 또는 [엔터프라이즈 SSO 커넥터](/connectors/enterprise-connectors)가 Logto에 구성 및 활성화되면, 사용자는 커넥터가 제공하는 기존 소셜 또는 엔터프라이즈 아이덴티티로 간편하게 회원가입할 수 있습니다. 소셜 및 엔터프라이즈 SSO 회원가입 방식은 비밀번호 생성이나 이메일/전화번호 인증과 같은 추가 단계를 건너뛸 수 있습니다. Logto는 사용자의 인증된 소셜 또는 엔터프라이즈 아이덴티티를 통해 정보를 자동으로 동기화하여 사용자 프로필에 저장합니다. +[소셜 커넥터](/connectors/social-connectors) 또는 [엔터프라이즈 SSO 커넥터](/connectors/enterprise-connectors)가 Logto에 구성 및 활성화되면, 사용자는 커넥터가 제공하는 기존 소셜 또는 엔터프라이즈 아이덴티티로 쉽게 회원가입할 수 있습니다. 소셜 및 엔터프라이즈 SSO 회원가입 방식은 비밀번호 생성이나 이메일/전화번호 인증과 같은 추가 단계를 건너뛸 수 있습니다. Logto는 사용자의 인증된 소셜 또는 엔터프라이즈 아이덴티티를 통해 정보를 자동으로 동기화하고, 이를 사용자 프로필에 저장합니다. -소셜 및 엔터프라이즈 SSO 커넥터를 통한 회원가입 플로우에 대해 더 알아보려면 [소셜 로그인](/end-user-flows/sign-up-and-sign-in/social-sign-in/) 및 [엔터프라이즈 SSO](/end-user-flows/enterprise-sso/) 섹션을 참고하세요. +소셜 및 엔터프라이즈 SSO 커넥터를 통한 회원가입 플로우에 대해 더 알고 싶다면 [소셜 로그인](/end-user-flows/sign-up-and-sign-in/social-sign-in/) 및 [엔터프라이즈 SSO](/end-user-flows/enterprise-sso/) 섹션을 참고하세요. :::note -참고: 커스텀 회원가입 플로우가 필요한 경우 [Bring your UI](/customization/bring-your-ui/) 기능을 참고하세요. +참고: 커스텀 회원가입 플로우가 필요한 경우, [Bring your UI](/customization/bring-your-ui/) 기능을 참고하세요. ::: ## 회원가입 시 추가 사용자 정보 수집 \{#collect-additional-user-info-on-sign-up} -회원가입 과정에서 추가 사용자 프로필 정보(예: 이름, 생일, 회사명 등)를 수집하려면 두 가지 유연한 옵션이 있습니다: +회원가입 과정에서 추가 사용자 프로필 정보(예: 이름, 생년월일, 회사명 등)를 수집하려면, 다음 두 가지 유연한 옵션이 있습니다: **옵션 1: 사용자 프로필 수집** -Logto의 기본 제공 "자기소개" 단계를 회원가입 플로우에 직접 추가하세요. 사용자는 모든 필수 항목을 입력해야 등록이 완료됩니다. 이 방식은 코드 없이 바로 사용할 수 있는 플러그 앤 플레이 솔루션입니다. +Logto의 기본 제공 "자기소개" 단계를 회원가입 플로우에 직접 추가하세요. 사용자는 모든 필수 항목을 입력해야 등록이 완료됩니다. 이 방식은 코드 작성 없이 바로 사용할 수 있는 솔루션입니다. 콘솔 > 로그인 경험 > 사용자 프로필 수집 @@ -127,16 +137,16 @@ Logto의 기본 제공 "자기소개" 단계를 회원가입 플로우에 직접 **옵션 2: 자체 호스팅 온보딩 플로우** -회원가입 성공 후 사용자를 자체 커스텀 온보딩 플로우로 리디렉션하여 완전히 맞춤화된 데이터 수집이 가능합니다. 이 방식은 사용자 경험을 완전히 제어할 수 있으며, 복잡한 다단계 온보딩 프로세스도 구현할 수 있습니다. +회원가입 성공 후 사용자를 커스텀 온보딩 플로우로 리디렉션하여, 완전히 커스터마이즈된 데이터 수집이 가능합니다. 이 방식은 사용자 경험을 완전히 제어할 수 있으며, 복잡한 다단계 온보딩 프로세스도 구현할 수 있습니다. [Account API](/end-user-flows/account-settings/by-account-api)를 사용하여 프로그래밍 방식으로 사용자 프로필 데이터를 관리하세요. -## 자주 묻는 질문 (FAQs) \{#faqs} +## 자주 묻는 질문 \{#faqs}
-### 관리자 생성 사용자 / 초대된 사용자 \{#admin-created-users--invited-users} +### 관리자 생성 사용자 / 초대 사용자 \{#admin-created-users--invited-users} @@ -158,11 +168,11 @@ Logto는 현재 로그인 및 회원가입을 위한 헤드리스 API를 지원
-### 신규 사용자에게 환영 이메일 보내기 \{#sending-welcome-emails-to-new-users} +### 신규 사용자에게 환영 이메일 발송 \{#sending-welcome-emails-to-new-users} -`User.Created` Webhook 이벤트를 구독하여 신규 사용자에게 환영 이메일을 발송할 수 있습니다. [Webhook 이벤트](/developers/webhooks/webhooks-events/#data-mutation-hook-events)에 대해 자세히 알아보세요. +`User.Created` Webhook 이벤트를 구독하여 신규 사용자에게 환영 이메일을 자동 발송할 수 있습니다. [Webhook 이벤트](/developers/webhooks/webhooks-events/#data-mutation-hook-events)에 대해 자세히 알아보세요.
@@ -173,7 +183,7 @@ Logto는 현재 로그인 및 회원가입을 위한 헤드리스 API를 지원 -현재 Logto는 인증된 이메일 및 전화번호만 식별자로 지원합니다. 인증 과정은 사용자의 식별자 보안 및 소유권을 보장하기 위해 필수입니다. +현재 Logto는 인증된 이메일 및 전화번호만 식별자로 허용합니다. 인증 과정은 사용자의 식별자 보안 및 소유권 확인을 위해 필수입니다. 인증되지 않은 이메일 또는 전화번호 지원은 [로드맵](https://feedback.logto.io/roadmap)에 포함되어 있습니다. 업데이트를 기대해 주세요!
diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 5d45534048d..d6184fc00a3 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,5 +1,5 @@ --- -description: 리디렉션 URI, 엔드포인트, 리프레시 토큰, 백채널 로그아웃 등을 포함한 OIDC 인증 통합을 위한 주요 애플리케이션 매개변수를 참조하세요. +description: OIDC 인증 (Authentication) 통합을 위한 주요 애플리케이션 파라미터(리디렉션 URI, 엔드포인트, 리프레시 토큰, 백채널 로그아웃 등)를 참고하세요. sidebar_position: 6 --- @@ -7,145 +7,149 @@ sidebar_position: 6 ## 소개 \{#introduction} -Logto에서 *애플리케이션*은 Logto 플랫폼에 등록되어 사용자 정보를 액세스하거나 사용자를 대신하여 작업을 수행할 수 있는 권한을 부여받은 특정 소프트웨어 프로그램 또는 서비스를 의미합니다. 애플리케이션은 Logto API에 대한 요청의 출처를 식별하고, 해당 애플리케이션에 액세스하는 사용자의 인증 및 인가 (Authorization) 프로세스를 관리하는 데 사용됩니다. +Logto에서 *애플리케이션*은 Logto 플랫폼에 등록되어 사용자 정보를 액세스하거나 사용자를 대신하여 작업을 수행할 수 있는 권한을 부여받은 특정 소프트웨어 프로그램 또는 서비스를 의미합니다. 애플리케이션은 Logto API에 대한 요청의 출처를 식별하고, 해당 애플리케이션에 접근하는 사용자의 인증 (Authentication) 및 인가 (Authorization) 과정을 관리하는 데 사용됩니다. -Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 단일 위치에서 승인된 애플리케이션에 쉽게 액세스하고 관리할 수 있으며, 일관되고 안전한 인증 프로세스를 제공합니다. 이는 사용자 경험을 간소화하고, 조직을 대신하여 민감한 정보에 액세스하거나 작업을 수행하는 권한이 있는 사람만이 액세스하도록 보장합니다. +Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 하나의 위치에서 자신이 인가 (Authorization)된 애플리케이션을 쉽게 접근하고 관리할 수 있으며, 일관되고 안전한 인증 (Authentication) 과정을 제공합니다. 이를 통해 사용자 경험을 간소화하고, 인가 (Authorization)된 사람만이 민감한 정보에 접근하거나 조직을 대신하여 작업을 수행하도록 보장할 수 있습니다. -애플리케이션은 또한 Logto의 감사 로그에서 사용자 활동을 추적하고 잠재적인 보안 위협이나 침해를 식별하는 데 사용됩니다. 특정 작업을 특정 애플리케이션과 연관시킴으로써, Logto는 데이터가 어떻게 액세스되고 사용되는지에 대한 자세한 통찰력을 제공하여 조직이 보안 및 규정 준수 요구 사항을 더 잘 관리할 수 있도록 합니다. -애플리케이션을 Logto와 통합하려면 [Logto 통합](/integrate-logto)을 참조하세요. +애플리케이션은 Logto의 감사 로그에서도 사용되어 사용자 활동을 추적하고 잠재적인 보안 위협이나 침해를 식별하는 데 활용됩니다. 특정 작업을 특정 애플리케이션과 연관시킴으로써, Logto는 데이터가 어떻게 접근되고 사용되는지에 대한 상세한 인사이트를 제공하여 조직이 보안 및 컴플라이언스 요구 사항을 더 잘 관리할 수 있도록 합니다. +애플리케이션을 Logto와 통합하고 싶다면 [Logto 통합하기](/integrate-logto)를 참고하세요. ## 속성 \{#properties} ### 애플리케이션 ID \{#application-id} -*애플리케이션 ID*는 Logto에서 애플리케이션을 식별하기 위한 고유한 자동 생성 키이며, OAuth 2.0에서 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)로 참조됩니다. +*애플리케이션 ID*는 Logto에서 애플리케이션을 식별하는 고유 자동 생성 키이며, OAuth 2.0에서는 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)로 참조됩니다. ### 애플리케이션 유형 \{#application-types} -*애플리케이션*은 다음 애플리케이션 유형 중 하나일 수 있습니다: +*애플리케이션*은 다음 중 하나의 애플리케이션 유형이 될 수 있습니다: -- **네이티브 앱**은 네이티브 환경에서 실행되는 앱입니다. 예: iOS 앱, Android 앱. -- **단일 페이지 앱**은 웹 브라우저에서 실행되며, 서버에서 새로운 데이터를 받아와 페이지를 업데이트하는 앱입니다. 예: React DOM 앱, Vue 앱. -- **전통적인 웹 앱**은 웹 서버에 의해 페이지를 렌더링하고 업데이트하는 앱입니다. 예: JSP, PHP. -- **기계 간 (M2M) 앱**은 사용자 상호작용 없이 서비스 간 직접 통신을 위해 기계 환경에서 실행되는 애플리케이션입니다. +- **네이티브 앱**: 네이티브 환경에서 실행되는 앱입니다. 예: iOS 앱, Android 앱. +- **싱글 페이지 앱**: 웹 브라우저에서 실행되며, 서버에서 새로운 데이터를 받아와 전체 페이지를 새로 고치지 않고 페이지를 업데이트하는 앱입니다. 예: React DOM 앱, Vue 앱. +- **전통적인 웹 앱**: 웹 서버만으로 페이지를 렌더링하고 업데이트하는 앱입니다. 예: JSP, PHP. +- **기계 간 (M2M) 앱**: 사용자 상호작용 없이 서비스 간 직접 통신을 위해 머신 환경에서 실행되는 애플리케이션입니다. -### 애플리케이션 비밀 \{#application-secret} +### 애플리케이션 시크릿 \{#application-secret} -*애플리케이션 비밀*은 인증 시스템에서 애플리케이션을 인증하는 데 사용되는 키로, 특히 개인 클라이언트 (전통적인 웹 및 M2M 앱)를 위한 개인 보안 장벽입니다. +*애플리케이션 시크릿*은 인증 (Authentication) 시스템에서 애플리케이션을 인증하는 데 사용되는 키로, 특히 프라이빗 클라이언트(전통적인 웹 및 M2M 앱)에서 프라이빗 보안 장벽 역할을 합니다. + +:::tip +싱글 페이지 앱(SPA)과 네이티브 앱은 앱 시크릿을 제공하지 않습니다. SPA와 네이티브 앱은 "공개 클라이언트"이므로 시크릿을 안전하게 보관할 수 없습니다(브라우저 코드 또는 앱 번들은 누구나 볼 수 있음). 앱 시크릿 대신 Logto는 PKCE, 엄격한 리디렉션 URI / CORS 검증, 단명 액세스 토큰, 리프레시 토큰 회전을 통해 보호합니다. +::: ### 애플리케이션 이름 \{#application-name} *애플리케이션 이름*은 사람이 읽을 수 있는 애플리케이션의 이름이며, 관리자 콘솔에 표시됩니다. -*애플리케이션 이름*은 Logto에서 애플리케이션을 관리하는 중요한 구성 요소로, 관리자가 플랫폼 내에서 개별 애플리케이션의 활동을 쉽게 식별하고 추적할 수 있도록 합니다. +*애플리케이션 이름*은 Logto에서 애플리케이션을 관리하는 데 중요한 요소로, 관리자가 플랫폼 내에서 개별 애플리케이션의 활동을 쉽게 식별하고 추적할 수 있도록 합니다. :::note -*애플리케이션 이름*은 관리자 콘솔에 액세스할 수 있는 모든 사용자에게 표시되므로 신중하게 선택해야 합니다. 애플리케이션의 목적과 기능을 정확하게 반영하면서도 이해하기 쉽고 인식하기 쉬워야 합니다. +*애플리케이션 이름*은 관리자 콘솔에 접근할 수 있는 모든 사용자에게 표시되므로 신중하게 선택해야 합니다. 애플리케이션의 목적과 기능을 정확하게 반영하면서도 이해하기 쉽고 인식하기 쉬워야 합니다. ::: ### 설명 \{#description} -애플리케이션의 간단한 설명이 관리자 콘솔 애플리케이션 세부 정보 페이지에 표시됩니다. 설명은 애플리케이션의 목적, 기능 및 기타 관련 세부 정보를 관리자가 추가로 제공받을 수 있도록 합니다. +애플리케이션에 대한 간단한 설명이 관리자 콘솔의 애플리케이션 상세 페이지에 표시됩니다. 설명은 애플리케이션의 목적, 기능, 기타 관련 정보를 관리자가 추가로 파악할 수 있도록 제공됩니다. ### 리디렉션 URI \{#redirect-uris} -*리디렉션 URI*는 애플리케이션에 대해 사전 구성된 유효한 리디렉션 URI 목록입니다. 사용자가 Logto에 로그인하고 애플리케이션에 액세스하려고 할 때, 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다. +*리디렉션 URI*는 애플리케이션에 대해 미리 구성된 유효한 리디렉션 URI 목록입니다. 사용자가 Logto에 로그인하고 애플리케이션에 접근하려고 할 때, 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다. -허용된 URI 목록은 애플리케이션이 인증 (Authentication) 프로세스 중 Logto에 보낸 인가 (Authorization) 요청에 포함된 리디렉션 URI를 검증하는 데 사용됩니다. 인가 요청에 지정된 리디렉션 URI가 애플리케이션 설정의 허용된 URI 중 하나와 일치하면, 사용자는 인증에 성공한 후 해당 URI로 리디렉션됩니다. 리디렉션 URI가 허용된 목록에 없으면, 사용자는 리디렉션되지 않으며 인증 프로세스가 실패합니다. +허용된 URI 목록은 인증 (Authentication) 과정에서 애플리케이션이 Logto로 보내는 인가 (Authorization) 요청에 포함된 리디렉션 URI를 검증하는 데 사용됩니다. 인가 (Authorization) 요청에 지정된 리디렉션 URI가 애플리케이션 설정의 허용된 URI 중 하나와 일치하면, 인증 (Authentication)에 성공한 후 해당 URI로 사용자가 리디렉션됩니다. 만약 리디렉션 URI가 허용 목록에 없다면, 사용자는 리디렉션되지 않고 인증 (Authentication) 과정이 실패하게 됩니다. :::note -모든 유효한 리디렉션 URI가 Logto의 애플리케이션에 대한 허용 목록에 추가되어야 사용자가 인증 후 애플리케이션에 성공적으로 액세스할 수 있습니다. +모든 유효한 리디렉션 URI가 Logto의 애플리케이션 허용 목록에 추가되어야, 인증 (Authentication) 후 사용자가 애플리케이션에 정상적으로 접근할 수 있습니다. ::: -[리디렉션 엔드포인트](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2)를 참조하여 더 많은 정보를 확인할 수 있습니다. +[Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2)에 대해 더 알아보세요. - 인가 코드 플로우를 사용한 OIDC에서 리디렉션 URI 이해하기 + OIDC에서 인가 코드 플로우의 리디렉션 URI 이해하기 ### 로그아웃 후 리디렉션 URI \{#post-sign-out-redirect-uris} -*로그아웃 후 리디렉션 URI*는 Logto에서 로그아웃한 후 사용자를 리디렉션하기 위해 애플리케이션에 대해 사전 구성된 유효한 URI 목록입니다. +*로그아웃 후 리디렉션 URI*는 사용자가 Logto에서 로그아웃한 후 리디렉션될 수 있도록 애플리케이션에 미리 구성된 유효한 URI 목록입니다. -로그아웃을 위한 허용된 *로그아웃 후 리디렉션 URI*의 사용은 OIDC의 RP-Initiated (Relying Party Initiated) 로그아웃 사양의 일부입니다. 이 사양은 사용자를 위한 로그아웃 요청을 시작하고, 로그아웃 후 사용자를 사전 구성된 엔드포인트로 리디렉션하는 표준화된 방법을 제공합니다. +허용된 _로그아웃 후 리디렉션 URI_ 사용은 OIDC의 RP-Initiated(신뢰 당사자 시작) 로그아웃 명세의 일부입니다. 이 명세는 애플리케이션이 사용자를 위한 로그아웃 요청을 표준화된 방식으로 시작하고, 로그아웃 후 미리 구성된 엔드포인트로 사용자를 리디렉션할 수 있도록 합니다. -사용자가 Logto에서 로그아웃하면, 세션이 종료되고 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다. 이는 사용자가 로그아웃 후 승인되고 유효한 엔드포인트로만 리디렉션되도록 하여, 알 수 없거나 검증되지 않은 엔드포인트로 사용자를 리디렉션하는 것과 관련된 무단 액세스 및 보안 위험을 방지하는 데 도움이 됩니다. +사용자가 Logto에서 로그아웃하면 세션이 종료되고, 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다. 이를 통해 사용자가 로그아웃 후 인가 (Authorization)된 유효한 엔드포인트로만 이동하도록 하여, 미확인 또는 검증되지 않은 엔드포인트로의 리디렉션에 따른 무단 접근 및 보안 위험을 방지할 수 있습니다. -[RP-initiated 로그아웃](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout)을 참조하여 더 많은 정보를 확인할 수 있습니다. +[RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout)에 대해 더 알아보세요. -### CORS 허용된 출처 \{#cors-allowed-origins} +### CORS 허용 오리진 \{#cors-allowed-origins} -*CORS (Cross-origin resource sharing) 허용된 출처*는 애플리케이션이 Logto 서비스에 요청을 보낼 수 있는 허용된 출처 목록입니다. 허용된 목록에 포함되지 않은 출처는 Logto 서비스에 요청을 보낼 수 없습니다. +*CORS (교차 출처 리소스 공유) 허용 오리진*은 애플리케이션이 Logto 서비스에 요청을 보낼 수 있도록 허용된 오리진(출처) 목록입니다. 허용 목록에 포함되지 않은 오리진에서는 Logto 서비스에 요청을 보낼 수 없습니다. -CORS 허용된 출처 목록은 무단 도메인으로부터 Logto 서비스에 대한 액세스를 제한하고, 교차 사이트 요청 위조 (CSRF) 공격을 방지하는 데 사용됩니다. Logto에서 애플리케이션에 대한 허용된 출처를 지정함으로써, 서비스는 승인된 도메인만이 서비스에 요청을 보낼 수 있도록 보장할 수 있습니다. +CORS 허용 오리진 목록은 인가 (Authorization)되지 않은 도메인에서 Logto 서비스에 접근하는 것을 제한하고, 교차 사이트 요청 위조(CSRF) 공격을 방지하는 데 도움이 됩니다. Logto에서 애플리케이션의 허용 오리진을 지정함으로써, 인가 (Authorization)된 도메인만 서비스에 요청을 보낼 수 있도록 보장할 수 있습니다. :::note -허용된 출처 목록에는 애플리케이션이 제공될 출처가 포함되어야 합니다. 이는 애플리케이션의 요청이 허용되도록 하며, 무단 출처의 요청은 차단됩니다. +허용 오리진 목록에는 애플리케이션이 서비스되는 오리진이 포함되어야 합니다. 이를 통해 애플리케이션에서의 요청은 허용되고, 인가 (Authorization)되지 않은 오리진의 요청은 차단됩니다. ::: ### OpenID 제공자 구성 엔드포인트 \{#openid-provider-configuration-endpoint} -[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest)의 엔드포인트입니다. +[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) 엔드포인트입니다. ### 인가 엔드포인트 \{#authorization-endpoint} -*인가 엔드포인트*는 OIDC 용어로, 사용자의 인증 프로세스를 시작하는 데 사용되는 필수 엔드포인트입니다. 사용자가 Logto 플랫폼에 등록된 보호된 리소스 또는 애플리케이션에 액세스하려고 할 때, 그들은 *인가 엔드포인트*로 리디렉션되어 자신의 아이덴티티를 인증하고 요청된 리소스에 대한 인가를 받습니다. +*인가 엔드포인트*는 OIDC 용어로, 사용자의 인증 (Authentication) 과정을 시작하는 데 사용되는 필수 엔드포인트입니다. 사용자가 Logto 플랫폼에 등록된 보호된 리소스 또는 애플리케이션에 접근하려고 할 때, *인가 엔드포인트*로 리디렉션되어 자신의 아이덴티티를 인증 (Authentication)하고 요청한 리소스에 접근할 수 있는 인가 (Authorization)를 받게 됩니다. -[인가 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint)를 참조하여 더 많은 정보를 확인할 수 있습니다. +[Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint)에 대해 더 알아보세요. ### 토큰 엔드포인트 \{#token-endpoint} -*토큰 엔드포인트*는 OIDC 용어로, OIDC 클라이언트가 OIDC 제공자로부터 액세스 토큰, ID 토큰 또는 리프레시 토큰을 얻기 위해 사용하는 웹 API 엔드포인트입니다. +*토큰 엔드포인트*는 OIDC 용어로, OIDC 클라이언트가 OIDC 제공자로부터 액세스 토큰, ID 토큰, 또는 리프레시 토큰을 얻기 위해 사용하는 웹 API 엔드포인트입니다. -OIDC 클라이언트가 액세스 토큰이나 ID 토큰을 얻어야 할 때, 인가 코드 또는 리프레시 토큰과 같은 인가 그랜트를 사용하여 토큰 엔드포인트에 요청을 보냅니다. 토큰 엔드포인트는 인가 그랜트를 검증하고, 그랜트가 유효한 경우 클라이언트에게 액세스 토큰이나 ID 토큰을 발급합니다. +OIDC 클라이언트가 액세스 토큰이나 ID 토큰을 얻어야 할 때, 인가 (Authorization) 그랜트(일반적으로 인가 코드 또는 리프레시 토큰)와 함께 토큰 엔드포인트에 요청을 보냅니다. 토큰 엔드포인트는 인가 (Authorization) 그랜트를 검증하고, 유효하다면 클라이언트에게 액세스 토큰 또는 ID 토큰을 발급합니다. -[토큰 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint)를 참조하여 더 많은 정보를 확인할 수 있습니다. +[Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint)에 대해 더 알아보세요. -### 사용자 정보 엔드포인트 \{#userinfo-endpoint} +### Userinfo 엔드포인트 \{#userinfo-endpoint} -OpenID Connect [사용자 정보 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). +OpenID Connect [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)입니다. ### 항상 리프레시 토큰 발급 \{#always-issue-refresh-token} -_사용 가능: 전통적인 웹, SPA_ +_적용 대상: 전통적인 웹, SPA_ -활성화되면, Logto는 인증 요청에 `prompt=consent`가 표시되지 않거나 스코프에 `offline_access`가 표시되지 않더라도 항상 리프레시 토큰을 발급합니다. +이 옵션을 활성화하면, 인증 (Authentication) 요청에 `prompt=consent`가 포함되어 있지 않거나, 스코프에 `offline_access`가 포함되어 있지 않아도 Logto는 항상 리프레시 토큰을 발급합니다. -그러나 이 관행은 필요하지 않는 한 권장되지 않습니다 (일반적으로 리프레시 토큰이 필요한 일부 타사 OAuth 통합에 유용함). 이는 OpenID Connect와 호환되지 않으며 잠재적으로 문제를 일으킬 수 있습니다. +그러나 이 방식은 OpenID Connect와 호환되지 않으며, 잠재적으로 문제를 일으킬 수 있으므로 꼭 필요한 경우(일반적으로 리프레시 토큰이 필요한 일부 서드파티 OAuth 통합) 외에는 권장하지 않습니다. ### 리프레시 토큰 회전 \{#rotate-refresh-token} _기본값: `true`_ -활성화되면, Logto는 다음 조건에서 토큰 요청에 대해 새로운 리프레시 토큰을 발급합니다: +이 옵션을 활성화하면, 다음 조건 중 하나에 해당할 때 Logto는 토큰 요청에 대해 새로운 리프레시 토큰을 발급합니다: -- 리프레시 토큰이 1년 동안 회전된 경우 (새로운 토큰 발급으로 TTL이 연장됨); **또는** -- 리프레시 토큰이 만료 시간에 가까운 경우 (원래 TTL의 70% 이상 경과); **또는** -- 클라이언트가 공용 클라이언트인 경우, 예: 네이티브 애플리케이션 또는 단일 페이지 애플리케이션 (SPA). +- 리프레시 토큰이 1년 동안 회전(새 토큰 발급으로 TTL 연장)된 경우; **또는** +- 리프레시 토큰이 만료 시간에 가까워진 경우(원래 TTL의 70% 이상 경과); **또는** +- 클라이언트가 공개 클라이언트(예: 네이티브 애플리케이션 또는 싱글 페이지 애플리케이션(SPA))인 경우. :::note -공용 클라이언트의 경우, 이 기능이 활성화되면 클라이언트가 리프레시 토큰을 사용하여 새로운 액세스 토큰을 교환할 때마다 항상 새로운 리프레시 토큰이 발급됩니다. -이러한 공용 클라이언트에 대해 기능을 비활성화할 수도 있지만, 보안상의 이유로 활성화 상태를 유지하는 것이 강력히 권장됩니다. +공개 클라이언트의 경우, 이 기능이 활성화되어 있으면 클라이언트가 리프레시 토큰을 사용해 새로운 액세스 토큰을 교환할 때마다 항상 새로운 리프레시 토큰이 발급됩니다. +공개 클라이언트에 대해 이 기능을 비활성화할 수도 있지만, 보안상의 이유로 활성화 상태를 유지하는 것이 강력히 권장됩니다. ::: 리프레시 토큰 회전 이해하기 -### 리프레시 토큰 TTL (Time-to-live) 일수 \{#refresh-token-time-to-live-ttl-in-days} +### 리프레시 토큰 TTL(유효 기간, 일 단위) \{#refresh-token-time-to-live-ttl-in-days} -_사용 가능: SPA 제외; 기본값: 14일_ +_적용 대상: SPA 제외; 기본값: 14일_ -리프레시 토큰이 만료되어 무효화되기 전에 새로운 액세스 토큰을 요청할 수 있는 기간입니다. 토큰 요청은 리프레시 토큰의 TTL을 이 값으로 연장합니다. +리프레시 토큰이 만료되어 무효화되기 전까지 새로운 액세스 토큰을 요청할 수 있는 기간입니다. 토큰 요청 시 리프레시 토큰의 TTL이 이 값으로 연장됩니다. -일반적으로 낮은 값이 선호됩니다. +일반적으로 더 낮은 값이 선호됩니다. -참고: 보안상의 이유로 SPA (단일 페이지 앱)에서는 TTL 갱신이 불가능합니다. 이는 Logto가 토큰 요청을 통해 TTL을 연장하지 않음을 의미합니다. 사용자 경험을 향상시키기 위해 "리프레시 토큰 회전" 기능을 활성화하여 필요할 때 Logto가 새로운 리프레시 토큰을 발급할 수 있도록 할 수 있습니다. +참고: 보안상의 이유로 SPA(싱글 페이지 앱)에서는 TTL 연장이 불가능합니다. 즉, Logto는 토큰 요청을 통해 TTL을 연장하지 않습니다. 사용자 경험을 개선하려면 "리프레시 토큰 회전" 기능을 활성화하여 필요 시 Logto가 새로운 리프레시 토큰을 발급하도록 할 수 있습니다. ### 백채널 로그아웃 URI \{#backchannel-logout-uri} -OpenID Connect 백채널 로그아웃 엔드포인트입니다. [연합 로그아웃: 백채널 로그아웃](#)을 참조하여 더 많은 정보를 확인할 수 있습니다. +OpenID Connect 백채널 로그아웃 엔드포인트입니다. 자세한 내용은 [연합 로그아웃: 백채널 로그아웃](#)을 참고하세요. -### 사용자 정의 데이터 \{#custom-data} +### 커스텀 데이터 \{#custom-data} -미리 정의된 애플리케이션 속성에 나열되지 않은 추가 사용자 정의 애플리케이션 정보로, 사용자는 비즈니스별 설정 및 구성과 같은 특정 요구에 따라 사용자 정의 데이터 필드를 정의할 수 있습니다. +사전 정의된 애플리케이션 속성에 포함되지 않은 추가 커스텀 애플리케이션 정보로, 사용자는 비즈니스별 설정 및 구성 등 특정 요구에 따라 자체 커스텀 데이터 필드를 정의할 수 있습니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index c956c235b87..b40bc996eb5 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -5,7 +5,7 @@ sidebar_position: 1 # Logto를 애플리케이션에 통합하세요 -Logto를 사용하여 사용자 대상 앱이든 기계 간 서비스든 애플리케이션에 인증 (Authentication)을 추가하려면 다음 단계를 따르세요: +Logto를 사용하여 사용자 대상 앱이든 기계 간 서비스든, 애플리케이션에 인증 (Authentication)을 추가하려면 다음 단계를 따르세요: 1. 콘솔 > 애플리케이션로 이동하세요. @@ -16,7 +16,7 @@ Logto를 사용하여 사용자 대상 앱이든 기계 간 서비스든 애플 4. 프레임워크를 선택하면 해당 프레임워크 SDK의 빠른 시작 가이드가 표시됩니다. 안내에 따라 애플리케이션을 구성하고 통합하세요. 통합 과정에서 필요한 개념을 이해하는 데 도움이 필요하다면, [Logto 인증 (Authentication) 플로우 이해하기](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/)를 참고하여 더 깊이 이해할 수 있습니다. :::note -콘솔의 가이드는 Logto SDK를 사용한 빠른 시작용입니다. 고급 SDK 사용법을 포함한 전체 통합 가이드는 [빠른 시작](/quick-starts) 섹션을 참고하세요. +콘솔의 가이드는 Logto SDK를 사용한 빠른 시작을 위한 것입니다. 고급 SDK 사용법을 포함한 전체 통합 가이드는 [빠른 시작](/quick-starts) 섹션을 참고하세요. ::: 5. 완료되면, Logto에 대해 더 탐색해보세요: @@ -25,6 +25,21 @@ Logto를 사용하여 사용자 대상 앱이든 기계 간 서비스든 애플 인가 (Authorization) 조직 (Organization) +## 자주 묻는 질문 \{#faqs} + +
+ + ### 내 백엔드 서비스가 Logto로 사용자 토큰을 검증하고 사용자를 관리하려면 어떻게 해야 하나요? + +백엔드 API(예: Python, Node.js, Go, Java, PHP 등)에서 액세스 토큰 (Access token)의 유효성을 안전하게 검증하고, 프로그래밍 방식으로 사용자를 관리하려면 다음 가이드를 참고하세요: [API 서비스 또는 백엔드에서 액세스 토큰 (Access token) 검증하기](/authorization/validate-access-tokens). + +이 문서에서는 다음을 다룹니다: + +- 모든 API 호출에서 베어러 토큰의 유효성 검사 방법 +- 여러 프론트엔드 앱과 백엔드 서비스를 Logto와 통합하는 모범 사례 + +
+ ## 관련 리소스 \{#related-resources} @@ -32,17 +47,17 @@ Logto를 사용하여 사용자 대상 앱이든 기계 간 서비스든 애플 - OpenID Connect 구성 살펴보기: 주요 필드와 그 활용 + OpenID Connect 구성 살펴보기: 주요 필드와 활용법 - Logto 사용 시 왜 다양한 앱 유형을 구분해야 할까요? + Logto 사용 시 다양한 앱 유형을 구분해야 하는 이유는? - "iat" 토큰 클레임 (Claim) 이해 및 "Invalid issued at time" 오류 해결 + "iat" 토큰 클레임 (Claim) 이해 및 "Invalid issued at time" 오류 해결하기 - "invalid_grant" 오류 이해 및 해결 + "invalid_grant" 오류 이해 및 해결하기 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index f73528f09cd..6e494f2d245 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -8,31 +8,31 @@ import CustomizationIcon from '@site/src/assets/customization.svg'; # 타사 앱 (OAuth / OIDC) -Logto의 타사 애플리케이션 통합 기능을 통해 Logto를 외부 애플리케이션의 [아이덴티티 제공자 (IdP)](https://auth.wiki/identity-provider)로 활용할 수 있습니다. +Logto의 타사 애플리케이션 통합을 통해 Logto를 외부 애플리케이션의 [아이덴티티 제공자 (IdP)](https://auth.wiki/identity-provider)로 활용할 수 있습니다. -아이덴티티 제공자 (IdP)는 사용자의 아이덴티티를 검증하고 로그인 자격 증명을 관리하는 서비스입니다. 사용자의 아이덴티티를 확인한 후, IdP는 인증 (Authentication) 토큰 또는 어설션을 생성하여 사용자가 다시 로그인할 필요 없이 다양한 애플리케이션이나 서비스에 접근할 수 있도록 합니다. +아이덴티티 제공자 (IdP)는 사용자의 아이덴티티를 검증하고 로그인 자격 증명을 관리하는 서비스입니다. 사용자의 아이덴티티를 확인한 후, IdP는 인증 (Authentication) 토큰 또는 어설션을 생성하여 사용자가 다시 로그인하지 않고도 다양한 애플리케이션이나 서비스에 접근할 수 있도록 합니다. -[Logto 애플리케이션에 통합하기](/integrate-logto/integrate-logto-into-your-application) 가이드에서 생성한, 여러분이 직접 개발하고 완전히 제어하는 애플리케이션과 달리, 타사 애플리케이션은 외부 개발자나 비즈니스 파트너가 개발한 독립적인 서비스입니다. +[애플리케이션에 Logto 통합하기](/integrate-logto/integrate-logto-into-your-application) 가이드에서 생성한, 여러분이 직접 개발하고 완전히 제어하는 애플리케이션과 달리, 타사 애플리케이션은 외부 개발자나 비즈니스 파트너가 개발한 독립적인 서비스입니다. -이 통합 방식은 일반적인 비즈니스 시나리오에 적합합니다. 사용자가 Logto 계정으로 파트너 애플리케이션에 접근할 수 있도록 할 수 있으며, 이는 엔터프라이즈 사용자가 Google Workspace로 Slack에 로그인하는 방식과 유사합니다. 또한, 타사 애플리케이션이 "Logto로 로그인" 기능을 추가할 수 있는 오픈 플랫폼을 구축할 수도 있습니다. 이는 "Google로 로그인"과 비슷합니다. +이 통합 방식은 일반적인 비즈니스 시나리오에 매우 적합합니다. 사용자가 Logto 계정으로 파트너 애플리케이션에 접근할 수 있도록 할 수 있으며, 이는 엔터프라이즈 사용자가 Google Workspace로 Slack에 로그인하는 방식과 유사합니다. 또한, 타사 애플리케이션이 "Logto로 로그인" 기능을 추가할 수 있는 오픈 플랫폼을 구축할 수도 있습니다. 이는 "Google로 로그인"과 비슷합니다. -Logto는 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 프로토콜을 기반으로 구축된 아이덴티티 서비스로, [인증 (Authentication)](https://auth.wiki/authentication)과 [인가 (Authorization)](https://auth.wiki/authorization) 기능을 모두 제공합니다. 이로 인해 OIDC 타사 앱 통합은 기존 웹 애플리케이션과 마찬가지로 매우 간단합니다. +Logto는 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 프로토콜을 기반으로 구축된 아이덴티티 서비스로, [인증 (Authentication)](https://auth.wiki/authentication)과 [인가 (Authorization)](https://auth.wiki/authorization) 기능을 모두 제공합니다. 이로 인해 OIDC 타사 앱 통합은 기존 웹 애플리케이션 통합만큼 간단합니다. -OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 (Authentication) 계층을 추가하여 구축되었기 때문에, OAuth 프로토콜을 사용하여 타사 앱을 통합할 수도 있습니다. +또한 OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 계층을 추가하여 구축되었기 때문에, OAuth 프로토콜을 사용하여 타사 앱을 통합할 수도 있습니다. ## Logto에서 타사 애플리케이션 생성하기 \{#create-an-third-party-application-in-logto} 1. 콘솔 > 애플리케이션으로 이동하세요. -2. 애플리케이션 유형으로 "타사 앱"을 선택하고, 다음 중 하나의 통합 프로토콜을 선택하세요: +2. "애플리케이션 생성" 버튼을 클릭하세요. 애플리케이션 유형으로 "타사 앱"을 선택하고, 다음 통합 프로토콜 중 하나를 선택하세요: - OIDC / OAuth 3. 애플리케이션의 이름과 설명을 입력한 후 “생성” 버튼을 클릭하세요. 새로운 타사 애플리케이션이 생성됩니다. -생성된 모든 타사 애플리케이션은 애플리케이션 페이지의 "타사 앱" 탭에 정리되어 표시됩니다. 이 구조는 여러분의 자체 애플리케이션과 구분하여 한 곳에서 모든 애플리케이션을 쉽게 관리할 수 있도록 도와줍니다. +생성된 모든 타사 애플리케이션은 애플리케이션 페이지의 "타사 앱" 탭에 정리되어 표시됩니다. 이 구조는 여러분의 자체 애플리케이션과 구분하여 모든 애플리케이션을 한 곳에서 쉽게 관리할 수 있도록 도와줍니다. -## OIDC 설정 구성하기 \{#set-up-the-oidc-configurations} +## OIDC 구성 설정하기 \{#set-up-the-oidc-configurations} :::note -OIDC 설정을 구성하기 전에, [OIDC 타사 애플리케이션을 생성](/quick-starts/third-party-oidc)했는지 확인하세요. +OIDC 구성을 설정하기 전에, [OIDC 타사 애플리케이션을 생성](/quick-starts/third-party-oidc)했는지 확인하세요. ::: 1. OIDC 타사 애플리케이션의 [**리디렉션 URI**](/integrate-logto/application-data-structure#redirect-uris)를 입력하세요. 이 URL은 Logto에서 인증 (Authentication) 후 사용자를 타사 애플리케이션으로 리디렉션하는 주소입니다. @@ -44,7 +44,7 @@ OIDC 설정을 구성하기 전에, [OIDC 타사 애플리케이션을 생성](/ 서비스 제공자가 OIDC 디스커버리를 지원한다면, Logto 애플리케이션 상세 페이지에서 **디스커버리 엔드포인트**를 복사하여 서비스 제공자에게 제공하면 됩니다. 서비스 제공자는 디스커버리 엔드포인트에서 최신 OIDC 인증 (Authentication) 정보를 자동으로 가져올 수 있습니다. 그렇지 않은 경우, **엔드포인트 상세 보기** 버튼을 클릭하여 모든 OIDC 인증 (Authentication) 엔드포인트를 확인할 수 있습니다. -## OIDC 타사 애플리케이션의 동의 화면 \{#consent-screen-for-oidc-third-party-applications} +## OIDC 타사 애플리케이션을 위한 동의 화면 \{#consent-screen-for-oidc-third-party-applications} 보안상의 이유로, 모든 OIDC 타사 애플리케이션은 Logto에서 인증 (Authentication) 후 [동의 화면](/end-user-flows/consent-screen)으로 리디렉션되어 사용자 인가 (Authorization)를 받게 됩니다. @@ -91,13 +91,13 @@ OIDC 설정을 구성하기 전에, [OIDC 타사 애플리케이션을 생성](/ -Logto는 역할 기반 접근 제어 (RBAC)를 사용하여 사용자 권한을 관리합니다. 동의 화면에는 사용자가 이미 역할을 통해 할당받은 스코프 (권한)만 표시됩니다. 타사 앱이 사용자가 가지지 않은 스코프를 요청할 경우, 해당 항목은 제외되어 비인가 동의를 방지합니다. +Logto는 역할 기반 접근 제어 (RBAC)를 사용하여 사용자 권한을 관리합니다. 동의 화면에는 사용자의 역할을 통해 이미 할당된 스코프 (권한)만 표시됩니다. 타사 앱이 사용자가 가지지 않은 스코프를 요청할 경우, 해당 스코프는 제외되어 인가되지 않은 동의가 이루어지지 않도록 합니다. 관리 방법: - 특정 스코프를 가진 [글로벌 역할](/authorization/role-based-access-control) 또는 [조직 역할](/authorization/organization-template)을 정의하세요. - 접근 필요에 따라 사용자에게 역할을 할당하세요. -- 사용자는 역할로부터 스코프를 자동으로 상속받게 됩니다. +- 사용자는 역할에서 스코프를 자동으로 상속받게 됩니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index 4b4ea3214a7..3073aec2640 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,10 +3,11 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Logto 클라우드 서비스 -[Logto Cloud](https://cloud.logto.io) 는 아이덴티티와 리소스를 원활하고 쉽게 관리할 수 있도록 다양한 관리 및 운영 서비스를 제공합니다. Logto에서 호스팅하며, [다중 리전 지원](/logto-cloud/tenant-settings#tenant-region), 테넌트 관리, [청구 및 가격 정책](/logto-cloud/billing-and-pricing), [멤버 관리](/logto-cloud/tenant-member-management), 콘솔 역할 기반 접근 제어 (RBAC) 등의 기능을 포함합니다. +[Logto Cloud](https://cloud.logto.io) 는 아이덴티티와 리소스를 원활하고 쉽게 관리할 수 있도록 다양한 관리 및 운영 서비스를 제공합니다. Logto에서 호스팅하며, [다중 리전 지원](/logto-cloud/tenant-settings#tenant-region), 테넌트 관리, [청구 및 가격](/logto-cloud/billing-and-pricing), [멤버 관리](/logto-cloud/tenant-member-management), 콘솔 역할 기반 접근 제어 (RBAC) 등의 기능을 포함합니다. 클라우드 서비스에 대해 궁금한 점이 있거나 추가 지원이 필요하시면 언제든지 문의해 주세요. @@ -55,12 +56,21 @@ import CustomDomains from '@site/src/assets/search.svg'; }, { type: 'link', - label: '청구 및 가격 정책', + label: '청구 및 가격', href: '/logto-cloud/billing-and-pricing', description: '청구서를 쉽게 이해하고 구독을 자신 있게 관리하세요.', customProps: { icon: , }, }, + { + type: 'link', + label: '시스템 한도', + href: '/logto-cloud/system-limit', + description: 'Dev, Pro, Enterprise 테넌트의 시스템 한도와 속도 보호 정책을 이해하세요.', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index b0bc31ea296..0121ee3dd81 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -13,10 +13,10 @@ Logto 테넌트에는 기본 무료 도메인 `{{tenant-id}}.app.logto`가 제 - [로그인 및 회원가입 페이지](/end-user-flows/sign-up-and-sign-in) URL - [패스키](/end-user-flows/mfa/webauthn) 연결 URL (사용자가 패스키를 연결한 후 도메인을 변경하면 인증이 차단될 수 있습니다). - [소셜 커넥터](/connectors/social-connectors) 또는 [엔터프라이즈 SSO 커넥터](/connectors/enterprise-connectors)의 콜백 URI. -- Logto를 애플리케이션과 통합할 때 사용하는 [SDK 엔드포인트](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint). +- 애플리케이션과 Logto를 연동하기 위한 [SDK 엔드포인트](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint). :::note -서비스를 배포한 후 도메인을 변경하면 애플리케이션 코드와 통합이 이전 도메인을 참조할 수 있으므로 문제가 발생할 수 있습니다. 원활한 전환을 위해 **프로덕션 테넌트 생성 시 처음부터 커스텀 도메인을 설정**하세요. +서비스를 배포한 후 도메인을 변경하면 애플리케이션 코드와 연동이 여전히 이전 도메인을 참조할 수 있으므로 문제가 발생할 수 있습니다. 원활한 전환을 위해 **프로덕션 테넌트 생성 시 초기에 커스텀 도메인을 설정**하세요. ::: ## 콘솔에서 커스텀 도메인 설정하기 \{#configure-custom-domain-in-console} @@ -24,11 +24,11 @@ Logto 테넌트에는 기본 무료 도메인 `{{tenant-id}}.app.logto`가 제 Logto 콘솔에서 새로운 커스텀 도메인을 추가하려면 다음 단계를 따르세요: 1. 콘솔 > 설정 > 도메인으로 이동합니다. -2. "커스텀 도메인" 섹션에서 도메인 이름을 입력하고 "도메인 추가"를 클릭합니다. +2. "커스텀 도메인" 섹션에서 도메인 이름을 입력하고 "도메인 추가"를 클릭하세요. 도메인 추가 -3. 표에 표시된 CNAME 값을 복사하여, 도메인 DNS 제공업체에서 레코드를 추가합니다. +3. 표에 표시된 CNAME 값을 복사한 후, 도메인의 DNS 제공업체로 이동하여 레코드를 추가하세요. 커스텀 도메인 처리 중 @@ -45,9 +45,9 @@ Logto 콘솔에서 새로운 커스텀 도메인을 추가하려면 다음 단 -커스텀 도메인 설정 시 SSL 인증서 문제를 겪는 경우, DNS 설정의 CAA 레코드와 관련이 있을 수 있습니다. CAA 레코드는 어떤 인증 기관(CA)이 도메인에 대한 인증서를 발급할 수 있는지 지정합니다. CAA 레코드를 사용하는 경우, Logto가 SSL 인증서를 발급할 수 있도록 "letsencrypt.org"와 "pki.goog" 모두를 허용해야 합니다. +커스텀 도메인 설정 시 SSL 인증서 문제가 발생한다면, DNS 설정의 CAA 레코드와 관련이 있을 수 있습니다. CAA 레코드는 어떤 인증 기관(CA)이 도메인에 대한 인증서를 발급할 수 있는지 지정합니다. CAA 레코드를 사용하는 경우, Logto가 SSL 인증서를 발급할 수 있도록 "letsencrypt.org"와 "pki.goog" 모두를 허용해야 합니다. -CAA 레코드 관련 SSL 인증서 문제 해결 방법은 [Cloudflare 문서](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/)를 참고하세요. +CAA 레코드 관련 SSL 인증서 문제를 해결하려면 [Cloudflare의 문서](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/)를 참고하세요. @@ -60,14 +60,14 @@ CAA 레코드 관련 SSL 인증서 문제 해결 방법은 [Cloudflare 문서](h 커스텀 도메인 추가 시 "The hostname is associated with a held zone, please contact the owner to have the hold removed"라는 오류 메시지가 나타난다면, 해당 도메인이 이미 Cloudflare 존에 등록되어 있고 "Zone Hold" 상태로 설정되어 있음을 의미합니다. 자세한 내용은 [Cloudflare 문서](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/)를 참고하세요. -이 문제를 해결하려면 존 홀드를 해제해야 합니다. Cloudflare에서 존 홀드를 해제하는 방법은 위 링크를 참고하세요. +이 문제를 해결하려면 존 홀드를 해제해야 합니다. 위 링크에서 Cloudflare에서 존 홀드를 해제하는 방법을 확인하세요.
-### Cloudflare에 호스팅된 도메인에서 연결 시간 초과 (오류 코드 522) \{#cloudflare-522-timeout} +### Cloudflare에 호스팅된 도메인의 연결 시간 초과 (오류 코드 522) \{#cloudflare-522-timeout} @@ -75,9 +75,40 @@ CAA 레코드 관련 SSL 인증서 문제 해결 방법은 [Cloudflare 문서](h
+
+ + +### 커스텀 도메인 설정 후 "Redirect URI does not match" 오류 \{#redirect-uri-mismatch} + + + +커스텀 도메인 추가 후 "redirect URI does not match" 오류가 발생한다면, SDK 설정에서 엔드포인트를 커스텀 도메인으로 업데이트해야 합니다. + +**"기본 도메인"에 대하여:** + +Logto에는 별도의 "기본 도메인" 설정이 없습니다. 커스텀 도메인을 추가하면, 커스텀 도메인과 기본 `{tenant-id}.logto.app` 도메인 모두 유효하게 남아 있습니다. SDK의 `endpoint` 파라미터에 어떤 도메인을 설정하느냐에 따라 인증 플로우에 사용되는 도메인이 결정됩니다. + +**해결 방법:** + +SDK 초기화 시 `endpoint` 파라미터를 커스텀 도메인으로 업데이트하세요: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // 커스텀 도메인 사용 + appId: 'your-app-id', + // ... 기타 옵션 +}); +``` + +또한 콘솔 → 애플리케이션에서 등록된 redirect URI가 사용 중인 도메인과 일치하는지 확인하세요. + +**참고:** Logto는 커스텀 도메인에 대한 SSL 인증서를 자동으로 발급 및 관리합니다. 별도의 인증서 설정은 필요하지 않습니다. + +
+ ## 커스텀 도메인 사용하기 \{#use-custom-domain} -설정을 완료하면, 커스텀 도메인과 기본 Logto 도메인 모두 테넌트에서 사용할 수 있습니다. 하지만, 커스텀 도메인 활성화를 위해 몇 가지 추가 설정이 필요합니다. +설정을 완료하면, 커스텀 도메인과 기본 Logto 도메인 모두 테넌트에서 사용할 수 있습니다. 단, 커스텀 도메인 활성화를 위해 몇 가지 추가 설정이 필요합니다. :::note @@ -85,7 +116,7 @@ CAA 레코드 관련 SSL 인증서 문제 해결 방법은 [Cloudflare 문서](h ::: -### 애플리케이션의 SDK 엔드포인트 업데이트하기 \{#updating-the-sdk-endpoint-for-applications} +### 애플리케이션의 SDK 엔드포인트 업데이트 \{#updating-the-sdk-endpoint-for-applications} Logto SDK 초기화 코드에서 엔드포인트의 도메인 이름을 수정하세요. @@ -96,9 +127,9 @@ const client = new LogtoClient({ }); ``` -### 기타 애플리케이션의 인증 엔드포인트 수정하기 \{#modifying-auth-endpoints-for-other-applications} +### 기타 애플리케이션의 인증 엔드포인트 수정 \{#modifying-auth-endpoints-for-other-applications} -Logto SDK를 사용하지 않는 애플리케이션이 있다면, 해당 애플리케이션의 인증 엔드포인트도 업데이트해야 합니다. +Logto SDK를 사용하지 않는 애플리케이션이 있다면, 해당 인증 엔드포인트도 업데이트해야 합니다. 인증 엔드포인트는 다음과 같은 well-known URL에서 확인할 수 있습니다: @@ -106,8 +137,8 @@ Logto SDK를 사용하지 않는 애플리케이션이 있다면, 해당 애플 https://auth.example.com/oidc/.well-known/openid-configuration ``` -### 소셜 커넥터의 콜백 URI 업데이트하기 \{#updating-the-social-connectors-callback-uri} +### 소셜 커넥터의 콜백 URI 업데이트 \{#updating-the-social-connectors-callback-uri} -사용자가 커스텀 도메인을 사용하는 경우, 소셜 커넥터의 콜백 URI는 자동으로 새 도메인을 사용하게 됩니다. 하지만, 소셜 제공업체의 개발자 콘솔에 접속하여 콜백 URI를 직접 업데이트해야 합니다. +사용자가 커스텀 도메인을 사용하는 경우, 소셜 커넥터의 콜백 URI는 자동으로 새 도메인으로 변경됩니다. 소셜 제공업체의 개발자 콘솔에 접속하여 콜백 URI를 수동으로 업데이트해야 합니다. -커스텀 도메인을 사용하는 경우, 소셜 커넥터의 콜백 URI도 새 도메인을 사용하게 되므로, 반드시 소셜 제공업체의 개발자 콘솔에서 콜백 URI를 수동으로 업데이트해야 합니다. +사용자가 커스텀 도메인을 사용하는 경우, 소셜 커넥터의 콜백 URI도 새 도메인을 사용하게 됩니다. 따라서 소셜 제공업체의 개발자 콘솔로 이동하여 콜백 URI를 직접 업데이트해야 합니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..ce62b185ca5 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# 시스템 한도 + +Logto에서는 모든 요금제에 대해 넉넉한 한도를 설정하고, 유연한 종량제 옵션을 제공하여 사용자가 실제로 사용하는 만큼만 비용을 지불할 수 있도록 했습니다. + +가격 페이지의 일부 항목이 _무제한_ 또는 *상한 없는 연속 종량제*로 표시된 것을 볼 수 있습니다. 이는 일반적으로 제한 없이 사용할 수 있음을 의미하지만, Logto는 모든 사용자의 공정한 사용을 보장하기 위해 실제 한도를 시간이 지남에 따라 조정할 권리를 보유합니다. 즉, 엔티티 한도는 플랫폼의 전반적인 건강을 보호하는 엄격한 상한선입니다. 이는 가격 정책의 일부가 아니지만, 요금제 그룹에 따라 다를 수 있습니다. + +사용 사례가 합리적임에도 시스템 한도에 도달한 경우, 언제든지 저희에게 연락하여 의견을 공유해 주세요. 이는 실제 사용 패턴을 더 잘 이해하고, 충성도 높은 고객을 더 잘 지원할 수 있도록 시스템 한도를 조정하는 데 도움이 됩니다. + +## 테넌트 수준 속도 제한 보호 \{#tenant-level-rate-limit-protection} + +### Dev 테넌트 \{#dev-tenants} + +Dev 테넌트의 경우, 사용자는 Logto의 무료 기능과 혜택을 활용할 수 있습니다. 남용을 방지하고 명확한 기대치를 설정하기 위해 특정 시스템 한도를 정의합니다. 이러한 한도는 테스트 및 개발 목적으로 무료 접근을 제공하면서도 플랫폼을 지속적으로 관리하는 데 도움이 됩니다. + +쿼터를 늘리고 싶으시다면 언제든지 저희에게 연락해 주세요. 또한 **Dev**에서 **Pro**로 업그레이드하면 한도가 해제되어 즉시 전체 기능을 사용할 수 있으니 권장합니다. + +| **기능** | **엔티티 한도** | +| -------------------------------- | --------------- | +| **포함된 토큰** | 월 5만 개 | +| **애플리케이션** | | +| 전체 애플리케이션 | 100 | +| 기계 간 애플리케이션 | 100 | +| 서드파티 애플리케이션 | 100 | +| **API 리소스** | | +| 리소스 개수 | 100 | +| **사용자 인증 (Authentication)** | | +| 소셜 커넥터 | 100 | +| 엔터프라이즈 SSO | 100 | +| **사용자 관리** | | +| 사용자 역할 | 100 | +| 기계 간 역할 | 100 | +| 역할당 권한 | 100 | +| **조직** | | +| 조직 개수 | 5,000 | +| 조직당 사용자 | 10만 | +| 조직 사용자 역할 | 1,000 | +| 조직 기계 간 역할 | 100 | +| 조직 권한 | 1,000 | +| **개발자 및 플랫폼** | | +| Webhook | 10 | +| 감사 로그 보관 기간 | 14일 | +| 테넌트 멤버 | 20 | + +### Pro 테넌트 \{#pro-tenant} + +Pro 테넌트의 경우, 엔티티 한도는 애드온 및 애플리케이션과 같은 "무제한" 엔티티의 상한선을 정의합니다. Pro 요금제의 시스템 한도는 아래와 같습니다. + +| **기능** | **엔티티 한도** | +| -------------------------------- | --------------- | +| **포함된 토큰** | 월 1,000만 개 | +| **애플리케이션** | | +| 전체 애플리케이션 | 100 | +| 기계 간 애플리케이션 | 100 | +| OIDC/OAuth 서드파티 애플리케이션 | 100 | +| SAML 애플리케이션 | 100 | +| **API 리소스** | | +| 리소스 개수 | 1,000 | +| 리소스당 권한 | 1,000 | +| **사용자 인증 (Authentication)** | | +| 소셜 커넥터 | 100 | +| 엔터프라이즈 SSO | 100 | +| **사용자 관리** | | +| 사용자 역할 | 1,000 | +| 기계 간 역할 | 100 | +| **조직** | | +| 조직 개수 | 10만 | +| 조직당 사용자 | 10만 | +| 조직 사용자 역할 | 1,000 | +| 조직 기계 간 역할 | 100 | +| 조직 권한 | 1,000 | +| **개발자 및 플랫폼** | | +| Webhook | 10 | +| 감사 로그 보관 기간 | 14일 | +| 커스텀 도메인 | 10 | +| 테넌트 멤버 | 100 | + +### 엔터프라이즈 \{#enterprise} + +엔터프라이즈 요금제의 경우, 한도와 기능은 계약을 통해 완전히 맞춤화 및 관리됩니다. 자세한 내용은 [문의해 주세요](https://logto.io/contact). diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index 25e011f89ea..6c56abc74a8 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -6,22 +6,22 @@ sidebar_position: 1 # 테넌트 설정 -Logto Cloud에 새로 가입한 사용자는 자동으로 무료 **개발(Development)**(Dev) 환경 테넌트에 온보딩됩니다. 이 테넌트에서 모든 기능을 탐색할 수 있습니다. +Logto Cloud에 새로 가입한 사용자는 자동으로 무료 **개발(Development)** (Dev) 환경 테넌트에 온보딩됩니다. 이 테넌트에서 모든 기능을 탐색할 수 있습니다. -**프로덕션(Production)**(Prod) 환경이나 새로운 프로젝트를 위한 별도의 테넌트를 만들고 싶다면, 상단 바의 왼쪽 상단에 있는 현재 테넌트 이름을 클릭하세요. 이 메뉴에서 테넌트 간 전환 또는 새 테넌트 생성을 할 수 있습니다. +**프로덕션(Production)** (Prod) 환경이나 새로운 프로젝트를 위한 별도의 테넌트를 만들고 싶다면, 상단 바의 왼쪽 상단에 있는 현재 테넌트 이름을 클릭하세요. 이 메뉴에서 테넌트 간 전환 또는 새 테넌트 생성을 할 수 있습니다. -"테넌트 생성"을 클릭한 후 다음을 진행하세요: +"테넌트 생성"을 클릭한 후 다음을 입력하세요: -- 테넌트 이름 지정 +- 테넌트 이름 - [테넌트 데이터 지역](#tenant-region) 선택 - [테넌트 유형](#tenant-types-dev-vs-prod) (환경) 선택 -기존 테넌트의 경우, 콘솔 > 테넌트 설정 > 설정로 이동하세요. 여기에서 다음을 할 수 있습니다: +기존 테넌트의 경우, 콘솔 > 테넌트 설정 > 설정로 이동하세요. 여기서 다음을 할 수 있습니다: - 테넌트 ID 확인 - 테넌트 이름 변경 - [테넌트 지역](#tenant-region) 확인 (생성 후 변경 불가) -- [테넌트 유형](#tenant-types-dev-vs-prod) 확인 (필요 시 Dev 테넌트를 Prod 테넌트로 전환 가능) +- [테넌트 유형](#tenant-types-dev-vs-prod) 확인 (필요 시 Dev 테넌트를 Prod 테넌트로 변환 가능) - [테넌트 나가기](#leave-tenant) - [테넌트 삭제](#delete-tenant) @@ -36,10 +36,10 @@ Logto Cloud에 새로 가입한 사용자는 자동으로 무료 **개발(Develo 일반적으로 고객과 가장 가까운 지역을 선택하여 지연 시간을 최소화하고 성능을 향상시키는 것이 좋습니다. -Logto는 글로벌 엣지 네트워크를 활용하여 애플리케이션에 최고의 성능과 가용성을 제공합니다. 요청 라우팅이 최적화되어 사용자가 항상 최상의 성능을 경험할 수 있도록 합니다. +Logto는 글로벌 엣지 네트워크를 활용하여 애플리케이션에 최고의 성능과 가용성을 제공합니다. 요청 라우팅이 최적화되어 사용자가 항상 최상의 성능으로 연결될 수 있도록 보장합니다. :::note -다른 지역이 필요하신가요? [문의하기](https://logto.io/contact) 를 통해 다음을 요청할 수 있습니다: +다른 지역이 필요하신가요? [문의하기](https://logto.io/contact): - 새로운 퍼블릭 클라우드 지역 요청 - 원하는 위치에 Logto 프라이빗 클라우드 배포 문의 @@ -47,88 +47,62 @@ Logto는 글로벌 엣지 네트워크를 활용하여 애플리케이션에 최 ## 테넌트 유형: Dev vs. Prod \{#tenant-types-dev-vs-prod} -Logto Cloud에는 두 가지 유형의 테넌트가 있습니다: 개발(Development, Dev)과 프로덕션(Production, Prod). 이 테넌트 구분을 통해 다양한 환경에서 프로젝트를 효율적으로 관리하고, 동시에 Logto의 모든 가치를 누릴 수 있습니다. +Logto Cloud에는 두 가지 유형의 테넌트가 있습니다: 개발(Development, Dev)과 프로덕션(Production, Prod). 이 테넌트 구분을 통해 다양한 환경에서 프로젝트를 효율적으로 관리할 수 있으며, 동시에 Logto의 모든 가치를 누릴 수 있습니다. -테넌트 생성 시 유형을 선택할 수 있습니다. 프로덕션 환경에서 실제 운영을 시작할 준비가 되면 두 가지 옵션이 있습니다: +테넌트 생성 시 유형을 선택할 수 있습니다. 프로덕션 환경에서 라이브로 전환할 준비가 되면 두 가지 옵션이 있습니다: - **새로운 프로덕션 테넌트 생성** - 새로운 프로덕션 테넌트를 생성하고 처음부터 설정하세요. 개발 환경과 프로덕션 환경을 분리하고 싶을 때 이상적입니다. -- **현재 Dev 테넌트를 프로덕션으로 전환** - 설정을 다시 하거나 사용자를 마이그레이션하지 않으려면, 기존 개발(Development) 테넌트를 유료 프로덕션(Production) 테넌트로 업그레이드할 수 있습니다. + 새 프로덕션 테넌트를 설정하고 처음부터 구성하세요. 개발 환경과 프로덕션 환경을 분리하고 싶을 때 이상적입니다. +- **현재 Dev 테넌트를 프로덕션으로 변환** + 구성을 다시 하거나 사용자를 마이그레이션하지 않으려면, 기존 개발 테넌트를 유료 프로덕션 테넌트로 업그레이드할 수 있습니다. - - **Pro 요금제로 전환**: 콘솔 > 테넌트 설정 > 설정로 이동한 후 "전환"을 클릭하여 셀프 서비스로 업그레이드하세요. Dev 테넌트에서 사용한 유료 기능은 Stripe 결제에 그대로 반영됩니다. - - **엔터프라이즈 요금제로 전환**: [문의하기](https://logto.io/contact) 를 통해 업그레이드를 도와드립니다. + - **Pro 플랜으로 변환**: 콘솔 > 테넌트 설정 > 설정로 이동한 후 "변환"을 클릭하여 셀프 서비스로 업그레이드하세요. Dev 테넌트에서 사용한 유료 기능은 Stripe 결제에 반영됩니다. + - **엔터프라이즈 플랜으로 변환**: [문의하기](https://logto.io/contact)로 연락주시면 업그레이드를 도와드립니다. :::note - 한 번 전환하면 테넌트를 Dev 환경으로 되돌릴 수 없습니다. 준비가 되었는지 반드시 확인 후 진행하세요. + 한 번 변환하면 테넌트를 Dev 환경으로 되돌릴 수 없습니다. 준비가 되었는지 반드시 확인 후 진행하세요. ::: ### 개발(Development) \{#development} -개발 테넌트(Dev 테넌트)는 주로 테스트 용도로 사용되며, 프로덕션 환경에서는 사용하지 않는 것이 좋습니다. 이 테넌트에서는 유료 요금제의 프리미엄 및 유료 기능을 무료로, 구독 없이 사용할 수 있습니다. +개발 테넌트(Dev 테넌트)는 주로 테스트 용도로 사용되며, 프로덕션 환경에서는 사용하지 않는 것이 좋습니다. 이 테넌트에서는 유료 플랜에서 제공하는 프리미엄 및 유료 기능을 무료로, 구독 없이 사용할 수 있습니다. 단, 개발 테넌트에는 다음과 같은 제한이 있습니다: - Dev 테넌트는 90일이 지난 사용자를 자동으로 삭제합니다. 자세한 내용은 [Dev 테넌트 데이터 보존 정책](./dev-tenant-data-retention)을 확인하세요. -- 로그인 경험 중 테넌트가 개발 모드임을 알리는 배너가 표시됩니다. -- 개발 테넌트는 일부 기능에 쿼터 제한이 있을 수 있습니다. 해당 제한은 기능 상세 페이지에 안내됩니다. -- Logto는 개발 테넌트의 쿼터 제한을 변경할 수 있으며, 사전에 최대한 안내해 드립니다. - -| 기능 | 엔티티 제한 | -| -------------------- | ----------- | -| **포함된 토큰** | 월 5만 개 | -| **애플리케이션** | -| 전체 애플리케이션 | 100 | -| 기계 간(M2M) 앱 | 100 | -| 서드파티 앱 | 100 | -| **API 리소스** | | -| 리소스 개수 | 100 | -| **사용자 인증** | | -| 소셜 커넥터 | 100 | -| 엔터프라이즈 SSO | 100 | -| **사용자 관리** | | -| 사용자 역할 | 100 | -| 기계 간 역할 | 100 | -| 역할당 권한 | 100 | -| **조직** | | -| 조직 개수 | 5,000 | -| 조직당 사용자 | 5,000 | -| 조직 역할 | 100 | -| 조직 권한 | 100 | -| **개발자 및 플랫폼** | | -| Webhook | 10 | -| 감사 로그 보존 | 14일 | -| 테넌트 멤버 | 20 | +- 로그인 경험 중에 테넌트가 개발 모드임을 알리는 배너가 표시됩니다. +- 개발 테넌트는 특정 기능에 쿼터 제한이 있을 수 있습니다. 해당 제한은 기능 상세 페이지에서 확인할 수 있습니다. Dev 플랜의 전체 제한 목록은 [시스템 제한](./system-limit) 페이지를 참고하세요. +- Logto는 개발 테넌트의 쿼터 제한을 업데이트할 수 있으며, 사전에 최대한 안내해 드릴 예정입니다. ### 프로덕션(Production) \{#production} -프로덕션 테넌트는 최종 사용자가 실제 앱에 접근하는 공간이며, [유료 구독](https://logto.io/pricing)이 필요할 수 있습니다. 프로덕션 테넌트 생성을 위해 Free 요금제 또는 Pro 요금제에 가입할 수 있습니다. Free 요금제 구독 시 최대 10개의 테넌트만 생성할 수 있습니다. +프로덕션 테넌트는 최종 사용자가 실제 앱에 접근하는 환경이며, [유료 구독](https://logto.io/pricing)이 필요할 수 있습니다. 프로덕션 테넌트 생성을 위해 무료 플랜 또는 Pro 플랜에 가입할 수 있습니다. 무료 플랜을 구독할 경우 최대 10개의 테넌트만 생성할 수 있습니다. ## MFA 활성화 \{#enable-mfa} Logto Pro/Enterprise 테넌트의 모든 멤버에게 다단계 인증 (MFA)을 요구하여 워크스페이스 보안을 강화하세요. -셀프 서비스는 아직 지원되지 않으므로, 해당 기능 활성화를 원하시면 [문의하기](https://logto.io/contact) 를 이용해 주세요. +셀프 서비스는 아직 지원되지 않으므로, 이 기능 활성화를 원하시면 [문의하기](https://logto.io/contact)로 연락해 주세요. ## 엔터프라이즈 SSO 활성화 \{#enable-enterprise-sso} -Logto Cloud는 엔터프라이즈 요금제 테넌트에 대해 Google Workspace, Okta, Azure AD 등과 같은 공급자를 포함한 엔터프라이즈 싱글 사인온 (SSO) 통합을 지원합니다. +Logto Cloud는 엔터프라이즈 플랜 테넌트에 대해 Google Workspace, Okta, Azure AD 등과 같은 공급자를 포함한 엔터프라이즈 싱글 사인온 (SSO) 통합을 지원합니다. -시작하려면 [문의하기](https://logto.io/contact) 를 통해 빠르게 설정을 도와드리겠습니다. +시작하려면 [문의하기](https://logto.io/contact)로 연락해 주세요. 빠르게 설정을 도와드리겠습니다. ## 테넌트 나가기 \{#leave-tenant} 관리자는 이 테넌트에 [추가 멤버를 초대](/logto-cloud/tenant-member-management)할 수 있습니다. -**관리자**(역할)가 한 명 이상이거나, **협업자**(역할)인 경우 테넌트에서 나갈 수 있습니다. 나간 후에는 테넌트 내 모든 리소스는 그대로 남지만, 더 이상 접근할 수 없습니다. +다른 **관리자**(역할)가 최소 한 명 이상 있거나, 본인이 **협업자**(역할)라면 테넌트에서 나갈 수 있습니다. 나간 후에는 테넌트 내 모든 리소스가 그대로 남지만, 더 이상 접근할 수 없습니다. 마지막 관리자인 경우, 나가기 전에 다른 협업자를 관리자로 지정해야 합니다. ## 테넌트 삭제 \{#delete-tenant} -[관리자](/logto-cloud/tenant-member-management#invite-collaborators)는 Logto 테넌트를 삭제할 수 있습니다. 테넌트 삭제 시 모든 관련 사용자 데이터와 설정이 영구적으로 삭제됩니다. 이 작업은 되돌릴 수 없습니다. Logto는 실수로 삭제되는 것을 방지하기 위해 테넌트 이름 입력을 요청합니다. +[관리자](/logto-cloud/tenant-member-management#invite-collaborators)는 Logto 테넌트를 삭제할 수 있습니다. 테넌트 삭제 시 모든 관련 사용자 데이터와 설정이 영구적으로 삭제됩니다. 이 작업은 되돌릴 수 없습니다. Logto는 실수로 삭제하는 것을 방지하기 위해 테넌트 이름 입력을 요청합니다. -도움이 필요하시면 [이메일로 문의](https://logto.io/contact)해 주세요. +도움이 필요하시면 [이메일로 문의하기](https://logto.io/contact)로 연락해 주세요. ## 자주 묻는 질문 \{#faqs} @@ -139,16 +113,16 @@ Logto Cloud는 엔터프라이즈 요금제 테넌트에 대해 Google Workspace -현재 **개발(Development)** 테넌트를 직접 **유료(Production)** 테넌트로 전환할 수 있습니다. [자세히 알아보기](#tenant-types-dev-vs-prod) +현재 **개발(Development)** 테넌트를 유료 플랜 **프로덕션(Production)** 테넌트로 직접 변환할 수 있습니다. [자세히 알아보기](#tenant-types-dev-vs-prod) -단, Logto Cloud와 OSS 버전 간의 (모든 설정 및 사용자 데이터) 셀프 서비스 마이그레이션은 지원되지 않습니다. 이 서비스가 필요하다면 [Logto 팀에 문의](https://logto.io/contact)하여 옵션을 논의하세요. +단, Logto Cloud와 OSS 버전 간의 (모든 설정 및 사용자 데이터) 셀프 서비스 마이그레이션은 지원되지 않습니다. 이 서비스가 필요하다면 [Logto 팀에 문의](https://logto.io/contact)하여 옵션을 논의해 주세요. -프로젝트에서 Logto Cloud 사용을 중단할 계획이라면, Logto가 모든 사용자 데이터 내보내기를 도와드릴 수 있습니다. [문의하기](https://logto.io/contact)를 이용해 주세요. +프로젝트에서 Logto Cloud 사용을 중단할 계획이라면, Logto가 모든 사용자 데이터 내보내기를 도와드릴 수 있습니다. [문의하기](https://logto.io/contact)로 연락해 주세요. ## 관련 리소스 \{#related-resources} - 로컬 지역 및 전용 컴퓨팅 리소스에서 아이덴티티를 보호하세요 + 현지 지역 및 전용 컴퓨팅 리소스에서 아이덴티티를 보호하세요 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index 298f4621c26..f3e216336e9 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -1,5 +1,5 @@ --- -description: Logto 오픈 소스 서비스 (OSS) 초기화를 위한 빠른 시작 가이드입니다. +description: Logto 오픈소스 서비스 (OSS) 초기화를 위한 빠른 시작 가이드입니다. sidebar_position: 1 --- @@ -17,24 +17,24 @@ import Tabs from '@theme/Tabs'; ## GitPod \{#gitpod} -Logto를 위한 온라인 GitPod 워크스페이스를 시작하려면, 여기를 클릭하세요. 잠시 기다리면 다음과 같은 메시지가 나타납니다: +Logto를 위한 온라인 GitPod 워크스페이스를 시작하려면 여기를 클릭하세요. 잠시 기다리면 다음과 같은 메시지가 표시됩니다:

Gitpod is running

-Logto는 기본적으로 핵심 서비스에 포트 `3001`을, 상호작용 관리 콘솔에 포트 `3002`를 사용합니다. +Logto는 기본적으로 코어 서비스에 포트 `3001`을, 인터랙티브 Admin Console에 포트 `3002`를 사용합니다. -Logto 여정을 계속하려면 Ctrl (또는 Cmd)을 누르고 `https://3002-...`로 시작하는 링크를 클릭하세요. 즐기세요! +Logto 여정을 계속하려면 Ctrl (또는 Cmd) 키를 누른 채 `https://3002-...`로 시작하는 링크를 클릭하세요. 즐기세요! ## 로컬 \{#local} -Logto를 호스팅하기 위한 최소 권장 하드웨어 요구 사항은 다음과 같습니다: +Logto를 호스팅하기 위한 최소 권장 하드웨어 사양은 다음과 같습니다: - **vCPU**: 2 - **메모리**: 8 GiB @@ -44,17 +44,18 @@ Logto를 호스팅하기 위한 최소 권장 하드웨어 요구 사항은 다 -Docker Compose CLI는 일반적으로 [Docker Desktop](https://www.docker.com/products/docker-desktop)과 함께 제공됩니다. +Docker Compose CLI는 일반적으로 [Docker Desktop](https://www.docker.com/products/docker-desktop)에 포함되어 있습니다. :::caution -프로덕션 환경에서는 우리의 docker compose 명령을 사용하지 마세요! 현재 Logto 앱과 함께 번들로 제공되는 내장 Postgres 데이터베이스가 `docker-compose.yml`에 포함되어 있어, 명령을 다시 실행할 때마다 새로운 데이터베이스 인스턴스가 생성되고 이전에 저장된 데이터는 모두 손실됩니다. +프로덕션 환경에서는 우리의 docker compose 명령어를 사용하지 마세요! 현재 `docker-compose.yml`에서 Logto 앱과 함께 내장된 Postgres 데이터베이스가 번들로 제공되기 때문에, +명령어를 다시 실행할 때마다 새로운 데이터베이스 인스턴스가 생성되며, 이전에 저장된 모든 데이터가 삭제됩니다. ::: ```bash curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | docker compose -p logto -f - up ``` -성공적으로 구성되면 다음과 같은 메시지가 나타납니다: +구성이 성공적으로 완료되면 다음과 같은 메시지가 표시됩니다: @@ -62,7 +63,7 @@ curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.

1단계

-[PostgreSQL](https://www.postgresql.org/)@^14.0 인스턴스를 준비하고, [Logto CLI](/logto-oss/using-cli)를 사용하여 Logto를 위한 데이터베이스를 시드하세요: +[PostgreSQL](https://www.postgresql.org/)@^14.0 인스턴스를 준비하고, [Logto CLI](/logto-oss/using-cli)를 사용하여 Logto용 데이터베이스를 시드하세요: @@ -96,16 +97,16 @@ docker pull svhd/logto:latest

3단계

-컨테이너 포트를 Logto 핵심 및 관리자 앱에 매핑합니다. 예를 들어, `3001:3001` 및 `3002:3002`로 설정하고, 다음 환경 변수를 컨테이너에 설정합니다: +컨테이너 포트를 Logto 코어 및 관리자 앱에 매핑하세요. 예: `3001:3001` 및 `3002:3002`; 그리고 다음 환경 변수를 컨테이너에 설정하세요: ```yml -TRUST_PROXY_HEADER: 1 # Logto 앞에 HTTPS 프록시 (예: Nginx)가 있는 경우 1로 설정 -ENDPOINT: https:// # (선택 사항) 사용자 지정 도메인을 사용하는 경우 Logto 엔드포인트 URL로 대체 -ADMIN_ENDPOINT: https:// # (선택 사항) 사용자 지정 도메인을 사용하는 경우 Logto 관리자 URL로 대체 -DB_URL: postgres://username:password@your_postgres_url:port/db_name # Postgres DSN으로 대체 +TRUST_PROXY_HEADER: 1 # Logto 앞에 HTTPS 프록시(예: Nginx)가 있다면 1로 설정 +ENDPOINT: https:// # (선택 사항) 커스텀 도메인을 사용하는 경우 Logto 엔드포인트 URL로 교체 +ADMIN_ENDPOINT: https:// # (선택 사항) 커스텀 도메인을 사용하는 경우 Logto 관리자 URL로 교체 +DB_URL: postgres://username:password@your_postgres_url:port/db_name # Postgres DSN으로 교체 ``` -위의 모든 환경 변수를 사용하여 컨테이너를 실행합니다: +위의 모든 환경 변수를 포함하여 컨테이너를 실행하세요: ```bash docker run \ @@ -121,35 +122,35 @@ docker run \ :::tip -- Docker Hub를 사용하는 경우, `ghcr.io/logto-io/logto:latest` 대신 `svhd/logto:latest`를 사용하세요. +- Docker Hub를 사용하는 경우 `ghcr.io/logto-io/logto:latest` 대신 `svhd/logto:latest`를 사용하세요. - `DB_URL`에서 호스트 IP를 참조하려면 `host.docker.internal` 또는 `172.17.0.1`을 사용하세요. ::: -마지막으로, 다음과 같은 메시지가 나타납니다: +마지막으로 다음과 같은 메시지가 표시됩니다:
-**필수 조건** +**사전 준비 사항** - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -더 높은 버전도 작동할 수 있지만 보장되지는 않습니다. +더 높은 버전도 일반적으로 동작하지만 보장되지는 않습니다. -Logto에 전용된 새로운 빈 데이터베이스를 사용하는 것을 권장하지만, 필수는 아닙니다. +Logto 전용의 새로운 빈 데이터베이스를 사용하는 것을 권장하지만, 필수는 아닙니다. **다운로드 및 시작** -터미널에서: +터미널에서 다음을 실행하세요: ```bash npm init @logto@latest ``` -초기화 과정을 완료하고 Logto를 시작하면 다음과 같은 메시지가 나타납니다: +초기화 과정을 완료하고 Logto를 시작하면 다음과 같은 메시지가 표시됩니다: @@ -172,13 +173,13 @@ Admin app is running at https://your-admin-domain-url -Logto zip 파일의 URL을 지정하려면 `--download-url` 옵션을 사용하세요. 예를 들어: +Logto zip 파일의 URL을 지정하려면 `--download-url` 옵션을 사용하세요. 예시: ``` npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -NPM이 인수를 전달하도록 하기 위해 추가 `--`가 필요합니다. +NPM이 인자를 전달하려면 추가 `--`가 필요합니다. @@ -190,15 +191,15 @@ NPM이 인수를 전달하도록 하기 위해 추가 `--`가 필요합니다. -Logto는 환경 변수를 사용하여 구성하며, `.env` 파일 지원도 제공합니다. 자세한 사용법과 전체 변수 목록은 [구성](/concepts/core-service/configuration)을 참조하세요. +Logto는 환경 변수와 `.env` 파일 지원을 통해 구성할 수 있습니다. 자세한 사용법과 전체 변수 목록은 [구성](/concepts/core-service/configuration)을 참고하세요. -_Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하다면 [핵심 서비스](/concepts/core-service)를 확인하세요._ +_더 고급 제어나 프로그래밍 방식 접근이 필요하다면 [코어 서비스](/concepts/core-service)를 확인하세요._ -## 호스팅 제공자 \{#hosting-providers} +## 호스팅 제공업체 \{#hosting-providers} -이 신뢰할 수 있는 호스팅 제공자들은 Logto를 위한 원클릭 설치 템플릿을 제공합니다. 쉽게 배포 가능한 서비스를 통해 Logto를 사용하여 CIAM 시스템을 몇 초 만에 설정하고 시작할 수 있습니다. +이 신뢰할 수 있는 호스팅 제공업체들은 Logto를 위한 원클릭 설치 템플릿을 제공합니다. 손쉽게 배포 가능한 서비스를 통해 Logto를 사용하여 CIAM 시스템을 몇 초 만에 구축하고 시작할 수 있습니다. , }, @@ -217,7 +218,7 @@ _Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하 label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', description: - '쉽게 앱과 데이터베이스를 관리할 수 있는 자체 호스팅 가능한 Heroku/Netlify 대안입니다.', + '앱 및 데이터베이스 관리를 쉽게 할 수 있는 셀프 호스팅 Heroku/Netlify 대안입니다.', customProps: { icon: , }, @@ -226,7 +227,7 @@ _Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하 type: 'link', label: 'Dokploy', href: 'https://docs.dokploy.com/docs/core', - description: '자신의 인프라에 앱을 배포하기 위한 경량 도구입니다.', + description: '자체 인프라에 앱을 배포할 수 있는 경량 툴입니다.', customProps: { icon: , }, @@ -235,7 +236,7 @@ _Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하 type: 'link', label: 'Easypanel', href: 'https://easypanel.io/docs/templates/logto', - description: 'Docker로 클라우드 서버를 관리하기 위한 현대적인 제어판입니다.', + description: 'Docker로 클라우드 서버를 관리할 수 있는 현대적인 컨트롤 패널입니다.', customProps: { icon: , }, @@ -244,7 +245,7 @@ _Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하 type: 'link', label: 'Elestio', href: 'https://elest.io/open-source/logto', - description: '코드와 오픈 소스 소프트웨어를 배포하기 위한 완전 관리형 DevOps 플랫폼입니다.', + description: '코드와 오픈소스 소프트웨어를 배포할 수 있는 완전 관리형 DevOps 플랫폼입니다.', customProps: { icon: , }, @@ -253,7 +254,7 @@ _Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하 type: 'link', label: 'Railway', href: 'https://railway.com/template/07_f_Z', - description: '앱 배포 및 인프라 관리를 간소화합니다.', + description: '앱 배포와 인프라 관리를 간소화합니다.', customProps: { icon: , }, @@ -262,7 +263,7 @@ _Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하 type: 'link', label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', - description: '개발자를 위한 앱 배포, 확장 및 모니터링을 간소화합니다.', + description: '개발자를 위한 앱 배포, 확장, 모니터링을 간소화합니다.', customProps: { icon: , }, @@ -270,12 +271,16 @@ _Logto에 대한 더 고급의 제어나 프로그래밍적 접근이 필요하 ]} /> -타사 서비스 제공자에 대한 고객 지원은 제공하지 않습니다. 지원 채널에 접근하려면 [Logto Cloud](https://cloud.logto.io)에 배포해 주세요. 감사합니다! +타사 서비스 제공업체에 대해서는 고객 지원을 제공하지 않습니다. 저희 지원 채널을 이용하려면 [Logto Cloud](https://cloud.logto.io)에 배포해 주세요. 감사합니다! -## 계정 생성 \{#create-an-account} +## 계정 생성하기 \{#create-an-account} -Logto를 서버에 성공적으로 호스팅한 후, 환영 페이지에서 "계정 생성"을 클릭하세요. Logto의 오픈 소스 버전은 초기 실행 시 하나의 계정 생성만 허용하며, 여러 계정을 지원하지 않습니다. 계정 생성 과정은 사용자 이름과 비밀번호 조합으로 제한됩니다. +Logto를 서버에 성공적으로 호스팅한 후, 환영 페이지에서 "계정 생성"을 클릭하세요. 오픈소스 버전의 Logto는 최초 실행 시 한 번만 계정 생성을 허용하며, 여러 계정을 지원하지 않습니다. 계정 생성은 사용자 이름과 비밀번호 조합으로만 제한됩니다. + +:::tip +Logto OSS (셀프 호스팅)는 여러 관리자를 구성할 수 없습니다. 팀 협업이나 여러 관리자 사용자가 필요한 프로젝트의 경우, 전체 팀 관리 기능을 제공하는 [Logto Cloud](https://cloud.logto.io) 사용을 권장합니다. +::: ## 관련 리소스 \{#related-resources} -로컬 HTTPS 개발 처리하기 +로컬 HTTPS 개발 다루기 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index df8ece88066..2684e154c21 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot는 Java 프로그래밍 언어로 안전하고 빠르며 확장 가능한 서버 애플리케이션을 구축할 수 있도록 하는 Java 웹 프레임워크입니다. + description: Spring Boot는 Java 프로그래밍 언어로 안전하고 빠르며 확장 가능한 서버 애플리케이션을 개발할 수 있게 해주는 Java용 웹 프레임워크입니다. logoFilename: 'spring-boot.svg' --- @@ -16,26 +16,26 @@ import ScopesAndClaims from './_scopes-and-claims.mdx'; # Java Spring Boot 애플리케이션에 인증 (Authentication)을 추가하세요 -이 가이드는 Logto를 Java Spring Boot 애플리케이션에 통합하는 방법을 보여줍니다. +이 가이드에서는 Logto를 Java Spring Boot 애플리케이션에 통합하는 방법을 안내합니다. :::tip -- 이 가이드의 샘플 코드는 [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub 저장소에서 찾을 수 있습니다. -- Java Spring Boot 애플리케이션에 Logto를 통합하기 위해 공식 SDK가 필요하지 않습니다. 우리는 Logto와 함께 OIDC 인증 흐름을 처리하기 위해 [Spring Security](https://spring.io/projects/spring-security) 및 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 라이브러리를 사용할 것입니다. +- 이 가이드의 샘플 코드는 [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) github 저장소에서 확인할 수 있습니다. +- Java Spring Boot 애플리케이션에 Logto를 통합하기 위해 공식 SDK가 필요하지 않습니다. Logto와 함께 OIDC 인증 (Authentication) 플로우를 처리하기 위해 [Spring Security](https://spring.io/projects/spring-security) 및 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 라이브러리를 사용할 것입니다. ::: ## 사전 준비 사항 \{#prerequisites} -- [Logto Cloud](https://cloud.logto.io) 계정 또는 [자체 호스팅 Logto](/introduction/set-up-logto-oss). -- 우리의 샘플 코드는 Spring Boot [웹 보안 스타터](https://spring.io/guides/gs/securing-web)를 사용하여 생성되었습니다. 웹 애플리케이션이 없는 경우 새 웹 애플리케이션을 부트스트랩하는 지침을 따르세요. -- 이 가이드에서는 Logto와 함께 OIDC 인증 흐름을 처리하기 위해 [Spring Security](https://spring.io/projects/spring-security) 및 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 라이브러리를 사용할 것입니다. 개념을 이해하기 위해 공식 문서를 반드시 읽어보세요. +- [Logto Cloud](https://cloud.logto.io) 계정 또는 [셀프 호스팅 Logto](/introduction/set-up-logto-oss). +- 샘플 코드는 Spring Boot [securing web starter](https://spring.io/guides/gs/securing-web)를 사용하여 생성되었습니다. 웹 애플리케이션이 없다면 해당 안내에 따라 새로 부트스트랩하세요. +- 이 가이드에서는 [Spring Security](https://spring.io/projects/spring-security) 및 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 라이브러리를 사용하여 Logto와 OIDC 인증 (Authentication) 플로우를 처리합니다. 개념을 이해하기 위해 공식 문서를 꼭 참고하세요. -## Java Spring Boot 애플리케이션 구성 \{#configure-your-java-spring-boot-application} +## Java Spring Boot 애플리케이션 구성하기 \{#configure-your-java-spring-boot-application} -### 종속성 추가 \{#adding-dependencies} +### 의존성 추가하기 \{#adding-dependencies} -[gradle](https://spring.io/guides/gs/gradle) 사용자는 다음 종속성을 `build.gradle` 파일에 추가하세요: +[gradle](https://spring.io/guides/gs/gradle) 사용자의 경우, `build.gradle` 파일에 다음 의존성을 추가하세요: ```groovy title="build.gradle" dependencies { @@ -46,7 +46,7 @@ dependencies { } ``` -[maven](https://spring.io/guides/gs/maven) 사용자는 다음 종속성을 `pom.xml` 파일에 추가하세요: +[maven](https://spring.io/guides/gs/maven) 사용자의 경우, `pom.xml` 파일에 다음 의존성을 추가하세요: ```xml title="pom.xml" @@ -69,9 +69,9 @@ dependencies { ### OAuth2 클라이언트 구성 \{#oauth2-client-configuration} -Logto Console에서 새로운 `Java Spring Boot` 애플리케이션을 등록하고 웹 애플리케이션에 대한 클라이언트 자격 증명 및 IdP 구성을 가져옵니다. +Logto Console에서 새로운 `Java Spring Boot` 애플리케이션을 등록하고, 웹 애플리케이션에 필요한 클라이언트 자격 증명 및 IdP 구성을 받으세요. -다음 구성을 `application.properties` 파일에 추가하세요: +`application.properties` 파일에 다음 구성을 추가하세요: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.client-name=logto @@ -91,15 +91,15 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc -사용자가 로그인한 후 애플리케이션으로 다시 리디렉션되도록 하려면 이전 단계에서 `client.registration.logto.redirect-uri` 속성을 사용하여 리디렉션 URI를 설정해야 합니다. +사용자가 로그인 후 애플리케이션으로 다시 리디렉션될 수 있도록, 이전 단계에서 `client.registration.logto.redirect-uri` 속성을 사용해 리디렉션 URI를 설정해야 합니다. - + -### WebSecurityConfig 구현 \{#implement-the-websecurityconfig} +### WebSecurityConfig 구현하기 \{#implement-the-websecurityconfig} -#### 프로젝트에 새로운 클래스 `WebSecurityConfig` 생성 \{#create-a-new-class-websecurityconfig-in-your-project} +#### 프로젝트에 새로운 클래스 `WebSecurityConfig` 생성하기 \{#create-a-new-class-websecurityconfig-in-your-project} -`WebSecurityConfig` 클래스는 애플리케이션의 보안 설정을 구성하는 데 사용됩니다. 이는 인증 및 인가 흐름을 처리하는 핵심 클래스입니다. 자세한 내용은 [Spring Security 문서](https://spring.io/guides/topicals/spring-security-architecture)를 참조하세요. +`WebSecurityConfig` 클래스는 애플리케이션의 보안 설정을 구성하는 데 사용됩니다. 인증 (Authentication) 및 인가 (Authorization) 플로우를 처리하는 핵심 클래스입니다. 자세한 내용은 [Spring Security 문서](https://spring.io/guides/topicals/spring-security-architecture)를 참고하세요. ```java title="WebSecurityConfig.java" package com.example.securingweb; @@ -115,9 +115,9 @@ public class WebSecurityConfig { } ``` -#### `idTokenDecoderFactory` 빈 생성 \{#create-a-idtokendecoderfactory-bean} +#### `idTokenDecoderFactory` 빈 생성하기 \{#create-a-idtokendecoderfactory-bean} -Logto는 기본 알고리즘으로 `ES384`를 사용하기 때문에, 동일한 알고리즘을 사용하도록 기본 `OidcIdTokenDecoderFactory`를 덮어써야 합니다. +Logto는 기본 알고리즘으로 `ES384`를 사용하므로, 기본 `OidcIdTokenDecoderFactory`를 동일한 알고리즘으로 덮어써야 합니다. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -138,9 +138,9 @@ public class WebSecurityConfig { } ``` -#### 로그인 성공 이벤트를 처리하기 위한 LoginSuccessHandler 클래스 생성 \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} +#### 로그인 성공 이벤트를 처리할 LoginSuccessHandler 클래스 생성하기 \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} -성공적인 로그인 후 사용자를 `/user` 페이지로 리디렉션합니다. +로그인에 성공하면 사용자를 `/user` 페이지로 리디렉션합니다. ```java title="CustomSuccessHandler.java" package com.example.securingweb; @@ -163,9 +163,9 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { } ``` -#### 로그아웃 성공 이벤트를 처리하기 위한 LogoutSuccessHandler 클래스 생성 \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} +#### 로그아웃 성공 이벤트를 처리할 LogoutSuccessHandler 클래스 생성하기 \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} -세션을 지우고 사용자를 홈 페이지로 리디렉션합니다. +세션을 삭제하고 사용자를 홈 페이지로 리디렉션합니다. ```java title="CustomLogoutHandler.java" package com.example.securingweb; @@ -195,11 +195,11 @@ public class CustomLogoutHandler implements LogoutSuccessHandler { } ``` -#### `securityFilterChain`으로 `WebSecurityConfig` 클래스 업데이트 \{#update-the-websecurityconfig-class-with-a-securityfilterchain} +#### `WebSecurityConfig` 클래스에 `securityFilterChain` 추가하기 \{#update-the-websecurityconfig-class-with-a-securityfilterchain} [securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html)은 들어오는 요청과 응답을 처리하는 필터 체인입니다. -우리는 `securityFilterChain`을 구성하여 홈 페이지에 대한 접근을 허용하고 다른 모든 요청에 대해 인증을 요구할 것입니다. 로그인 및 로그아웃 이벤트를 처리하기 위해 `CustomSuccessHandler` 및 `CustomLogoutHandler`를 사용합니다. +`securityFilterChain`을 구성하여 홈 페이지 접근을 허용하고, 그 외 모든 요청에 인증 (Authentication)을 요구하도록 설정합니다. 로그인 및 로그아웃 이벤트 처리는 `CustomSuccessHandler`와 `CustomLogoutHandler`를 사용합니다. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -214,8 +214,8 @@ public class WebSecurityConfig { http .authorizeRequests(authorizeRequests -> authorizeRequests - .antMatchers("/", "/home").permitAll() // 홈 페이지에 대한 접근 허용 - .anyRequest().authenticated() // 다른 모든 요청은 인증 필요 + .antMatchers("/", "/home").permitAll() // 홈 페이지 접근 허용 + .anyRequest().authenticated() // 그 외 모든 요청은 인증 (Authentication) 필요 ) .oauth2Login(oauth2Login -> oauth2Login @@ -230,9 +230,9 @@ public class WebSecurityConfig { } ``` -### 홈 페이지 생성 \{#create-a-home-page} +### 홈 페이지 생성하기 \{#create-a-home-page} -(프로젝트에 이미 홈 페이지가 있는 경우 이 단계를 건너뛸 수 있습니다) +(이미 프로젝트에 홈 페이지가 있다면 이 단계는 건너뛰어도 됩니다) ```java title="HomeController.java" package com.example.securingweb; @@ -251,19 +251,19 @@ public class HomeController { } ``` -이 컨트롤러는 사용자가 인증된 경우 사용자 페이지로 리디렉션하고, 그렇지 않으면 홈 페이지를 표시합니다. 홈 페이지에 로그인 링크를 추가하세요. +이 컨트롤러는 사용자가 인증 (Authentication)된 경우 사용자 페이지로 리디렉션하고, 그렇지 않으면 홈 페이지를 보여줍니다. 홈 페이지에 로그인 링크를 추가하세요. ```html title="resources/templates/home.html"

Welcome!

-

Login with Logto

+

Logto로 로그인

``` -### 사용자 페이지 생성 \{#create-a-user-page} +### 사용자 페이지 생성하기 \{#create-a-user-page} -사용자 페이지를 처리하기 위한 새로운 컨트롤러를 생성하세요: +사용자 페이지를 처리할 새로운 컨트롤러를 생성하세요: ```java title="UserController.java" package com.example.securingweb; @@ -299,54 +299,54 @@ public class UserController { } ``` -사용자가 인증되면, 인증된 주체 객체에서 `OAuth2User` 데이터를 가져옵니다. 자세한 내용은 [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) 및 [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html)를 참조하세요. +사용자가 인증 (Authentication)되면, 인증된 principal 객체에서 `OAuth2User` 데이터를 가져옵니다. 자세한 내용은 [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) 및 [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html)를 참고하세요. -사용자 데이터를 읽고 `user.html` 템플릿에 전달하세요. +사용자 데이터를 읽어 `user.html` 템플릿에 전달합니다. ```html title="resources/templates/user.html" -

User Details

+

사용자 정보

-

name:
-
email:
+
이름:
+
이메일:
id:

- +
``` -#### 추가 클레임 요청 \{#request-additional-claims} +#### 추가 클레임 (Claim) 요청하기 \{#request-additional-claims} -추가 사용자 정보를 검색하려면 `application.properties` 파일에 추가 스코프를 추가할 수 있습니다. 예를 들어, `email`, `phone`, 및 `urn:logto:scope:organizations` 스코프를 요청하려면 `application.properties` 파일에 다음 줄을 추가하세요: +추가 사용자 정보를 가져오려면, `application.properties` 파일에 추가 스코프 (Scope)를 넣을 수 있습니다. 예를 들어, `email`, `phone`, `urn:logto:scope:organizations` 스코프를 요청하려면 다음과 같이 추가하세요: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -그런 다음 `OAuth2User` 객체에서 추가 클레임에 접근할 수 있습니다. +이후 `OAuth2User` 객체에서 추가 클레임 (Claim)에 접근할 수 있습니다. -### 애플리케이션 실행 및 테스트 \{#run-and-test-the-application} +### 애플리케이션 실행 및 테스트하기 \{#run-and-test-the-application} 애플리케이션을 실행하고 `http://localhost:8080`으로 이동하세요. -- 로그인 링크가 있는 홈 페이지를 볼 수 있습니다. +- 로그인 링크가 있는 홈 페이지가 보입니다. - 링크를 클릭하여 Logto로 로그인하세요. -- 인증이 성공하면 사용자 세부 정보가 포함된 사용자 페이지로 리디렉션됩니다. -- 로그아웃 버튼을 클릭하여 로그아웃하세요. 홈 페이지로 다시 리디렉션됩니다. +- 인증 (Authentication)에 성공하면 사용자 정보가 있는 사용자 페이지로 리디렉션됩니다. +- 로그아웃 버튼을 클릭하면 로그아웃되고 다시 홈 페이지로 이동합니다. -## 스코프 및 클레임 \{#scopes-and-claims} +## 스코프 (Scope)와 클레임 (Claim) \{#scopes-and-claims} -## 추가 읽을거리 \{#further-readings} +## 추가 참고 자료 \{#further-readings} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index e8b694ce385..a892bc7319c 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -1,34 +1,34 @@ --- id: federated-token-set -title: 서드파티 토큰 저장소 & API 접근 -sidebar_label: 서드파티 토큰 저장소 +title: 타사 토큰 저장소 & API 접근 +sidebar_label: 타사 토큰 저장소 --- import Availability from '@components/Availability'; -서드파티 토큰 세트(일명 페더레이티드 토큰 세트)는 Logto의 [시크릿 볼트](/secret-vault)에 저장되는 시크릿 유형으로, 서드파티 아이덴티티 제공자가 발급한 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)을 안전하게 관리하는 데 사용됩니다. 사용자가 소셜 또는 엔터프라이즈 싱글 사인온 (SSO) 커넥터를 통해 인증 (Authentication)할 때, Logto는 발급된 토큰을 볼트에 저장합니다. 이 토큰들은 이후 재인증 없이 사용자를 대신해 서드파티 API에 접근하는 데 사용할 수 있습니다. +타사 토큰 세트(연합 토큰 세트라고도 함)는 Logto의 [비밀 금고](/secret-vault)에 저장되는 비밀 유형으로, 타사 아이덴티티 제공자가 발급한 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)을 안전하게 관리하는 데 사용됩니다. 사용자가 소셜 또는 엔터프라이즈 싱글 사인온 (SSO) 커넥터를 통해 인증 (Authentication)할 때, Logto는 발급된 토큰을 금고에 저장합니다. 이 토큰들은 이후 재인증 없이 사용자를 대신해 타사 API에 접근하기 위해 가져올 수 있습니다. ## 일반적인 사용 사례 \{#common-use-cases} -이 기능은 AI 에이전트, SaaS 플랫폼, 생산성 도구, 고객 애플리케이션 등 사용자를 대신해 서드파티 서비스와 상호작용해야 하는 현대 애플리케이션에 필수적입니다. 다음은 실질적인 예시입니다: +이 기능은 AI 에이전트, SaaS 플랫폼, 생산성 도구, 고객용 애플리케이션 등 사용자를 대신해 타사 서비스와 상호작용해야 하는 현대 애플리케이션에 필수적입니다. 다음은 실질적인 예시입니다: -**📅 캘린더 관리 앱**: 사용자가 Google로 로그인한 후, 생산성 앱이 사용자의 캘린더 이벤트를 자동으로 동기화하고, 새 미팅을 생성하며, 초대장을 보낼 수 있습니다. 이때 추가 인증을 요구하지 않습니다. +**📅 캘린더 관리 앱**: 사용자가 Google로 로그인한 후, 생산성 앱이 사용자의 캘린더 이벤트를 자동으로 동기화하고, 새로운 미팅을 생성하며, 초대장을 보낼 수 있습니다. 이 과정에서 추가 인증을 요구하지 않습니다. -**🤖 AI 어시스턴트**: AI 에이전트가 사용자의 GitHub 저장소에 접근하여 코드 분석, 풀 리퀘스트 생성, 이슈 관리 등을 할 수 있습니다. 이 모든 것은 로그인 또는 계정 연동 시 사용자의 1회 동의만으로 가능합니다. +**🤖 AI 어시스턴트**: AI 에이전트가 사용자의 GitHub 저장소에 접근하여 코드 분석, 풀 리퀘스트 생성, 이슈 관리 등을 할 수 있습니다. 이 모든 것은 로그인 또는 계정 연결 시 사용자의 1회 동의만으로 가능합니다. -**📊 분석 대시보드**: SaaS 플랫폼이 사용자의 연결된 소셜 미디어 계정(Facebook, LinkedIn 등)에서 데이터를 가져와 인사이트와 리포트를 생성할 수 있습니다. 반복적인 로그인 요청 없이 워크플로우를 방해하지 않습니다. +**📊 분석 대시보드**: SaaS 플랫폼이 사용자의 연결된 소셜 미디어 계정(Facebook, LinkedIn)에서 데이터를 가져와 인사이트와 리포트를 생성할 수 있습니다. 반복적인 로그인 요청 없이 워크플로우를 방해하지 않습니다. -## 서드파티 토큰 저장 활성화 \{#enable-third-party-token-storage} +## 타사 토큰 저장소 활성화 \{#enable-third-party-token-storage} ### 소셜 커넥터 \{#social-connectors} -이 기능은 토큰 저장을 지원하는 [소셜 커넥터](/connectors/social-connectors)에서 사용할 수 있습니다. 서드파티 토큰은 [소셜 로그인](/end-user-flows/sign-up-and-sign-in/social-sign-in), [소셜 계정 연동](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection), [서드파티 API 접근을 위한 토큰 갱신 시](/secret-vault/federated-token-set#reauthentication-and-token-renewal)에 저장될 수 있습니다. 현재 지원되는 커넥터는 [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [표준 OAuth 2.0](/integrations/oauth2), [표준 OIDC](/integrations/oidc)입니다. 추가 커넥터 지원은 점진적으로 제공될 예정입니다. +이 기능은 토큰 저장을 지원하는 [소셜 커넥터](/connectors/social-connectors)에서 사용할 수 있습니다. 타사 토큰은 [소셜 로그인](/end-user-flows/sign-up-and-sign-in/social-sign-in), [소셜 계정 연결](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection), [타사 API 접근을 위한 토큰 갱신 시](/secret-vault/federated-token-set#reauthentication-and-token-renewal)에 저장될 수 있습니다. 현재 지원되는 커넥터는 [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [표준 OAuth 2.0](/integrations/oauth2), [표준 OIDC](/integrations/oidc)입니다. 추가 커넥터 지원은 점진적으로 제공될 예정입니다. 1. 콘솔 > 커넥터 > 소셜 커넥터로 이동하세요. -2. 서드파티 토큰 저장을 활성화할 소셜 커넥터를 선택하세요. -3. 커넥터 설정 튜토리얼을 따라 필요한 서드파티 API 접근 스코프를 추가하세요. +2. 타사 토큰 저장을 활성화할 소셜 커넥터를 선택하세요. +3. 커넥터 설정 튜토리얼을 따라 필요한 스코프를 추가하여 특정 타사 API 접근 권한을 구성하세요. 4. "설정" 페이지에서 **지속적인 API 접근을 위한 토큰 저장** 옵션을 활성화하세요. ### 엔터프라이즈 SSO 커넥터 \{#enterprise-sso-connectors} @@ -36,111 +36,111 @@ import Availability from '@components/Availability'; 토큰 저장은 모든 OIDC [엔터프라이즈 커넥터](/connectors/enterprise-connectors)에서 사용할 수 있습니다. 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)은 [엔터프라이즈 싱글 사인온 (SSO)](/end-user-flows/enterprise-sso) 중에 저장될 수 있습니다. 현재 지원되는 커넥터는 [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc), [Okta](/integrations/okta), [OIDC (Enterprise)](/integrations/oidc-sso)입니다. 1. 콘솔 > 엔터프라이즈 SSO로 이동하세요. -2. 서드파티 토큰 저장을 활성화할 엔터프라이즈 SSO 커넥터를 선택하세요. -3. 커넥터 설정 튜토리얼을 따라 필요한 서드파티 API 접근 스코프를 추가하세요. +2. 타사 토큰 저장을 활성화할 엔터프라이즈 SSO 커넥터를 선택하세요. +3. 커넥터 설정 튜토리얼을 따라 필요한 스코프를 추가하여 특정 타사 API 접근 권한을 구성하세요. 4. "SSO 경험" 탭에서 **지속적인 API 접근을 위한 토큰 저장** 옵션을 활성화하세요. -변경 사항을 반드시 저장하세요. +변경 사항을 꼭 저장하세요. ## 토큰 저장 \{#token-storage} -서드파티 토큰 저장이 활성화되면, 사용자가 소셜 또는 엔터프라이즈 SSO 커넥터를 통해 인증 (Authentication)할 때마다 Logto가 페더레이티드 아이덴티티 제공자가 발급한 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)을 자동으로 저장합니다. 여기에는 다음이 포함됩니다: +타사 토큰 저장이 활성화되면, 사용자가 소셜 또는 엔터프라이즈 SSO 커넥터를 통해 인증 (Authentication)할 때마다 Logto가 연합 아이덴티티 제공자가 발급한 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)을 자동으로 저장합니다. 여기에는 다음이 포함됩니다: - [소셜 로그인 및 회원가입](/end-user-flows/sign-up-and-sign-in/social-sign-in) - [엔터프라이즈 SSO 로그인 및 회원가입](/end-user-flows/enterprise-sso) -- [Account API를 통한 소셜 계정 연동](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) +- [계정 API를 통한 소셜 계정 연결](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -저장된 토큰은 사용자의 소셜 또는 엔터프라이즈 SSO 아이덴티티에 연결되어, 재인증 없이 나중에 API 접근을 위해 토큰을 조회할 수 있습니다. +저장된 토큰은 사용자의 소셜 또는 엔터프라이즈 SSO 아이덴티티에 연결되어, 재인증 없이 나중에 API 접근을 위해 토큰을 가져올 수 있습니다. ### 토큰 저장 상태 확인 \{#checking-token-storage-status} -Logto 콘솔에서 사용자의 서드파티 토큰 저장 상태를 확인할 수 있습니다: +Logto 콘솔에서 사용자의 타사 토큰 저장 상태를 확인할 수 있습니다: 1. 콘솔 > 사용자로 이동하세요. 2. 확인하려는 사용자를 클릭하세요. 사용자의 상세 페이지로 이동합니다. -3. **연결** 섹션까지 스크롤하세요. 이 영역에는 사용자와 연결된 모든 소셜 및 엔터프라이즈 SSO 연결이 나열됩니다. -4. 각 연결 항목에는 해당 연결에 대해 토큰이 저장되어 있는지 나타내는 토큰 상태 레이블이 표시됩니다. -5. 연결 항목을 클릭하면 저장된 액세스 토큰 (Access token) 메타데이터와 리프레시 토큰 (Refresh token) 사용 가능 여부(해당 시)를 포함한 자세한 정보를 볼 수 있습니다. +3. **연결** 섹션으로 스크롤하세요. 이 영역에는 사용자와 연결된 모든 소셜 및 엔터프라이즈 SSO 연결이 나열됩니다. +4. 각 연결 항목에는 해당 연결에 토큰이 저장되어 있는지 나타내는 토큰 상태 레이블이 표시됩니다. +5. 연결 항목을 클릭하면 저장된 액세스 토큰 (Access token) 메타데이터와 리프레시 토큰 (Refresh token) 사용 가능 여부(가능한 경우)를 포함한 자세한 정보를 볼 수 있습니다. -또한 관리 API를 통해 사용자 서드파티 아이덴티티 및 토큰 저장 상태를 확인할 수 있습니다: +또한 관리 API를 통해 사용자 타사 아이덴티티 및 토큰 저장 상태를 확인할 수 있습니다: - `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`: 지정한 커넥터 타겟(예: `github`, `google` 등)으로 연결된 사용자의 소셜 아이덴티티 및 토큰 저장 상태를 조회합니다. - `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`: 지정한 SSO 커넥터 ID로 연결된 사용자의 엔터프라이즈 SSO 아이덴티티 및 토큰 저장 상태를 조회합니다. ### 토큰 저장 상태 \{#token-storage-status} -- **Active(활성)**: 액세스 토큰 (Access token)이 저장되어 있고 활성 상태입니다. -- **Expired(만료됨)**: 액세스 토큰 (Access token)이 저장되어 있지만 만료되었습니다. 리프레시 토큰 (Refresh token)이 있으면 새 액세스 토큰을 얻을 수 있습니다. -- **Inactive(비활성)**: 이 연결에 대해 저장된 액세스 토큰 (Access token)이 없습니다. 사용자가 이 연결을 통해 인증하지 않았거나 토큰 저장이 삭제된 경우 발생할 수 있습니다. -- **Not applicable(해당 없음)**: 해당 커넥터가 토큰 저장을 지원하지 않습니다. +- **활성**: 액세스 토큰 (Access token)이 저장되어 있고 활성 상태입니다. +- **만료됨**: 액세스 토큰 (Access token)이 저장되어 있지만 만료되었습니다. 리프레시 토큰 (Refresh token)이 있으면 새 액세스 토큰을 받을 수 있습니다. +- **비활성**: 이 연결에 저장된 액세스 토큰 (Access token)이 없습니다. 사용자가 이 연결을 통해 인증하지 않았거나 토큰 저장이 삭제된 경우 발생할 수 있습니다. +- **해당 없음**: 커넥터가 토큰 저장을 지원하지 않습니다. ### 토큰 메타데이터 \{#token-metadata} -데이터 무결성과 보안을 위해 모든 토큰은 시크릿 볼트에 저장되기 전에 암호화됩니다. 실제 토큰 값은 적절한 인가 (Authorization)를 받은 최종 사용자만 접근할 수 있습니다. 반면, 개발자는 민감한 내용을 노출하지 않고 저장된 토큰의 상태를 파악할 수 있도록 토큰 세트 메타데이터만 조회할 수 있습니다. +데이터 무결성과 보안을 위해 모든 토큰은 비밀 금고에 저장되기 전에 암호화됩니다. 실제 토큰 값은 적절한 인가 (Authorization)를 받은 최종 사용자만 접근할 수 있습니다. 개발자는 민감한 내용을 노출하지 않고 저장된 토큰의 상태를 파악하기 위해 토큰 세트 메타데이터만 조회할 수 있습니다. -- `createdAt`: 연결이 처음 생성되고 토큰 세트가 시크릿 볼트에 최초 저장된 시각입니다. +- `createdAt`: 연결이 처음 생성되고 토큰 세트가 비밀 금고에 최초로 저장된 시각입니다. - `updatedAt`: 토큰 세트가 마지막으로 업데이트된 시각입니다. - 리프레시 토큰 (Refresh token)이 없으면 이 값은 **createdAt**과 동일합니다. - - 리프레시 토큰 (Refresh token)이 있으면, 이 값은 액세스 토큰 (Access token)이 가장 최근에 갱신된 시각을 나타냅니다. + - 리프레시 토큰 (Refresh token)이 있으면, 이 값은 액세스 토큰 (Access token)이 가장 최근에 갱신된 시각을 반영합니다. - `hasRefreshToken`: 리프레시 토큰 (Refresh token) 사용 가능 여부를 나타냅니다. - 커넥터가 오프라인 접근을 지원하고 인가 요청이 올바르게 구성된 경우, Logto는 아이덴티티 제공자가 액세스 토큰 (Access token)과 함께 발급한 리프레시 토큰 (Refresh token)도 저장합니다. - 액세스 토큰 (Access token)이 만료되고 유효한 리프레시 토큰 (Refresh token)이 존재하면, 사용자가 연결된 제공자에 접근할 때마다 Logto가 저장된 리프레시 토큰 (Refresh token)으로 새 액세스 토큰 (Access token) 발급을 자동 시도합니다. + 커넥터가 오프라인 접근을 지원하고 인가 요청이 적절히 구성된 경우, Logto는 아이덴티티 제공자가 액세스 토큰 (Access token)과 함께 발급한 리프레시 토큰 (Refresh token)도 저장합니다. + 액세스 토큰 (Access token)이 만료되고 유효한 리프레시 토큰 (Refresh token)이 존재하면, 사용자가 연결된 제공자에 접근할 때 Logto가 자동으로 저장된 리프레시 토큰 (Refresh token)으로 새 액세스 토큰 (Access token)을 받으려고 시도합니다. - `expiresAt`: 액세스 토큰 (Access token)의 예상 만료 시각(초 단위)입니다. 이는 아이덴티티 제공자의 토큰 엔드포인트에서 반환된 `expires_in` 값을 기반으로 계산됩니다. (이 필드는 제공자가 토큰 응답에 `expires_in`을 포함할 때만 제공됩니다.) -- `scope`: 액세스 토큰 (Access token)의 스코프로, 아이덴티티 제공자가 부여한 권한 (Permission)을 나타냅니다. +- `scope`: 액세스 토큰 (Access token)의 스코프로, 아이덴티티 제공자가 부여한 권한을 나타냅니다. 저장된 액세스 토큰 (Access token)으로 어떤 작업이 가능한지 이해하는 데 유용합니다. (이 필드는 제공자가 토큰 응답에 `scope`를 포함할 때만 제공됩니다.) - `tokenType`: 액세스 토큰 (Access token)의 유형으로, 일반적으로 "Bearer"입니다. (이 필드는 제공자가 토큰 응답에 `token_type`을 포함할 때만 제공됩니다.) -## 토큰 조회 \{#token-retrieval} +## 토큰 가져오기 \{#token-retrieval} -토큰 저장이 활성화되고 토큰이 Logto의 시크릿 볼트에 안전하게 저장되면, 최종 사용자는 Logto의 [Account API](/end-user-flows/account-settings/by-account-api)를 연동하여 클라이언트 애플리케이션에서 자신의 서드파티 액세스 토큰 (Access token)을 조회할 수 있습니다. +토큰 저장이 활성화되고 토큰이 Logto의 비밀 금고에 안전하게 저장되면, 최종 사용자는 Logto의 [사용자 계정 API](/end-user-flows/account-settings/by-account-api)를 통합하여 클라이언트 애플리케이션에서 자신의 타사 액세스 토큰 (Access token)을 가져올 수 있습니다. -- `GET /my-account/identities/:target/access-token`: 커넥터 타겟(예: github, google 등)을 지정하여 소셜 아이덴티티의 액세스 토큰 (Access token)을 조회합니다. +- `GET /my-account/identities/:target/access-token`: 커넥터 타겟(예: github, google)을 지정하여 소셜 아이덴티티의 액세스 토큰 (Access token)을 가져옵니다. -- `GET /my-account/sso-identities/:connectorId/access-token`: 커넥터 ID를 지정하여 엔터프라이즈 SSO 아이덴티티의 액세스 토큰 (Access token)을 조회합니다. +- `GET /my-account/sso-identities/:connectorId/access-token`: 커넥터 ID를 지정하여 엔터프라이즈 SSO 아이덴티티의 액세스 토큰 (Access token)을 가져옵니다. :::info -Logto에서 발급한 액세스 토큰 (Access token)으로 Account API를 [활성화](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api)하고 [접근](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token)하는 방법을 알아보세요. +타사 액세스 토큰 (Access token)을 가져오려면, 먼저 콘솔 > 로그인 & 계정 > 계정 센터에서 최종 사용자를 위한 Account API를 활성화해야 합니다. [Account API 활성화 방법](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) 및 [Logto에서 발급한 액세스 토큰 (Access token)으로 접근하는 방법](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token)을 참고하세요. ::: ### 토큰 회전 \{#token-rotation} -토큰 조회 엔드포인트는 다음과 같이 응답합니다: +토큰 가져오기 엔드포인트는 다음을 반환합니다: - `200` OK: 액세스 토큰 (Access token)이 성공적으로 조회되었고 아직 유효한 경우. - `404` Not Found: 사용자가 지정한 타겟 또는 커넥터 ID와 연결된 소셜 또는 엔터프라이즈 SSO 아이덴티티가 없거나, 액세스 토큰 (Access token)이 저장되어 있지 않은 경우. - `401` Unauthorized: 액세스 토큰 (Access token)이 만료된 경우. -액세스 토큰 (Access token)이 만료되었고 리프레시 토큰 (Refresh token)이 있으면, Logto가 자동으로 액세스 토큰 (Access token)을 갱신하여 새 액세스 토큰 (Access token)을 응답에 반환합니다. 시크릿 볼트의 토큰 저장소도 새 액세스 토큰 (Access token)과 메타데이터로 업데이트됩니다. +액세스 토큰 (Access token)이 만료되었고 리프레시 토큰 (Refresh token)이 있으면, Logto가 자동으로 액세스 토큰 (Access token)을 갱신하여 응답에 새 액세스 토큰 (Access token)을 반환합니다. 비밀 금고의 토큰 저장소도 새 액세스 토큰 (Access token)과 메타데이터로 업데이트됩니다. ## 토큰 저장소 삭제 \{#token-storage-deletion} -서드파티 토큰 저장은 각 사용자의 소셜 또는 엔터프라이즈 SSO 연결과 직접적으로 연동됩니다. 즉, 다음과 같은 경우 저장된 토큰 세트가 자동으로 삭제됩니다: +타사 토큰 저장소는 각 사용자의 소셜 또는 엔터프라이즈 SSO 연결과 직접적으로 연결되어 있습니다. 즉, 다음과 같은 경우 저장된 토큰 세트가 자동으로 삭제됩니다: -- 연결된 소셜 또는 엔터프라이즈 SSO 아이덴티티가 사용자 계정에서 제거된 경우 -- 사용자 계정이 테넌트에서 삭제된 경우 -- 소셜 또는 엔터프라이즈 SSO 커넥터가 테넌트에서 삭제된 경우 +- 연결된 소셜 또는 엔터프라이즈 SSO 아이덴티티가 사용자의 계정에서 제거된 경우. +- 사용자 계정이 테넌트에서 삭제된 경우. +- 소셜 또는 엔터프라이즈 SSO 커넥터가 테넌트에서 삭제된 경우. ### 토큰 폐기 \{#revoking-tokens} -사용자의 서드파티 토큰 세트를 수동으로 삭제하여 접근을 폐기할 수도 있습니다: +사용자의 타사 토큰 세트를 수동으로 삭제하여 접근을 폐기할 수도 있습니다: - 콘솔에서: - 사용자의 아이덴티티 상세 페이지로 이동하세요. **액세스 토큰 (Access token)** 섹션(토큰 저장이 가능한 경우)까지 스크롤한 후, 해당 섹션 끝의 **토큰 삭제** 버튼을 클릭하세요. + 사용자의 아이덴티티 상세 페이지로 이동하세요. **액세스 토큰 (Access token)** 섹션(토큰 저장이 가능한 경우)으로 스크롤하여, 섹션 끝의 **토큰 삭제** 버튼을 클릭하세요. - 관리 API를 통해: - - `DELETE /api/secret/:id`: 사용자 아이덴티티 상세 정보에서 얻을 수 있는 시크릿 ID로 특정 시크릿을 삭제합니다. + - `DELETE /api/secret/:id`: 사용자 아이덴티티 상세 정보에서 얻을 수 있는 ID로 특정 비밀을 삭제합니다. -토큰 세트를 폐기하면 사용자는 서드파티 API에 다시 접근하기 전에 서드파티 제공자와 재인증해야 새 액세스 토큰 (Access token)을 받을 수 있습니다. +토큰 세트를 폐기하면 사용자는 타사 API에 다시 접근하기 전에 타사 제공자와 재인증해야 새 액세스 토큰 (Access token)을 받을 수 있습니다. ## 재인증 및 토큰 갱신 \{#reauthentication-and-token-renewal} -저장된 액세스 토큰 (Access token)이 만료되었거나 애플리케이션이 추가 API 스코프를 요청해야 하는 경우, 최종 사용자는 서드파티 제공자와 재인증하여 새로운 액세스 토큰 (Access token)을 받을 수 있습니다. 이때 Logto에 다시 로그인할 필요는 없습니다. -이는 Logto의 [Social Verification API](https://openapi.logto.io/operation/operation-createverificationbysocial)를 통해 가능하며, 사용자가 페더레이티드 소셜 인가 플로우를 재시작하고 저장된 토큰 세트를 업데이트할 수 있습니다. +저장된 액세스 토큰 (Access token)이 만료되었거나 애플리케이션이 추가 API 스코프를 요청해야 하는 상황에서는, 최종 사용자가 타사 제공자와 재인증하여 새로운 액세스 토큰 (Access token)을 받을 수 있습니다. 이때 Logto에 다시 로그인할 필요는 없습니다. +이는 Logto의 [소셜 인증 API](https://openapi.logto.io/operation/operation-createverificationbysocial)를 통해 가능합니다. 사용자는 연합 소셜 인가 플로우를 재시작하고 저장된 토큰 세트를 업데이트할 수 있습니다. :::note -페더레이티드 인가 재시작은 현재 소셜 커넥터에 한정되어 있습니다. -엔터프라이즈 SSO 커넥터의 경우, 재인증 및 토큰 갱신을 위해 사용자가 Logto 인증 (Authentication) 플로우 전체를 다시 시작해야 하며, 로그인 이후 엔터프라이즈 SSO 제공자와의 직접 재인가 (Authorization)는 현재 지원되지 않습니다. +연합 인가 재시작은 현재 소셜 커넥터에만 제한됩니다. +엔터프라이즈 SSO 커넥터의 경우, 재인증 및 토큰 갱신을 위해 사용자가 Logto 인증 (Authentication) 플로우 전체를 다시 시작해야 하며, 로그인 이후 엔터프라이즈 SSO 제공자와의 직접 재인가(reauthorization)는 현재 지원되지 않습니다. ::: ```mermaid @@ -149,10 +149,10 @@ sequenceDiagram participant User as 사용자 participant Logto as Logto - participant Provider as 서드파티 제공자 + participant Provider as 타사 제공자 User->>Logto: post /api/verification/social - Logto->>User: 서드파티 제공자로 리디렉션 + Logto->>User: 타사 제공자로 리디렉션 User->>Provider: 인증 및 인가 Provider->>User: 인가 코드와 함께 리디렉션 User->>Logto: post /api/verification/social/verify (인가 코드 포함) @@ -160,7 +160,7 @@ sequenceDiagram User->>Logto: patch /my-account/identities/:target/access-token ``` -1. 사용자가 `POST /api/verification/social` 엔드포인트를 호출하여 소셜 인증 요청을 시작합니다. 이때 서드파티 제공자로부터 추가 권한 (Permission)을 요청하기 위해 커스텀 스코프를 지정할 수 있습니다. +1. 사용자가 `POST /api/verification/social` 엔드포인트를 호출하여 소셜 인증 요청을 시작합니다. 사용자는 타사 제공자로부터 추가 권한을 요청하기 위해 커스텀 스코프를 지정할 수 있습니다. ```sh curl -X POST https:///api/verification/social \ @@ -174,12 +174,12 @@ sequenceDiagram }' ``` - - **authorization header**: Logto에서 발급한 사용자의 액세스 토큰 (Access token) - - **connectorId**: Logto의 소셜 커넥터 ID - - **redirectUri**: 인증 후 사용자를 애플리케이션으로 리디렉션할 URI. 이 URI는 제공자 애플리케이션 설정에 등록해야 합니다. - - **scope**: (선택 사항) 서드파티 제공자로부터 추가 권한 (Permission)을 요청할 커스텀 스코프. 지정하지 않으면 커넥터에 설정된 기본 스코프가 사용됩니다. + - **authorization header**: Logto에서 발급한 사용자의 액세스 토큰 (Access token). + - **connectorId**: Logto의 소셜 커넥터 ID. + - **redirectUri**: 인증 후 사용자를 애플리케이션으로 다시 리디렉션할 URI. 이 URI는 제공자의 애플리케이션 설정에 등록해야 합니다. + - **scope**: (선택 사항) 타사 제공자로부터 추가 권한을 요청할 커스텀 스코프. 지정하지 않으면 커넥터에 구성된 기본 스코프가 사용됩니다. -2. Logto가 새로운 소셜 인증 레코드를 생성하고, 사용자를 서드파티 제공자 인증을 위한 인가 URL과 함께 소셜 인증 ID를 반환합니다. +2. Logto가 새로운 소셜 인증 레코드를 생성하고, 인증을 위해 사용자를 타사 제공자로 리디렉션할 인가 URL과 함께 소셜 인증 ID를 반환합니다. 응답 예시는 다음과 같습니다: @@ -191,9 +191,9 @@ sequenceDiagram } ``` -3. 사용자를 인가 URL로 리디렉션하세요. 사용자는 서드파티 제공자와 인증 및 권한 (Permission) 부여를 진행합니다. +3. 사용자를 인가 URL로 리디렉션하세요. 사용자는 타사 제공자와 인증하고 권한을 부여합니다. -4. 서드파티 제공자가 인가 코드를 포함하여 사용자를 클라이언트 애플리케이션으로 리디렉션합니다. +4. 타사 제공자가 인가 코드를 포함하여 사용자를 클라이언트 애플리케이션으로 다시 리디렉션합니다. 5. 인가 콜백을 처리하여 인가 코드를 Logto의 인증 엔드포인트로 전달하세요: @@ -210,15 +210,15 @@ sequenceDiagram }' ``` - - **authorization header**: Logto에서 발급한 사용자의 액세스 토큰 (Access token) - - **verificationRecordId**: 이전 단계에서 반환된 소셜 인증 ID - - **connectorData**: 콜백 시 서드파티 제공자가 반환한 인가 코드 및 기타 데이터 + - **authorization header**: Logto에서 발급한 사용자의 액세스 토큰 (Access token). + - **verificationRecordId**: 이전 단계에서 반환된 소셜 인증 ID. + - **connectorData**: 인가 코드 및 콜백 시 타사 제공자가 반환한 기타 데이터. :::note CSRF 공격을 방지하기 위해 반드시 `state` 파라미터를 검증하세요. ::: -6. Logto가 인가 코드를 검증하고, 서드파티 제공자로부터 새 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)을 교환한 뒤, 응답에 소셜 인증 ID를 반환합니다. +6. Logto가 인가 코드를 검증하고, 타사 제공자로부터 새 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)을 교환한 뒤, 응답에 소셜 인증 ID를 반환합니다. 7. 마지막으로, `PATCH /my-account/identities/:target/access-token` 엔드포인트에 소셜 인증 ID를 전달하여 사용자의 토큰 저장소를 업데이트하세요: @@ -231,9 +231,9 @@ sequenceDiagram }' ``` - - **authorization header**: Logto에서 발급한 사용자의 액세스 토큰 (Access token) - - **socialVerificationId**: 이전 단계에서 반환된 소셜 인증 레코드 ID + - **authorization header**: Logto에서 발급한 사용자의 액세스 토큰 (Access token). + - **socialVerificationId**: 이전 단계에서 반환된 소셜 인증 레코드 ID. - 이 과정을 통해 Logto의 시크릿 볼트에 저장된 사용자의 토큰 세트가 새 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)으로 갱신되어, 사용자는 Logto에 다시 로그인하지 않고도 서드파티 API에 접근할 수 있습니다. + 이 과정을 통해 Logto의 비밀 금고에 저장된 사용자의 토큰 세트가 새 액세스 토큰 (Access token)과 리프레시 토큰 (Refresh token)으로 업데이트되어, 사용자는 Logto에 다시 로그인하지 않고도 타사 API에 접근할 수 있습니다. - 갱신된 액세스 토큰 (Access token)이 반환됩니다. + 업데이트된 액세스 토큰 (Access token)이 반환됩니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/ko/docusaurus-plugin-content-docs/current/security/blocklist.md index 3641995df25..5cc8e426fcc 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/ko/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -4,37 +4,37 @@ sidebar_label: 차단 목록 sidebar_position: 3 --- -# 차단 목록 (Blocklist) +# 차단 목록 -## 이메일 차단 목록 (Email blocklist) {#email-blocklist} +## 이메일 차단 목록 {#email-blocklist} -이메일 차단 목록 정책을 통해 계정 가입 남용을 방지하기 위한 이메일 차단 목록 설정을 사용자 지정할 수 있습니다. 이 정책은 가입 및 계정 설정에 사용되는 이메일 주소를 모니터링합니다. 사용자가 차단 목록 규칙을 위반하는 이메일 주소로 가입하거나 연결을 시도할 경우, 시스템은 해당 요청을 거부하여 스팸 계정을 줄이고 전체 계정 보안을 강화합니다. +이메일 차단 목록 정책을 통해 계정 가입 남용을 방지하기 위한 이메일 차단 목록 설정을 사용자 지정할 수 있습니다. 이 정책은 가입 및 계정 설정에 사용되는 이메일 주소를 모니터링합니다. 사용자가 차단 목록 규칙을 위반하는 이메일 주소로 가입하거나 이메일을 연결하려고 시도하면, 시스템은 해당 요청을 거부하여 스팸 계정을 줄이고 전체 계정 보안을 강화합니다. -이메일 차단 목록 설정을 구성하려면 콘솔 > 보안 > 차단 목록로 이동하세요. +이메일 차단 목록 설정을 구성하려면 콘솔 > 보안 > 차단 목록을 방문하세요. -### 일회용 이메일 주소 차단 (Block disposable email addresses) {#block-disposable-email-addresses} +### 일회용 이메일 주소 차단 {#block-disposable-email-addresses} 이 기능은 **클라우드 전용** 기능입니다. 활성화하면, 시스템은 제공된 이메일 주소의 도메인을 알려진 일회용 이메일 도메인 목록과 자동으로 대조합니다. 도메인이 목록에 있으면 요청이 거부됩니다. 일회용 이메일 도메인 목록은 효과를 유지하기 위해 정기적으로 업데이트됩니다. -### 이메일 서브어드레싱 차단 (Block email subaddressing) {#block-email-subaddressing} +### 이메일 서브어드레싱 차단 {#block-email-subaddressing} -이메일 서브어드레싱은 사용자가 플러스 기호(+)와 추가 문자를 사용하여 이메일 주소의 변형을 만들 수 있게 해줍니다 (예: user+tag@example.com). 이 기능은 악의적인 사용자가 차단 목록 제한을 우회하는 데 악용될 수 있습니다. 이메일 서브어드레싱 차단 기능을 활성화하면, 시스템은 서브어드레싱 이메일 형식을 사용하는 가입 또는 계정 연결 시도를 거부합니다. +이메일 서브어드레싱은 사용자가 플러스 기호(+)와 추가 문자를 사용하여 이메일 주소의 변형을 만들 수 있게 해줍니다 (예: user+tag@example.com). 이 기능은 악의적인 사용자가 차단 목록 제한을 우회하는 데 악용될 수 있습니다. 이메일 서브어드레싱 차단 기능을 활성화하면, 시스템은 서브어드레싱 이메일 형식을 사용하는 가입 또는 계정 연결 시도를 모두 거부합니다. -### 사용자 지정 이메일 차단 목록 (Custom email blocklist) {#custom-email-blocklist} +### 사용자 지정 이메일 차단 목록 {#custom-email-blocklist} -차단할 이메일 주소 또는 도메인 목록을 지정하여 사용자 지정 이메일 차단 목록을 만들 수 있습니다. 시스템은 이 항목들과 일치하는 가입 또는 계정 연결 시도를 거부합니다. 차단 목록은 전체 이메일 주소와 도메인 모두에 대해 일치시킵니다. +차단할 이메일 주소 또는 도메인 목록을 지정하여 사용자 지정 이메일 차단 목록을 만들 수 있습니다. 시스템은 이 항목과 일치하는 가입 또는 계정 연결 시도를 모두 거부합니다. 차단 목록은 전체 이메일 주소와 도메인 모두에 대한 일치를 지원합니다. -예를 들어, `@example.com`을 차단 목록에 추가하면 해당 도메인을 가진 모든 이메일 주소가 차단됩니다. 마찬가지로, `foo@example.com`을 추가하면 해당 이메일 주소만 차단됩니다. +예를 들어, 차단 목록에 `@example.com`을 추가하면 해당 도메인을 가진 모든 이메일 주소가 차단됩니다. 마찬가지로, `foo@example.com`을 추가하면 해당 이메일 주소만 차단됩니다. :::note -일회용 이메일, 서브어드레싱, 사용자 지정 이메일은 등록 및 계정 연결 시 제한됩니다. 이러한 이메일 주소를 가진 기존 사용자는 계속 로그인할 수 있습니다. +일회용 이메일, 서브어드레싱, 사용자 지정 이메일은 [신규 사용자 등록](/end-user-flows/sign-up-and-sign-in/sign-up), [소셜 로그인 시 이메일 연결](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers), [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email)를 통한 이메일 업데이트 시 제한됩니다. 해당 이메일 주소를 가진 기존 사용자는 계속 로그인할 수 있습니다. -- 관리자는 콘솔 > 사용자 관리에서 사용자를 수동으로 추가하거나, [Management API](https://openapi.logto.io/operation/operation-createuser)를 통해 "제한 우회"가 가능합니다. 예: 서브어드레싱이 차단된 경우에도 서브어드레싱 이메일로 사용자를 생성할 수 있습니다. -- 기존 계정을 차단하려면 콘솔 > 사용자 관리에서 계정을 삭제하거나 일시 중단하세요. +- 관리자는 콘솔 > 사용자 관리에서 사용자를 수동으로 추가하거나, [Management API](https://openapi.logto.io/operation/operation-createuser)를 통해 "제한 우회"가 가능합니다. 예: 서브어드레싱이 차단된 상태에서 서브어드레싱 이메일로 사용자를 생성. +- 기존 계정을 차단하려면 콘솔 > 사용자 관리에서 계정을 삭제하거나 일시 중지하세요. ::: ## 관련 리소스 {#related-resources} -일회용 이메일이란 무엇이며, 앱에서 어떻게 처리해야 할까요? +일회용 이메일이란? 앱에서 어떻게 처리해야 할까요? diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/security/password-policy.mdx index 4e8da0cce6b..ae55fbfac1e 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -1,32 +1,41 @@ --- slug: /security/password-policy -sidebar_label: 비밀번호 정책 (Password Policy) +sidebar_label: 비밀번호 정책 sidebar_position: 1 --- -# 비밀번호 정책 (Password Policy) +# 비밀번호 정책 + +Logto는 비밀번호가 생성되거나 업데이트되는 방식에 따라 비밀번호 정책을 다르게 적용합니다: + +- [기본 제공 로그인 경험](/end-user-flows/sign-up-and-sign-in/sign-up), [Experience API](/customization/bring-your-ui), [Account API](/end-user-flows/account-settings/by-account-api#update-users-password)와 같은 엔드유저 플로우에서는 항상 현재 [비밀번호 정책](#set-up-password-policy)이 적용됩니다. +- Management API를 통한 관리자 작업 [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword)에는 정책이 적용되지 않아, 필요할 때 정책 검사 없이 자격 증명을 프로비저닝하거나 재설정할 수 있습니다. +- 기존 비밀번호가 현재 규칙을 준수하는지 감사하려면 [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience)를 호출하고 반환된 검증 결과에 따라 조치하세요. 자세한 내용은 [비밀번호 준수 검사](#password-compliance-check)를 참고하세요. ## 비밀번호 정책 설정하기 \{#set-up-password-policy} -신규 사용자 또는 비밀번호를 변경하는 사용자의 경우, 비밀번호 강도 요건을 적용하기 위해 비밀번호 정책을 설정할 수 있습니다. 콘솔 > 보안 > 비밀번호 정책에서 비밀번호 정책 설정을 구성하세요. +신규 사용자 또는 비밀번호를 변경하는 사용자를 위해, 비밀번호 강도 요구 사항을 적용하는 비밀번호 정책을 설정할 수 있습니다. 콘솔 > 보안 > 비밀번호 정책에서 비밀번호 정책을 설정하세요. 1. **최소 비밀번호 길이**: 비밀번호에 필요한 최소 문자 수를 설정합니다. (NIST는 최소 8 [문자](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)를 권장합니다) -2. **필수 문자 유형 최소 개수**: 비밀번호에 필요한 문자 유형의 최소 개수를 설정합니다. 사용 가능한 문자 유형은 다음과 같습니다: +2. **최소 요구 문자 유형 수**: 비밀번호에 필요한 최소 문자 유형 수를 설정합니다. 사용 가능한 문자 유형은 다음과 같습니다: 1. 대문자: `(A-Z)` 2. 소문자: `(a-z)` 3. 숫자: `(0-9)` 4. 특수 문자: ``(!"#$%&'()\*+,-./:;<>=?@[]^\_`|{}~ )`` -3. **유출 이력 확인**: 이 설정을 활성화하면 데이터 유출에서 이미 노출된 비밀번호를 거부합니다. ([Have I Been Pwned](https://haveibeenpwned.com/Passwords) 기반) -4. **반복 문자 확인**: 이 설정을 활성화하면 반복되는 문자가 포함된 비밀번호를 거부합니다. (예: "11111111" 또는 "password123") -5. **사용자 정보 확인**: 이 설정을 활성화하면 사용자 이름, 이메일 주소, 전화번호 등 사용자 정보가 포함된 비밀번호를 거부합니다. +3. **유출 이력 검사**: 이 설정을 활성화하면 데이터 유출에 노출된 적이 있는 비밀번호를 거부합니다. ([Have I Been Pwned](https://haveibeenpwned.com/Passwords) 기반) +4. **반복 문자 검사**: 이 설정을 활성화하면 반복되는 문자가 포함된 비밀번호를 거부합니다. (예: "11111111" 또는 "password123") +5. **사용자 정보 포함 검사**: 이 설정을 활성화하면 사용자 이름, 이메일 주소, 전화번호 등 사용자 정보가 포함된 비밀번호를 거부합니다. 6. **사용자 지정 단어**: 비밀번호에 포함되면 거부할 사용자 지정 단어 목록(대소문자 구분 없음)을 입력하세요. -## 비밀번호 정책 준수 확인 \{#password-compliance-check} +## 비밀번호 준수 검사 \{#password-compliance-check} Logto에서 비밀번호 정책을 업데이트한 후에도 기존 사용자는 현재 비밀번호로 계속 로그인할 수 있습니다. 새로 생성된 계정만 업데이트된 정책을 따라야 합니다. -더 강력한 보안을 적용하려면, `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience)를 사용하여 사용자의 비밀번호가 기본 로그인 경험에 정의된 현재 정책을 충족하는지 확인할 수 있습니다. 충족하지 않는 경우, [Account API](/end-user-flows/account-settings/by-management-api#user-password-management)를 사용하여 사용자에게 비밀번호를 업데이트하도록 커스텀 플로우로 안내할 수 있습니다. +더 강력한 보안을 적용하려면, `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience)를 사용하여 사용자의 비밀번호가 기본 로그인 경험에 정의된 현재 정책을 충족하는지 확인할 수 있습니다. 충족하지 않는 경우, [Account API](/end-user-flows/account-settings/by-account-api)를 사용하여 사용자에게 비밀번호 업데이트를 요청하는 커스텀 플로우를 안내할 수 있습니다. ## 관련 리소스 \{#related-resources} +사용자 관리 +회원가입 및 로그인 +Account API로 계정 설정 비밀번호 정책 설계하기 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index dec96ac7cd1..2c3cfc8f589 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -8,59 +8,65 @@ sidebar_position: 2 ### 사용자 탐색 및 검색 \{#browse-and-search-users} -Logto Console에서 사용자 관리 기능에 접근하려면 Console > 사용자 관리로 이동하세요. -이동하면 모든 사용자를 표 형식으로 볼 수 있습니다. +Logto Console에서 사용자 관리 기능에 접근하려면 Console > 사용자 관리로 이동하세요. 이곳에서 모든 사용자의 테이블 뷰를 볼 수 있습니다. -표는 세 개의 열로 구성되어 있습니다: +테이블은 세 개의 열로 구성되어 있습니다: - **사용자**: 아바타, 전체 이름, 사용자명, 전화번호, 이메일 등 사용자의 정보를 표시합니다. - **애플리케이션에서 등록**: 사용자가 최초로 등록한 애플리케이션의 이름을 표시합니다. - **최신 로그인**: 사용자의 가장 최근 로그인 시각을 표시합니다. -이 표는 [`name`](/user-management/user-data#name), [`id`](/user-management/user-data#id), [`username`](/user-management/user-data#username), [`primary-phone`](/user-management/user-data#primary_phone), [`primary-email`](/user-management/user-data#primary_email) 키워드 매핑을 지원합니다. +이 테이블은 [`name`](/user-management/user-data#name), [`id`](/user-management/user-data#id), [`username`](/user-management/user-data#username), [`primary-phone`](/user-management/user-data#primary_phone), [`primary-email`](/user-management/user-data#primary_email)에 대한 키워드 매핑을 지원합니다. ### 사용자 추가 \{#add-users} Console을 사용하여 개발자는 최종 사용자를 위한 새 계정을 생성할 수 있습니다. 화면 오른쪽 상단의 "사용자 추가" 버튼을 클릭하세요. -Logto Console 또는 Management API(엔드 유저가 UI를 통해 직접 가입하는 경우가 아님)로 사용자를 생성할 때는 최소 하나의 식별자(`primary email`, `primary phone`, `username`)를 반드시 입력해야 합니다. `name` 필드는 선택 사항입니다. +Logto Console 또는 Management API(엔드 유저가 UI를 통해 직접 등록하는 경우가 아님)를 통해 사용자를 생성할 때, 최소한 하나의 식별자: `primary email`, `primary phone`, 또는 `username`을 제공해야 합니다. `name` 필드는 선택 사항입니다. -사용자가 생성되면 Logto는 자동으로 임의의 비밀번호를 생성합니다. 초기 비밀번호는 한 번만 표시되지만, 나중에 [비밀번호를 재설정](./manage-users#reset-user-password)할 수 있습니다. 특정 비밀번호를 설정하려면, 사용자가 생성된 후 Management API의 `patch /api/users/{userId}/password`를 사용하여 업데이트하세요. +사용자가 생성되면 Logto는 자동으로 임의의 비밀번호를 생성합니다. 초기 비밀번호는 한 번만 표시되지만, 나중에 [비밀번호 재설정](./manage-users#reset-user-password)이 가능합니다. 특정 비밀번호를 설정하려면, 사용자가 생성된 후 Management API의 `patch /api/users/{userId}/password`를 사용하여 업데이트하세요. **입력한 식별자(이메일 주소 / 전화번호 / 사용자명)**와 **초기 비밀번호**를 한 번에 복사할 수 있어, 새 사용자에게 이 정보를 쉽게 전달하여 바로 로그인할 수 있습니다. :::tip -초대 전용 가입을 구현하고 싶다면, [매직 링크로 사용자 초대](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended)를 권장합니다. 이를 통해 화이트리스트에 등록된 사용자만 직접 가입하고 비밀번호를 설정할 수 있습니다. +초대 전용 등록을 구현하려면, [매직 링크로 사용자 초대](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended)를 권장합니다. 이를 통해 화이트리스트에 등록된 사용자만 직접 등록하고 비밀번호를 설정할 수 있습니다. ::: -### 사용자 프로필 보기 및 수정 \{#view-and-update-the-user-profile} +### 사용자 프로필 보기 및 업데이트 \{#view-and-update-the-user-profile} -사용자 세부 정보를 보려면 사용자 표에서 해당 행을 클릭하세요. "**사용자 세부 정보**" 페이지로 이동하며, 여기서 사용자의 프로필 정보를 확인할 수 있습니다. 포함 내용: +사용자 세부 정보를 보려면, 사용자 테이블에서 해당 행을 클릭하세요. "**사용자 세부 정보**" 페이지로 이동하여 다음과 같은 프로필 정보를 확인할 수 있습니다: - **인증 관련 데이터**: - **이메일 주소** ([primary_email](/user-management/user-data#primary_email)): 수정 가능 - **전화번호** ([primary_phone](/user-management/user-data#primary_phone)): 수정 가능 - **사용자명** ([username](/user-management/user-data#username)): 수정 가능 - **비밀번호** ([has_password](/user-management/user-data#has_password)): 임의의 비밀번호를 재생성할 수 있습니다. "[사용자 비밀번호 재설정](#reset-user-password)" 참고. - - **소셜 연결** ([identities](/user-management/user-data#social-identities)): 연결된 소셜 계정 및 소셜 ID를 확인할 수 있습니다. 예를 들어, 사용자가 Facebook 계정으로 로그인한 경우 목록에 "Facebook" 항목이 표시됩니다. Console에서 연결된 소셜 아이덴티티를 제거할 수 있지만, 엔드 유저를 대신해 새 소셜 계정을 연결할 수는 없습니다. - - **엔터프라이즈 SSO 연결** ([sso_identities](/user-management/user-data#sso-identities)): 연결된 엔터프라이즈 아이덴티티를 확인할 수 있습니다. Console에서는 SSO 아이덴티티를 추가하거나 제거할 수 없습니다. - - **다단계 인증 (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): 이 사용자가 설정한 모든 인증 요소(예: 패스키, 인증 앱, 백업 코드)를 확인할 수 있습니다. Console에서 인증 요소를 제거할 수 있습니다. + - **다단계 인증 (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): 이 사용자가 설정한 모든 인증 요소(예: 패스키, 인증 앱, 백업 코드)를 확인할 수 있습니다. Console에서 요소를 제거할 수 있습니다. - **개인 액세스 토큰**: [개인 액세스 토큰](/user-management/personal-access-token)을 생성, 보기, 이름 변경, 삭제할 수 있습니다. -- **사용자 프로필 데이터**: 이름, 아바타 URL, 커스텀 데이터, 추가 OpenID Connect 표준 클레임(포함되지 않은 항목). 이 모든 프로필 필드는 수정 가능합니다. +- **연결**: + - **소셜 연결** ([identities](/user-management/user-data#social-identities)): + - 사용자의 연결된 소셜 계정, 소셜 ID, 소셜 제공자에서 동기화된 프로필 정보를 확인할 수 있습니다(예: Facebook으로 로그인한 경우 "Facebook" 항목이 표시됨). + - 기존 소셜 아이덴티티는 제거할 수 있지만, 사용자를 대신해 새 소셜 계정을 연결할 수는 없습니다. + - [토큰 저장](/secret-vault/federated-token-set)이 활성화된 소셜 커넥터의 경우, 연결 상세 페이지에서 액세스 토큰 및 리프레시 토큰을 확인하고 관리할 수 있습니다. + - **엔터프라이즈 SSO 연결** ([sso_identities](/user-management/user-data#sso-identities)): + - 사용자의 연결된 엔터프라이즈 아이덴티티, 엔터프라이즈 ID, 프로필 정보를 확인할 수 있습니다. + - Console에서는 엔터프라이즈 SSO 아이덴티티를 추가하거나 제거할 수 없습니다. + - OIDC 기반 엔터프라이즈 커넥터에서 [토큰 저장](/secret-vault/federated-token-set)이 활성화된 경우, 연결 상세 페이지에서 토큰을 확인하고 삭제할 수 있습니다. +- **사용자 프로필 데이터**: 이름, 아바타 URL, 커스텀 데이터, 추가 OpenID Connect 표준 클레임(포함되지 않은 항목). 모든 프로필 필드는 수정 가능합니다. :::warning -소셜 연결을 제거하기 전에, 사용자가 다른 로그인 방법(다른 소셜 연결, 전화번호, 이메일, 사용자명+비밀번호 등)을 가지고 있는지 반드시 확인해야 합니다. 다른 로그인 방법이 없다면, 소셜 연결을 제거한 후 계정에 다시 접근할 수 없습니다. +소셜 연결을 제거하기 전에, 사용자가 다른 소셜 연결, 전화번호, 이메일, 또는 사용자명-비밀번호 등 대체 로그인 방법을 가지고 있는지 반드시 확인해야 합니다. 다른 로그인 방법이 없다면, 소셜 연결이 제거된 후 계정에 다시 접근할 수 없습니다. ::: ### 사용자 활동 보기 \{#view-user-activities} -사용자의 최근 활동을 보려면 "사용자 세부 정보" 페이지의 "사용자 로그" 하위 탭으로 이동하세요. 여기서 사용자의 최근 활동(수행한 작업, 결과, 관련 애플리케이션, 작업 시간 등)을 표로 확인할 수 있습니다. +사용자의 최근 활동을 보려면, "사용자 세부 정보" 페이지의 "사용자 로그" 하위 탭으로 이동하세요. 여기서 사용자의 최근 활동(수행된 작업, 결과, 관련 애플리케이션, 작업 시각 등)을 테이블로 확인할 수 있습니다. -표의 행을 클릭하면 사용자 로그의 상세 정보(IP 주소, user agent, 원시 데이터 등)를 볼 수 있습니다. +테이블 행을 클릭하면 IP 주소, 사용자 에이전트, 원시 데이터 등 로그의 더 많은 세부 정보를 볼 수 있습니다. ### 사용자 정지 \{#suspend-user} @@ -76,11 +82,17 @@ Logto Console 또는 Management API(엔드 유저가 UI를 통해 직접 가입 ### 사용자 비밀번호 재설정 \{#reset-user-password} -"사용자 세부 정보" 페이지에서 "점 세 개" -> "비밀번호 재설정" 버튼을 클릭하면, Logto가 임의의 비밀번호를 자동으로 재생성합니다. +"사용자 세부 정보" 페이지에서 "점 세 개" -> "비밀번호 재설정" 버튼을 클릭하면, Logto가 자동으로 임의의 비밀번호를 재생성합니다. -비밀번호를 재설정한 후, 복사하여 엔드 유저에게 전달하세요. "비밀번호 재설정" 모달을 닫으면 비밀번호를 더 이상 볼 수 없습니다. 만약 복사하지 못했다면, 다시 재설정할 수 있습니다. +비밀번호를 재설정한 후, 복사하여 최종 사용자에게 전달하세요. "비밀번호 재설정" 모달이 닫히면 비밀번호를 더 이상 볼 수 없습니다. 만약 비밀번호를 저장하지 못했다면, 다시 재설정할 수 있습니다. -Logto Console에서는 사용자의 특정 비밀번호를 직접 설정할 수 없지만, [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password`를 사용하여 비밀번호를 지정할 수 있습니다. +Logto Console에서는 사용자를 위한 특정 비밀번호를 직접 설정할 수 없지만, [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password`를 사용하여 비밀번호를 지정할 수 있습니다. + +## 비밀번호 정책 준수 검사 \{#password-compliance-check} + +Logto에서 [비밀번호 정책](/security/password-policy)을 업데이트한 후에도 기존 사용자는 현재 비밀번호로 계속 로그인할 수 있습니다. 새로 생성된 계정만이 업데이트된 비밀번호 정책을 따라야 합니다. + +더 강력한 보안을 위해, `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience)를 사용하여 사용자의 비밀번호가 기본 로그인 경험에 정의된 현재 정책을 충족하는지 확인할 수 있습니다. 충족하지 않는 경우, [Account API](/end-user-flows/account-settings/by-management-api#user-password-management)를 사용하여 사용자에게 비밀번호 업데이트를 안내하는 커스텀 플로우를 구현할 수 있습니다. ### 사용자 역할 관리 \{#manage-roles-of-users} @@ -88,23 +100,23 @@ Logto Console에서는 사용자의 특정 비밀번호를 직접 설정할 수 ### 사용자가 속한 조직 보기 \{#view-the-organizations-the-user-belongs-to} -Logto는 [조직](/organizations/organization-management)을 지원하며, 조직의 구성원을 관리할 수 있습니다. 사용자 세부 정보를 쉽게 확인하고, 사용자가 속한 조직을 볼 수 있습니다. +Logto는 [조직](/organizations/organization-management)을 지원하며, 구성원 관리를 할 수 있습니다. 사용자 세부 정보를 쉽게 확인하고, 사용자가 속한 조직을 볼 수 있습니다. ## Logto Management API를 통한 관리 \{#manage-via-logto-management-api} [Management API](/concepts/core-service/#management-api)는 Logto 백엔드 서비스에 접근할 수 있는 API 모음입니다. 앞서 언급했듯이, 사용자 API는 이 서비스의 핵심 구성 요소이며 다양한 시나리오를 지원할 수 있습니다. -사용자 관련 [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API는 `/api/users`에 위치하며, 사용자 활동(로그)은 `/api/logs?userId=:userId`에 위치합니다. +사용자 관련 [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API는 `/api/users`에 위치하며, 사용자 활동(즉, 사용자 로그)은 `/api/logs?userId=:userId`에 위치합니다. -Management API를 통해 여러 상황에서 사용자를 관리할 수 있습니다. 예를 들어, [고급 사용자 검색](/user-management/advanced-user-search), [대량 계정 생성](https://openapi.logto.io/operation/operation-createuser), [초대 전용 가입](/end-user-flows/sign-up-and-sign-in/disable-user-registration) 등이 있습니다. +Management API를 통해 여러 사용 사례에서 사용자를 관리할 수 있습니다. 예를 들어, [고급 사용자 검색](/user-management/advanced-user-search), [대량 계정 생성](https://openapi.logto.io/operation/operation-createuser), [초대 전용 회원가입](/end-user-flows/sign-up-and-sign-in/disable-user-registration) 등이 있습니다. -## 자주 묻는 질문(FAQs) \{#faqs} +## 자주 묻는 질문 (FAQs) \{#faqs}
-### 특정 사용자에 대해 특정 애플리케이션 접근을 제한하려면 어떻게 해야 하나요? \{#how-to-restrict-access-to-certain-application-for-specific-users} +### 특정 사용자의 특정 애플리케이션 접근을 제한하려면 어떻게 해야 하나요? \{#how-to-restrict-access-to-certain-application-for-specific-users} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index 8adefd468dc..114dc66f2d6 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -8,13 +8,13 @@ sidebar_position: 1 ## 사용자 프로필 \{#user-profile} -각 사용자는 [모든 사용자 정보](#property-reference)를 포함하는 프로필을 가집니다. +각 사용자는 [모든 사용자 정보](#property-reference)를 포함하는 프로필을 가지고 있습니다. 이는 다음과 같은 유형의 데이터로 구성됩니다: -- [기본 데이터](/user-management/user-data#basic-data): 사용자 프로필의 기본 정보입니다. 소셜 `identities` 및 `custom_data`를 제외한 모든 _사용자_ 속성을 저장합니다. 예를 들어 사용자 ID, 사용자 이름, 이메일, 전화번호, 마지막 로그인 시간 등이 있습니다. -- [소셜 아이덴티티](/user-management/user-data#social-identities): Facebook, GitHub, WeChat 등 소셜 커넥터로 소셜 로그인 시 가져온 사용자 정보를 저장합니다. -- [사용자 정의 데이터](/user-management/user-data#custom-data): 미리 정의된 사용자 속성에 포함되지 않은 추가 사용자 정보를 저장합니다. 예를 들어 사용자가 선호하는 색상과 언어 등이 있습니다. +- [기본 데이터](/user-management/user-data#basic-data): 사용자 프로필의 기본 정보입니다. 소셜 `identities`와 `custom_data`를 제외한 모든 _사용자_ 속성을 저장합니다. 예를 들어, 사용자 id, 사용자명, 이메일, 전화번호, 마지막 로그인 시각 등이 있습니다. +- [소셜 아이덴티티](/user-management/user-data#social-identities): Facebook, GitHub, WeChat 등 소셜 커넥터로 로그인(소셜 로그인)할 때 가져온 사용자 정보를 저장합니다. +- [사용자 정의 데이터](/user-management/user-data#custom-data): 미리 정의된 사용자 속성에 포함되지 않은 추가 사용자 정보를 저장합니다. 예를 들어, 사용자가 선호하는 색상과 언어 등이 있습니다. 다음은 Facebook으로 로그인하여 가져온 사용자 데이터 샘플입니다: @@ -48,8 +48,8 @@ sidebar_position: 1 } ``` -Logto Console 또는 Logto Management API, 예를 들어 [`GET -/api/users/:userId`](https://openapi.logto.io/operation/operation-getuser) 를 사용하여 사용자 +Logto Console 또는 Logto Management API(예: [`GET +/api/users/:userId`](https://openapi.logto.io/operation/operation-getuser))를 사용하여 사용자 프로필을 조회할 수 있습니다. ## 기본 데이터 \{#basic-data} @@ -64,19 +64,23 @@ sidebar_position: 1 *username*은 *username*과 비밀번호로 로그인할 때 사용됩니다. -값은 사용자가 처음 등록할 때 입력한 사용자 이름에서 가져옵니다. `null`일 수 있습니다. null이 아닌 값은 128자 이하여야 하며, 영문자, 숫자, 밑줄(`_`)만 포함할 수 있고 숫자로 시작할 수 없습니다. 대소문자를 구분합니다. +값은 사용자가 최초로 등록할 때 입력한 사용자명에서 가져옵니다. `null`일 수 있습니다. null이 아닌 값은 128자 이내여야 하며, 영문자, 숫자, 밑줄(`_`)만 포함할 수 있고 숫자로 시작할 수 없습니다. 대소문자를 구분합니다. ### primary_email \{#primary_email} *primary_email*은 사용자의 이메일 주소로, 이메일과 비밀번호 / 인증 코드로 로그인할 때 사용됩니다. -값은 사용자가 처음 등록할 때 입력한 이메일 주소에서 가져옵니다. `null`일 수 있습니다. 최대 길이는 128자입니다. +값은 사용자가 최초로 등록할 때 입력한 이메일 주소에서 가져옵니다. `null`일 수 있습니다. 최대 길이는 128자입니다. + +소셜 또는 엔터프라이즈 SSO 아이덴티티 제공자에서 인증된 이메일 주소만 `primary_email`로 동기화 및 저장할 수 있습니다. ### primary_phone \{#primary_phone} *primary_phone*은 사용자의 전화번호로, 전화번호와 비밀번호 / SMS 인증 코드로 로그인할 때 사용됩니다. -값은 사용자가 처음 등록할 때 입력한 전화번호에서 가져옵니다. `null`일 수 있습니다. null이 아닌 값은 [국가 전화 코드](https://en.wikipedia.org/wiki/List_of_country_calling_codes)로 시작하는 숫자여야 하며, 플러스 기호 `+`는 제외합니다. +값은 사용자가 최초로 등록할 때 입력한 전화번호에서 가져옵니다. `null`일 수 있습니다. null이 아닌 값은 [국가 전화 코드](https://en.wikipedia.org/wiki/List_of_country_calling_codes)로 시작하는 숫자여야 하며(플러스 기호 `+`는 제외), 숫자만 포함해야 합니다. + +소셜 또는 엔터프라이즈 SSO 아이덴티티 제공자에서 인증된 전화번호만 `primary_phone`로 동기화 및 저장할 수 있습니다. ### name \{#name} @@ -130,7 +134,7 @@ type UserProfile = Partial<{ ::: -다른 표준 클레임 (Claim)과의 차이점은, `profile`의 속성 값이 비어 있지 않을 때만 [ID 토큰](https://auth.wiki/id-token) 또는 userinfo 엔드포인트 응답에 포함된다는 점입니다. 반면, 다른 표준 클레임 (Claim)은 값이 비어 있으면 `null`을 반환합니다. +다른 표준 클레임 (Claim)과의 차이점은, `profile`의 속성들은 값이 비어 있지 않을 때만 [ID 토큰 (ID token)](https://auth.wiki/id-token) 또는 userinfo 엔드포인트 응답에 포함된다는 점입니다. 반면, 다른 표준 클레임 (Claim)은 값이 비어 있으면 `null`을 반환합니다. ### application_id \{#application_id} @@ -138,33 +142,33 @@ type UserProfile = Partial<{ ### last_sign_in_at \{#last_sign_in_at} -*last_sign_in_at*은 사용자가 마지막으로 로그인한 시점의 타임존이 포함된 타임스탬프입니다. +*last_sign_in_at*은 사용자가 마지막으로 로그인한 시각(타임존 포함)입니다. ### created_at \{#created_at} -*created_at*은 사용자가 계정을 등록한 시점의 타임존이 포함된 타임스탬프입니다. +*created_at*은 사용자가 계정을 등록한 시각(타임존 포함)입니다. ### updated_at \{#updated_at} -*updated_at*은 사용자의 프로필 정보가 마지막으로 업데이트된 시점의 타임존이 포함된 타임스탬프입니다. +*updated_at*은 사용자의 프로필 정보가 마지막으로 업데이트된 시각(타임존 포함)입니다. ### has_password \{#has_password} -*has_password*는 사용자가 비밀번호를 가지고 있는지 여부를 나타내는 불리언 값입니다. Console > 사용자 관리의 상세 페이지에서 이 상태를 확인하고 새 비밀번호 설정 또는 비밀번호 재설정이 가능합니다. +*has_password*는 사용자가 비밀번호를 가지고 있는지 여부를 나타내는 불리언 값입니다. Console > 사용자 관리의 상세 페이지에서 이 상태를 확인 및 관리(새 비밀번호 설정 또는 재설정)할 수 있습니다. ### password_encrypted \{#password_encrypted} *password_encrypted*는 사용자의 암호화된 비밀번호를 저장합니다. -값은 사용자가 처음 등록할 때 입력한 비밀번호에서 가져옵니다. `null`일 수 있습니다. null이 아닌 경우, 암호화 전 원본 내용은 최소 6자 이상이어야 합니다. +값은 사용자가 최초로 등록할 때 입력한 비밀번호에서 가져옵니다. `null`일 수 있습니다. null이 아닌 경우, 암호화 전 원본 내용은 최소 6자 이상이어야 합니다. ### password_encryption_method \{#password_encryption_method} -*password_encryption_method*는 사용자의 비밀번호를 암호화하는 데 사용됩니다. 사용자가 사용자 이름과 비밀번호로 등록할 때 초기화됩니다. `null`일 수 있습니다. +*password_encryption_method*는 사용자의 비밀번호를 암호화하는 데 사용됩니다. 사용자가 사용자명과 비밀번호로 등록할 때 초기화됩니다. `null`일 수 있습니다. Logto는 기본적으로 [Argon2](https://en.wikipedia.org/wiki/Argon2)의 구현체인 [node-argon2](https://github.com/ranisalt/node-argon2)를 암호화 방식으로 사용합니다. 자세한 내용은 참고 자료를 확인하세요. -비밀번호가 `123456`인 사용자의 _password_encrypted_ 및 _password_encryption_method_ 샘플: +비밀번호가 `123456`인 사용자의 *password_encrypted*와 _password_encryption_method_ 샘플: ```json { @@ -175,13 +179,13 @@ Logto는 기본적으로 [Argon2](https://en.wikipedia.org/wiki/Argon2)의 구 ### is_suspended \{#is_suspended} -*is_suspended*는 사용자가 정지되었는지 여부를 나타내는 불리언 값입니다. 값은 [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) 호출 또는 Logto Console을 통해 관리할 수 있습니다. +*is_suspended*는 사용자가 정지되었는지 여부를 나타내는 불리언 값입니다. [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) 호출 또는 Logto Console에서 값을 관리할 수 있습니다. -사용자가 정지되면, 사전에 부여된 리프레시 토큰 (Refresh token)은 즉시 폐기되며, 더 이상 Logto를 통해 인증 (Authentication)받을 수 없습니다. +사용자가 정지되면, 미리 발급된 리프레시 토큰 (Refresh token)은 즉시 폐기되며, 더 이상 Logto를 통해 인증 (Authentication)받을 수 없습니다. ### mfa_verification_factors \{#mfa_verification_factors} -*mfa_verification_factors*는 사용자의 계정에 연결된 [다단계 인증 (MFA)](/end-user-flows/mfa) 방법 목록입니다. 가능한 값에는 _Totp_ (인증 앱 OTP), _WebAuthn_ (패스키), *BackupCode*가 있습니다. +*mfa_verification_factors*는 사용자의 계정에 연결된 [다단계 인증 (MFA)](/end-user-flows/mfa) 방법을 나열하는 배열입니다. 가능한 값에는 _Totp_ (인증 앱 OTP), _WebAuthn_ (패스키), *BackupCode*가 포함됩니다. ```tsx mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; @@ -189,7 +193,7 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; ## 소셜 아이덴티티 \{#social-identities} -*identities*는 [소셜 로그인](/end-user-flows/sign-up-and-sign-in/social-sign-in) (즉, [소셜 커넥터](/connectors/social-connectors)로 로그인)에서 가져온 사용자 정보를 포함합니다. 각 사용자의 *identities*는 개별 JSON 객체로 저장됩니다. +*identities*는 [소셜 로그인](/end-user-flows/sign-up-and-sign-in/social-sign-in)(즉, [소셜 커넥터](/connectors/social-connectors)로 로그인)에서 가져온 사용자 정보를 포함합니다. 각 사용자의 *identities*는 개별 JSON 객체로 저장됩니다. 사용자 정보는 소셜 아이덴티티 제공자(즉, 소셜 네트워크 플랫폼)에 따라 다르며, 일반적으로 다음을 포함합니다: @@ -199,7 +203,7 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; - 사용자의 인증된 이메일 - 사용자의 아바타 -사용자 계정은 소셜 로그인으로 여러 소셜 아이덴티티 제공자와 연결될 수 있으며, 각 제공자로부터 가져온 사용자 정보는 _identities_ 객체에 저장됩니다. +사용자 계정은 소셜 로그인을 통해 여러 소셜 아이덴티티 제공자와 연결될 수 있으며, 각 제공자에서 가져온 사용자 정보는 _identities_ 객체에 저장됩니다. Google과 Facebook으로 모두 로그인한 사용자의 _identities_ 샘플: @@ -228,9 +232,9 @@ Google과 Facebook으로 모두 로그인한 사용자의 _identities_ 샘플: ## SSO 아이덴티티 \{#sso-identities} -*sso_identities*는 [엔터프라이즈 SSO](/end-user-flows/enterprise-sso) (즉, 엔터프라이즈 커넥터로 싱글 사인온 (SSO) 로그인](/connectors/enterprise-connectors))에서 가져온 사용자 정보를 포함합니다. 각 사용자의 *ssoIdentities*는 개별 JSON 객체로 저장됩니다. +*sso_identities*는 [엔터프라이즈 SSO](/end-user-flows/enterprise-sso)(즉, 엔터프라이즈 커넥터로 싱글 사인온 (SSO) 로그인)에서 가져온 사용자 정보를 포함합니다. 각 사용자의 *ssoIdentities*는 개별 JSON 객체로 저장됩니다. -SSO 아이덴티티 제공자로부터 동기화된 데이터는 엔터프라이즈 커넥터에서 요청하도록 구성된 스코프에 따라 다릅니다. 아래는 TypeScript 타입 정의 복사본입니다: +SSO 아이덴티티 제공자에서 동기화되는 데이터는 엔터프라이즈 커넥터에서 요청하도록 구성된 스코프에 따라 다릅니다. 아래는 TypeScript 타입 정의 복사본입니다: ```ts type SSOIdentity = { @@ -247,8 +251,8 @@ type SSOIdentity = { *custom_data*를 사용하여 다음과 같은 작업을 할 수 있습니다: - 사용자가 특정 작업(예: 환영 페이지를 본 적이 있는지 등)을 했는지 기록 -- 애플리케이션별로 사용자 프로필에 데이터 저장 (예: 사용자가 선호하는 언어, 애플리케이션별 테마 등) -- 사용자와 관련된 기타 임의의 데이터 관리 +- 애플리케이션별로 사용자 프로필에 데이터를 저장(예: 사용자가 선호하는 언어, 테마 등) +- 사용자와 관련된 기타 임의의 데이터 유지 Logto의 관리자 사용자의 _custom_data_ 샘플: @@ -276,26 +280,26 @@ Logto의 관리자 사용자의 _custom_data_ 샘플: ::: -사용자 로그인 후 [커스텀 JWT 토큰 클레임 (Claim)](/developers/custom-token-claims)을 통해 사용자 정의 데이터에 접근할 수 있으며, JWT 토큰은 base64로 인코딩(암호화 아님)되어 네트워크를 통해 자주 전송되므로 민감한 데이터가 쉽게 노출될 수 있습니다. +사용자 로그인 후 [커스텀 JWT 토큰 클레임 (Claim)](/developers/custom-token-claims)을 통해 사용자 정의 데이터에 접근할 수 있습니다. JWT 토큰은 base64로 인코딩(암호화 아님)되어 네트워크를 통해 자주 전송되므로, 민감한 데이터가 쉽게 노출될 수 있습니다. [Management API](https://openapi.logto.io/operation/operation-listusercustomdata)를 통해 *custom_data*가 포함된 사용자 프로필을 조회하여 프론트엔드 앱이나 외부 백엔드 서비스로 전송할 수 있습니다. 따라서 *custom_data*에 민감한 정보를 넣으면 데이터 유출 위험이 있습니다. -그래도 *custom_data*에 민감한 정보를 저장해야 한다면, 먼저 암호화할 것을 권장합니다. 암호화/복호화는 백엔드 서비스 등 신뢰할 수 있는 파티에서만 수행하고, 프론트엔드 앱에서는 피하세요. 이렇게 하면 사용자의 *custom_data*가 실수로 유출되더라도 피해를 최소화할 수 있습니다. +그래도 *custom_data*에 민감한 정보를 넣어야 한다면, 반드시 암호화해서 저장하세요. 암호화/복호화는 백엔드 서비스 등 신뢰할 수 있는 파티에서만 수행하고, 프론트엔드 앱에서는 피하세요. 이렇게 하면 사용자의 *custom_data*가 실수로 유출되더라도 피해를 최소화할 수 있습니다. **사용자 정의 데이터 수집 및 업데이트 방법** - [사용자 프로필 수집](/end-user-flows/collect-user-profile) 기능을 사용하여 회원가입 시 사용자 정의 데이터를 수집하세요. - [Account API](/end-user-flows/account-settings/by-account-api)를 사용하여 최종 사용자 프로필 또는 계정 설정을 구현하세요. - - [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile)로 모든 사용자 데이터를 조회하세요. - - [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile)로 사용자의 *custom_data*를 업데이트하세요. + - [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile)로 모든 사용자 데이터를 조회할 수 있습니다. + - [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile)로 사용자의 *custom_data*를 업데이트할 수 있습니다. - [Management API](/user-management/manage-users/#manage-via-logto-management-api)를 사용하여 사용자 관리 또는 고급 커스텀 플로우를 구현하세요: - - [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser)로 모든 사용자 데이터를 조회하세요. - - [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata)로 사용자의 *custom_data*를 업데이트하세요. + - [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser)로 모든 사용자 데이터를 조회할 수 있습니다. + - [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata)로 사용자의 *custom_data*를 업데이트할 수 있습니다. - 지원팀은 Console > 사용자 관리에서 직접 사용자 *custom_data*를 업데이트할 수 있습니다. [사용자 프로필 조회 및 업데이트](/user-management/manage-users/#view-and-update-the-user-profile)에서 자세히 알아보세요. -업데이트 시 주의하세요. 사용자의 *custom_data*를 업데이트하면 기존 저장된 내용이 완전히 덮어써집니다. +업데이트 시 주의하세요. 사용자의 *custom_data*를 업데이트하면 저장소의 기존 내용이 완전히 덮어써집니다. -예를 들어, _custom_data_ 업데이트 API 호출 입력이 다음과 같고(기존 *custom_data*는 앞서 제시한 샘플 데이터라고 가정): +예를 들어, _custom_data_ 업데이트 API 호출 시 입력값이 다음과 같고(기존 *custom_data*는 앞서 예시로 든 데이터라고 가정): ```json { @@ -319,28 +323,28 @@ Logto의 관리자 사용자의 _custom_data_ 샘플: ## 속성 참조 \{#property-reference} -다음 DB 사용자 테이블 컬럼(_password_encrypted_ 및 _password_encryption_method_ 제외)은 사용자 프로필에서 확인할 수 있으며, [Management API](https://openapi.logto.io/operation/operation-getuser)로 조회할 수 있습니다. - -| 이름 | 타입 | 설명 | 고유 | 필수 | -| ----------------------------------------------------------------------------------- | --------- | ---------------------------------------------- | ---- | ---- | -| [id](/user-management/user-data#id) | string | 고유 식별자 | ✅ | ✅ | -| [username](/user-management/user-data#username) | string | 로그인용 사용자 이름 | ✅ | ❌ | -| [primary_email](/user-management/user-data#primary_email) | string | 기본 이메일 | ✅ | ❌ | -| [primary_phone](/user-management/user-data#primary_phone) | string | 기본 전화번호 | ✅ | ❌ | -| [name](/user-management/user-data#name) | string | 전체 이름 | ❌ | ❌ | -| [avatar](/user-management/user-data#avatar) | string | 사용자 아바타 이미지 URL | ❌ | ❌ | -| [profile](/user-management/user-data#profile) | object | 사용자 프로필 | ❌ | ✅ | -| [identities](/user-management/user-data#social-identities) | object | 소셜 로그인에서 가져온 사용자 정보 | ❌ | ✅ | -| [custom_data](/user-management/user-data#custom-data) | object | 커스터마이즈 가능한 속성의 추가 정보 | ❌ | ✅ | -| [application_id](/user-management/user-data#application_id) | string | 사용자가 처음 등록한 애플리케이션 ID | ❌ | ✅ | -| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | 사용자가 마지막으로 로그인한 시점의 타임스탬프 | ❌ | ✅ | -| [password_encrypted](/user-management/user-data#password_encrypted) | string | 암호화된 비밀번호 | ❌ | ❌ | -| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | 비밀번호 암호화 방식 | ❌ | ❌ | -| [is_suspended](/user-management/user-data#is_suspended) | bool | 사용자 정지 여부 표시 | ❌ | ✅ | -| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 인증 (Authentication) 요소 | ❌ | ✅ | - -- **고유**: 데이터베이스 테이블 속성 값의 [고유성](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS)을 보장합니다. -- **필수**: 데이터베이스 테이블 속성 값이 `null`이 될 수 없음을 보장합니다. +다음 DB 사용자 테이블 컬럼( _password_encrypted_ 및 _password_encryption_method_ 제외)은 사용자 프로필에서 확인할 수 있으며, [Management API](https://openapi.logto.io/operation/operation-getuser)로 조회할 수 있습니다. + +| 이름 | 타입 | 설명 | 고유 | 필수 | +| ----------------------------------------------------------------------------------- | --------- | ------------------------------------ | ---- | ---- | +| [id](/user-management/user-data#id) | string | 고유 식별자 | ✅ | ✅ | +| [username](/user-management/user-data#username) | string | 로그인용 사용자명 | ✅ | ❌ | +| [primary_email](/user-management/user-data#primary_email) | string | 기본 이메일 | ✅ | ❌ | +| [primary_phone](/user-management/user-data#primary_phone) | string | 기본 전화번호 | ✅ | ❌ | +| [name](/user-management/user-data#name) | string | 전체 이름 | ❌ | ❌ | +| [avatar](/user-management/user-data#avatar) | string | 사용자 아바타 이미지 URL | ❌ | ❌ | +| [profile](/user-management/user-data#profile) | object | 사용자 프로필 | ❌ | ✅ | +| [identities](/user-management/user-data#social-identities) | object | 소셜 로그인에서 가져온 사용자 정보 | ❌ | ✅ | +| [custom_data](/user-management/user-data#custom-data) | object | 커스터마이즈 가능한 추가 정보 | ❌ | ✅ | +| [application_id](/user-management/user-data#application_id) | string | 사용자가 처음 등록한 애플리케이션 ID | ❌ | ✅ | +| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | 사용자가 마지막으로 로그인한 시각 | ❌ | ✅ | +| [password_encrypted](/user-management/user-data#password_encrypted) | string | 암호화된 비밀번호 | ❌ | ❌ | +| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | 비밀번호 암호화 방식 | ❌ | ❌ | +| [is_suspended](/user-management/user-data#is_suspended) | bool | 사용자 정지 여부 | ❌ | ✅ | +| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 인증 (Authentication) 요소 | ❌ | ✅ | + +- **고유**: 데이터베이스 테이블의 속성 값의 [고유성](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS)을 보장합니다. +- **필수**: 데이터베이스 테이블의 속성 값이 `null`이 될 수 없음을 보장합니다. ## 관련 리소스 \{#related-resources} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index cb3764aa5e0..912556f027a 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -13,7 +13,7 @@ import Tabs from '@theme/Tabs'; export const resource = 'https://api.your-app.com'; -Proteja APIs de todo o produto usando controle de acesso baseado em papel (RBAC) no Logto. Atribua papéis globais e permissões para controlar o acesso de todos os usuários e clientes em todo o seu aplicativo. +Proteja APIs de todo o produto usando controle de acesso baseado em papel (RBAC) no Logto. Atribua papéis globais e permissões para controlar o acesso de todos os usuários e clientes em seu aplicativo. ## O que são recursos globais de API? \{#what-are-global-api-resources} @@ -22,7 +22,7 @@ Recursos globais de API são endpoints ou serviços em seu aplicativo que são a **Casos de uso incluem** - APIs públicas ou endpoints compartilhados entre sua base de usuários. -- Microsserviços que não estão atrelados à multi-tenancy. +- Microsserviços que não estão atrelados à multi-tenância. - APIs centrais do aplicativo (por exemplo, `/api/users`, `/api/products`) usadas por todos os clientes. O Logto permite proteger essas APIs usando OAuth 2.1, combinado com controle de acesso flexível baseado em papel. @@ -41,7 +41,7 @@ O Logto permite proteger essas APIs usando OAuth 2.1, combinado com controle de 2. **Defina papéis** com as permissões necessárias para acessar a API. 3. **Atribua papéis** a usuários ou clientes. 4. **Use fluxos de autorização OAuth 2.0** para obter tokens de acesso para a API (o parâmetro resource deve corresponder ao identificador da API registrada). -5. **Valide os tokens de acesso** em sua API para aplicar as permissões. +5. **Valide tokens de acesso** em sua API para aplicar as permissões. ### Entendendo indicadores de recurso \{#understanding-resource-indicators} @@ -81,12 +81,12 @@ sequenceDiagram Logto->>Cliente: Retorna refresh token Cliente->>Logto: POST /oidc/token com `grant_type=refresh_token`
e parâmetro `resource` end - else Autenticação cliente máquina para máquina (M2M) + else Autenticação de cliente máquina para máquina (M2M) Cliente->>Logto: POST /oidc/token com `grant_type=client_credentials`
e parâmetro `resource` end Logto->>Cliente: Retorna token de acesso (JSON Web Token) - Cliente->>Recurso de API: Requisição com Bearer token + Cliente->>Recurso de API: Requisição com token Bearer Recurso de API->>Recurso de API: Valida token de acesso alt Token é válido @@ -96,7 +96,7 @@ sequenceDiagram end ``` -_Autenticação do usuário = navegador / aplicativo. M2M = serviço backend ou script usando credenciais de cliente._ +_Autenticação do usuário = navegador / aplicativo. M2M = serviço backend ou script usando credenciais do cliente._ :::note O parâmetro `resource` deve corresponder exatamente ao identificador da API (indicador de recurso) que você registrou no Logto. @@ -106,22 +106,22 @@ O parâmetro `resource` deve corresponder exatamente ao identificador da API (in ### Registre seus recursos de API \{#register-your-api-resources} -1. Vá para Console → Recursos de API. +1. Acesse Console → Recursos de API. 2. Crie um novo recurso de API (por exemplo, `https://api.yourapp.com/org`) e defina suas permissões (escopos). Para etapas completas de configuração, veja [Definir recursos de API com permissões](/authorization/role-based-access-control#define-api-resources-with-permissions). ### Configure papéis globais \{#set-up-global-roles} -1. Vá para Console → Papéis. +1. Acesse Console → Papéis. 2. Crie papéis que correspondam às permissões da sua API (por exemplo, `read:products`, `write:products`). -3. Atribua esses papéis a usuários ou clientes que precisam de acesso à API. +3. Atribua esses papéis a usuários ou clientes que precisam acessar a API. Para etapas completas de configuração, veja [Usar papéis globais](/authorization/role-based-access-control#configure-global-roles). ### Obtenha tokens de acesso para recursos globais de API \{#obtain-access-tokens-for-global-api-resources} -Antes de acessar um recurso global de API, seu cliente deve obter um token de acesso. O Logto emite [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) como tokens de acesso para recursos globais de API. Isso normalmente é feito usando o [fluxo de código de autorização OAuth 2.0](https://auth.wiki/authorization-code-flow), [fluxo de refresh token](https://auth.wiki/refresh-token) ou o [fluxo de client credentials](https://auth.wiki/client-credentials-flow). +Antes de acessar um recurso global de API, seu cliente deve obter um token de acesso. O Logto emite [JSON Web Tokens (JWTs)](https://auth.wiki/jwt) como tokens de acesso para recursos globais de API. Isso normalmente é feito usando o [fluxo de código de autorização OAuth 2.0](https://auth.wiki/authorization-code-flow), [fluxo de refresh token](https://auth.wiki/refresh-token) ou o [fluxo de credenciais do cliente](https://auth.wiki/client-credentials-flow). #### Fluxo de código de autorização ou refresh token \{#authorization-code-or-refresh-token-flow} @@ -137,11 +137,11 @@ Uma vez que o usuário esteja autenticado, passe o indicador de recurso no parâ Para detalhes sobre cada SDK, veja os [Comece rápido](/quick-starts). - + Ao configurar seu cliente OAuth 2.0 ou inicializar o fluxo de código de autorização, certifique-se de incluir o parâmetro `resource` e os escopos desejados na solicitação de autorização. -Algumas bibliotecas podem não suportar o parâmetro `resource` nativamente, mas geralmente permitem passar parâmetros adicionais na solicitação de autorização. Verifique a documentação da sua biblioteca para detalhes. +Algumas bibliotecas podem não suportar o parâmetro `resource` nativamente, mas geralmente permitem passar parâmetros adicionais na solicitação de autorização. Consulte a documentação da sua biblioteca para detalhes. Aqui está um exemplo não normativo da solicitação de autorização com os parâmetros `resource` e `scope`: @@ -149,29 +149,29 @@ Aqui está um exemplo não normativo da solicitação de autorização com os pa Uma vez que o usuário esteja autenticado, você receberá um código de autorização. Troque esse código por um token de acesso fazendo uma requisição POST para o endpoint `/oidc/token` do Logto, incluindo o parâmetro `resource` no corpo da requisição. -Aqui está um exemplo não normativo da solicitação de token usando o tipo de concessão authorization code: +Aqui está um exemplo não normativo da solicitação de token usando o tipo de concessão authorization_code: -Você também pode usar o tipo de concessão `refresh_token` para obter um novo token de acesso sem interação do usuário, desde que o parâmetro `resource` seja incluído na requisição. +Você também pode usar o tipo de concessão `refresh_token` para obter um novo token de acesso sem interação do usuário, desde que o parâmetro `resource` esteja incluído na requisição. -Aqui está um exemplo não normativo da solicitação de token usando o tipo de concessão refresh token: +Aqui está um exemplo não normativo da solicitação de token usando o tipo de concessão refresh_token: -#### Fluxo de client credentials \{#client-credentials-flow} +#### Fluxo de credenciais do cliente \{#client-credentials-flow} -Para cenários máquina para máquina (M2M), você pode usar o fluxo de client credentials para obter um token de acesso para seu recurso global de API. Fazendo uma requisição POST para o endpoint `/oidc/token` do Logto, você pode solicitar um token de acesso usando seu client ID e secret. +Para cenários máquina para máquina (M2M), você pode usar o fluxo de credenciais do cliente para obter um token de acesso para seu recurso global de API. Fazendo uma requisição POST para o endpoint `/oidc/token` do Logto, você pode solicitar um token de acesso usando seu client ID e secret. Há dois parâmetros principais a serem incluídos na requisição: -- `resource`: O URI indicador de recurso da API que você deseja acessar (por exemplo, `https://api.yourapp.com`). +- `resource`: O URI do indicador de recurso da API que você deseja acessar (por exemplo, `https://api.yourapp.com`). - `scope`: As permissões que você deseja solicitar para a API (por exemplo, `read:products write:products`). -Aqui está um exemplo não normativo da solicitação de token usando o tipo de concessão client credentials: +Aqui está um exemplo não normativo da solicitação de token usando o tipo de concessão client_credentials: +
+ + +### Posso usar prefixos de escopo ou versões abreviadas ao solicitar permissões? \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +Não. Os nomes dos escopos devem **corresponder exatamente** aos nomes das permissões definidos em seu recurso de API. Prefixos e versões abreviadas não funcionam como curingas. + +**Exemplo:** + +Se seu recurso de API define: + +- `read:elections` +- `write:elections` + +Você deve solicitar: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +Isso **NÃO funcionará**: + +```swift +scopes: ["read", "write"] // ❌ Não corresponde aos nomes das permissões +``` + +
+ ## Leitura adicional \{#further-reading} Como validar tokens de acesso diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index 09f82c63a91..8d06a8d0e3d 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -60,17 +60,17 @@ Em tempo de execução, o idioma da experiência de login é resolvido com a seg 2. Caso contrário, se a "detecção automática" estiver ativada, o idioma do cliente do usuário detectado (por exemplo, do cabeçalho HTTP `Accept-Language`). 3. Caso contrário, o idioma padrão do tenant na Experiência de Login. -Essa resolução também afeta a localização de emails para mensagens disparadas pela interação. Saiba mais: [Localização de templates de email](/connectors/email-connectors/email-templates#email-template-localization). +Essa resolução também afeta a localização de e-mails para mensagens disparadas pela interação. Saiba mais: [Localização de templates de e-mail](/connectors/email-connectors/email-templates#email-template-localization). ## Casos de uso \{#use-cases} Como o idioma adicionado aparece para os clientes finais? -Vamos supor que você tenha um site onde o inglês é o idioma padrão e a detecção automática está ativada. Um usuário do Japão acessa seu site e decide criar uma conta. Se ele/ela usar o japonês como idioma do aplicativo, mas o Logto ainda não oferecer suporte ao idioma, a tela de login aparecerá em inglês. +Suponha que você tenha um site onde o inglês é o idioma padrão e a detecção automática está ativada. Um usuário do Japão acessa seu site e decide criar uma conta. Se ele/ela usar japonês como idioma do aplicativo, mas o Logto ainda não oferecer suporte ao idioma, a tela de login aparecerá em inglês. -A experiência de login i18n do Logto torna possível o idioma personalizado. +A experiência de login do Logto i18n torna possível a personalização de idiomas. -Clique na tag de idioma `ja` para adicionar sua própria tradução em japonês. +Clique na tag de idioma `ja` para adicionar sua própria tradução para o japonês. Dessa forma, o usuário acessando seu site do Japão poderá ler o conteúdo em japonês, que você acabou de traduzir do inglês. @@ -83,7 +83,7 @@ Dessa forma, o usuário acessando seu site do Japão poderá ler o conteúdo em -Ao lado da tag de idioma à esquerda, aparecerá uma tag de idioma fornecida pelo Logto, e o idioma que você adicionou não poderá mais ser removido. Os valores modificados continuam funcionando e substituem os valores originais do Logto. Apague os valores fornecidos pelo usuário para usar os valores fornecidos pela configuração padrão do Logto. +Ao lado da tag de idioma à esquerda, aparecerá uma tag indicando que é fornecido pelo Logto, e o idioma que você adicionou não poderá mais ser removido. Os valores modificados continuam funcionando e substituem os valores originais do Logto. Apague os valores fornecidos pelo usuário para usar os valores fornecidos pela configuração padrão do Logto.
@@ -99,6 +99,19 @@ Suponha que você queira ajustar apenas um subconjunto dos textos originais forn +
+ + +### Como posso definir um código de país padrão para número de telefone na experiência de login? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +O código de país do número de telefone na [experiência de login](/end-user-flows/sign-up-and-sign-in/sign-up) é definido por padrão de acordo com o local do navegador do usuário. Por exemplo, se o idioma do navegador do usuário estiver definido como `fr`, o código do país será definido como França (+33). + +Para controlar programaticamente o código de país padrão para usuários ou regiões específicas, você pode usar o parâmetro de autenticação [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales). Por exemplo, definir `ui_locales=ja` fará com que o código do país padrão seja Japão (+81). + +
+ ## Recursos relacionados \{#related-resources} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index 786b76c63c8..7101d7aac47 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -8,19 +8,19 @@ sidebar_position: 1 Personalize a aparência da sua página de login navegando até Console > Experiência de login > Personalização. Esta seção permite ajustar facilmente os principais elementos de identidade visual. -**Cor da marca** +### Cor da marca \{#brand-color} Defina a cor primária usada em toda a experiência de login, incluindo botões principais, links e outros componentes. Substitua a cor roxa padrão do Logto pela cor da sua marca. Para o modo escuro, uma cor de marca separada pode ser especificada. -**Logo da empresa** +### Logotipo da empresa \{#company-logo} -O logo será exibido na página inicial de login, página inicial de cadastro, página de carregamento e outras interfaces com nossa expansão. +O logotipo será exibido na página inicial de login, página inicial de cadastro, página de carregamento e outras interfaces com nossa expansão. - Existem algumas limitações para imagens: devem ter menos de 500KB e estar nos formatos SVG, PNG, JPG, JPEG ou ICO. -- Se você deixar o campo do logo em branco, o logo não será exibido na interface. -- Uma versão do logo para o modo escuro também pode ser enviada. +- Se você deixar o campo do logotipo em branco, o logotipo não será exibido na interface. +- Uma versão do logotipo para o modo escuro também pode ser enviada. -**Favicon** +### Favicon \{#favicon} Um favicon é um pequeno ícone que representa um site e é exibido na aba do navegador, favoritos e outras áreas da interface do navegador. @@ -28,34 +28,38 @@ Um favicon é um pequeno ícone que representa um site e é exibido na aba do na - Uma versão do favicon para o modo escuro também pode ser enviada. - Além disso, o título do navegador para diferentes fluxos (Entrar / Cadastrar / Esqueci a senha, etc.) agora é usado em vez de um título personalizado. -**Modo escuro** +### Modo escuro \{#dark-mode} Ative o modo escuro para ajustar automaticamente a aparência da página de login com base nas preferências do sistema do usuário. +### Ocultar marca Logto \{#hide-logto-branding} + +Por padrão, as páginas de experiência de login prontas para uso exibem "Powered by Logto" na parte inferior. Ative a opção "Ocultar marca Logto" para remover a marca Logto e criar uma experiência de login limpa e profissional que destaque exclusivamente a identidade da sua própria marca. + ## Personalização específica do aplicativo \{#app-specific-branding} Se o seu negócio multiaplicativo precisa de experiências de login em nível de aplicativo, você pode configurar isso na página de detalhes do aplicativo. Navegue até Console > Aplicativos. -Ao ativar a "Experiência de login em nível de aplicativo", você pode configurar logos, favicons, cores e até mesmo [CSS personalizado](/customization/custom-css) específicos para cada app. Quando um login é iniciado a partir de um app com personalização em nível de app ativada, a experiência de login será personalizada de acordo com as configurações desse app; caso contrário, será usada a configuração padrão da experiência omni de login. +Ao ativar "Experiência de login em nível de aplicativo", você pode configurar logotipos, favicons, cores e até mesmo [CSS personalizado](/customization/custom-css) específicos para cada aplicativo. Quando um login é iniciado a partir de um aplicativo com personalização em nível de aplicativo ativada, a experiência de login será personalizada de acordo com as configurações desse aplicativo; caso contrário, será usada a configuração padrão da experiência omni de login. -Tanto as configurações de modo claro quanto de modo escuro estão disponíveis para a personalização em nível de app. As configurações de modo escuro só terão efeito quando o modo escuro estiver ativado nas configurações da [experiência omni de login](#omni-sign-in-experience). +Configurações para modo claro e escuro estão disponíveis para a personalização em nível de aplicativo. As configurações de modo escuro só terão efeito quando o modo escuro estiver ativado nas configurações da [experiência omni de login](#omni-sign-in-experience). ## Personalização específica da organização \{#organization-specific-branding} -Para exibir dinamicamente o logo da organização do seu cliente na experiência de login, você pode enviar os logos das organizações na página de configurações da organização. Navegue até Console > Organizações. +Para exibir dinamicamente o logotipo da organização do seu cliente na experiência de login, você pode enviar os logotipos das organizações na página de configurações da organização. Navegue até Console > Organizações. -Ao ativar a "Experiência de login em nível de organização", assim como na personalização em nível de app, você também pode configurar logos, favicons, cores e [CSS personalizado](/customization/custom-css) específicos para cada organização. +Ao ativar "Experiência de login em nível de organização", assim como na personalização em nível de aplicativo, você também pode configurar logotipos, favicons, cores e [CSS personalizado](/customization/custom-css) específicos para cada organização. -Então, ao acionar um login, você pode passar o ID da organização no parâmetro `organization_id` para informar ao Logto qual logo de organização exibir. Por exemplo, para mostrar o logo da organização com ID `123456`: +Então, ao acionar um login, você pode passar o ID da organização no parâmetro `organization_id` para informar ao Logto qual logotipo de organização exibir. Por exemplo, para mostrar o logotipo da organização com ID `123456`: - Se você estiver usando o Logto SDK, pode passar o parâmetro `organization_id` no objeto `extraParams` do método `signIn`. - Se estiver usando um cliente OIDC, pode passar o parâmetro `organization_id` ao solicitar o [endpoint de autorização](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). -Tanto as configurações de modo claro quanto de modo escuro estão disponíveis para a personalização em nível de organização. As configurações de modo escuro só terão efeito quando o modo escuro estiver ativado nas configurações da [experiência omni de login](#omni-sign-in-experience). +Configurações para modo claro e escuro estão disponíveis para a personalização em nível de organização. As configurações de modo escuro só terão efeito quando o modo escuro estiver ativado nas configurações da [experiência omni de login](#omni-sign-in-experience). :::note -Se tanto a personalização em nível de app quanto em nível de organização estiverem ativadas, a personalização em nível de organização terá precedência. A ordem completa de precedência é: -Personalização em nível de organização -> Personalização em nível de app -> Experiência omni de login +Se tanto a personalização em nível de aplicativo quanto em nível de organização estiverem ativadas, a personalização em nível de organização terá precedência. A ordem completa de precedência é: +Personalização em nível de organização -> Personalização em nível de aplicativo -> Experiência omni de login ::: Aqui está um exemplo de como passar o parâmetro `organization_id` no método `signIn` usando o [Logto browser SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out): @@ -81,5 +85,5 @@ Estamos implementando gradualmente o recurso `extraParams` em todos os Logto SDK ## Recursos relacionados \{#related-resources} - Como personalizar a experiência de login para cada app ou organização? + Como personalizar a experiência de login para cada aplicativo ou organização? diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index c35af7de92b..e887dfa16f7 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -10,9 +10,9 @@ sidebar_position: 1 A Logto Account API é um conjunto abrangente de APIs que oferece aos usuários finais acesso direto via API sem a necessidade de passar pela Management API. Aqui estão os destaques: - Acesso direto: A Account API permite que os usuários finais acessem e gerenciem diretamente seus próprios perfis de conta sem precisar do repasse da Management API. -- Gerenciamento de perfil de usuário e identidades: Os usuários podem gerenciar totalmente seus perfis e configurações de segurança, incluindo a capacidade de atualizar informações de identidade como email, telefone e senha, além de gerenciar conexões sociais. Suporte para MFA e SSO em breve. +- Gerenciamento de perfil de usuário e identidades: Os usuários podem gerenciar totalmente seus perfis e configurações de segurança, incluindo a capacidade de atualizar informações de identidade como email, telefone e senha, além de gerenciar conexões sociais. Suporte a MFA e SSO em breve. - Controle de acesso global: Os administradores têm controle total e global sobre as configurações de acesso e podem personalizar cada campo. -- Autorização perfeita: A autorização está mais fácil do que nunca! Basta usar `client.getAccessToken()` para obter um token opaco de acesso para OP (Logto) e anexá-lo ao cabeçalho Authorization como `Bearer `. +- Autorização (Authorization) sem atrito: A autorização nunca foi tão fácil! Basta usar `client.getAccessToken()` para obter um token opaco de acesso para OP (Logto) e anexá-lo ao cabeçalho Authorization como `Bearer `. Com a Logto Account API, você pode construir um sistema personalizado de gerenciamento de contas, como uma página de perfil totalmente integrada ao Logto. @@ -28,13 +28,13 @@ Para saber mais sobre as APIs disponíveis, visite [Referência da Logto Account :::note -Os recursos de visualização de conta SSO e exclusão de conta estão atualmente disponíveis através das Management APIs do Logto. Veja [Configurações de conta pela Management API](/end-user-flows/account-settings/by-management-api) para detalhes de implementação. +Os recursos de visualização de conta SSO e exclusão de conta estão disponíveis atualmente através das Management APIs do Logto. Veja [Configurações de conta pela Management API](/end-user-flows/account-settings/by-management-api) para detalhes de implementação. ::: ## Como habilitar a Account API \{#how-to-enable-account-api} -Navegue até Console > Login & conta > Central de contas. +Navegue até Console > Login & conta > Central da conta. A Account API vem desativada por padrão, então seus controles de acesso estão bloqueados. Ative **Habilitar Account API** para ligá-la. @@ -42,26 +42,26 @@ Uma vez habilitada, configure permissões por campo para identificadores, dados 1. **Campos de segurança**: - Os campos incluem: email principal, telefone principal, identidades sociais, senha e MFA. - - Antes de os usuários finais editarem esses campos, eles devem verificar sua identidade via senha, email ou SMS para obter um ID de registro de verificação válido por 10 minutos. Veja [Obter um ID de registro de verificação](#get-a-verification-record-id). - - Para usar passkeys WebAuthn para MFA, adicione os domínios do seu app front-end em **WebAuthn Related Origins** para que a central de contas e a experiência de login possam compartilhar passkeys. Veja [Vincular uma nova passkey WebAuthn](#link-a-new-webauthn-passkey). + - Antes que os usuários finais editem esses campos, eles devem verificar sua identidade via senha, email ou SMS para obter um ID de registro de verificação válido por 10 minutos. Veja [Obter um ID de registro de verificação](#get-a-verification-record-id). + - Para usar passkeys WebAuthn para MFA, adicione os domínios do seu app front-end em **WebAuthn Related Origins** para que a central da conta e a experiência de login possam compartilhar passkeys. Veja [Vincular uma nova passkey WebAuthn](#link-a-new-webauthn-passkey). 2. **Campos de perfil**: - Os campos incluem: nome de usuário, nome, avatar, [perfil](/user-management/user-data#profile) (outros atributos padrão de perfil) e [dados personalizados](/user-management/user-data#custom-data). - Usuários finais podem editar esses campos sem verificação adicional. -3. **Cofre de segredos**: Para conectores sociais e corporativos OIDC ou OAuth, o [cofre de segredos](/secret-vault/federated-token-set) do Logto armazena com segurança tokens de acesso e atualização de terceiros após a autenticação. Os apps podem então chamar APIs externas, como sincronizar eventos do Google Agenda, sem solicitar novo login ao usuário. A recuperação de tokens fica disponível automaticamente após habilitar a Account API. +3. **Cofre de segredos**: Para conectores sociais e corporativos OIDC ou OAuth, o [cofre de segredos](/secret-vault/federated-token-set) do Logto armazena com segurança tokens de acesso e atualização de terceiros após a autenticação. Os apps podem então chamar APIs externas, como sincronizar eventos do Google Agenda, sem pedir que os usuários façam login novamente. A recuperação de tokens fica disponível automaticamente após habilitar a Account API. ## Como acessar a Account API \{#how-to-access-account-api} :::note -Para garantir que o token de acesso tenha as permissões apropriadas, certifique-se de configurar corretamente os escopos correspondentes no seu config do Logto. +Para garantir que o token de acesso tenha as permissões apropriadas, certifique-se de configurar corretamente os escopos correspondentes em sua configuração do Logto. -Por exemplo, para a API `POST /api/my-account/primary-email`, você precisa configurar o escopo `email`; para a API `POST /api/my-account/primary-phone`, configure o escopo `phone`. +Por exemplo, para a API `POST /api/my-account/primary-email`, você precisa configurar o escopo `email`; para a API `POST /api/my-account/primary-phone`, você precisa configurar o escopo `phone`. ```ts import { type LogtoConfig, UserScope } from '@logto/js'; const config: LogtoConfig = { // ...outras opções - // Adicione os escopos adequados conforme seu caso de uso. + // Adicione os escopos adequados para seus casos de uso. scopes: [ UserScope.Email, // Para as APIs `{POST,DELETE} /api/my-account/primary-email` UserScope.Phone, // Para as APIs `{POST,DELETE} /api/my-account/primary-phone` @@ -77,13 +77,13 @@ const config: LogtoConfig = { ### Buscar um token de acesso \{#fetch-an-access-token} -Após configurar o SDK em seu aplicativo, você pode usar o método `client.getAccessToken()` para buscar um token de acesso. Esse token é um token opaco que pode ser usado para acessar a Account API. +Após configurar o SDK em seu aplicativo, você pode usar o método `client.getAccessToken()` para buscar um token de acesso. Este token é um token opaco que pode ser usado para acessar a Account API. -Se você não estiver usando o SDK oficial, deve definir o `resource` como vazio na solicitação de concessão de token de acesso para `/oidc/token`. +Se você não estiver usando o SDK oficial, deve definir o `resource` como vazio na solicitação de concessão do token de acesso para `/oidc/token`. ### Acessar a Account API usando o token de acesso \{#access-account-api-using-access-token} -Você deve incluir o token de acesso no campo `Authorization` dos headers HTTP no formato Bearer (`Bearer YOUR_TOKEN`) ao interagir com a Account API. +Você deve incluir o token de acesso no campo `Authorization` dos cabeçalhos HTTP com o formato Bearer (`Bearer YOUR_TOKEN`) ao interagir com a Account API. Veja um exemplo para obter as informações da conta do usuário: @@ -96,7 +96,7 @@ curl https://[tenant-id].logto.app/api/my-account \ ### Recuperar informações da conta do usuário \{#retrieve-user-account-information} -Para obter os dados do usuário, utilize o endpoint [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile). +Para obter dados do usuário, você pode usar o endpoint [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile). ```bash curl https://[tenant-id].logto.app/api/my-account \ @@ -114,13 +114,13 @@ O corpo da resposta será assim: } ``` -Os campos da resposta podem variar conforme as configurações da central de contas. +Os campos da resposta podem variar dependendo das configurações da central da conta. ### Atualizar informações básicas da conta \{#update-basic-account-information} As informações básicas da conta incluem nome de usuário, nome, avatar, dados personalizados e outras informações de perfil. -Para atualizar **username, name, avatar e customData** utilize o endpoint [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile). +Para atualizar **username, name, avatar e customData** você pode usar o endpoint [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile). ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account \ @@ -129,7 +129,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account \ --data-raw '{"username":"...","name":"...","avatar":"..."}' ``` -Para atualizar outras informações de perfil, incluindo **familyName, givenName, middleName, nickname, profile (URL da página de perfil), website, gender, birthdate, zoneinfo, locale e address**, utilize o endpoint [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile). +Para atualizar outras informações de perfil, incluindo **familyName, givenName, middleName, nickname, profile (URL da página de perfil), website, gender, birthdate, zoneinfo, locale e address**, você pode usar o endpoint [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile). ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ @@ -144,7 +144,7 @@ Por motivos de segurança, a Account API exige uma camada adicional de autoriza ### Obter um ID de registro de verificação \{#get-a-verification-record-id} -Primeiro, você precisa obter um **ID de registro de verificação** com expiração de 10 minutos (TTL). Ele pode ser usado para verificar a identidade do usuário antes de atualizar informações sensíveis. Isso significa que, uma vez que o usuário verifique sua identidade com senha, código de verificação por email ou SMS, ele terá 10 minutos para atualizar dados relacionados à autenticação, incluindo identificadores, credenciais, vinculação de conta social e MFA. +Primeiro, você precisa obter um **ID de registro de verificação** com expiração de 10 minutos (TTL). Isso pode ser usado para verificar a identidade do usuário antes de atualizar informações sensíveis. Ou seja, uma vez que o usuário verifica sua identidade com sucesso via senha, código de verificação por email ou SMS, ele tem 10 minutos para atualizar seus dados relacionados à autenticação, incluindo identificadores, credenciais, vinculação de conta social e MFA. Para obter um ID de registro de verificação, você pode [verificar a senha do usuário](#verify-the-users-password) ou [enviar um código de verificação para o email ou telefone do usuário](#verify-by-sending-a-verification-code-to-the-users-email-or-phone). @@ -169,7 +169,7 @@ O corpo da resposta será assim: #### Verificar enviando um código de verificação para o email ou telefone do usuário \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} :::note -Para usar este método, é necessário [configurar o conector de email](/connectors/email-connectors/) ou [conector de SMS](/connectors/sms-connectors/), e garantir que o template `UserPermissionValidation` esteja configurado. +Para usar este método, você precisa [configurar o conector de email](/connectors/email-connectors/) ou [conector de SMS](/connectors/sms-connectors/), e garantir que o template `UserPermissionValidation` esteja configurado. ::: Usando email como exemplo, solicite um novo código de verificação e obtenha o ID de registro de verificação: @@ -203,11 +203,11 @@ Após verificar o código, você pode usar o ID de registro de verificação par Para saber mais sobre verificações, consulte [Verificação de segurança pela Account API](/end-user-flows/security-verification). -### Enviar requisição com ID de registro de verificação \{#send-request-with-verification-record-id} +### Enviar solicitação com ID de registro de verificação \{#send-request-with-verification-record-id} -Ao enviar uma requisição para atualizar o identificador do usuário, inclua o ID de registro de verificação no header da requisição com o campo `logto-verification-id`. +Ao enviar uma solicitação para atualizar o identificador do usuário, inclua o ID de registro de verificação no cabeçalho da requisição com o campo `logto-verification-id`. -### Atualizar senha do usuário \{#update-users-password} +### Atualizar a senha do usuário \{#update-users-password} Para atualizar a senha do usuário, utilize o endpoint [`POST /api/my-account/password`](https://openapi.logto.io/operation/operation-updatepassword). @@ -219,13 +219,17 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +Assim como as senhas criadas durante o cadastro, as senhas definidas pela Account API devem estar em conformidade com a [política de senha](/security/password-policy) que você configurou em Console > Segurança > Política de senha. O Logto retorna resultados detalhados de validação e mensagens de erro se a senha não atender à política. +::: + ### Atualizar ou vincular novo email \{#update-or-link-new-email} :::note -Para usar este método, é necessário [configurar o conector de email](/connectors/email-connectors/) e garantir que o template `BindNewIdentifier` esteja configurado. +Para usar este método, você precisa [configurar o conector de email](/connectors/email-connectors/) e garantir que o template `BindNewIdentifier` esteja configurado. ::: -Para atualizar ou vincular um novo email, primeiro é necessário comprovar a posse do email. +Para atualizar ou vincular um novo email, primeiro você deve comprovar a posse do email. Chame o endpoint [`POST /api/verifications/verification-code`](https://openapi.logto.io/operation/operation-createverificationbyverificationcode) para solicitar um código de verificação. @@ -236,7 +240,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ --data-raw '{"identifier":{"type":"email","value":"..."}}' ``` -Você encontrará um `verificationId` na resposta e receberá um código de verificação no email; use-o para verificar o email. +Você encontrará um `verificationId` na resposta e receberá um código de verificação no email, use-o para verificar o email. ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \ @@ -255,6 +259,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +Assim como os emails coletados durante o cadastro, qualquer email vinculado pela Account API deve passar pela verificação da [blocklist](/security/blocklist) que você configurou em Console > Segurança > Blocklist. O Logto rejeitará a solicitação e retornará um erro detalhado se o email violar a política. +::: + ### Remover o email do usuário \{#remove-the-users-email} Para remover o email do usuário, utilize o endpoint [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail). @@ -268,10 +276,10 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### Gerenciar telefone \{#manage-phone} :::note -Para usar este método, é necessário [configurar o conector de SMS](/connectors/sms-connectors/) e garantir que o template `BindNewIdentifier` esteja configurado. +Para usar este método, você precisa [configurar o conector de SMS](/connectors/sms-connectors/) e garantir que o template `BindNewIdentifier` esteja configurado. ::: -Semelhante à atualização de email, utilize o endpoint [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) para atualizar ou vincular um novo telefone. E use o endpoint [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) para remover o telefone do usuário. +Semelhante à atualização de email, você pode usar o endpoint [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) para atualizar ou vincular um novo telefone. E usar o endpoint [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) para remover o telefone do usuário. ### Vincular uma nova conexão social \{#link-a-new-social-connection} @@ -285,8 +293,8 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ ``` - `connectorId`: O ID do [conector social](/connectors/social-connectors/). -- `redirectUri`: A URI de redirecionamento após o usuário autorizar o aplicativo; hospede uma página web nesta URL e capture o callback. -- `state`: O estado a ser retornado após a autorização do usuário; é uma string aleatória usada para prevenir ataques CSRF. +- `redirectUri`: O URI de redirecionamento após o usuário autorizar o aplicativo; você deve hospedar uma página web neste URL e capturar o callback. +- `state`: O estado a ser retornado após o usuário autorizar o aplicativo; é uma string aleatória usada para evitar ataques CSRF. Na resposta, você encontrará um `verificationRecordId`, guarde-o para uso posterior. @@ -299,9 +307,9 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -O `connectorData` são os dados retornados pelo conector social após a autorização do usuário; você precisa analisar e obter os parâmetros da query do `redirectUri` em sua página de callback e empacotá-los como JSON no campo `connectorData`. +O `connectorData` são os dados retornados pelo conector social após o usuário autorizar o aplicativo; você precisa analisar e obter os parâmetros de consulta do `redirectUri` em sua página de callback e empacotá-los como JSON no campo `connectorData`. -Por fim, utilize o endpoint [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) para vincular a conexão social. +Por fim, use o endpoint [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) para vincular a conexão social. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/identities \ @@ -328,23 +336,23 @@ Lembre-se de [habilitar MFA e WebAuthn](/end-user-flows/mfa) primeiro. ::: :::note -Para usar este método, é necessário habilitar o campo `mfa` nas [configurações da central de contas](#how-to-enable-account-api). +Para usar este método, você precisa habilitar o campo `mfa` nas [configurações da central da conta](#how-to-enable-account-api). ::: **Passo 1: Adicione a origem do seu app front-end às origens relacionadas** As passkeys WebAuthn são vinculadas a um hostname específico chamado **Relying Party ID (RP ID)**. Apenas aplicativos hospedados na origem do RP ID podem registrar ou autenticar com essas passkeys. -Como seu app front-end chama a Account API de um domínio diferente das páginas de autenticação do Logto, é necessário configurar **Related Origins** para permitir operações de passkey entre origens. +Como seu aplicativo front-end chama a Account API de um domínio diferente das páginas de autenticação do Logto, é necessário configurar as **Related Origins** para permitir operações de passkey entre domínios. **Como o Logto determina o RP ID:** - **Configuração padrão**: Se você usa apenas o domínio padrão do Logto `https://[tenant-id].logto.app`, o RP ID é `[tenant-id].logto.app` -- **Domínio personalizado**: Se você configurou um [domínio personalizado](/logto-cloud/custom-domain) como `https://auth.example.com`, o RP ID será `auth.example.com` +- **Domínio personalizado**: Se você configurou um [domínio personalizado](/logto-cloud/custom-domain) como `https://auth.example.com`, o RP ID passa a ser `auth.example.com` **Configurar Related Origins:** -Use o endpoint [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) para adicionar a origem do seu app front-end. Por exemplo, se a central de contas do seu app roda em `https://account.example.com`: +Use o endpoint [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) para adicionar a origem do seu app front-end. Por exemplo, se a central da conta do seu app roda em `https://account.example.com`: ```bash curl -X PATCH https://[tenant-id].logto.app/api/account-center \ @@ -353,7 +361,17 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -Para saber mais sobre origens relacionadas, consulte a documentação [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/). +:::note + +O WebAuthn suporta até 5 rótulos eTLD+1 únicos para Related Origins. O eTLD+1 (domínio de nível superior efetivo mais um rótulo) é a parte registrável do domínio. Por exemplo: + +- `https://example.com`, `https://app.example.com` e `https://auth.example.com` contam como **um** rótulo (`example.com`) +- `https://shopping.com`, `https://shopping.co.uk` e `https://shopping.co.jp` também contam como **um** rótulo (`shopping`) +- `https://example.com` e `https://another.com` contam como **dois** rótulos + +Se precisar suportar mais de 5 domínios diferentes como Related Origins, consulte a documentação [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) para detalhes. + +::: **Passo 2: Solicitar novas opções de registro** @@ -475,7 +493,7 @@ Lembre-se de [habilitar MFA e TOTP](/end-user-flows/mfa) primeiro. ::: :::note -Para usar este método, é necessário habilitar o campo `mfa` nas [configurações da central de contas](#how-to-enable-account-api). +Para usar este método, você precisa habilitar o campo `mfa` nas [configurações da central da conta](#how-to-enable-account-api). ::: **Passo 1: Gerar um segredo TOTP** @@ -496,11 +514,11 @@ O corpo da resposta será assim: } ``` -**Passo 2: Exibir o segredo TOTP ao usuário** +**Passo 2: Exibir o segredo TOTP para o usuário** -Use o segredo para gerar um QR code ou exibi-lo diretamente ao usuário. O usuário deve adicioná-lo ao seu app autenticador (como Google Authenticator, Microsoft Authenticator ou Authy). +Use o segredo para gerar um QR code ou exibi-lo diretamente ao usuário. O usuário deve adicioná-lo ao seu aplicativo autenticador (como Google Authenticator, Microsoft Authenticator ou Authy). -O formato da URI para o QR code deve ser: +O formato URI para o QR code deve ser: ``` otpauth://totp/[Emissor]:[Conta]?secret=[Segredo]&issuer=[Emissor] @@ -509,12 +527,12 @@ otpauth://totp/[Emissor]:[Conta]?secret=[Segredo]&issuer=[Emissor] Exemplo: ``` -otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp +otpauth://totp/SeuApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=SeuApp ``` **Passo 3: Vincular o fator TOTP** -Após o usuário adicionar o segredo ao app autenticador, ele deve verificá-lo e vinculá-lo à sua conta. Use o endpoint [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) para vincular o fator TOTP. +Após o usuário adicionar o segredo ao aplicativo autenticador, ele precisa verificá-lo e vinculá-lo à sua conta. Use o endpoint [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) para vincular o fator TOTP. ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -539,7 +557,7 @@ Lembre-se de [habilitar MFA e códigos de backup](/end-user-flows/mfa) primeiro. ::: :::note -Para usar este método, é necessário habilitar o campo `mfa` nas [configurações da central de contas](#how-to-enable-account-api). +Para usar este método, você precisa habilitar o campo `mfa` nas [configurações da central da conta](#how-to-enable-account-api). ::: **Passo 1: Gerar novos códigos de backup** @@ -560,9 +578,9 @@ O corpo da resposta será assim: } ``` -**Passo 2: Exibir os códigos de backup ao usuário** +**Passo 2: Exibir códigos de backup para o usuário** -Antes de vincular os códigos de backup à conta do usuário, exiba-os ao usuário e oriente-o a: +Antes de vincular os códigos de backup à conta do usuário, você deve exibi-los ao usuário e instruí-lo a: - Baixar ou anotar esses códigos imediatamente - Armazená-los em local seguro diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index e985e1a969e..52342626c12 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -14,22 +14,26 @@ Um conjunto de parâmetros de autenticação personalizados que permitem adaptar O parâmetro `first_screen` é o parâmetro chave que determina a primeira tela que os usuários verão ao serem redirecionados para a página de login do Logto. Por padrão, o formulário universal de login será exibido. Use este parâmetro para personalizar a primeira tela de acordo com os requisitos do seu aplicativo. Os valores suportados são: -- `sign_in`: Exibe o formulário de login. (Padrão) +- `sign_in` (Padrão): Exibe o formulário de login. - `register`: Exibe o formulário de cadastro. - `reset_password`: Exibe o formulário de redefinição de senha. -- `single_sign_on`: Exibe o formulário de login SSO corporativo (Enterprise SSO). (Um endereço de email será solicitado para determinar os provedores de SSO habilitados) -- `identifier:sign-in`: Exibe um formulário de login específico para o identificador. O tipo de identificador pode ser especificado usando o parâmetro `identifier`. Isso é útil quando você tem vários métodos de login por identificador habilitados. -- `identifier:register`: Exibe um formulário de cadastro específico para o identificador. O tipo de identificador pode ser especificado usando o parâmetro `identifier`. Isso é útil quando você tem vários métodos de cadastro por identificador habilitados. +- `single_sign_on`: Exibe o formulário de login do SSO corporativo (Enterprise SSO). (Um endereço de email será solicitado para determinar os provedores de SSO habilitados) +- `identifier:sign-in`: Exibe um formulário de login específico para o identificador. O tipo de identificador pode ser especificado usando o parâmetro `identifier` (opcional). Isso é útil quando você tem vários métodos de login por identificador habilitados. +- `identifier:register`: Exibe um formulário de cadastro específico para o identificador. O tipo de identificador pode ser especificado usando o parâmetro `identifier` (opcional). Isso é útil quando você tem vários métodos de cadastro por identificador habilitados. Parâmetro da primeira tela -Por exemplo, enviar usuários diretamente para o formulário de login SSO corporativo (Enterprise SSO): +Por exemplo, enviar usuários diretamente para o formulário de login do SSO corporativo (Enterprise SSO): ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +A primeira tela seguirá as configurações definidas em Console > Experiência de login. Você precisa habilitar primeiro os métodos de autenticação necessários e configurar marca, termos e políticas de privacidade, e internacionalização (i18n). Observe que apenas as páginas `sign-in` e `register` exibem o logotipo por padrão. +::: + ## identifier \{#identifier} O parâmetro `identifier` é usado para especificar os tipos de identificador que o formulário de login ou cadastro aceitará. Este parâmetro só é aplicável quando o parâmetro `first_screen` está definido como `identifier:sign-in`, `identifier:register` ou `reset_password`. Os valores suportados são: `username`, `email` e `phone`. Separe vários valores com um espaço vazio para permitir múltiplos tipos de identificador. @@ -41,13 +45,13 @@ curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=identifier:register&identifier=email phone' ``` -Todos os tipos de identificador especificados neste parâmetro devem estar habilitados nas configurações de login ou cadastro no Logto Console. +Todos os tipos de identificador especificados neste parâmetro devem estar habilitados nas suas configurações de login ou cadastro no Console do Logto. -Quaisquer tipos de identificador não suportados ou desabilitados serão ignorados. Se todos os identificadores especificados não forem suportados, a configuração padrão da experiência de login será utilizada. +Quaisquer tipos de identificador não suportados ou desabilitados serão ignorados. Se todos os identificadores especificados não forem suportados, a configuração padrão da experiência de login será usada. ## login_hint \{#login_hint} -O parâmetro `login_hint`, definido na [especificação padrão do OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint), é usado para pré-preencher o formulário de login com o identificador do usuário (como um email, número de telefone ou nome de usuário). Com o Logto, ele pode ser combinado com outros parâmetros de tela de login para aprimorar a experiência do usuário. Este parâmetro é especialmente útil se você possui um formulário de pré-autenticação personalizado que coleta o identificador do usuário antecipadamente, permitindo que ele pule a etapa de digitação durante o login. +O parâmetro `login_hint`, definido na [especificação padrão do OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint), é usado para pré-preencher o formulário de login com o identificador do usuário (como um email, número de telefone ou nome de usuário). Com o Logto, ele pode ser combinado com outros parâmetros de tela de login para aprimorar a experiência do usuário. Este parâmetro é especialmente útil se você tiver um formulário de pré-autenticação personalizado que coleta o identificador do usuário antecipadamente, permitindo que ele pule a etapa de digitação durante o login. Por exemplo, pré-preenchendo o endereço de email coletado no formulário de login: @@ -70,7 +74,7 @@ logtoClient.signIn({ ``` :::note -Estamos adicionando gradualmente suporte para os parâmetros `first_screen`, `identifier` e `login_hint` em todos os SDKs do Logto. Se você não os encontrar em seu SDK, por favor, abra uma issue ou entre em contato conosco. +Estamos adicionando gradualmente suporte aos parâmetros `first_screen`, `identifier` e `login_hint` em todos os SDKs do Logto. Se você não os encontrar em seu SDK, por favor, abra uma issue ou entre em contato conosco. Para usuários do [Logto OSS](/logto-oss), esses parâmetros são suportados desde a versão 1.15.0. Se você estiver usando uma versão mais antiga, por favor, [atualize](/logto-oss/upgrading-oss-version) para a versão mais recente. ::: diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index a25620527f7..85de8c0740a 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -9,19 +9,20 @@ O Logto suporta o parâmetro padrão de autenticação OIDC `ui_locales` para co ## O que faz \{#what-it-does} - Determina o idioma da interface da experiência de login hospedada pelo Logto em tempo de execução. O Logto seleciona a primeira tag de idioma em `ui_locales` que é suportada na biblioteca de idiomas do seu tenant. -- Afeta a localização de emails para mensagens disparadas pela interação (por exemplo, emails de código de verificação). Veja [Localização de templates de email](/connectors/email-connectors/email-templates#email-template-localization). -- Expõe o valor original para os templates de email como uma variável `uiLocales`, permitindo que você o inclua no assunto / conteúdo do email, se necessário. +- Afeta a localização dos e-mails para mensagens disparadas pela interação (por exemplo, e-mails de código de verificação). Veja [Localização de templates de e-mail](/connectors/email-connectors/email-templates#email-template-localization). +- Expõe o valor original para os templates de e-mail como uma variável `uiLocales`, permitindo incluí-lo no assunto/conteúdo do e-mail se necessário. +- Define o código de país padrão do número de telefone na experiência de login. Por exemplo, se `ui_locales=fr`, o campo de entrada do número de telefone será padrão para França (+33). Isso é útil quando você deseja controlar o código de país padrão programaticamente para grupos de usuários ou regiões específicas. ## Formato do parâmetro \{#parameter-format} - Nome: `ui_locales` - Tipo: `string` -- Valor: Lista separada por espaço de tags de idioma BCP 47, por exemplo, `fr-CA fr en`. +- Valor: Lista separada por espaços de tags de idioma BCP 47, por exemplo, `fr-CA fr en`. - Referência: [OpenID Connect Core - ui_locales](https://openid.net/specs/openid-connect-core-1_0.html) ## Ordem de resolução e precedência \{#resolution-order-and-precedence} -Ao determinar o idioma da interface para a experiência de login e emails relacionados, o Logto resolve o idioma do usuário final nesta ordem: +Ao determinar o idioma da interface para a experiência de login e e-mails relacionados, o Logto resolve o idioma do usuário final nesta ordem: 1. `ui_locales` da solicitação de autenticação atual (a primeira tag suportada vence). 2. Caso contrário, cabeçalho `Accept-Language` (Experience APIs / User Account APIs) ou `messagePayload.locale` (Management APIs como convites de organização). @@ -44,11 +45,11 @@ await logtoClient.signIn({ ## Exemplos \{#examples} -- `ui_locales=fr-CA fr en` → Se `fr-CA` existir na sua biblioteca de idiomas, a interface de login será exibida em francês (Canadá); caso contrário, recai para `fr`, depois `en`. -- `ui_locales=ja` mas japonês não está habilitado → Recorre ao `Accept-Language` ou ao padrão do tenant. +- `ui_locales=fr-CA fr en` → Se `fr-CA` existir na sua biblioteca de idiomas, a interface de login será exibida em francês (Canadá); caso contrário, será feito fallback para `fr`, depois `en`. +- `ui_locales=ja` mas japonês não está habilitado → Fallback para `Accept-Language` ou idioma padrão do tenant. ## Relacionados \{#related} - [Idiomas localizados](/customization/localized-languages) -- [Templates de email](/connectors/email-connectors/email-templates#email-template-localization) +- [Templates de e-mail](/connectors/email-connectors/email-templates#email-template-localization) - [Parâmetros de autenticação](/end-user-flows/authentication-parameters) diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index 7d4b4f32321..2f4111164d7 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -4,43 +4,44 @@ sidebar_position: 2 # Login por email / telefone / nome de usuário -## Configurar o fluxo de login por identificador \{#configure-the-identifier-sign-in-flow} +## Configure o fluxo de login por identificador \{#configure-the-identifier-sign-in-flow} -Como mencionado anteriormente, vários tipos de identificadores podem ser coletados dos usuários ao longo do [fluxo de inscrição](/end-user-flows/sign-up-and-sign-in/sign-up) ou [criação direta de conta no Logto](/user-management/manage-users#add-users). Além disso, os usuários podem inserir e completar informações adicionais à medida que exploram e utilizam o produto. Esses identificadores podem ser usados para identificar exclusivamente os usuários no sistema do Logto e permitir que eles sejam autenticados e façam login nos aplicativos integrados ao Logto. +Como mencionado anteriormente, vários tipos de identificadores podem ser coletados dos usuários durante o [fluxo de cadastro](/end-user-flows/sign-up-and-sign-in/sign-up) ou [criação direta de conta no Logto](/user-management/manage-users#add-users). Além disso, os usuários podem inserir e completar informações adicionais à medida que exploram e utilizam o produto. Esses identificadores podem ser usados para identificar exclusivamente os usuários no sistema do Logto e permitir que sejam autenticados e façam login nos aplicativos integrados ao Logto. -Seja escolhendo usar a página de login pré-construída hospedada pelo Logto ou planejando [construir sua própria interface de login personalizada](/customization#custom-ui), você precisará configurar os métodos de login disponíveis e as configurações de verificação para seus usuários finais. +Seja utilizando a página de login pré-construída hospedada pelo Logto ou planejando [construir sua própria interface de login personalizada](/customization#custom-ui), você precisará configurar os métodos de login disponíveis e as configurações de verificação para seus usuários finais. -## Configurar as configurações de identificador e autenticação \{#set-up-the-identifier-and-authentication-settings} +## Configure os identificadores e as configurações de autenticação \{#set-up-the-identifier-and-authentication-settings} -### 1. Definir os identificadores de login suportados \{#1-set-the-supported-sign-in-identifiers} +### 1. Defina os identificadores de login suportados \{#1-set-the-supported-sign-in-identifiers} -Você pode adicionar vários identificadores suportados a partir da lista suspensa como métodos de login habilitados para usuários finais. As opções disponíveis são: +Você pode adicionar vários identificadores suportados a partir da lista suspensa como métodos de login habilitados para os usuários finais. As opções disponíveis são: - **Nome de usuário** - **Endereço de email** - **Número de telefone** -Reordenar os identificadores mudará a ordem em que são exibidos na página de login. O primeiro identificador será o método de login principal para os usuários. +Reordenar os identificadores mudará a ordem em que são exibidos na página de login. O primeiro identificador será o método principal de login para os usuários. -### 2. Definir as configurações de autenticação \{#2-set-the-authentication-settings} +### 2. Defina as configurações de autenticação \{#2-set-the-authentication-settings} Para cada identificador de login, você precisará configurar pelo menos um fator de verificação eficaz para verificar a identidade do usuário. Existem dois fatores que você pode escolher: -- **Senha**: Disponível para todos os tipos de identificadores de login. Uma vez habilitado, os usuários devem fornecer uma senha para completar o processo de login. -- **Código de verificação**: Disponível apenas para identificadores de **Endereço de email** e **Número de telefone**. Uma vez habilitado, os usuários devem inserir um código de verificação enviado para seu email ou número de telefone para completar o processo de login. +- **Senha**: Disponível para todos os tipos de identificadores de login. Uma vez habilitado, os usuários devem fornecer uma senha para concluir o processo de login. +- **Código de verificação**: Disponível apenas para os identificadores **Endereço de email** e **Número de telefone**. Uma vez habilitado, os usuários devem inserir um código de verificação enviado para seu email ou número de telefone para concluir o processo de login. -Se ambos os fatores estiverem habilitados, os usuários podem escolher qualquer método para completar o processo de login. Você também pode reordenar os fatores para mudar a ordem em que são exibidos na página de login. O primeiro fator será usado como o método de verificação principal para os usuários e o segundo será exibido como um link alternativo. +Se ambos os fatores estiverem habilitados, os usuários podem escolher qualquer um dos métodos para concluir o processo de login. Você também pode reordenar os fatores para alterar a ordem em que são exibidos na página de login. O primeiro fator será usado como método principal de verificação para os usuários e o segundo será exibido como um link alternativo. ## Experiência do usuário no fluxo de login por identificador \{#identifier-sign-in-flow-user-experience} A experiência de login se adapta com base no identificador escolhido e nos fatores de autenticação disponíveis. - **Entrada inteligente para múltiplos identificadores:** - Se mais de um método de login por identificador estiver habilitado, a página de login integrada do Logto detectará automaticamente o tipo de identificador inserido pelo usuário e exibirá as opções de verificação correspondentes. Por exemplo, se tanto **Endereço de email** quanto **Número de telefone** estiverem habilitados, a página de login detectará automaticamente o tipo de identificador inserido pelo usuário e exibirá as opções de verificação correspondentes. Ela muda para um formato de número de telefone com código de região se números forem inseridos consecutivamente ou um formato de email quando um símbolo “@” for usado. + Se mais de um método de login por identificador estiver habilitado, a página de login incorporada do Logto detectará automaticamente o tipo de identificador inserido pelo usuário e exibirá as opções de verificação correspondentes. Por exemplo, se tanto **Endereço de email** quanto **Número de telefone** estiverem habilitados, a página de login detectará automaticamente o tipo de identificador inserido pelo usuário e exibirá as opções de verificação correspondentes. Ela alterna para o formato de número de telefone com código de região se números forem inseridos consecutivamente ou para o formato de email quando um símbolo "@" for usado. + - O código do país do número de telefone é definido por padrão de acordo com o idioma do navegador do usuário; os usuários podem alterar manualmente. Você pode usar o parâmetro [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) para definir um código de país padrão específico. Veja [Idiomas localizados](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience) para mais detalhes. - **Fatores de verificação habilitados:** - - **Apenas senha:** Tanto os campos de identificador quanto de senha serão exibidos na primeira tela. + - **Apenas senha:** Os campos de identificador e senha serão exibidos na primeira tela. - **Apenas código de verificação:** O campo de identificador aparece na primeira tela, seguido pelo campo de código de verificação na segunda tela. - - **Senha e código de verificação:** O campo de identificador é inserido inicialmente na primeira tela, seguido por etapas para inserir a senha ou o código de verificação na segunda tela com base na ordem de verificação. Um link de alternância é fornecido para permitir que os usuários alternem entre os dois métodos de verificação. + - **Senha e código de verificação:** O campo de identificador é inserido inicialmente na primeira tela, seguido pelos passos para inserir a senha ou o código de verificação na segunda tela, conforme a ordem de verificação. Um link de alternância é fornecido para permitir que os usuários alternem entre os dois métodos de verificação. ### Exemplos \{#examples} @@ -51,7 +52,7 @@ A experiência de login se adapta com base no identificador escolhido e nos fato -Adicione o **Endereço de email** como o identificador de login e habilite o fator **Senha** para verificação. +Adicione o **Endereço de email** como identificador de login e habilite o fator **Senha** para verificação. -### Exemplo 2: Email/Telefone com verificação por senha (primária) e código de verificação (alternativa) habilitada \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} +### Exemplo 2: Email/Telefone com senha (primário) e código de verificação (alternativo) habilitados \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} -Adicione tanto **Endereço de email** quanto **Número de telefone** como os identificadores de login. +Adicione tanto o **Endereço de email** quanto o **Número de telefone** como identificadores de login. Habilite os fatores **Senha** e **Código de verificação** para ambos os identificadores. -## Coletar perfil adicional do usuário no login \{#collect-additional-user-profile-on-sign-in} +## Coletar informações adicionais do perfil do usuário no login \{#collect-additional-user-profile-on-sign-in} -No fluxo de login do Logto, um processo de preenchimento de perfil pode ser acionado se as configurações de identificador de inscrição forem atualizadas. Isso garante que todos os usuários, incluindo os existentes, forneçam quaisquer identificadores recém-requeridos. +No fluxo de login do Logto, um processo de preenchimento de perfil pode ser acionado se as configurações de identificador de cadastro forem atualizadas. Isso garante que todos os usuários, inclusive os já existentes, forneçam quaisquer identificadores recém-exigidos. -Quando um desenvolvedor adiciona um novo identificador (como um endereço de email), ele se torna obrigatório para todos os usuários. Se um usuário retornando fizer login com um identificador existente (como um nome de usuário), ele será solicitado a fornecer e verificar o novo identificador se estiver faltando em seu perfil. Somente após completar esta etapa, ele poderá acessar o aplicativo, garantindo uma transição suave e consistente para os requisitos atualizados. +Quando um desenvolvedor adiciona um novo identificador (como um endereço de email), ele se torna obrigatório para todos os usuários. Se um usuário recorrente fizer login com um identificador existente (como um nome de usuário), será solicitado que forneça e verifique o novo identificador caso ele esteja ausente em seu perfil. Somente após concluir essa etapa ele poderá acessar o aplicativo, garantindo uma transição suave e consistente para os novos requisitos. -Desmembrando o processo: +Detalhando o processo: -1. **Nome de usuário** foi previamente definido como o identificador de inscrição com a configuração **Crie sua senha** habilitada automaticamente. -2. **Endereço de email** é posteriormente definido como o identificador de inscrição. O identificador **Endereço de email** é automaticamente adicionado como uma opção de login habilitada. -3. Um usuário retornando faz login com seu nome de usuário e senha. -4. O usuário é solicitado a fornecer e verificar um endereço de email após sua etapa inicial de login. +1. **Nome de usuário** foi previamente definido como identificador de cadastro com a configuração **Crie sua senha** habilitada automaticamente. +2. **Endereço de email** é posteriormente definido como identificador de cadastro. O identificador **Endereço de email** é automaticamente adicionado como uma opção de login habilitada. +3. Um usuário recorrente faz login com seu nome de usuário e senha. +4. O usuário é solicitado a fornecer e verificar um endereço de email após a etapa inicial de login. ```mermaid flowchart TD A[Visitar página de login] --> B[Inserir nome de usuário e senha] - B -.-> C{{Endereço de email necessário e ausente?}} + B -.-> C{{Endereço de email obrigatório e ausente?}} C -->|Sim| D[Inserir endereço de email] D --> E[Inserir código de verificação] E --> F[Login bem-sucedido] C --> |Não| F ``` -O mesmo processo se aplica às configurações de inscrição **Crie sua senha** também. Se as configurações **Crie sua senha** forem recém-habilitadas no fluxo de inscrição, o fator **Senha** será automaticamente habilitado para todos os identificadores de login que você escolher. Todos os usuários retornando sem uma senha serão solicitados a criar uma durante o processo de login. +O mesmo processo se aplica às configurações de cadastro **Crie sua senha**. Se as configurações **Crie sua senha** forem habilitadas recentemente no fluxo de cadastro, o fator **Senha** será automaticamente habilitado para todos os identificadores de login que você escolher. Todos os usuários recorrentes sem senha serão solicitados a criar uma durante o processo de login. :::note -Nota: Para fluxos de login personalizados, consulte o recurso de [Traga sua UI](/customization/bring-your-ui/). +Nota: Para fluxos de login personalizados, consulte o recurso [Traga sua UI](/customization/bring-your-ui/). ::: -## FAQs \{#faqs} +## Perguntas frequentes \{#faqs}
-### Experiência de login auto-hospedada (login embutido) \{#self-hosted-sign-in-experience-embedded-sign-in} +### Experiência de login auto-hospedada (login incorporado) \{#self-hosted-sign-in-experience-embedded-sign-in} -O Logto atualmente não suporta API sem interface para login e inscrição. No entanto, você pode usar nosso recurso [Traga sua UI](/customization/bring-your-ui/) para carregar seu formulário de login personalizado no Logto. Também suportamos múltiplos parâmetros de login que você pode usar para pré-preencher o formulário de login com o identificador do usuário coletado do seu aplicativo ou fazer login diretamente com um provedor de SSO social ou corporativo de terceiros. Saiba mais em [Parâmetros de autenticação](/end-user-flows/authentication-parameters/). +O Logto atualmente não oferece suporte a API headless para login e cadastro. No entanto, você pode usar o recurso [Traga sua UI](/customization/bring-your-ui/) para enviar seu formulário de login personalizado ao Logto. Também oferecemos suporte a vários parâmetros de login que você pode usar para pré-preencher o formulário de login com o identificador do usuário coletado do seu aplicativo ou fazer login diretamente com um provedor de login social ou SSO corporativo de terceiros. Saiba mais em [Parâmetros de autenticação](/end-user-flows/authentication-parameters/).
## Recursos relacionados \{#related-resources} - Experiência de inscrição e login por email + Experiência de cadastro e login por email - Experiência de inscrição e login por nome de usuário + Experiência de cadastro e login por nome de usuário diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index 19eaf96856e..178133e7ecc 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -14,23 +14,33 @@ Acesse Console > Experi Para criar com sucesso uma nova conta de usuário no Logto, os usuários devem fornecer pelo menos um **identificador** que os identifique de forma única dentro do sistema do Logto. Como primeiro passo, selecione os identificadores que os usuários devem fornecer durante o processo de cadastro. As opções disponíveis são: -- **Nome de usuário (Username)**: Um [nome de usuário](/user-management/user-data#username) exclusivo que o usuário pode usar para fazer login no aplicativo. -- **Endereço de email (Email address)**: Um [endereço de email](/user-management/user-data#primary_email) válido que o usuário pode usar para fazer login no aplicativo. -- **Número de telefone (Phone number)**: Um [número de telefone](/user-management/user-data#primary_phone) válido que o usuário pode usar para fazer login no aplicativo. -- **Endereço de email ou número de telefone (Email address or phone number)**: Permite que os usuários se cadastrem com um endereço de email válido ou número de telefone. +- **Nome de usuário**: Um [nome de usuário](/user-management/user-data#username) exclusivo que o usuário pode usar para fazer login no aplicativo. +- **Endereço de email**: Um [endereço de email](/user-management/user-data#primary_email) válido que o usuário pode usar para fazer login no aplicativo. +- **Número de telefone**: Um [número de telefone](/user-management/user-data#primary_phone) válido que o usuário pode usar para fazer login no aplicativo. +- **Endereço de email ou número de telefone**: Permite que os usuários se cadastrem com um endereço de email válido ou número de telefone. -Todos os identificadores coletados durante o processo de cadastro devem ser exclusivos entre os usuários sob o mesmo tenant. Eles serão armazenados no [perfil do usuário](/user-management/user-data#user-profile) e podem ser usados para fazer login nos aplicativos integrados ao Logto. +Todos os identificadores coletados durante o processo de cadastro devem ser exclusivos entre os usuários do mesmo tenant. Eles serão armazenados no [perfil do usuário](/user-management/user-data#user-profile) e podem ser usados para login nos aplicativos integrados ao Logto. -Se nenhum identificador for selecionado, aplica-se aos métodos de cadastro [social](/end-user-flows/sign-up-and-sign-in/social-sign-in) ou [SSO corporativo (Enterprise SSO)](/end-user-flows/enterprise-sso) apenas. +Se nenhum identificador for selecionado, aplica-se aos métodos de cadastro [social](/end-user-flows/sign-up-and-sign-in/social-sign-in) ou [SSO corporativo (Enterprise SSO)](/end-user-flows/enterprise-sso) exclusivamente. Você pode ajustar a ordem dos identificadores de cadastro para priorizar aquele que deseja que os usuários forneçam primeiro durante o cadastro. Essa ordem é refletida no processo de cadastro, onde o primeiro identificador aparece na tela inicial de registro e os demais são coletados nas etapas seguintes. -## Configurar as definições de verificação de cadastro \{#set-up-the-sign-up-verification-settings} +:::tip +Para bloquear tipos específicos de endereços de email durante o cadastro (como emails descartáveis, subendereçamento com sinal de mais (+), endereços de email específicos ou domínios inteiros), use o recurso **blocklist** na seção de Segurança. Veja [Blocklist](/security/blocklist) para mais detalhes. +::: + +:::tip +O **código do país** do número de telefone é definido por padrão de acordo com o idioma do navegador do usuário. Por exemplo, se o idioma do navegador do usuário estiver definido como `fr`, o código do país será definido como França (+33). + +Você também pode usar o parâmetro de autenticação [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) para definir o idioma da experiência de login, o que também determinará o código do país padrão. +::: + +## Configurar as opções de verificação do cadastro \{#set-up-the-sign-up-verification-settings} -Para garantir a segurança do cadastro e do futuro processo de login do usuário, você também precisa configurar as definições de verificação para os identificadores coletados durante o cadastro. As configurações disponíveis são: +Para garantir a segurança do cadastro e do futuro processo de login do usuário, você também precisa configurar as opções de verificação para os identificadores coletados durante o cadastro. As opções disponíveis são: -- **Criar sua senha:** Exige que os usuários criem uma senha durante o cadastro que esteja em conformidade com a política de senha configurada nas definições de experiência de login. Essa senha, juntamente com o identificador do usuário, serve como credencial para login no aplicativo. Se você definir **Nome de usuário (Username)** como identificador de cadastro, esse requisito é ativado automaticamente, pois o **Nome de usuário** só pode ser usado com uma senha para verificar efetivamente a identidade do usuário. A [política de senha](/security/password-policy) pode ser personalizada para atender aos seus requisitos de segurança. -- **Verificar no cadastro (Verify at sign-up)**: Exige que os usuários verifiquem seu endereço de email ou número de telefone durante o cadastro. Atualmente, o Logto só aceita emails e números de telefone verificados como identificadores. Essa configuração é ativada automaticamente quando **Endereço de email (Email address)** ou **Número de telefone (Phone number)** é usado como identificador de cadastro. Os usuários devem confirmar a posse inserindo um código de verificação enviado ao email ou número de telefone durante o processo de cadastro. +- **Criar sua senha:** Exige que os usuários criem uma senha durante o cadastro que esteja em conformidade com a política de senha configurada nas configurações de experiência de login. Essa senha, juntamente com o identificador do usuário, serve como credencial para login no aplicativo. Se você definir **Nome de usuário** como identificador de cadastro, esse requisito é ativado automaticamente, pois o **Nome de usuário** só pode ser usado com senha para verificar efetivamente a identidade do usuário. A [política de senha](/security/password-policy) pode ser personalizada para atender aos seus requisitos de segurança. +- **Verificar no cadastro**: Exige que os usuários verifiquem seu endereço de email ou número de telefone durante o cadastro. Atualmente, o Logto só aceita emails e números de telefone verificados como identificadores. Essa opção é ativada automaticamente quando **Endereço de email** ou **Número de telefone** é usado como identificador de cadastro. Os usuários devem confirmar a posse inserindo um código de verificação enviado ao email ou telefone durante o processo de cadastro. | Identificador | Criar senha do usuário | Verificar no cadastro | | ------------------ | ---------------------- | --------------------- | @@ -39,7 +49,7 @@ Para garantir a segurança do cadastro e do futuro processo de login do usuário | Número de telefone | Opcional | Obrigatório | | Email ou telefone | Opcional | Obrigatório | -## Exemplos de fluxos de cadastro \{#sign-up-flow-examples} +## Exemplos de fluxo de cadastro \{#sign-up-flow-examples}
@@ -48,7 +58,7 @@ Para garantir a segurança do cadastro e do futuro processo de login do usuário -Selecione o **Nome de usuário (Username)** como identificador de cadastro. Criar sua senha é ativado automaticamente. +Selecione o **Nome de usuário** como identificador de cadastro. A opção Criar sua senha é ativada automaticamente. Cadastro por nome de usuário e senha @@ -57,11 +67,11 @@ Selecione o **Nome de usuário (Username)** como identificador de cadastro. Cria
-### Tipo 2: Endereço de email ou número de telefone com fluxo de verificação \{#type-2-email-address-or-phone-number-with-verification-flow} +### Tipo 2: Endereço de email ou número de telefone com verificação \{#type-2-email-address-or-phone-number-with-verification-flow} -Selecione **Endereço de email ou número de telefone (Email address or phone number)** como identificador de cadastro. **Verificar no cadastro (Verify at sign-up)** é forçado a ser ativado. +Selecione **Endereço de email ou número de telefone** como identificador de cadastro. **Verificar no cadastro** é ativado obrigatoriamente. -Selecione **Endereço de email (Email address)** como identificador de cadastro. **Verificar no cadastro (Verify at sign-up)** é forçado a ser ativado. Ative **Criar sua senha** para exigir que os usuários criem uma senha durante o cadastro. (O mesmo se aplica ao fluxo de cadastro por número de telefone) +Selecione **Endereço de email** como identificador de cadastro. **Verificar no cadastro** é ativado obrigatoriamente. Ative **Criar sua senha** para exigir que os usuários criem uma senha durante o cadastro. (O mesmo se aplica ao fluxo de cadastro por número de telefone) -Selecione **Endereço de email (Email address)** e **Nome de usuário (Username)** como identificadores de cadastro. **Verificar no cadastro (Verify at sign-up)** é forçado a ser ativado. Ative **Criar sua senha** para exigir que os usuários criem uma senha durante o cadastro. +Selecione **Endereço de email** e **Nome de usuário** como identificadores de cadastro. **Verificar no cadastro** é ativado obrigatoriamente. Ative **Criar sua senha** para exigir que os usuários criem uma senha durante o cadastro. Console > Experiência de login > Coletar perfil do usuário para escolher entre campos de dados básicos pré-configurados ou criar campos personalizados com validação flexível. Saiba mais: [Coletar perfil do usuário](/end-user-flows/collect-user-profile) +Configure a coleta de perfil em Console > Experiência de login > Coletar perfil do usuário para escolher entre campos básicos pré-configurados ou criar campos personalizados com validação flexível. Saiba mais: [Coletar perfil do usuário](/end-user-flows/collect-user-profile) **Opção 2: Fluxos de onboarding auto-hospedados** -Redirecione os usuários para seu próprio fluxo de onboarding personalizado após o cadastro bem-sucedido para uma coleta de dados totalmente personalizável. Essa abordagem oferece controle total sobre a experiência do usuário e permite processos de onboarding complexos e em várias etapas. +Redirecione os usuários para seu próprio fluxo de onboarding personalizado após o cadastro bem-sucedido para uma coleta de dados totalmente customizável. Essa abordagem oferece controle total sobre a experiência do usuário e permite processos de onboarding complexos e com várias etapas. Use a [Account API](/end-user-flows/account-settings/by-account-api) para gerenciar dados do perfil do usuário programaticamente. @@ -139,7 +149,7 @@ Use a [Account API](/end-user-flows/account-settings/by-account-api) para gerenc -Saiba como implementar o [fluxo de cadastro apenas por convite.](/end-user-flows/sign-up-and-sign-in/disable-user-registration/#implement-an-invitation-only-sign-up-flow) +Saiba como implementar o [fluxo de cadastro somente por convite.](/end-user-flows/sign-up-and-sign-in/disable-user-registration/#implement-an-invitation-only-sign-up-flow)
@@ -150,18 +160,18 @@ Saiba como implementar o [fluxo de cadastro apenas por convite.](/end-user-flows -O Logto atualmente não oferece suporte a API headless para login e cadastro. Você pode usar o recurso [Traga sua UI (Bring your UI)](/customization/bring-your-ui/) para enviar seu próprio formulário de cadastro ao Logto ou usar os parâmetros de login para preencher informações do usuário no Logto a partir do seu site. Saiba mais sobre o preenchimento do identificador do usuário em [Parâmetros de autenticação](/end-user-flows/authentication-parameters/). +O Logto atualmente não oferece suporte a API headless para login e cadastro. Você pode usar o recurso [Traga sua UI](/customization/bring-your-ui/) para enviar seu próprio formulário de cadastro ao Logto ou usar os parâmetros de login para preencher informações do usuário do seu site para o Logto. Saiba mais sobre o preenchimento do identificador do usuário em [Parâmetros de autenticação](/end-user-flows/authentication-parameters/).
-### Enviando emails de boas-vindas para novos usuários \{#sending-welcome-emails-to-new-users} +### Envio de emails de boas-vindas para novos usuários \{#sending-welcome-emails-to-new-users} -Assine o evento webhook `User.Created` para acionar um email de boas-vindas para novos usuários. Saiba mais sobre [eventos de webhook](/developers/webhooks/webhooks-events/#data-mutation-hook-events). +Assine o evento webhook `User.Created` para acionar o envio de email de boas-vindas para novos usuários. Saiba mais sobre [eventos de webhook](/developers/webhooks/webhooks-events/#data-mutation-hook-events).
@@ -173,7 +183,7 @@ Assine o evento webhook `User.Created` para acionar um email de boas-vindas para Atualmente, o Logto só aceita emails e números de telefone verificados como identificadores. O processo de verificação é obrigatório para garantir a segurança e a posse do identificador do usuário. -O suporte para emails ou números de telefone não verificados está em nosso [roadmap](https://feedback.logto.io/roadmap). Fique atento para novidades! +O suporte a emails ou números de telefone não verificados está em nosso [roadmap](https://feedback.logto.io/roadmap). Fique atento para novidades! diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 6debfeb7df6..6ad8a651e78 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,117 +1,121 @@ --- -description: Consulte os principais parâmetros de aplicação para integração de autenticação OIDC, incluindo URIs de redirecionamento, endpoints, tokens de atualização, logout de backchannel, etc. +description: Consulte os principais parâmetros de aplicativo para integração de autenticação OIDC, incluindo URIs de redirecionamento, endpoints, tokens de atualização, logout backchannel, etc. sidebar_position: 6 --- -# Estrutura de dados da aplicação +# Estrutura de dados do aplicativo ## Introdução \{#introduction} -No Logto, uma _aplicação_ refere-se a um programa de software ou serviço específico que está registrado na plataforma Logto e recebeu autorização para acessar informações do usuário ou realizar ações em nome de um usuário. As aplicações são usadas para identificar a origem das solicitações feitas à API do Logto, bem como para gerenciar o processo de autenticação e autorização para usuários que acessam essas aplicações. +No Logto, um _aplicativo_ refere-se a um programa de software ou serviço específico que está registrado na plataforma Logto e recebeu autorização para acessar informações do usuário ou realizar ações em nome de um usuário. Os aplicativos são usados para identificar a origem das solicitações feitas à API do Logto, bem como para gerenciar o processo de autenticação e autorização para os usuários que acessam esses aplicativos. -O uso de aplicações na experiência de login do Logto permite que os usuários acessem e gerenciem facilmente suas aplicações autorizadas a partir de um único local, com um processo de autenticação consistente e seguro. Isso ajuda a simplificar a experiência do usuário e garante que apenas indivíduos autorizados estejam acessando informações sensíveis ou realizando ações em nome da organização. +O uso de aplicativos na experiência de login do Logto permite que os usuários acessem e gerenciem facilmente seus aplicativos autorizados a partir de um único local, com um processo de autenticação consistente e seguro. Isso ajuda a simplificar a experiência do usuário e garante que apenas pessoas autorizadas estejam acessando informações sensíveis ou realizando ações em nome da organização. -As aplicações também são usadas nos logs de auditoria do Logto para rastrear a atividade do usuário e identificar quaisquer ameaças ou violações de segurança potenciais. Ao associar ações específicas a uma aplicação em particular, o Logto pode fornecer insights detalhados sobre como os dados estão sendo acessados e usados, permitindo que as organizações gerenciem melhor seus requisitos de segurança e conformidade. -Se você deseja integrar sua aplicação com o Logto, veja [Integrar Logto](/integrate-logto). +Os aplicativos também são usados nos logs de auditoria do Logto para rastrear a atividade do usuário e identificar possíveis ameaças ou violações de segurança. Ao associar ações específicas a um determinado aplicativo, o Logto pode fornecer insights detalhados sobre como os dados estão sendo acessados e utilizados, permitindo que as organizações gerenciem melhor seus requisitos de segurança e conformidade. +Se você deseja integrar seu aplicativo ao Logto, veja [Integrar Logto](/integrate-logto). ## Propriedades \{#properties} -### ID da aplicação \{#application-id} +### ID do aplicativo \{#application-id} -_ID da aplicação_ é uma chave única gerada automaticamente para identificar sua aplicação no Logto e é referenciada como [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) no OAuth 2.0. +_O ID do aplicativo_ é uma chave única gerada automaticamente para identificar seu aplicativo no Logto, e é referenciado como [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) no OAuth 2.0. -### Tipos de aplicação \{#application-types} +### Tipos de aplicativo \{#application-types} -Uma _Aplicação_ pode ser um dos seguintes tipos de aplicação: +Um _aplicativo_ pode ser um dos seguintes tipos de aplicativo: - **Aplicativo nativo** é um aplicativo que roda em um ambiente nativo. Ex.: aplicativo iOS, aplicativo Android. -- **Aplicativo de página única** é um aplicativo que roda em um navegador web, que atualiza a página com os novos dados do servidor sem carregar páginas inteiras novas. Ex.: aplicativo React DOM, aplicativo Vue. +- **Aplicativo de página única (SPA)** é um aplicativo que roda em um navegador web, que atualiza a página com novos dados do servidor sem carregar páginas inteiras novas. Ex.: aplicativo React DOM, aplicativo Vue. - **Aplicativo web tradicional** é um aplicativo que renderiza e atualiza páginas apenas pelo servidor web. Ex.: JSP, PHP. -- **Aplicativo máquina para máquina (M2M)** é um aplicativo que roda em um ambiente de máquina para comunicação direta de serviço para serviço sem interação do usuário. +- **Aplicativo máquina para máquina (M2M)** é um aplicativo que roda em um ambiente de máquina para comunicação direta entre serviços, sem interação do usuário. -### Segredo da aplicação \{#application-secret} +### Segredo do aplicativo \{#application-secret} -_Segredo da aplicação_ é uma chave usada para autenticar a aplicação no sistema de autenticação, especificamente para clientes privados (aplicativos Web Tradicionais e M2M) como uma barreira de segurança privada. +_O segredo do aplicativo_ é uma chave usada para autenticar o aplicativo no sistema de autenticação, especificamente para clientes privados (aplicativos Web tradicionais e M2M) como uma barreira de segurança privada. -### Nome da aplicação \{#application-name} +:::tip +Aplicativos de página única (SPAs) e aplicativos nativos não fornecem segredo do aplicativo. SPAs e aplicativos nativos são "clientes públicos" e não podem manter segredos (o código do navegador ou os pacotes do aplicativo podem ser inspecionados). Em vez de um segredo do aplicativo, o Logto os protege com PKCE, validação rigorosa de URI de redirecionamento / CORS, tokens de acesso de curta duração e rotação de token de atualização. +::: + +### Nome do aplicativo \{#application-name} -_Nome da aplicação_ é um nome legível por humanos da aplicação e será exibido no console de administração. +_O nome do aplicativo_ é um nome legível por humanos do aplicativo e será exibido no console de administração. -O _Nome da aplicação_ é um componente importante do gerenciamento de aplicações no Logto, pois permite que os administradores identifiquem e rastreiem facilmente a atividade de aplicações individuais dentro da plataforma. +O _nome do aplicativo_ é um componente importante do gerenciamento de aplicativos no Logto, pois permite que os administradores identifiquem e acompanhem facilmente a atividade de aplicativos individuais dentro da plataforma. :::note -É importante notar que o _Nome da aplicação_ deve ser escolhido cuidadosamente, pois será visível para todos os usuários que têm acesso ao console de administração. Ele deve refletir com precisão o propósito e a função da aplicação, além de ser fácil de entender e reconhecer. +É importante observar que o _nome do aplicativo_ deve ser escolhido com cuidado, pois será visível para todos os usuários que têm acesso ao console de administração. Ele deve refletir com precisão o propósito e a função do aplicativo, além de ser fácil de entender e reconhecer. ::: ### Descrição \{#description} -Uma breve descrição da aplicação será exibida na página de detalhes da aplicação no console de administração. A descrição destina-se a fornecer aos administradores informações adicionais sobre a aplicação, como seu propósito, funcionalidade e quaisquer outros detalhes relevantes. +Uma breve descrição do aplicativo será exibida na página de detalhes do aplicativo no console de administração. A descrição tem como objetivo fornecer aos administradores informações adicionais sobre o aplicativo, como seu propósito, funcionalidade e quaisquer outros detalhes relevantes. ### URIs de redirecionamento \{#redirect-uris} -_URIs de redirecionamento_ são uma lista de URIs de redirecionamento válidos que foram pré-configurados para uma aplicação. Quando um usuário faz login no Logto e tenta acessar a aplicação, ele é redirecionado para um dos URIs permitidos especificados nas configurações da aplicação. +_URIs de redirecionamento_ são uma lista de URIs de redirecionamento válidas que foram pré-configuradas para um aplicativo. Quando um usuário faz login no Logto e tenta acessar o aplicativo, ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo. -A lista de URIs permitidos é usada para validar o URI de redirecionamento que está incluído na solicitação de autorização enviada pela aplicação ao Logto durante o processo de autenticação. Se o URI de redirecionamento especificado na solicitação de autorização corresponder a um dos URIs permitidos nas configurações da aplicação, o usuário é redirecionado para esse URI após a autenticação bem-sucedida. Se o URI de redirecionamento não estiver na lista permitida, o usuário não será redirecionado e o processo de autenticação falhará. +A lista de URIs permitidas é usada para validar o URI de redirecionamento incluído na solicitação de autorização enviada pelo aplicativo ao Logto durante o processo de autenticação. Se o URI de redirecionamento especificado na solicitação de autorização corresponder a um dos URIs permitidos nas configurações do aplicativo, o usuário será redirecionado para esse URI após a autenticação bem-sucedida. Se o URI de redirecionamento não estiver na lista permitida, o usuário não será redirecionado e o processo de autenticação falhará. :::note -É importante garantir que todos os URIs de redirecionamento válidos sejam adicionados à lista permitida para uma aplicação no Logto, a fim de garantir que os usuários possam acessar a aplicação com sucesso após a autenticação. +É importante garantir que todos os URIs de redirecionamento válidos sejam adicionados à lista permitida para um aplicativo no Logto, para garantir que os usuários possam acessar o aplicativo com sucesso após a autenticação. ::: -Você pode conferir o [Endpoint de redirecionamento](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) para mais informações. +Você pode conferir o [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) para mais informações. - Entendendo URIs de redirecionamento em OIDC com Fluxo de Código de Autorização + Compreendendo URIs de redirecionamento em OIDC com Authorization Code Flow ### URIs de redirecionamento pós logout \{#post-sign-out-redirect-uris} -_URIs de redirecionamento pós logout_ são uma lista de URIs válidos que foram pré-configurados para uma aplicação redirecionar o usuário após ele ter feito logout do Logto. +_URIs de redirecionamento pós logout_ são uma lista de URIs válidas que foram pré-configuradas para um aplicativo redirecionar o usuário após ele sair do Logto. -O uso de _URIs de redirecionamento pós logout_ permitidos para Logout faz parte da especificação de Logout Iniciado pela RP (Relying Party Initiated) no OIDC. Esta especificação fornece um método padronizado para aplicações iniciarem uma solicitação de logout para um usuário, o que inclui redirecionar o usuário para um endpoint pré-configurado após ele ter feito logout. +O uso de _URIs de redirecionamento pós logout_ permitidas para logout faz parte da especificação de logout iniciado pela RP (Relying Party Initiated) no OIDC. Essa especificação fornece um método padronizado para os aplicativos iniciarem uma solicitação de logout para um usuário, que inclui redirecionar o usuário para um endpoint pré-configurado após ele sair. -Quando um usuário faz logout do Logto, sua sessão é encerrada e ele é redirecionado para um dos URIs permitidos especificados nas configurações da aplicação. Isso garante que o usuário seja direcionado apenas para endpoints autorizados e válidos após ter feito logout, ajudando a prevenir acesso não autorizado e riscos de segurança associados ao redirecionamento de usuários para endpoints desconhecidos ou não verificados. +Quando um usuário sai do Logto, sua sessão é encerrada e ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo. Isso garante que o usuário seja direcionado apenas para endpoints autorizados e válidos após sair, ajudando a evitar acessos não autorizados e riscos de segurança associados ao redirecionamento de usuários para endpoints desconhecidos ou não verificados. -Você pode conferir o [Logout iniciado pela RP](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) para mais informações. +Você pode conferir o [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) para mais informações. -### Origens permitidas pelo CORS \{#cors-allowed-origins} +### Origens permitidas CORS \{#cors-allowed-origins} -As _Origens permitidas pelo CORS (Cross-origin resource sharing)_ são uma lista de origens permitidas das quais uma aplicação pode fazer solicitações ao serviço Logto. Qualquer origem que não esteja incluída na lista permitida não poderá fazer solicitações ao serviço Logto. +_As origens permitidas CORS (Cross-origin resource sharing)_ são uma lista de origens permitidas a partir das quais um aplicativo pode fazer solicitações ao serviço Logto. Qualquer origem que não esteja incluída na lista permitida não poderá fazer solicitações ao serviço Logto. -A lista de origens permitidas pelo CORS é usada para restringir o acesso ao serviço Logto de domínios não autorizados e para ajudar a prevenir ataques de falsificação de solicitação entre sites (CSRF). Ao especificar as origens permitidas para uma aplicação no Logto, o serviço pode garantir que apenas domínios autorizados possam fazer solicitações ao serviço. +A lista de origens permitidas CORS é usada para restringir o acesso ao serviço Logto a partir de domínios não autorizados e para ajudar a prevenir ataques de falsificação de solicitação entre sites (CSRF). Ao especificar as origens permitidas para um aplicativo no Logto, o serviço pode garantir que apenas domínios autorizados possam fazer solicitações ao serviço. :::note -A lista de origens permitidas deve conter a origem onde a aplicação será servida. Isso garante que as solicitações da aplicação sejam permitidas, enquanto as solicitações de origens não autorizadas são bloqueadas. +A lista de origens permitidas deve conter a origem onde o aplicativo será servido. Isso garante que as solicitações do aplicativo sejam permitidas, enquanto solicitações de origens não autorizadas sejam bloqueadas. ::: ### Endpoint de configuração do provedor OpenID \{#openid-provider-configuration-endpoint} -O endpoint para [Descoberta OpenID Connect](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest). +O endpoint para [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest). ### Endpoint de autorização \{#authorization-endpoint} -_Endpoint de autorização_ é um termo do OIDC, e é um endpoint necessário que é usado para iniciar o processo de autenticação para um usuário. Quando um usuário tenta acessar um recurso ou aplicação protegida que foi registrada na plataforma Logto, ele será redirecionado para o _Endpoint de autorização_ para autenticar sua identidade e obter autorização para acessar o recurso solicitado. +_Endpoint de autorização_ é um termo OIDC, e é um endpoint obrigatório usado para iniciar o processo de autenticação de um usuário. Quando um usuário tenta acessar um recurso protegido ou aplicativo que foi registrado na plataforma Logto, ele será redirecionado para o _endpoint de autorização_ para autenticar sua identidade e obter autorização para acessar o recurso solicitado. -Você pode conferir o [Endpoint de autorização](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) para mais informações. +Você pode conferir o [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) para mais informações. ### Endpoint de token \{#token-endpoint} -_Endpoint de token_ é um termo do OIDC, é um endpoint de API web que é usado por um cliente OIDC para obter um token de acesso, um token de ID ou um token de atualização de um provedor OIDC. +_Endpoint de token_ é um termo OIDC, é um endpoint de API web usado por um cliente OIDC para obter um token de acesso, um token de ID ou um token de atualização de um provedor OIDC. -Quando um cliente OIDC precisa obter um token de acesso ou token de ID, ele envia uma solicitação ao Endpoint de Token com uma concessão de autorização, que é tipicamente um código de autorização ou um token de atualização. O Endpoint de Token então valida a concessão de autorização e emite um token de acesso ou token de ID para o cliente se a concessão for válida. +Quando um cliente OIDC precisa obter um token de acesso ou token de ID, ele envia uma solicitação ao endpoint de token com uma concessão de autorização, que normalmente é um código de autorização ou um token de atualização. O endpoint de token então valida a concessão de autorização e emite um token de acesso ou token de ID para o cliente se a concessão for válida. -Você pode conferir o [Endpoint de token](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) para mais informações. +Você pode conferir o [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) para mais informações. -### Endpoint de informações do usuário \{#userinfo-endpoint} +### Endpoint Userinfo \{#userinfo-endpoint} -O [Endpoint de informações do usuário](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) do OpenID Connect. +O [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) do OpenID Connect. ### Sempre emitir token de atualização \{#always-issue-refresh-token} _Disponibilidade: Web tradicional, SPA_ -Quando ativado, o Logto sempre emitirá tokens de atualização, independentemente de `prompt=consent` ser apresentado na solicitação de autenticação, nem `offline_access` ser apresentado nos escopos. +Quando ativado, o Logto sempre emitirá tokens de atualização, independentemente de `prompt=consent` estar presente na solicitação de autenticação, ou `offline_access` estar presente nos escopos. -No entanto, essa prática é desencorajada, a menos que necessário (geralmente é útil para algumas integrações OAuth de terceiros que exigem token de atualização), pois não é compatível com OpenID Connect e pode potencialmente causar problemas. +No entanto, essa prática é desencorajada, a menos que seja necessário (geralmente é útil para algumas integrações OAuth de terceiros que exigem token de atualização), pois não é compatível com OpenID Connect e pode causar problemas. ### Rotacionar token de atualização \{#rotate-refresh-token} @@ -119,33 +123,33 @@ _Padrão: `true`_ Quando ativado, o Logto emitirá um novo token de atualização para solicitações de token sob as seguintes condições: -- Se o token de atualização tiver sido rotacionado (ter seu TTL prolongado emitindo um novo) por um ano; **OU** -- Se o token de atualização estiver próximo do seu tempo de expiração (>=70% do seu Tempo de Vida (TTL) original passado); **OU** -- Se o cliente for um cliente público, por exemplo, aplicativo nativo ou aplicativo de página única (SPA). +- Se o token de atualização foi rotacionado (teve seu TTL prolongado emitindo um novo) por um ano; **OU** +- Se o token de atualização estiver próximo do tempo de expiração (>=70% do Tempo de Vida (TTL) original passado); **OU** +- Se o cliente for um cliente público, ex.: aplicativo nativo ou aplicativo de página única (SPA). :::note Para clientes públicos, quando esse recurso está ativado, um novo token de atualização sempre será emitido quando o cliente estiver trocando por um novo token de acesso usando o token de atualização. -Embora você ainda possa desativar o recurso para esses clientes públicos, é altamente recomendável mantê-lo ativado por razões de segurança. +Embora você ainda possa desativar o recurso para esses clientes públicos, é altamente recomendado mantê-lo ativado por motivos de segurança. ::: - Entendendo a rotação de token de atualização + Compreendendo a rotação de token de atualização ### Tempo de vida (TTL) do token de atualização em dias \{#refresh-token-time-to-live-ttl-in-days} _Disponibilidade: Não SPA; Padrão: 14 dias_ -A duração pela qual um token de atualização pode ser usado para solicitar novos tokens de acesso antes que expire e se torne inválido. As solicitações de token estenderão o TTL do token de atualização para este valor. +A duração pela qual um token de atualização pode ser usado para solicitar novos tokens de acesso antes de expirar e se tornar inválido. As solicitações de token estenderão o TTL do token de atualização para esse valor. -Normalmente, um valor mais baixo é preferido. +Normalmente, um valor mais baixo é preferível. -Nota: A atualização do TTL não está disponível em SPA (aplicativo de página única) por razões de segurança. Isso significa que o Logto não estenderá o TTL através de solicitações de token. Para melhorar a experiência do usuário, você pode ativar o recurso "Rotacionar token de atualização", permitindo que o Logto emita um novo token de atualização quando necessário. +Nota: A atualização do TTL não está disponível em SPA (aplicativo de página única) por motivos de segurança. Isso significa que o Logto não estenderá o TTL por meio de solicitações de token. Para melhorar a experiência do usuário, você pode ativar o recurso "Rotacionar token de atualização", permitindo que o Logto emita um novo token de atualização quando necessário. -### URI de logout de backchannel \{#backchannel-logout-uri} +### URI de logout backchannel \{#backchannel-logout-uri} -O endpoint de logout de backchannel do OpenID Connect. Veja [Logout federado: Logout de backchannel](#) para mais informações. +O endpoint de logout backchannel do OpenID Connect. Veja [Logout federado: logout back-channel](#) para mais informações. ### Dados personalizados \{#custom-data} -Informações adicionais personalizadas da aplicação não listadas nas propriedades predefinidas da aplicação, os usuários podem definir seus próprios campos de dados personalizados de acordo com suas necessidades específicas, como configurações e configurações específicas de negócios. +Informações adicionais personalizadas do aplicativo não listadas nas propriedades predefinidas do aplicativo; os usuários podem definir seus próprios campos de dados personalizados de acordo com suas necessidades específicas, como configurações e definições específicas do negócio. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index 9a758d8e1eb..30077a1b312 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -16,15 +16,30 @@ Siga estes passos para adicionar autenticação aos seus aplicativos com o Logto 4. Após selecionar seu framework, você verá um guia de início rápido para o SDK do framework. Siga os passos para configurar e integrar seu aplicativo. Se precisar de ajuda para entender os conceitos envolvidos no processo de integração, consulte [Entendendo o fluxo de autenticação do Logto](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) para um entendimento mais profundo da integração. :::note -O guia no console é apenas para início rápido com o Logto usando nosso SDK. Para guias completos de integração, incluindo uso avançado do SDK, confira a seção de [Inícios rápidos](/quick-starts). +O guia no console serve apenas para um início rápido com o Logto usando nosso SDK. Para guias completos de integração, incluindo uso avançado do SDK, confira a seção [Inícios rápidos](/quick-starts). ::: -5. Depois de concluir, você está pronto para explorar mais sobre o Logto: +5. Após concluir, você está pronto para explorar mais sobre o Logto: Fluxos do usuário final Autorização (Authorization) Organizações (Organizations) +## Perguntas frequentes \{#faqs} + +
+ + ### Como meu serviço backend pode validar tokens de usuário e gerenciar usuários com o Logto? + +Para validar com segurança tokens de acesso em sua API backend (por exemplo, Python, Node.js, Go, Java, PHP, etc.) e gerenciar usuários programaticamente, consulte o guia: [Como validar tokens de acesso em seu serviço de API ou backend](/authorization/validate-access-tokens). + +Esta documentação aborda: + +- Como verificar a validade de tokens bearer em cada chamada de API +- Melhores práticas para integrar o Logto com múltiplos apps frontend e um serviço backend + +
+ ## Recursos relacionados \{#related-resources} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index cb112fbda26..257d3ea9c20 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -1,5 +1,5 @@ --- -description: Use Logto para criar seu próprio Provedor de Identidade e habilitar SSO para aplicativos de terceiros. Integre facilmente aplicativos OIDC / OAuth. +description: Use o Logto para criar seu próprio Provedor de Identidade e habilitar SSO para aplicativos de terceiros. Integre facilmente aplicativos OIDC / OAuth. sidebar_position: 4 --- @@ -14,16 +14,16 @@ Um Provedor de Identidade (IdP) é um serviço que verifica identidades de usuá Diferente dos aplicativos que você criou no guia [Integre Logto ao seu aplicativo](/integrate-logto/integrate-logto-into-your-application), que são desenvolvidos e totalmente controlados por você, os aplicativos de terceiros são serviços independentes desenvolvidos por desenvolvedores externos ou parceiros de negócios. -Essa abordagem de integração é ideal para cenários de negócios comuns. Você pode permitir que usuários acessem aplicativos parceiros usando suas contas Logto, assim como usuários corporativos fazem login no Slack com o Google Workspace. Você também pode construir uma plataforma aberta onde aplicativos de terceiros podem adicionar a funcionalidade "Entrar com Logto", semelhante ao "Entrar com Google". +Essa abordagem de integração é adequada para cenários de negócios comuns. Você pode permitir que usuários acessem aplicativos parceiros usando suas contas Logto, assim como usuários corporativos fazem login no Slack com o Google Workspace. Você também pode construir uma plataforma aberta onde aplicativos de terceiros podem adicionar a funcionalidade "Entrar com Logto", semelhante ao "Entrar com Google". -O Logto é um serviço de identidade construído sobre o protocolo [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), fornecendo capacidades de [autenticação (Authentication)](https://auth.wiki/authentication) e [autorização (Authorization)](https://auth.wiki/authorization). Isso torna a integração de um aplicativo de terceiros OIDC tão simples quanto uma aplicação web tradicional. +O Logto é um serviço de identidade construído sobre o protocolo [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), fornecendo capacidades de [autenticação (Authentication)](https://auth.wiki/authentication) e [autorização (Authorization)](https://auth.wiki/authorization). Isso torna a integração de um aplicativo de terceiros OIDC tão simples quanto a de um aplicativo web tradicional. -Além disso, como o OIDC é construído sobre o [OAuth 2.0](https://auth.wiki/oauth-2.0) adicionando uma camada de autenticação, você também pode integrar aplicativos de terceiros usando o protocolo OAuth. +Como o OIDC é construído sobre o [OAuth 2.0](https://auth.wiki/oauth-2.0), adicionando uma camada de autenticação, você também pode integrar aplicativos de terceiros usando o protocolo OAuth. ## Criar um aplicativo de terceiros no Logto \{#create-an-third-party-application-in-logto} -1. Vá para Console > Aplicativos -2. Selecione "Aplicativo de terceiros" como o tipo de aplicativo e escolha um dos seguintes protocolos de integração: +1. Vá para Console > Aplicativos. +2. Clique no botão "Criar aplicativo". Selecione "Aplicativo de terceiros" como o tipo de aplicativo e escolha um dos seguintes protocolos de integração: - OIDC / OAuth 3. Insira um nome e uma descrição para seu aplicativo e clique no botão “Criar”. Um novo aplicativo de terceiros será criado. @@ -91,7 +91,7 @@ Essas permissões solicitadas só serão concedidas aos aplicativos de terceiros -O Logto utiliza Controle de Acesso Baseado em Papel (RBAC) para gerenciar permissões de usuários. Na tela de consentimento, apenas os escopos (permissões) já atribuídos ao usuário — por meio de seus papéis — serão exibidos. Se um aplicativo de terceiros solicitar escopos que o usuário não possui, esses serão excluídos para evitar consentimento não autorizado. +O Logto utiliza Controle de Acesso Baseado em Papel (RBAC) para gerenciar permissões de usuários. Na tela de consentimento, apenas os escopos (permissões) já atribuídos ao usuário — por meio de seus papéis — serão exibidos. Se um aplicativo de terceiros solicitar escopos que o usuário não possui, eles serão excluídos para evitar consentimento não autorizado. Para gerenciar isso: diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index 23f7d0ddc38..62558bd5314 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,10 +3,11 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Serviço em nuvem Logto -[Logto Cloud](https://cloud.logto.io) oferece uma variedade de serviços de gerenciamento e operação para ajudar você a gerenciar identidades e recursos de forma simples e eficiente. Hospedado pelo Logto, inclui recursos como [suporte a múltiplas regiões](/logto-cloud/tenant-settings#tenant-region), gerenciamento de tenant, [cobrança e preços](/logto-cloud/billing-and-pricing), [gerenciamento de membros](/logto-cloud/tenant-member-management) e controle de acesso baseado em papel na console. +[Logto Cloud](https://cloud.logto.io) oferece uma variedade de serviços de gerenciamento e operação para ajudar você a gerenciar identidades e recursos de forma tranquila e fácil. Hospedado pelo Logto, inclui recursos como [suporte a múltiplas regiões](/logto-cloud/tenant-settings#tenant-region), gerenciamento de tenant, [faturamento e preços](/logto-cloud/billing-and-pricing), [gerenciamento de membros](/logto-cloud/tenant-member-management) e controle de acesso baseado em papel no console. Se você tiver dúvidas sobre os serviços em nuvem e precisar de suporte adicional, entre em contato conosco. @@ -49,19 +50,29 @@ Se você tiver dúvidas sobre os serviços em nuvem e precisar de suporte adicio label: 'Domínios personalizados', href: '/logto-cloud/custom-domain', description: - 'Use seu próprio domínio para seu tenant Logto e mantenha a consistência da marca na experiência de login.', + 'Use seu próprio domínio para seu tenant Logto para manter a consistência da marca na sua experiência de login.', customProps: { icon: , }, }, { type: 'link', - label: 'Cobrança e preços', + label: 'Faturamento e preços', href: '/logto-cloud/billing-and-pricing', description: 'Entenda facilmente sua fatura e gerencie sua assinatura com confiança.', customProps: { icon: , }, }, + { + type: 'link', + label: 'Limite do sistema', + href: '/logto-cloud/system-limit', + description: + 'Entenda os limites do sistema e a proteção de taxa para tenants Dev, Pro e Enterprise.', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index a53d233b91d..3bf7cedac52 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -16,12 +16,12 @@ Seu domínio personalizado é utilizado para várias funções: - [Endpoint do SDK](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) para integrar o Logto ao seu aplicativo. :::note -Alterar o domínio após publicar seu serviço pode causar problemas porque o código do seu aplicativo e integrações podem ainda referenciar o domínio antigo. Para garantir uma transição tranquila, **configure seu domínio personalizado no início** durante a criação do tenant de Produção. +Alterar o domínio após publicar seu serviço pode causar problemas porque o código do seu aplicativo e integrações podem ainda referenciar o domínio antigo. Para garantir uma transição suave, **configure seu domínio personalizado no início** durante a criação do tenant de Produção. ::: ## Configurar domínio personalizado no Console \{#configure-custom-domain-in-console} -Para adicionar um novo domínio personalizado no Console Logto, siga estes passos: +Para adicionar um novo domínio personalizado no Logto Console, siga estes passos: 1. Navegue até Console > Configurações > Domínios. 2. Na seção "Domínio personalizado", insira o nome do seu domínio e clique em "adicionar domínio". @@ -33,8 +33,8 @@ Para adicionar um novo domínio personalizado no Console Logto, siga estes passo Processando domínio personalizado 4. Aguarde o processo de verificação e SSL. - 1. Faremos a verificação automática dos seus registros a cada 10 segundos até que o domínio personalizado seja adicionado. Apenas certifique-se de que o nome do domínio inserido ou os registros DNS estejam corretos. - 2. A verificação normalmente leva alguns minutos, mas pode levar até 24 horas, dependendo do provedor de DNS. Fique à vontade para navegar para outras páginas durante o processo. + 1. Nós iremos verificar automaticamente seus registros a cada 10 segundos até que o domínio personalizado seja adicionado. Apenas certifique-se de que o nome do domínio inserido ou os Registros DNS estejam corretos. + 2. A verificação normalmente leva alguns minutos, mas pode levar até 24 horas, dependendo do provedor de DNS. Sinta-se à vontade para navegar para outras páginas durante o processo. ## Solução de problemas \{#troubleshooting} @@ -45,22 +45,22 @@ Para adicionar um novo domínio personalizado no Console Logto, siga estes passo -Se você encontrar problemas com o certificado SSL ao configurar seu domínio personalizado, isso pode estar relacionado a registros CAA na configuração do seu DNS. Os registros CAA especificam quais Autoridades Certificadoras (CAs) estão autorizadas a emitir certificados para seu domínio. Se você estiver usando registros CAA, será necessário autorizar tanto "letsencrypt.org" quanto "pki.goog" para que o Logto possa emitir certificados SSL. +Se você encontrar problemas com o certificado SSL ao configurar seu domínio personalizado, isso pode estar relacionado a registros CAA na configuração do seu DNS. Registros CAA especificam quais Autoridades Certificadoras (CAs) estão autorizadas a emitir certificados para seu domínio. Se você estiver usando registros CAA, será necessário autorizar tanto "letsencrypt.org" quanto "pki.goog" para que o Logto possa emitir certificados SSL. -Para solucionar e resolver problemas de certificado SSL relacionados a registros CAA, consulte a [documentação da Cloudflare](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) sobre registros CAA. +Para solucionar e resolver problemas de certificado SSL relacionados a registros CAA, consulte a [documentação da Cloudflare](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) sobre Registros CAA.
-### Erro "The hostname is associated with a held zone" \{#the-hostname-is-associated-with-a-held-zone-error} +### Erro "O hostname está associado a uma zona retida" \{#the-hostname-is-associated-with-a-held-zone-error} -Se você encontrar a mensagem de erro "The hostname is associated with a held zone, please contact the owner to have the hold removed" ao adicionar um domínio personalizado, isso significa que o domínio já está em uma zona Cloudflare e está com o status "Zone Hold". Veja esta [documentação da Cloudflare](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/) para mais informações. +Se você encontrar a mensagem de erro "O hostname está associado a uma zona retida, por favor entre em contato com o proprietário para remover a retenção" ao adicionar um domínio personalizado, isso significa que o domínio já está em uma zona Cloudflare, e está definido como status "Zone Hold". Veja esta [documentação da Cloudflare](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/) para mais informações. -Para resolver esse problema, será necessário liberar o "zone hold". Siga o link acima para instruções de como liberar o "zone hold" na Cloudflare. +Para resolver esse problema, você precisará liberar a retenção da zona. Siga o link acima para instruções de como liberar a retenção da zona na Cloudflare.
@@ -75,9 +75,40 @@ Se o seu domínio está hospedado na Cloudflare, desative o proxy da Cloudflare +
+ + +### Erro "Redirect URI does not match" após configurar domínio personalizado \{#redirect-uri-mismatch} + + + +Se você receber um erro "redirect URI does not match" após adicionar seu domínio personalizado, é necessário atualizar a configuração do seu SDK para usar o domínio personalizado como endpoint. + +**Sobre "domínio primário":** + +Não existe uma configuração separada de "domínio primário" no Logto. Após adicionar um domínio personalizado, tanto seu domínio personalizado quanto o domínio padrão `{tenant-id}.logto.app` permanecem válidos. O domínio que você configurar no parâmetro `endpoint` do seu SDK determina qual domínio será usado nos fluxos de autenticação. + +**Solução:** + +Atualize o parâmetro `endpoint` na inicialização do seu SDK para usar seu domínio personalizado: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // Use seu domínio personalizado + appId: 'your-app-id', + // ... outras opções +}); +``` + +Também verifique se os URIs de redirecionamento registrados em Console → Aplicativos correspondem ao domínio que você está usando. + +**Nota:** O Logto provisiona e gerencia automaticamente certificados SSL para seu domínio personalizado. Você não precisa configurar seus próprios certificados. + +
+ ## Usar domínio personalizado \{#use-custom-domain} -Depois de configurar suas definições, tanto o nome do domínio personalizado quanto o nome de domínio padrão do Logto estarão disponíveis para seu tenant. No entanto, certas configurações são necessárias para ativar o nome do domínio personalizado. +Depois de configurar suas definições, tanto seu nome de domínio personalizado quanto o nome de domínio padrão do Logto estarão disponíveis para seu tenant. No entanto, certas configurações são necessárias para ativar seu nome de domínio personalizado. :::note @@ -87,7 +118,7 @@ Neste artigo, assumimos que seu domínio personalizado é `auth.example.com`. ### Atualizando o endpoint do SDK para aplicativos \{#updating-the-sdk-endpoint-for-applications} -Altere seu código de inicialização do SDK do Logto modificando o nome do domínio do endpoint. +Altere seu código de inicialização do SDK do Logto modificando o nome de domínio do endpoint. ```typescript const client = new LogtoClient({ @@ -108,6 +139,6 @@ https://auth.example.com/oidc/.well-known/openid-configuration ### Atualizando o URI de callback do conector social \{#updating-the-social-connectors-callback-uri} -O URI de callback do conector social será atualizado automaticamente se seus usuários estiverem usando o domínio personalizado. Você precisa acessar o console do desenvolvedor do provedor social para atualizar o URI de callback. +O URI de callback do conector social será atualizado automaticamente se seus usuários estiverem usando o domínio personalizado. Você precisa acessar o console de desenvolvedor do provedor social para atualizar o URI de callback. -Quando seus usuários estiverem usando o domínio personalizado, o URI de callback do conector social utilizará o novo domínio. Portanto, é necessário acessar o console do desenvolvedor do provedor social para atualizar manualmente o URI de callback. +Quando seus usuários estiverem usando o domínio personalizado, o URI de callback do conector social utilizará o novo domínio. Portanto, é necessário acessar o console de desenvolvedor do provedor social para atualizar manualmente o URI de callback. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..77097d7acbf --- /dev/null +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# Limite do sistema + +No Logto, definimos limites generosos em todos os planos e oferecemos opções flexíveis de pagamento conforme o uso, para que os usuários paguem apenas pelo que realmente utilizam. + +Você pode notar que alguns itens na página de preços estão marcados como _ilimitados_ ou como _pagamento contínuo conforme o uso, sem teto_. Isso significa que geralmente podem ser usados sem restrição, mas o Logto reserva o direito de ajustar esses limites reais ao longo do tempo para manter o uso justo para todos os usuários. Em outras palavras, os limites de entidades são restrições rígidas que protegem a saúde geral da plataforma. Eles não fazem parte da precificação, embora possam variar entre diferentes grupos de planos. + +Se o seu caso de uso for razoável, mas atingir um limite do sistema, sinta-se à vontade para entrar em contato conosco e compartilhar seu feedback. Isso nos ajuda a entender melhor os padrões de uso no mundo real e ajustar os limites do sistema para melhor apoiar nossos clientes fiéis. + +## Proteção de limite de taxa no nível do tenant \{#tenant-level-rate-limit-protection} + +### Tenants Dev \{#dev-tenants} + +Para tenants Dev, os usuários podem aproveitar os recursos e ofertas gratuitas do Logto. Para evitar abusos e definir expectativas claras, estabelecemos certos limites do sistema. Esses limites nos ajudam a gerenciar nossa plataforma de forma sustentável, ao mesmo tempo em que fornecemos acesso gratuito para fins de teste e desenvolvimento. + +Se você quiser aumentar sua cota, pode entrar em contato conosco para obter assistência. Também recomendamos atualizar de **Dev** para **Pro**, o que remove o limite e oferece acesso total imediatamente. + +| **Recurso** | **Limite de entidade** | +| ------------------------------------ | ---------------------- | +| **Tokens incluídos** | 50 mil por mês | +| **Aplicativos** | | +| Total de aplicativos | 100 | +| Aplicativos máquina para máquina | 100 | +| Aplicativos de terceiros | 100 | +| **Recursos de API** | | +| Quantidade de recursos | 100 | +| **Autenticação de usuário** | | +| Conector social | 100 | +| SSO corporativo | 100 | +| **Gerenciamento de usuários** | | +| Papéis de usuário | 100 | +| Papéis máquina para máquina | 100 | +| Permissão por papel | 100 | +| **Organizações** | | +| Quantidade de organizações | 5.000 | +| Usuários por organização | 100 mil | +| Papéis de usuário por organização | 1.000 | +| Papéis máquina para máquina por org. | 100 | +| Permissões da organização | 1.000 | +| **Desenvolvedores e plataforma** | | +| Webhooks | 10 | +| Retenção de log de auditoria | 14 dias | +| Membros do tenant | 20 | + +### Tenant Pro \{#pro-tenant} + +Para tenants Pro, os limites de entidade definem o teto máximo para complementos e outras entidades "ilimitadas", como aplicativos. Os detalhes dos limites do sistema do plano Pro estão listados abaixo. + +| **Recurso** | **Limite de entidade** | +| ------------------------------------ | ---------------------- | +| **Tokens incluídos** | 10 milhões por mês | +| **Aplicativos** | | +| Total de aplicativos | 100 | +| Aplicativos máquina para máquina | 100 | +| Aplicativos OIDC/OAuth de terceiros | 100 | +| Aplicativos SAML | 100 | +| **Recursos de API** | | +| Quantidade de recursos | 1.000 | +| Permissão por recurso | 1.000 | +| **Autenticação de usuário** | | +| Conectores sociais | 100 | +| SSO corporativo | 100 | +| **Gerenciamento de usuários** | | +| Papéis de usuário | 1.000 | +| Papéis máquina para máquina | 100 | +| **Organizações** | | +| Quantidade de organizações | 100 mil | +| Usuários por organização | 100 mil | +| Papéis de usuário por organização | 1.000 | +| Papéis máquina para máquina por org. | 100 | +| Permissões da organização | 1.000 | +| **Desenvolvedores e plataforma** | | +| Webhooks | 10 | +| Retenção de log de auditoria | 14 dias | +| Domínios personalizados | 10 | +| Membros do tenant | 100 | + +### Enterprise \{#enterprise} + +Para planos Enterprise, os limites e recursos são totalmente personalizáveis e gerenciados por meio de contrato. Por favor, [entre em contato conosco](https://logto.io/contact) para mais detalhes. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index a3f4b81fb85..2bae5b5ff55 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -6,11 +6,11 @@ sidebar_position: 1 # Configurações do tenant -Novos usuários que se registram no Logto Cloud são automaticamente inseridos em um tenant de ambiente **Desenvolvimento** (Dev) gratuito. Você pode explorar todos os recursos neste tenant. +Novos usuários que se registram no Logto Cloud são automaticamente integrados a um tenant gratuito de ambiente **Desenvolvimento** (Dev). Você pode explorar todos os recursos neste tenant. Se você quiser criar um tenant separado para o ambiente de **Produção** (Prod) ou para um novo projeto, clique no nome do seu tenant atual no canto superior esquerdo da barra superior. Neste menu, você pode alternar entre tenants ou criar um novo. -Clique em "Criar tenant" e então: +Clique em "Criar tenant" e, em seguida: - Nome para o tenant - Selecione uma [região de dados do tenant](#tenant-region) @@ -21,7 +21,7 @@ Para um tenant existente, vá para Console > Configura - Visualizar o ID do tenant - Atualizar o nome do tenant - Visualizar a [região do tenant](#tenant-region). Isso não pode ser alterado após a criação. -- Visualizar o [tipo do tenant](#tenant-types-dev-vs-prod). Você pode converter um tenant Dev em um tenant Prod se necessário. +- Visualizar o [tipo de tenant](#tenant-types-dev-vs-prod). Você pode converter um tenant Dev em um tenant Prod se necessário. - [Sair do tenant](#leave-tenant) - [Excluir o tenant](#delete-tenant) @@ -36,7 +36,7 @@ Ao criar um tenant, você pode escolher a região onde os dados do tenant serão Normalmente, você deve escolher a região mais próxima dos seus clientes para minimizar a latência e melhorar o desempenho. -O Logto utiliza a rede global de edge para oferecer o melhor desempenho e disponibilidade para seus aplicativos. O roteamento de solicitações é otimizado para garantir que seus usuários estejam sempre conectados à opção de melhor desempenho. +O Logto aproveita a rede global de edge para oferecer o melhor desempenho e disponibilidade para seus aplicativos. O roteamento de solicitações é otimizado para garantir que seus usuários estejam sempre conectados à opção de melhor desempenho. :::note Procurando outra região? [Entre em contato conosco](https://logto.io/contact) para: @@ -47,7 +47,7 @@ Procurando outra região? [Entre em contato conosco](https://logto.io/contact) p ## Tipos de tenant: Dev vs. Prod \{#tenant-types-dev-vs-prod} -Existem dois tipos de tenants no Logto Cloud: Desenvolvimento (Dev) e Produção (Prod). Com essa diferenciação de tenants, você pode gerenciar melhor seus projetos em diferentes ambientes para eficiência e, ao mesmo tempo, aproveitar todo o valor do Logto. +Existem dois tipos de tenants no Logto Cloud: Desenvolvimento (Dev) e Produção (Prod). Com essa diferenciação de tenants, você pode gerenciar melhor seus projetos em diferentes ambientes para maior eficiência e, ao mesmo tempo, aproveitar todo o valor do Logto. Você pode escolher o tipo de tenant durante a criação. Quando estiver pronto para ir para produção, há duas opções: @@ -56,11 +56,11 @@ Você pode escolher o tipo de tenant durante a criação. Quando estiver pronto - **Converter seu tenant Dev atual em Produção** Se preferir não refazer a configuração ou migrar usuários, você pode atualizar seu tenant de Desenvolvimento existente para um tenant de Produção pago. - - **Converter para o plano Pro**: Vá para Console > Configurações do tenant > Configurações, depois clique em "Converter" para fazer o upgrade por autoatendimento. Quaisquer recursos pagos que você tenha usado no tenant dev serão transferidos para o checkout do Stripe. + - **Converter para o plano Pro**: Vá para Console > Configurações do tenant > Configurações e clique em "Converter" para fazer o upgrade por autoatendimento. Quaisquer recursos pagos que você tenha usado no tenant dev serão transferidos para o checkout do Stripe. - **Converter para o plano Enterprise**: [Entre em contato conosco](https://logto.io/contact) e ajudaremos você a concluir o upgrade. :::note - Uma vez convertido, o tenant não pode ser revertido para o ambiente Dev; por favor, confirme que está pronto antes de prosseguir. + Uma vez convertido, o tenant não pode ser revertido para o ambiente Dev; por favor, confirme que você está pronto antes de prosseguir. ::: ### Desenvolvimento \{#development} @@ -69,36 +69,10 @@ O tenant de desenvolvimento (tenant dev) é destinado principalmente para fins d No entanto, existem algumas limitações que se aplicam aos tenants de desenvolvimento: -- O tenant dev excluirá automaticamente usuários após 90 dias. Consulte a [Política de retenção de dados do tenant Dev](./dev-tenant-data-retention) para detalhes. +- O tenant dev excluirá automaticamente usuários após 90 dias. Confira a [Política de retenção de dados do tenant Dev](./dev-tenant-data-retention) para detalhes. - Um banner aparece durante a experiência de login, indicando que o tenant está em modo de desenvolvimento. -- Tenants de desenvolvimento podem ter limites de cota em recursos específicos. Esses limites são explicados na página de detalhes do recurso, se aplicável. -- O Logto pode atualizar os limites de cota do tenant de desenvolvimento, e tentaremos notificá-lo com antecedência. - -| Recurso | Limite de entidade | -| -------------------------------- | ------------------ | -| **Tokens incluídos** | 50 mil por mês | -| **Aplicativos** | -| Total de aplicativos | 100 | -| Aplicativos máquina para máquina | 100 | -| Aplicativos de terceiros | 100 | -| **Recursos de API** | | -| Quantidade de recursos | 100 | -| **Autenticação de usuário** | | -| Conector social | 100 | -| SSO corporativo | 100 | -| **Gerenciamento de usuários** | | -| Papéis de usuário | 100 | -| Papéis máquina para máquina | 100 | -| Permissão por papel | 100 | -| **Organizações** | | -| Quantidade de organizações | 5.000 | -| Usuários por organização | 5.000 | -| Papéis da organização | 100 | -| Permissões da organização | 100 | -| **Desenvolvedores e plataforma** | | -| Webhooks | 10 | -| Retenção de log de auditoria | 14 dias | -| Membros do tenant | 20 | +- Tenants de desenvolvimento podem ter limites de cota em recursos específicos. Esses limites são explicados na página de detalhes do recurso, se aplicável. Para uma lista completa das limitações do plano Dev, consulte a página [Limite do sistema](./system-limit). +- O Logto pode atualizar os limites de cota do tenant de desenvolvimento, e tentaremos avisá-lo com antecedência. ### Produção \{#production} @@ -112,7 +86,7 @@ Como o autoatendimento ainda não está disponível, por favor, [entre em contat ## Ativar SSO corporativo \{#enable-enterprise-sso} -O Logto Cloud oferece suporte à integração de autenticação única corporativa (SSO corporativo) para tenants do plano Enterprise, incluindo provedores como Google Workspace, Okta, Azure AD e outros. +O Logto Cloud oferece suporte à integração de autenticação única corporativa (Single Sign-On) para tenants do Plano Enterprise, incluindo provedores como Google Workspace, Okta, Azure AD e outros. Para começar, por favor, [entre em contato conosco](https://logto.io/contact). Vamos ajudá-lo a configurar rapidamente. @@ -126,7 +100,7 @@ Se você for o último administrador, deverá atribuir outro colaborador como ad ## Excluir tenant \{#delete-tenant} -[Administradores](/logto-cloud/tenant-member-management#invite-collaborators) podem excluir um tenant Logto. Excluir um tenant remove permanentemente todos os dados de usuários e configurações associados. Esta ação NÃO PODE ser desfeita. O Logto solicitará que você digite o nome do tenant para confirmar e ajudar a evitar exclusão acidental. +[Administradores](/logto-cloud/tenant-member-management#invite-collaborators) podem excluir um tenant Logto. Excluir um tenant remove permanentemente todos os dados de usuários e configurações associados. Essa ação NÃO PODE ser desfeita. O Logto solicitará que você digite o nome do tenant para confirmar e ajudar a evitar exclusão acidental. Se precisar de ajuda, por favor, [entre em contato conosco](https://logto.io/contact) por e-mail. @@ -139,7 +113,7 @@ Se precisar de ajuda, por favor, [entre em contato conosco](https://logto.io/con -Atualmente, você pode converter seu tenant **Desenvolvimento** para um tenant **Produção** com plano pago por conta própria. [Saiba mais](#tenant-types-dev-vs-prod) +Atualmente, você pode converter seu tenant **Desenvolvimento** em um tenant **Produção** com plano pago por conta própria. [Saiba mais](#tenant-types-dev-vs-prod) No entanto, a migração por autoatendimento (todas as configurações e dados de usuários) entre Logto Cloud e a versão OSS não é suportada. Se precisar desse serviço, por favor, [entre em contato com a equipe Logto](https://logto.io/contact) para discutir suas opções. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index a2017679dfe..7f05e7bebd4 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -13,11 +13,11 @@ import ZeaburIcon from '@site/src/assets/oss-zeabur.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; -# Comece com OSS +# Primeiros passos com OSS ## GitPod \{#gitpod} -Para iniciar um workspace online do GitPod para Logto, clique aqui. Aguarde alguns momentos, você verá a mensagem como: +Para iniciar um workspace online do GitPod para o Logto, clique aqui. Aguarde alguns instantes e você verá uma mensagem como:

@@ -86,7 +86,7 @@ npx @logto/cli db seed

Passo 2

-Puxe a imagem: +Baixe a imagem: ```bash # ghcr @@ -97,16 +97,16 @@ docker pull svhd/logto:latest

Passo 3

-Mapeie as portas do contêiner para o núcleo do Logto e o aplicativo de administração, por exemplo, `3001:3001` e `3002:3002`; e defina as seguintes variáveis de ambiente para o contêiner: +Mapeie as portas do container para o core do Logto e o app admin, por exemplo, `3001:3001` e `3002:3002`; e defina as seguintes variáveis de ambiente no container: ```yml -TRUST_PROXY_HEADER: 1 # Defina como 1 se você tiver um proxy HTTPS (por exemplo, Nginx) na frente do Logto -ENDPOINT: https:// # (Opcional) Substitua pela URL do seu endpoint Logto se estiver usando um domínio personalizado -ADMIN_ENDPOINT: https:// # (Opcional) Substitua pela URL do seu admin Logto se estiver usando um domínio personalizado +TRUST_PROXY_HEADER: 1 # Defina como 1 se você tiver um proxy HTTPS (ex: Nginx) na frente do Logto +ENDPOINT: https:// # (Opcional) Substitua pela URL do endpoint do Logto se estiver usando um domínio personalizado +ADMIN_ENDPOINT: https:// # (Opcional) Substitua pela URL admin do Logto se estiver usando um domínio personalizado DB_URL: postgres://username:password@your_postgres_url:port/db_name # Substitua pelo seu DSN do Postgres ``` -Execute o contêiner com todas as variáveis de ambiente acima: +Execute o container com todas as variáveis de ambiente acima: ```bash docker run \ @@ -122,12 +122,12 @@ docker run \ :::tip -- Se você estiver usando o Docker Hub, use `svhd/logto:latest` em vez de `ghcr.io/logto-io/logto:latest`. +- Se estiver usando o Docker Hub, utilize `svhd/logto:latest` em vez de `ghcr.io/logto-io/logto:latest`. - Use `host.docker.internal` ou `172.17.0.1` em `DB_URL` para se referir ao IP do host. ::: -Finalmente, você verá a mensagem como: +Por fim, você verá uma mensagem como: @@ -140,9 +140,9 @@ Finalmente, você verá a mensagem como: Versões superiores geralmente funcionam, mas não são garantidas. -Recomendamos usar um novo banco de dados vazio dedicado ao Logto, embora não seja um requisito rígido. +Recomendamos utilizar um novo banco de dados vazio dedicado ao Logto, embora não seja um requisito obrigatório. -**Baixar e iniciar** +**Baixe e inicie** No seu terminal: @@ -150,7 +150,7 @@ No seu terminal: npm init @logto@latest ``` -Uma vez que você complete o processo de inicialização e inicie o Logto, você verá a mensagem como: +Assim que você concluir o processo de inicialização e iniciar o Logto, verá uma mensagem como: @@ -163,7 +163,7 @@ Admin app is running at http://localhost:3002 Admin app is running at https://your-admin-domain-url ``` -Vá para `http://localhost:3002/` para continuar sua jornada com Logto. Aproveite! +Acesse `http://localhost:3002/` para continuar sua jornada com o Logto. Aproveite!
@@ -173,13 +173,13 @@ Vá para `http://localhost:3002/` para continuar sua jornada com Logto. Aproveit -Se você quiser especificar uma URL para o arquivo zip do Logto, use a opção `--download-url`. Por exemplo: +Se você deseja especificar uma URL para o arquivo zip do Logto, utilize a opção `--download-url`. Por exemplo: ``` npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -Observe que o extra `--` é necessário para o NPM passar os argumentos. +Observe que o `--` extra é necessário para o NPM repassar os argumentos.
@@ -191,15 +191,15 @@ Observe que o extra `--` é necessário para o NPM passar os argumentos. -Logto usa variáveis de ambiente para configuração, juntamente com suporte a arquivos `.env`. Veja [Configuração](/concepts/core-service/configuration) para uso detalhado e lista completa de variáveis. +O Logto utiliza variáveis de ambiente para configuração, além do suporte ao arquivo `.env`. Veja [Configuração](/concepts/core-service/configuration) para uso detalhado e lista completa de variáveis. -_Confira [Core service](/concepts/core-service) se você quiser controles mais avançados ou acesso programático ao Logto._ +_Confira [Core service](/concepts/core-service) se você deseja controles mais avançados ou acesso programático ao Logto._ ## Provedores de hospedagem \{#hosting-providers} -Esses provedores de hospedagem confiáveis oferecem modelos de instalação com um clique para Logto. Com serviços facilmente implantáveis, você pode configurar e lançar seu sistema CIAM usando Logto em segundos. +Esses provedores de hospedagem confiáveis oferecem templates de instalação com um clique para o Logto. Com serviços facilmente implantáveis, você pode configurar e lançar seu sistema CIAM usando o Logto em segundos. , }, @@ -218,7 +218,7 @@ Esses provedores de hospedagem confiáveis oferecem modelos de instalação com label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', description: - 'Uma alternativa ao Heroku/Netlify auto-hospedável para fácil gerenciamento de aplicativos e bancos de dados.', + 'Uma alternativa auto-hospedável ao Heroku/Netlify para gerenciamento fácil de apps e bancos de dados.', customProps: { icon: , }, @@ -227,7 +227,7 @@ Esses provedores de hospedagem confiáveis oferecem modelos de instalação com type: 'link', label: 'Dokploy', href: 'https://docs.dokploy.com/docs/core', - description: 'Ferramenta leve para implantar aplicativos em sua própria infraestrutura.', + description: 'Ferramenta leve para implantar apps em sua própria infraestrutura.', customProps: { icon: , }, @@ -246,7 +246,7 @@ Esses provedores de hospedagem confiáveis oferecem modelos de instalação com label: 'Elestio', href: 'https://elest.io/open-source/logto', description: - 'Plataforma DevOps totalmente gerenciada para implantar seu código e software open-source.', + 'Plataforma DevOps totalmente gerenciada para implantar seu código e softwares open-source.', customProps: { icon: , }, @@ -255,7 +255,7 @@ Esses provedores de hospedagem confiáveis oferecem modelos de instalação com type: 'link', label: 'Railway', href: 'https://railway.com/template/07_f_Z', - description: 'Simplifica a implantação de aplicativos e o gerenciamento de infraestrutura.', + description: 'Simplifica a implantação de apps e o gerenciamento de infraestrutura.', customProps: { icon: , }, @@ -265,7 +265,7 @@ Esses provedores de hospedagem confiáveis oferecem modelos de instalação com label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', description: - 'Simplifica a implantação, escalonamento e monitoramento de aplicativos para desenvolvedores.', + 'Simplifica a implantação, escalonamento e monitoramento de apps para desenvolvedores.', customProps: { icon: , }, @@ -273,11 +273,15 @@ Esses provedores de hospedagem confiáveis oferecem modelos de instalação com ]} /> -Por favor, note que não fornecemos suporte ao cliente para provedores de serviços de terceiros. Para acessar nossos canais de suporte, gentilmente faça a implantação no [Logto Cloud](https://cloud.logto.io). Obrigado! +Observe que não fornecemos suporte ao cliente para provedores de serviços de terceiros. Para acessar nossos canais de suporte, faça a implantação no [Logto Cloud](https://cloud.logto.io). Obrigado! ## Criar uma conta \{#create-an-account} -Uma vez que você tenha hospedado com sucesso o Logto em seu servidor, clique em "Criar conta" na página de boas-vindas. Lembre-se de que a versão open-source do Logto permite apenas a criação de uma conta durante o lançamento inicial e não suporta múltiplas contas. O processo de criação de conta é limitado a combinações de nome de usuário e senha. +Assim que você hospedar o Logto com sucesso em seu servidor, clique em "Criar conta" na página de boas-vindas. Lembre-se de que a versão open-source do Logto permite apenas a criação de uma conta durante o lançamento inicial e não suporta múltiplas contas. O processo de criação de conta é limitado à combinação de nome de usuário e senha. + +:::tip +O Logto OSS (auto-hospedado) não suporta a configuração de múltiplos administradores. Para colaboração em equipe e projetos que exigem múltiplos usuários admin, recomendamos o uso do [Logto Cloud](https://cloud.logto.io), que oferece recursos completos de gerenciamento de equipes. +::: ## Recursos relacionados \{#related-resources} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index f6be4ae49a6..b0380c90ef8 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot é um framework web para Java que permite aos desenvolvedores criar aplicativos de servidor seguros, rápidos e escaláveis com a linguagem de programação Java. + description: Spring Boot é um framework web para Java que permite aos desenvolvedores criar aplicações servidoras seguras, rápidas e escaláveis com a linguagem de programação Java. logoFilename: 'spring-boot.svg' --- @@ -14,28 +14,28 @@ import SignInFlowSummary from '../../fragments/_web-sign-in-flow-summary.mdx'; import ScopesAndClaims from './_scopes-and-claims.mdx'; -# Adicionar autenticação ao seu aplicativo Java Spring Boot +# Adicionar autenticação ao seu aplicativo Java Spring Boot (Add authentication to your Java Spring Boot application) Este guia mostrará como integrar o Logto ao seu aplicativo Java Spring Boot. :::tip -- Você pode encontrar o código de exemplo para este guia em nosso repositório github [spring-boot-sample](https://github.com/logto-io/spring-boot-sample). -- Nenhum SDK oficial é necessário para integrar o Logto ao seu aplicativo Java Spring Boot. Usaremos as bibliotecas [Spring Security](https://spring.io/projects/spring-security) e [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para lidar com o fluxo de autenticação OIDC com o Logto. +- Você pode encontrar o código de exemplo para este guia em nosso repositório do github [spring-boot-sample](https://github.com/logto-io/spring-boot-sample). +- Não é necessário um SDK oficial para integrar o Logto ao seu aplicativo Java Spring Boot. Usaremos as bibliotecas [Spring Security](https://spring.io/projects/spring-security) e [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para lidar com o fluxo de autenticação OIDC com o Logto. ::: ## Pré-requisitos \{#prerequisites} -- Uma conta [Logto Cloud](https://cloud.logto.io) ou um [Logto auto-hospedado](/introduction/set-up-logto-oss). -- Nosso código de exemplo foi criado usando o [securing web starter](https://spring.io/guides/gs/securing-web) do Spring Boot. Siga as instruções para iniciar um novo aplicativo web se você não tiver um. -- Neste guia, usaremos as bibliotecas [Spring Security](https://spring.io/projects/spring-security) e [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para lidar com o fluxo de autenticação OIDC com o Logto. Certifique-se de passar pela documentação oficial para entender os conceitos. +- Uma conta no [Logto Cloud](https://cloud.logto.io) ou um [Logto auto-hospedado](/introduction/set-up-logto-oss). +- Nosso código de exemplo foi criado usando o Spring Boot [securing web starter](https://spring.io/guides/gs/securing-web). Siga as instruções para iniciar um novo aplicativo web caso você ainda não tenha um. +- Neste guia, usaremos as bibliotecas [Spring Security](https://spring.io/projects/spring-security) e [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) para lidar com o fluxo de autenticação OIDC com o Logto. Certifique-se de ler a documentação oficial para entender os conceitos. -## Configurar seu aplicativo Java Spring Boot \{#configure-your-java-spring-boot-application} +## Configure seu aplicativo Java Spring Boot \{#configure-your-java-spring-boot-application} ### Adicionando dependências \{#adding-dependencies} -Para usuários de [gradle](https://spring.io/guides/gs/gradle), adicione as seguintes dependências ao seu arquivo `build.gradle`: +Para usuários do [gradle](https://spring.io/guides/gs/gradle), adicione as seguintes dependências ao seu arquivo `build.gradle`: ```groovy title="build.gradle" dependencies { @@ -46,7 +46,7 @@ dependencies { } ``` -Para usuários de [maven](https://spring.io/guides/gs/maven), adicione as seguintes dependências ao seu arquivo `pom.xml`: +Para usuários do [maven](https://spring.io/guides/gs/maven), adicione as seguintes dependências ao seu arquivo `pom.xml`: ```xml title="pom.xml" @@ -69,7 +69,7 @@ Para usuários de [maven](https://spring.io/guides/gs/maven), adicione as seguin ### Configuração do Cliente OAuth2 \{#oauth2-client-configuration} -Registre um novo aplicativo `Java Spring Boot` no Logto Console e obtenha as credenciais do cliente e as configurações do IdP para seu aplicativo web. +Registre um novo aplicativo `Java Spring Boot` no Logto Console e obtenha as credenciais do cliente e configurações do IdP para seu aplicativo web. Adicione a seguinte configuração ao seu arquivo `application.properties`: @@ -91,15 +91,15 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc -Para redirecionar os usuários de volta ao seu aplicativo após o login, você precisa definir o URI de redirecionamento usando a propriedade `client.registration.logto.redirect-uri` na etapa anterior. +Para redirecionar os usuários de volta ao seu aplicativo após o login, você precisa definir o redirect URI usando a propriedade `client.registration.logto.redirect-uri` no passo anterior. - + -### Implementar o WebSecurityConfig \{#implement-the-websecurityconfig} +### Implemente o WebSecurityConfig \{#implement-the-websecurityconfig} -#### Criar uma nova classe `WebSecurityConfig` em seu projeto \{#create-a-new-class-websecurityconfig-in-your-project} +#### Crie uma nova classe `WebSecurityConfig` em seu projeto \{#create-a-new-class-websecurityconfig-in-your-project} -A classe `WebSecurityConfig` será usada para configurar as configurações de segurança do seu aplicativo. É a classe chave que lidará com o fluxo de autenticação e autorização. Por favor, consulte a [documentação do Spring Security](https://spring.io/guides/topicals/spring-security-architecture) para mais detalhes. +A classe `WebSecurityConfig` será usada para configurar as definições de segurança do seu aplicativo. É a classe chave que irá lidar com o fluxo de autenticação e autorização. Consulte a [documentação do Spring Security](https://spring.io/guides/topicals/spring-security-architecture) para mais detalhes. ```java title="WebSecurityConfig.java" package com.example.securingweb; @@ -115,9 +115,9 @@ public class WebSecurityConfig { } ``` -#### Criar um bean `idTokenDecoderFactory` \{#create-a-idtokendecoderfactory-bean} +#### Crie um bean `idTokenDecoderFactory` \{#create-a-idtokendecoderfactory-bean} -Isso é necessário porque o Logto usa `ES384` como o algoritmo padrão, precisamos sobrescrever o `OidcIdTokenDecoderFactory` padrão para usar o mesmo algoritmo. +Isso é necessário porque o Logto usa `ES384` como algoritmo padrão, precisamos sobrescrever o `OidcIdTokenDecoderFactory` padrão para usar o mesmo algoritmo. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -138,9 +138,9 @@ public class WebSecurityConfig { } ``` -#### Criar uma classe LoginSuccessHandler para lidar com o evento de sucesso de login \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} +#### Crie uma classe LoginSuccessHandler para lidar com o evento de sucesso no login \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} -Redirecionaremos o usuário para a página `/user` após um login bem-sucedido. +Vamos redirecionar o usuário para a página `/user` após um login bem-sucedido. ```java title="CustomSuccessHandler.java" package com.example.securingweb; @@ -163,7 +163,7 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { } ``` -#### Criar uma classe LogoutSuccessHandler para lidar com o evento de sucesso de logout \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} +#### Crie uma classe LogoutSuccessHandler para lidar com o evento de sucesso no logout \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} Limpe a sessão e redirecione o usuário para a página inicial. @@ -195,11 +195,11 @@ public class CustomLogoutHandler implements LogoutSuccessHandler { } ``` -#### Atualizar a classe `WebSecurityConfig` com um `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} +#### Atualize a classe `WebSecurityConfig` com um `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} -[securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) é uma cadeia de filtros responsáveis por processar as solicitações e respostas recebidas. +O [securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) é uma cadeia de filtros responsável por processar as requisições e respostas recebidas. -Configuraremos o `securityFilterChain` para permitir o acesso à página inicial e exigir autenticação para todas as outras solicitações. Use o `CustomSuccessHandler` e o `CustomLogoutHandler` para lidar com os eventos de login e logout. +Vamos configurar o `securityFilterChain` para permitir acesso à página inicial e exigir autenticação para todas as outras requisições. Use o `CustomSuccessHandler` e o `CustomLogoutHandler` para lidar com os eventos de login e logout. ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -215,7 +215,7 @@ public class WebSecurityConfig { .authorizeRequests(authorizeRequests -> authorizeRequests .antMatchers("/", "/home").permitAll() // Permitir acesso à página inicial - .anyRequest().authenticated() // Todas as outras solicitações exigem autenticação + .anyRequest().authenticated() // Todas as outras requisições exigem autenticação ) .oauth2Login(oauth2Login -> oauth2Login @@ -230,7 +230,7 @@ public class WebSecurityConfig { } ``` -### Criar uma página inicial \{#create-a-home-page} +### Crie uma página inicial \{#create-a-home-page} (Você pode pular esta etapa se já tiver uma página inicial em seu projeto) @@ -251,7 +251,7 @@ public class HomeController { } ``` -Este controlador redirecionará o usuário para a página do usuário se o usuário estiver autenticado, caso contrário, mostrará a página inicial. Adicione um link de login à página inicial. +Este controller irá redirecionar o usuário para a página de usuário se ele estiver autenticado, caso contrário, mostrará a página inicial. Adicione um link de login à página inicial. ```html title="resources/templates/home.html" @@ -261,9 +261,9 @@ Este controlador redirecionará o usuário para a página do usuário se o usuá ``` -### Criar uma página de usuário \{#create-a-user-page} +### Crie uma página de usuário \{#create-a-user-page} -Crie um novo controlador para lidar com a página do usuário: +Crie um novo controller para lidar com a página de usuário: ```java title="UserController.java" package com.example.securingweb; @@ -299,7 +299,7 @@ public class UserController { } ``` -Uma vez que o usuário está autenticado, recuperaremos os dados do `OAuth2User` do objeto principal autenticado. Por favor, consulte [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) e [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) para mais detalhes. +Uma vez que o usuário está autenticado, vamos recuperar os dados do `OAuth2User` a partir do objeto principal autenticado. Consulte [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) e [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) para mais detalhes. Leia os dados do usuário e passe-os para o template `user.html`. @@ -326,24 +326,24 @@ Leia os dados do usuário e passe-os para o template `user.html`. -Para recuperar informações adicionais do usuário, você pode adicionar escopos extras ao arquivo `application.properties`. Por exemplo, para solicitar o escopo `email`, `phone` e `urn:logto:scope:organizations`, adicione a seguinte linha ao arquivo `application.properties`: +Para recuperar informações adicionais do usuário, você pode adicionar escopos extras ao arquivo `application.properties`. Por exemplo, para solicitar os escopos `email`, `phone` e `urn:logto:scope:organizations`, adicione a seguinte linha ao arquivo `application.properties`: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -Então você pode acessar as reivindicações adicionais no objeto `OAuth2User`. +Depois, você poderá acessar as reivindicações adicionais no objeto `OAuth2User`. -### Executar e testar o aplicativo \{#run-and-test-the-application} +### Execute e teste o aplicativo \{#run-and-test-the-application} -Execute o aplicativo e navegue até `http://localhost:8080`. +Execute o aplicativo e acesse `http://localhost:8080`. - Você verá a página inicial com um link de login. - Clique no link para fazer login com o Logto. -- Após a autenticação bem-sucedida, você será redirecionado para a página do usuário com seus detalhes de usuário. +- Após a autenticação bem-sucedida, você será redirecionado para a página de usuário com seus detalhes. - Clique no botão de logout para sair. Você será redirecionado de volta para a página inicial. -## Escopos e Reivindicações \{#scopes-and-claims} +## Escopos e Reivindicações (Scopes and Claims) \{#scopes-and-claims} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index 904e613ebee..b2d559761e3 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -12,45 +12,45 @@ O conjunto de tokens de terceiros (também conhecido como conjunto de tokens fed ## Casos de uso comuns \{#common-use-cases} -Essa capacidade é essencial para aplicativos modernos como agentes de IA, plataformas SaaS, ferramentas de produtividade e aplicativos para clientes que precisam interagir com serviços de terceiros em nome dos usuários. Aqui estão alguns exemplos práticos: +Essa capacidade é essencial para aplicativos modernos como agentes de IA, plataformas SaaS, ferramentas de produtividade e aplicativos de clientes que precisam interagir com serviços de terceiros em nome dos usuários. Aqui estão alguns exemplos práticos: **📅 Aplicativos de gerenciamento de calendário**: Após um usuário fazer login com o Google, seu aplicativo de produtividade pode sincronizar automaticamente os eventos do calendário, criar novas reuniões e enviar convites sem pedir que ele se autentique novamente. **🤖 Assistentes de IA**: Um agente de IA pode acessar os repositórios do GitHub de um usuário para analisar código, criar pull requests ou gerenciar issues. Tudo com o consentimento único do usuário durante o login ou vinculação de conta. -**📊 Dashboards de análise**: Plataformas SaaS podem extrair dados das contas de redes sociais conectadas dos usuários (Facebook, LinkedIn) para gerar insights e relatórios sem interromper o fluxo de trabalho com solicitações de login repetidas. +**📊 Dashboards de análise**: Plataformas SaaS podem extrair dados das contas de redes sociais conectadas dos usuários (Facebook, LinkedIn) para gerar insights e relatórios sem interromper o fluxo de trabalho com solicitações repetidas de login. -## Habilitar armazenamento de tokens de terceiros \{#enable-third-party-token-storage} +## Ativar armazenamento de tokens de terceiros \{#enable-third-party-token-storage} ### Conectores sociais \{#social-connectors} -Esse recurso está disponível para [conectores sociais](/connectors/social-connectors) que suportam armazenamento de tokens. Os tokens de terceiros podem ser armazenados durante o [login social](/end-user-flows/sign-up-and-sign-in/social-sign-in), [vinculação de conta social](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) e [ao renovar tokens para acesso à API de terceiros](/secret-vault/federated-token-set#reauthentication-and-token-renewal). Os conectores atualmente suportados incluem: [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [OAuth 2.0 padrão](/integrations/oauth2) e [OIDC padrão](/integrations/oidc). O suporte para conectores adicionais será disponibilizado gradualmente. +Esse recurso está disponível para [conectores sociais](/connectors/social-connectors) que suportam armazenamento de tokens. Os tokens de terceiros podem ser armazenados durante o [login social](/end-user-flows/sign-up-and-sign-in/social-sign-in), [vinculação de conta social](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) e [ao renovar tokens para acesso à API de terceiros](/secret-vault/federated-token-set#reauthentication-and-token-renewal). Os conectores atualmente suportados incluem: [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [OAuth 2.0 padrão](/integrations/oauth2) e [OIDC padrão](/integrations/oidc). O suporte para conectores adicionais será lançado gradualmente. 1. Navegue até Console > Conectores > Conectores Sociais. -2. Selecione o conector social para o qual deseja habilitar o armazenamento de tokens de terceiros. +2. Selecione o conector social para o qual deseja ativar o armazenamento de tokens de terceiros. 3. Siga os tutoriais de configuração para configurar o conector, incluindo a adição dos escopos necessários para acessar APIs de terceiros específicas. -4. Na página "Configuração", habilite a opção **Armazenar tokens para acesso persistente à API**. +4. Na página "Configuração", ative a opção **Armazenar tokens para acesso persistente à API**. ### Conectores SSO corporativos \{#enterprise-sso-connectors} O armazenamento de tokens está disponível para todos os [conectores corporativos OIDC](/connectors/enterprise-connectors). Tokens de acesso e atualização podem ser armazenados durante o [Single Sign-On corporativo](/end-user-flows/enterprise-sso). Os conectores atualmente suportados incluem: [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc), [Okta](/integrations/okta) e [OIDC (Enterprise)](/integrations/oidc-sso). 1. Navegue até Console > SSO Corporativo. -2. Selecione o conector SSO corporativo para o qual deseja habilitar o armazenamento de tokens de terceiros. +2. Selecione o conector SSO corporativo para o qual deseja ativar o armazenamento de tokens de terceiros. 3. Siga os tutoriais de configuração para configurar o conector, incluindo a adição dos escopos necessários para acessar APIs de terceiros específicas. -4. Na guia "Experiência SSO", habilite a opção **Armazenar tokens para acesso persistente à API**. +4. Na guia "Experiência SSO", ative a opção **Armazenar tokens para acesso persistente à API**. Certifique-se de salvar suas alterações. ## Armazenamento de tokens \{#token-storage} -Uma vez que o armazenamento de tokens de terceiros esteja habilitado, o Logto armazena automaticamente os tokens de acesso e atualização emitidos pelo provedor de identidade federado sempre que um usuário se autentica por meio de um conector social ou SSO corporativo. Isso inclui: +Uma vez que o armazenamento de tokens de terceiros está ativado, o Logto armazena automaticamente os tokens de acesso e atualização emitidos pelo provedor de identidade federado sempre que um usuário se autentica por meio de um conector social ou SSO corporativo. Isso inclui: - [Login e cadastro social](/end-user-flows/sign-up-and-sign-in/social-sign-in) -- [Login e cadastro via SSO corporativo](/end-user-flows/enterprise-sso) +- [Login e cadastro SSO corporativo](/end-user-flows/enterprise-sso) - [Vinculação de conta social via Account API](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -Os tokens armazenados são vinculados à identidade social ou SSO corporativa do usuário, permitindo que ele recupere os tokens posteriormente para acesso à API sem exigir nova autenticação. +Os tokens armazenados são vinculados à identidade social ou SSO corporativa do usuário, permitindo que eles recuperem os tokens posteriormente para acesso à API sem exigir nova autenticação. ### Verificando o status do armazenamento de tokens \{#checking-token-storage-status} @@ -60,11 +60,11 @@ Você pode verificar o status do armazenamento de tokens de terceiros de um usu 2. Clique no usuário que deseja inspecionar. Isso o levará à página de detalhes do usuário. 3. Role até a seção **Conexões**. Esta área lista todas as conexões sociais e SSO corporativas associadas ao usuário. 4. Cada entrada de conexão mostra um rótulo de status do token indicando se os tokens estão armazenados para essa conexão. -5. Clique na entrada da conexão para ver mais detalhes, incluindo os metadados do token de acesso armazenado e a disponibilidade do token de atualização (se disponível). +5. Clique na entrada da conexão para ver mais detalhes, incluindo metadados do token de acesso armazenado e disponibilidade do token de atualização (se disponível). Você também pode verificar as identidades de terceiros do usuário e o status do armazenamento de tokens via Management API: -- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`: Recupera a identidade social de um usuário e o status do armazenamento de tokens associado à identidade por um determinado conector (por exemplo, `github`, `google`, etc.). +- `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`: Recupera a identidade social de um usuário e o status do armazenamento de tokens associado à identidade por um determinado target de conector (por exemplo, `github`, `google`, etc.). - `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`: Recupera a identidade SSO corporativa de um usuário e o status do armazenamento de tokens associado à identidade por um determinado ID de conector SSO. ### Status do armazenamento de tokens \{#token-storage-status} @@ -81,7 +81,7 @@ Para integridade e segurança dos dados, todos os tokens são criptografados ant - `createdAt`: O timestamp de quando a conexão foi estabelecida pela primeira vez e o conjunto de tokens foi inicialmente armazenado no cofre de segredos. - `updatedAt`: A última vez que o conjunto de tokens foi atualizado. - Se nenhum token de atualização estiver disponível, esse valor será o mesmo que **createdAt**. - - Se houver um token de atualização, esse valor reflete a última vez que o token de acesso foi renovado. + - Se houver um token de atualização, esse valor reflete a última vez que o token de acesso foi atualizado. - `hasRefreshToken`: Indica se um token de atualização está disponível. Se o conector suportar acesso offline e a solicitação de autorização estiver devidamente configurada, o Logto armazena o token de atualização quando ele é emitido pelo provedor de identidade junto com o token de acesso. Quando o token de acesso expira e existe um token de atualização válido, o Logto tenta automaticamente obter um novo token de acesso usando o token de atualização armazenado sempre que o usuário solicita acesso ao provedor conectado. @@ -94,14 +94,14 @@ Para integridade e segurança dos dados, todos os tokens são criptografados ant ## Recuperação de tokens \{#token-retrieval} -Uma vez que o armazenamento de tokens esteja habilitado e os tokens estejam armazenados com segurança no cofre de segredos do Logto, os usuários finais podem recuperar seus tokens de acesso de terceiros a partir do seu aplicativo cliente integrando com a [Account API](/end-user-flows/account-settings/by-account-api) do Logto. +Uma vez que o armazenamento de tokens está ativado e os tokens estão armazenados com segurança no cofre de segredos do Logto, os usuários finais podem recuperar seus tokens de acesso de terceiros a partir do seu aplicativo cliente integrando com a [Account API](/end-user-flows/account-settings/by-account-api) do Logto. -- `GET /my-account/identities/:target/access-token`: Recupera o token de acesso para uma identidade social especificando o conector (por exemplo, github, google). +- `GET /my-account/identities/:target/access-token`: Recupera o token de acesso para uma identidade social especificando o target do conector (por exemplo, github, google). - `GET /my-account/sso-identities/:connectorId/access-token`: Recupera o token de acesso para uma identidade SSO corporativa especificando o ID do conector. :::info -Saiba como [habilitar](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) e [acessar](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) a Account API usando o token de acesso emitido pelo Logto. +Para recuperar tokens de acesso de terceiros, você deve primeiro ativar a Account API para usuários finais em Console > Login & Conta > Central da conta. Saiba como [ativar a Account API](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) e [acessá-la usando um token de acesso emitido pelo Logto](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token). ::: ### Rotação de tokens \{#token-rotation} @@ -109,10 +109,10 @@ Saiba como [habilitar](/end-user-flows/account-settings/by-account-api#how-to-en Os endpoints de recuperação de tokens retornam: - `200` OK: Se o token de acesso for recuperado com sucesso e ainda estiver válido. -- `404` Não encontrado: Se o usuário não tiver uma identidade social ou SSO corporativa associada ao conector especificado, ou se o token de acesso não estiver armazenado. +- `404` Não encontrado: Se o usuário não tiver uma identidade social ou SSO corporativa associada ao target ou ID de conector especificado, ou se o token de acesso não estiver armazenado. - `401` Não autorizado: Se o token de acesso estiver expirado. -Se o token de acesso estiver expirado e um token de atualização estiver disponível, o Logto tentará automaticamente renovar o token de acesso e retornará o novo token de acesso na resposta. O armazenamento do token no cofre de segredos também será atualizado com o novo token de acesso e seus metadados. +Se o token de acesso estiver expirado e um token de atualização estiver disponível, o Logto tentará automaticamente atualizar o token de acesso e retornará o novo token de acesso na resposta. O armazenamento do token no cofre de segredos também será atualizado com o novo token de acesso e seus metadados. ## Exclusão do armazenamento de tokens \{#token-storage-deletion} @@ -131,16 +131,16 @@ Você também pode excluir manualmente o conjunto de tokens de terceiros de um u - Via Management API: - `DELETE /api/secret/:id`: Exclui um segredo específico pelo seu ID, que pode ser obtido nos detalhes da identidade do usuário. -Revogar o conjunto de tokens forçará o usuário a se autenticar novamente com o provedor de terceiros para obter um novo token de acesso antes de poder acessar as APIs de terceiros novamente. +Revogar o conjunto de tokens forçará o usuário a se autenticar novamente com o provedor de terceiros para obter um novo token de acesso antes de poder acessar APIs de terceiros novamente. ## Reautenticação e renovação de tokens \{#reauthentication-and-token-renewal} -Em cenários onde um token de acesso armazenado expirou ou quando um aplicativo precisa solicitar escopos adicionais de API, os usuários finais podem se reautenticar com o provedor de terceiros para obter um novo token de acesso—sem precisar fazer login novamente no Logto. -Isso pode ser feito através da [Social Verification API](https://openapi.logto.io/operation/operation-createverificationbysocial) do Logto, que permite aos usuários reiniciar um fluxo de autorização social federada e atualizar seu conjunto de tokens armazenado. +Em cenários onde um token de acesso armazenado expirou ou quando um aplicativo precisa solicitar escopos adicionais de API, os usuários finais podem se reautenticar com o provedor de terceiros para obter um novo token de acesso — sem precisar fazer login novamente no Logto. +Isso pode ser feito através da [Social Verification API](https://openapi.logto.io/operation/operation-createverificationbysocial) do Logto, que permite aos usuários reiniciar um fluxo de autorização social federado e atualizar seu conjunto de tokens armazenado. :::note A reinicialização da autorização federada está atualmente limitada a conectores sociais. -Para conectores SSO corporativos, a reautenticação e renovação de tokens exigem que o usuário inicie novamente todo o fluxo de autenticação do Logto, pois a reautorização direta com o provedor SSO corporativo não é suportada após o login. +Para conectores SSO corporativos, a reautenticação e renovação de tokens exigem que o usuário inicie novamente um fluxo completo de autenticação Logto, pois a reautorização direta com o provedor SSO corporativo não é suportada após o login. ::: ```mermaid @@ -152,7 +152,7 @@ sequenceDiagram participant Provider as Provedor de terceiros User->>Logto: post /api/verification/social - Logto->>User: Redirecionar para o provedor de terceiros + Logto->>User: Redirecionar para provedor de terceiros User->>Provider: Autenticar e autorizar Provider->>User: Redirecionar de volta com código de autorização User->>Logto: post /api/verification/social/verify com código de autorização @@ -160,10 +160,10 @@ sequenceDiagram User->>Logto: patch /my-account/identities/:target/access-token ``` -1. O usuário inicia uma solicitação de verificação social chamando o endpoint `POST /api/verification/social`. O usuário pode especificar escopos personalizados para solicitar permissões adicionais ao provedor de terceiros. +1. O usuário inicia uma solicitação de verificação social chamando o endpoint `POST /api/verification/social`. O usuário pode especificar escopos personalizados para solicitar permissões adicionais do provedor de terceiros. ```sh - curl -X POST https:///api/verification/social \ + curl -X POST https:///api/verification/social \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ @@ -177,7 +177,7 @@ sequenceDiagram - **authorization header**: O token de acesso do usuário emitido pelo Logto. - **connectorId**: O ID do conector social no Logto. - **redirectUri**: O URI para redirecionar o usuário de volta ao seu aplicativo após a autenticação. Você precisará registrar esse URI nas configurações do aplicativo do provedor. - - **scope**: (Opcional) Escopos personalizados para solicitar permissões adicionais ao provedor de terceiros. Se não especificado, os escopos padrão configurados no conector serão usados. + - **scope**: (Opcional) Escopos personalizados para solicitar permissões adicionais do provedor de terceiros. Se não especificado, os escopos padrão configurados no conector serão usados. 2. O Logto cria um novo registro de verificação social e retorna o ID de verificação social junto com a URL de autorização para redirecionar o usuário ao provedor de terceiros para autenticação. @@ -198,7 +198,7 @@ sequenceDiagram 5. Trate o callback de autorização encaminhando o código de autorização para o endpoint de verificação do Logto: ```sh - curl -X POST https:///api/verification/social/verify \ + curl -X POST https:///api/verification/social/verify \ -H "Authorization: Bearer " \ -d '{ "verificationRecordId": "", @@ -223,7 +223,7 @@ sequenceDiagram 7. Por fim, atualize o armazenamento de tokens do usuário chamando o endpoint `PATCH /my-account/identities/:target/access-token` com o ID de verificação social: ```sh - curl -X PATCH https:///my-account/identities//access-token \ + curl -X PATCH https:///my-account/identities//access-token \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ @@ -232,7 +232,7 @@ sequenceDiagram ``` - **authorization header**: O token de acesso do usuário emitido pelo Logto. - - **socialVerificationId**: O ID do registro de verificação social retornado na etapa anterior. + - **socialVerificationId**: O ID do registro de verificação social verificado retornado na etapa anterior. Isso atualizará o armazenamento do conjunto de tokens do usuário no cofre de segredos do Logto com o novo token de acesso e token de atualização, permitindo que o usuário acesse APIs de terceiros sem precisar fazer login novamente no Logto. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/blocklist.md index fba182ff91f..08fd48c3fe0 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -1,40 +1,40 @@ --- slug: /security/blocklist -sidebar_label: Lista de bloqueio +sidebar_label: Blocklist sidebar_position: 3 --- -# Lista de bloqueio (Blocklist) +# Blocklist -## Lista de bloqueio de e-mails (Email blocklist) {#email-blocklist} +## Blocklist de e-mails {#email-blocklist} -A política de lista de bloqueio de e-mails permite a personalização das configurações de bloqueio para evitar abusos no cadastro de contas. Ela monitora os endereços de e-mail usados para cadastro e configurações de conta. Se um usuário tentar se cadastrar ou vincular um endereço de e-mail que viole alguma regra da lista de bloqueio, o sistema rejeitará a solicitação, ajudando a mitigar contas de spam e aumentar a segurança geral das contas. +A política de blocklist de e-mails permite a personalização das configurações de blocklist para prevenir abusos no cadastro de contas. Ela monitora os endereços de e-mail usados para cadastro e configurações de conta. Se um usuário tentar se cadastrar ou vincular um endereço de e-mail que viole alguma regra da blocklist, o sistema rejeitará a solicitação, ajudando a mitigar contas de spam e aumentar a segurança geral das contas. -Acesse o Console > Segurança > Lista de bloqueio para configurar as definições da lista de bloqueio de e-mails. +Acesse o Console > Segurança > Blocklist para configurar as definições da blocklist de e-mails. -### Bloquear endereços de e-mail descartáveis (Block disposable email addresses) {#block-disposable-email-addresses} +### Bloquear endereços de e-mail descartáveis {#block-disposable-email-addresses} -Este é um recurso **exclusivo da nuvem**. Uma vez ativado, o sistema validará automaticamente o domínio do endereço de e-mail fornecido em relação a uma lista de domínios de e-mail descartáveis conhecidos. Se o domínio estiver na lista, a solicitação será rejeitada. A lista de domínios descartáveis é atualizada regularmente para garantir sua eficácia. +Este é um recurso **exclusivo da nuvem**. Uma vez habilitado, o sistema validará automaticamente o domínio do endereço de e-mail fornecido em relação a uma lista de domínios de e-mail descartáveis conhecidos. Se o domínio estiver na lista, a solicitação será rejeitada. A lista de domínios descartáveis é atualizada regularmente para garantir sua eficácia. -### Bloquear subendereçamento de e-mail (Block email subaddressing) {#block-email-subaddressing} +### Bloquear subendereçamento de e-mail {#block-email-subaddressing} -O subendereçamento de e-mail permite que os usuários criem variações de seus endereços de e-mail adicionando um sinal de mais (+) seguido de caracteres adicionais (por exemplo, usuario+tag@exemplo.com). Esse recurso pode ser explorado por usuários mal-intencionados para contornar restrições da lista de bloqueio. Ao ativar o bloqueio de subendereçamento, o sistema rejeitará qualquer tentativa de cadastro ou vinculação de conta que utilize formatos de e-mail com subendereçamento. +O subendereçamento de e-mail permite que os usuários criem variações de seus endereços de e-mail adicionando um sinal de mais (+) seguido de caracteres adicionais (ex.: usuario+tag@exemplo.com). Esse recurso pode ser explorado por usuários mal-intencionados para contornar restrições da blocklist. Ao habilitar o bloqueio de subendereçamento de e-mail, o sistema rejeitará qualquer tentativa de cadastro ou vinculação de conta que utilize formatos de e-mail com subendereçamento. -### Lista de bloqueio de e-mails personalizada (Custom email blocklist) {#custom-email-blocklist} +### Blocklist de e-mails personalizada {#custom-email-blocklist} -Você pode criar uma lista de bloqueio personalizada especificando uma lista de endereços de e-mail ou domínios a serem bloqueados. O sistema rejeitará qualquer tentativa de cadastro ou vinculação de conta que corresponda a essas entradas. A lista de bloqueio suporta tanto correspondência de endereço de e-mail completo quanto de domínio. +Você pode criar uma blocklist personalizada especificando uma lista de endereços de e-mail ou domínios a serem bloqueados. O sistema rejeitará qualquer tentativa de cadastro ou vinculação de conta que corresponda a essas entradas. A blocklist suporta tanto correspondência de endereço de e-mail completo quanto de domínio. -Por exemplo, ao adicionar `@example.com` à lista de bloqueio, todos os endereços de e-mail com esse domínio serão bloqueados. Da mesma forma, ao adicionar `foo@example.com`, apenas esse endereço de e-mail será bloqueado. +Por exemplo, ao adicionar `@exemplo.com` à blocklist, todos os endereços de e-mail com esse domínio serão bloqueados. Da mesma forma, ao adicionar `foo@exemplo.com`, apenas esse endereço de e-mail será bloqueado. :::note -E-mails descartáveis, subendereçamento e e-mails personalizados são restritos durante o registro e a vinculação de contas. Usuários existentes com esses endereços de e-mail ainda podem fazer login. +E-mails descartáveis, subendereçamento e e-mails personalizados são restritos durante [registro de novo usuário](/end-user-flows/sign-up-and-sign-in/sign-up), [vinculação de e-mail durante login social](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers) e atualização de e-mails via [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email). Usuários existentes com esses endereços de e-mail ainda podem fazer login. -- Os administradores podem "ignorar restrições" adicionando usuários manualmente em Console > Gerenciamento de usuários, ou via [Management API](https://openapi.logto.io/operation/operation-createuser). Exemplo: Criar um usuário com e-mail subendereçado quando o subendereçamento está bloqueado. +- Admins podem "ignorar restrições" adicionando usuários manualmente em Console > Gerenciamento de usuários, ou via [Management API](https://openapi.logto.io/operation/operation-createuser). Ex.: Criar um usuário com e-mail de subendereçamento quando o subendereçamento está bloqueado. - Bloqueie contas existentes excluindo ou suspendendo-as em Console > Gerenciamento de usuários. ::: ## Recursos relacionados {#related-resources} -O que é e-mail descartável? Como lidar com eles em seu aplicativo? +O que é e-mail descartável? Como lidar com eles no seu app? diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/password-policy.mdx index 29f07f31a5d..5d91a46cc1c 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,9 +6,15 @@ sidebar_position: 1 # Política de senha +O Logto aplica a política de senha de diferentes maneiras, dependendo de como a senha é criada ou atualizada: + +- Fluxos de usuário final, como [a experiência de login pronta para uso](/end-user-flows/sign-up-and-sign-in/sign-up), [a Experience API](/customization/bring-your-ui) e [a Account API](/end-user-flows/account-settings/by-account-api#update-users-password) sempre aplicam a [política de senha](#set-up-password-policy) atual. +- Ações de administrador via Management API [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) são isentas, permitindo provisionar ou redefinir credenciais sem verificações de política quando necessário. +- Para auditar senhas existentes em relação às regras atuais, chame [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) e aja conforme o resultado da validação retornado. Leia [Verificação de conformidade de senha](#password-compliance-check) para saber mais. + ## Configurar política de senha \{#set-up-password-policy} -Para novos usuários ou usuários que estão atualizando sua senha, você pode definir uma política de senha para impor requisitos de força de senha. Visite o Console > Segurança > Política de senha para configurar as definições da política de senha. +Para novos usuários ou usuários que estão atualizando sua senha, você pode definir uma política de senha para impor requisitos de força. Acesse o Console > Segurança > Política de senha para configurar as definições da política de senha. 1. **Comprimento mínimo da senha**: Defina o número mínimo de caracteres exigidos para a senha. (O NIST sugere usar pelo menos 8 [caracteres](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) 2. **Tipos mínimos de caracteres exigidos**: Defina o número mínimo de tipos de caracteres exigidos para a senha. Os tipos de caracteres disponíveis são: @@ -21,12 +27,17 @@ Para novos usuários ou usuários que estão atualizando sua senha, você pode d 5. **Verificação de informações do usuário**: Ative esta configuração para rejeitar senhas que contenham informações do usuário, como nome de usuário, endereço de e-mail ou número de telefone. 6. **Palavras personalizadas**: Forneça uma lista de palavras personalizadas (não diferencia maiúsculas de minúsculas) que você deseja rejeitar na senha. -## Verificação de conformidade da senha \{#password-compliance-check} +## Verificação de conformidade de senha \{#password-compliance-check} -Após atualizar a política de senha no Logto, os usuários existentes ainda poderão fazer login com suas senhas atuais. Somente contas recém-criadas serão obrigadas a seguir a política atualizada. +Após atualizar a política de senha no Logto, os usuários existentes ainda poderão fazer login com suas senhas atuais. Apenas contas recém-criadas serão obrigadas a seguir a política atualizada. -Para impor uma segurança mais forte, você pode usar o `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) para verificar se a senha de um usuário atende à política atual definida na experiência de login padrão. Caso não atenda, você pode solicitar ao usuário que atualize sua senha com um fluxo personalizado usando a [Account API](/end-user-flows/account-settings/by-management-api#user-password-management). +Para impor uma segurança mais forte, você pode usar a [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) `POST /api/sign-in-exp/default/check-password` para verificar se a senha de um usuário atende à política atual definida na experiência de login padrão. Caso não atenda, você pode solicitar ao usuário que atualize sua senha com um fluxo personalizado usando a [Account API](/end-user-flows/account-settings/by-account-api). ## Recursos relacionados \{#related-resources} +Gerenciar usuários +Cadastro e login + + Configurações de conta pela Account API + Desenhe sua política de senha diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index 8029f904454..5184c7e9c0f 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -8,8 +8,7 @@ sidebar_position: 2 ### Navegar e pesquisar usuários \{#browse-and-search-users} -Para acessar a funcionalidade de gerenciamento de usuários no Logto Console, navegue até Console > Gerenciamento de usuários. -Uma vez lá, você verá uma visualização em tabela de todos os usuários. +Para acessar a funcionalidade de gerenciamento de usuários no Logto Console, navegue até Console > Gerenciamento de usuários. Uma vez lá, você verá uma visualização em tabela de todos os usuários. A tabela consiste em três colunas: @@ -25,7 +24,7 @@ Usando o Console, desenvolvedores podem criar novas contas para usuários finais Ao criar um usuário no Logto Console ou via Management API (não auto-registro pelo usuário final via UI), é necessário fornecer pelo menos um identificador: `primary email`, `primary phone` ou `username`. O campo `name` é opcional. -Após a criação do usuário, o Logto irá gerar automaticamente uma senha aleatória. A senha inicial aparecerá apenas uma vez, mas você pode [redefinir a senha](./manage-users#reset-user-password) posteriormente. Se desejar definir uma senha específica, utilize o endpoint `patch /api/users/{userId}/password` da Management API para atualizá-la após a criação do usuário. +Após a criação do usuário, o Logto irá gerar automaticamente uma senha aleatória. A senha inicial aparecerá apenas uma vez, mas você pode [redefinir a senha](./manage-users#reset-user-password) posteriormente. Se quiser definir uma senha específica, utilize o Management API `patch /api/users/{userId}/password` para atualizá-la após a criação do usuário. Você pode copiar os **identificadores inseridos (endereço de e-mail / número de telefone / nome de usuário)** e a **senha inicial** com um clique, facilitando o compartilhamento dessas credenciais com o novo usuário para que ele possa fazer login e começar a usar. @@ -44,10 +43,17 @@ Para visualizar os detalhes de um usuário, basta clicar na linha correspondente - **Número de telefone** ([primary_phone](/user-management/user-data#primary_phone)): Editável - **Nome de usuário** ([username](/user-management/user-data#username)): Editável - **Senha** ([has_password](/user-management/user-data#has_password)): Você pode gerar uma nova senha aleatória. Saiba mais em "[Redefinir senha do usuário](#reset-user-password)". - - **Conexões sociais** ([identities](/user-management/user-data#social-identities)): Visualize contas sociais vinculadas e IDs sociais. Por exemplo, se o usuário fez login usando sua conta do Facebook, você verá um item "Facebook" na lista. Você pode remover uma identidade social vinculada no Console, mas não pode vincular uma nova em nome do usuário final. - - **Conexões SSO corporativas (Enterprise SSO)** ([sso_identities](/user-management/user-data#sso-identities)): Visualize identidades corporativas vinculadas. Não é possível adicionar ou remover identidades SSO no Console. - - **Autenticação multifatorial (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): Visualize todos os fatores de autenticação (por exemplo, passkeys, aplicativos autenticadores, códigos de backup) que este usuário configurou. Os fatores podem ser removidos no Console. - - **Token de acesso pessoal**: Crie, visualize, renomeie e exclua [tokens de acesso pessoal](/user-management/personal-access-token). + - **Autenticação multifatorial (Multi-factor authentication)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): Veja todos os fatores de autenticação (por exemplo, passkeys, aplicativos autenticadores, códigos de backup) que este usuário configurou. Os fatores podem ser removidos no Console. + - **Token de acesso pessoal (Personal access token)**: Crie, visualize, renomeie e exclua [tokens de acesso pessoal](/user-management/personal-access-token). +- **Conexão**: + - **Conexões sociais (Social connections)** ([identities](/user-management/user-data#social-identities)): + - Veja as contas sociais vinculadas do usuário, incluindo IDs sociais e detalhes do perfil sincronizados dos provedores sociais (por exemplo, uma entrada "Facebook" aparecerá se o usuário fez login via Facebook). + - Você pode remover identidades sociais existentes, mas não pode vincular novas contas sociais em nome do usuário. + - Para conectores sociais com [armazenamento de token](/secret-vault/federated-token-set) habilitado, você pode visualizar e gerenciar tokens de acesso e tokens de atualização na página de detalhes da conexão. + - **Conexões SSO corporativas (Enterprise SSO connections)** ([sso_identities](/user-management/user-data#sso-identities)): + - Veja as identidades corporativas vinculadas do usuário, incluindo IDs corporativos e detalhes do perfil sincronizados dos provedores de identidade corporativos. + - Você não pode adicionar ou remover identidades SSO corporativas no Console. + - Para conectores corporativos baseados em OIDC com [armazenamento de token](/secret-vault/federated-token-set) habilitado, você pode visualizar e excluir tokens na página de detalhes da conexão. - **Dados do perfil do usuário**: nome, URL do avatar, dados personalizados e reivindicações padrão adicionais do OpenID Connect que não estão incluídas. Todos esses campos de perfil são editáveis. :::warning @@ -68,7 +74,7 @@ Na página de detalhes do usuário, clique em "Três pontos" -> botão "Suspende Uma vez suspenso, o usuário não poderá fazer login no seu aplicativo e não conseguirá obter um novo token de acesso após o atual expirar. Além disso, quaisquer solicitações de API feitas por esse usuário falharão. -Se desejar reativar esse usuário, basta clicar em "Três pontos" -> botão "Reativar usuário". +Se quiser reativar esse usuário, basta clicar em "Três pontos" -> botão "Reativar usuário". ### Excluir usuário \{#delete-user} @@ -76,11 +82,17 @@ Na página de detalhes do usuário, clique em "Três pontos" -> botão "Excluir" ### Redefinir senha do usuário \{#reset-user-password} -Na página de detalhes do usuário, clique em "Três pontos" -> botão "Redefinir senha", e então o Logto irá gerar automaticamente uma nova senha aleatória. +Na página de detalhes do usuário, clique em "Três pontos" -> botão "Redefinir senha", e então o Logto irá gerar automaticamente uma senha aleatória. Após redefinir a senha, copie e envie para o usuário final. Uma vez que o modal "Redefinir senha" for fechado, não será mais possível visualizar a senha. Se esquecer de anotá-la, basta redefinir novamente. -Não é possível definir uma senha específica para usuários no Logto Console, mas você pode usar a [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` para especificar uma senha. +Você não pode definir uma senha específica para usuários no Logto Console, mas pode usar o [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` para especificar uma senha. + +## Verificação de conformidade de senha \{#password-compliance-check} + +Após atualizar a [política de senha](/security/password-policy) no Logto, os usuários existentes ainda poderão fazer login com suas senhas atuais. Apenas contas recém-criadas precisarão seguir a política de senha atualizada. + +Para reforçar a segurança, você pode usar o `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) para verificar se a senha de um usuário atende à política atual definida na experiência de login padrão. Caso não atenda, você pode solicitar que o usuário atualize sua senha com um fluxo personalizado usando o [Account API](/end-user-flows/account-settings/by-management-api#user-password-management). ### Gerenciar papéis dos usuários \{#manage-roles-of-users} @@ -88,17 +100,17 @@ Na aba "Papéis" da página de detalhes do usuário, você pode facilmente atrib ### Visualizar as organizações às quais o usuário pertence \{#view-the-organizations-the-user-belongs-to} -O Logto suporta [organizações](/organizations/organization-management) e pode gerenciar seus membros. Você pode facilmente visualizar os detalhes do usuário e ver a quais organizações ele pertence. +O Logto suporta [organizações](/organizations/organization-management) e pode gerenciar seus membros. Você pode facilmente visualizar os detalhes do usuário e ver a qual organização ele pertence. ## Gerenciar via Logto Management API \{#manage-via-logto-management-api} -A [Management API](/concepts/core-service/#management-api) é um conjunto de APIs que fornece acesso ao serviço backend do Logto. Como mencionado anteriormente, a API de usuário é um componente crítico deste serviço e pode suportar uma ampla gama de cenários. +O [Management API](/concepts/core-service/#management-api) é um conjunto de APIs que fornecem acesso ao serviço backend do Logto. Como mencionado anteriormente, a API de usuário é um componente crítico desse serviço e pode suportar uma ampla variedade de cenários. As APIs [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) relacionadas a usuários estão disponíveis em `/api/users`, exceto para atividades do usuário, ou seja, logs de usuário em `/api/logs?userId=:userId`. -Você pode gerenciar usuários através da Management API em diversos casos de uso, como [pesquisa avançada de usuários](/user-management/advanced-user-search), [criação em massa de contas](https://openapi.logto.io/operation/operation-createuser), [registro apenas por convite](/end-user-flows/sign-up-and-sign-in/disable-user-registration), etc. +Você pode gerenciar usuários através do Management API em vários casos de uso, como [pesquisa avançada de usuários](/user-management/advanced-user-search), [criação em massa de contas](https://openapi.logto.io/operation/operation-createuser), [registro apenas por convite](/end-user-flows/sign-up-and-sign-in/disable-user-registration), etc. -## Perguntas frequentes (FAQs) \{#faqs} +## Perguntas frequentes \{#faqs}
@@ -108,8 +120,8 @@ Você pode gerenciar usuários através da Management API em diversos casos de u -Devido à natureza do [Omni-sign-in](https://logto.io/products/omni-sign-in) do Logto, ele não foi projetado para restringir o acesso do usuário a determinados aplicativos antes da autenticação. -No entanto, ainda é possível definir papéis e permissões específicos por aplicativo para proteger seus recursos de API e validar permissões no acesso à API após o login bem-sucedido do usuário. +Devido à natureza do [Omni-sign-in](https://logto.io/products/omni-sign-in) do Logto, ele não foi projetado para restringir o acesso de usuários a determinados aplicativos antes da autenticação. +No entanto, ainda é possível criar papéis e permissões específicas para cada aplicativo para proteger seus recursos de API, e validar permissões no acesso à API após o login bem-sucedido do usuário. Consulte Autorização: [Controle de acesso baseado em papel (RBAC)](/authorization/role-based-access-control) para mais informações.
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index eab5d587ae4..f432b7dea36 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -48,8 +48,7 @@ Aqui está um exemplo de dados de um usuário recuperados de um login pelo Faceb } ``` -Você pode consultar o perfil do usuário usando Logto Console -ou Logto Management API, como [`GET /api/users/:userId`](https://openapi.logto.io/operation/operation-getuser). +Você pode consultar o perfil do usuário usando o Logto Console ou o Logto Management API, como [`GET /api/users/:userId`](https://openapi.logto.io/operation/operation-getuser). ## Dados básicos \{#basic-data} @@ -61,7 +60,7 @@ _id_ é uma chave única gerada automaticamente para identificar o usuário no L ### username \{#username} -_username_ é usado para login com _nome de usuário_ e senha. +_username_ é usado para login com _username_ e senha. Seu valor vem do nome de usuário com o qual o usuário se registrou pela primeira vez. Pode ser `null`. Seu valor não nulo deve ter no máximo 128 caracteres, conter apenas letras, números e sublinhados (`_`), e NÃO começar com um número. É sensível a maiúsculas e minúsculas. @@ -71,11 +70,15 @@ _primary_email_ é o endereço de email do usuário, usado para login com email Seu valor geralmente vem do endereço de email com o qual o usuário se registrou pela primeira vez. Pode ser `null`. Seu comprimento máximo é 128. +Apenas endereços de email verificados de provedores de identidade social ou SSO corporativo podem ser sincronizados e salvos como `primary_email`. + ### primary_phone \{#primary_phone} -_primary_phone_ é o número de telefone do usuário, usado para login com o número de telefone e senha / código de verificação por SMS. +_primary_phone_ é o número de telefone do usuário, usado para login com o número de telefone e senha / código de verificação via SMS. + +Seu valor geralmente vem do número de telefone com o qual o usuário se registrou pela primeira vez. Pode ser `null`. Seu valor não nulo deve conter números prefixados pelo [código de chamada do país](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (excluindo o sinal de mais `+`). -Seu valor geralmente vem do número de telefone com o qual o usuário se registrou pela primeira vez. Pode ser `null`. Seu valor não nulo deve conter números prefixados com o [código de discagem do país](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (excluindo o sinal de mais `+`). +Apenas números de telefone verificados de provedores de identidade social ou SSO corporativo podem ser sincronizados e salvos como `primary_phone`. ### name \{#name} @@ -83,7 +86,7 @@ _name_ é o nome completo do usuário. Seu comprimento máximo é 128. ### avatar \{#avatar} -_avatar_ é a URL que aponta para a imagem do avatar do usuário. Seu comprimento máximo é 2048. +_avatar_ é a URL que aponta para a imagem de avatar do usuário. Seu comprimento máximo é 2048. Se o usuário se registrar com um conector social como Google ou Facebook, seu valor pode ser recuperado das informações sociais do usuário. @@ -149,7 +152,7 @@ _updated_at_ é o timestamp com o fuso horário de quando as informações do pe ### has_password \{#has_password} -_has_password_ é um valor booleano que indica se o usuário possui uma senha. Você pode visualizar e gerenciar esse status, incluindo definir uma nova senha ou redefinir a senha na página de detalhes de Console > Gerenciamento de usuários. +_has_password_ é um valor booleano que indica se o usuário possui uma senha. Você pode visualizar e gerenciar esse status, incluindo definir uma nova senha ou redefinir a senha na página de detalhes do Console > Gerenciamento de usuários. ### password_encrypted \{#password_encrypted} @@ -161,7 +164,7 @@ Seu valor vem da senha com a qual o usuário se registrou pela primeira vez. Pod _password_encryption_method_ é usado para criptografar a senha do usuário. Seu valor é inicializado quando o usuário se registra com nome de usuário e senha. Pode ser `null`. -O Logto usa a implementação [node-argon2](https://github.com/ranisalt/node-argon2) do [Argon2](https://en.wikipedia.org/wiki/Argon2) como método de criptografia padrão; veja a referência para detalhes se estiver interessado. +O Logto usa a implementação [Argon2](https://en.wikipedia.org/wiki/Argon2) [node-argon2](https://github.com/ranisalt/node-argon2) como método de criptografia padrão; veja a referência para detalhes se tiver interesse. Exemplo de _password_encrypted_ e _password_encryption_method_ de um usuário cuja senha é `123456`: @@ -174,7 +177,7 @@ Exemplo de _password_encrypted_ e _password_encryption_method_ de um usuário cu ### is_suspended \{#is_suspended} -_is_suspended_ é um valor booleano que indica se um usuário está suspenso ou não. O valor pode ser gerenciado chamando a [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) ou usando o Logto Console. +_is_suspended_ é um valor booleano que indica se um usuário está suspenso ou não. O valor pode ser gerenciado chamando o [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) ou usando o Logto Console. Uma vez que um usuário é suspenso, os tokens de atualização previamente concedidos serão revogados imediatamente e o usuário não poderá mais ser autenticado pelo Logto. @@ -227,7 +230,7 @@ Exemplo de _identities_ de um usuário que fez login tanto com Google quanto com ## Identidades SSO \{#sso-identities} -_sso_identities_ contém as informações do usuário recuperadas do [SSO corporativo (Enterprise SSO)](/end-user-flows/enterprise-sso) (ou seja, login de autenticação única com um [conector corporativo](/connectors/enterprise-connectors)). Cada _ssoIdentities_ de usuário é armazenado em um objeto JSON individual. +_sso_identities_ contém as informações do usuário recuperadas do [SSO corporativo (Enterprise SSO)](/end-user-flows/enterprise-sso) (ou seja, login Single Sign-On com um [conector corporativo](/connectors/enterprise-connectors)). Cada _ssoIdentities_ de usuário é armazenado em um objeto JSON individual. Os dados sincronizados do provedor de identidade SSO dependem dos escopos configurados no conector corporativo para requisição. Aqui está uma cópia da definição de tipo TypeScript: @@ -277,23 +280,22 @@ NÃO coloque dados sensíveis em _custom_data_. Os dados personalizados podem ser acessados por meio de [Reivindicações personalizadas de token JWT](/developers/custom-token-claims) após o login do usuário, e os tokens JWT são codificados em base64 (não criptografados) e frequentemente transmitidos pela rede, tornando qualquer dado sensível facilmente exposto. -Você pode buscar um perfil de usuário contendo _custom_data_ usando a [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) e enviá-lo para aplicativos frontend ou serviços backend externos. Portanto, colocar informações sensíveis em _custom_data_ pode causar vazamento de dados. +Você pode buscar um perfil de usuário contendo _custom_data_ usando o [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) e enviá-lo para aplicativos frontend ou serviços backend externos. Portanto, colocar informações sensíveis em _custom_data_ pode causar vazamento de dados. -Se ainda assim quiser colocar informações sensíveis em _custom_data_, recomendamos criptografá-las primeiro. Só criptografe / descriptografe em uma parte confiável, como seus serviços backend, e evite fazer isso em aplicativos frontend. Isso minimizará a perda caso o _custom_data_ de seus usuários seja vazado por engano. +Se ainda assim quiser colocar informações sensíveis em _custom_data_, recomendamos criptografá-las primeiro. Só criptografe / descriptografe em uma parte confiável, como seus serviços backend, e evite fazer isso em aplicativos frontend. Isso minimizará as perdas caso o _custom_data_ dos seus usuários seja vazado por engano. **Como coletar e atualizar dados personalizados do usuário** - Use o recurso [Coletar perfil do usuário](/end-user-flows/collect-user-profile) para reunir dados personalizados durante o cadastro do usuário. -- Use a [Account API](/end-user-flows/account-settings/by-account-api) para implementar configurações de perfil ou conta do usuário final. +- Use o [Account API](/end-user-flows/account-settings/by-account-api) para implementar configurações de perfil ou conta do usuário final. - Use [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) para recuperar todos os dados do usuário. - Use [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) para atualizar o _custom_data_ de um usuário. -- Use a [Management API](/user-management/manage-users/#manage-via-logto-management-api) para gerenciamento de usuários ou fluxos personalizados avançados: +- Use o [Management API](/user-management/manage-users/#manage-via-logto-management-api) para gerenciamento de usuários ou fluxos personalizados avançados: - Use [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) para recuperar todos os dados do usuário. - Use [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) para atualizar o _custom_data_ de um usuário. -- Sua equipe de suporte pode atualizar diretamente o _custom_data_ do usuário em Console > Gerenciamento de usuários. - Saiba mais sobre [visualizar e atualizar perfis de usuário](/user-management/manage-users/#view-and-update-the-user-profile). +- Sua equipe de suporte pode atualizar diretamente o _custom_data_ do usuário em Console > Gerenciamento de usuários. Saiba mais sobre [visualizar e atualizar perfis de usuário](/user-management/manage-users/#view-and-update-the-user-profile). -Atualize com cuidado. Atualizar o _custom_data_ de um usuário sobrescreverá completamente seu conteúdo original no armazenamento. +Atualize com cuidado. Atualizar o _custom_data_ de um usuário irá sobrescrever completamente seu conteúdo original no armazenamento. Por exemplo, se sua entrada ao chamar a API de atualização de _custom_data_ for assim (supondo que o _custom_data_ original seja o exemplo mostrado anteriormente): @@ -315,11 +317,11 @@ então o novo valor de _custom_data_ após a atualização será: } ``` -Ou seja, o valor do campo atualizado não terá relação com o valor anterior. +Ou seja, o valor do campo atualizado não tem relação com o valor anterior. ## Referência de propriedades \{#property-reference} -As seguintes colunas da tabela de usuários do banco de dados (exceto _password_encrypted_ e _password_encryption_method_) são visíveis no perfil do usuário, o que significa que você pode consultá-las usando a [Management API](https://openapi.logto.io/operation/operation-getuser). +As seguintes colunas da tabela de usuários do banco de dados (exceto _password_encrypted_ e _password_encryption_method_) são visíveis no perfil do usuário, o que significa que você pode consultá-las usando o [Management API](https://openapi.logto.io/operation/operation-getuser). | Nome | Tipo | Descrição | Único | Obrigatório | | ----------------------------------------------------------------------------------- | --------- | ------------------------------------------------------- | ----- | ----------- | @@ -330,7 +332,7 @@ As seguintes colunas da tabela de usuários do banco de dados (exceto _password_ | [name](/user-management/user-data#name) | string | Nome completo | ❌ | ❌ | | [avatar](/user-management/user-data#avatar) | string | URL do avatar do usuário | ❌ | ❌ | | [profile](/user-management/user-data#profile) | object | Perfil do usuário | ❌ | ✅ | -| [identities](/user-management/user-data#social-identities) | object | Informações do usuário do login social | ❌ | ✅ | +| [identities](/user-management/user-data#social-identities) | object | Informações do usuário de login social | ❌ | ✅ | | [custom_data](/user-management/user-data#custom-data) | object | Informações adicionais em propriedades customizáveis | ❌ | ✅ | | [application_id](/user-management/user-data#application_id) | string | ID do aplicativo em que o usuário se registrou primeiro | ❌ | ✅ | | [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | Timestamp do último login do usuário | ❌ | ✅ | diff --git a/i18n/th/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/th/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index 991fe60fe6e..273b0378383 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -17,11 +17,11 @@ export const resource = 'https://api.your-app.com'; ## ทรัพยากร API ระดับโกลบอลคืออะไร? \{#what-are-global-api-resources} -ทรัพยากร API ระดับโกลบอล คือ endpoint หรือบริการในแอปพลิเคชันของคุณที่ผู้ใช้ทุกคนสามารถเข้าถึงได้ ไม่ขึ้นกับองค์กรหรือผู้เช่า (tenant) โดยทั่วไปจะเป็น API ที่เปิดเผยต่อสาธารณะ, บริการหลักของผลิตภัณฑ์ หรือ endpoint ใด ๆ ที่ไม่ได้จำกัดขอบเขตเฉพาะองค์กร +ทรัพยากร API ระดับโกลบอล คือ endpoint หรือบริการในแอปพลิเคชันของคุณที่ผู้ใช้ทุกคนสามารถเข้าถึงได้ ไม่ว่าจะอยู่ในองค์กรหรือผู้เช่าใดก็ตาม โดยทั่วไปจะเป็น API ที่เปิดเผยต่อสาธารณะ บริการหลักของผลิตภัณฑ์ หรือ endpoint ใด ๆ ที่ไม่ได้จำกัดขอบเขตกับองค์กรใดองค์กรหนึ่ง **กรณีการใช้งาน เช่น** -- API สาธารณะหรือ endpoint ที่ใช้ร่วมกันในกลุ่มผู้ใช้ของคุณ +- API สาธารณะหรือ endpoint ที่ใช้ร่วมกันกับผู้ใช้ทั้งหมด - Microservices ที่ไม่ได้ผูกกับระบบหลายผู้เช่า (multi-tenancy) - API หลักของแอปพลิเคชัน (เช่น `/api/users`, `/api/products`) ที่ลูกค้าทุกคนใช้ @@ -29,40 +29,40 @@ Logto ช่วยให้คุณรักษาความปลอดภ ## วิธีการทำงานใน Logto \{#how-it-works-in-logto} -- **ทรัพยากร API และสิทธิ์ถูกลงทะเบียนในระดับโกลบอล:** แต่ละ API ที่คุณต้องการปกป้องจะถูกกำหนดด้วย resource indicator (URI) ที่ไม่ซ้ำ พร้อมชุดสิทธิ์ (scopes) ที่ควบคุมการเข้าถึง -- **การเข้าถึงถูกควบคุมด้วยบทบาทระดับโกลบอล:** คุณสามารถกำหนดสิทธิ์ให้กับบทบาท แล้วมอบหมายบทบาทเหล่านั้นให้กับผู้ใช้หรือไคลเอนต์ -- **แยกจากสิทธิ์ระดับองค์กร:** ทรัพยากร API ระดับโกลบอลจะไม่มีบริบทขององค์กร อย่างไรก็ตาม สามารถใช้ร่วมกับบทบาทขององค์กรเพื่อเพิ่มชั้นบริบทเพิ่มเติมได้หากจำเป็น หากต้องการปกป้อง API ระดับองค์กร ดู [ปกป้องทรัพยากร API ระดับองค์กร](/authorization/organization-level-api-resources) +- **ทรัพยากร API และสิทธิ์ถูกลงทะเบียนในระดับโกลบอล:** แต่ละ API ที่คุณต้องการปกป้องจะถูกกำหนดด้วย resource indicator (URI) ที่ไม่ซ้ำกัน พร้อมชุดสิทธิ์ (scopes) ที่ควบคุมการเข้าถึง +- **การเข้าถึงถูกควบคุมด้วยบทบาทระดับโกลบอล:** คุณสามารถกำหนดสิทธิ์ให้กับบทบาท แล้วนำบทบาทนั้นไปกำหนดให้กับผู้ใช้หรือไคลเอนต์ +- **แยกจากสิทธิ์ระดับองค์กร:** ทรัพยากร API ระดับโกลบอลไม่มีบริบทขององค์กร อย่างไรก็ตาม สามารถใช้ร่วมกับบทบาทขององค์กรเพื่อเพิ่มชั้นบริบทได้หากจำเป็น หากต้องการปกป้อง API ระดับองค์กร ดู [ปกป้องทรัพยากร API ระดับองค์กร](/authorization/organization-level-api-resources) Global API resources RBAC -### ภาพรวมการใช้งาน \{#implementation-overview} +### ภาพรวมการนำไปใช้ \{#implementation-overview} 1. **ลงทะเบียนทรัพยากร API ของคุณ** และกำหนดสิทธิ์ใน Logto 2. **กำหนดบทบาท** พร้อมสิทธิ์ที่จำเป็นสำหรับการเข้าถึง API -3. **มอบหมายบทบาท** ให้กับผู้ใช้หรือไคลเอนต์ -4. **ใช้ OAuth 2.0 authorization flows** เพื่อขอรับโทเค็นการเข้าถึงสำหรับ API (ค่าพารามิเตอร์ resource ต้องตรงกับ API identifier ที่ลงทะเบียนไว้) +3. **กำหนดบทบาท** ให้กับผู้ใช้หรือไคลเอนต์ +4. **ใช้ OAuth 2.0 authorization flows** เพื่อขอรับโทเค็นการเข้าถึงสำหรับ API (parameter `resource` ต้องตรงกับ API identifier ที่ลงทะเบียนไว้) 5. **ตรวจสอบโทเค็นการเข้าถึง** ใน API ของคุณเพื่อบังคับใช้สิทธิ์ ### ทำความเข้าใจ resource indicator \{#understanding-resource-indicators} -Logto สร้างแบบจำลองทรัพยากร API ตาม [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html) โดย **resource indicator** คือ URI ที่ระบุ API หรือบริการเป้าหมายที่ร้องขออย่างไม่ซ้ำ +Logto สร้างแบบจำลองทรัพยากร API ตาม [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html) โดย **resource indicator** คือ URI ที่ระบุ API หรือบริการเป้าหมายที่ร้องขออย่างไม่ซ้ำกัน **ประเด็นสำคัญ** -- resource indicator ต้องเป็น absolute URI (เช่น `https://api.example.com`) +- Resource indicator ต้องเป็น absolute URI (เช่น `https://api.example.com`) - ไม่มี fragment component; หลีกเลี่ยงการใช้ query string หากเป็นไปได้ -- resource indicator ช่วยให้รองรับ audience-restricted token และสถาปัตยกรรม multi-API +- Resource indicator ช่วยให้รองรับ audience-restricted token และสถาปัตยกรรม multi-API **ตัวอย่าง** - Management API: `https://my-tenant.logto.app/api` - Custom global API: `https://api.yourapp.com` -### กระบวนการอนุญาต: การยืนยันตัวตนและการรักษาความปลอดภัย API ของคุณ \{#authorization-flow-authenticating-and-securing-your-api} +### กระบวนการอนุญาต: การยืนยันตัวตนและปกป้อง API ของคุณ \{#authorization-flow-authenticating-and-securing-your-api} -กระบวนการด้านล่างนี้ใช้ได้ทั้งกรณีการยืนยันตัวตนของผู้ใช้แบบโต้ตอบ (browser / app) และกรณี backend เครื่องต่อเครื่อง (M2M) +ขั้นตอนด้านล่างนี้ใช้ได้ทั้งกรณีการยืนยันตัวตนของผู้ใช้ (browser / app) และกรณี backend แบบเครื่องต่อเครื่อง (M2M) -โปรดทราบว่ากระบวนการนี้ไม่ได้รวมรายละเอียดพารามิเตอร์หรือ header ที่จำเป็นทั้งหมด แต่เน้นขั้นตอนสำคัญ อ่านต่อเพื่อดูตัวอย่างการทำงานจริง +โปรดทราบว่า flow นี้ไม่ได้แสดงรายละเอียดพารามิเตอร์หรือ header ทั้งหมด แต่เน้นขั้นตอนสำคัญ อ่านต่อเพื่อดูตัวอย่างการทำงานจริง ```mermaid sequenceDiagram @@ -75,14 +75,14 @@ sequenceDiagram Logto->>Logto: เปลี่ยนเส้นทางผู้ใช้ไปยังหน้าลงชื่อเข้าใช้ Logto->>Client: เปลี่ยนเส้นทางกลับพร้อม `authorization_code` alt ใช้ authorization_code grant - Client->>Logto: POST /oidc/token พร้อม `grant_type=authorization_code`
และพารามิเตอร์ `resource` + Client->>Logto: POST /oidc/token พร้อม `grant_type=authorization_code`
และ parameter `resource` else ใช้ refresh_token grant Client->>Logto: POST /oidc/token พร้อม `grant_type=authorization_code` Logto->>Client: ส่งคืน refresh token - Client->>Logto: POST /oidc/token พร้อม `grant_type=refresh_token`
และพารามิเตอร์ `resource` + Client->>Logto: POST /oidc/token พร้อม `grant_type=refresh_token`
และ parameter `resource` end - else การยืนยันตัวตนของไคลเอนต์เครื่องต่อเครื่อง (M2M) - Client->>Logto: POST /oidc/token พร้อม `grant_type=client_credentials`
และพารามิเตอร์ `resource` + else การยืนยันตัวตนของไคลเอนต์แบบเครื่องต่อเครื่อง (M2M) + Client->>Logto: POST /oidc/token พร้อม `grant_type=client_credentials`
และ parameter `resource` end Logto->>Client: ส่งคืนโทเค็นการเข้าถึง (JSON Web Token) @@ -96,66 +96,66 @@ sequenceDiagram end ``` -_การยืนยันตัวตนของผู้ใช้ = browser / app. M2M = บริการ backend หรือสคริปต์ที่ใช้ client credentials._ +_การยืนยันตัวตนของผู้ใช้ = browser / app. M2M = backend service หรือ script ที่ใช้ client credentials._ :::note -พารามิเตอร์ `resource` ต้องตรงกับ API identifier (resource indicator) ที่คุณลงทะเบียนใน Logto +parameter `resource` ต้องตรงกับ API identifier (resource indicator) ที่คุณลงทะเบียนใน Logto ::: -## ขั้นตอนการใช้งาน \{#implementation-steps} +## ขั้นตอนการนำไปใช้ \{#implementation-steps} ### ลงทะเบียนทรัพยากร API ของคุณ \{#register-your-api-resources} 1. ไปที่ Console → API resources -2. สร้างทรัพยากร API ใหม่ (เช่น `https://api.yourapp.com/org`) และกำหนดสิทธิ์ (scopes) ของมัน +2. สร้าง API resource ใหม่ (เช่น `https://api.yourapp.com/org`) และกำหนดสิทธิ์ (scopes) -สำหรับขั้นตอนการตั้งค่าแบบเต็ม ดู [กำหนดทรัพยากร API พร้อมสิทธิ์](/authorization/role-based-access-control#define-api-resources-with-permissions) +สำหรับขั้นตอนการตั้งค่าแบบละเอียด ดู [กำหนด API resources พร้อมสิทธิ์](/authorization/role-based-access-control#define-api-resources-with-permissions) ### ตั้งค่าบทบาทระดับโกลบอล \{#set-up-global-roles} 1. ไปที่ Console → Roles -2. สร้างบทบาทที่สอดคล้องกับสิทธิ์ของ API ของคุณ (เช่น `read:products`, `write:products`) -3. มอบหมายบทบาทเหล่านี้ให้กับผู้ใช้หรือไคลเอนต์ที่ต้องการเข้าถึง API +2. สร้างบทบาทที่แมปกับสิทธิ์ของ API ของคุณ (เช่น `read:products`, `write:products`) +3. กำหนดบทบาทเหล่านี้ให้กับผู้ใช้หรือไคลเอนต์ที่ต้องการเข้าถึง API -สำหรับขั้นตอนการตั้งค่าแบบเต็ม ดู [ใช้บทบาทระดับโกลบอล](/authorization/role-based-access-control#configure-global-roles) +สำหรับขั้นตอนการตั้งค่าแบบละเอียด ดู [ใช้บทบาทระดับโกลบอล](/authorization/role-based-access-control#configure-global-roles) ### ขอรับโทเค็นการเข้าถึงสำหรับทรัพยากร API ระดับโกลบอล \{#obtain-access-tokens-for-global-api-resources} -ก่อนเข้าถึงทรัพยากร API ระดับโกลบอล ไคลเอนต์ของคุณต้องขอรับโทเค็นการเข้าถึง Logto จะออก [JSON Web Token (JWT)](https://auth.wiki/jwt) เป็นโทเค็นการเข้าถึงสำหรับทรัพยากร API ระดับโกลบอล โดยปกติจะใช้ [OAuth 2.0 authorization code flow](https://auth.wiki/authorization-code-flow), [refresh token flow](https://auth.wiki/refresh-token) หรือ [client credentials flow](https://auth.wiki/client-credentials-flow) +ก่อนเข้าถึงทรัพยากร API ระดับโกลบอล ไคลเอนต์ของคุณต้องขอโทเค็นการเข้าถึง Logto จะออก [JSON Web Token (JWT)](https://auth.wiki/jwt) เป็นโทเค็นการเข้าถึงสำหรับทรัพยากร API ระดับโกลบอล โดยปกติจะใช้ [OAuth 2.0 authorization code flow](https://auth.wiki/authorization-code-flow), [refresh token flow](https://auth.wiki/refresh-token) หรือ [client credentials flow](https://auth.wiki/client-credentials-flow) #### Authorization code หรือ refresh token flow \{#authorization-code-or-refresh-token-flow} -SDK อย่างเป็นทางการของ Logto ทุกตัวรองรับการขอรับโทเค็นการเข้าถึงสำหรับทรัพยากร API ระดับโกลบอลด้วย refresh token flow ได้ทันที คุณยังสามารถใช้ไลบรารี OAuth 2.0 / OIDC client มาตรฐานเพื่อใช้งาน flow นี้ได้เช่นกัน +SDK อย่างเป็นทางการของ Logto ทั้งหมดรองรับการขอโทเค็นการเข้าถึงสำหรับทรัพยากร API ระดับโกลบอลด้วย refresh token flow ในตัว คุณยังสามารถใช้ไลบรารี OAuth 2.0 / OIDC client มาตรฐานเพื่อใช้งาน flow นี้ได้ -เมื่อเริ่มต้น Logto client ให้เพิ่ม resource indicator ลงในพารามิเตอร์ `resources` (array) จากนั้นเพิ่มสิทธิ์ (scopes) ที่ต้องการลงในพารามิเตอร์ `scopes` +เมื่อเริ่มต้น Logto client ให้เพิ่ม resource indicator ลงใน parameter `resources` (array) จากนั้นเพิ่มสิทธิ์ (scopes) ที่ต้องการลงใน parameter `scopes` -เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว ให้ส่ง resource indicator ในพารามิเตอร์ `resource` หรือพารามิเตอร์ที่มีชื่อคล้ายกันขณะร้องขอโทเค็นการเข้าถึง (เช่น เรียก `getAccessToken()`) +เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว ให้ส่ง resource indicator ใน parameter `resource` หรือ parameter ที่ชื่อใกล้เคียงกันขณะขอโทเค็นการเข้าถึง (เช่น เรียก `getAccessToken()`) -สำหรับรายละเอียดของแต่ละ SDK ดูที่ [เริ่มต้นอย่างรวดเร็ว](/quick-starts) +ดูรายละเอียดแต่ละ SDK ได้ที่ [Quick starts](/quick-starts) -เมื่อกำหนดค่า OAuth 2.0 client หรือเริ่มต้น authorization code flow ให้แน่ใจว่าคุณใส่พารามิเตอร์ `resource` และ scopes ที่ต้องการในคำขออนุญาต +เมื่อกำหนดค่า OAuth 2.0 client หรือเริ่มต้น authorization code flow ให้แน่ใจว่าคุณใส่ parameter `resource` และ scopes ที่ต้องการใน authorization request -ไลบรารีบางตัวอาจไม่รองรับพารามิเตอร์ `resource` โดยตรง แต่โดยทั่วไปจะอนุญาตให้ส่งพารามิเตอร์เพิ่มเติมในคำขออนุญาต ตรวจสอบเอกสารของไลบรารีของคุณสำหรับรายละเอียด +บางไลบรารีอาจไม่รองรับ parameter `resource` โดยตรง แต่โดยทั่วไปจะอนุญาตให้ส่ง parameter เพิ่มเติมใน authorization request ได้ ตรวจสอบเอกสารของไลบรารีที่คุณใช้ -ตัวอย่างคำขออนุญาตแบบไม่เป็นทางการที่มีพารามิเตอร์ `resource` และ `scope`: +ตัวอย่าง authorization request ที่ไม่เป็นทางการพร้อม parameter `resource` และ `scope`: -เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว คุณจะได้รับ authorization code แลกเปลี่ยน code นี้เป็นโทเค็นการเข้าถึงโดยส่ง POST ไปยัง endpoint `/oidc/token` ของ Logto พร้อมพารามิเตอร์ `resource` ใน request body +เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว คุณจะได้รับ authorization code นำ code นี้ไปแลกเป็น access token โดยส่ง POST request ไปที่ endpoint `/oidc/token` ของ Logto พร้อม parameter `resource` ใน request body -ตัวอย่างคำขอโทเค็นแบบไม่เป็นทางการโดยใช้ grant type authorization code: +ตัวอย่าง token request ที่ไม่เป็นทางการโดยใช้ grant type authorization code: -คุณยังสามารถใช้ grant type `refresh_token` เพื่อขอโทเค็นการเข้าถึงใหม่โดยไม่ต้องมีการโต้ตอบของผู้ใช้ ตราบใดที่มีพารามิเตอร์ `resource` ในคำขอ +คุณยังสามารถใช้ grant type `refresh_token` เพื่อขอโทเค็นการเข้าถึงใหม่โดยไม่ต้องให้ผู้ใช้โต้ตอบ ตราบใดที่มี parameter `resource` ใน request -ตัวอย่างคำขอโทเค็นแบบไม่เป็นทางการโดยใช้ grant type refresh token: +ตัวอย่าง token request ที่ไม่เป็นทางการโดยใช้ grant type refresh token: @@ -164,14 +164,14 @@ SDK อย่างเป็นทางการของ Logto ทุกตั #### Client credentials flow \{#client-credentials-flow} -สำหรับกรณีเครื่องต่อเครื่อง (M2M) คุณสามารถใช้ client credentials flow เพื่อขอโทเค็นการเข้าถึงสำหรับทรัพยากร API ระดับโกลบอลของคุณ โดยส่ง POST ไปยัง endpoint `/oidc/token` ของ Logto คุณสามารถขอโทเค็นการเข้าถึงโดยใช้ client ID และ secret ของคุณ +สำหรับกรณีเครื่องต่อเครื่อง (M2M) คุณสามารถใช้ client credentials flow เพื่อขอโทเค็นการเข้าถึงสำหรับทรัพยากร API ระดับโกลบอลของคุณ โดยส่ง POST request ไปที่ endpoint `/oidc/token` ของ Logto เพื่อขอโทเค็นโดยใช้ client ID และ secret ของคุณ -มีสองพารามิเตอร์สำคัญที่ต้องใส่ในคำขอ: +มีสอง parameter สำคัญที่ต้องใส่ใน request: -- `resource`: resource indicator URI ของ API ที่คุณต้องการเข้าถึง (เช่น `https://api.yourapp.com`) +- `resource`: URI ของ resource indicator ของ API ที่คุณต้องการเข้าถึง (เช่น `https://api.yourapp.com`) - `scope`: สิทธิ์ที่คุณต้องการร้องขอสำหรับ API (เช่น `read:products write:products`) -ตัวอย่างคำขอโทเค็นแบบไม่เป็นทางการโดยใช้ grant type client credentials: +ตัวอย่าง token request ที่ไม่เป็นทางการโดยใช้ grant type client credentials: -### ถ้าไคลเอนต์ของฉันไม่รองรับพารามิเตอร์ resource ล่ะ? \{#what-if-my-client-doesn-t-support-the-resource-parameter} +### ถ้าไคลเอนต์ของฉันไม่รองรับ parameter resource ล่ะ? \{#what-if-my-client-doesn-t-support-the-resource-parameter} -ตั้งค่า API resource เริ่มต้นใน Logto Console โทเค็นจะใช้ audience นี้โดยอัตโนมัติเมื่อไม่มีการระบุพารามิเตอร์ resource ในคำขอโทเค็น +ตั้งค่า API resource เริ่มต้นใน Logto Console โทเค็นจะใช้ audience นี้โดยอัตโนมัติเมื่อไม่มีการระบุ parameter resource ใน token request @@ -227,10 +227,10 @@ JWT ที่ออกโดย Logto จะมีการอ้างสิท ตรวจสอบปัญหาทั่วไปดังต่อไปนี้: -- **ลายเซ็นโทเค็น:** ตรวจสอบว่า backend ของคุณดึง JWKs ที่ถูกต้องจาก Logto +- **ลายเซ็นของโทเค็น:** ตรวจสอบว่า backend ของคุณดึง JWKs ที่ถูกต้องจาก Logto - **หมดอายุโทเค็น:** ตรวจสอบว่าโทเค็นยังไม่หมดอายุ (`exp` claim) -- **Audience:** ตรวจสอบว่า claim `aud` ตรงกับ resource indicator ที่คุณลงทะเบียนไว้ -- **Scope ที่จำเป็น:** ตรวจสอบว่าโทเค็นมีสิทธิ์ที่จำเป็นใน claim `scope` +- **ผู้รับ (Audience):** ตรวจสอบว่า claim `aud` ตรงกับ resource indicator ที่คุณลงทะเบียนไว้ +- **scope ที่จำเป็น:** ตรวจสอบว่าโทเค็นมีสิทธิ์ที่จำเป็นใน claim `scope` @@ -241,7 +241,37 @@ JWT ที่ออกโดย Logto จะมีการอ้างสิท -ใช้ [personal access token](/user-management/personal-access-token) เพื่อจำลองการเรียก API แบบยืนยันตัวตน วิธีนี้ช่วยให้คุณทดสอบ endpoint ของ API ได้โดยไม่ต้องพัฒนา OAuth flow ครบชุดในแอปไคลเอนต์ของคุณ +ใช้ [personal access token](/user-management/personal-access-token) เพื่อจำลองการเรียก API แบบยืนยันตัวตน วิธีนี้ช่วยให้คุณทดสอบ endpoint ของ API ได้โดยไม่ต้องพัฒนา OAuth flow ครบชุดในแอปของคุณ + + + +
+ + +### ขอ scope แบบ prefix หรือแบบย่อได้ไหม? \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +ไม่ได้ ชื่อ scope ต้อง **ตรงกับ** ชื่อสิทธิ์ที่กำหนดไว้ใน API resource ของคุณเท่านั้น ไม่สามารถใช้ prefix หรือแบบย่อแทนได้ + +**ตัวอย่าง:** + +ถ้า API resource ของคุณกำหนดไว้ว่า: + +- `read:elections` +- `write:elections` + +คุณต้องร้องขอ: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +แบบนี้จะ **ไม่ได้ผล**: + +```swift +scopes: ["read", "write"] // ❌ ไม่ตรงกับชื่อสิทธิ์ +```
@@ -249,7 +279,7 @@ JWT ที่ออกโดย Logto จะมีการอ้างสิท วิธีตรวจสอบ access token - RBAC ในทางปฏิบัติ: การใช้งานการอนุญาตที่ปลอดภัยสำหรับแอปของคุณ + RBAC ในทางปฏิบัติ: การนำการอนุญาตที่ปลอดภัยไปใช้กับแอปของคุณ ปรับแต่ง token claims RFC 8707: Resource Indicators diff --git a/i18n/th/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/th/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index e6a6bc7d8e8..fc822816a55 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -4,7 +4,7 @@ sidebar_position: 4 # ภาษาท้องถิ่น -Logto รองรับภาษาที่กำหนดไว้ล่วงหน้าหลากหลายภาษา และมีแท็กภาษาเพิ่มเติมอีก 113 แท็ก เครื่องมืออันทรงพลังนี้ช่วยให้คุณปรับแต่งประสบการณ์การลงชื่อเข้าใช้ได้โดยการสร้างและจัดการตัวเลือกภาษาและคำแปลของคุณเอง +Logto รองรับภาษาที่กำหนดไว้ล่วงหน้าหลากหลายภาษา และมีแท็กภาษาเพิ่มเติมอีก 113 แท็ก เครื่องมือนี้ช่วยให้คุณปรับแต่งประสบการณ์การลงชื่อเข้าใช้ได้โดยการสร้างและจัดการตัวเลือกภาษาและคำแปลของคุณเอง ## ขั้นตอนการปรับแต่งใน Logto Console \{#customization-steps-in-logto-console} @@ -14,28 +14,28 @@ Logto รองรับภาษาที่กำหนดไว้ล่ว 2. **จัดการภาษา**: คลิกปุ่ม “จัดการภาษา” เพื่อเข้าถึงคลังภาษาของคุณ - **แก้ไขภาษาที่มีอยู่:** ปรับแต่งคำแปลของภาษาที่ Logto ให้มา ภาาเหล่านี้ไม่สามารถลบได้ แต่การเปลี่ยนแปลงของคุณจะเขียนทับค่าดั้งเดิม - **เพิ่มภาษาใหม่**: คลิกปุ่ม “เพิ่มภาษา” เลือกแท็กภาษา ใส่คำแปลของคุณ แล้วบันทึกการเปลี่ยนแปลงเพื่อเพิ่มภาษาใหม่ -3. **เปิดใช้งานการตรวจจับอัตโนมัติ**: เมื่อเปิดใช้งานแล้ว ระบบจะแสดงหน้าลงชื่อเข้าใช้เป็นภาษาที่ผู้ใช้ต้องการโดยอัตโนมัติตามการตั้งค่าของอุปกรณ์ -4. **ตั้งค่าภาษาเริ่มต้น:** คุณสามารถเลือกภาษาหลักจากคลังภาษาของคุณได้ ภาษานี้จะถูกใช้เมื่อไม่พบภาษาของผู้ใช้ในคลังภาษา +3. **เปิดใช้งานตรวจจับอัตโนมัติ**: เมื่อเปิดใช้งานแล้ว ระบบจะแสดงหน้าลงชื่อเข้าใช้เป็นภาษาที่ผู้ใช้ต้องการโดยอัตโนมัติตามการตั้งค่าของอุปกรณ์ +4. **ตั้งค่าภาษาเริ่มต้น:** คุณสามารถเลือกภาษาเริ่มต้นจากคลังภาษาของคุณ ภาษาเริ่มต้นนี้จะถูกใช้เมื่อไม่พบภาษาของผู้ใช้ในคลังภาษา ต่อไปนี้คือคำศัพท์สำคัญที่ควรเข้าใจเมื่อจัดการภาษา: -| คำจำกัดความ | คำอธิบาย | -| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -| แท็กภาษา (Language tag) | แท็กภาษาระบุภาษาของเนื้อหา แท็กภาษาประกอบด้วยรหัสภาษา (เช่น en, fr, zh) และรหัสประเทศ / ภูมิภาค (เช่น US, UK, KR) คั่นด้วยขีดกลาง ตัวอย่างแท็กภาษา: en-US | -| ภาษาที่ Logto ให้มา (Logto provided language) | ภาษาที่ Logto ให้มาเป็นภาษาทางการของ Logto และถูกเก็บไว้ในโค้ดต้นฉบับของ Logto | -| ภาษาที่เพิ่ม (Added language) | ภาษาที่เพิ่มคือภาษาที่ผู้ใช้เพิ่มเข้ามาเอง | -| ค่าต้นฉบับของ Logto (Logto source values) | ค่าต้นฉบับของ Logto คือค่าที่ Logto กำหนดมาโดยยังไม่ได้รับการปรับแต่งจากผู้ใช้ | -| ค่าที่ปรับแต่งเอง (Custom values) | ค่าที่ปรับแต่งเองคือค่าที่ผู้ใช้ได้ปรับแต่งแล้ว ค่าต้นฉบับของ Logto จะถูกเขียนทับ | +| คำจำกัดความ | คำอธิบาย | +| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| แท็กภาษา (Language tag) | แท็กภาษาคือรหัสที่ระบุภาษาของเนื้อหา ประกอบด้วยรหัสภาษา (เช่น en, fr, zh) และรหัสประเทศ / ภูมิภาค (เช่น US, UK, KR) คั่นด้วยขีดกลาง ตัวอย่างเช่น: en-US | +| ภาษา Logto ให้มา | ภาษา Logto ให้มาคือภาษาทางการของ Logto และถูกเก็บไว้ในโค้ดต้นฉบับของ Logto | +| ภาษาที่เพิ่ม | ภาษาที่เพิ่มคือภาษาที่ผู้ใช้เพิ่มเข้ามาเอง | +| ค่าเริ่มต้นของ Logto | ค่าเริ่มต้นของ Logto คือค่าที่ Logto กำหนดมาและยังไม่ได้รับการปรับแต่งโดยผู้ใช้ | +| ค่าที่ปรับแต่งแล้ว | ค่าที่ปรับแต่งแล้วคือค่าที่ผู้ใช้ได้ปรับแต่งเองแล้ว ค่าต้นฉบับของ Logto จะถูกเขียนทับ | ## การปรับแต่งผ่าน Management API \{#customization-using-management-api} -คุณสามารถใช้ Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) เพื่อปรับแต่งคำแปลภาษาได้ โดย body ของ API request จะเป็นอ็อบเจ็กต์ locale แบบบางส่วน เช่น: +คุณสามารถใช้ Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) เพื่อปรับแต่งคำแปลภาษาได้ โดย body ของ API request จะเป็นอ็อบเจกต์ locale แบบบางส่วน เช่น: ```json { "input": { "username": "Username", "password": "Password" }, "secondary": { - "social_bind_with": "มีบัญชีอยู่แล้ว? ลงชื่อเข้าใช้เพื่อเชื่อมโยง {{methods, list(type: disjunction;)}} กับบัญชีโซเชียลของคุณ" + "social_bind_with": "มีบัญชีอยู่แล้วใช่ไหม? ลงชื่อเข้าใช้เพื่อเชื่อมโยง {{methods, list(type: disjunction;)}} กับบัญชีโซเชียลของคุณ" }, "action": { "sign_in": "ลงชื่อเข้าใช้" }, "error": { @@ -50,15 +50,15 @@ Logto รองรับภาษาที่กำหนดไว้ล่ว ดู [ซอร์สโค้ด](https://github.com/logto-io/logto/blob/master/packages/phrases-experience/src/locales/en/index.ts) เพื่อดูเนื้อหาทั้งหมดที่สามารถปรับแต่งได้ -คุณยังสามารถใช้ [PATCH /api/sign-in-exp](https://openapi.logto.io/group/endpoint-sign-in-experience) API เพื่อควบคุมนโยบาย [การตรวจจับภาษา](https://openapi.logto.io/operation/operation-getsigninexp#operation-getsigninexp-200-body-application-json-languageinfo) ได้ด้วย +คุณยังสามารถใช้ [PATCH /api/sign-in-exp](https://openapi.logto.io/group/endpoint-sign-in-experience) API เพื่อควบคุมนโยบาย [การตรวจจับภาษา](https://openapi.logto.io/operation/operation-getsigninexp#operation-getsigninexp-200-body-application-json-languageinfo) ## การเลือกภาษาในขณะรันไทม์ \{#runtime-language-resolution} -ขณะรันไทม์ ระบบจะเลือกภาษาของประสบการณ์การลงชื่อเข้าใช้ตามลำดับความสำคัญดังนี้: +ในขณะรันไทม์ ระบบจะเลือกภาษาของประสบการณ์การลงชื่อเข้าใช้ตามลำดับความสำคัญดังนี้: 1. พารามิเตอร์ `ui_locales` ของ OIDC จากคำขอการยืนยันตัวตนปัจจุบัน (ใช้แท็กแรกที่รองรับ) ดู [ui_locales](/end-user-flows/authentication-parameters/ui-locales) -2. หากไม่พบ และเปิดใช้งาน “ตรวจจับอัตโนมัติ” ระบบจะใช้ภาษาของผู้ใช้ที่ตรวจพบ (เช่น จาก HTTP header `Accept-Language`) -3. หากยังไม่พบ จะใช้ภาษาหลักของ tenant ในประสบการณ์การลงชื่อเข้าใช้ +2. หากไม่ได้ระบุ และเปิดใช้งาน “ตรวจจับอัตโนมัติ” ระบบจะใช้ภาษาของไคลเอนต์ผู้ใช้ที่ตรวจพบ (เช่น จาก HTTP header `Accept-Language`) +3. หากยังไม่พบ จะใช้ภาษาเริ่มต้นของ tenant ใน Sign-in Experience การเลือกภาษานี้ยังมีผลกับการแปลอีเมลสำหรับข้อความที่เกิดจากการโต้ตอบด้วย ดูเพิ่มเติม: [การแปลเทมเพลตอีเมล](/connectors/email-connectors/email-templates#email-template-localization) @@ -66,7 +66,7 @@ Logto รองรับภาษาที่กำหนดไว้ล่ว ภาษาที่เพิ่มจะปรากฏต่อผู้ใช้ปลายทางอย่างไร? -สมมติว่าคุณมีเว็บไซต์ที่ใช้ภาษาอังกฤษเป็นค่าเริ่มต้นและเปิดใช้งานการตรวจจับอัตโนมัติ ผู้ใช้จากญี่ปุ่นเข้ามาที่เว็บไซต์ของคุณและต้องการสร้างบัญชี หากเขา / เธอใช้ภาษาญี่ปุ่นเป็นภาษาของแอป แต่ Logto ยังไม่รองรับภาษานี้ หน้าลงชื่อเข้าใช้จะปรากฏเป็นภาษาอังกฤษ +สมมติว่าคุณมีเว็บไซต์ที่ใช้ภาษาอังกฤษเป็นค่าเริ่มต้นและเปิดใช้งานตรวจจับอัตโนมัติ ผู้ใช้จากญี่ปุ่นเข้ามาที่เว็บไซต์ของคุณและต้องการสร้างบัญชี หากเขา / เธอใช้ภาษาญี่ปุ่นเป็นภาษาของแอป แต่ Logto ยังไม่รองรับภาษานี้ หน้าลงชื่อเข้าใช้จะปรากฏเป็นภาษาอังกฤษ ประสบการณ์การลงชื่อเข้าใช้ของ Logto รองรับ i18n ทำให้สามารถปรับแต่งภาษาได้ @@ -79,22 +79,35 @@ Logto รองรับภาษาที่กำหนดไว้ล่ว
-### ถ้าภาษาที่ฉันเพิ่มกลายเป็นภาษาที่ Logto ให้มาจะเกิดอะไรขึ้น? \{#what-if-the-language-i-added-becomes-logto-provided-language} +### ถ้าภาษาที่ฉันเพิ่มกลายเป็นภาษา Logto ให้มาจะเกิดอะไรขึ้น? \{#what-if-the-language-i-added-becomes-logto-provided-language} -ถัดจากแท็กภาษาทางซ้ายจะมีป้ายกำกับว่า “Logto-provided” ปรากฏขึ้น และภาษาที่คุณเพิ่มจะไม่สามารถลบได้อีกต่อไป ค่าที่คุณแก้ไขจะยังคงทำงานและแทนที่ค่าต้นฉบับของ Logto หากต้องการกลับไปใช้ค่าที่ Logto กำหนดมา ให้ลบค่าที่ผู้ใช้ระบุออก +ถัดจากแท็กภาษาทางซ้ายจะมีป้ายกำกับว่า Logto-provided ปรากฏขึ้น และภาษาที่คุณเพิ่มจะไม่สามารถลบได้อีกต่อไป ค่าที่คุณแก้ไขจะยังคงทำงานและแทนที่ค่าต้นฉบับของ Logto หากต้องการกลับไปใช้ค่าที่ Logto กำหนดมา ให้ลบค่าที่ผู้ใช้ระบุออก
-### ถ้าฉันเพิ่มแค่ค่าที่ปรับแต่งเองบางส่วนเท่านั้นจะเป็นอย่างไร? \{#what-if-i-only-added-a-few-custom-values} +### ถ้าฉันเพิ่มค่าที่ปรับแต่งเองเพียงบางส่วนจะเป็นอย่างไร? \{#what-if-i-only-added-a-few-custom-values} -สิ่งที่ผู้ใช้ปลายทางเห็นคือผลลัพธ์ของการรวมสองคอลัมน์ สมมติว่าคุณต้องการปรับแต่งเฉพาะบางส่วนของเนื้อหาต้นฉบับที่ Logto ให้มา หน้าสมัครสมาชิกของคุณจะแตกต่างจากของ Logto เฉพาะในคีย์ที่คุณแก้ไข ส่วนที่เหลือจะเหมือนเดิม +สิ่งที่ผู้ใช้ปลายทางเห็นคือผลลัพธ์ของการรวมสองคอลัมน์ สมมติว่าคุณต้องการปรับแต่งเฉพาะบางส่วนของเนื้อหาต้นฉบับที่ Logto ให้มา ความแตกต่างระหว่างหน้าสมัครของคุณกับของ Logto จะมีเฉพาะคีย์ที่คุณแก้ไข ส่วนที่เหลือจะเหมือนเดิม + +
+ +
+ + +### ฉันจะตั้งค่ารหัสประเทศของหมายเลขโทรศัพท์เริ่มต้นสำหรับประสบการณ์การลงชื่อเข้าใช้ได้อย่างไร? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +รหัสประเทศของหมายเลขโทรศัพท์ใน [ประสบการณ์การลงชื่อเข้าใช้](/end-user-flows/sign-up-and-sign-in/sign-up) จะตั้งค่าเริ่มต้นตาม locale ของเบราว์เซอร์ผู้ใช้ เช่น หากเบราว์เซอร์ของผู้ใช้ตั้งเป็น `fr` รหัสประเทศจะเป็นฝรั่งเศส (+33) + +หากต้องการควบคุมรหัสประเทศเริ่มต้นสำหรับผู้ใช้หรือภูมิภาคเฉพาะแบบโปรแกรม ให้ใช้พารามิเตอร์ [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) ในการยืนยันตัวตน เช่น ตั้งค่า `ui_locales=ja` จะทำให้รหัสประเทศเริ่มต้นเป็นญี่ปุ่น (+81)
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/th/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index f122e7425f9..8ede2c6e388 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -2,63 +2,67 @@ sidebar_position: 1 --- -# ปรับแต่งให้ตรงกับแบรนด์ของคุณ +# ปรับให้ตรงกับแบรนด์ของคุณ ## ประสบการณ์การลงชื่อเข้าใช้แบบ Omni \{#omni-sign-in-experience} -ปรับแต่งรูปลักษณ์และความรู้สึกของหน้าลงชื่อเข้าใช้ของคุณได้โดยไปที่ Console > Sign-in experience > Branding ส่วนนี้ช่วยให้คุณปรับแต่งองค์ประกอบแบรนด์หลักได้อย่างง่ายดาย +ปรับแต่งรูปลักษณ์และความรู้สึกของหน้าลงชื่อเข้าใช้ของคุณได้โดยไปที่ Console > ประสบการณ์การลงชื่อเข้าใช้ > การตั้งค่าแบรนด์ ส่วนนี้จะช่วยให้คุณปรับแต่งองค์ประกอบสำคัญของแบรนด์ได้อย่างง่ายดาย -**สีประจำแบรนด์** +### สีประจำแบรนด์ \{#brand-color} กำหนดสีหลักที่ใช้ตลอดประสบการณ์การลงชื่อเข้าใช้ รวมถึงปุ่มหลัก ลิงก์ และองค์ประกอบอื่น ๆ แทนที่สีม่วงเริ่มต้นของ Logto ด้วยสีของแบรนด์คุณ สำหรับโหมดมืด (dark mode) สามารถระบุสีประจำแบรนด์แยกต่างหากได้ -**โลโก้บริษัท** +### โลโก้บริษัท \{#company-logo} -โลโก้จะแสดงในหน้าแรกของการลงชื่อเข้าใช้ หน้าแรกของการสมัครใช้งาน หน้าโหลด และอินเทอร์เฟซอื่น ๆ ที่เราขยายต่อไป +โลโก้จะแสดงในหน้าแรกของการลงชื่อเข้าใช้ หน้าแรกของการสมัครสมาชิก หน้าโหลด และอินเทอร์เฟซอื่น ๆ ที่เราขยายไว้ - มีข้อจำกัดสำหรับรูปภาพ: ต้องมีขนาดไม่เกิน 500KB และอยู่ในรูปแบบ SVG, PNG, JPG, JPEG หรือ ICO -- หากคุณเว้นช่องโลโก้ว่างไว้ โลโก้จะไม่แสดงในอินเทอร์เฟซ +- หากคุณเว้นช่องโลโก้ไว้ โลโก้จะไม่แสดงในอินเทอร์เฟซ - สามารถอัปโหลดโลโก้เวอร์ชันโหมดมืดได้เช่นกัน -**Favicon** +### Favicon \{#favicon} -Favicon คือไอคอนขนาดเล็กที่แสดงถึงเว็บไซต์ และจะแสดงในแท็บเบราว์เซอร์ ที่คั่นหน้า และพื้นที่อื่น ๆ ของอินเทอร์เฟซเบราว์เซอร์ +Favicon คือไอคอนขนาดเล็กที่แสดงถึงเว็บไซต์ และจะแสดงในแท็บเบราว์เซอร์ บุ๊กมาร์ก และพื้นที่อื่น ๆ ของอินเทอร์เฟซเบราว์เซอร์ - รูปภาพต้องมีขนาดไม่เกิน 500KB และอยู่ในรูปแบบ SVG, PNG, JPG, JPEG หรือ ICO แนะนำให้อัปโหลดภาพสี่เหลี่ยมจัตุรัสเพื่อให้แสดงผลได้ดี - สามารถอัปโหลด favicon เวอร์ชันโหมดมืดได้เช่นกัน -- นอกจากนี้ ชื่อแท็บเบราว์เซอร์สำหรับแต่ละ flow (Sign in / Sign up / Forgot password ฯลฯ) จะถูกใช้แทนชื่อที่กำหนดเอง +- นอกจากนี้ ชื่อแท็บเบราว์เซอร์สำหรับแต่ละ flow (ลงชื่อเข้าใช้/สมัครสมาชิก/ลืมรหัสผ่าน ฯลฯ) จะถูกใช้แทนชื่อที่กำหนดเอง -**โหมดมืด** +### โหมดมืด \{#dark-mode} -เปิดใช้งานโหมดมืดเพื่อปรับรูปลักษณ์หน้าลงชื่อเข้าใช้โดยอัตโนมัติตามการตั้งค่าระบบของผู้ใช้ +เปิดใช้งานโหมดมืดเพื่อปรับรูปลักษณ์ของหน้าลงชื่อเข้าใช้โดยอัตโนมัติตามการตั้งค่าระบบของผู้ใช้ + +### ซ่อนแบรนด์ Logto \{#hide-logto-branding} + +โดยค่าเริ่มต้น หน้าประสบการณ์การลงชื่อเข้าใช้จะแสดงข้อความ "Powered by Logto" ที่ด้านล่าง เปิดใช้งานตัวเลือก "ซ่อนแบรนด์ Logto" เพื่อเอาเครื่องหมาย Logto ออกและสร้างประสบการณ์การลงชื่อเข้าใช้ที่ดูสะอาดตาและเป็นมืออาชีพซึ่งแสดงเฉพาะเอกลักษณ์ของแบรนด์คุณเท่านั้น ## การตั้งค่าแบรนด์เฉพาะแอป \{#app-specific-branding} -หากธุรกิจของคุณมีหลายแอปและต้องการประสบการณ์ลงชื่อเข้าใช้ในแต่ละแอป สามารถตั้งค่าได้ในหน้ารายละเอียดแอป ไปที่ Console > Applications +หากธุรกิจของคุณมีหลายแอปและต้องการประสบการณ์การลงชื่อเข้าใช้ในแต่ละแอป สามารถตั้งค่าได้ในหน้ารายละเอียดแอป ไปที่ Console > Applications -โดยการเปิดใช้งาน "App-level sign-in experience" คุณสามารถตั้งค่าโลโก้แบรนด์, favicon, สี และแม้แต่ [custom CSS](/customization/custom-css) เฉพาะแต่ละแอปได้ เมื่อมีการเริ่มต้นลงชื่อเข้าใช้จากแอปที่เปิดใช้งานการตั้งค่าแบรนด์ระดับแอป ประสบการณ์การลงชื่อเข้าใช้จะถูกปรับแต่งตามการตั้งค่าแบรนด์ของแอปนั้น ๆ หากไม่ได้เปิดใช้งาน จะใช้การตั้งค่าจาก omni sign-in experience เป็นค่าเริ่มต้น +โดยการเปิดใช้งาน "ประสบการณ์การลงชื่อเข้าใช้ระดับแอป" คุณสามารถตั้งค่าโลโก้ Favicon สี และแม้แต่ [CSS กำหนดเอง](/customization/custom-css) สำหรับแต่ละแอป เมื่อมีการเริ่มต้นลงชื่อเข้าใช้จากแอปที่เปิดใช้งานการตั้งค่าแบรนด์ระดับแอป ประสบการณ์การลงชื่อเข้าใช้จะถูกปรับแต่งตามการตั้งค่าแบรนด์ของแอปนั้น ๆ หากไม่เปิดใช้งาน จะใช้การตั้งค่าประสบการณ์การลงชื่อเข้าใช้แบบ omni เป็นค่าเริ่มต้น -สามารถตั้งค่าได้ทั้งโหมดสว่างและโหมดมืดสำหรับแบรนด์ระดับแอป โดยการตั้งค่าโหมดมืดจะมีผลเฉพาะเมื่อเปิดใช้งานโหมดมืดใน [omni sign-in experience](#omni-sign-in-experience) +สามารถตั้งค่าได้ทั้งโหมดสว่างและโหมดมืดสำหรับแบรนด์ระดับแอป โดยการตั้งค่าโหมดมืดจะมีผลเฉพาะเมื่อเปิดใช้งานโหมดมืดใน [ประสบการณ์การลงชื่อเข้าใช้แบบ omni](#omni-sign-in-experience) ## การตั้งค่าแบรนด์เฉพาะองค์กร \{#organization-specific-branding} หากต้องการแสดงโลโก้องค์กรของลูกค้าแบบไดนามิกในประสบการณ์การลงชื่อเข้าใช้ สามารถอัปโหลดโลโก้องค์กรได้ในหน้าตั้งค่าองค์กร ไปที่ Console > Organizations -โดยการเปิดใช้งาน "Organization-level sign-in experience" เช่นเดียวกับการตั้งค่าแบรนด์ระดับแอป คุณสามารถตั้งค่าโลโก้แบรนด์, favicon, สี และ [custom CSS](/customization/custom-css) เฉพาะแต่ละองค์กรได้เช่นกัน +โดยการเปิดใช้งาน "ประสบการณ์การลงชื่อเข้าใช้ระดับองค์กร" เช่นเดียวกับแบรนด์ระดับแอป คุณสามารถตั้งค่าโลโก้ Favicon สี และ [CSS กำหนดเอง](/customization/custom-css) สำหรับแต่ละองค์กรได้เช่นกัน -จากนั้น เมื่อมีการเรียกใช้งานลงชื่อเข้าใช้ คุณสามารถส่งค่า organization ID ในพารามิเตอร์ `organization_id` เพื่อบอก Logto ให้แสดงโลโก้องค์กรใด ตัวอย่างเช่น หากต้องการแสดงโลโก้องค์กรสำหรับ organization ID `123456`: +จากนั้น เมื่อมีการเรียกใช้งานลงชื่อเข้าใช้ คุณสามารถส่งค่า organization ID ในพารามิเตอร์ `organization_id` เพื่อบอก Logto ว่าจะแสดงโลโก้องค์กรใด ตัวอย่างเช่น หากต้องการแสดงโลโก้องค์กรสำหรับ organization ID `123456`: -- หากใช้ Logto SDK สามารถส่งพารามิเตอร์ `organization_id` ในอ็อบเจกต์ `extraParams` ของเมธอด `signIn` -- หากใช้ OIDC client สามารถส่งพารามิเตอร์ `organization_id` เมื่อเรียก [authorization endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) +- หากคุณใช้ Logto SDK สามารถส่งพารามิเตอร์ `organization_id` ในอ็อบเจกต์ `extraParams` ของเมธอด `signIn` +- หากคุณใช้ OIDC client สามารถส่งพารามิเตอร์ `organization_id` เมื่อเรียกขอ [authorization endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) -สามารถตั้งค่าได้ทั้งโหมดสว่างและโหมดมืดสำหรับแบรนด์ระดับองค์กร โดยการตั้งค่าโหมดมืดจะมีผลเฉพาะเมื่อเปิดใช้งานโหมดมืดใน [omni sign-in experience](#omni-sign-in-experience) +สามารถตั้งค่าได้ทั้งโหมดสว่างและโหมดมืดสำหรับแบรนด์ระดับองค์กร โดยการตั้งค่าโหมดมืดจะมีผลเฉพาะเมื่อเปิดใช้งานโหมดมืดใน [ประสบการณ์การลงชื่อเข้าใช้แบบ omni](#omni-sign-in-experience) :::note -หากเปิดใช้งานทั้งการตั้งค่าแบรนด์ระดับแอปและระดับองค์กร การตั้งค่าแบรนด์ระดับองค์กรจะมีลำดับความสำคัญสูงกว่า ลำดับความสำคัญทั้งหมดคือ: -การตั้งค่าแบรนด์ระดับองค์กร -> การตั้งค่าแบรนด์ระดับแอป -> Omni sign-in experience +หากเปิดใช้งานทั้งแบรนด์ระดับแอปและแบรนด์ระดับองค์กร แบรนด์ระดับองค์กรจะมีลำดับความสำคัญสูงกว่า ลำดับความสำคัญทั้งหมดคือ: +แบรนด์ระดับองค์กร -> แบรนด์ระดับแอป -> ประสบการณ์การลงชื่อเข้าใช้แบบ omni ::: -ตัวอย่างการส่งพารามิเตอร์ `organization_id` ในเมธอด `signIn` โดยใช้ [Logto browser SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out): +นี่คือตัวอย่างการส่งพารามิเตอร์ `organization_id` ในเมธอด `signIn` โดยใช้ [Logto browser SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out): **index.ts** @@ -81,5 +85,5 @@ logtoClient.signIn({ ## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} - วิธีปรับแต่งประสบการณ์การลงชื่อเข้าใช้สำหรับแต่ละแอปหรือแต่ละองค์กร? + วิธีปรับแต่งประสบการณ์การลงชื่อเข้าใช้สำหรับแต่ละแอปหรือองค์กร? diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index 3bd2604cfad..714aeb13094 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -10,13 +10,13 @@ sidebar_position: 1 Logto Account API คือชุด API ที่ครอบคลุมซึ่งเปิดให้ผู้ใช้ปลายทางเข้าถึง API ได้โดยตรงโดยไม่ต้องผ่าน Management API จุดเด่นมีดังนี้: - เข้าถึงโดยตรง: Account API ให้อำนาจผู้ใช้ปลายทางในการเข้าถึงและจัดการโปรไฟล์บัญชีของตนเองโดยตรง โดยไม่ต้องส่งต่อผ่าน Management API -- การจัดการโปรไฟล์ผู้ใช้และอัตลักษณ์: ผู้ใช้สามารถจัดการโปรไฟล์และการตั้งค่าความปลอดภัยได้อย่างเต็มที่ รวมถึงการอัปเดตข้อมูลอัตลักษณ์ เช่น อีเมล เบอร์โทรศัพท์ รหัสผ่าน และการจัดการการเชื่อมต่อโซเชียล รองรับ MFA และ SSO กำลังจะมาเร็ว ๆ นี้ -- การควบคุมการเข้าถึงระดับโกลบอล: ผู้ดูแลระบบมีสิทธิ์ควบคุมการเข้าถึงและปรับแต่งแต่ละฟิลด์ได้อย่างเต็มที่ -- การอนุญาต (Authorization) ที่ไร้รอยต่อ: การอนุญาต (Authorization) ง่ายกว่าที่เคย! เพียงใช้ `client.getAccessToken()` เพื่อรับโทเค็นการเข้าถึงทึบ (opaque access token) สำหรับ OP (Logto) และแนบไปกับ Authorization header เป็น `Bearer ` +- การจัดการโปรไฟล์ผู้ใช้และอัตลักษณ์: ผู้ใช้สามารถจัดการโปรไฟล์และการตั้งค่าความปลอดภัยได้อย่างเต็มที่ รวมถึงการอัปเดตข้อมูลอัตลักษณ์ เช่น อีเมล เบอร์โทรศัพท์ รหัสผ่าน และการจัดการการเชื่อมต่อโซเชียล รองรับ MFA และ SSO เร็วๆ นี้ +- การควบคุมการเข้าถึงระดับโลก: ผู้ดูแลระบบมีสิทธิ์ควบคุมการเข้าถึงแบบเต็มรูปแบบ และสามารถปรับแต่งแต่ละฟิลด์ได้ +- การอนุญาต (Authorization) ที่ไร้รอยต่อ: การอนุญาตง่ายกว่าที่เคย! เพียงใช้ `client.getAccessToken()` เพื่อรับโทเค็นการเข้าถึงทึบ (opaque access token) สำหรับ OP (Logto) และแนบไปกับ Authorization header เป็น `Bearer ` ด้วย Logto Account API คุณสามารถสร้างระบบจัดการบัญชีผู้ใช้แบบกำหนดเอง เช่น หน้าโปรไฟล์ ที่ผสานรวมกับ Logto ได้อย่างสมบูรณ์ -ตัวอย่างการใช้งานที่พบบ่อย เช่น: +ตัวอย่างกรณีการใช้งานที่พบบ่อย: - ดึงข้อมูลโปรไฟล์ผู้ใช้ - อัปเดตโปรไฟล์ผู้ใช้ @@ -28,7 +28,7 @@ Logto Account API คือชุด API ที่ครอบคลุมซึ :::note -ฟีเจอร์การดูบัญชี SSO และการลบบัญชี มีให้ใช้งานผ่าน Logto Management API เท่านั้น ดูรายละเอียดการใช้งานได้ที่ [การตั้งค่าบัญชีผู้ใช้ด้วย Management API](/end-user-flows/account-settings/by-management-api) +ฟีเจอร์การดูบัญชี SSO และการลบบัญชีมีให้บริการผ่าน Logto Management APIs เท่านั้น ดูรายละเอียดการใช้งานที่ [การตั้งค่าบัญชีผู้ใช้ด้วย Management API](/end-user-flows/account-settings/by-management-api) ::: @@ -41,13 +41,13 @@ Account API ถูกปิดใช้งานโดยค่าเริ่ เมื่อเปิดใช้งานแล้ว ให้กำหนดสิทธิ์แต่ละฟิลด์สำหรับตัวระบุ ข้อมูลโปรไฟล์ และการเข้าถึงโทเค็นของบุคคลที่สาม แต่ละฟิลด์รองรับ `Off`, `ReadOnly` หรือ `Edit` โดยค่าเริ่มต้นคือ `Off` 1. **ฟิลด์ความปลอดภัย**: - - ฟิลด์ประกอบด้วย: อีเมลหลัก, เบอร์โทรศัพท์หลัก, อัตลักษณ์โซเชียล, รหัสผ่าน และ MFA + - ฟิลด์ประกอบด้วย: อีเมลหลัก เบอร์โทรศัพท์หลัก อัตลักษณ์โซเชียล รหัสผ่าน และ MFA - ก่อนที่ผู้ใช้ปลายทางจะสามารถแก้ไขฟิลด์เหล่านี้ได้ ต้องยืนยันตัวตนผ่านรหัสผ่าน อีเมล หรือ SMS เพื่อรับรหัสบันทึกการยืนยัน (verification record ID) ที่มีอายุ 10 นาที ดู [รับรหัสบันทึกการยืนยัน](#get-a-verification-record-id) - - หากต้องการใช้ WebAuthn passkey สำหรับ MFA ให้เพิ่มโดเมนแอป front-end ของคุณใน **WebAuthn Related Origins** เพื่อให้ account center และประสบการณ์การลงชื่อเข้าใช้สามารถแชร์ passkey ได้ ดู [เชื่อมโยง WebAuthn passkey ใหม่](#link-a-new-webauthn-passkey) + - หากต้องการใช้ WebAuthn passkey สำหรับ MFA ให้เพิ่มโดเมนแอป front-end ของคุณใน **WebAuthn Related Origins** เพื่อให้ account center และประสบการณ์การลงชื่อเข้าใช้สามารถใช้ passkey ร่วมกันได้ ดู [เชื่อมโยง WebAuthn passkey ใหม่](#link-a-new-webauthn-passkey) 2. **ฟิลด์โปรไฟล์**: - - ฟิลด์ประกอบด้วย: ชื่อผู้ใช้, ชื่อ, อวาตาร์, [โปรไฟล์](/user-management/user-data#profile) (แอตทริบิวต์โปรไฟล์มาตรฐานอื่น ๆ) และ [ข้อมูลกำหนดเอง](/user-management/user-data#custom-data) - - ผู้ใช้ปลายทางสามารถแก้ไขฟิลด์เหล่านี้ได้โดยไม่ต้องยืนยันตัวตนเพิ่มเติม -3. **Secret vault**: สำหรับ OIDC หรือ OAuth social และ enterprise connectors, Logto [secret vault](/secret-vault/federated-token-set) จะเก็บโทเค็นการเข้าถึงและรีเฟรชของบุคคลที่สามอย่างปลอดภัยหลังการยืนยันตัวตน จากนั้นแอปสามารถเรียก API ภายนอก เช่น ซิงค์กิจกรรม Google Calendar ได้โดยไม่ต้องให้ผู้ใช้ลงชื่อเข้าใช้อีก การดึงโทเค็นจะพร้อมใช้งานโดยอัตโนมัติเมื่อเปิด Account API + - ฟิลด์ประกอบด้วย: ชื่อผู้ใช้ ชื่อ รูปโปรไฟล์ [profile](/user-management/user-data#profile) (แอตทริบิวต์โปรไฟล์มาตรฐานอื่นๆ) และ [custom data](/user-management/user-data#custom-data) + - ผู้ใช้ปลายทางสามารถแก้ไขฟิลด์เหล่านี้ได้โดยไม่ต้องยืนยันเพิ่มเติม +3. **Secret vault**: สำหรับ OIDC หรือ OAuth social และ enterprise connectors, Logto [secret vault](/secret-vault/federated-token-set) จะเก็บโทเค็นการเข้าถึงและรีเฟรชของบุคคลที่สามอย่างปลอดภัยหลังการยืนยันตัวตน แอปสามารถเรียก API ภายนอก เช่น ซิงค์กิจกรรม Google Calendar ได้โดยไม่ต้องให้ผู้ใช้ลงชื่อเข้าใช้อีก การดึงโทเค็นจะพร้อมใช้งานโดยอัตโนมัติเมื่อเปิด Account API ## วิธีเข้าถึง Account API \{#how-to-access-account-api} @@ -60,7 +60,7 @@ Account API ถูกปิดใช้งานโดยค่าเริ่ import { type LogtoConfig, UserScope } from '@logto/js'; const config: LogtoConfig = { - // ...ตัวเลือกอื่น ๆ + // ...other options // เพิ่ม scopes ที่เหมาะสมกับกรณีใช้งานของคุณ scopes: [ UserScope.Email, // สำหรับ `{POST,DELETE} /api/my-account/primary-email` @@ -79,7 +79,7 @@ const config: LogtoConfig = { หลังจากตั้งค่า SDK ในแอปของคุณแล้ว คุณสามารถใช้เมธอด `client.getAccessToken()` เพื่อดึง access token ได้ โทเค็นนี้เป็นโทเค็นทึบ (opaque token) ที่ใช้เข้าถึง Account API -หากคุณไม่ได้ใช้ SDK อย่างเป็นทางการ คุณควรกำหนดค่า `resource` ให้ว่างเปล่าสำหรับ access token grant request ไปที่ `/oidc/token` +หากคุณไม่ได้ใช้ SDK อย่างเป็นทางการ คุณควรกำหนด `resource` เป็นค่าว่างในการขอ access token ที่ `/oidc/token` ### เข้าถึง Account API ด้วย access token \{#access-account-api-using-access-token} @@ -118,9 +118,9 @@ curl https://[tenant-id].logto.app/api/my-account \ ### อัปเดตข้อมูลบัญชีผู้ใช้พื้นฐาน \{#update-basic-account-information} -ข้อมูลบัญชีผู้ใช้พื้นฐานประกอบด้วย ชื่อผู้ใช้, ชื่อ, อวาตาร์, custom data และข้อมูลโปรไฟล์อื่น ๆ +ข้อมูลบัญชีผู้ใช้พื้นฐานประกอบด้วย ชื่อผู้ใช้ ชื่อ รูปโปรไฟล์ custom data และข้อมูลโปรไฟล์อื่นๆ -เพื่ออัปเดต **username, name, avatar, และ customData** ใช้ endpoint [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) +หากต้องการอัปเดต **username, name, avatar, และ customData** ให้ใช้ endpoint [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account \ @@ -129,7 +129,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account \ --data-raw '{"username":"...","name":"...","avatar":"..."}' ``` -เพื่ออัปเดตข้อมูลโปรไฟล์อื่น ๆ เช่น **familyName, givenName, middleName, nickname, profile (profile page URL), website, gender, birthdate, zoneinfo, locale, และ address** ใช้ endpoint [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) +หากต้องการอัปเดตข้อมูลโปรไฟล์อื่นๆ เช่น **familyName, givenName, middleName, nickname, profile (URL หน้าโปรไฟล์), website, gender, birthdate, zoneinfo, locale, และ address** ให้ใช้ endpoint [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ @@ -138,15 +138,15 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ --data-raw '{"familyName":"...","givenName":"..."}' ``` -## จัดการตัวระบุและข้อมูลสำคัญอื่น ๆ \{#manage-identifiers-and-other-sensitive-information} +## จัดการตัวระบุและข้อมูลสำคัญอื่นๆ \{#manage-identifiers-and-other-sensitive-information} -ด้วยเหตุผลด้านความปลอดภัย Account API ต้องการการอนุญาต (Authorization) ชั้นพิเศษสำหรับการดำเนินการที่เกี่ยวข้องกับตัวระบุและข้อมูลสำคัญอื่น ๆ +ด้วยเหตุผลด้านความปลอดภัย Account API ต้องการการอนุญาต (Authorization) เพิ่มเติมสำหรับการดำเนินการที่เกี่ยวข้องกับตัวระบุและข้อมูลสำคัญอื่นๆ ### รับรหัสบันทึกการยืนยัน (verification record id) \{#get-a-verification-record-id} -ก่อนอื่น คุณต้องขอ **verification record ID** ที่มีอายุ 10 นาที (TTL) เพื่อใช้ยืนยันตัวตนผู้ใช้ก่อนอัปเดตข้อมูลสำคัญ หมายความว่า เมื่อผู้ใช้ยืนยันตัวตนสำเร็จผ่านรหัสผ่าน, โค้ดยืนยันอีเมล หรือโค้ดยืนยัน SMS จะมีเวลา 10 นาทีในการอัปเดตข้อมูลที่เกี่ยวข้องกับการยืนยันตัวตน เช่น ตัวระบุ, ข้อมูลรับรอง, การเชื่อมต่อบัญชีโซเชียล และ MFA +ก่อนอื่น คุณต้องขอ **verification record ID** ที่มีอายุ 10 นาที (TTL) เพื่อใช้ยืนยันตัวตนผู้ใช้ก่อนอัปเดตข้อมูลสำคัญ หมายความว่า เมื่อผู้ใช้ยืนยันตัวตนสำเร็จผ่านรหัสผ่าน รหัสยืนยันอีเมล หรือรหัสยืนยัน SMS จะมีเวลา 10 นาทีในการอัปเดตข้อมูลที่เกี่ยวข้องกับการยืนยันตัวตน เช่น ตัวระบุ ข้อมูลรับรอง การเชื่อมต่อบัญชีโซเชียล และ MFA -เพื่อรับ verification record ID คุณสามารถ [ยืนยันรหัสผ่านผู้ใช้](#verify-the-users-password) หรือ [ส่งโค้ดยืนยันไปยังอีเมลหรือโทรศัพท์ของผู้ใช้](#verify-by-sending-a-verification-code-to-the-users-email-or-phone) +เพื่อขอ verification record ID คุณสามารถ [ยืนยันรหัสผ่านผู้ใช้](#verify-the-users-password) หรือ [ส่งรหัสยืนยันไปยังอีเมลหรือโทรศัพท์ของผู้ใช้](#verify-by-sending-a-verification-code-to-the-users-email-or-phone) #### ยืนยันรหัสผ่านผู้ใช้ \{#verify-the-users-password} @@ -166,13 +166,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/password \ } ``` -#### ยืนยันโดยส่งโค้ดยืนยันไปยังอีเมลหรือโทรศัพท์ของผู้ใช้ \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} +#### ยืนยันโดยส่งรหัสยืนยันไปยังอีเมลหรือโทรศัพท์ของผู้ใช้ \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} :::note -หากต้องการใช้วิธีนี้ คุณต้อง [ตั้งค่าตัวเชื่อมต่ออีเมล](/connectors/email-connectors/) หรือ [ตัวเชื่อมต่อ SMS](/connectors/sms-connectors/) และตรวจสอบให้แน่ใจว่าได้ตั้งค่าเทมเพลต `UserPermissionValidation` แล้ว +หากต้องการใช้วิธีนี้ คุณต้อง [ตั้งค่า email connector](/connectors/email-connectors/) หรือ [SMS connector](/connectors/sms-connectors/) และตรวจสอบให้แน่ใจว่าได้ตั้งค่าเทมเพลต `UserPermissionValidation` แล้ว ::: -ตัวอย่างการขอโค้ดยืนยันใหม่และรับ verification record ID ผ่านอีเมล: +ตัวอย่างการขอรหัสยืนยันทางอีเมลและรับ verification record ID: ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ @@ -190,7 +190,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ } ``` -เมื่อได้รับโค้ดยืนยันแล้ว คุณสามารถใช้โค้ดนี้เพื่ออัปเดตสถานะการยืนยันของ verification record +เมื่อได้รับรหัสยืนยันแล้ว คุณสามารถใช้รหัสนั้นเพื่ออัปเดตสถานะการยืนยันของ verification record ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \ @@ -199,9 +199,9 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"123456"}' ``` -หลังจากยืนยันโค้ดแล้ว คุณสามารถใช้ verification record ID เพื่ออัปเดตตัวระบุของผู้ใช้ +หลังจากยืนยันรหัสแล้ว คุณสามารถใช้ verification record ID เพื่ออัปเดตตัวระบุของผู้ใช้ได้ -หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการยืนยัน โปรดดู [Security verification by Account API](/end-user-flows/security-verification) +หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการยืนยัน โปรดดูที่ [Security verification by Account API](/end-user-flows/security-verification) ### ส่งคำขอพร้อม verification record id \{#send-request-with-verification-record-id} @@ -209,7 +209,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v ### อัปเดตรหัสผ่านผู้ใช้ \{#update-users-password} -เพื่ออัปเดตรหัสผ่านผู้ใช้ ใช้ endpoint [`POST /api/my-account/password`](https://openapi.logto.io/operation/operation-updatepassword) +หากต้องการอัปเดตรหัสผ่านผู้ใช้ ให้ใช้ endpoint [`POST /api/my-account/password`](https://openapi.logto.io/operation/operation-updatepassword) ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/password \ @@ -219,15 +219,19 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +เช่นเดียวกับรหัสผ่านที่สร้างระหว่างสมัครใช้งาน รหัสผ่านที่ตั้งผ่าน Account API ต้องเป็นไปตาม [นโยบายรหัสผ่าน](/security/password-policy) ที่คุณตั้งค่าไว้ใน Console > Security > Password policy Logto จะส่งผลการตรวจสอบและข้อความผิดพลาดโดยละเอียดหากรหัสผ่านไม่ผ่านนโยบาย +::: + ### อัปเดตหรือเชื่อมโยงอีเมลใหม่ \{#update-or-link-new-email} :::note -หากต้องการใช้วิธีนี้ คุณต้อง [ตั้งค่าตัวเชื่อมต่ออีเมล](/connectors/email-connectors/) และตรวจสอบให้แน่ใจว่าได้ตั้งค่าเทมเพลต `BindNewIdentifier` แล้ว +หากต้องการใช้วิธีนี้ คุณต้อง [ตั้งค่า email connector](/connectors/email-connectors/) และตรวจสอบให้แน่ใจว่าได้ตั้งค่าเทมเพลต `BindNewIdentifier` แล้ว ::: -เพื่ออัปเดตหรือเชื่อมโยงอีเมลใหม่ คุณต้องพิสูจน์ความเป็นเจ้าของอีเมลก่อน +หากต้องการอัปเดตหรือเชื่อมโยงอีเมลใหม่ คุณต้องพิสูจน์ความเป็นเจ้าของอีเมลนั้นก่อน -เรียก endpoint [`POST /api/verifications/verification-code`](https://openapi.logto.io/operation/operation-createverificationbyverificationcode) เพื่อขอโค้ดยืนยัน +เรียก endpoint [`POST /api/verifications/verification-code`](https://openapi.logto.io/operation/operation-createverificationbyverificationcode) เพื่อขอรหัสยืนยัน ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ @@ -236,7 +240,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ --data-raw '{"identifier":{"type":"email","value":"..."}}' ``` -คุณจะพบ `verificationId` ใน response และได้รับโค้ดยืนยันทางอีเมล ให้นำไปยืนยันอีเมล +คุณจะพบ `verificationId` ใน response และได้รับรหัสยืนยันทางอีเมล ใช้รหัสนี้เพื่อยืนยันอีเมล ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \ @@ -245,7 +249,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}' ``` -หลังจากยืนยันโค้ดแล้ว ให้เรียก [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) เพื่ออัปเดตอีเมลผู้ใช้ โดยใส่ `verificationId` ใน request body เป็น `newIdentifierVerificationRecordId` +หลังจากยืนยันรหัสแล้ว ให้เรียก [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) เพื่ออัปเดตอีเมลของผู้ใช้ โดยใส่ `verificationId` ใน request body เป็น `newIdentifierVerificationRecordId` ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -255,9 +259,13 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +เช่นเดียวกับอีเมลที่เก็บระหว่างสมัครใช้งาน อีเมลใดๆ ที่เชื่อมโยงผ่าน Account API ต้องผ่านการตรวจสอบ [blocklist](/security/blocklist) ที่คุณตั้งค่าไว้ใน Console > Security > Blocklist Logto จะปฏิเสธคำขอและส่งข้อความผิดพลาดโดยละเอียดหากอีเมลละเมิดนโยบาย +::: + ### ลบอีเมลของผู้ใช้ \{#remove-the-users-email} -เพื่อลบอีเมลของผู้ใช้ ใช้ endpoint [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) +หากต้องการลบอีเมลของผู้ใช้ ให้ใช้ endpoint [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -268,14 +276,14 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### จัดการเบอร์โทรศัพท์ \{#manage-phone} :::note -หากต้องการใช้วิธีนี้ คุณต้อง [ตั้งค่าตัวเชื่อมต่อ SMS](/connectors/sms-connectors/) และตรวจสอบให้แน่ใจว่าได้ตั้งค่าเทมเพลต `BindNewIdentifier` แล้ว +หากต้องการใช้วิธีนี้ คุณต้อง [ตั้งค่า SMS connector](/connectors/sms-connectors/) และตรวจสอบให้แน่ใจว่าได้ตั้งค่าเทมเพลต `BindNewIdentifier` แล้ว ::: คล้ายกับการอัปเดตอีเมล คุณสามารถใช้ endpoint [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) เพื่ออัปเดตหรือเชื่อมโยงเบอร์โทรศัพท์ใหม่ และใช้ endpoint [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) เพื่อลบเบอร์โทรศัพท์ของผู้ใช้ -### เชื่อมโยงบัญชีโซเชียลใหม่ \{#link-a-new-social-connection} +### เชื่อมโยงการเชื่อมต่อโซเชียลใหม่ \{#link-a-new-social-connection} -เพื่อเชื่อมโยงบัญชีโซเชียลใหม่ ก่อนอื่นคุณต้องขอ authorization URL ด้วย [`POST /api/verifications/social`](https://openapi.logto.io/operation/operation-createverificationbysocial) +หากต้องการเชื่อมโยงการเชื่อมต่อโซเชียลใหม่ ให้ขอ authorization URL ก่อนด้วย [`POST /api/verifications/social`](https://openapi.logto.io/operation/operation-createverificationbysocial) ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social \ @@ -284,13 +292,13 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ --data-raw '{"connectorId":"...","redirectUri":"...","state":"..."}' ``` -- `connectorId`: รหัสของ [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors/) -- `redirectUri`: URI ที่จะเปลี่ยนเส้นทางหลังผู้ใช้อนุญาตแอป คุณควรโฮสต์หน้าเว็บที่ URL นี้และจับ callback -- `state`: สถานะที่จะถูกส่งกลับหลังผู้ใช้อนุญาตแอป เป็นสตริงสุ่มที่ใช้ป้องกัน CSRF +- `connectorId`: รหัสของ [social connector](/connectors/social-connectors/) +- `redirectUri`: URL ที่จะ redirect หลังผู้ใช้อนุญาตแอป คุณควรโฮสต์หน้าเว็บที่ URL นี้และจับ callback +- `state`: สถานะที่จะถูกส่งกลับหลังผู้ใช้อนุญาตแอป เป็นสตริงสุ่มเพื่อป้องกัน CSRF -ใน response คุณจะพบ `verificationRecordId` ให้เก็บไว้ใช้ในขั้นตอนถัดไป +ใน response คุณจะพบ `verificationRecordId` เก็บไว้ใช้ในขั้นตอนถัดไป -หลังจากผู้ใช้อนุญาตแอป คุณจะได้รับ callback ที่ `redirectUri` พร้อมพารามิเตอร์ `state` จากนั้นใช้ endpoint [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) เพื่อตรวจสอบการเชื่อมต่อโซเชียล +หลังผู้ใช้อนุญาตแอป คุณจะได้รับ callback ที่ `redirectUri` พร้อมพารามิเตอร์ `state` จากนั้นใช้ endpoint [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) เพื่อยืนยันการเชื่อมต่อโซเชียล ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ @@ -299,9 +307,9 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -`connectorData` คือข้อมูลที่ตัวเชื่อมต่อโซเชียลส่งกลับหลังผู้ใช้อนุญาตแอป คุณต้องดึง query parameters จาก `redirectUri` ในหน้า callback ของคุณ และห่อเป็น JSON ในฟิลด์ `connectorData` +`connectorData` คือข้อมูลที่ social connector ส่งกลับหลังผู้ใช้อนุญาตแอป คุณต้องแยก query parameters จาก `redirectUri` ในหน้า callback ของคุณ และห่อเป็น JSON ในฟิลด์ `connectorData` -สุดท้าย ใช้ endpoint [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) เพื่อเชื่อมโยงบัญชีโซเชียล +สุดท้าย ใช้ endpoint [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) เพื่อเชื่อมโยงการเชื่อมต่อโซเชียล ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/identities \ @@ -311,9 +319,9 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/identities \ --data-raw '{"newIdentifierVerificationRecordId":"..."}' ``` -### ลบบัญชีโซเชียล \{#remove-a-social-connection} +### ลบการเชื่อมต่อโซเชียล \{#remove-a-social-connection} -เพื่อลบบัญชีโซเชียล ใช้ endpoint [`DELETE /api/my-account/identities`](https://openapi.logto.io/operation/operation-deleteidentity) +หากต้องการลบการเชื่อมต่อโซเชียล ให้ใช้ endpoint [`DELETE /api/my-account/identities`](https://openapi.logto.io/operation/operation-deleteidentity) ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connector_target_id] \ @@ -335,16 +343,16 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connecto WebAuthn passkey จะผูกกับ hostname เฉพาะที่เรียกว่า **Relying Party ID (RP ID)** เฉพาะแอปที่โฮสต์บน origin ของ RP ID เท่านั้นที่สามารถลงทะเบียนหรือยืนยันตัวตนด้วย passkey เหล่านั้นได้ -เนื่องจากแอป front-end ของคุณเรียก Account API จากโดเมนที่ต่างจากหน้าการยืนยันตัวตนของ Logto คุณต้องกำหนดค่า **Related Origins** เพื่ออนุญาตการดำเนินการ passkey ข้ามโดเมน +เนื่องจากแอป front-end ของคุณเรียก Account API จากโดเมนที่ต่างจากหน้าการยืนยันตัวตนของ Logto คุณต้องกำหนด **Related Origins** เพื่ออนุญาตการดำเนินการ passkey ข้าม origin **Logto กำหนด RP ID อย่างไร:** - **ค่าเริ่มต้น**: หากใช้โดเมนเริ่มต้นของ Logto `https://[tenant-id].logto.app` RP ID คือ `[tenant-id].logto.app` - **Custom domain**: หากตั้งค่า [custom domain](/logto-cloud/custom-domain) เช่น `https://auth.example.com` RP ID จะเป็น `auth.example.com` -**กำหนดค่า Related Origins:** +**กำหนด Related Origins:** -ใช้ endpoint [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) เพื่อเพิ่ม origin ของแอป front-end ของคุณ เช่น หาก account center ของแอปรันที่ `https://account.example.com`: +ใช้ endpoint [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) เพื่อเพิ่ม origin ของแอป front-end ของคุณ เช่น ถ้า account center ของแอปรันที่ `https://account.example.com`: ```bash curl -X PATCH https://[tenant-id].logto.app/api/account-center \ @@ -353,7 +361,17 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -ดูข้อมูลเพิ่มเติมเกี่ยวกับ related origins ได้ที่ [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) +:::note + +WebAuthn รองรับได้สูงสุด 5 eTLD+1 labels สำหรับ Related Origins โดย eTLD+1 (effective top-level domain plus one label) คือส่วนโดเมนที่ลงทะเบียนได้ เช่น: + +- `https://example.com`, `https://app.example.com`, และ `https://auth.example.com` นับเป็น **หนึ่ง** label (`example.com`) +- `https://shopping.com`, `https://shopping.co.uk`, และ `https://shopping.co.jp` ก็นับเป็น **หนึ่ง** label (`shopping`) +- `https://example.com` และ `https://another.com` นับเป็น **สอง** label + +หากต้องการรองรับมากกว่า 5 โดเมนที่แตกต่างกันใน Related Origins โปรดดู [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) สำหรับรายละเอียด + +::: **ขั้นตอนที่ 2: ขอ registration options ใหม่** @@ -365,7 +383,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registrat -H 'content-type: application/json' ``` -ตัวอย่าง response: +คุณจะได้รับ response เช่น: ```json { @@ -418,12 +436,12 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ ``` - `verification_record_id`: verification record ID ที่ถูกต้อง โดยได้จากการยืนยันปัจจัยเดิมของผู้ใช้ ดูรายละเอียดที่ [รับรหัสบันทึกการยืนยัน](#get-a-verification-record-id) -- `type`: ประเภทของ MFA factor ปัจจุบันรองรับเฉพาะ `WebAuthn` +- `type`: ประเภทของ MFA factor ขณะนี้รองรับเฉพาะ `WebAuthn` - `newIdentifierVerificationRecordId`: verification record ID ที่ได้จากเซิร์ฟเวอร์ในขั้นตอนที่ 1 ### จัดการ WebAuthn passkey ที่มีอยู่ \{#manage-existing-webauthn-passkeys} -เพื่อจัดการ WebAuthn passkey ที่มีอยู่ ใช้ endpoint [`GET /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-getmfaverifications) เพื่อดึง passkey ปัจจุบันและปัจจัย MFA อื่น ๆ +หากต้องการจัดการ WebAuthn passkey ที่มีอยู่ ให้ใช้ endpoint [`GET /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-getmfaverifications) เพื่อดึง passkey ปัจจุบันและปัจจัย MFA อื่นๆ ```bash curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -498,12 +516,12 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp **ขั้นตอนที่ 2: แสดง TOTP secret ให้ผู้ใช้** -นำ secret ไปสร้าง QR code หรือแสดงให้ผู้ใช้โดยตรง ผู้ใช้ควรเพิ่ม secret นี้ลงในแอป authenticator (เช่น Google Authenticator, Microsoft Authenticator หรือ Authy) +ใช้ secret นี้สร้าง QR code หรือแสดงให้ผู้ใช้โดยตรง ผู้ใช้ควรเพิ่ม secret นี้ในแอป authenticator (เช่น Google Authenticator, Microsoft Authenticator หรือ Authy) รูปแบบ URI สำหรับ QR code คือ: ``` -otpauth://totp/[ผู้ออก]:[บัญชี]?secret=[Secret]&issuer=[ผู้ออก] +otpauth://totp/[Issuer]:[Account]?secret=[Secret]&issuer=[Issuer] ``` ตัวอย่าง: @@ -514,7 +532,7 @@ otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp **ขั้นตอนที่ 3: ผูกปัจจัย TOTP** -หลังจากผู้ใช้เพิ่ม secret ลงในแอป authenticator แล้ว ต้องยืนยันและผูกกับบัญชีผู้ใช้ โดยใช้ endpoint [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) +หลังผู้ใช้เพิ่ม secret ในแอป authenticator แล้ว ต้องยืนยันและผูกกับบัญชีผู้ใช้ ใช้ endpoint [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) เพื่อผูกปัจจัย TOTP ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -529,10 +547,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ - `secret`: TOTP secret ที่สร้างในขั้นตอนที่ 1 :::note -ผู้ใช้สามารถมีปัจจัย TOTP ได้เพียงหนึ่งรายการเท่านั้น หากมีอยู่แล้วและพยายามเพิ่มใหม่จะได้รับ error 422 +ผู้ใช้สามารถมีปัจจัย TOTP ได้เพียงหนึ่งรายการเท่านั้น หากผู้ใช้มี TOTP อยู่แล้ว การเพิ่มใหม่จะได้ error 422 ::: -### จัดการ backup codes \{#manage-backup-codes} +### จัดการรหัสสำรอง (backup codes) \{#manage-backup-codes} :::note อย่าลืม [เปิดใช้งาน MFA และ backup codes](/end-user-flows/mfa) ก่อน @@ -542,9 +560,9 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ หากต้องการใช้วิธีนี้ คุณต้องเปิดฟิลด์ `mfa` ใน [การตั้งค่า account center](#how-to-enable-account-api) ::: -**ขั้นตอนที่ 1: สร้าง backup codes ใหม่** +**ขั้นตอนที่ 1: สร้างรหัสสำรองใหม่** -ใช้ endpoint [`POST /api/my-account/mfa-verifications/backup-codes/generate`](https://openapi.logto.io/operation/operation-generatemyaccountbackupcodes) เพื่อสร้าง backup codes ชุดใหม่ 10 รหัส +ใช้ endpoint [`POST /api/my-account/mfa-verifications/backup-codes/generate`](https://openapi.logto.io/operation/operation-generatemyaccountbackupcodes) เพื่อสร้างรหัสสำรองใหม่ 10 รหัส ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes/generate \ @@ -560,20 +578,20 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/back } ``` -**ขั้นตอนที่ 2: แสดง backup codes ให้ผู้ใช้** +**ขั้นตอนที่ 2: แสดงรหัสสำรองให้ผู้ใช้** -ก่อนผูก backup codes กับบัญชีผู้ใช้ คุณต้องแสดงรหัสเหล่านี้ให้ผู้ใช้และแนะนำให้: +ก่อนผูกรหัสสำรองกับบัญชีผู้ใช้ คุณต้องแสดงรหัสเหล่านี้ให้ผู้ใช้และแนะนำให้: - ดาวน์โหลดหรือจดรหัสเหล่านี้ทันที - เก็บไว้ในที่ปลอดภัย - เข้าใจว่ารหัสแต่ละรหัสใช้ได้เพียงครั้งเดียว - ทราบว่ารหัสเหล่านี้เป็นทางเลือกสุดท้ายหากสูญเสียการเข้าถึงวิธี MFA หลัก -คุณควรแสดงรหัสในรูปแบบที่ชัดเจน ง่ายต่อการคัดลอก และอาจมีตัวเลือกให้ดาวน์โหลด (เช่น ไฟล์ข้อความหรือ PDF) +คุณควรแสดงรหัสในรูปแบบที่ชัดเจน ง่ายต่อการคัดลอก และอาจมีตัวเลือกดาวน์โหลด (เช่น ไฟล์ข้อความหรือ PDF) -**ขั้นตอนที่ 3: ผูก backup codes กับบัญชีผู้ใช้** +**ขั้นตอนที่ 3: ผูกรหัสสำรองกับบัญชีผู้ใช้** -ใช้ endpoint [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) เพื่อผูก backup codes กับบัญชีผู้ใช้ +ใช้ endpoint [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) เพื่อผูกรหัสสำรองกับบัญชีผู้ใช้ ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -585,19 +603,19 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ - `verification_record_id`: verification record ID ที่ถูกต้อง โดยได้จากการยืนยันปัจจัยเดิมของผู้ใช้ ดูรายละเอียดที่ [รับรหัสบันทึกการยืนยัน](#get-a-verification-record-id) - `type`: ต้องเป็น `BackupCode` -- `codes`: อาร์เรย์ของ backup codes ที่สร้างในขั้นตอนก่อนหน้า +- `codes`: อาร์เรย์ของรหัสสำรองที่สร้างในขั้นตอนก่อนหน้า :::note -- ผู้ใช้สามารถมี backup codes ได้เพียงชุดเดียว หากใช้หมดแล้วต้องสร้างและผูกใหม่ -- backup codes ไม่สามารถเป็นปัจจัย MFA เพียงอย่างเดียวได้ ผู้ใช้ต้องเปิดใช้งานปัจจัย MFA อื่นอย่างน้อยหนึ่งรายการ (เช่น WebAuthn หรือ TOTP) -- backup code แต่ละรหัสใช้ได้เพียงครั้งเดียว +- ผู้ใช้สามารถมีชุดรหัสสำรองได้เพียงชุดเดียว หากใช้หมดแล้วต้องสร้างและผูกใหม่ +- รหัสสำรองไม่สามารถเป็นปัจจัย MFA เพียงอย่างเดียวได้ ผู้ใช้ต้องมีปัจจัย MFA อื่นอย่างน้อยหนึ่งรายการ (เช่น WebAuthn หรือ TOTP) +- รหัสสำรองแต่ละรหัสใช้ได้เพียงครั้งเดียว ::: -**ดู backup codes ที่มีอยู่** +**ดูรหัสสำรองที่มีอยู่** -เพื่อดู backup codes ที่มีอยู่และสถานะการใช้งาน ใช้ endpoint [`GET /api/my-account/mfa-verifications/backup-codes`](https://openapi.logto.io/operation/operation-getbackupcodes): +หากต้องการดูรหัสสำรองที่มีอยู่และสถานะการใช้งาน ให้ใช้ endpoint [`GET /api/my-account/mfa-verifications/backup-codes`](https://openapi.logto.io/operation/operation-getbackupcodes): ```bash curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes \ @@ -621,5 +639,5 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes } ``` -- `code`: backup code -- `usedAt`: เวลาที่ใช้รหัสนั้น `null` หากยังไม่ถูกใช้ +- `code`: รหัสสำรอง +- `usedAt`: เวลาที่ใช้รหัส ถ้ายังไม่ใช้จะเป็น `null` diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index 2a61cccd352..c8247b0eb19 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -4,7 +4,7 @@ sidebar_position: 2 # พารามิเตอร์หน้าจอแรก -ชุดของพารามิเตอร์การยืนยันตัวตนแบบกำหนดเองที่ช่วยให้คุณปรับแต่งประสบการณ์หน้าจอแรกตามที่ต้องการสำหรับผู้ใช้ปลายทาง +ชุดพารามิเตอร์การยืนยันตัวตนแบบกำหนดเองที่ช่วยให้คุณปรับแต่งประสบการณ์หน้าจอแรกตามที่ต้องการสำหรับผู้ใช้ปลายทาง - `first_screen`: ระบุหน้าจอแรกที่ผู้ใช้จะเห็น - `identifier`: ระบุประเภทตัวระบุที่ฟอร์มลงชื่อเข้าใช้หรือลงทะเบียนจะยอมรับ @@ -14,42 +14,46 @@ sidebar_position: 2 พารามิเตอร์ `first_screen` เป็นพารามิเตอร์หลักที่กำหนดว่าผู้ใช้จะเห็นหน้าจอแรกใดเมื่อถูกเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ของ Logto โดยค่าเริ่มต้นจะเป็นฟอร์มลงชื่อเข้าใช้แบบสากล คุณสามารถใช้พารามิเตอร์นี้เพื่อปรับแต่งหน้าจอแรกตามความต้องการของแอปพลิเคชันของคุณ ค่าที่รองรับ ได้แก่: -- `sign_in`: แสดงฟอร์มลงชื่อเข้าใช้ (ค่าเริ่มต้น) +- `sign_in` (ค่าเริ่มต้น): แสดงฟอร์มลงชื่อเข้าใช้ - `register`: แสดงฟอร์มลงทะเบียน - `reset_password`: แสดงฟอร์มรีเซ็ตรหัสผ่าน -- `single_sign_on`: แสดงฟอร์มลงชื่อเข้าใช้ Enterprise SSO (ระบบจะขออีเมลเพื่อระบุผู้ให้บริการ SSO ที่เปิดใช้งาน) -- `identifier:sign-in`: แสดงฟอร์มลงชื่อเข้าใช้แบบระบุชนิดตัวระบุ สามารถระบุประเภทตัวระบุได้ด้วยพารามิเตอร์ `identifier` เหมาะสำหรับกรณีที่คุณเปิดใช้งานวิธีลงชื่อเข้าใช้หลายแบบ -- `identifier:register`: แสดงฟอร์มลงทะเบียนแบบระบุชนิดตัวระบุ สามารถระบุประเภทตัวระบุได้ด้วยพารามิเตอร์ `identifier` เหมาะสำหรับกรณีที่คุณเปิดใช้งานวิธีลงทะเบียนหลายแบบ +- `single_sign_on`: แสดงฟอร์มลงชื่อเข้าใช้ SSO สำหรับองค์กร (ระบบจะถามอีเมลเพื่อกำหนดผู้ให้บริการ SSO ที่เปิดใช้งาน) +- `identifier:sign-in`: แสดงฟอร์มลงชื่อเข้าใช้แบบระบุประเภทตัวระบุ สามารถระบุประเภทตัวระบุได้ด้วยพารามิเตอร์ `identifier` (ไม่บังคับ) เหมาะสำหรับกรณีที่คุณเปิดใช้งานวิธีลงชื่อเข้าใช้หลายประเภท +- `identifier:register`: แสดงฟอร์มลงทะเบียนแบบระบุประเภทตัวระบุ สามารถระบุประเภทตัวระบุได้ด้วยพารามิเตอร์ `identifier` (ไม่บังคับ) เหมาะสำหรับกรณีที่คุณเปิดใช้งานวิธีลงทะเบียนหลายประเภท First screen parameter -ตัวอย่างเช่น การส่งผู้ใช้ไปยังฟอร์มลงชื่อเข้าใช้ Enterprise SSO โดยตรง: +ตัวอย่างเช่น ส่งผู้ใช้ไปยังฟอร์มลงชื่อเข้าใช้ SSO สำหรับองค์กรโดยตรง: ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +หน้าจอแรกจะเป็นไปตามการตั้งค่าที่กำหนดใน Console > ประสบการณ์การลงชื่อเข้าใช้ คุณต้องเปิดใช้งานวิธีการยืนยันตัวตนที่ต้องการก่อน และตั้งค่าแบรนด์ ข้อกำหนดและนโยบายความเป็นส่วนตัว และการแปลภาษา (i18n) โปรดทราบว่าเฉพาะหน้าลงชื่อเข้าใช้ (`sign-in`) และหน้าลงทะเบียน (`register`) เท่านั้นที่แสดงโลโก้โดยค่าเริ่มต้น +::: + ## identifier \{#identifier} -พารามิเตอร์ `identifier` ใช้สำหรับระบุประเภทตัวระบุที่ฟอร์มลงชื่อเข้าใช้หรือลงทะเบียนจะรับค่า พารามิเตอร์นี้จะใช้ได้เฉพาะเมื่อพารามิเตอร์ `first_screen` ถูกตั้งค่าเป็น `identifier:sign-in`, `identifier:register` หรือ `reset_password` ค่าที่รองรับ ได้แก่: `username`, `email` และ `phone` หากต้องการอนุญาตหลายประเภท ให้คั่นค่าด้วยช่องว่าง +พารามิเตอร์ `identifier` ใช้เพื่อระบุประเภทตัวระบุที่ฟอร์มลงชื่อเข้าใช้หรือลงทะเบียนจะรับ ค่านี้ใช้ได้เฉพาะเมื่อพารามิเตอร์ `first_screen` ถูกตั้งค่าเป็น `identifier:sign-in`, `identifier:register` หรือ `reset_password` ค่าที่รองรับ ได้แก่: `username`, `email` และ `phone` หากต้องการอนุญาตหลายประเภท ให้คั่นค่าด้วยช่องว่าง -ตัวอย่างเช่น การส่งผู้ใช้ไปยังหน้าลงทะเบียนด้วยอีเมลหรือเบอร์โทรศัพท์โดยตรง: +ตัวอย่างเช่น ส่งผู้ใช้ไปยังหน้าลงทะเบียนด้วยอีเมลหรือเบอร์โทรศัพท์โดยตรง: ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=identifier:register&identifier=email phone' ``` -ประเภทตัวระบุทั้งหมดที่ระบุในพารามิเตอร์นี้จะต้องถูกเปิดใช้งานในการตั้งค่าการลงชื่อเข้าใช้หรือลงทะเบียนใน Logto Console +ประเภทตัวระบุทั้งหมดที่ระบุในพารามิเตอร์นี้จะต้องถูกเปิดใช้งานในหน้าตั้งค่าการลงชื่อเข้าใช้หรือลงทะเบียนใน Logto Console -ประเภทตัวระบุที่ไม่รองรับหรือถูกปิดใช้งานจะถูกละเว้น หากตัวระบุที่ระบุทั้งหมดไม่รองรับ จะใช้การตั้งค่าประสบการณ์ลงชื่อเข้าใช้เริ่มต้นแทน +ประเภทตัวระบุที่ไม่รองรับหรือถูกปิดใช้งานจะถูกละเว้น หากตัวระบุที่ระบุทั้งหมดไม่รองรับ จะใช้การตั้งค่าประสบการณ์การลงชื่อเข้าใช้เริ่มต้นแทน ## login_hint \{#login_hint} -พารามิเตอร์ `login_hint` ซึ่งกำหนดไว้ใน [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) มาตรฐาน ใช้สำหรับเติมข้อมูลล่วงหน้าในฟอร์มลงชื่อเข้าใช้ด้วยตัวระบุของผู้ใช้ (เช่น อีเมล เบอร์โทรศัพท์ หรือชื่อผู้ใช้) ใน Logto คุณสามารถใช้ร่วมกับพารามิเตอร์หน้าจอลงชื่อเข้าใช้อื่น ๆ เพื่อเพิ่มประสบการณ์ผู้ใช้ พารามิเตอร์นี้เหมาะอย่างยิ่งหากคุณมีฟอร์มก่อนการยืนยันตัวตนแบบกำหนดเองที่เก็บตัวระบุของผู้ใช้ไว้ล่วงหน้า ทำให้ผู้ใช้ไม่ต้องกรอกซ้ำในขั้นตอนลงชื่อเข้าใช้ +พารามิเตอร์ `login_hint` ซึ่งกำหนดไว้ใน [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) มาตรฐาน ใช้เพื่อเติมข้อมูลล่วงหน้าในฟอร์มลงชื่อเข้าใช้ด้วยตัวระบุของผู้ใช้ (เช่น อีเมล เบอร์โทรศัพท์ หรือชื่อผู้ใช้) ใน Logto คุณสามารถใช้ร่วมกับพารามิเตอร์หน้าจอลงชื่อเข้าใช้อื่น ๆ เพื่อเพิ่มประสบการณ์ผู้ใช้ พารามิเตอร์นี้มีประโยชน์มากหากคุณมีฟอร์มก่อนการยืนยันตัวตนแบบกำหนดเองที่เก็บตัวระบุของผู้ใช้ไว้ล่วงหน้า ทำให้ผู้ใช้ไม่ต้องกรอกซ้ำในขั้นตอนลงชื่อเข้าใช้ -ตัวอย่างเช่น การเติมอีเมลที่เก็บไว้ล่วงหน้าในฟอร์มลงชื่อเข้าใช้: +ตัวอย่างเช่น เติมอีเมลที่เก็บไว้ล่วงหน้าในฟอร์มลงชื่อเข้าใช้: ```sh curl --location \ @@ -58,7 +62,7 @@ curl --location \ ## การรองรับ SDK \{#sdk-support} -ใน Logto SDK ที่รองรับ คุณสามารถตั้งค่าพารามิเตอร์เหล่านี้ขณะเรียกใช้เมธอด `signIn`: +ใน Logto SDK ที่รองรับ คุณสามารถตั้งค่าพารามิเตอร์เหล่านี้ขณะเรียกใช้เมธอด `signIn` ได้ดังนี้: ```javascript logtoClient.signIn({ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index 6f462aa8802..a9e8ccb1149 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -8,26 +8,27 @@ Logto รองรับพารามิเตอร์มาตรฐาน O ## สิ่งที่ทำได้ \{#what-it-does} -- กำหนดภาษาของ UI สำหรับประสบการณ์การลงชื่อเข้าใช้ที่โฮสต์โดย Logto ในขณะรันไทม์ Logto จะเลือกแท็กภาษาตัวแรกใน `ui_locales` ที่รองรับในไลบรารีภาษาของ tenant ของคุณ -- มีผลกับการแปลอีเมลสำหรับข้อความที่ถูกกระตุ้นโดยอินเทอร์แอคชัน (เช่น อีเมลรหัสยืนยัน) ดู [การแปลเทมเพลตอีเมล](/connectors/email-connectors/email-templates#email-template-localization) -- เปิดเผยค่าต้นฉบับไปยังเทมเพลตอีเมลเป็นตัวแปร `uiLocales` เพื่อให้คุณสามารถนำไปใช้ในหัวข้อ/เนื้อหาอีเมลได้หากต้องการ +- กำหนดภาษาของ UI ในประสบการณ์การลงชื่อเข้าใช้ที่โฮสต์โดย Logto ขณะรันไทม์ Logto จะเลือกแท็กภาษาตัวแรกใน `ui_locales` ที่รองรับในไลบรารีภาษาใน tenant ของคุณ +- มีผลกับการแปลอีเมลสำหรับข้อความที่ถูกทริกเกอร์โดยอินเทอร์แอคชัน (เช่น อีเมลรหัสยืนยัน) ดู [การแปลเทมเพลตอีเมล](/connectors/email-connectors/email-templates#email-template-localization) +- เปิดเผยค่าต้นฉบับให้กับเทมเพลตอีเมลเป็นตัวแปร `uiLocales` เพื่อให้คุณสามารถนำไปใช้ในหัวข้อ/เนื้อหาอีเมลได้หากต้องการ +- กำหนดรหัสประเทศเริ่มต้นของหมายเลขโทรศัพท์ในประสบการณ์การลงชื่อเข้าใช้ เช่น หาก `ui_locales=fr` ช่องกรอกหมายเลขโทรศัพท์จะตั้งค่าเริ่มต้นเป็นฝรั่งเศส (+33) ฟีเจอร์นี้มีประโยชน์เมื่อคุณต้องการควบคุมรหัสประเทศเริ่มต้นแบบโปรแกรมสำหรับกลุ่มผู้ใช้หรือภูมิภาคเฉพาะ ## รูปแบบของพารามิเตอร์ \{#parameter-format} - ชื่อ: `ui_locales` - ชนิด: `string` -- ค่า: รายการแท็กภาษาตามมาตรฐาน BCP 47 คั่นด้วยช่องว่าง เช่น `fr-CA fr en` +- ค่า: รายการแท็กภาษาตาม BCP 47 คั่นด้วยช่องว่าง เช่น `fr-CA fr en` - อ้างอิง: [OpenID Connect Core - ui_locales](https://openid.net/specs/openid-connect-core-1_0.html) ## ลำดับและลำดับความสำคัญในการเลือกภาษา \{#resolution-order-and-precedence} เมื่อกำหนดภาษาของ UI สำหรับประสบการณ์การลงชื่อเข้าใช้และอีเมลที่เกี่ยวข้อง Logto จะเลือกภาษาของผู้ใช้ปลายทางตามลำดับนี้: -1. `ui_locales` จากคำขอการยืนยันตัวตน (authentication request) ปัจจุบัน (แท็กที่รองรับตัวแรกจะถูกเลือก) -2. หากไม่พบ ใช้ `Accept-Language` header (Experience APIs / User Account APIs) หรือ `messagePayload.locale` (Management APIs เช่น การเชิญองค์กร) +1. `ui_locales` จากคำขอการยืนยันตัวตนปัจจุบัน (แท็กที่รองรับตัวแรกจะถูกเลือก) +2. หากไม่พบ ใช้ `Accept-Language` header (Experience API / Account API) หรือ `messagePayload.locale` (Management API เช่น คำเชิญองค์กร) 3. หากยังไม่พบ ใช้ภาษาหลักของ tenant ที่ตั้งค่าไว้ใน Sign-in Experience -พฤติกรรมนี้จะไม่เปลี่ยนการตั้งค่าภาษาของคุณถาวร; จะมีผลเฉพาะกับอินเทอร์แอคชันปัจจุบันเท่านั้น +พฤติกรรมนี้จะไม่เปลี่ยนการตั้งค่าภาษาของคุณถาวร มีผลเฉพาะกับอินเทอร์แอคชันปัจจุบันเท่านั้น ## การใช้งาน SDK \{#sdk-usage} @@ -44,11 +45,11 @@ await logtoClient.signIn({ ## ตัวอย่าง \{#examples} -- `ui_locales=fr-CA fr en` → หาก `fr-CA` มีอยู่ในไลบรารีภาษา UI จะเป็นภาษาฝรั่งเศส (แคนาดา); หากไม่พบจะย้อนกลับไปที่ `fr` แล้วจึงเป็น `en` -- `ui_locales=ja` แต่ไม่ได้เปิดใช้งานภาษาญี่ปุ่น → จะย้อนกลับไปที่ `Accept-Language` หรือภาษาหลักของ tenant +- `ui_locales=fr-CA fr en` → หาก `fr-CA` มีอยู่ในไลบรารีภาษา UI จะเป็นภาษาฝรั่งเศส (แคนาดา) หากไม่พบจะย้อนกลับไปที่ `fr` แล้วจึงเป็น `en` +- `ui_locales=ja` แต่ไม่ได้เปิดใช้งานภาษาญี่ปุ่น → จะย้อนกลับไปที่ `Accept-Language` หรือค่าหลักของ tenant ## ที่เกี่ยวข้อง \{#related} -- [ภาษาท้องถิ่น](/customization/localized-languages) +- [ภาษาท้องถิ่นที่รองรับ](/customization/localized-languages) - [เทมเพลตอีเมล](/connectors/email-connectors/email-templates#email-template-localization) - [พารามิเตอร์การยืนยันตัวตน](/end-user-flows/authentication-parameters) diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index ecae3960d5e..7e6b6acb4f8 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -2,11 +2,11 @@ sidebar_position: 2 --- -# ลงชื่อเข้าใช้ด้วยอีเมล / เบอร์โทรศัพท์ / ชื่อผู้ใช้ +# การลงชื่อเข้าใช้ด้วยอีเมล / เบอร์โทรศัพท์ / ชื่อผู้ใช้ ## กำหนดค่ากระบวนการลงชื่อเข้าใช้ด้วยตัวระบุ \{#configure-the-identifier-sign-in-flow} -ตามที่กล่าวไว้ก่อนหน้านี้ คุณสามารถเก็บข้อมูลตัวระบุประเภทต่าง ๆ จากผู้ใช้ได้ตลอด [กระบวนการสมัครสมาชิก](/end-user-flows/sign-up-and-sign-in/sign-up) หรือ [การสร้างบัญชีโดยตรงใน Logto](/user-management/manage-users#add-users) นอกจากนี้ ผู้ใช้อาจกรอกและยืนยันข้อมูลเพิ่มเติมเมื่อใช้งานผลิตภัณฑ์ ตัวระบุเหล่านี้สามารถใช้ระบุผู้ใช้แต่ละรายในระบบของ Logto ได้อย่างชัดเจน และอนุญาตให้พวกเขายืนยันตัวตนและลงชื่อเข้าใช้แอปพลิเคชันที่เชื่อมต่อกับ Logto +ดังที่กล่าวไว้ก่อนหน้านี้ คุณสามารถเก็บข้อมูลตัวระบุประเภทต่าง ๆ จากผู้ใช้ได้ตลอด [กระบวนการสมัครสมาชิก](/end-user-flows/sign-up-and-sign-in/sign-up) หรือ [การสร้างบัญชีโดยตรงใน Logto](/user-management/manage-users#add-users) นอกจากนี้ ผู้ใช้อาจกรอกและยืนยันข้อมูลเพิ่มเติมเมื่อใช้งานผลิตภัณฑ์ ตัวระบุเหล่านี้สามารถใช้ระบุผู้ใช้แต่ละรายในระบบของ Logto ได้อย่างไม่ซ้ำกัน และอนุญาตให้พวกเขายืนยันตัวตนและลงชื่อเข้าใช้แอปพลิเคชันที่เชื่อมต่อกับ Logto ไม่ว่าคุณจะเลือกใช้หน้าลงชื่อเข้าใช้สำเร็จรูปที่โฮสต์โดย Logto หรือวางแผน [สร้าง UI ลงชื่อเข้าใช้ของคุณเอง](/customization#custom-ui) คุณจะต้องกำหนดวิธีการลงชื่อเข้าใช้และการตั้งค่าการยืนยันตัวตนที่พร้อมใช้งานสำหรับผู้ใช้ปลายทาง @@ -14,7 +14,7 @@ sidebar_position: 2 ### 1. กำหนดตัวระบุที่รองรับสำหรับการลงชื่อเข้าใช้ \{#1-set-the-supported-sign-in-identifiers} -คุณสามารถเพิ่มตัวระบุที่รองรับหลายรายการจากรายการดรอปดาวน์ เพื่อเปิดใช้งานเป็นวิธีการลงชื่อเข้าใช้สำหรับผู้ใช้ปลายทาง ตัวเลือกที่มีให้ ได้แก่: +คุณสามารถเพิ่มตัวระบุที่รองรับหลายรายการจากรายการแบบดรอปดาวน์เป็นวิธีการลงชื่อเข้าใช้ที่เปิดใช้งานสำหรับผู้ใช้ปลายทาง ตัวเลือกที่มี ได้แก่ - **ชื่อผู้ใช้** - **ที่อยู่อีเมล** @@ -24,23 +24,24 @@ sidebar_position: 2 ### 2. ตั้งค่าการยืนยันตัวตน \{#2-set-the-authentication-settings} -สำหรับแต่ละตัวระบุที่ใช้ลงชื่อเข้าใช้ คุณต้องกำหนดปัจจัยการยืนยันตัวตนอย่างน้อยหนึ่งรายการเพื่อยืนยันตัวตนของผู้ใช้ มีปัจจัยให้เลือกสองแบบ: +สำหรับแต่ละตัวระบุที่ใช้ลงชื่อเข้าใช้ คุณต้องกำหนดปัจจัยการยืนยันตัวตนอย่างน้อยหนึ่งรายการเพื่อยืนยันตัวตนของผู้ใช้ โดยมีสองปัจจัยให้เลือก: - **รหัสผ่าน**: ใช้ได้กับตัวระบุทุกประเภท เมื่อเปิดใช้งาน ผู้ใช้ต้องกรอกรหัสผ่านเพื่อดำเนินการลงชื่อเข้าใช้ให้เสร็จสมบูรณ์ - **รหัสยืนยัน**: ใช้ได้กับตัวระบุ **ที่อยู่อีเมล** และ **หมายเลขโทรศัพท์** เท่านั้น เมื่อเปิดใช้งาน ผู้ใช้ต้องกรอกรหัสยืนยันที่ส่งไปยังอีเมลหรือเบอร์โทรศัพท์เพื่อดำเนินการลงชื่อเข้าใช้ให้เสร็จสมบูรณ์ -หากเปิดใช้งานทั้งสองปัจจัย ผู้ใช้สามารถเลือกวิธีใดวิธีหนึ่งเพื่อดำเนินการลงชื่อเข้าใช้ คุณยังสามารถจัดลำดับปัจจัยใหม่เพื่อเปลี่ยนลำดับการแสดงผลบนหน้าลงชื่อเข้าใช้ ปัจจัยแรกจะถูกใช้เป็นวิธีการยืนยันหลัก และปัจจัยที่สองจะแสดงเป็นลิงก์ทางเลือก +หากเปิดใช้งานทั้งสองปัจจัย ผู้ใช้สามารถเลือกวิธีใดวิธีหนึ่งเพื่อดำเนินการลงชื่อเข้าใช้ คุณยังสามารถจัดลำดับปัจจัยใหม่เพื่อเปลี่ยนลำดับการแสดงผลบนหน้าลงชื่อเข้าใช้ได้ ปัจจัยแรกจะถูกใช้เป็นวิธีการยืนยันหลัก และปัจจัยที่สองจะแสดงเป็นลิงก์ทางเลือก ## ประสบการณ์ผู้ใช้ในกระบวนการลงชื่อเข้าใช้ด้วยตัวระบุ \{#identifier-sign-in-flow-user-experience} -ประสบการณ์การลงชื่อเข้าใช้จะปรับเปลี่ยนตามตัวระบุที่เลือกและปัจจัยการยืนยันตัวตนที่เปิดใช้งาน +ประสบการณ์การลงชื่อเข้าใช้จะปรับเปลี่ยนตามตัวระบุที่เลือกและปัจจัยการยืนยันตัวตนที่มีให้ - **อินพุตอัจฉริยะสำหรับหลายตัวระบุ:** - หากเปิดใช้งานวิธีการลงชื่อเข้าใช้ด้วยตัวระบรมากกว่าหนึ่งแบบ หน้าลงชื่อเข้าใช้ของ Logto จะตรวจจับประเภทของตัวระบุที่ผู้ใช้กรอกโดยอัตโนมัติและแสดงตัวเลือกการยืนยันที่เกี่ยวข้อง ตัวอย่างเช่น หากเปิดใช้งานทั้ง **ที่อยู่อีเมล** และ **หมายเลขโทรศัพท์** หน้าลงชื่อเข้าใช้จะตรวจจับประเภทของตัวระบุที่ผู้ใช้กรอกโดยอัตโนมัติและแสดงตัวเลือกการยืนยันที่เกี่ยวข้อง หากกรอกตัวเลขต่อเนื่องจะเปลี่ยนเป็นรูปแบบเบอร์โทรศัพท์พร้อมรหัสประเทศ หรือหากมีสัญลักษณ์ “@” จะเปลี่ยนเป็นรูปแบบอีเมล + หากเปิดใช้งานวิธีการลงชื่อเข้าใช้ด้วยตัวระบรมากกว่าหนึ่งแบบ หน้าลงชื่อเข้าใช้ของ Logto จะตรวจจับประเภทของตัวระบุที่ผู้ใช้กรอกโดยอัตโนมัติและแสดงตัวเลือกการยืนยันที่เกี่ยวข้อง ตัวอย่างเช่น หากเปิดใช้งานทั้ง **ที่อยู่อีเมล** และ **หมายเลขโทรศัพท์** หน้าลงชื่อเข้าใช้จะตรวจจับประเภทของตัวระบุที่ผู้ใช้กรอกและแสดงตัวเลือกการยืนยันที่เกี่ยวข้องโดยอัตโนมัติ โดยจะสลับเป็นรูปแบบหมายเลขโทรศัพท์พร้อมรหัสประเทศหากกรอกตัวเลขต่อเนื่อง หรือเป็นรูปแบบอีเมลเมื่อใช้สัญลักษณ์ "@" + - รหัสประเทศของหมายเลขโทรศัพท์จะตั้งค่าตามภาษาของเบราว์เซอร์ผู้ใช้โดยอัตโนมัติ ผู้ใช้สามารถเปลี่ยนเองได้ คุณสามารถใช้พารามิเตอร์ [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) เพื่อกำหนดรหัสประเทศเริ่มต้นโดยเฉพาะ ดูรายละเอียดเพิ่มเติมที่ [ภาษาท้องถิ่น](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience) - **ปัจจัยการยืนยันที่เปิดใช้งาน:** - - **เฉพาะรหัสผ่าน:** จะแสดงช่องกรอกตัวระบุและรหัสผ่านในหน้าจอแรก - - **เฉพาะรหัสยืนยัน:** จะแสดงช่องกรอกตัวระบุในหน้าจอแรก ตามด้วยช่องกรอกรหัสยืนยันในหน้าจอที่สอง - - **รหัสผ่านและรหัสยืนยัน:** กรอกตัวระบุในหน้าจอแรก ตามด้วยขั้นตอนกรอกรหัสผ่านหรือรหัสยืนยันในหน้าจอที่สองตามลำดับปัจจัยการยืนยัน โดยมีลิงก์สลับวิธีให้ผู้ใช้เปลี่ยนระหว่างสองวิธีได้ + - **รหัสผ่านเท่านั้น:** จะแสดงช่องกรอกตัวระบุและรหัสผ่านบนหน้าจอแรก + - **รหัสยืนยันเท่านั้น:** จะแสดงช่องกรอกตัวระบุบนหน้าจอแรก ตามด้วยช่องกรอกรหัสยืนยันบนหน้าจอที่สอง + - **รหัสผ่านและรหัสยืนยัน:** กรอกตัวระบุบนหน้าจอแรก จากนั้นดำเนินการกรอกรหัสผ่านหรือรหัสยืนยันบนหน้าจอที่สองตามลำดับการยืนยัน โดยมีลิงก์สลับวิธีให้ผู้ใช้เลือก ### ตัวอย่าง \{#examples} @@ -51,7 +52,7 @@ sidebar_position: 2 -เพิ่ม **ที่อยู่อีเมล** เป็นตัวระบุสำหรับลงชื่อเข้าใช้และเปิดใช้งานปัจจัย **รหัสผ่าน** สำหรับการยืนยัน +เพิ่ม **ที่อยู่อีเมล** เป็นตัวระบุสำหรับลงชื่อเข้าใช้ และเปิดใช้งานปัจจัย **รหัสผ่าน** สำหรับการยืนยัน Email address with password verification @@ -74,18 +75,18 @@ sidebar_position: 2 -## เก็บข้อมูลโปรไฟล์ผู้ใช้เพิ่มเติมขณะลงชื่อเข้าใช้ \{#collect-additional-user-profile-on-sign-in} +## เก็บข้อมูลโปรไฟล์ผู้ใช้เพิ่มเติมระหว่างลงชื่อเข้าใช้ \{#collect-additional-user-profile-on-sign-in} -ในกระบวนการลงชื่อเข้าใช้ของ Logto อาจมีการเรียกใช้ขั้นตอนการกรอกโปรไฟล์หากมีการอัปเดตการตั้งค่าตัวระบุสำหรับสมัครสมาชิก เพื่อให้แน่ใจว่าผู้ใช้ทุกคน (รวมถึงผู้ใช้เดิม) จะต้องกรอกตัวระบุที่จำเป็นใหม่ +ในกระบวนการลงชื่อเข้าใช้ของ Logto อาจมีการเรียกใช้กระบวนการเติมข้อมูลโปรไฟล์หากมีการอัปเดตการตั้งค่าตัวระบุสำหรับสมัครสมาชิก เพื่อให้แน่ใจว่าผู้ใช้ทุกคน (รวมถึงผู้ใช้เดิม) จะต้องกรอกตัวระบุใหม่ที่จำเป็น -เมื่อผู้พัฒนาระบบเพิ่มตัวระบุใหม่ (เช่น ที่อยู่อีเมล) จะกลายเป็นข้อมูลบังคับสำหรับผู้ใช้ทุกคน หากผู้ใช้เดิมลงชื่อเข้าใช้ด้วยตัวระบุเดิม (เช่น ชื่อผู้ใช้) ระบบจะขอให้กรอกและยืนยันตัวระบุใหม่หากยังไม่มีในโปรไฟล์ เมื่อดำเนินการเสร็จสิ้นจึงจะสามารถเข้าใช้งานแอปพลิเคชันได้ เพื่อให้การเปลี่ยนผ่านไปสู่ข้อกำหนดใหม่เป็นไปอย่างราบรื่นและสม่ำเสมอ +เมื่อมีการเพิ่มตัวระบุใหม่ (เช่น ที่อยู่อีเมล) โดยนักพัฒนา ตัวระบุนั้นจะกลายเป็นข้อมูลบังคับสำหรับผู้ใช้ทุกคน หากผู้ใช้เดิมลงชื่อเข้าใช้ด้วยตัวระบุเดิม (เช่น ชื่อผู้ใช้) ระบบจะขอให้กรอกและยืนยันตัวระบุใหม่หากยังไม่มีในโปรไฟล์ เมื่อดำเนินการเสร็จสิ้นจึงจะสามารถเข้าใช้งานแอปพลิเคชันได้ เพื่อให้การเปลี่ยนแปลงข้อกำหนดเป็นไปอย่างราบรื่นและสม่ำเสมอ -ขั้นตอนโดยสังเขป: +รายละเอียดกระบวนการ: -1. **ชื่อผู้ใช้** ถูกตั้งเป็นตัวระบุสำหรับสมัครสมาชิก พร้อมเปิดใช้งาน **สร้างรหัสผ่านของคุณ** -2. **ที่อยู่อีเมล** ถูกตั้งเป็นตัวระบุสำหรับสมัครสมาชิกในภายหลัง ตัวระบุ **ที่อยู่อีเมล** จะถูกเพิ่มเป็นตัวเลือกสำหรับลงชื่อเข้าใช้โดยอัตโนมัติ +1. **ชื่อผู้ใช้** ถูกตั้งเป็นตัวระบุสำหรับสมัครสมาชิก พร้อมเปิดใช้งาน **สร้างรหัสผ่านของคุณ** โดยอัตโนมัติ +2. ต่อมา **ที่อยู่อีเมล** ถูกตั้งเป็นตัวระบุสำหรับสมัครสมาชิก ตัวระบุ **ที่อยู่อีเมล** จะถูกเพิ่มเป็นตัวเลือกสำหรับลงชื่อเข้าใช้โดยอัตโนมัติ 3. ผู้ใช้เดิมลงชื่อเข้าใช้ด้วยชื่อผู้ใช้และรหัสผ่าน -4. หลังจากลงชื่อเข้าใช้ขั้นแรก ผู้ใช้จะถูกขอให้กรอกและยืนยันที่อยู่อีเมล +4. หลังจากลงชื่อเข้าใช้ครั้งแรก ผู้ใช้จะถูกขอให้กรอกและยืนยันที่อยู่อีเมล ```mermaid flowchart TD @@ -97,10 +98,10 @@ flowchart TD C --> |ไม่| F ``` -กระบวนการเดียวกันนี้ใช้กับการตั้งค่า **สร้างรหัสผ่านของคุณ** ด้วย หากเปิดใช้งานการตั้งค่า **สร้างรหัสผ่านของคุณ** ในกระบวนการสมัครสมาชิก ปัจจัย **รหัสผ่าน** จะถูกเปิดใช้งานโดยอัตโนมัติสำหรับตัวระบุที่คุณเลือก ผู้ใช้เดิมที่ยังไม่มีรหัสผ่านจะถูกขอให้สร้างรหัสผ่านระหว่างกระบวนการลงชื่อเข้าใช้ +กระบวนการเดียวกันนี้ใช้กับการตั้งค่า **สร้างรหัสผ่านของคุณ** ด้วย หากมีการเปิดใช้งาน **สร้างรหัสผ่านของคุณ** ในกระบวนการสมัครสมาชิก ปัจจัย **รหัสผ่าน** จะถูกเปิดใช้งานโดยอัตโนมัติสำหรับตัวระบุที่คุณเลือก ผู้ใช้เดิมที่ยังไม่มีรหัสผ่านจะถูกขอให้สร้างรหัสผ่านระหว่างกระบวนการลงชื่อเข้าใช้ :::note -หมายเหตุ: สำหรับกระบวนการลงชื่อเข้าใช้แบบกำหนดเอง โปรดดูฟีเจอร์ [Bring your UI](/customization/bring-your-ui/) +หมายเหตุ: สำหรับกระบวนการลงชื่อเข้าใช้แบบกำหนดเอง ดูฟีเจอร์ [Bring your UI](/customization/bring-your-ui/) ::: ## คำถามที่พบบ่อย \{#faqs} @@ -112,7 +113,7 @@ flowchart TD -ขณะนี้ Logto ยังไม่รองรับ API แบบ headless สำหรับการลงชื่อเข้าใช้และสมัครสมาชิก อย่างไรก็ตาม คุณสามารถใช้ฟีเจอร์ [Bring your UI](/customization/bring-your-ui/) เพื่ออัปโหลดฟอร์มลงชื่อเข้าใช้ที่คุณออกแบบเองมายัง Logto ได้ เรายังรองรับพารามิเตอร์การลงชื่อเข้าใช้หลายแบบที่คุณสามารถใช้กรอกข้อมูลตัวระบุผู้ใช้ล่วงหน้าจากแอปของคุณ หรือเข้าสู่ระบบโดยตรงกับผู้ให้บริการโซเชียลหรือ SSO สำหรับองค์กรจากภายนอก ดูรายละเอียดเพิ่มเติมที่ [Authentication parameters](/end-user-flows/authentication-parameters/) +ขณะนี้ Logto ยังไม่รองรับ API แบบ headless สำหรับการลงชื่อเข้าใช้และสมัครสมาชิก อย่างไรก็ตาม คุณสามารถใช้ฟีเจอร์ [Bring your UI](/customization/bring-your-ui/) เพื่ออัปโหลดฟอร์มลงชื่อเข้าใช้ที่คุณออกแบบเองไปยัง Logto ได้ เรายังรองรับพารามิเตอร์การลงชื่อเข้าใช้หลายแบบที่คุณสามารถใช้เติมข้อมูลตัวระบุผู้ใช้ที่เก็บจากแอปของคุณล่วงหน้าหรือเข้าสู่ระบบโดยตรงกับผู้ให้บริการโซเชียลหรือ Enterprise SSO ของบุคคลที่สาม ดูรายละเอียดเพิ่มเติมที่ [Authentication parameters](/end-user-flows/authentication-parameters/) diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index cadad93e72d..6161875677d 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -4,7 +4,7 @@ sidebar_position: 1 # การสมัครด้วยอีเมล / เบอร์โทรศัพท์ / ชื่อผู้ใช้ -การลงทะเบียนผู้ใช้เป็นก้าวแรกที่ผู้ใช้จะมีปฏิสัมพันธ์กับแอปพลิเคชันของคุณ Logto รองรับวิธีการสมัครหลากหลายรูปแบบ เช่น การตั้งชื่อผู้ใช้และรหัสผ่าน การยืนยันอีเมลหรือเบอร์โทรศัพท์ [การสมัครด้วยโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in) และ [Enterprise SSO](/end-user-flows/enterprise-sso) คุณสามารถตั้งค่าวิธีการสมัครที่เหมาะสมกับความต้องการของแอปพลิเคชันของคุณได้ +การลงทะเบียนผู้ใช้เป็นขั้นตอนแรกที่ผู้ใช้จะมีส่วนร่วมกับแอปพลิเคชันของคุณ Logto รองรับวิธีการสมัครหลากหลายรูปแบบ เช่น การตั้งชื่อผู้ใช้และรหัสผ่าน การยืนยันอีเมลหรือเบอร์โทรศัพท์ [สมัครด้วยโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in) และ [Enterprise SSO](/end-user-flows/enterprise-sso) คุณสามารถตั้งค่าวิธีสมัครที่เหมาะสมกับความต้องการของแอปของคุณได้ ไปที่ Console > ประสบการณ์การลงชื่อเข้าใช้ > สมัครและลงชื่อเข้าใช้ เพื่อเริ่มตั้งค่ากระบวนการสมัครด้วยตัวระบุ @@ -12,32 +12,42 @@ sidebar_position: 1 ## ตั้งค่าตัวระบุสำหรับการสมัคร \{#set-up-the-sign-up-identifier} -เพื่อสร้างบัญชีผู้ใช้ใหม่ใน Logto ได้สำเร็จ ผู้ใช้ต้องระบุ **ตัวระบุ** อย่างน้อยหนึ่งรายการที่สามารถระบุตัวตนของตนเองได้อย่างไม่ซ้ำในระบบของ Logto ในขั้นตอนแรก ให้เลือกตัวระบุที่ผู้ใช้ต้องกรอกในกระบวนการสมัคร ตัวเลือกที่มี ได้แก่ +เพื่อสร้างบัญชีผู้ใช้ใหม่ใน Logto ได้สำเร็จ ผู้ใช้ต้องระบุ **ตัวระบุ** อย่างน้อยหนึ่งรายการที่สามารถระบุผู้ใช้นั้นได้อย่างไม่ซ้ำในระบบของ Logto ในขั้นตอนแรก ให้เลือกตัวระบุที่ผู้ใช้ต้องกรอกในกระบวนการสมัคร ตัวเลือกที่มี ได้แก่ -- **ชื่อผู้ใช้ (Username)**: [ชื่อผู้ใช้](/user-management/user-data#username) ที่ไม่ซ้ำกันซึ่งผู้ใช้สามารถใช้ลงชื่อเข้าใช้แอปพลิเคชัน -- **อีเมล (Email address)**: [อีเมล](/user-management/user-data#primary_email) ที่ถูกต้องซึ่งผู้ใช้สามารถใช้ลงชื่อเข้าใช้แอปพลิเคชัน -- **เบอร์โทรศัพท์ (Phone number)**: [เบอร์โทรศัพท์](/user-management/user-data#primary_phone) ที่ถูกต้องซึ่งผู้ใช้สามารถใช้ลงชื่อเข้าใช้แอปพลิเคชัน -- **อีเมลหรือเบอร์โทรศัพท์ (Email address or phone number)**: อนุญาตให้ผู้ใช้สมัครด้วยอีเมลหรือเบอร์โทรศัพท์ที่ถูกต้องอย่างใดอย่างหนึ่ง +- **ชื่อผู้ใช้**: [ชื่อผู้ใช้](/user-management/user-data#username) ที่ไม่ซ้ำกันซึ่งผู้ใช้สามารถใช้ลงชื่อเข้าใช้แอปพลิเคชัน +- **อีเมล**: [อีเมล](/user-management/user-data#primary_email) ที่ถูกต้องซึ่งผู้ใช้สามารถใช้ลงชื่อเข้าใช้แอปพลิเคชัน +- **เบอร์โทรศัพท์**: [เบอร์โทรศัพท์](/user-management/user-data#primary_phone) ที่ถูกต้องซึ่งผู้ใช้สามารถใช้ลงชื่อเข้าใช้แอปพลิเคชัน +- **อีเมลหรือเบอร์โทรศัพท์**: อนุญาตให้ผู้ใช้สมัครด้วยอีเมลหรือเบอร์โทรศัพท์ที่ถูกต้องอย่างใดอย่างหนึ่ง -ตัวระบุทั้งหมดที่เก็บในระหว่างการสมัครต้องไม่ซ้ำกันในกลุ่มผู้ใช้ภายใต้ tenant เดียวกัน ข้อมูลเหล่านี้จะถูกเก็บไว้ใน [โปรไฟล์ผู้ใช้](/user-management/user-data#user-profile) และสามารถใช้ลงชื่อเข้าใช้แอปพลิเคชันที่เชื่อมต่อกับ Logto ได้ +ตัวระบุทั้งหมดที่เก็บในระหว่างกระบวนการสมัครต้องไม่ซ้ำกันในผู้ใช้ภายใต้ tenant เดียวกัน ตัวระบุเหล่านี้จะถูกเก็บไว้ใน [โปรไฟล์ผู้ใช้](/user-management/user-data#user-profile) และสามารถใช้ลงชื่อเข้าใช้แอปที่เชื่อมต่อกับ Logto ได้ หากไม่ได้เลือกตัวระบุใดเลย จะใช้กับวิธีสมัครแบบ [โซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in) เท่านั้น หรือ [Enterprise SSO](/end-user-flows/enterprise-sso) เท่านั้น -คุณสามารถปรับลำดับของตัวระบุสำหรับการสมัครเพื่อกำหนดลำดับความสำคัญว่าต้องการให้ผู้ใช้กรอกตัวระบุใดก่อน ลำดับนี้จะสะท้อนในกระบวนการสมัคร โดยตัวระบุแรกจะปรากฏในหน้าลงทะเบียนแรก และตัวระบุที่เหลือจะถูกรวบรวมในขั้นตอนถัดไป +คุณสามารถปรับลำดับของตัวระบุสำหรับการสมัครเพื่อจัดลำดับความสำคัญว่าต้องการให้ผู้ใช้กรอกตัวระบุใดก่อน ลำดับนี้จะสะท้อนในกระบวนการสมัคร โดยตัวระบุแรกจะปรากฏในหน้าลงทะเบียนแรก และตัวระบุที่เหลือจะถูกรวบรวมในขั้นตอนถัดไป + +:::tip +หากต้องการบล็อกอีเมลบางประเภทในระหว่างการสมัคร (เช่น อีเมลชั่วคราว, อีเมลที่มีเครื่องหมายบวก (+), อีเมลหรือโดเมนเฉพาะ) ให้ใช้ฟีเจอร์ **blocklist** ในส่วน Security ดูรายละเอียดเพิ่มเติมที่ [Blocklist](/security/blocklist) +::: + +:::tip +รหัสประเทศของเบอร์โทรศัพท์ (**country code**) จะถูกตั้งค่าเริ่มต้นตาม locale ของเบราว์เซอร์ผู้ใช้ เช่น หากเบราว์เซอร์ของผู้ใช้ตั้งเป็น `fr` รหัสประเทศจะถูกตั้งเป็นฝรั่งเศส (+33) + +คุณยังสามารถใช้พารามิเตอร์การยืนยันตัวตน [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) เพื่อกำหนดภาษาของประสบการณ์การลงชื่อเข้าใช้ ซึ่งจะกำหนดรหัสประเทศเริ่มต้นด้วย +::: ## ตั้งค่าการยืนยันตัวตนสำหรับการสมัคร \{#set-up-the-sign-up-verification-settings} เพื่อความปลอดภัยของกระบวนการสมัครและการลงชื่อเข้าใช้ในอนาคต คุณต้องตั้งค่าการยืนยันตัวตนสำหรับตัวระบุที่เก็บในระหว่างการสมัครด้วย ตัวเลือกที่มี ได้แก่ -- **สร้างรหัสผ่านของคุณ:** กำหนดให้ผู้ใช้สร้างรหัสผ่านในระหว่างการสมัคร โดยต้องเป็นไปตามนโยบายรหัสผ่านที่ตั้งค่าไว้ในประสบการณ์การลงชื่อเข้าใช้ รหัสผ่านนี้พร้อมกับตัวระบุของผู้ใช้จะใช้เป็นข้อมูลรับรองสำหรับการลงชื่อเข้าใช้แอปพลิเคชัน หากคุณตั้งค่า **ชื่อผู้ใช้** เป็นตัวระบุสำหรับการสมัคร ข้อกำหนดนี้จะถูกเปิดใช้งานโดยอัตโนมัติ เนื่องจาก **ชื่อผู้ใช้** สามารถใช้ได้กับรหัสผ่านเท่านั้นเพื่อยืนยันตัวตนของผู้ใช้อย่างมีประสิทธิภาพ [นโยบายรหัสผ่าน](/security/password-policy) สามารถปรับแต่งให้เหมาะกับความต้องการด้านความปลอดภัยของคุณได้ -- **ยืนยันในขั้นตอนสมัคร (Verify at sign-up)**: กำหนดให้ผู้ใช้ยืนยันอีเมลหรือเบอร์โทรศัพท์ในระหว่างการสมัคร ปัจจุบัน Logto รองรับเฉพาะอีเมลและเบอร์โทรศัพท์ที่ได้รับการยืนยันแล้วเป็นตัวระบุเท่านั้น การตั้งค่านี้จะถูกเปิดใช้งานโดยอัตโนมัติเมื่อใช้ **อีเมล** หรือ **เบอร์โทรศัพท์** เป็นตัวระบุสำหรับการสมัคร ผู้ใช้ต้องยืนยันความเป็นเจ้าของโดยกรอกรหัสยืนยันที่ส่งไปยังอีเมลหรือเบอร์โทรศัพท์ในระหว่างการสมัคร +- **สร้างรหัสผ่านของคุณ:** บังคับให้ผู้ใช้สร้างรหัสผ่านในระหว่างการสมัคร โดยต้องเป็นไปตามนโยบายรหัสผ่านที่ตั้งค่าไว้ในประสบการณ์การลงชื่อเข้าใช้ รหัสผ่านนี้พร้อมกับตัวระบุของผู้ใช้จะใช้เป็นข้อมูลรับรองสำหรับการลงชื่อเข้าใช้แอป หากคุณตั้งค่า **ชื่อผู้ใช้** เป็นตัวระบุสำหรับการสมัคร ข้อนี้จะถูกเปิดใช้งานโดยอัตโนมัติ เพราะ **ชื่อผู้ใช้** สามารถใช้ได้กับรหัสผ่านเท่านั้นเพื่อยืนยันตัวตนของผู้ใช้อย่างมีประสิทธิภาพ [นโยบายรหัสผ่าน](/security/password-policy) สามารถปรับแต่งให้ตรงกับความต้องการด้านความปลอดภัยของคุณได้ +- **ยืนยันในระหว่างสมัคร**: บังคับให้ผู้ใช้ยืนยันอีเมลหรือเบอร์โทรศัพท์ในระหว่างการสมัคร ปัจจุบัน Logto รองรับเฉพาะอีเมลและเบอร์โทรศัพท์ที่ได้รับการยืนยันแล้วเท่านั้นเป็นตัวระบุ ข้อนี้จะถูกเปิดใช้งานโดยอัตโนมัติเมื่อใช้อีเมลหรือเบอร์โทรศัพท์เป็นตัวระบุสำหรับการสมัคร ผู้ใช้ต้องยืนยันความเป็นเจ้าของโดยกรอกรหัสยืนยันที่ส่งไปยังอีเมลหรือเบอร์โทรศัพท์ในระหว่างการสมัคร -| ตัวระบุ | สร้างรหัสผ่านผู้ใช้ | ยืนยันในขั้นตอนสมัคร | +| ตัวระบุ | สร้างรหัสผ่านผู้ใช้ | ยืนยันในระหว่างสมัคร | | ---------------------- | ------------------- | -------------------- | | ชื่อผู้ใช้ | เลือกได้ | N/A | -| อีเมล | เลือกได้ | จำเป็น | -| เบอร์โทรศัพท์ | เลือกได้ | จำเป็น | -| อีเมลหรือเบอร์โทรศัพท์ | เลือกได้ | จำเป็น | +| อีเมล | เลือกได้ | บังคับ | +| เบอร์โทรศัพท์ | เลือกได้ | บังคับ | +| อีเมลหรือเบอร์โทรศัพท์ | เลือกได้ | บังคับ | ## ตัวอย่างกระบวนการสมัคร \{#sign-up-flow-examples} @@ -48,7 +58,7 @@ sidebar_position: 1 -เลือก **ชื่อผู้ใช้** เป็นตัวระบุสำหรับการสมัคร ระบบจะเปิดใช้งานการสร้างรหัสผ่านโดยอัตโนมัติ +เลือก **ชื่อผู้ใช้** เป็นตัวระบุสำหรับการสมัคร “สร้างรหัสผ่านของคุณ” จะถูกเปิดใช้งานโดยอัตโนมัติ สมัครด้วยชื่อผู้ใช้และรหัสผ่าน @@ -61,11 +71,11 @@ sidebar_position: 1 -เลือก **อีเมลหรือเบอร์โทรศัพท์** เป็นตัวระบุสำหรับการสมัคร ระบบจะบังคับเปิดใช้งาน **ยืนยันในขั้นตอนสมัคร** +เลือก **อีเมลหรือเบอร์โทรศัพท์** เป็นตัวระบุสำหรับการสมัคร “ยืนยันในระหว่างสมัคร” จะถูกบังคับให้เปิดใช้งาน สมัครด้วยอีเมลหรือเบอร์โทรศัพท์พร้อมยืนยัน @@ -73,28 +83,31 @@ sidebar_position: 1
-### ประเภทที่ 3: อีเมลพร้อมยืนยันและสร้างรหัสผ่าน \{#type-3-email-address-with-verification-and-password-creation} +### ประเภทที่ 3: อีเมลพร้อมการยืนยันและสร้างรหัสผ่าน \{#type-3-email-address-with-verification-and-password-creation} -เลือก **อีเมล** เป็นตัวระบุสำหรับการสมัคร ระบบจะบังคับเปิดใช้งาน **ยืนยันในขั้นตอนสมัคร** เปิดใช้งาน **สร้างรหัสผ่านของคุณ** เพื่อกำหนดให้ผู้ใช้สร้างรหัสผ่านในระหว่างการสมัคร (ใช้กับการสมัครด้วยเบอร์โทรศัพท์เช่นกัน) +เลือก **อีเมล** เป็นตัวระบุสำหรับการสมัคร “ยืนยันในระหว่างสมัคร” จะถูกบังคับให้เปิดใช้งาน เปิดใช้งาน “สร้างรหัสผ่านของคุณ” เพื่อบังคับให้ผู้ใช้สร้างรหัสผ่านในระหว่างสมัคร (ใช้กับการสมัครด้วยเบอร์โทรศัพท์เช่นกัน) -สมัครด้วยอีเมลพร้อมยืนยันและสร้างรหัสผ่าน +สมัครด้วยอีเมลพร้อมการยืนยันและสร้างรหัสผ่าน
-### ประเภทที่ 4: อีเมลพร้อมยืนยัน ชื่อผู้ใช้ และสร้างรหัสผ่าน \{#type-4-email-address-with-verification-username-and-password-creation} +### ประเภทที่ 4: อีเมลพร้อมการยืนยัน ชื่อผู้ใช้ และสร้างรหัสผ่าน \{#type-4-email-address-with-verification-username-and-password-creation} -เลือก **อีเมล** และ **ชื่อผู้ใช้** เป็นตัวระบุสำหรับการสมัคร ระบบจะบังคับเปิดใช้งาน **ยืนยันในขั้นตอนสมัคร** เปิดใช้งาน **สร้างรหัสผ่านของคุณ** เพื่อกำหนดให้ผู้ใช้สร้างรหัสผ่านในระหว่างการสมัคร +เลือก **อีเมล** และ **ชื่อผู้ใช้** เป็นตัวระบุสำหรับการสมัคร “ยืนยันในระหว่างสมัคร” จะถูกบังคับให้เปิดใช้งาน เปิดใช้งาน “สร้างรหัสผ่านของคุณ” เพื่อบังคับให้ผู้ใช้สร้างรหัสผ่านในระหว่างสมัคร สมัครด้วยอีเมลและชื่อผู้ใช้พร้อมยืนยันและสร้างรหัสผ่าน
@@ -103,27 +116,27 @@ sidebar_position: 1 นอกจากวิธีการสมัครแบบตัวระบุแบบดั้งเดิมเหล่านี้แล้ว Logto ยังรองรับการสมัครแบบไม่ใช้รหัสผ่านด้วยผู้ให้บริการโซเชียลและ Enterprise SSO ทำให้กระบวนการ onboarding ราบรื่นและเป็นมิตรกับผู้ใช้มากขึ้น -เมื่อมีการตั้งค่าและเปิดใช้งาน [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors) หรือ [ตัวเชื่อมต่อ Enterprise SSO](/connectors/enterprise-connectors) ใน Logto แล้ว ผู้ใช้สามารถสมัครได้อย่างง่ายดายด้วยอัตลักษณ์โซเชียลหรือองค์กรที่มีอยู่ผ่านตัวเชื่อมต่อ วิธีการสมัครด้วยโซเชียลและ Enterprise SSO ช่วยให้ผู้ใช้ข้ามขั้นตอนเพิ่มเติม เช่น การสร้างรหัสผ่านหรือการยืนยันอีเมล / เบอร์โทรศัพท์ Logto จะซิงค์ข้อมูลผู้ใช้โดยอัตโนมัติผ่านอัตลักษณ์โซเชียลหรือองค์กรที่ได้รับการยืนยัน และจัดเก็บไว้ในโปรไฟล์ผู้ใช้ +เมื่อมีการตั้งค่าและเปิดใช้งาน [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors) หรือ [ตัวเชื่อมต่อ Enterprise SSO](/connectors/enterprise-connectors) ใน Logto ผู้ใช้สามารถสมัครได้อย่างง่ายดายโดยใช้ตัวตนโซเชียลหรือองค์กรที่มีอยู่แล้วผ่านตัวเชื่อมต่อ วิธีสมัครด้วยโซเชียลและ Enterprise SSO ช่วยให้ผู้ใช้ข้ามขั้นตอนเพิ่มเติม เช่น การสร้างรหัสผ่านหรือการยืนยันอีเมล / เบอร์โทรศัพท์ Logto จะซิงค์ข้อมูลผู้ใช้โดยอัตโนมัติผ่านตัวตนโซเชียลหรือองค์กรที่ได้รับการยืนยัน และเก็บไว้ในโปรไฟล์ผู้ใช้ -ดูรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการสมัครด้วยตัวเชื่อมต่อโซเชียลและ Enterprise SSO ได้ที่ [การลงชื่อเข้าใช้ด้วยโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in/) และ [Enterprise SSO](/end-user-flows/enterprise-sso/) +ดูรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการสมัครด้วยตัวเชื่อมต่อโซเชียลและ Enterprise SSO ได้ที่ [สมัครด้วยโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in/) และ [Enterprise SSO](/end-user-flows/enterprise-sso/) :::note หมายเหตุ: สำหรับกระบวนการสมัครแบบกำหนดเอง ดูฟีเจอร์ [Bring your UI](/customization/bring-your-ui/) ::: -## เก็บข้อมูลผู้ใช้เพิ่มเติมในขั้นตอนสมัคร \{#collect-additional-user-info-on-sign-up} +## เก็บข้อมูลผู้ใช้เพิ่มเติมในระหว่างสมัคร \{#collect-additional-user-info-on-sign-up} -หากต้องการเก็บข้อมูลโปรไฟล์ผู้ใช้เพิ่มเติม (เช่น ชื่อ-นามสกุล วันเกิด ชื่อบริษัท) ในระหว่างการสมัคร คุณมี 2 ทางเลือกที่ยืดหยุ่น: +หากต้องการเก็บข้อมูลโปรไฟล์ผู้ใช้เพิ่มเติม (เช่น ชื่อ-นามสกุล วันเกิด ชื่อบริษัท) ในระหว่างสมัคร คุณมี 2 ตัวเลือกที่ยืดหยุ่น: -**ทางเลือกที่ 1: เก็บโปรไฟล์ผู้ใช้** +**ตัวเลือกที่ 1: เก็บโปรไฟล์ผู้ใช้** -เพิ่มขั้นตอน "บอกเราเกี่ยวกับตัวคุณ" ที่สร้างไว้ล่วงหน้าของ Logto ลงในกระบวนการสมัครโดยตรง ผู้ใช้ต้องกรอกข้อมูลที่จำเป็นให้ครบถ้วนก่อนการลงทะเบียนจะเสร็จสมบูรณ์ วิธีนี้ไม่ต้องเขียนโค้ดและใช้งานได้ทันที +เพิ่มขั้นตอน “บอกเราเกี่ยวกับตัวคุณ” ที่สร้างไว้ล่วงหน้าของ Logto ลงในกระบวนการสมัครโดยตรง ผู้ใช้ต้องกรอกข้อมูลที่จำเป็นทั้งหมดก่อนการลงทะเบียนจะเสร็จสมบูรณ์ วิธีนี้ไม่ต้องเขียนโค้ดและใช้งานได้ทันที ตั้งค่าการเก็บโปรไฟล์ผ่าน Console > ประสบการณ์การลงชื่อเข้าใช้ > เก็บโปรไฟล์ผู้ใช้ เพื่อเลือกฟิลด์ข้อมูลพื้นฐานที่ตั้งค่าไว้ล่วงหน้าหรือสร้างฟิลด์เองพร้อมการตรวจสอบที่ยืดหยุ่น ดูเพิ่มเติม: [เก็บโปรไฟล์ผู้ใช้](/end-user-flows/collect-user-profile) -**ทางเลือกที่ 2: กระบวนการ onboarding แบบโฮสต์เอง** +**ตัวเลือกที่ 2: กระบวนการ onboarding แบบโฮสต์เอง** -เปลี่ยนเส้นทางผู้ใช้ไปยังกระบวนการ onboarding ที่คุณออกแบบเองหลังสมัครสำเร็จ เพื่อเก็บข้อมูลได้อย่างยืดหยุ่นเต็มที่ วิธีนี้ให้คุณควบคุมประสบการณ์ผู้ใช้และรองรับกระบวนการ onboarding หลายขั้นตอนที่ซับซ้อนได้ +เปลี่ยนเส้นทางผู้ใช้ไปยังกระบวนการ onboarding ที่คุณออกแบบเองหลังสมัครสำเร็จ เพื่อเก็บข้อมูลได้อย่างอิสระและปรับแต่งประสบการณ์ผู้ใช้ได้เต็มที่ รวมถึงรองรับกระบวนการ onboarding หลายขั้นตอนที่ซับซ้อน ใช้ [Account API](/end-user-flows/account-settings/by-account-api) เพื่อจัดการข้อมูลโปรไฟล์ผู้ใช้แบบโปรแกรม @@ -136,18 +149,18 @@ sidebar_position: 1 -เรียนรู้วิธีสร้าง [กระบวนการสมัครแบบเชิญเท่านั้น](/end-user-flows/sign-up-and-sign-in/disable-user-registration/#implement-an-invitation-only-sign-up-flow) +เรียนรู้วิธีสร้าง [กระบวนการสมัครเฉพาะผู้ได้รับเชิญ](/end-user-flows/sign-up-and-sign-in/disable-user-registration/#implement-an-invitation-only-sign-up-flow)
-### ฟอร์มสมัครฝังในเว็บไซต์ของคุณ \{#embedded-sign-up-forms-on-your-website} +### แบบฟอร์มสมัครฝังในเว็บไซต์ของคุณ \{#embedded-sign-up-forms-on-your-website} -ขณะนี้ Logto ยังไม่รองรับ Headless API สำหรับการลงชื่อเข้าใช้และสมัคร คุณสามารถใช้ฟีเจอร์ [Bring your UI](/customization/bring-your-ui/) เพื่ออัปโหลดฟอร์มสมัครของคุณเองไปยัง Logto หรือใช้พารามิเตอร์การลงชื่อเข้าใช้เพื่อส่งข้อมูลผู้ใช้จากเว็บไซต์ของคุณไปยัง Logto ดูรายละเอียดเกี่ยวกับการส่งข้อมูลตัวระบุผู้ใช้ได้ที่ [Authentication parameters](/end-user-flows/authentication-parameters/) +ขณะนี้ Logto ยังไม่รองรับ headless API สำหรับการลงชื่อเข้าใช้และสมัคร คุณสามารถใช้ฟีเจอร์ [Bring your UI](/customization/bring-your-ui/) เพื่ออัปโหลดฟอร์มสมัครของคุณเองไปยัง Logto หรือใช้พารามิเตอร์การลงชื่อเข้าเพื่อส่งข้อมูลผู้ใช้จากเว็บไซต์ของคุณไปยัง Logto ดูรายละเอียดเพิ่มเติมเกี่ยวกับการส่งตัวระบุผู้ใช้ที่ [Authentication parameters](/end-user-flows/authentication-parameters/)
@@ -158,19 +171,19 @@ sidebar_position: 1 -สมัครรับ event webhook `User.Created` เพื่อทริกเกอร์อีเมลต้อนรับผู้ใช้ใหม่ ดูเพิ่มเติมเกี่ยวกับ [Webhook events](/developers/webhooks/webhooks-events/#data-mutation-hook-events) +สมัครรับ event webhook `User.Created` เพื่อทริกเกอร์อีเมลต้อนรับผู้ใช้ใหม่ ดูรายละเอียดเกี่ยวกับ [webhook events](/developers/webhooks/webhooks-events/#data-mutation-hook-events)
-### ข้ามการยืนยันอีเมลในขั้นตอนสมัคร \{#skip-email-verification-on-sign-up} +### ข้ามการยืนยันอีเมลในระหว่างสมัคร \{#skip-email-verification-on-sign-up} -ขณะนี้ Logto รองรับเฉพาะอีเมลและเบอร์โทรศัพท์ที่ได้รับการยืนยันแล้วเป็นตัวระบุเท่านั้น กระบวนการยืนยันเป็นสิ่งจำเป็นเพื่อความปลอดภัยและความเป็นเจ้าของตัวระบุของผู้ใช้ -การรองรับอีเมลหรือเบอร์โทรศัพท์ที่ยังไม่ได้รับการยืนยันอยู่ใน [roadmap](https://feedback.logto.io/roadmap) ของเรา โปรดติดตามข่าวสาร! +ขณะนี้ Logto รองรับเฉพาะอีเมลและเบอร์โทรศัพท์ที่ได้รับการยืนยันแล้วเท่านั้นเป็นตัวระบุ กระบวนการยืนยันเป็นสิ่งจำเป็นเพื่อความปลอดภัยและความเป็นเจ้าของตัวระบุของผู้ใช้ +การรองรับอีเมลหรือเบอร์โทรศัพท์ที่ยังไม่ได้รับการยืนยันอยู่ใน [roadmap](https://feedback.logto.io/roadmap) ของเรา โปรดติดตามอัปเดต!
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 50ed1b29e99..760c5d9ccfd 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,5 +1,5 @@ --- -description: อ้างอิงพารามิเตอร์สำคัญของแอปพลิเคชันสำหรับการผสานรวมการยืนยันตัวตน OIDC รวมถึง redirect URIs, endpoints, โทเค็นรีเฟรช (refresh tokens), การออกจากระบบแบบ backchannel ฯลฯ +description: ดูข้อมูลคีย์พารามิเตอร์ของแอปพลิเคชันสำหรับการผสานรวมการยืนยันตัวตน OIDC รวมถึง redirect URIs, endpoints, โทเค็นรีเฟรช (refresh tokens), backchannel logout ฯลฯ sidebar_position: 6 --- @@ -7,11 +7,11 @@ sidebar_position: 6 ## บทนำ \{#introduction} -ใน Logto _แอปพลิเคชัน_ หมายถึงโปรแกรมซอฟต์แวร์หรือบริการเฉพาะที่ลงทะเบียนกับแพลตฟอร์ม Logto และได้รับการอนุญาต (Authorization) ให้เข้าถึงข้อมูลผู้ใช้หรือดำเนินการในนามของผู้ใช้ แอปพลิเคชันถูกใช้เพื่อระบุแหล่งที่มาของคำขอที่ส่งไปยัง Logto API รวมถึงจัดการกระบวนการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) สำหรับผู้ใช้ที่เข้าถึงแอปพลิเคชันเหล่านั้น +ใน Logto _แอปพลิเคชัน_ หมายถึงโปรแกรมซอฟต์แวร์หรือบริการเฉพาะที่ลงทะเบียนกับแพลตฟอร์ม Logto และได้รับการอนุญาต (Authorization) ให้เข้าถึงข้อมูลผู้ใช้หรือดำเนินการในนามของผู้ใช้ แอปพลิเคชันถูกใช้เพื่อระบุแหล่งที่มาของคำขอที่ส่งไปยัง Logto API รวมถึงจัดการกระบวนการการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) สำหรับผู้ใช้ที่เข้าถึงแอปพลิเคชันเหล่านั้น -การใช้แอปพลิเคชันในประสบการณ์การลงชื่อเข้าใช้ของ Logto ช่วยให้ผู้ใช้สามารถเข้าถึงและจัดการแอปพลิเคชันที่ได้รับอนุญาตของตนได้อย่างง่ายดายจากที่เดียว ด้วยกระบวนการยืนยันตัวตนที่สม่ำเสมอและปลอดภัย สิ่งนี้ช่วยให้ประสบการณ์ผู้ใช้ราบรื่นและมั่นใจได้ว่ามีเพียงบุคคลที่ได้รับอนุญาตเท่านั้นที่เข้าถึงข้อมูลสำคัญหรือดำเนินการในนามขององค์กร +การใช้แอปพลิเคชันในประสบการณ์การลงชื่อเข้าใช้ของ Logto ช่วยให้ผู้ใช้สามารถเข้าถึงและจัดการแอปพลิเคชันที่ได้รับอนุญาตของตนได้อย่างง่ายดายจากที่เดียว ด้วยกระบวนการยืนยันตัวตนที่สม่ำเสมอและปลอดภัย ช่วยให้ประสบการณ์ผู้ใช้ราบรื่นและมั่นใจได้ว่ามีเพียงบุคคลที่ได้รับอนุญาตเท่านั้นที่เข้าถึงข้อมูลสำคัญหรือดำเนินการในนามขององค์กร -แอปพลิเคชันยังถูกใช้ในบันทึกการตรวจสอบ (audit logs) ของ Logto เพื่อบันทึกกิจกรรมของผู้ใช้และระบุภัยคุกคามหรือการละเมิดความปลอดภัยที่อาจเกิดขึ้น โดยการเชื่อมโยงการกระทำเฉพาะกับแอปพลิเคชันแต่ละตัว Logto สามารถให้ข้อมูลเชิงลึกอย่างละเอียดเกี่ยวกับวิธีการเข้าถึงและใช้งานข้อมูล ช่วยให้องค์กรจัดการข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดได้ดียิ่งขึ้น +แอปพลิเคชันยังถูกใช้ในบันทึกการตรวจสอบ (audit logs) ของ Logto เพื่อติดตามกิจกรรมของผู้ใช้และระบุภัยคุกคามหรือการละเมิดความปลอดภัยที่อาจเกิดขึ้น ด้วยการเชื่อมโยงการกระทำเฉพาะกับแอปพลิเคชันแต่ละตัว Logto สามารถให้ข้อมูลเชิงลึกโดยละเอียดเกี่ยวกับวิธีการเข้าถึงและใช้งานข้อมูล ช่วยให้องค์กรจัดการความปลอดภัยและข้อกำหนดด้านการปฏิบัติตามได้ดียิ่งขึ้น หากคุณต้องการผสานรวมแอปพลิเคชันของคุณกับ Logto ดูที่ [ผสานรวม Logto](/integrate-logto) ## คุณสมบัติ \{#properties} @@ -33,28 +33,32 @@ _แอปพลิเคชัน_ สามารถเป็นประเ _Application secret_ คือคีย์ที่ใช้ในการยืนยันตัวตนของแอปพลิเคชันในระบบการยืนยันตัวตน โดยเฉพาะสำหรับ private clients (Traditional Web และ M2M apps) เพื่อเป็นกำแพงความปลอดภัยส่วนตัว +:::tip +Single Page Apps (SPAs) และ Native apps จะไม่มี App secret SPAs และ Native apps เป็น “public clients” และไม่สามารถเก็บความลับได้ (โค้ดเบราว์เซอร์หรือ app bundle สามารถถูกตรวจสอบได้) แทนที่จะใช้ app secret, Logto ปกป้องด้วย PKCE, การตรวจสอบ redirect URI / CORS อย่างเข้มงวด, โทเค็นการเข้าถึง (access tokens) อายุสั้น และการหมุนเวียนโทเค็นรีเฟรช (refresh-token rotation) +::: + ### Application name \{#application-name} -_Application name_ คือชื่อที่มนุษย์อ่านเข้าใจได้ของแอปพลิเคชันและจะแสดงในคอนโซลผู้ดูแลระบบ +_Application name_ คือชื่อที่มนุษย์อ่านเข้าใจได้ของแอปพลิเคชัน และจะแสดงในคอนโซลผู้ดูแลระบบ _Application name_ เป็นองค์ประกอบสำคัญในการจัดการแอปพลิเคชันใน Logto เพราะช่วยให้ผู้ดูแลระบบสามารถระบุและติดตามกิจกรรมของแต่ละแอปพลิเคชันในแพลตฟอร์มได้อย่างง่ายดาย :::note -ควรเลือก _Application name_ อย่างระมัดระวัง เนื่องจากจะแสดงให้ผู้ใช้ทุกคนที่เข้าถึงคอนโซลผู้ดูแลระบบเห็น ควรสะท้อนวัตถุประสงค์และหน้าที่ของแอปพลิเคชันอย่างถูกต้อง และเข้าใจง่าย +ควรเลือก _Application name_ อย่างระมัดระวัง เพราะจะแสดงให้ผู้ใช้ทุกคนที่เข้าถึงคอนโซลผู้ดูแลระบบเห็น ควรสะท้อนวัตถุประสงค์และหน้าที่ของแอปพลิเคชันอย่างถูกต้อง และควรเข้าใจง่ายและจดจำได้ ::: ### คำอธิบาย \{#description} -คำอธิบายสั้น ๆ ของแอปพลิเคชันจะแสดงในหน้ารายละเอียดแอปพลิเคชันของคอนโซลผู้ดูแลระบบ คำอธิบายนี้มีไว้เพื่อให้ข้อมูลเพิ่มเติมแก่ผู้ดูแลระบบ เช่น วัตถุประสงค์ ฟังก์ชันการทำงาน และรายละเอียดที่เกี่ยวข้องอื่น ๆ +คำอธิบายสั้น ๆ ของแอปพลิเคชันจะแสดงในหน้ารายละเอียดแอปพลิเคชันของคอนโซลผู้ดูแลระบบ คำอธิบายนี้มีไว้เพื่อให้ข้อมูลเพิ่มเติมแก่ผู้ดูแลระบบเกี่ยวกับแอปพลิเคชัน เช่น วัตถุประสงค์ ฟังก์ชันการทำงาน และรายละเอียดอื่น ๆ ที่เกี่ยวข้อง ### Redirect URIs \{#redirect-uris} _Redirect URIs_ คือรายการของ redirect URIs ที่ถูกต้องซึ่งถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชัน เมื่อผู้ใช้ลงชื่อเข้าใช้ Logto และพยายามเข้าถึงแอปพลิเคชัน จะถูกเปลี่ยนเส้นทางไปยัง URI ที่อนุญาตซึ่งระบุไว้ในการตั้งค่าแอปพลิเคชัน -รายการ URIs ที่อนุญาตนี้ใช้เพื่อตรวจสอบ redirect URI ที่รวมอยู่ในคำขอการอนุญาตที่แอปพลิเคชันส่งไปยัง Logto ระหว่างกระบวนการยืนยันตัวตน หาก redirect URI ที่ระบุในคำขอการอนุญาตตรงกับ URI ที่อนุญาตในแอปพลิเคชัน ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง URI นั้นหลังจากยืนยันตัวตนสำเร็จ หาก redirect URI ไม่อยู่ในรายการที่อนุญาต ผู้ใช้จะไม่ถูกเปลี่ยนเส้นทางและกระบวนการยืนยันตัวตนจะล้มเหลว +รายการ URI ที่อนุญาตนี้ใช้เพื่อตรวจสอบ redirect URI ที่รวมอยู่ในคำขอการอนุญาต (authorization request) ที่แอปพลิเคชันส่งไปยัง Logto ระหว่างกระบวนการยืนยันตัวตน หาก redirect URI ที่ระบุในคำขอการอนุญาตตรงกับ URI ที่อนุญาตในตั้งค่าแอปพลิเคชัน ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง URI นั้นหลังจากยืนยันตัวตนสำเร็จ หาก redirect URI ไม่อยู่ในรายการที่อนุญาต ผู้ใช้จะไม่ถูกเปลี่ยนเส้นทางและกระบวนการยืนยันตัวตนจะล้มเหลว :::note -ควรตรวจสอบให้แน่ใจว่าได้เพิ่ม redirect URIs ที่ถูกต้องทั้งหมดลงในรายการที่อนุญาตสำหรับแอปพลิเคชันใน Logto เพื่อให้ผู้ใช้สามารถเข้าถึงแอปพลิเคชันได้สำเร็จหลังจากยืนยันตัวตน +ควรตรวจสอบให้แน่ใจว่าได้เพิ่ม redirect URIs ที่ถูกต้องทั้งหมดลงในรายการที่อนุญาตของแอปพลิเคชันใน Logto เพื่อให้ผู้ใช้สามารถเข้าถึงแอปพลิเคชันได้สำเร็จหลังจากยืนยันตัวตน ::: คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) @@ -65,22 +69,22 @@ _Redirect URIs_ คือรายการของ redirect URIs ที่ถ ### Post sign-out redirect URIs \{#post-sign-out-redirect-uris} -_Post sign-out redirect URIs_ คือรายการของ URIs ที่ถูกต้องซึ่งถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชันเพื่อเปลี่ยนเส้นทางผู้ใช้หลังจากออกจากระบบ Logto +_Post sign-out redirect URIs_ คือรายการ URI ที่ถูกต้องซึ่งถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชันเพื่อเปลี่ยนเส้นทางผู้ใช้หลังจากที่ออกจากระบบ Logto แล้ว -การใช้ Allowed _Post Sign-out Redirect URIs_ สำหรับ Logout เป็นส่วนหนึ่งของข้อกำหนด RP-Initiated (Relying Party Initiated) Logout ใน OIDC ข้อกำหนดนี้ให้วิธีมาตรฐานสำหรับแอปพลิเคชันในการเริ่มต้นคำขอออกจากระบบสำหรับผู้ใช้ ซึ่งรวมถึงการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่กำหนดไว้ล่วงหน้าหลังจากออกจากระบบ +การใช้ Allowed _Post Sign-out Redirect URIs_ สำหรับ Logout เป็นส่วนหนึ่งของข้อกำหนด RP-Initiated (Relying Party Initiated) Logout ใน OIDC ข้อกำหนดนี้ให้วิธีมาตรฐานสำหรับแอปพลิเคชันในการเริ่มคำขอออกจากระบบสำหรับผู้ใช้ ซึ่งรวมถึงการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่กำหนดไว้ล่วงหน้าหลังจากออกจากระบบ -เมื่อผู้ใช้ออกจากระบบ Logto เซสชันของพวกเขาจะสิ้นสุดและจะถูกเปลี่ยนเส้นทางไปยัง URI ที่อนุญาตซึ่งระบุไว้ในการตั้งค่าแอปพลิเคชัน สิ่งนี้ช่วยให้มั่นใจว่าผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง endpoint ที่ได้รับอนุญาตและถูกต้องเท่านั้นหลังจากออกจากระบบ ช่วยป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตและความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่ไม่รู้จักหรือไม่ได้รับการยืนยัน +เมื่อผู้ใช้ออกจากระบบ Logto เซสชันของพวกเขาจะสิ้นสุดลงและจะถูกเปลี่ยนเส้นทางไปยัง URI ที่อนุญาตซึ่งระบุไว้ในการตั้งค่าแอปพลิเคชัน เพื่อให้แน่ใจว่าผู้ใช้จะถูกนำทางไปยัง endpoint ที่ได้รับอนุญาตและถูกต้องเท่านั้นหลังจากออกจากระบบ ช่วยป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตและความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่ไม่รู้จักหรือไม่ได้รับการตรวจสอบ คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) ### CORS allowed origins \{#cors-allowed-origins} -_CORS (Cross-origin resource sharing) allowed origins_ คือรายการของ origin ที่อนุญาตให้แอปพลิเคชันสามารถส่งคำขอไปยังบริการ Logto ได้ Origin ที่ไม่ได้อยู่ในรายการที่อนุญาตจะไม่สามารถส่งคำขอไปยังบริการ Logto ได้ +_CORS (Cross-origin resource sharing) allowed origins_ คือรายการของ origin ที่ได้รับอนุญาตให้แอปพลิเคชันสามารถส่งคำขอไปยังบริการ Logto ได้ Origin ที่ไม่ได้อยู่ในรายการที่อนุญาตจะไม่สามารถส่งคำขอไปยังบริการ Logto ได้ -รายการ CORS allowed origins ใช้เพื่อจำกัดการเข้าถึงบริการ Logto จากโดเมนที่ไม่ได้รับอนุญาต และช่วยป้องกันการโจมตีแบบ cross-site request forgery (CSRF) โดยการระบุ origin ที่อนุญาตสำหรับแอปพลิเคชันใน Logto บริการจะมั่นใจได้ว่าเฉพาะโดเมนที่ได้รับอนุญาตเท่านั้นที่สามารถส่งคำขอไปยังบริการได้ +รายการ CORS allowed origins นี้ใช้เพื่อจำกัดการเข้าถึงบริการ Logto จากโดเมนที่ไม่ได้รับอนุญาต และช่วยป้องกันการโจมตีแบบ cross-site request forgery (CSRF) ด้วยการระบุ origin ที่อนุญาตสำหรับแอปพลิเคชันใน Logto บริการจะมั่นใจได้ว่าเฉพาะโดเมนที่ได้รับอนุญาตเท่านั้นที่สามารถส่งคำขอไปยังบริการได้ :::note -รายการ origin ที่อนุญาตควรประกอบด้วย origin ที่แอปพลิเคชันจะถูกให้บริการ เพื่อให้แน่ใจว่าคำขอจากแอปพลิเคชันได้รับอนุญาต ในขณะที่คำขอจาก origin ที่ไม่ได้รับอนุญาตจะถูกบล็อก +รายการ allowed origins ควรมี origin ที่แอปพลิเคชันจะถูกให้บริการ เพื่อให้แน่ใจว่าคำขอจากแอปพลิเคชันจะได้รับอนุญาต ในขณะที่คำขอจาก origin ที่ไม่ได้รับอนุญาตจะถูกบล็อก ::: ### OpenID provider configuration endpoint \{#openid-provider-configuration-endpoint} @@ -89,15 +93,15 @@ Endpoint สำหรับ [OpenID Connect Discovery](https://openid.net/specs/ ### Authorization endpoint \{#authorization-endpoint} -_Authorization Endpoint_ เป็นคำศัพท์ของ OIDC และเป็น endpoint ที่จำเป็นสำหรับเริ่มต้นกระบวนการยืนยันตัวตนของผู้ใช้ เมื่อผู้ใช้พยายามเข้าถึงทรัพยากรหรือแอปพลิเคชันที่ได้รับการลงทะเบียนกับแพลตฟอร์ม Logto พวกเขาจะถูกเปลี่ยนเส้นทางไปยัง _Authorization Endpoint_ เพื่อยืนยันตัวตนและขออนุญาตเข้าถึงทรัพยากรที่ร้องขอ +_Authorization Endpoint_ เป็นคำศัพท์ของ OIDC และเป็น endpoint ที่จำเป็นสำหรับเริ่มกระบวนการยืนยันตัวตนของผู้ใช้ เมื่อผู้ใช้พยายามเข้าถึงทรัพยากรหรือแอปพลิเคชันที่ได้รับการลงทะเบียนกับแพลตฟอร์ม Logto จะถูกเปลี่ยนเส้นทางไปยัง _Authorization Endpoint_ เพื่อยืนยันตัวตนและขออนุญาตเข้าถึงทรัพยากรที่ร้องขอ คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) ### Token endpoint \{#token-endpoint} -_Token Endpoint_ เป็นคำศัพท์ของ OIDC เป็น endpoint ของเว็บ API ที่ใช้โดย OIDC client เพื่อขอรับโทเค็นการเข้าถึง (Access token), โทเค็น ID (ID token) หรือโทเค็นรีเฟรช (Refresh token) จาก OIDC provider +_Token Endpoint_ เป็นคำศัพท์ของ OIDC เป็น endpoint ของเว็บ API ที่ใช้โดย OIDC client เพื่อขอโทเค็นการเข้าถึง (access token), โทเค็น ID (ID token) หรือโทเค็นรีเฟรช (refresh token) จาก OIDC provider -เมื่อ OIDC client ต้องการขอรับ access token หรือ ID token จะส่งคำขอไปยัง Token Endpoint พร้อม authorization grant ซึ่งโดยปกติจะเป็น authorization code หรือ refresh token จากนั้น Token Endpoint จะตรวจสอบความถูกต้องของ authorization grant และออก access token หรือ ID token ให้ client หาก grant ถูกต้อง +เมื่อ OIDC client ต้องการขอโทเค็นการเข้าถึงหรือโทเค็น ID จะส่งคำขอไปยัง Token Endpoint พร้อม authorization grant ซึ่งโดยทั่วไปคือ authorization code หรือโทเค็นรีเฟรช (refresh token) Token Endpoint จะตรวจสอบความถูกต้องของ authorization grant และออกโทเค็นการเข้าถึงหรือโทเค็น ID ให้ client หาก grant ถูกต้อง คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) @@ -111,7 +115,7 @@ _การใช้งาน: Traditional web, SPA_ เมื่อเปิดใช้งาน Logto จะออกโทเค็นรีเฟรช (refresh tokens) เสมอ ไม่ว่าจะมี `prompt=consent` ในคำขอการยืนยันตัวตนหรือไม่ หรือมี `offline_access` ในขอบเขต (scopes) หรือไม่ก็ตาม -อย่างไรก็ตาม ไม่แนะนำให้ใช้แนวทางนี้เว้นแต่จำเป็น (โดยปกติจะใช้สำหรับการผสานรวม OAuth ของบุคคลที่สามบางรายที่ต้องการ refresh token) เนื่องจากไม่สอดคล้องกับ OpenID Connect และอาจทำให้เกิดปัญหาได้ +อย่างไรก็ตาม ไม่แนะนำให้ใช้แนวทางนี้หากไม่จำเป็น (โดยปกติจะใช้สำหรับการผสานรวม OAuth ของบุคคลที่สามบางรายที่ต้องการ refresh token) เพราะไม่สอดคล้องกับ OpenID Connect และอาจทำให้เกิดปัญหาได้ ### Rotate refresh token \{#rotate-refresh-token} @@ -119,33 +123,33 @@ _ค่าเริ่มต้น: `true`_ เมื่อเปิดใช้งาน Logto จะออกโทเค็นรีเฟรชใหม่สำหรับคำขอโทเค็นภายใต้เงื่อนไขต่อไปนี้: -- หากโทเค็นรีเฟรชถูกหมุน (มีการขยาย TTL โดยออกโทเค็นใหม่) เป็นเวลาหนึ่งปี; **หรือ** +- หากโทเค็นรีเฟรชถูกหมุนเวียน (TTL ถูกขยายโดยการออกโทเค็นใหม่) เป็นเวลาหนึ่งปี; **หรือ** - หากโทเค็นรีเฟรชใกล้หมดอายุ (>=70% ของ TTL เดิมผ่านไปแล้ว); **หรือ** - หาก client เป็น public client เช่น Native application หรือ single page application (SPA) :::note -สำหรับ public clients เมื่อเปิดใช้งานฟีเจอร์นี้ จะมีการออกโทเค็นรีเฟรชใหม่เสมอเมื่อ client แลกเปลี่ยนเพื่อขอ access token ใหม่โดยใช้ refresh token +สำหรับ public clients เมื่อเปิดใช้งานฟีเจอร์นี้ จะมีการออกโทเค็นรีเฟรชใหม่เสมอเมื่อ client แลกเปลี่ยนเพื่อขอโทเค็นการเข้าถึงใหม่โดยใช้ refresh token แม้ว่าคุณจะสามารถปิดฟีเจอร์นี้สำหรับ public clients ได้ แต่ขอแนะนำอย่างยิ่งให้เปิดใช้งานเพื่อเหตุผลด้านความปลอดภัย ::: - ทำความเข้าใจการหมุนเวียน refresh token + ทำความเข้าใจการหมุนเวียนโทเค็นรีเฟรช (refresh token rotation) -### Refresh token time-to-live (TTL) เป็นวัน \{#refresh-token-time-to-live-ttl-in-days} +### อายุการใช้งาน (TTL) ของ refresh token (วัน) \{#refresh-token-time-to-live-ttl-in-days} _การใช้งาน: ไม่ใช่ SPA; ค่าเริ่มต้น: 14 วัน_ -ระยะเวลาที่โทเค็นรีเฟรชสามารถใช้ขอ access token ใหม่ได้ก่อนที่จะหมดอายุและกลายเป็นโมฆะ คำขอโทเค็นจะขยาย TTL ของ refresh token เป็นค่านี้ +ระยะเวลาที่ refresh token สามารถใช้ขอโทเค็นการเข้าถึงใหม่ก่อนที่จะหมดอายุและกลายเป็นโมฆะ คำขอโทเค็นจะขยาย TTL ของ refresh token เป็นค่านี้ -โดยทั่วไป ค่าที่ต่ำกว่าจะดีกว่า +โดยทั่วไป ค่าที่ต่ำกว่าจะปลอดภัยกว่า -หมายเหตุ: การขยาย TTL ของ refresh token ไม่สามารถใช้ได้ใน SPA (single page app) ด้วยเหตุผลด้านความปลอดภัย ซึ่งหมายความว่า Logto จะไม่ขยาย TTL ผ่านคำขอโทเค็น เพื่อประสบการณ์ผู้ใช้ที่ดีขึ้น คุณสามารถเปิดใช้งานฟีเจอร์ "Rotate refresh token" เพื่อให้ Logto ออก refresh token ใหม่เมื่อจำเป็น +หมายเหตุ: การต่ออายุ TTL ของ refresh token จะไม่สามารถใช้ได้ใน SPA (single page app) ด้วยเหตุผลด้านความปลอดภัย หมายความว่า Logto จะไม่ขยาย TTL ผ่านคำขอโทเค็น เพื่อประสบการณ์ผู้ใช้ที่ดีขึ้น คุณสามารถเปิดใช้งานฟีเจอร์ “Rotate refresh token” เพื่อให้ Logto ออก refresh token ใหม่เมื่อจำเป็น ### Backchannel logout URI \{#backchannel-logout-uri} -Endpoint สำหรับ OpenID Connect backchannel logout ดู [Federated sign-out: Back-channel logout](#) สำหรับข้อมูลเพิ่มเติม +Endpoint backchannel logout ของ OpenID Connect ดู [Federated sign-out: Back-channel logout](#) สำหรับข้อมูลเพิ่มเติม ### ข้อมูลกำหนดเอง \{#custom-data} -ข้อมูลแอปพลิเคชันเพิ่มเติมที่ไม่ได้อยู่ในคุณสมบัติที่กำหนดไว้ล่วงหน้า ผู้ใช้สามารถกำหนดฟิลด์ข้อมูลกำหนดเองตามความต้องการเฉพาะ เช่น การตั้งค่าและคอนฟิกธุรกิจเฉพาะ +ข้อมูลเพิ่มเติมของแอปพลิเคชันที่ไม่ได้อยู่ในคุณสมบัติที่กำหนดไว้ล่วงหน้า ผู้ใช้สามารถกำหนดฟิลด์ข้อมูลกำหนดเองตามความต้องการเฉพาะ เช่น การตั้งค่าและการกำหนดค่าทางธุรกิจ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index 3046bfa85ae..58e13b6525c 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -1,30 +1,45 @@ --- -description: ผสานรวมการยืนยันตัวตนของแอปพลิเคชันและการรวมตัวตนแบบ Federation ได้ในไม่กี่นาทีด้วยคู่มือเริ่มต้นอย่างรวดเร็วของเรา +description: ผสานรวมการยืนยันตัวตนของแอปพลิเคชันและการรวมตัวตน (identity federation) ได้ในไม่กี่นาทีด้วยคู่มือเริ่มต้นอย่างรวดเร็วของเรา sidebar_position: 1 --- # ผสานรวม Logto เข้ากับแอปพลิเคชันของคุณ -ทำตามขั้นตอนเหล่านี้เพื่อเพิ่มการยืนยันตัวตนให้กับแอปพลิเคชันของคุณด้วย Logto ไม่ว่าจะเป็นแอปสำหรับผู้ใช้หรือบริการแบบเครื่องต่อเครื่อง: +ทำตามขั้นตอนเหล่านี้เพื่อเพิ่มการยืนยันตัวตนให้กับแอปพลิเคชันของคุณด้วย Logto ไม่ว่าจะเป็นแอปสำหรับผู้ใช้หรือบริการเครื่องต่อเครื่อง (machine-to-machine): 1. ไปที่ Console > Applications 2. คลิก "Create application" เพื่อเพิ่มแอปพลิเคชันใหม่ -3. เลือก [เฟรมเวิร์กของแอปพลิเคชัน](/quick-starts) ของคุณเพื่อเริ่มต้น หากไม่พบเฟรมเวิร์กของคุณ ให้คลิกปุ่ม "Create app without framework" ที่มุมขวาล่างของหน้าสร้างแอปพลิเคชันเพื่อสร้างแอปโดยเลือก [ประเภทแอปพลิเคชัน](/integrate-logto/application-data-structure/#application-types) หรือส่งคำขอฟีเจอร์หรือร่วมพัฒนา SDK ตาม [แนวทาง SDK ของเรา](/developers/sdk-conventions) +3. เลือก [เฟรมเวิร์กแอปพลิเคชัน](/quick-starts) ของคุณเพื่อเริ่มต้น หากไม่พบเฟรมเวิร์กของคุณ ให้คลิกปุ่ม "Create app without framework" ที่มุมขวาล่างของหน้าสร้างแอปพลิเคชันเพื่อสร้างแอปโดยเลือก [ประเภทแอปพลิเคชัน](/integrate-logto/application-data-structure/#application-types) หรือส่งคำขอฟีเจอร์หรือร่วมพัฒนา SDK ตาม [แนวทาง SDK ของเรา](/developers/sdk-conventions) -4. หลังจากเลือกเฟรมเวิร์กแล้ว คุณจะเห็นคู่มือเริ่มต้นอย่างรวดเร็วสำหรับ SDK ของเฟรมเวิร์กนั้น ให้ทำตามขั้นตอนเพื่อกำหนดค่าและผสานรวมแอปพลิเคชันของคุณ หากต้องการความเข้าใจเกี่ยวกับแนวคิดที่เกี่ยวข้องกับกระบวนการผสานรวม สามารถดูได้ที่ [ทำความเข้าใจโฟลว์การยืนยันตัวตนของ Logto](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) เพื่อเข้าใจเชิงลึกยิ่งขึ้น +4. หลังจากเลือกเฟรมเวิร์กแล้ว คุณจะเห็นคู่มือเริ่มต้นอย่างรวดเร็วสำหรับ SDK ของเฟรมเวิร์กนั้น ให้ทำตามขั้นตอนเพื่อกำหนดค่าและผสานรวมแอปพลิเคชันของคุณ หากต้องการความเข้าใจเกี่ยวกับแนวคิดที่เกี่ยวข้องกับกระบวนการผสานรวม สามารถดูได้ที่ [ทำความเข้าใจ flow การยืนยันตัวตนของ Logto](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) เพื่อเข้าใจเชิงลึกเกี่ยวกับการผสานรวม :::note -คู่มือในคอนโซลนี้เหมาะสำหรับเริ่มต้นอย่างรวดเร็วกับ Logto โดยใช้ SDK ของเราเท่านั้น สำหรับคู่มือการผสานรวมแบบสมบูรณ์ รวมถึงการใช้งาน SDK ขั้นสูง โปรดดูที่ส่วน [Quick starts](/quick-starts) +คู่มือใน console นี้เหมาะสำหรับเริ่มต้นอย่างรวดเร็วกับ Logto โดยใช้ SDK ของเราเท่านั้น สำหรับคู่มือการผสานรวมแบบสมบูรณ์ รวมถึงการใช้งาน SDK ขั้นสูง โปรดดูที่ส่วน [Quick starts](/quick-starts) ::: -5. เมื่อเสร็จสิ้นแล้ว คุณพร้อมที่จะสำรวจเพิ่มเติมเกี่ยวกับ Logto: +5. เมื่อเสร็จสิ้นแล้ว คุณก็พร้อมที่จะสำรวจเพิ่มเติมเกี่ยวกับ Logto: - โฟลว์สำหรับผู้ใช้ปลายทาง + ประสบการณ์ (Experience) ของผู้ใช้ปลายทาง การอนุญาต (Authorization) องค์กร (Organizations) +## คำถามที่พบบ่อย \{#faqs} + +
+ + ### บริการ backend ของฉันจะตรวจสอบโทเค็นผู้ใช้และจัดการผู้ใช้กับ Logto ได้อย่างไร? + +เพื่อยืนยันความถูกต้องของโทเค็นการเข้าถึง (access tokens) ใน API backend ของคุณ (เช่น Python, Node.js, Go, Java, PHP ฯลฯ) และเพื่อจัดการผู้ใช้แบบโปรแกรม โปรดดูคู่มือ: [วิธีตรวจสอบโทเค็นการเข้าถึงในบริการ API หรือ backend ของคุณ](/authorization/validate-access-tokens) + +เอกสารนี้ครอบคลุม: + +- วิธีตรวจสอบความถูกต้องของ bearer token ในทุกการเรียก API +- แนวปฏิบัติที่ดีที่สุดสำหรับการผสาน Logto กับแอป frontend หลายตัวและบริการ backend + +
+ ## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} @@ -36,7 +51,7 @@ sidebar_position: 1 - ทำไมเราต้องแยกประเภทแอปต่าง ๆ เหล่านี้เมื่อใช้ Logto? + ทำไมเราต้องแยกประเภทแอปเหล่านี้เมื่อใช้ Logto? diff --git a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 4a23b06ed41..c87849c7e7a 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -12,18 +12,18 @@ import CustomizationIcon from '@site/src/assets/customization.svg'; ผู้ให้บริการข้อมูลระบุตัวตน (IdP) คือบริการที่ตรวจสอบตัวตนของผู้ใช้และจัดการข้อมูลรับรองการเข้าสู่ระบบของพวกเขา หลังจากยืนยันตัวตนของผู้ใช้แล้ว IdP จะสร้างโทเค็นการยืนยันตัวตนหรือ assertion และอนุญาตให้ผู้ใช้เข้าถึงแอปพลิเคชันหรือบริการต่าง ๆ ได้โดยไม่ต้องเข้าสู่ระบบซ้ำอีก -แตกต่างจากแอปพลิเคชันที่คุณสร้างในคู่มือ [ผสานรวม Logto เข้ากับแอปพลิเคชันของคุณ](/integrate-logto/integrate-logto-into-your-application) ซึ่งคุณเป็นผู้พัฒนาและควบคุมโดยสมบูรณ์ แอปพลิเคชันบุคคลที่สามเป็นบริการอิสระที่พัฒนาโดยนักพัฒนาภายนอกหรือพันธมิตรทางธุรกิจ +แตกต่างจากแอปพลิเคชันที่คุณสร้างในคู่มือ [ผสานรวม Logto เข้ากับแอปพลิเคชันของคุณ](/integrate-logto/integrate-logto-into-your-application) ซึ่งพัฒนาและควบคุมโดยคุณเอง แอปพลิเคชันบุคคลที่สามเป็นบริการอิสระที่พัฒนาโดยนักพัฒนาภายนอกหรือพันธมิตรทางธุรกิจ แนวทางการผสานรวมนี้เหมาะกับสถานการณ์ทางธุรกิจทั่วไป คุณสามารถเปิดให้ผู้ใช้เข้าถึงแอปพันธมิตรโดยใช้บัญชี Logto ของตนเอง เช่นเดียวกับที่ผู้ใช้ระดับองค์กรลงชื่อเข้าใช้ Slack ด้วย Google Workspace หรือคุณสามารถสร้างแพลตฟอร์มเปิดที่แอปพลิเคชันบุคคลที่สามสามารถเพิ่มฟีเจอร์ “ลงชื่อเข้าใช้ด้วย Logto” ได้ เช่นเดียวกับ “ลงชื่อเข้าใช้ด้วย Google” -Logto เป็นบริการข้อมูลระบุตัวตนที่สร้างขึ้นบนโปรโตคอล [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) ซึ่งให้ทั้ง [การยืนยันตัวตน (Authentication)](https://auth.wiki/authentication) และ [การอนุญาต (Authorization)](https://auth.wiki/authorization) การผสานรวมแอป OIDC บุคคลที่สามจึงง่ายเหมือนกับแอปเว็บทั่วไป +Logto เป็นบริการข้อมูลระบุตัวตนที่สร้างขึ้นบนโปรโตคอล [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) ซึ่งให้ทั้ง [การยืนยันตัวตน (Authentication)](https://auth.wiki/authentication) และ [การอนุญาต (Authorization)](https://auth.wiki/authorization) ทำให้การผสานรวมแอป OIDC บุคคลที่สามเป็นเรื่องง่ายเหมือนกับแอปเว็บแบบดั้งเดิม -เนื่องจาก OIDC สร้างขึ้นบน [OAuth 2.0](https://auth.wiki/oauth-2.0) โดยเพิ่มชั้นการยืนยันตัวตน คุณจึงสามารถผสานรวมแอปบุคคลที่สามด้วยโปรโตคอล OAuth ได้เช่นกัน +เนื่องจาก OIDC สร้างขึ้นบน [OAuth 2.0](https://auth.wiki/oauth-2.0) โดยเพิ่มชั้นการยืนยันตัวตน คุณจึงสามารถผสานรวมแอปบุคคลที่สามโดยใช้โปรโตคอล OAuth ได้เช่นกัน ## สร้างแอปพลิเคชันบุคคลที่สามใน Logto \{#create-an-third-party-application-in-logto} 1. ไปที่ Console > Applications -2. เลือก "Third-party app" เป็นประเภทแอปพลิเคชันและเลือกหนึ่งในโปรโตคอลการผสานรวมต่อไปนี้: +2. คลิกปุ่ม "Create application" เลือก "Third-party app" เป็นประเภทแอปพลิเคชัน และเลือกหนึ่งในโปรโตคอลการผสานรวมต่อไปนี้: - OIDC / OAuth 3. กรอกชื่อและคำอธิบายสำหรับแอปพลิเคชันของคุณ แล้วคลิกปุ่ม “Create” จะมีการสร้างแอปพลิเคชันบุคคลที่สามใหม่ @@ -36,21 +36,21 @@ Logto เป็นบริการข้อมูลระบุตัวต ::: 1. ระบุ [**redirect URI**](/integrate-logto/application-data-structure#redirect-uris) ของแอป OIDC บุคคลที่สามของคุณ นี่คือ URL ที่แอปพลิเคชันบุคคลที่สามจะเปลี่ยนเส้นทางผู้ใช้กลับมาหลังจากได้รับการยืนยันตัวตนโดย Logto - โดยปกติคุณจะพบข้อมูลนี้ในหน้าตั้งค่าการเชื่อมต่อ IdP ของแอปพลิเคชันบุคคลที่สาม + โดยปกติคุณจะพบข้อมูลนี้ในหน้าการตั้งค่าการเชื่อมต่อ IdP ของแอปพลิเคชันบุคคลที่สาม -2. ดึง [**client ID**](/integrate-logto/application-data-structure#application-id) และ [**client secret**](/integrate-logto/application-data-structure#application-secret) จากหน้ารายละเอียดแอป Logto แล้วกรอกลงในหน้าตั้งค่าการเชื่อมต่อ IdP ของผู้ให้บริการของคุณ +2. รับ [**client ID**](/integrate-logto/application-data-structure#application-id) และ [**client secret**](/integrate-logto/application-data-structure#application-secret) จากหน้ารายละเอียดแอป Logto แล้วกรอกลงในหน้าการตั้งค่าการเชื่อมต่อ IdP ของผู้ให้บริการของคุณ -3. ดึง [**authorization endpoint**](/integrate-logto/application-data-structure#authorization-endpoint) และ [**token endpoint**](/integrate-logto/application-data-structure#token-endpoint) จากหน้ารายละเอียดแอป Logto แล้วแจ้งให้ผู้ให้บริการของคุณทราบ - หากผู้ให้บริการของคุณรองรับ OIDC discovery คุณสามารถคัดลอก **discovery endpoint** จากหน้ารายละเอียดแอป Logto แล้วแจ้งให้ผู้ให้บริการของคุณทราบ ผู้ให้บริการจะสามารถดึงข้อมูล OIDC authentication ล่าสุดทั้งหมดจาก discovery endpoint ได้โดยอัตโนมัติ +3. รับ [**authorization endpoint**](/integrate-logto/application-data-structure#authorization-endpoint) และ [**token endpoint**](/integrate-logto/application-data-structure#token-endpoint) จากหน้ารายละเอียดแอป Logto แล้วแจ้งให้ผู้ให้บริการของคุณทราบ + หากผู้ให้บริการของคุณรองรับ OIDC discovery คุณสามารถคัดลอก **discovery endpoint** จากหน้ารายละเอียดแอป Logto แล้วแจ้งให้ผู้ให้บริการของคุณทราบ ผู้ให้บริการจะสามารถดึงข้อมูลการยืนยันตัวตน OIDC ที่อัปเดตล่าสุดจาก discovery endpoint ได้โดยอัตโนมัติ หากไม่รองรับ ให้คลิกปุ่ม **Show endpoint details** เพื่อดู endpoint การยืนยันตัวตน OIDC ทั้งหมด ## หน้าขอความยินยอมสำหรับแอป OIDC บุคคลที่สาม \{#consent-screen-for-oidc-third-party-applications} เพื่อความปลอดภัย แอป OIDC บุคคลที่สามทั้งหมดจะถูกเปลี่ยนเส้นทางไปยัง [หน้าขอความยินยอม (consent screen)](/end-user-flows/consent-screen) เพื่อขอการอนุญาตจากผู้ใช้หลังจากได้รับการยืนยันตัวตนโดย Logto -[สิทธิ์โปรไฟล์ผู้ใช้](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) [ขอบเขตทรัพยากร API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes) [สิทธิ์องค์กร](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) และข้อมูลสมาชิกองค์กรที่แอปบุคคลที่สามร้องขอทั้งหมดจะแสดงบนหน้าขอความยินยอม +สิทธิ์โปรไฟล์ผู้ใช้ที่แอปบุคคลที่สามร้องขอทั้งหมด ([user profile permissions](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)), [ขอบเขตทรัพยากร API (API resource scopes)](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [สิทธิ์องค์กร (organization permissions)](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) และข้อมูลสมาชิกองค์กรจะถูกแสดงบนหน้าขอความยินยอม -สิทธิ์ที่ร้องขอเหล่านี้จะถูกอนุมัติให้แอปพลิเคชันบุคคลที่สามก็ต่อเมื่อผู้ใช้คลิกปุ่ม "Authorize" เท่านั้น +สิทธิ์ที่ร้องขอเหล่านี้จะถูกอนุมัติให้กับแอปบุคคลที่สามก็ต่อเมื่อผู้ใช้คลิกปุ่ม "Authorize" เท่านั้น
consent screen @@ -87,16 +87,16 @@ Logto เป็นบริการข้อมูลระบุตัวต
-### เราจะมั่นใจได้อย่างไรว่าผู้ใช้สามารถให้สิทธิ์เฉพาะที่ตนเองมีบนหน้าขอความยินยอม? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} +### เราจะมั่นใจได้อย่างไรว่าผู้ใช้สามารถให้สิทธิ์เฉพาะที่ตนเองมีอยู่จริงบนหน้าขอความยินยอม? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} -Logto ใช้การควบคุมการเข้าถึงตามบทบาท (RBAC) เพื่อจัดการสิทธิ์ของผู้ใช้ บนหน้าขอความยินยอมจะแสดงเฉพาะขอบเขต (สิทธิ์) ที่ผู้ใช้ได้รับผ่านบทบาทของตนเท่านั้น หากแอปบุคคลที่สามร้องขอขอบเขตที่ผู้ใช้ไม่มี จะไม่แสดงเพื่อป้องกันการให้ความยินยอมโดยไม่ได้รับอนุญาต +Logto ใช้การควบคุมการเข้าถึงตามบทบาท (RBAC) เพื่อจัดการสิทธิ์ของผู้ใช้ บนหน้าขอความยินยอมจะมีการแสดงเฉพาะขอบเขต (สิทธิ์) ที่ผู้ใช้ได้รับผ่านบทบาทของตนเท่านั้น หากแอปบุคคลที่สามร้องขอขอบเขตที่ผู้ใช้ไม่มี จะไม่แสดงเพื่อป้องกันการให้ความยินยอมโดยไม่ได้รับอนุญาต วิธีจัดการ: -- กำหนด [บทบาทระดับโกลบอล](/authorization/role-based-access-control) หรือ [บทบาทองค์กร](/authorization/organization-template) พร้อมขอบเขตเฉพาะ -- กำหนดบทบาทให้ผู้ใช้ตามความต้องการในการเข้าถึง +- กำหนด [บทบาทระดับโกลบอล](/authorization/role-based-access-control) หรือ [บทบาทองค์กร](/authorization/organization-template) พร้อมขอบเขตที่ต้องการ +- มอบหมายบทบาทให้ผู้ใช้ตามความต้องการในการเข้าถึง - ผู้ใช้จะได้รับขอบเขตจากบทบาทโดยอัตโนมัติ
@@ -104,7 +104,7 @@ Logto ใช้การควบคุมการเข้าถึงตา ## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} - กรณีศึกษา: ผสานรวม Apache Answer เพื่อสร้างชุมชนสำหรับผู้ใช้ของคุณ + กรณีศึกษา: ผสานรวม Apache Answer เพื่อสร้างคอมมูนิตี้สำหรับผู้ใช้ของคุณ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index 0ee621c821b..c8e1474d186 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,10 +3,11 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # บริการคลาวด์ของ Logto -[Logto Cloud](https://cloud.logto.io) ให้บริการด้านการจัดการและการดำเนินงานที่หลากหลาย เพื่อช่วยให้คุณบริหารจัดการเอกลักษณ์และทรัพยากรได้อย่างราบรื่นและง่ายดาย โดยโฮสต์โดย Logto ซึ่งมีฟีเจอร์ต่าง ๆ เช่น [รองรับหลายภูมิภาค](/logto-cloud/tenant-settings#tenant-region), การจัดการผู้เช่า (tenant), [การเรียกเก็บเงินและราคา](/logto-cloud/billing-and-pricing), [การจัดการสมาชิกผู้เช่า](/logto-cloud/tenant-member-management), และการควบคุมการเข้าถึงคอนโซลตามบทบาท (RBAC) +[Logto Cloud](https://cloud.logto.io) ให้บริการด้านการจัดการและการดำเนินงานหลากหลาย เพื่อช่วยให้คุณจัดการเอกลักษณ์และทรัพยากรได้อย่างราบรื่นและง่ายดาย โดยโฮสต์โดย Logto ซึ่งมีฟีเจอร์ต่าง ๆ เช่น [รองรับหลายภูมิภาค](/logto-cloud/tenant-settings#tenant-region), การจัดการผู้เช่า (tenant), [การเรียกเก็บเงินและราคา](/logto-cloud/billing-and-pricing), [การจัดการสมาชิกผู้เช่า](/logto-cloud/tenant-member-management), และการควบคุมการเข้าถึงคอนโซลตามบทบาท (RBAC) หากคุณมีคำถามเกี่ยวกับบริการคลาวด์และต้องการความช่วยเหลือเพิ่มเติม กรุณาติดต่อเรา @@ -16,7 +17,7 @@ import CustomDomains from '@site/src/assets/search.svg'; items={[ { type: 'link', - label: 'การตั้งค่าผู้เช่า (Tenant settings)', + label: 'การตั้งค่าผู้เช่า', href: '/logto-cloud/tenant-settings', description: 'อัปเดตหรือเปลี่ยนชื่อผู้เช่า ตรวจสอบภูมิภาค และลบหรือออกจากผู้เช่า', customProps: { @@ -25,17 +26,17 @@ import CustomDomains from '@site/src/assets/search.svg'; }, { type: 'link', - label: 'นโยบายการเก็บข้อมูลผู้เช่า dev (Dev tenant data retention policy)', + label: 'นโยบายการเก็บข้อมูลผู้เช่า Dev', href: '/logto-cloud/dev-tenant-data-retention', description: - 'ทำความเข้าใจนโยบายการเก็บข้อมูลผู้ใช้ 90 วันของ dev tenant และวิธีใช้ dev tenant ของ Logto อย่างมีประสิทธิภาพ', + 'ทำความเข้าใจนโยบายการเก็บข้อมูลผู้ใช้ 90 วันสำหรับผู้เช่า Dev และวิธีใช้ผู้เช่า Dev ของ Logto อย่างมีประสิทธิภาพ', customProps: { icon: , }, }, { type: 'link', - label: 'การจัดการสมาชิกผู้เช่า (Tenant member management)', + label: 'การจัดการสมาชิกผู้เช่า', href: '/logto-cloud/tenant-member-management', description: 'ผู้ดูแลผู้เช่าสามารถเชิญและจัดการสมาชิก รวมถึงอัปเดตบทบาทของพวกเขาได้', customProps: { @@ -44,22 +45,32 @@ import CustomDomains from '@site/src/assets/search.svg'; }, { type: 'link', - label: 'โดเมนแบบกำหนดเอง (Custom domains)', + label: 'โดเมนแบบกำหนดเอง', href: '/logto-cloud/custom-domain', description: - 'ใช้โดเมนของคุณเองสำหรับผู้เช่า Logto เพื่อให้แบรนด์ของคุณสอดคล้องกันในประสบการณ์การลงชื่อเข้าใช้', + 'ใช้โดเมนของคุณเองกับผู้เช่า Logto เพื่อให้แบรนด์ของคุณสอดคล้องกันในประสบการณ์การลงชื่อเข้าใช้', customProps: { icon: , }, }, { type: 'link', - label: 'การเรียกเก็บเงินและราคา (Billing and pricing)', + label: 'การเรียกเก็บเงินและราคา', href: '/logto-cloud/billing-and-pricing', description: 'เข้าใจบิลของคุณได้ง่ายและจัดการการสมัครสมาชิกของคุณอย่างมั่นใจ', customProps: { icon: , }, }, + { + type: 'link', + label: 'ขีดจำกัดของระบบ', + href: '/logto-cloud/system-limit', + description: + 'ทำความเข้าใจขีดจำกัดของระบบและการป้องกันอัตราสำหรับผู้เช่า Dev, Pro และ Enterprise', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index eaf69a4cc4a..f3fc3f91fe7 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -4,19 +4,19 @@ title: โดเมนแบบกำหนดเอง sidebar_position: 4 --- -# โดเมนแบบกำหนดเอง +# โดเมนแบบกำหนดเอง (Custom domain) Logto tenant ของคุณจะมาพร้อมกับโดเมนฟรีเริ่มต้น `{{tenant-id}}.app.logto` อย่างไรก็ตาม คุณสามารถยกระดับประสบการณ์ผู้ใช้และการจดจำแบรนด์ของคุณได้ด้วยการใช้โดเมนแบบกำหนดเอง เช่น `auth.example.com` โดเมนแบบกำหนดเองของคุณจะถูกใช้ในหลายฟังก์ชัน เช่น: - URL ของ [หน้าลงชื่อเข้าใช้และลงทะเบียน](/end-user-flows/sign-up-and-sign-in) -- URL สำหรับการเชื่อมโยง [Passkey](/end-user-flows/mfa/webauthn) (การเปลี่ยนโดเมนหลังจากที่ผู้ใช้เชื่อมโยง Passkey แล้ว อาจทำให้การยืนยันตัวตนของพวกเขาถูกบล็อก) +- URL สำหรับเชื่อมโยง [Passkey](/end-user-flows/mfa/webauthn) (การเปลี่ยนโดเมนหลังจากผู้ใช้เชื่อมโยง Passkey แล้ว อาจทำให้การยืนยันตัวตนของพวกเขาถูกบล็อก) - Callback URI สำหรับ [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors) หรือ [ตัวเชื่อมต่อ enterprise SSO](/connectors/enterprise-connectors) - [SDK endpoint](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) สำหรับการเชื่อมต่อ Logto กับแอปพลิเคชันของคุณ :::note -การเปลี่ยนโดเมนหลังจากเผยแพร่บริการของคุณแล้ว อาจทำให้เกิดปัญหาได้ เนื่องจากโค้ดแอปพลิเคชันและการเชื่อมต่อของคุณอาจยังอ้างอิงโดเมนเดิมอยู่ เพื่อให้การเปลี่ยนผ่านเป็นไปอย่างราบรื่น **ควรกำหนดโดเมนแบบกำหนดเองตั้งแต่ต้น** ขณะสร้าง Production tenant +การเปลี่ยนโดเมนหลังจากเผยแพร่บริการของคุณแล้วอาจทำให้เกิดปัญหาได้ เนื่องจากโค้ดแอปพลิเคชันและการเชื่อมต่อของคุณอาจยังอ้างอิงโดเมนเดิมอยู่ เพื่อให้การเปลี่ยนผ่านเป็นไปอย่างราบรื่น **ควรตั้งค่าโดเมนแบบกำหนดเองตั้งแต่ต้น** ขณะสร้าง Production tenant ::: ## ตั้งค่าโดเมนแบบกำหนดเองใน Console \{#configure-custom-domain-in-console} @@ -32,9 +32,9 @@ Logto tenant ของคุณจะมาพร้อมกับโดเม Custom domain processing -4. รอการตรวจสอบและออกใบรับรอง SSL +4. รอการตรวจสอบและกระบวนการ SSL 1. เราจะตรวจสอบ record ของคุณอัตโนมัติทุก 10 วินาทีจนกว่าโดเมนแบบกำหนดเองจะถูกเพิ่ม ตรวจสอบให้แน่ใจว่าชื่อโดเมนหรือ DNS Records ที่กรอกถูกต้อง - 2. การตรวจสอบมักใช้เวลาเพียงไม่กี่นาที แต่ในบางกรณีอาจนานถึง 24 ชั่วโมง ขึ้นอยู่กับผู้ให้บริการ DNS คุณสามารถออกจากหน้านี้ระหว่างรอได้ + 2. การตรวจสอบมักใช้เวลาไม่กี่นาที แต่ในบางกรณีอาจนานถึง 24 ชั่วโมง ขึ้นอยู่กับผู้ให้บริการ DNS คุณสามารถออกจากหน้านี้ระหว่างรอได้ ## การแก้ไขปัญหา \{#troubleshooting} @@ -47,7 +47,7 @@ Logto tenant ของคุณจะมาพร้อมกับโดเม หากคุณพบปัญหาใบรับรอง SSL ขณะตั้งค่าโดเมนแบบกำหนดเอง อาจเกี่ยวข้องกับ CAA records ในการตั้งค่า DNS ของคุณ CAA records จะระบุว่า Certificate Authorities (CAs) ใดได้รับอนุญาตให้ออกใบรับรองสำหรับโดเมนของคุณ หากคุณใช้ CAA records คุณต้องอนุญาตทั้ง "letsencrypt.org" และ "pki.goog" เพื่อให้ Logto สามารถออกใบรับรอง SSL ได้ -สำหรับวิธีแก้ไขปัญหาใบรับรอง SSL ที่เกี่ยวข้องกับ CAA records โปรดดู [เอกสาร Cloudflare](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) เกี่ยวกับ CAA Records +สำหรับการแก้ไขปัญหาและรายละเอียดเพิ่มเติมเกี่ยวกับ CAA records โปรดดู [เอกสาร Cloudflare](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) เกี่ยวกับ CAA Records @@ -58,9 +58,9 @@ Logto tenant ของคุณจะมาพร้อมกับโดเม -หากคุณพบข้อความแสดงข้อผิดพลาด "The hostname is associated with a held zone, please contact the owner to have the hold removed" ขณะเพิ่มโดเมนแบบกำหนดเอง หมายความว่าโดเมนนั้นอยู่ใน Cloudflare zone แล้ว และถูกตั้งสถานะเป็น "Zone Hold" ดู [เอกสาร Cloudflare](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/) สำหรับข้อมูลเพิ่มเติม +หากคุณพบข้อความผิดพลาด "The hostname is associated with a held zone, please contact the owner to have the hold removed" ขณะเพิ่มโดเมนแบบกำหนดเอง หมายความว่าโดเมนนั้นอยู่ใน Cloudflare zone และถูกตั้งสถานะเป็น "Zone Hold" ดู [เอกสาร Cloudflare นี้](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/) สำหรับข้อมูลเพิ่มเติม -ในการแก้ไขปัญหานี้ คุณต้องปลดล็อก zone hold ดูลิงก์ข้างต้นสำหรับวิธีการปลดล็อก zone hold ใน Cloudflare +วิธีแก้ไขคือต้องปลดสถานะ zone hold ดูวิธีการได้จากลิงก์ข้างต้น @@ -75,9 +75,40 @@ Logto tenant ของคุณจะมาพร้อมกับโดเม +
+ + +### ข้อผิดพลาด "Redirect URI does not match" หลังตั้งค่าโดเมนแบบกำหนดเอง \{#redirect-uri-mismatch} + + + +หากคุณได้รับข้อผิดพลาด "redirect URI does not match" หลังจากเพิ่มโดเมนแบบกำหนดเอง คุณต้องอัปเดตการตั้งค่า SDK ของคุณให้ใช้โดเมนแบบกำหนดเองเป็น endpoint + +**เกี่ยวกับ "primary domain":** + +ใน Logto ไม่มีการตั้งค่า "primary domain" แยกต่างหาก หลังจากเพิ่มโดเมนแบบกำหนดเองแล้ว ทั้งโดเมนแบบกำหนดเองและโดเมนเริ่มต้น `{tenant-id}.logto.app` จะยังคงใช้งานได้ โดเมนที่คุณกำหนดในพารามิเตอร์ `endpoint` ของ SDK จะเป็นตัวกำหนดว่าจะใช้โดเมนใดใน flow การยืนยันตัวตน + +**วิธีแก้ไข:** + +อัปเดตพารามิเตอร์ `endpoint` ในการเริ่มต้น SDK ของคุณให้ใช้โดเมนแบบกำหนดเอง: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // ใช้โดเมนแบบกำหนดเองของคุณ + appId: 'your-app-id', + // ... ตัวเลือกอื่น ๆ +}); +``` + +ตรวจสอบด้วยว่า redirect URI ที่ลงทะเบียนใน Console → Applications ตรงกับโดเมนที่คุณใช้งาน + +**หมายเหตุ:** Logto จะจัดเตรียมและจัดการใบรับรอง SSL สำหรับโดเมนแบบกำหนดเองของคุณโดยอัตโนมัติ คุณไม่จำเป็นต้องตั้งค่าใบรับรองเอง + +
+ ## การใช้งานโดเมนแบบกำหนดเอง \{#use-custom-domain} -เมื่อคุณตั้งค่าการใช้งานเสร็จแล้ว ทั้งชื่อโดเมนแบบกำหนดเองและชื่อโดเมน Logto เริ่มต้นจะพร้อมใช้งานสำหรับ tenant ของคุณ อย่างไรก็ตาม จำเป็นต้องมีการตั้งค่าบางอย่างเพื่อเปิดใช้งานโดเมนแบบกำหนดเอง +เมื่อคุณตั้งค่าการใช้งานเสร็จแล้ว ทั้งชื่อโดเมนแบบกำหนดเองและโดเมนเริ่มต้นของ Logto จะพร้อมใช้งานสำหรับ tenant ของคุณ อย่างไรก็ตาม ต้องมีการตั้งค่าบางอย่างเพื่อเปิดใช้งานโดเมนแบบกำหนดเอง :::note @@ -87,7 +118,7 @@ Logto tenant ของคุณจะมาพร้อมกับโดเม ### การอัปเดต SDK endpoint สำหรับแอปพลิเคชัน \{#updating-the-sdk-endpoint-for-applications} -ปรับเปลี่ยนโค้ดเริ่มต้นของ Logto SDK โดยแก้ไขชื่อโดเมนของ endpoint +แก้ไขโค้ดเริ่มต้นของ Logto SDK โดยเปลี่ยนชื่อโดเมนใน endpoint ```typescript const client = new LogtoClient({ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..b3492e4914d --- /dev/null +++ b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# ขีดจำกัดของระบบ + +ที่ Logto เรากำหนดขีดจำกัดที่เอื้อเฟื้อในทุกแผน พร้อมตัวเลือกจ่ายตามการใช้งานจริง (pay-as-you-go) ที่ยืดหยุ่น เพื่อให้ผู้ใช้จ่ายเฉพาะสิ่งที่ใช้จริงเท่านั้น + +คุณอาจสังเกตเห็นว่าบางรายการในหน้าราคา ถูกระบุว่า _ไม่จำกัด_ หรือ _จ่ายตามการใช้งานจริงแบบต่อเนื่องโดยไม่มีเพดาน_ ซึ่งหมายความว่าสามารถใช้งานได้โดยทั่วไปโดยไม่มีข้อจำกัด แต่ Logto ขอสงวนสิทธิ์ในการปรับขีดจำกัดเหล่านี้ตามความเหมาะสม เพื่อรักษาการใช้งานที่เป็นธรรมสำหรับผู้ใช้ทุกคน กล่าวคือ ขีดจำกัดของเอนทิตีเป็นเพดานที่เข้มงวดเพื่อปกป้องสุขภาพโดยรวมของแพลตฟอร์ม ไม่ใช่ส่วนหนึ่งของราคา แม้อาจแตกต่างกันในแต่ละกลุ่มแผน + +หากกรณีการใช้งานของคุณสมเหตุสมผลแต่ถึงขีดจำกัดของระบบ สามารถติดต่อเราและแบ่งปันข้อเสนอแนะได้เสมอ สิ่งนี้ช่วยให้เราเข้าใจรูปแบบการใช้งานจริง และปรับขีดจำกัดของระบบให้รองรับลูกค้าประจำได้ดียิ่งขึ้น + +## การป้องกันขีดจำกัดอัตราในระดับผู้เช่า (Tenant-level rate limit protection) \{#tenant-level-rate-limit-protection} + +### ผู้เช่า Dev \{#dev-tenants} + +สำหรับผู้เช่า Dev ผู้ใช้สามารถใช้ประโยชน์จากฟีเจอร์และข้อเสนอฟรีของ Logto ได้ เพื่อป้องกันการใช้งานที่ผิดวัตถุประสงค์และสร้างความคาดหวังที่ชัดเจน เราจึงกำหนดขีดจำกัดของระบบบางประการ ขีดจำกัดเหล่านี้ช่วยให้เราบริหารจัดการแพลตฟอร์มอย่างยั่งยืน ขณะเดียวกันยังคงให้เข้าถึงฟรีสำหรับการทดสอบและพัฒนา + +หากต้องการเพิ่มโควตา สามารถติดต่อเราเพื่อขอความช่วยเหลือได้ นอกจากนี้ยังแนะนำให้อัปเกรดจาก **Dev** เป็น **Pro** ซึ่งจะยกเลิกเพดานและให้เข้าถึงเต็มรูปแบบทันที + +| **ฟีเจอร์** | **ขีดจำกัดเอนทิตี** | +| --------------------------------- | ------------------- | +| **โทเค็นที่รวมในแพ็กเกจ** | 50,000 ต่อเดือน | +| **แอปพลิเคชัน** | | +| จำนวนแอปพลิเคชันทั้งหมด | 100 | +| แอป Machine-to-machine | 100 | +| แอป Third-party | 100 | +| **ทรัพยากร API** | | +| จำนวนทรัพยากร | 100 | +| **การยืนยันตัวตนผู้ใช้** | | +| ตัวเชื่อมต่อโซเชียล | 100 | +| Enterprise SSO | 100 | +| **การจัดการผู้ใช้** | | +| บทบาทผู้ใช้ | 100 | +| บทบาท Machine-to-machine | 100 | +| สิทธิ์ต่อบทบาท | 100 | +| **องค์กร** | | +| จำนวนองค์กร | 5,000 | +| ผู้ใช้ต่อองค์กร | 100,000 | +| บทบาทผู้ใช้ในองค์กร | 1,000 | +| บทบาท Machine-to-machine ในองค์กร | 100 | +| สิทธิ์ขององค์กร | 1,000 | +| **นักพัฒนาและแพลตฟอร์ม** | | +| Webhook | 10 | +| ระยะเวลาจัดเก็บบันทึกการตรวจสอบ | 14 วัน | +| สมาชิกผู้เช่า | 20 | + +### ผู้เช่า Pro \{#pro-tenant} + +สำหรับผู้เช่า Pro ขีดจำกัดของเอนทิตีจะเป็นเพดานสูงสุดสำหรับ Add-on และเอนทิตี “ไม่จำกัด” อื่น ๆ เช่น แอปพลิเคชัน รายละเอียดขีดจำกัดของระบบในแผน Pro มีดังนี้ + +| **ฟีเจอร์** | **ขีดจำกัดเอนทิตี** | +| --------------------------------- | ------------------- | +| **โทเค็นที่รวมในแพ็กเกจ** | 10,000,000 ต่อเดือน | +| **แอปพลิเคชัน** | | +| จำนวนแอปพลิเคชันทั้งหมด | 100 | +| แอป Machine-to-machine | 100 | +| แอป OIDC/OAuth 3rd party | 100 | +| แอป SAML | 100 | +| **ทรัพยากร API** | | +| จำนวนทรัพยากร | 1,000 | +| สิทธิ์ต่อทรัพยากร | 1,000 | +| **การยืนยันตัวตนผู้ใช้** | | +| ตัวเชื่อมต่อโซเชียล | 100 | +| Enterprise SSO | 100 | +| **การจัดการผู้ใช้** | | +| บทบาทผู้ใช้ | 1,000 | +| บทบาท Machine-to-machine | 100 | +| **องค์กร** | | +| จำนวนองค์กร | 100,000 | +| ผู้ใช้ต่อองค์กร | 100,000 | +| บทบาทผู้ใช้ในองค์กร | 1,000 | +| บทบาท Machine-to-machine ในองค์กร | 100 | +| สิทธิ์ขององค์กร | 1,000 | +| **นักพัฒนาและแพลตฟอร์ม** | | +| Webhook | 10 | +| ระยะเวลาจัดเก็บบันทึกการตรวจสอบ | 14 วัน | +| โดเมนแบบกำหนดเอง | 10 | +| สมาชิกผู้เช่า | 100 | + +### Enterprise \{#enterprise} + +สำหรับแผน Enterprise ขีดจำกัดและฟีเจอร์สามารถปรับแต่งได้เต็มที่และบริหารจัดการผ่านสัญญา โปรด [ติดต่อเรา](https://logto.io/contact) เพื่อขอรายละเอียดเพิ่มเติม diff --git a/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index ac8e1f819ac..ab7cabc173d 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -6,9 +6,9 @@ sidebar_position: 1 # การตั้งค่าเทนแนนต์ -ผู้ใช้ใหม่ที่ลงทะเบียน Logto Cloud จะได้รับการเริ่มต้นใช้งานอัตโนมัติในเทนแนนต์สภาพแวดล้อม **พัฒนา (Development; Dev)** ฟรี คุณสามารถสำรวจฟีเจอร์ทั้งหมดในเทนแนนต์นี้ได้ +ผู้ใช้ใหม่ที่ลงทะเบียน Logto Cloud จะได้รับการเริ่มต้นใช้งานกับ **สภาพแวดล้อมการพัฒนา (Development; Dev)** ฟรีโดยอัตโนมัติ คุณสามารถทดลองใช้ฟีเจอร์ทั้งหมดในเทนแนนต์นี้ได้ -หากคุณต้องการสร้างเทนแนนต์แยกสำหรับสภาพแวดล้อม **ผลิต (Production; Prod)** หรือโปรเจกต์ใหม่ ให้คลิกชื่อเทนแนนต์ปัจจุบันของคุณที่มุมซ้ายบนของแถบด้านบน ในเมนูนี้ คุณสามารถสลับระหว่างเทนแนนต์หรือสร้างเทนแนนต์ใหม่ได้ +หากคุณต้องการสร้างเทนแนนต์แยกสำหรับ **สภาพแวดล้อมการผลิต (Production; Prod)** หรือโปรเจกต์ใหม่ ให้คลิกชื่อเทนแนนต์ปัจจุบันของคุณที่มุมซ้ายบนของแถบด้านบน ในเมนูนี้ คุณสามารถสลับระหว่างเทนแนนต์หรือสร้างเทนแนนต์ใหม่ได้ คลิก "Create tenant" จากนั้น: @@ -21,13 +21,13 @@ sidebar_position: 1 - ดูรหัสเทนแนนต์ (tenant ID) - อัปเดตชื่อเทนแนนต์ - ดู [ภูมิภาคของเทนแนนต์](#tenant-region) (ไม่สามารถเปลี่ยนแปลงได้หลังจากสร้าง) -- ดู [ประเภทของเทนแนนต์](#tenant-types-dev-vs-prod) (คุณสามารถแปลงเทนแนนต์ Dev เป็นเทนแนนต์ Prod ได้หากต้องการ) +- ดู [ประเภทของเทนแนนต์](#tenant-types-dev-vs-prod) (คุณสามารถแปลง Dev tenant เป็น Prod tenant ได้หากต้องการ) - [ออกจากเทนแนนต์](#leave-tenant) - [ลบเทนแนนต์](#delete-tenant) ## ภูมิภาคของเทนแนนต์ \{#tenant-region} -เมื่อคุณสร้างเทนแนนต์ คุณสามารถเลือกภูมิภาคที่จัดเก็บข้อมูลของเทนแนนต์ได้ ซึ่งไม่สามารถเปลี่ยนแปลงได้หลังจากสร้างเทนแนนต์แล้ว ภูมิภาคที่มีให้เลือก ได้แก่ +เมื่อคุณสร้างเทนแนนต์ คุณสามารถเลือกภูมิภาคที่จัดเก็บข้อมูลของเทนแนนต์ได้ โดยไม่สามารถเปลี่ยนแปลงได้หลังจากสร้างเทนแนนต์แล้ว ภูมิภาคที่มีให้เลือก ได้แก่ - ยุโรป (เนเธอร์แลนด์) - สหรัฐอเมริกาตะวันตก (แอริโซนา) @@ -36,10 +36,10 @@ sidebar_position: 1 โดยปกติ คุณควรเลือกภูมิภาคที่ใกล้กับลูกค้าของคุณมากที่สุด เพื่อลดความหน่วงและเพิ่มประสิทธิภาพ -Logto ใช้ประโยชน์จากเครือข่าย edge ทั่วโลกเพื่อมอบประสิทธิภาพและความพร้อมใช้งานที่ดีที่สุดสำหรับแอปพลิเคชันของคุณ การกำหนดเส้นทางคำขอได้รับการปรับแต่งเพื่อให้แน่ใจว่าผู้ใช้ของคุณเชื่อมต่อกับตัวเลือกที่มีประสิทธิภาพสูงสุดเสมอ +Logto ใช้ประโยชน์จากเครือข่าย edge ทั่วโลกเพื่อมอบประสิทธิภาพและความพร้อมใช้งานที่ดีที่สุดสำหรับแอปพลิเคชันของคุณ การกำหนดเส้นทางคำขอได้รับการปรับแต่งเพื่อให้แน่ใจว่าผู้ใช้ของคุณเชื่อมต่อกับตัวเลือกที่มีประสิทธิภาพดีที่สุดเสมอ :::note -กำลังมองหาภูมิภาคอื่นอยู่ใช่ไหม? [ติดต่อเรา](https://logto.io/contact) เพื่อ: +กำลังมองหาภูมิภาคอื่น? [ติดต่อเรา](https://logto.io/contact) เพื่อ: - ขอเพิ่มภูมิภาค public cloud ใหม่ - สอบถามเกี่ยวกับการติดตั้ง Logto Private Cloud ในสถานที่ที่คุณต้องการ @@ -47,68 +47,42 @@ Logto ใช้ประโยชน์จากเครือข่าย edge ## ประเภทของเทนแนนต์: Dev กับ Prod \{#tenant-types-dev-vs-prod} -ใน Logto Cloud มีเทนแนนต์สองประเภท: พัฒนา (Development; Dev) และ ผลิต (Production; Prod) ด้วยการแยกประเภทเทนแนนต์นี้ คุณจะสามารถจัดการโปรเจกต์ของคุณในแต่ละสภาพแวดล้อมได้อย่างมีประสิทธิภาพ และยังได้รับประโยชน์จาก Logto อย่างเต็มที่ +ใน Logto Cloud มีเทนแนนต์ 2 ประเภท: การพัฒนา (Dev) และการผลิต (Prod) ด้วยการแยกประเภทเทนแนนต์นี้ คุณจะสามารถจัดการโปรเจกต์ในแต่ละสภาพแวดล้อมได้อย่างมีประสิทธิภาพ และยังได้รับประโยชน์จาก Logto อย่างเต็มที่ -คุณสามารถเลือกประเภทเทนแนนต์ได้ขณะสร้าง เมื่อคุณพร้อมใช้งานจริงสำหรับ production มีสองทางเลือก: +คุณสามารถเลือกประเภทเทนแนนต์ได้ขณะสร้าง เมื่อพร้อมใช้งานจริงสำหรับ production มี 2 ทางเลือก: - **สร้างเทนแนนต์ Production ใหม่** - ตั้งค่าเทนแนนต์ production ใหม่และกำหนดค่าตั้งแต่ต้น เหมาะสำหรับกรณีที่ต้องการแยกสภาพแวดล้อมพัฒนาและผลิตออกจากกัน -- **แปลงเทนแนนต์ Dev ปัจจุบันของคุณเป็น Production** - หากคุณไม่ต้องการตั้งค่าหรือย้ายผู้ใช้ใหม่ คุณสามารถอัปเกรดเทนแนนต์ Development ที่มีอยู่เป็นเทนแนนต์ Production แบบชำระเงินได้ + ตั้งค่าเทนแนนต์ production ใหม่และกำหนดค่าตั้งแต่ต้น เหมาะสำหรับกรณีที่ต้องการแยกสภาพแวดล้อม dev และ prod ออกจากกัน +- **แปลง Dev tenant ปัจจุบันเป็น Production** + หากไม่ต้องการตั้งค่าหรือย้ายผู้ใช้ใหม่ คุณสามารถอัปเกรด Dev tenant ที่มีอยู่เป็น Production tenant แบบเสียค่าใช้จ่ายได้ - - **แปลงเป็นแผน Pro**: ไปที่ Console > การตั้งค่าเทนแนนต์ > การตั้งค่า แล้วคลิก "Convert" เพื่ออัปเกรดด้วยตนเอง ฟีเจอร์ที่ต้องชำระเงินที่คุณใช้ในเทนแนนต์ dev จะถูกรวมไปยัง Stripe checkout + - **แปลงเป็นแผน Pro**: ไปที่ Console > การตั้งค่าเทนแนนต์ > การตั้งค่า แล้วคลิก "Convert" เพื่ออัปเกรดด้วยตนเอง ฟีเจอร์ที่ต้องชำระเงินที่คุณใช้ใน dev tenant จะถูกรวมใน Stripe checkout - **แปลงเป็นแผน Enterprise**: [ติดต่อเรา](https://logto.io/contact) แล้วเราจะช่วยคุณดำเนินการอัปเกรด :::note - เมื่อแปลงแล้ว เทนแนนต์จะไม่สามารถย้อนกลับเป็นสภาพแวดล้อม Dev ได้ โปรดยืนยันว่าคุณพร้อมก่อนดำเนินการ + เมื่อแปลงแล้วจะไม่สามารถย้อนกลับเป็น Dev environment ได้ กรุณาตรวจสอบความพร้อมก่อนดำเนินการ ::: -### พัฒนา (Development) \{#development} - -เทนแนนต์พัฒนา (dev tenant) มีไว้สำหรับการทดสอบเป็นหลัก และไม่ควรใช้ในสภาพแวดล้อม production เทนแนนต์เหล่านี้สามารถเข้าถึงฟีเจอร์พรีเมียมและฟีเจอร์ที่ต้องชำระเงินในแผนแบบชำระเงินได้ฟรีโดยไม่ต้องสมัครสมาชิก - -อย่างไรก็ตาม มีข้อจำกัดบางประการสำหรับเทนแนนต์พัฒนา: - -- เทนแนนต์ Dev จะลบผู้ใช้อัตโนมัติหลังจาก 90 วัน ดู [นโยบายการเก็บข้อมูลของเทนแนนต์ Dev](./dev-tenant-data-retention) สำหรับรายละเอียด -- จะมีแบนเนอร์แสดงระหว่างประสบการณ์การลงชื่อเข้าใช้ เพื่อระบุว่าเทนแนนต์อยู่ในโหมดพัฒนา -- เทนแนนต์พัฒนาอาจมีข้อจำกัดโควต้าสำหรับฟีเจอร์บางอย่าง โดยจะอธิบายไว้ในหน้ารายละเอียดฟีเจอร์ (ถ้ามี) -- Logto อาจอัปเดตข้อจำกัดโควต้าของเทนแนนต์พัฒนา และเราจะพยายามแจ้งให้คุณทราบล่วงหน้า - -| ฟีเจอร์ | ขีดจำกัดเอนทิตี | -| ------------------------ | --------------- | -| **โทเค็นที่รวมในแผน** | 50,000 ต่อเดือน | -| **แอปพลิเคชัน** | -| แอปพลิเคชันทั้งหมด | 100 | -| แอป machine-to-machine | 100 | -| แอป third-party | 100 | -| **ทรัพยากร API** | | -| จำนวนทรัพยากร | 100 | -| **การยืนยันตัวตนผู้ใช้** | | -| ตัวเชื่อมต่อโซเชียล | 100 | -| SSO สำหรับองค์กร | 100 | -| **การจัดการผู้ใช้** | | -| บทบาทผู้ใช้ | 100 | -| บทบาท machine-to-machine | 100 | -| สิทธิ์ต่อบทบาท | 100 | -| **องค์กร** | | -| จำนวนองค์กร | 5,000 | -| ผู้ใช้ต่อองค์กร | 5,000 | -| บทบาทองค์กร | 100 | -| สิทธิ์องค์กร | 100 | -| **นักพัฒนาและแพลตฟอร์ม** | | -| Webhook | 10 | -| การเก็บ log การตรวจสอบ | 14 วัน | -| สมาชิกเทนแนนต์ | 20 | - -### ผลิต (Production) \{#production} - -เทนแนนต์ production คือที่ที่ผู้ใช้ปลายทางเข้าถึงแอปจริง และคุณอาจต้องมี [การสมัครสมาชิกแบบชำระเงิน](https://logto.io/pricing) คุณสามารถสมัครแผน Free หรือ Pro เพื่อสร้างเทนแนนต์ production ได้ หากสมัครแผน Free จะสามารถสร้างเทนแนนต์ได้สูงสุด 10 เท่านั้น +### การพัฒนา (Development) \{#development} + +เทนแนนต์สำหรับการพัฒนา (dev tenant) มีไว้สำหรับการทดสอบเป็นหลัก และไม่ควรใช้ในสภาพแวดล้อม production เทนแนนต์เหล่านี้สามารถเข้าถึงฟีเจอร์พรีเมียมและฟีเจอร์ที่ต้องชำระเงินในแผนแบบเสียค่าใช้จ่ายได้ฟรีโดยไม่ต้องสมัครสมาชิก + +อย่างไรก็ตาม มีข้อจำกัดบางประการสำหรับ dev tenant: + +- Dev tenant จะลบผู้ใช้ที่มีอายุเกิน 90 วันโดยอัตโนมัติ ดู [นโยบายการเก็บข้อมูลของ Dev tenant](./dev-tenant-data-retention) สำหรับรายละเอียด +- จะมีแบนเนอร์แสดงระหว่างประสบการณ์การลงชื่อเข้าใช้ เพื่อระบุว่าเทนแนนต์นี้อยู่ในโหมดพัฒนา +- Dev tenant อาจมีข้อจำกัดโควต้าสำหรับฟีเจอร์บางอย่าง โดยจะอธิบายไว้ในหน้ารายละเอียดฟีเจอร์นั้น ๆ หากมี สำหรับรายการข้อจำกัด Dev plan ทั้งหมด โปรดดูที่หน้า [ขีดจำกัดของระบบ](./system-limit) +- Logto อาจอัปเดตโควต้าของ dev tenant และจะพยายามแจ้งให้คุณทราบล่วงหน้า + +### การผลิต (Production) \{#production} + +Production tenant คือที่ที่ผู้ใช้ปลายทางเข้าถึงแอปจริง และคุณอาจต้องมี [การสมัครสมาชิกแบบชำระเงิน](https://logto.io/pricing) คุณสามารถสมัครแผน Free หรือ Pro เพื่อสร้าง production tenant ได้ หากสมัครแผน Free จะสามารถสร้างได้สูงสุด 10 tenants ## เปิดใช้งาน MFA \{#enable-mfa} -เพิ่มความปลอดภัยให้ workspace ของคุณโดยกำหนดให้สมาชิกทุกคนในเทนแนนต์ Logto Pro / Enterprise ต้องใช้การยืนยันตัวตนหลายปัจจัย (MFA) +เพิ่มความปลอดภัยให้ workspace ของคุณด้วยการบังคับใช้การยืนยันตัวตนหลายปัจจัย (MFA) สำหรับสมาชิกทุกคนใน Logto Pro / Enterprise tenant ของคุณ -เนื่องจากยังไม่สามารถเปิดใช้งานด้วยตนเองได้ โปรด [ติดต่อเรา](https://logto.io/contact) เพื่อเปิดใช้งานฟีเจอร์นี้ +เนื่องจากยังไม่สามารถเปิดใช้งานด้วยตนเองได้ โปรด [ติดต่อเรา](https://logto.io/contact) เพื่อเปิดฟีเจอร์นี้ ## เปิดใช้งาน Enterprise SSO \{#enable-enterprise-sso} @@ -120,13 +94,13 @@ Logto Cloud รองรับการเชื่อมต่อ Single Sign-O ผู้ดูแลระบบสามารถ [เชิญสมาชิกเพิ่มเติม](/logto-cloud/tenant-member-management) มายังเทนแนนต์นี้ได้ -หากมี **ผู้ดูแลระบบ** (บทบาท) อย่างน้อยหนึ่งคน หรือหากคุณเป็น **ผู้ร่วมมือ** (บทบาท) คุณสามารถเลือกออกจากเทนแนนต์ได้ หลังจากออกแล้ว ทรัพยากรทั้งหมดในเทนแนนต์จะยังคงอยู่ แต่คุณจะไม่สามารถเข้าถึงได้อีก +หากมี **ผู้ดูแลระบบ (admin)** คนอื่นอย่างน้อย 1 คน หรือคุณเป็น **ผู้ร่วมมือ (collaborator)** คุณสามารถเลือกออกจากเทนแนนต์ได้ หลังจากออกแล้ว ทรัพยากรทั้งหมดในเทนแนนต์จะยังคงอยู่ แต่คุณจะไม่สามารถเข้าถึงได้อีก -หากคุณเป็นผู้ดูแลระบบคนสุดท้าย คุณต้องแต่งตั้งผู้ร่วมมือคนอื่นเป็นผู้ดูแลระบบก่อนจึงจะออกได้ +หากคุณเป็นผู้ดูแลระบบคนสุดท้าย คุณต้องแต่งตั้ง collaborator คนอื่นเป็น admin ก่อนจึงจะออกได้ ## ลบเทนแนนต์ \{#delete-tenant} -[ผู้ดูแลระบบ](/logto-cloud/tenant-member-management#invite-collaborators) สามารถลบเทนแนนต์ Logto ได้ การลบเทนแนนต์จะลบข้อมูลผู้ใช้และการตั้งค่าทั้งหมดที่เกี่ยวข้องอย่างถาวร การดำเนินการนี้ไม่สามารถย้อนกลับได้ Logto จะขอให้คุณกรอกชื่อเทนแนนต์เพื่อยืนยันและช่วยป้องกันการลบโดยไม่ได้ตั้งใจ +[ผู้ดูแลระบบ](/logto-cloud/tenant-member-management#invite-collaborators) สามารถลบ Logto tenant ได้ การลบเทนแนนต์จะลบข้อมูลผู้ใช้และการตั้งค่าทั้งหมดที่เกี่ยวข้องอย่างถาวร การดำเนินการนี้ไม่สามารถย้อนกลับได้ Logto จะขอให้คุณกรอกชื่อเทนแนนต์เพื่อยืนยันและช่วยป้องกันการลบโดยไม่ตั้งใจ หากต้องการความช่วยเหลือ โปรด [ติดต่อเรา](https://logto.io/contact) ทางอีเมล @@ -135,15 +109,15 @@ Logto Cloud รองรับการเชื่อมต่อ Single Sign-O
-### จะย้ายข้อมูลระหว่างเทนแนนต์ Logto หรือระหว่าง Cloud กับ OSS หรือส่งออกข้อมูลผู้ใช้ทั้งหมดได้อย่างไร? \{#how-to-migrate-between-logto-tenants-or-between-cloud-and-oss-or-export-all-user-data} +### วิธีการย้ายข้อมูลระหว่าง Logto tenants หรือระหว่าง Cloud กับ OSS หรือส่งออกข้อมูลผู้ใช้ทั้งหมด? \{#how-to-migrate-between-logto-tenants-or-between-cloud-and-oss-or-export-all-user-data} -ขณะนี้คุณสามารถแปลงเทนแนนต์ **Development** ของคุณเป็นเทนแนนต์ **Production** แบบชำระเงินได้ด้วยตนเอง [ดูรายละเอียด](#tenant-types-dev-vs-prod) +ขณะนี้คุณสามารถแปลง **Dev tenant** ของคุณเป็น **Production tenant** แบบเสียค่าใช้จ่ายได้ด้วยตนเอง [ดูรายละเอียด](#tenant-types-dev-vs-prod) -อย่างไรก็ตาม การย้ายข้อมูลด้วยตนเอง (ทั้งการตั้งค่าและข้อมูลผู้ใช้) ระหว่าง Logto Cloud กับเวอร์ชัน OSS ยังไม่รองรับ หากคุณต้องการบริการนี้ โปรด [ติดต่อทีม Logto](https://logto.io/contact) เพื่อพูดคุยทางเลือก +อย่างไรก็ตาม ยังไม่รองรับการย้ายข้อมูล (ทั้งการตั้งค่าและข้อมูลผู้ใช้) ระหว่าง Logto Cloud กับเวอร์ชัน OSS ด้วยตนเอง หากต้องการบริการนี้ โปรด [ติดต่อทีม Logto](https://logto.io/contact) เพื่อพูดคุยทางเลือก -หากคุณวางแผนจะหยุดใช้ Logto Cloud สำหรับโปรเจกต์ Logto สามารถช่วยคุณส่งออกข้อมูลผู้ใช้ทั้งหมดได้ โปรด [ติดต่อเรา](https://logto.io/contact) +หากคุณวางแผนจะหยุดใช้ Logto Cloud สำหรับโปรเจกต์ Logto สามารถช่วยส่งออกข้อมูลผู้ใช้ทั้งหมดได้ โปรด [ติดต่อเรา](https://logto.io/contact)
diff --git a/i18n/th/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/th/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index b2243a202a4..c4b5d99f8d5 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -28,13 +28,13 @@ import Tabs from '@theme/Tabs'; />

-Logto ใช้พอร์ต `3001` สำหรับ core service และพอร์ต `3002` สำหรับ Admin Console แบบโต้ตอบโดยค่าเริ่มต้น +Logto ใช้พอร์ต `3001` สำหรับบริการหลัก และพอร์ต `3002` สำหรับ Admin Console แบบโต้ตอบโดยปริยาย -เพื่อดำเนินการต่อกับ Logto ของคุณ ให้กด Ctrl (หรือ Cmd) แล้วคลิกลิงก์ที่ขึ้นต้นด้วย `https://3002-...` ขอให้สนุก! +เพื่อดำเนินการใช้งาน Logto ต่อ ให้กด Ctrl (หรือ Cmd) และคลิกลิงก์ที่ขึ้นต้นด้วย `https://3002-...` ขอให้สนุก! ## Local \{#local} -ข้อกำหนดขั้นต่ำของฮาร์ดแวร์ที่แนะนำสำหรับการโฮสต์ Logto ได้แก่: +ข้อกำหนดขั้นต่ำของฮาร์ดแวร์ที่แนะนำสำหรับการโฮสต์ Logto คือ: - **vCPU**: 2 - **หน่วยความจำ**: 8 GiB @@ -47,7 +47,7 @@ Logto ใช้พอร์ต `3001` สำหรับ core service และ Docker Compose CLI มักจะมาพร้อมกับ [Docker Desktop](https://www.docker.com/products/docker-desktop) :::caution -ห้ามใช้คำสั่ง docker compose ของเราใน production! เนื่องจากปัจจุบันเรามีฐานข้อมูล Postgres ที่ฝังมากับ Logto app ใน `docker-compose.yml` ทุกครั้งที่คุณรันคำสั่งนี้ใหม่ จะมีการสร้างอินสแตนซ์ฐานข้อมูลใหม่ และข้อมูลเดิมทั้งหมดจะหายไป +ห้ามใช้คำสั่ง docker compose ของเราใน production! เนื่องจากขณะนี้เรามีฐานข้อมูล Postgres ที่รวมมากับแอป Logto ใน `docker-compose.yml` ทุกครั้งที่คุณรันคำสั่งนี้ใหม่ จะมีการสร้างอินสแตนซ์ฐานข้อมูลใหม่ และข้อมูลเดิมทั้งหมดจะหายไป ::: ```bash @@ -137,7 +137,7 @@ docker run \ - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -เวอร์ชันที่สูงกว่ามักใช้งานได้แต่ไม่รับประกัน +เวอร์ชันที่สูงกว่านี้มักจะใช้ได้ แต่ไม่รับประกัน เราแนะนำให้ใช้ฐานข้อมูลใหม่ว่างเปล่าที่เตรียมไว้สำหรับ Logto โดยเฉพาะ แม้จะไม่ใช่ข้อบังคับก็ตาม @@ -162,13 +162,13 @@ Admin app is running at http://localhost:3002 Admin app is running at https://your-admin-domain-url ``` -ไปที่ `http://localhost:3002/` เพื่อดำเนินการต่อกับ Logto ของคุณ ขอให้สนุก! +ไปที่ `http://localhost:3002/` เพื่อดำเนินการใช้งาน Logto ต่อ ขอให้สนุก!
-### การใช้ URL ทางเลือกสำหรับการดาวน์โหลด \{#using-an-alternative-url-for-downloading} +### การใช้ URL ทางเลือกสำหรับดาวน์โหลด \{#using-an-alternative-url-for-downloading} @@ -178,7 +178,7 @@ Admin app is running at https://your-admin-domain-url npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -โปรดสังเกตว่าต้องมี `--` เพิ่มเติมสำหรับ NPM เพื่อส่งอาร์กิวเมนต์ +โปรดสังเกตว่าต้องมี `--` เพิ่มเติมเพื่อให้ NPM ส่งอาร์กิวเมนต์ไปยังสคริปต์
@@ -190,7 +190,7 @@ npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/relea -Logto ใช้ตัวแปรสภาพแวดล้อมสำหรับการตั้งค่า พร้อมรองรับไฟล์ `.env` ดู [การตั้งค่า](/concepts/core-service/configuration) สำหรับรายละเอียดการใช้งานและรายการตัวแปรทั้งหมด +Logto ใช้ตัวแปรสภาพแวดล้อมสำหรับการตั้งค่า พร้อมรองรับไฟล์ `.env` ดู [การตั้งค่า](/concepts/core-service/configuration) สำหรับวิธีใช้งานโดยละเอียดและรายการตัวแปรทั้งหมด @@ -207,7 +207,7 @@ _ดู [Core service](/concepts/core-service) หากคุณต้องก label: 'Logto Cloud', href: 'https://cloud.logto.io', description: - 'บริการคลาวด์ราคาประหยัดพร้อม dev tenant ฟรีสำหรับการผสานการยืนยันตัวตนอย่างง่าย', + 'บริการคลาวด์ราคาประหยัดพร้อม dev tenant ฟรี สำหรับการผสานการยืนยันตัวตนอย่างง่าย', customProps: { icon: , }, @@ -216,7 +216,7 @@ _ดู [Core service](/concepts/core-service) หากคุณต้องก type: 'link', label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', - description: 'ทางเลือก Heroku/Netlify แบบ self-host สำหรับจัดการแอปและฐานข้อมูลได้ง่าย', + description: 'ทางเลือก Heroku/Netlify แบบ self-host สำหรับจัดการแอปและฐานข้อมูลอย่างง่าย', customProps: { icon: , }, @@ -243,7 +243,8 @@ _ดู [Core service](/concepts/core-service) หากคุณต้องก type: 'link', label: 'Elestio', href: 'https://elest.io/open-source/logto', - description: 'แพลตฟอร์ม DevOps แบบจัดการเต็มรูปแบบสำหรับดีพลอยโค้ดและซอฟต์แวร์โอเพ่นซอร์ส', + description: + 'แพลตฟอร์ม DevOps แบบจัดการเต็มรูปแบบสำหรับดีพลอยโค้ดและซอฟต์แวร์โอเพ่นซอร์สของคุณ', customProps: { icon: , }, @@ -261,7 +262,7 @@ _ดู [Core service](/concepts/core-service) หากคุณต้องก type: 'link', label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', - description: 'ช่วยให้นักพัฒนาดีพลอย ขยาย และมอนิเตอร์แอปได้ง่าย', + description: 'ช่วยให้นักพัฒนาสามารถดีพลอย ขยาย และมอนิเตอร์แอปได้อย่างง่ายดาย', customProps: { icon: , }, @@ -273,8 +274,12 @@ _ดู [Core service](/concepts/core-service) หากคุณต้องก ## สร้างบัญชี \{#create-an-account} -เมื่อคุณโฮสต์ Logto บนเซิร์ฟเวอร์ของคุณสำเร็จแล้ว ให้คลิก "Create account" บนหน้า welcome โปรดทราบว่า Logto เวอร์ชันโอเพ่นซอร์สอนุญาตให้สร้างบัญชีได้เพียงหนึ่งบัญชีในครั้งแรก และไม่รองรับหลายบัญชี กระบวนการสร้างบัญชีจะใช้เพียงชื่อผู้ใช้และรหัสผ่านเท่านั้น +เมื่อคุณโฮสต์ Logto บนเซิร์ฟเวอร์ของคุณสำเร็จแล้ว ให้คลิก "Create account" บนหน้า welcome โปรดทราบว่าเวอร์ชันโอเพ่นซอร์สของ Logto อนุญาตให้สร้างบัญชีได้เพียงหนึ่งบัญชีในครั้งแรกเท่านั้น และไม่รองรับหลายบัญชี กระบวนการสร้างบัญชีจะใช้เพียงชื่อผู้ใช้และรหัสผ่าน + +:::tip +Logto OSS (self-hosted) ไม่รองรับการตั้งค่าผู้ดูแลระบบหลายคน หากต้องการทำงานร่วมกันในทีม หรือโปรเจกต์ที่ต้องการผู้ดูแลระบบหลายคน แนะนำให้ใช้ [Logto Cloud](https://cloud.logto.io) ซึ่งมีฟีเจอร์จัดการทีมครบถ้วน +::: ## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} -การพัฒนา HTTPS ในเครื่อง +การจัดการกับการพัฒนา HTTPS ในเครื่อง diff --git a/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index 8a516ae7672..b6307637de4 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot คือเฟรมเวิร์กเว็บสำหรับ Java ที่ช่วยให้นักพัฒนาสร้างแอปพลิเคชันเซิร์ฟเวอร์ที่ปลอดภัย รวดเร็ว และขยายขนาดได้ด้วยภาษา Java + description: Spring Boot เป็นเฟรมเวิร์กเว็บสำหรับ Java ที่ช่วยให้นักพัฒนาสร้างแอปพลิเคชันเซิร์ฟเวอร์ที่ปลอดภัย รวดเร็ว และขยายขนาดได้ด้วยภาษาโปรแกรม Java logoFilename: 'spring-boot.svg' --- @@ -16,20 +16,20 @@ import ScopesAndClaims from './_scopes-and-claims.mdx'; # เพิ่มการยืนยันตัวตนให้กับแอป Java Spring Boot ของคุณ (Add authentication to your Java Spring Boot application) -คู่มือนี้จะแสดงวิธีผสาน Logto เข้ากับแอป Java Spring Boot ของคุณ +คู่มือนี้จะแสดงวิธีการผสาน Logto เข้ากับแอปพลิเคชัน Java Spring Boot ของคุณ :::tip -- คุณสามารถดูตัวอย่างโค้ดสำหรับคู่มือนี้ได้ที่ [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) ใน github ของเรา +- คุณสามารถดูตัวอย่างโค้ดสำหรับคู่มือนี้ได้ที่ [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) ใน github repository ของเรา - ไม่จำเป็นต้องใช้ SDK อย่างเป็นทางการในการผสาน Logto กับแอป Java Spring Boot ของคุณ เราจะใช้ไลบรารี [Spring Security](https://spring.io/projects/spring-security) และ [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) เพื่อจัดการโฟลว์การยืนยันตัวตน OIDC กับ Logto ::: ## ข้อกำหนดเบื้องต้น \{#prerequisites} -- มีบัญชี [Logto Cloud](https://cloud.logto.io) หรือ [Logto ที่โฮสต์เอง](/introduction/set-up-logto-oss) -- ตัวอย่างโค้ดของเราสร้างขึ้นโดยใช้ Spring Boot [securing web starter](https://spring.io/guides/gs/securing-web) ทำตามคำแนะนำเพื่อสร้างแอปเว็บใหม่หากคุณยังไม่มี -- ในคู่มือนี้ เราจะใช้ไลบรารี [Spring Security](https://spring.io/projects/spring-security) และ [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) เพื่อจัดการโฟลว์การยืนยันตัวตน OIDC กับ Logto โปรดอ่านเอกสารอย่างเป็นทางการเพื่อเข้าใจแนวคิดต่าง ๆ +- บัญชี [Logto Cloud](https://cloud.logto.io) หรือ [Logto ที่ติดตั้งเอง](/introduction/set-up-logto-oss) +- ตัวอย่างโค้ดของเราสร้างขึ้นโดยใช้ Spring Boot [securing web starter](https://spring.io/guides/gs/securing-web) หากคุณยังไม่มีแอปพลิเคชันเว็บใหม่ ให้ทำตามคำแนะนำเพื่อบูตแอป +- ในคู่มือนี้ เราจะใช้ไลบรารี [Spring Security](https://spring.io/projects/spring-security) และ [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) เพื่อจัดการโฟลว์ OIDC authentication กับ Logto โปรดศึกษาคู่มืออย่างเป็นทางการเพื่อเข้าใจแนวคิด ## ตั้งค่าแอป Java Spring Boot ของคุณ \{#configure-your-java-spring-boot-application} @@ -87,22 +87,32 @@ spring.security.oauth2.client.provider.logto.authorization-uri={{LOGTO_ENDPOINT} spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc/jwks ``` -## การนำไปใช้ \{#implementation} +## การนำไปใช้ (Implementation) \{#implementation} เพื่อเปลี่ยนเส้นทางผู้ใช้กลับมายังแอปของคุณหลังจากลงชื่อเข้าใช้ คุณต้องตั้งค่า redirect URI โดยใช้ property `client.registration.logto.redirect-uri` ในขั้นตอนก่อนหน้า - + ### สร้าง WebSecurityConfig \{#implement-the-websecurityconfig} #### สร้างคลาสใหม่ชื่อ `WebSecurityConfig` ในโปรเจกต์ของคุณ \{#create-a-new-class-websecurityconfig-in-your-project} -คลาส `WebSecurityConfig` จะใช้สำหรับกำหนดค่าความปลอดภัยของแอปของคุณ เป็นคลาสสำคัญที่จัดการโฟลว์การยืนยันตัวตนและการอนุญาต โปรดดู [Spring Security documentation](https://spring.io/guides/topicals/spring-security-architecture) สำหรับรายละเอียดเพิ่มเติม +คลาส `WebSecurityConfig` จะใช้สำหรับตั้งค่าความปลอดภัยของแอปพลิเคชัน เป็นคลาสสำคัญที่จัดการโฟลว์การยืนยันตัวตนและการอนุญาต โปรดดู [Spring Security documentation](https://spring.io/guides/topicals/spring-security-architecture) สำหรับรายละเอียดเพิ่มเติม ```java title="WebSecurityConfig.java" -// โค้ดเหมือนเดิม +package com.example.securingweb; + +import org.springframework.context.annotation.Configuration; +import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; + +@Configuration +@EnableWebSecurity + +public class WebSecurityConfig { + // ... +} ``` #### สร้าง bean `idTokenDecoderFactory` \{#create-a-idtokendecoderfactory-bean} @@ -110,7 +120,22 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc จำเป็นต้องทำเพราะ Logto ใช้ `ES384` เป็นอัลกอริทึมเริ่มต้น เราต้องเขียนทับ `OidcIdTokenDecoderFactory` เริ่มต้นเพื่อใช้อัลกอริทึมเดียวกัน ```java title="WebSecurityConfig.java" -// โค้ดเหมือนเดิม +import org.springframework.context.annotation.Bean; +import org.springframework.security.oauth2.client.oidc.authentication.OidcIdTokenDecoderFactory; +import org.springframework.security.oauth2.client.registration.ClientRegistration; +import org.springframework.security.oauth2.jose.jws.SignatureAlgorithm; +import org.springframework.security.oauth2.jwt.JwtDecoderFactory; + +public class WebSecurityConfig { + // ... + + @Bean + public JwtDecoderFactory idTokenDecoderFactory() { + OidcIdTokenDecoderFactory idTokenDecoderFactory = new OidcIdTokenDecoderFactory(); + idTokenDecoderFactory.setJwsAlgorithmResolver(clientRegistration -> SignatureAlgorithm.ES384); + return idTokenDecoderFactory; + } +} ``` #### สร้างคลาส LoginSuccessHandler เพื่อจัดการเหตุการณ์เข้าสู่ระบบสำเร็จ \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} @@ -118,7 +143,24 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc เราจะเปลี่ยนเส้นทางผู้ใช้ไปยังหน้า `/user` หลังจากเข้าสู่ระบบสำเร็จ ```java title="CustomSuccessHandler.java" -// โค้ดเหมือนเดิม +package com.example.securingweb; + +import java.io.IOException; + +import org.springframework.security.core.Authentication; +import org.springframework.security.web.authentication.AuthenticationSuccessHandler; + +import jakarta.servlet.ServletException; +import jakarta.servlet.http.HttpServletRequest; +import jakarta.servlet.http.HttpServletResponse; + +public class CustomSuccessHandler implements AuthenticationSuccessHandler { + @Override + public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, + Authentication authentication) throws IOException, ServletException { + response.sendRedirect("/user"); + } +} ``` #### สร้างคลาส LogoutSuccessHandler เพื่อจัดการเหตุการณ์ออกจากระบบสำเร็จ \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} @@ -126,79 +168,171 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc ล้าง session และเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าแรก ```java title="CustomLogoutHandler.java" -// โค้ดเหมือนเดิม +package com.example.securingweb; + +import java.io.IOException; + +import org.springframework.security.core.Authentication; +import org.springframework.security.web.authentication.logout.LogoutSuccessHandler; + +import jakarta.servlet.ServletException; +import jakarta.servlet.http.HttpServletRequest; +import jakarta.servlet.http.HttpServletResponse; +import jakarta.servlet.http.HttpSession; + +public class CustomLogoutHandler implements LogoutSuccessHandler { + @Override + public void onLogoutSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) + throws IOException, ServletException { + HttpSession session = request.getSession(); + + if (session != null) { + session.invalidate(); + } + + response.sendRedirect("/home"); + } +} ``` #### อัปเดตคลาส `WebSecurityConfig` ด้วย `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} [securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) คือชุดของฟิลเตอร์ที่รับผิดชอบในการประมวลผล request และ response ที่เข้ามา -เราจะกำหนดค่า `securityFilterChain` เพื่ออนุญาตเข้าถึงหน้าแรก และต้องยืนยันตัวตนสำหรับ request อื่น ๆ ทั้งหมด ใช้ `CustomSuccessHandler` และ `CustomLogoutHandler` เพื่อจัดการเหตุการณ์เข้าสู่ระบบและออกจากระบบ +เราจะตั้งค่า `securityFilterChain` เพื่ออนุญาตเข้าถึงหน้าแรก และต้องยืนยันตัวตนสำหรับ request อื่น ๆ ทั้งหมด ใช้ `CustomSuccessHandler` และ `CustomLogoutHandler` เพื่อจัดการเหตุการณ์เข้าสู่ระบบและออกจากระบบ ```java title="WebSecurityConfig.java" -// โค้ดเหมือนเดิม +import org.springframework.context.annotation.Bean; +import org.springframework.security.config.annotation.web.builders.HttpSecurity; +import org.springframework.security.web.DefaultSecurityFilterChain; + +public class WebSecurityConfig { + // ... + + @Bean + public DefaultSecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { + http + .authorizeRequests(authorizeRequests -> + authorizeRequests + .antMatchers("/", "/home").permitAll() // อนุญาตเข้าถึงหน้าแรก + .anyRequest().authenticated() // คำขออื่น ๆ ต้องยืนยันตัวตน + ) + .oauth2Login(oauth2Login -> + oauth2Login + .successHandler(new CustomSuccessHandler()) + ) + .logout(logout -> + logout + .logoutSuccessHandler(new CustomLogoutHandler()) + ); + return http.build(); + } +} ``` -### สร้างหน้าแรก \{#create-a-home-page} +### สร้างหน้าแรก (home page) \{#create-a-home-page} -(คุณสามารถข้ามขั้นตอนนี้ได้หากมีหน้าแรกอยู่แล้วในโปรเจกต์ของคุณ) +(คุณสามารถข้ามขั้นตอนนี้ได้หากมีหน้าแรกในโปรเจกต์ของคุณแล้ว) ```java title="HomeController.java" -// โค้ดเหมือนเดิม +package com.example.securingweb; + +import java.security.Principal; + +import org.springframework.stereotype.Controller; +import org.springframework.web.bind.annotation.GetMapping; + +@Controller +public class HomeController { + @GetMapping({ "/", "/home" }) + public String home(Principal principal) { + return principal != null ? "redirect:/user" : "home"; + } +} ``` คอนโทรลเลอร์นี้จะเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าผู้ใช้หากผู้ใช้ได้รับการยืนยันตัวตนแล้ว มิฉะนั้นจะแสดงหน้าแรก เพิ่มลิงก์เข้าสู่ระบบในหน้าแรก ```html title="resources/templates/home.html" -

ยินดีต้อนรับ!

+

Welcome!

-

เข้าสู่ระบบด้วย Logto

+

Login with Logto

``` -### สร้างหน้าผู้ใช้ \{#create-a-user-page} +### สร้างหน้าผู้ใช้ (user page) \{#create-a-user-page} สร้างคอนโทรลเลอร์ใหม่เพื่อจัดการหน้าผู้ใช้: ```java title="UserController.java" -// โค้ดเหมือนเดิม +package com.example.securingweb; + +import java.security.Principal; +import java.util.Map; + +import org.springframework.security.oauth2.client.authentication.OAuth2AuthenticationToken; +import org.springframework.security.oauth2.core.user.OAuth2User; +import org.springframework.stereotype.Controller; +import org.springframework.ui.Model; +import org.springframework.web.bind.annotation.GetMapping; +import org.springframework.web.bind.annotation.RequestMapping; + +@Controller +@RequestMapping("/user") +public class UserController { + + @GetMapping + public String user(Model model, Principal principal) { + if (principal instanceof OAuth2AuthenticationToken) { + OAuth2AuthenticationToken token = (OAuth2AuthenticationToken) principal; + OAuth2User oauth2User = token.getPrincipal(); + Map attributes = oauth2User.getAttributes(); + + model.addAttribute("username", attributes.get("username")); + model.addAttribute("email", attributes.get("email")); + model.addAttribute("sub", attributes.get("sub")); + } + + return "user"; + } +} ``` -เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว เราจะดึงข้อมูล `OAuth2User` จาก principal ที่ได้รับการยืนยัน โปรดดู [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) และ [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) สำหรับรายละเอียดเพิ่มเติม +เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว เราจะดึงข้อมูล `OAuth2User` จาก principal ที่ยืนยันตัวตนแล้ว โปรดดู [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) และ [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) สำหรับรายละเอียดเพิ่มเติม -อ่านข้อมูลผู้ใช้และส่งไปยังเทมเพลต `user.html` +อ่านข้อมูลผู้ใช้และส่งต่อไปยังเทมเพลต `user.html` ```html title="resources/templates/user.html" -

รายละเอียดผู้ใช้

+

User Details

-

ชื่อ:
-
อีเมล:
-
รหัส:
+
name:
+
email:
+
id:

- +
``` -#### ขอข้อมูลการอ้างสิทธิ์เพิ่มเติม \{#request-additional-claims} +#### ขอข้อมูล claims เพิ่มเติม \{#request-additional-claims} -หากต้องการดึงข้อมูลผู้ใช้เพิ่มเติม คุณสามารถเพิ่ม scope เพิ่มเติมในไฟล์ `application.properties` ตัวอย่างเช่น หากต้องการขอ scope `email`, `phone` และ `urn:logto:scope:organizations` ให้เพิ่มบรรทัดต่อไปนี้ในไฟล์ `application.properties`: +หากต้องการดึงข้อมูลผู้ใช้เพิ่มเติม คุณสามารถเพิ่ม scopes เพิ่มเติมในไฟล์ `application.properties` ตัวอย่างเช่น หากต้องการขอ scope `email`, `phone` และ `urn:logto:scope:organizations` ให้เพิ่มบรรทัดนี้ในไฟล์ `application.properties`: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -จากนั้นคุณสามารถเข้าถึงข้อมูลการอ้างสิทธิ์เพิ่มเติมในอ็อบเจกต์ `OAuth2User` +จากนั้นคุณสามารถเข้าถึง claims เพิ่มเติมในอ็อบเจกต์ `OAuth2User` ### รันและทดสอบแอปพลิเคชัน \{#run-and-test-the-application} @@ -206,7 +340,7 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc - คุณจะเห็นหน้าแรกพร้อมลิงก์เข้าสู่ระบบ - คลิกที่ลิงก์เพื่อเข้าสู่ระบบด้วย Logto -- หลังจากยืนยันตัวตนสำเร็จ คุณจะถูกเปลี่ยนเส้นทางไปยังหน้าผู้ใช้พร้อมรายละเอียดของคุณ +- หลังจากยืนยันตัวตนสำเร็จ คุณจะถูกเปลี่ยนเส้นทางไปยังหน้าผู้ใช้พร้อมรายละเอียดผู้ใช้ของคุณ - คลิกปุ่มออกจากระบบเพื่อออกจากระบบ คุณจะถูกเปลี่ยนเส้นทางกลับไปยังหน้าแรก ## ขอบเขต (Scopes) และ การอ้างสิทธิ์ (Claims) \{#scopes-and-claims} diff --git a/i18n/th/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/th/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index d0d250a06ab..985f4b28e41 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -8,49 +8,49 @@ import Availability from '@components/Availability'; -ชุดโทเค็นของบุคคลที่สาม (หรือที่เรียกว่า federated token set) คือประเภทของความลับที่จัดเก็บใน [secret vault](/secret-vault) ของ Logto ใช้สำหรับจัดการโทเค็นการเข้าถึง (Access token) และโทเค็นรีเฟรช (Refresh token) ที่ออกโดยผู้ให้บริการข้อมูลระบุตัวตน (IdP) บุคคลที่สามอย่างปลอดภัย เมื่อผู้ใช้ยืนยันตัวตนผ่านตัวเชื่อมต่อโซเชียลหรือ SSO สำหรับองค์กร Logto จะจัดเก็บโทเค็นที่ออกให้ใน vault โทเค็นเหล่านี้สามารถเรียกใช้เพื่อเข้าถึง API ของบุคคลที่สามในนามของผู้ใช้โดยไม่ต้องยืนยันตัวตนซ้ำ +ชุดโทเค็นของบุคคลที่สาม (หรือที่เรียกว่า federated token set) คือประเภทของความลับที่จัดเก็บไว้ใน [secret vault](/secret-vault) ของ Logto ใช้สำหรับจัดการโทเค็นการเข้าถึง (Access token) และโทเค็นรีเฟรช (Refresh token) ที่ออกโดยผู้ให้บริการข้อมูลระบุตัวตน (IdP) บุคคลที่สามอย่างปลอดภัย เมื่อผู้ใช้ทำการยืนยันตัวตนผ่านตัวเชื่อมต่อโซเชียลหรือ SSO สำหรับองค์กร Logto จะจัดเก็บโทเค็นที่ได้รับไว้ใน vault โทเค็นเหล่านี้สามารถเรียกใช้ภายหลังเพื่อเข้าถึง API ของบุคคลที่สามในนามของผู้ใช้ โดยไม่ต้องยืนยันตัวตนซ้ำ ## กรณีการใช้งานทั่วไป \{#common-use-cases} -ความสามารถนี้จำเป็นสำหรับแอปพลิเคชันสมัยใหม่ เช่น เอเจนต์ AI แพลตฟอร์ม SaaS เครื่องมือเพิ่มประสิทธิภาพ และแอปสำหรับลูกค้าที่ต้องโต้ตอบกับบริการของบุคคลที่สามในนามของผู้ใช้ ตัวอย่างการใช้งานจริง: +ความสามารถนี้จำเป็นสำหรับแอปพลิเคชันสมัยใหม่ เช่น เอเจนต์ AI แพลตฟอร์ม SaaS เครื่องมือเพิ่มประสิทธิภาพ และแอปพลิเคชันลูกค้าที่ต้องโต้ตอบกับบริการบุคคลที่สามในนามของผู้ใช้ ตัวอย่างเช่น: -**📅 แอปจัดการปฏิทิน**: หลังจากผู้ใช้ลงชื่อเข้าใช้ด้วย Google แอป productivity ของคุณสามารถซิงค์กิจกรรมในปฏิทิน สร้างการประชุมใหม่ และส่งคำเชิญโดยไม่ต้องขอให้ผู้ใช้ยืนยันตัวตนซ้ำ +**📅 แอปจัดการปฏิทิน**: หลังจากผู้ใช้ลงชื่อเข้าใช้ด้วย Google แอป productivity ของคุณสามารถซิงค์กิจกรรมในปฏิทิน สร้างการประชุมใหม่ และส่งคำเชิญโดยอัตโนมัติ โดยไม่ต้องขอให้ผู้ใช้ยืนยันตัวตนซ้ำ **🤖 ผู้ช่วย AI**: เอเจนต์ AI สามารถเข้าถึง repository ของผู้ใช้ใน GitHub เพื่อวิเคราะห์โค้ด สร้าง pull request หรือจัดการ issue ทั้งหมดนี้ด้วยความยินยอมเพียงครั้งเดียวของผู้ใช้ระหว่างการลงชื่อเข้าใช้หรือเชื่อมโยงบัญชี -**📊 แดชบอร์ดวิเคราะห์ข้อมูล**: แพลตฟอร์ม SaaS สามารถดึงข้อมูลจากบัญชีโซเชียลมีเดียที่ผู้ใช้เชื่อมต่อ (Facebook, LinkedIn) เพื่อสร้าง insight และรายงานโดยไม่ขัดจังหวะการทำงานของผู้ใช้ด้วยการขอเข้าสู่ระบบซ้ำ +**📊 แดชบอร์ดวิเคราะห์ข้อมูล**: แพลตฟอร์ม SaaS สามารถดึงข้อมูลจากบัญชีโซเชียลมีเดียที่ผู้ใช้เชื่อมต่อ (Facebook, LinkedIn) เพื่อสร้าง insight และรายงาน โดยไม่รบกวนการทำงานของผู้ใช้ด้วยการขอเข้าสู่ระบบซ้ำ ## เปิดใช้งานการจัดเก็บโทเค็นของบุคคลที่สาม \{#enable-third-party-token-storage} ### ตัวเชื่อมต่อโซเชียล \{#social-connectors} -ฟีเจอร์นี้ใช้ได้กับ [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors) ที่รองรับการจัดเก็บโทเค็น โทเค็นของบุคคลที่สามจะถูกจัดเก็บระหว่าง [การลงชื่อเข้าใช้โซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in), [การเชื่อมโยงบัญชีโซเชียล](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection), และ [เมื่อรีเฟรชโทเค็นเพื่อเข้าถึง API ของบุคคลที่สาม](/secret-vault/federated-token-set#reauthentication-and-token-renewal) ตัวเชื่อมต่อที่รองรับในปัจจุบัน ได้แก่: [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [Standard OAuth 2.0](/integrations/oauth2), และ [Standard OIDC](/integrations/oidc) โดยจะทยอยรองรับตัวเชื่อมต่ออื่นเพิ่มเติม +ฟีเจอร์นี้มีให้สำหรับ [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors) ที่รองรับการจัดเก็บโทเค็น โทเค็นของบุคคลที่สามจะถูกจัดเก็บระหว่าง [การลงชื่อเข้าใช้โซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in), [การเชื่อมโยงบัญชีโซเชียล](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) และ [เมื่อมีการต่ออายุโทเค็นเพื่อเข้าถึง API ของบุคคลที่สาม](/secret-vault/federated-token-set#reauthentication-and-token-renewal) ตัวเชื่อมต่อที่รองรับในปัจจุบัน ได้แก่: [GitHub](/integrations/github), [Google](/integrations/google), [Facebook](/integrations/facebook), [Standard OAuth 2.0](/integrations/oauth2), และ [Standard OIDC](/integrations/oidc) โดยจะมีการเพิ่มการรองรับตัวเชื่อมต่ออื่น ๆ ในอนาคต 1. ไปที่ Console > Connectors > Social Connectors -2. เลือกตัวเชื่อมต่อโซเชียลที่ต้องการเปิดใช้งานการจัดเก็บโทเค็นของบุคคลที่สาม -3. ทำตามคู่มือการตั้งค่าเพื่อกำหนดค่าตัวเชื่อมต่อ รวมถึงเพิ่มขอบเขต (scope) ที่จำเป็นสำหรับเข้าถึง API ของบุคคลที่สาม +2. เลือกตัวเชื่อมต่อโซเชียลที่คุณต้องการเปิดใช้งานการจัดเก็บโทเค็นของบุคคลที่สาม +3. ทำตามคู่มือการตั้งค่าเพื่อกำหนดค่าตัวเชื่อมต่อ รวมถึงการเพิ่มขอบเขต (scope) ที่จำเป็นเพื่อเข้าถึง API ของบุคคลที่สาม 4. ในหน้า "Setting" ให้เปิดใช้งานตัวเลือก **Store tokens for persistent API access** -### ตัวเชื่อมต่อ Enterprise SSO \{#enterprise-sso-connectors} +### ตัวเชื่อมต่อ SSO สำหรับองค์กร \{#enterprise-sso-connectors} -การจัดเก็บโทเค็นใช้ได้กับ OIDC [ตัวเชื่อมต่อองค์กร](/connectors/enterprise-connectors) ทุกตัว สามารถจัดเก็บโทเค็นการเข้าถึงและโทเค็นรีเฟรชระหว่าง [Enterprise Single Sign-On](/end-user-flows/enterprise-sso) ตัวเชื่อมต่อที่รองรับในปัจจุบัน ได้แก่: [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc), [Okta](/integrations/okta), และ [OIDC (Enterprise)](/integrations/oidc-sso) +การจัดเก็บโทเค็นสามารถใช้ได้กับ [ตัวเชื่อมต่อองค์กร OIDC](/connectors/enterprise-connectors) ทุกตัว โทเค็นการเข้าถึงและโทเค็นรีเฟรชจะถูกจัดเก็บระหว่าง [การลงชื่อเข้าใช้ SSO สำหรับองค์กร](/end-user-flows/enterprise-sso) ตัวเชื่อมต่อที่รองรับในปัจจุบัน ได้แก่: [Google Workspace](/integrations/google-workspace), [Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc), [Okta](/integrations/okta), และ [OIDC (Enterprise)](/integrations/oidc-sso) 1. ไปที่ Console > Enterprise SSO -2. เลือกตัวเชื่อมต่อ Enterprise SSO ที่ต้องการเปิดใช้งานการจัดเก็บโทเค็นของบุคคลที่สาม -3. ทำตามคู่มือการตั้งค่าเพื่อกำหนดค่าตัวเชื่อมต่อ รวมถึงเพิ่มขอบเขต (scope) ที่จำเป็นสำหรับเข้าถึง API ของบุคคลที่สาม +2. เลือกตัวเชื่อมต่อ SSO สำหรับองค์กรที่คุณต้องการเปิดใช้งานการจัดเก็บโทเค็นของบุคคลที่สาม +3. ทำตามคู่มือการตั้งค่าเพื่อกำหนดค่าตัวเชื่อมต่อ รวมถึงการเพิ่มขอบเขต (scope) ที่จำเป็นเพื่อเข้าถึง API ของบุคคลที่สาม 4. ในแท็บ "SSO Experience" ให้เปิดใช้งานตัวเลือก **Store tokens for persistent API access** -อย่าลืมบันทึกการเปลี่ยนแปลง +อย่าลืมบันทึกการเปลี่ยนแปลงของคุณ ## การจัดเก็บโทเค็น \{#token-storage} -เมื่อเปิดใช้งานการจัดเก็บโทเค็นของบุคคลที่สาม Logto จะจัดเก็บโทเค็นการเข้าถึง (Access token) และโทเค็นรีเฟรช (Refresh token) ที่ออกโดยผู้ให้บริการข้อมูลระบุตัวตน (IdP) บุคคลที่สามโดยอัตโนมัติทุกครั้งที่ผู้ใช้ยืนยันตัวตนผ่านตัวเชื่อมต่อโซเชียลหรือ Enterprise SSO ซึ่งรวมถึง: +เมื่อเปิดใช้งานการจัดเก็บโทเค็นของบุคคลที่สาม Logto จะจัดเก็บโทเค็นการเข้าถึง (Access token) และโทเค็นรีเฟรช (Refresh token) ที่ออกโดยผู้ให้บริการข้อมูลระบุตัวตน (IdP) บุคคลที่สามโดยอัตโนมัติทุกครั้งที่ผู้ใช้ยืนยันตัวตนผ่านตัวเชื่อมต่อโซเชียลหรือ SSO สำหรับองค์กร ซึ่งรวมถึง: -- [การลงชื่อเข้าใช้และสมัครด้วยโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in) -- [การลงชื่อเข้าใช้และสมัครด้วย Enterprise SSO](/end-user-flows/enterprise-sso) +- [การลงชื่อเข้าใช้และสมัครสมาชิกด้วยโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in) +- [การลงชื่อเข้าใช้และสมัครสมาชิกด้วย SSO สำหรับองค์กร](/end-user-flows/enterprise-sso) - [การเชื่อมโยงบัญชีโซเชียลผ่าน Account API](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -โทเค็นที่จัดเก็บจะผูกกับตัวตนโซเชียลหรือ Enterprise SSO ของผู้ใช้ ทำให้สามารถเรียกใช้โทเค็นเพื่อเข้าถึง API ได้ในภายหลังโดยไม่ต้องยืนยันตัวตนซ้ำ +โทเค็นที่จัดเก็บจะผูกกับตัวตนโซเชียลหรือ SSO สำหรับองค์กรของผู้ใช้ ทำให้สามารถเรียกใช้โทเค็นเหล่านี้ในภายหลังเพื่อเข้าถึง API ได้โดยไม่ต้องยืนยันตัวตนซ้ำ ### ตรวจสอบสถานะการจัดเก็บโทเค็น \{#checking-token-storage-status} @@ -58,89 +58,89 @@ import Availability from '@components/Availability'; 1. ไปที่ Console > Users 2. คลิกที่ผู้ใช้ที่ต้องการตรวจสอบ จะเข้าสู่หน้ารายละเอียดของผู้ใช้ -3. เลื่อนไปที่ส่วน **Connections** ซึ่งจะแสดงการเชื่อมต่อโซเชียลและ Enterprise SSO ทั้งหมดที่เกี่ยวข้องกับผู้ใช้ +3. เลื่อนลงไปที่ส่วน **Connections** ซึ่งจะแสดงการเชื่อมต่อโซเชียลและ SSO สำหรับองค์กรทั้งหมดที่เกี่ยวข้องกับผู้ใช้ 4. แต่ละรายการจะแสดงป้ายสถานะโทเค็นว่ามีการจัดเก็บโทเค็นสำหรับการเชื่อมต่อนั้นหรือไม่ -5. คลิกรายการการเชื่อมต่อเพื่อดูรายละเอียดเพิ่มเติม รวมถึง metadata ของโทเค็นการเข้าถึงที่จัดเก็บและสถานะโทเค็นรีเฟรช (ถ้ามี) +5. คลิกรายการการเชื่อมต่อเพื่อดูรายละเอียดเพิ่มเติม รวมถึง metadata ของโทเค็นการเข้าถึงที่จัดเก็บไว้และสถานะโทเค็นรีเฟรช (ถ้ามี) คุณยังสามารถตรวจสอบตัวตนของผู้ใช้และสถานะการจัดเก็บโทเค็นผ่าน Management API ได้ด้วย: - `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`: ดึงข้อมูลตัวตนโซเชียลและสถานะการจัดเก็บโทเค็นของผู้ใช้ที่เชื่อมโยงกับตัวเชื่อมต่อที่ระบุ (เช่น `github`, `google` ฯลฯ) -- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`: ดึงข้อมูลตัวตน Enterprise SSO และสถานะการจัดเก็บโทเค็นของผู้ใช้ที่เชื่อมโยงกับ SSO connector ID ที่ระบุ +- `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`: ดึงข้อมูลตัวตน SSO สำหรับองค์กรและสถานะการจัดเก็บโทเค็นของผู้ใช้ที่เชื่อมโยงกับ SSO connector ID ที่ระบุ ### สถานะการจัดเก็บโทเค็น \{#token-storage-status} - **Active**: มีการจัดเก็บโทเค็นการเข้าถึงและยังใช้งานได้ -- **Expired**: มีการจัดเก็บโทเค็นการเข้าถึงแต่หมดอายุแล้ว หากมีโทเค็นรีเฟรช สามารถใช้เพื่อขอโทเค็นใหม่ได้ +- **Expired**: มีการจัดเก็บโทเค็นการเข้าถึงแต่หมดอายุแล้ว หากมีโทเค็นรีเฟรช สามารถใช้เพื่อขอโทเค็นการเข้าถึงใหม่ได้ - **Inactive**: ไม่มีการจัดเก็บโทเค็นการเข้าถึงสำหรับการเชื่อมต่อนี้ อาจเกิดจากผู้ใช้ยังไม่เคยยืนยันตัวตนผ่านการเชื่อมต่อนี้ หรือมีการลบการจัดเก็บโทเค็นแล้ว -- **Not applicable**: ตัวเชื่อมต่อไม่รองรับการจัดเก็บโทเค็น +- **Not applicable**: ตัวเชื่อมต่อนี้ไม่รองรับการจัดเก็บโทเค็น ### ข้อมูลเมตาของโทเค็น \{#token-metadata} -เพื่อความถูกต้องและความปลอดภัยของข้อมูล โทเค็นทั้งหมดจะถูกเข้ารหัสก่อนจัดเก็บใน secret vault ค่าจริงของโทเค็นจะเข้าถึงได้เฉพาะผู้ใช้ปลายทางที่ได้รับอนุญาตเท่านั้น นักพัฒนาจะสามารถดึงเฉพาะ metadata ของชุดโทเค็นเพื่อดูสถานะโดยไม่เห็นเนื้อหาที่สำคัญ +เพื่อความถูกต้องและความปลอดภัยของข้อมูล โทเค็นทั้งหมดจะถูกเข้ารหัสก่อนจัดเก็บใน secret vault ค่าจริงของโทเค็นจะเข้าถึงได้เฉพาะผู้ใช้ปลายทางที่ได้รับอนุญาตเท่านั้น ฝั่งนักพัฒนาจะสามารถดึงเฉพาะ metadata ของชุดโทเค็นเพื่อดูสถานะโดยไม่เปิดเผยข้อมูลสำคัญ -- `createdAt`: เวลาที่มีการเชื่อมต่อและจัดเก็บชุดโทเค็นครั้งแรกใน secret vault -- `updatedAt`: เวลาที่ชุดโทเค็นถูกอัปเดตล่าสุด +- `createdAt`: เวลาที่มีการเชื่อมต่อครั้งแรกและจัดเก็บชุดโทเค็นใน secret vault +- `updatedAt`: เวลาที่มีการอัปเดตชุดโทเค็นล่าสุด - หากไม่มีโทเค็นรีเฟรช ค่านี้จะเท่ากับ **createdAt** - - หากมีโทเค็นรีเฟรช ค่านี้จะแสดงเวลาที่รีเฟรชโทเค็นการเข้าถึงล่าสุด + - หากมีโทเค็นรีเฟรช ค่านี้จะแสดงเวลาที่มีการรีเฟรชโทเค็นการเข้าถึงล่าสุด - `hasRefreshToken`: ระบุว่ามีโทเค็นรีเฟรชหรือไม่ - หากตัวเชื่อมต่อรองรับ offline access และมีการกำหนดค่า authorization request อย่างถูกต้อง Logto จะจัดเก็บโทเค็นรีเฟรชเมื่อ IdP ออกให้พร้อมกับโทเค็นการเข้าถึง - เมื่อโทเค็นการเข้าถึงหมดอายุและมีโทเค็นรีเฟรชที่ถูกต้อง Logto จะพยายามขอโทเค็นใหม่โดยอัตโนมัติเมื่อผู้ใช้ร้องขอเข้าถึงผู้ให้บริการที่เชื่อมต่อ + หากตัวเชื่อมต่อรองรับ offline access และมีการกำหนดค่า authorization request อย่างถูกต้อง Logto จะจัดเก็บโทเค็นรีเฟรชเมื่อได้รับจาก IdP พร้อมกับโทเค็นการเข้าถึง + เมื่อโทเค็นการเข้าถึงหมดอายุและมีโทเค็นรีเฟรชที่ถูกต้อง Logto จะพยายามขอโทเค็นการเข้าถึงใหม่โดยอัตโนมัติเมื่อผู้ใช้ร้องขอเข้าถึงผู้ให้บริการที่เชื่อมต่อ - `expiresAt`: เวลาหมดอายุโดยประมาณของโทเค็นการเข้าถึง (หน่วยเป็น **วินาที**) - ค่านี้คำนวณจาก `expires_in` ที่ IdP ส่งกลับมา (มีเฉพาะเมื่อผู้ให้บริการส่ง `expires_in` กลับมาใน response) -- `scope`: ขอบเขตของโทเค็นการเข้าถึง แสดงสิทธิ์ที่ IdP อนุญาต - ใช้เพื่อดูว่าทำอะไรได้บ้างกับโทเค็นที่จัดเก็บ (มีเฉพาะเมื่อผู้ให้บริการส่ง `scope` กลับมาใน response) + ค่านี้คำนวณจาก `expires_in` ที่ IdP ส่งกลับมา (มีเฉพาะเมื่อผู้ให้บริการส่ง `expires_in` ใน response) +- `scope`: ขอบเขตของโทเค็นการเข้าถึง แสดงสิทธิ์ที่ได้รับจาก IdP + ใช้เพื่อดูว่าทำอะไรได้บ้างกับโทเค็นที่จัดเก็บ (มีเฉพาะเมื่อผู้ให้บริการส่ง `scope` ใน response) - `tokenType`: ประเภทของโทเค็นการเข้าถึง โดยทั่วไปคือ "Bearer" - (มีเฉพาะเมื่อผู้ให้บริการส่ง `token_type` กลับมาใน response) + (มีเฉพาะเมื่อผู้ให้บริการส่ง `token_type` ใน response) ## การเรียกใช้โทเค็น \{#token-retrieval} -เมื่อเปิดใช้งานการจัดเก็บโทเค็นและโทเค็นถูกจัดเก็บอย่างปลอดภัยใน secret vault ของ Logto แล้ว ผู้ใช้ปลายทางสามารถเรียกใช้โทเค็นการเข้าถึงของบุคคลที่สามจากแอปของคุณโดยเชื่อมต่อกับ [Account API](/end-user-flows/account-settings/by-account-api) ของ Logto +เมื่อเปิดใช้งานการจัดเก็บโทเค็นและโทเค็นถูกจัดเก็บอย่างปลอดภัยใน secret vault ของ Logto แล้ว ผู้ใช้ปลายทางสามารถเรียกใช้โทเค็นการเข้าถึงของบุคคลที่สามจากแอปของคุณได้โดยเชื่อมต่อกับ [Account API](/end-user-flows/account-settings/by-account-api) ของ Logto - `GET /my-account/identities/:target/access-token`: ดึงโทเค็นการเข้าถึงสำหรับตัวตนโซเชียลโดยระบุตัวเชื่อมต่อ (เช่น github, google) -- `GET /my-account/sso-identities/:connectorId/access-token`: ดึงโทเค็นการเข้าถึงสำหรับตัวตน Enterprise SSO โดยระบุ connector ID +- `GET /my-account/sso-identities/:connectorId/access-token`: ดึงโทเค็นการเข้าถึงสำหรับตัวตน SSO สำหรับองค์กรโดยระบุ connector ID :::info -เรียนรู้วิธี [เปิดใช้งาน](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) และ [เข้าถึง](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) Account API ด้วยโทเค็นการเข้าถึงที่ออกโดย Logto +หากต้องการเรียกใช้โทเค็นการเข้าถึงของบุคคลที่สาม คุณต้องเปิดใช้งาน Account API สำหรับผู้ใช้ปลายทางที่ Console > Sign-in & Account > Account center ดูวิธี [เปิดใช้งาน Account API](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) และ [เข้าถึงด้วยโทเค็นการเข้าถึงที่ออกโดย Logto](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) ::: ### การหมุนเวียนโทเค็น \{#token-rotation} -Endpoint สำหรับเรียกใช้โทเค็นจะส่งกลับ: +Endpoint สำหรับเรียกโทเค็นจะส่งกลับ: - `200` OK: หากดึงโทเค็นการเข้าถึงได้สำเร็จและยังไม่หมดอายุ -- `404` Not Found: หากผู้ใช้ไม่มีตัวตนโซเชียลหรือ Enterprise SSO ที่เกี่ยวข้องกับ target หรือ connector ID ที่ระบุ หรือไม่มีการจัดเก็บโทเค็นการเข้าถึง +- `404` Not Found: หากผู้ใช้ไม่มีตัวตนโซเชียลหรือ SSO สำหรับองค์กรที่ตรงกับ target หรือ connector ID ที่ระบุ หรือไม่มีการจัดเก็บโทเค็นการเข้าถึง - `401` Unauthorized: หากโทเค็นการเข้าถึงหมดอายุ -หากโทเค็นการเข้าถึงหมดอายุและมีโทเค็นรีเฟรช Logto จะพยายามรีเฟรชโทเค็นการเข้าถึงโดยอัตโนมัติและส่งโทเค็นใหม่กลับมาใน response พร้อมอัปเดตการจัดเก็บใน secret vault ด้วยโทเค็นและ metadata ใหม่ +หากโทเค็นการเข้าถึงหมดอายุและมีโทเค็นรีเฟรช Logto จะพยายามรีเฟรชโทเค็นการเข้าถึงโดยอัตโนมัติและส่งโทเค็นใหม่กลับมาใน response พร้อมอัปเดตการจัดเก็บใน secret vault ด้วยโทเค็นใหม่และ metadata ## การลบการจัดเก็บโทเค็น \{#token-storage-deletion} -การจัดเก็บโทเค็นของบุคคลที่สามจะผูกกับการเชื่อมต่อโซเชียลหรือ Enterprise SSO ของผู้ใช้แต่ละรายโดยตรง หมายความว่าชุดโทเค็นที่จัดเก็บจะถูกลบโดยอัตโนมัติในกรณีต่อไปนี้: +การจัดเก็บโทเค็นของบุคคลที่สามจะผูกกับการเชื่อมต่อโซเชียลหรือ SSO สำหรับองค์กรของผู้ใช้แต่ละรายโดยตรง ซึ่งหมายความว่าชุดโทเค็นที่จัดเก็บจะถูกลบโดยอัตโนมัติในกรณีต่อไปนี้: -- ตัวตนโซเชียลหรือ Enterprise SSO ที่เกี่ยวข้องถูกลบออกจากบัญชีผู้ใช้ +- ตัวตนโซเชียลหรือ SSO สำหรับองค์กรที่เกี่ยวข้องถูกลบออกจากบัญชีผู้ใช้ - บัญชีผู้ใช้ถูกลบออกจาก tenant ของคุณ -- ตัวเชื่อมต่อโซเชียลหรือ Enterprise SSO ถูกลบออกจาก tenant ของคุณ +- ตัวเชื่อมต่อโซเชียลหรือ SSO สำหรับองค์กรถูกลบออกจาก tenant ของคุณ ### การเพิกถอนโทเค็น \{#revoking-tokens} -คุณสามารถลบชุดโทเค็นของบุคคลที่สามของผู้ใช้ด้วยตนเองเพื่อเพิกถอนการเข้าถึงได้เช่นกัน: +คุณสามารถลบชุดโทเค็นของบุคคลที่สามของผู้ใช้ออกด้วยตนเองเพื่อเพิกถอนการเข้าถึงได้เช่นกัน: - จาก Console: - ไปที่หน้ารายละเอียดตัวตนของผู้ใช้ เลื่อนไปที่ส่วน **Access token** (หากมีการจัดเก็บโทเค็น) แล้วคลิกปุ่ม **Delete tokens** ที่ท้ายส่วน + ไปที่หน้ารายละเอียดตัวตนของผู้ใช้ เลื่อนลงไปที่ส่วน **Access token** (หากมีการจัดเก็บโทเค็น) แล้วคลิกปุ่ม **Delete tokens** ที่ท้ายส่วน - ผ่าน Management API: - - `DELETE /api/secret/:id`: ลบ secret เฉพาะโดยใช้ ID ซึ่งสามารถดูได้จากหน้ารายละเอียดตัวตนของผู้ใช้ + - `DELETE /api/secret/:id`: ลบ secret เฉพาะโดยใช้ ID ซึ่งสามารถดูได้จากหน้ารายละเอียดตัวตนผู้ใช้ การเพิกถอนชุดโทเค็นจะบังคับให้ผู้ใช้ต้องยืนยันตัวตนกับผู้ให้บริการบุคคลที่สามใหม่ก่อนจึงจะเข้าถึง API ได้อีกครั้ง ## การยืนยันตัวตนใหม่และการต่ออายุโทเค็น \{#reauthentication-and-token-renewal} -ในกรณีที่โทเค็นการเข้าถึงที่จัดเก็บหมดอายุ หรือแอปพลิเคชันต้องการขอขอบเขต API เพิ่มเติม ผู้ใช้ปลายทางสามารถยืนยันตัวตนใหม่กับผู้ให้บริการบุคคลที่สามเพื่อรับโทเค็นการเข้าถึงชุดใหม่—โดยไม่ต้องลงชื่อเข้าใช้ Logto ซ้ำ -สามารถทำได้ผ่าน [Social Verification API](https://openapi.logto.io/operation/operation-createverificationbysocial) ของ Logto ซึ่งอนุญาตให้ผู้ใช้เริ่มต้น federated social authorization flow ใหม่และอัปเดตชุดโทเค็นที่จัดเก็บ +ในกรณีที่โทเค็นการเข้าถึงที่จัดเก็บไว้หมดอายุ หรือแอปพลิเคชันต้องการขอขอบเขต API เพิ่มเติม ผู้ใช้ปลายทางสามารถยืนยันตัวตนกับผู้ให้บริการบุคคลที่สามใหม่เพื่อรับโทเค็นการเข้าถึงชุดใหม่—โดยไม่ต้องลงชื่อเข้าใช้ Logto ซ้ำ +สามารถทำได้ผ่าน [Social Verification API](https://openapi.logto.io/operation/operation-createverificationbysocial) ของ Logto ซึ่งช่วยให้ผู้ใช้เริ่มต้น federated social authorization flow ใหม่และอัปเดตชุดโทเค็นที่จัดเก็บไว้ :::note -การเริ่ม federated authorization ใหม่ในขณะนี้จำกัดเฉพาะตัวเชื่อมต่อโซเชียล -สำหรับตัวเชื่อมต่อ Enterprise SSO การยืนยันตัวตนใหม่และการต่ออายุโทเค็นจำเป็นต้องให้ผู้ใช้เริ่ม flow การยืนยันตัวตนของ Logto ใหม่ทั้งหมด เนื่องจากยังไม่รองรับการ reauthorize กับผู้ให้บริการ Enterprise SSO หลังลงชื่อเข้าใช้ +การเริ่มต้น federated authorization ใหม่ในขณะนี้จำกัดเฉพาะตัวเชื่อมต่อโซเชียลเท่านั้น +สำหรับตัวเชื่อมต่อ SSO สำหรับองค์กร การยืนยันตัวตนใหม่และการต่ออายุโทเค็นจำเป็นต้องให้ผู้ใช้เริ่มต้น flow การยืนยันตัวตนของ Logto ใหม่ทั้งหมด เนื่องจากยังไม่รองรับการ reauthorize กับผู้ให้บริการ SSO สำหรับองค์กรหลังลงชื่อเข้าใช้ ::: ```mermaid @@ -160,7 +160,7 @@ sequenceDiagram User->>Logto: patch /my-account/identities/:target/access-token ``` -1. ผู้ใช้เริ่มคำขอ social verification โดยเรียก endpoint `POST /api/verification/social` ผู้ใช้อาจระบุขอบเขต (scope) เพิ่มเติมเพื่อขอสิทธิ์จากผู้ให้บริการบุคคลที่สาม +1. ผู้ใช้เริ่มต้นคำขอ social verification โดยเรียก endpoint `POST /api/verification/social` ผู้ใช้อาจระบุ custom scope เพื่อขอสิทธิ์เพิ่มเติมจากผู้ให้บริการบุคคลที่สาม ```sh curl -X POST https:///api/verification/social \ @@ -177,9 +177,9 @@ sequenceDiagram - **authorization header**: โทเค็นการเข้าถึงของผู้ใช้ที่ออกโดย Logto - **connectorId**: รหัสตัวเชื่อมต่อโซเชียลใน Logto - **redirectUri**: URI ที่จะเปลี่ยนเส้นทางผู้ใช้กลับไปยังแอปของคุณหลังยืนยันตัวตน ต้องลงทะเบียน URI นี้ในแอปของผู้ให้บริการ - - **scope**: (ไม่บังคับ) ขอบเขตเพิ่มเติมเพื่อขอสิทธิ์จากผู้ให้บริการบุคคลที่สาม หากไม่ระบุจะใช้ขอบเขตเริ่มต้นที่กำหนดไว้ในตัวเชื่อมต่อ + - **scope**: (ไม่บังคับ) ขอบเขตเพิ่มเติมที่ต้องการขอสิทธิ์จากผู้ให้บริการบุคคลที่สาม หากไม่ระบุจะใช้ขอบเขตเริ่มต้นที่กำหนดไว้ในตัวเชื่อมต่อ -2. Logto สร้าง social verification record ใหม่และส่งคืน social verification ID พร้อม authorization URL เพื่อเปลี่ยนเส้นทางผู้ใช้ไปยังผู้ให้บริการบุคคลที่สามสำหรับการยืนยันตัวตน +2. Logto สร้าง social verification record ใหม่และส่งคืน social verification ID พร้อม authorization URL เพื่อเปลี่ยนเส้นทางผู้ใช้ไปยังผู้ให้บริการบุคคลที่สามเพื่อยืนยันตัวตน ตัวอย่าง response: @@ -215,7 +215,7 @@ sequenceDiagram - **connectorData**: authorization code และข้อมูลอื่น ๆ ที่ผู้ให้บริการบุคคลที่สามส่งกลับมาใน callback :::note - อย่าลืมตรวจสอบค่า `state` เพื่อป้องกัน CSRF + อย่าลืมตรวจสอบ parameter `state` เพื่อป้องกัน CSRF ::: 6. Logto ตรวจสอบ authorization code และแลกเปลี่ยนเป็นโทเค็นการเข้าถึงและโทเค็นรีเฟรชใหม่จากผู้ให้บริการบุคคลที่สาม จากนั้นส่งคืน social verification ID ใน response @@ -236,4 +236,4 @@ sequenceDiagram การดำเนินการนี้จะอัปเดตชุดโทเค็นของผู้ใช้ใน secret vault ของ Logto ด้วยโทเค็นการเข้าถึงและโทเค็นรีเฟรชใหม่ ทำให้ผู้ใช้เข้าถึง API ของบุคคลที่สามได้โดยไม่ต้องลงชื่อเข้าใช้ Logto ซ้ำ - โทเค็นการเข้าถึงที่อัปเดตจะถูกส่งกลับ + โทเค็นการเข้าถึงที่อัปเดตจะถูกส่งกลับมา diff --git a/i18n/th/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/th/docusaurus-plugin-content-docs/current/security/blocklist.md index 4788907c98c..588fdeb86c3 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/th/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -10,31 +10,31 @@ sidebar_position: 3 นโยบายรายการบล็อกอีเมลช่วยให้คุณปรับแต่งการตั้งค่ารายการบล็อกอีเมลเพื่อป้องกันการสมัครบัญชีที่ไม่เหมาะสม โดยจะตรวจสอบที่อยู่อีเมลที่ใช้สำหรับการสมัครและการตั้งค่าบัญชี หากผู้ใช้พยายามสมัครหรือเชื่อมโยงอีเมลที่ละเมิดกฎรายการบล็อก ระบบจะปฏิเสธคำขอ ช่วยลดบัญชีสแปมและเพิ่มความปลอดภัยของบัญชีโดยรวม -ไปที่ Console > Security > Blocklist เพื่อกำหนดค่าการตั้งค่ารายการบล็อกอีเมล +ไปที่ คอนโซล > ความปลอดภัย > รายการบล็อก เพื่อกำหนดค่าการตั้งค่ารายการบล็อกอีเมล ### บล็อกอีเมลแบบใช้ครั้งเดียว (Block disposable email addresses) {#block-disposable-email-addresses} -นี่คือฟีเจอร์ **เฉพาะคลาวด์** เมื่อเปิดใช้งาน ระบบจะตรวจสอบโดเมนของอีเมลที่ระบุโดยอัตโนมัติกับรายการโดเมนอีเมลแบบใช้ครั้งเดียวที่รู้จัก หากพบโดเมนในรายการ ระบบจะปฏิเสธคำขอ รายการโดเมนอีเมลแบบใช้ครั้งเดียวจะได้รับการอัปเดตอย่างสม่ำเสมอเพื่อให้มีประสิทธิภาพ +นี่เป็นฟีเจอร์ **เฉพาะคลาวด์** เมื่อเปิดใช้งาน ระบบจะตรวจสอบโดเมนของอีเมลที่ระบุโดยอัตโนมัติกับรายการโดเมนอีเมลแบบใช้ครั้งเดียวที่รู้จัก หากพบโดเมนในรายการ ระบบจะปฏิเสธคำขอ รายการโดเมนอีเมลแบบใช้ครั้งเดียวจะได้รับการอัปเดตอย่างสม่ำเสมอเพื่อให้มีประสิทธิภาพ ### บล็อกการใช้งานอีเมลแบบ subaddressing (Block email subaddressing) {#block-email-subaddressing} -การใช้งานอีเมลแบบ subaddressing ช่วยให้ผู้ใช้สร้างรูปแบบอีเมลที่แตกต่างกันโดยเพิ่มเครื่องหมายบวก (+) ตามด้วยอักขระเพิ่มเติม (เช่น user+tag@example.com) ฟีเจอร์นี้อาจถูกผู้ไม่หวังดีนำไปใช้เพื่อหลีกเลี่ยงข้อจำกัดของรายการบล็อกได้ การเปิดใช้งานฟีเจอร์นี้ ระบบจะปฏิเสธการสมัครหรือเชื่อมโยงบัญชีที่ใช้อีเมลรูปแบบ subaddressing +การใช้งานอีเมลแบบ subaddressing ช่วยให้ผู้ใช้สร้างรูปแบบอีเมลที่แตกต่างกันได้โดยการเพิ่มเครื่องหมายบวก (+) ตามด้วยอักขระเพิ่มเติม (เช่น user+tag@example.com) ฟีเจอร์นี้อาจถูกผู้ไม่หวังดีนำไปใช้เพื่อหลีกเลี่ยงข้อจำกัดของรายการบล็อกได้ การเปิดใช้งานฟีเจอร์นี้จะทำให้ระบบปฏิเสธการสมัครหรือเชื่อมโยงบัญชีที่ใช้อีเมลรูปแบบ subaddressing ### รายการบล็อกอีเมลแบบกำหนดเอง (Custom email blocklist) {#custom-email-blocklist} คุณสามารถสร้างรายการบล็อกอีเมลแบบกำหนดเองได้โดยระบุรายการที่อยู่อีเมลหรือโดเมนที่ต้องการบล็อก ระบบจะปฏิเสธการสมัครหรือเชื่อมโยงบัญชีที่ตรงกับรายการเหล่านี้ รายการบล็อกนี้รองรับทั้งการระบุที่อยู่อีเมลเต็มและการระบุโดเมน -ตัวอย่างเช่น การเพิ่ม `@example.com` ในรายการบล็อกจะบล็อกอีเมลทั้งหมดที่ใช้โดเมนนั้น หรือการเพิ่ม `foo@example.com` จะบล็อกเฉพาะอีเมลนั้น +ตัวอย่างเช่น การเพิ่ม `@example.com` ลงในรายการบล็อกจะบล็อกอีเมลทั้งหมดที่ใช้โดเมนนั้น หรือการเพิ่ม `foo@example.com` จะบล็อกเฉพาะอีเมลนั้น :::note -อีเมลแบบใช้ครั้งเดียว, subaddressing และอีเมลแบบกำหนดเองจะถูกจำกัดในระหว่างการลงทะเบียนและการเชื่อมโยงบัญชี ผู้ใช้ที่มีอีเมลเหล่านี้อยู่แล้วสามารถลงชื่อเข้าใช้ได้ตามปกติ +อีเมลแบบใช้ครั้งเดียว, subaddressing และอีเมลแบบกำหนดเองจะถูกจำกัดในระหว่าง [การลงทะเบียนผู้ใช้ใหม่](/end-user-flows/sign-up-and-sign-in/sign-up), [การเชื่อมโยงอีเมลระหว่างการเข้าสู่ระบบโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers), และการอัปเดตอีเมลผ่าน [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email) ผู้ใช้เดิมที่มีอีเมลเหล่านี้ยังสามารถลงชื่อเข้าใช้ได้ -- ผู้ดูแลระบบสามารถ “ข้ามข้อจำกัด” ได้โดยการเพิ่มผู้ใช้ด้วยตนเองที่ Console > User management หรือผ่าน [Management API](https://openapi.logto.io/operation/operation-createuser) เช่น สร้างผู้ใช้ด้วยอีเมล subaddress เมื่อมีการบล็อก subaddressing -- บล็อกบัญชีที่มีอยู่โดยการลบหรือระงับใน Console > User management +- ผู้ดูแลระบบสามารถ “ข้ามข้อจำกัด” ได้โดยการเพิ่มผู้ใช้ด้วยตนเองที่ คอนโซล > การจัดการผู้ใช้ หรือผ่าน [Management API](https://openapi.logto.io/operation/operation-createuser) เช่น สร้างผู้ใช้ด้วยอีเมล subaddress เมื่อมีการบล็อก subaddressing +- บล็อกบัญชีที่มีอยู่โดยการลบหรือระงับใน คอนโซล > การจัดการผู้ใช้ ::: -## แหล่งข้อมูลที่เกี่ยวข้อง (Related resources) {#related-resources} +## แหล่งข้อมูลที่เกี่ยวข้อง {#related-resources} อีเมลแบบใช้ครั้งเดียวคืออะไร? จะจัดการกับมันในแอปของคุณอย่างไร? diff --git a/i18n/th/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/th/docusaurus-plugin-content-docs/current/security/password-policy.mdx index debb17f98ae..91f70a6089e 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,27 +6,36 @@ sidebar_position: 1 # นโยบายรหัสผ่าน +Logto ใช้นโยบายรหัสผ่านในรูปแบบที่แตกต่างกัน ขึ้นอยู่กับวิธีที่รหัสผ่านถูกสร้างหรืออัปเดต: + +- กระบวนการสำหรับผู้ใช้ปลายทาง เช่น [ประสบการณ์การลงชื่อเข้าใช้สำเร็จรูป](/end-user-flows/sign-up-and-sign-in/sign-up), [Experience API](/customization/bring-your-ui), และ [Account API](/end-user-flows/account-settings/by-account-api#update-users-password) จะบังคับใช้นโยบายรหัสผ่านปัจจุบันเสมอ ดูรายละเอียดที่ [ตั้งค่านโยบายรหัสผ่าน](#set-up-password-policy) +- การดำเนินการของผู้ดูแลระบบผ่าน Management API [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) จะได้รับการยกเว้น ทำให้คุณสามารถจัดเตรียมหรือรีเซ็ตรหัสผ่านโดยไม่ต้องตรวจสอบนโยบายเมื่อจำเป็น +- หากต้องการตรวจสอบรหัสผ่านที่มีอยู่กับกฎปัจจุบัน ให้เรียก [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) และดำเนินการตามผลการตรวจสอบ อ่าน [การตรวจสอบความสอดคล้องของรหัสผ่าน](#password-compliance-check) เพื่อเรียนรู้เพิ่มเติม + ## ตั้งค่านโยบายรหัสผ่าน \{#set-up-password-policy} -สำหรับผู้ใช้ใหม่หรือผู้ใช้ที่กำลังอัปเดตรหัสผ่าน คุณสามารถตั้งค่านโยบายรหัสผ่านเพื่อบังคับใช้ข้อกำหนดความแข็งแรงของรหัสผ่านได้ เยี่ยมชม Console > ความปลอดภัย > นโยบายรหัสผ่าน เพื่อกำหนดค่านโยบายรหัสผ่าน +สำหรับผู้ใช้ใหม่หรือผู้ใช้ที่กำลังอัปเดตรหัสผ่าน คุณสามารถตั้งนโยบายรหัสผ่านเพื่อบังคับใช้ข้อกำหนดความแข็งแรงของรหัสผ่านได้ ไปที่ Console > ความปลอดภัย > นโยบายรหัสผ่าน เพื่อกำหนดค่านโยบายรหัสผ่าน -1. **ความยาวรหัสผ่านขั้นต่ำ**: กำหนดจำนวนอักขระขั้นต่ำที่ต้องใช้สำหรับรหัสผ่าน (NIST แนะนำให้ใช้อย่างน้อย 8 [อักขระ](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) -2. **ประเภทอักขระขั้นต่ำที่ต้องมี**: กำหนดจำนวนประเภทอักขระขั้นต่ำที่ต้องมีในรหัสผ่าน ประเภทอักขระที่รองรับ ได้แก่: - 1. ตัวอักษรตัวใหญ่: `(A-Z)` - 2. ตัวอักษรตัวเล็ก: `(a-z)` +1. **ความยาวขั้นต่ำของรหัสผ่าน**: กำหนดจำนวนอักขระขั้นต่ำที่ต้องใช้ในรหัสผ่าน (NIST แนะนำให้ใช้อย่างน้อย 8 [อักขระ](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) +2. **ประเภทอักขระขั้นต่ำที่ต้องมี**: กำหนดจำนวนประเภทอักขระขั้นต่ำที่ต้องมีในรหัสผ่าน ประเภทอักขระที่มีให้เลือก ได้แก่: + 1. ตัวอักษรตัวพิมพ์ใหญ่: `(A-Z)` + 2. ตัวอักษรตัวพิมพ์เล็ก: `(a-z)` 3. ตัวเลข: `(0-9)` 4. อักขระพิเศษ: ``(!"#$%&'()\*+,-./:;<>=?@[]^\_`|{}~ )`` -3. **ตรวจสอบประวัติการรั่วไหล**: เปิดใช้งานการตั้งค่านี้เพื่อปฏิเสธรหัสผ่านที่เคยถูกเปิดเผยในการรั่วไหลของข้อมูลมาก่อน (ขับเคลื่อนโดย [Have I Been Pwned](https://haveibeenpwned.com/Passwords)) -4. **ตรวจสอบการซ้ำซ้อน**: เปิดใช้งานการตั้งค่านี้เพื่อปฏิเสธรหัสผ่านที่มีอักขระซ้ำกัน (เช่น "11111111" หรือ "password123") -5. **ตรวจสอบข้อมูลผู้ใช้**: เปิดใช้งานการตั้งค่านี้เพื่อปฏิเสธรหัสผ่านที่มีข้อมูลของผู้ใช้ เช่น ชื่อผู้ใช้ อีเมล หรือหมายเลขโทรศัพท์ -6. **คำที่กำหนดเอง**: ระบุรายการคำที่คุณต้องการปฏิเสธในรหัสผ่าน (ไม่สนใจตัวพิมพ์เล็ก / ใหญ่) +3. **ตรวจสอบประวัติการรั่วไหล**: เปิดใช้งานเพื่อตรวจสอบและปฏิเสธรหัสผ่านที่เคยรั่วไหลในเหตุการณ์ข้อมูลรั่วไหลมาก่อน (ขับเคลื่อนโดย [Have I Been Pwned](https://haveibeenpwned.com/Passwords)) +4. **ตรวจสอบการซ้ำซ้อน**: เปิดใช้งานเพื่อตรวจสอบและปฏิเสธรหัสผ่านที่มีอักขระซ้ำกัน (เช่น "11111111" หรือ "password123") +5. **ตรวจสอบข้อมูลผู้ใช้**: เปิดใช้งานเพื่อตรวจสอบและปฏิเสธรหัสผ่านที่มีข้อมูลผู้ใช้ เช่น ชื่อผู้ใช้ อีเมล หรือเบอร์โทรศัพท์ +6. **คำที่กำหนดเอง**: ระบุรายการคำที่คุณต้องการปฏิเสธในรหัสผ่าน (ไม่สนใจตัวพิมพ์ใหญ่-เล็ก) ## การตรวจสอบความสอดคล้องของรหัสผ่าน \{#password-compliance-check} -หลังจากที่คุณอัปเดตนโยบายรหัสผ่านใน Logto ผู้ใช้เดิมยังคงสามารถลงชื่อเข้าใช้ด้วยรหัสผ่านปัจจุบันได้ จะมีเพียงบัญชีที่สร้างใหม่เท่านั้นที่ต้องปฏิบัติตามนโยบายที่อัปเดต +หลังจากที่คุณอัปเดตนโยบายรหัสผ่านใน Logto ผู้ใช้ที่มีอยู่ยังคงสามารถลงชื่อเข้าใช้ด้วยรหัสผ่านเดิมได้ จะมีเพียงบัญชีที่สร้างใหม่เท่านั้นที่ต้องปฏิบัติตามนโยบายที่อัปเดต -เพื่อบังคับใช้ความปลอดภัยที่เข้มงวดยิ่งขึ้น คุณสามารถใช้ `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) เพื่อตรวจสอบว่ารหัสผ่านของผู้ใช้ตรงตามนโยบายปัจจุบันที่กำหนดไว้ในประสบการณ์การลงชื่อเข้าใช้เริ่มต้นหรือไม่ หากไม่ตรง คุณสามารถแจ้งให้ผู้ใช้อัปเดตรหัสผ่านผ่าน flow ที่คุณกำหนดเองโดยใช้ [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) +เพื่อเสริมความปลอดภัยที่เข้มงวดยิ่งขึ้น คุณสามารถใช้ `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) เพื่อตรวจสอบว่ารหัสผ่านของผู้ใช้ตรงตามนโยบายปัจจุบันที่กำหนดไว้ในประสบการณ์การลงชื่อเข้าใช้หรือไม่ หากไม่ตรง คุณสามารถแจ้งให้ผู้ใช้อัปเดตรหัสผ่านผ่านกระบวนการที่คุณกำหนดเองโดยใช้ [Account API](/end-user-flows/account-settings/by-account-api) ## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} +จัดการผู้ใช้ +ลงทะเบียนและลงชื่อเข้าใช้ +ตั้งค่าบัญชีด้วย Account API ออกแบบนโยบายรหัสผ่านของคุณ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/th/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index 2c65bda553b..268e049dfcc 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -20,44 +20,51 @@ sidebar_position: 2 ### เพิ่มผู้ใช้ \{#add-users} -นักพัฒนาสามารถสร้างบัญชีใหม่ให้กับผู้ใช้ปลายทางผ่าน Console ได้ โดยคลิกปุ่ม "เพิ่มผู้ใช้" ที่มุมขวาบนของหน้าจอ +นักพัฒนาสามารถสร้างบัญชีใหม่ให้ผู้ใช้ปลายทางผ่าน Console ได้ โดยคลิกปุ่ม "เพิ่มผู้ใช้" ที่มุมขวาบนของหน้าจอ -เมื่อสร้างผู้ใช้ใน Logto Console หรือผ่าน Management API (ไม่ใช่การลงทะเบียนด้วยตนเองของผู้ใช้ผ่าน UI) คุณต้องระบุ identifier อย่างน้อยหนึ่งอย่าง ได้แก่ `primary email`, `primary phone` หรือ `username` ส่วน `name` เป็นตัวเลือก +เมื่อสร้างผู้ใช้ใน Logto Console หรือผ่าน Management API (ไม่ใช่การลงทะเบียนด้วยตนเองผ่าน UI) คุณต้องระบุ identifier อย่างน้อยหนึ่งอย่าง: `primary email`, `primary phone` หรือ `username` ฟิลด์ `name` เป็นตัวเลือก หลังจากสร้างผู้ใช้แล้ว Logto จะสร้างรหัสผ่านแบบสุ่มให้อัตโนมัติ รหัสผ่านเริ่มต้นจะแสดงเพียงครั้งเดียว แต่คุณสามารถ [รีเซ็ตรหัสผ่าน](./manage-users#reset-user-password) ได้ในภายหลัง หากต้องการตั้งรหัสผ่านเฉพาะ ให้ใช้ Management API `patch /api/users/{userId}/password` เพื่ออัปเดตหลังจากสร้างผู้ใช้แล้ว -คุณสามารถคัดลอก **identifier ที่กรอก (ที่อยู่อีเมล / หมายเลขโทรศัพท์ / ชื่อผู้ใช้)** และ **รหัสผ่านเริ่มต้น** ได้ในคลิกเดียว เพื่อแชร์ข้อมูลนี้กับผู้ใช้ใหม่ให้สามารถลงชื่อเข้าใช้และเริ่มต้นใช้งานได้ทันที +คุณสามารถคัดลอก **identifier ที่กรอก (ที่อยู่อีเมล / หมายเลขโทรศัพท์ / ชื่อผู้ใช้)** และ **รหัสผ่านเริ่มต้น** ได้ด้วยคลิกเดียว เพื่อแบ่งปันข้อมูลรับรองนี้กับผู้ใช้ใหม่ให้สามารถลงชื่อเข้าใช้และเริ่มต้นใช้งานได้ทันที :::tip -หากคุณต้องการให้ลงทะเบียนเฉพาะผู้ที่ได้รับเชิญเท่านั้น แนะนำให้ [เชิญผู้ใช้ด้วย magic link](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended) วิธีนี้จะอนุญาตเฉพาะผู้ใช้ที่อยู่ใน whitelist ให้ลงทะเบียนและตั้งรหัสผ่านเองได้ +หากต้องการให้ลงทะเบียนแบบเชิญเท่านั้น แนะนำให้ [เชิญผู้ใช้ด้วย magic link](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended) วิธีนี้จะอนุญาตเฉพาะผู้ใช้ที่อยู่ใน whitelist ให้ลงทะเบียนและตั้งรหัสผ่านเองได้ ::: ### ดูและอัปเดตโปรไฟล์ผู้ใช้ \{#view-and-update-the-user-profile} -หากต้องการดูรายละเอียดของผู้ใช้ ให้คลิกแถวที่ต้องการในตารางผู้ใช้ จะเข้าสู่หน้า "**รายละเอียดผู้ใช้**" ซึ่งจะแสดงข้อมูลโปรไฟล์ของผู้ใช้ รวมถึง: +เพื่อดูรายละเอียดของผู้ใช้ ให้คลิกแถวที่ต้องการในตารางผู้ใช้ จะเข้าสู่หน้า "**รายละเอียดผู้ใช้**" ซึ่งจะแสดงข้อมูลโปรไฟล์ของผู้ใช้ รวมถึง: -- **ข้อมูลที่เกี่ยวข้องกับการยืนยันตัวตน**: +- **ข้อมูลที่เกี่ยวข้องกับการยืนยันตัวตน (Authentication)**: - **ที่อยู่อีเมล** ([primary_email](/user-management/user-data#primary_email)): แก้ไขได้ - **หมายเลขโทรศัพท์** ([primary_phone](/user-management/user-data#primary_phone)): แก้ไขได้ - **ชื่อผู้ใช้** ([username](/user-management/user-data#username)): แก้ไขได้ - **รหัสผ่าน** ([has_password](/user-management/user-data#has_password)): สามารถสร้างรหัสผ่านแบบสุ่มใหม่ได้ ดูเพิ่มเติมที่ "[รีเซ็ตรหัสผ่านผู้ใช้](#reset-user-password)" - - **การเชื่อมต่อโซเชียล** ([identities](/user-management/user-data#social-identities)): ดูบัญชีโซเชียลที่เชื่อมต่อและ social ID เช่น หากผู้ใช้ลงชื่อเข้าใช้ด้วย Facebook จะเห็นรายการ "Facebook" ในลิสต์นี้ คุณสามารถลบบัญชีโซเชียลที่เชื่อมต่อใน Console ได้ แต่ไม่สามารถเชื่อมต่อใหม่แทนผู้ใช้ได้ - - **การเชื่อมต่อ Enterprise SSO** ([sso_identities](/user-management/user-data#sso-identities)): ดู enterprise identity ที่เชื่อมต่อ ไม่สามารถเพิ่มหรือลบ SSO identity ใน Console ได้ - - **การยืนยันตัวตนหลายปัจจัย (MFA)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): ดูปัจจัยการยืนยันตัวตนทั้งหมด (เช่น passkey, แอป authenticator, รหัสสำรอง) ที่ผู้ใช้ตั้งค่าไว้ สามารถลบปัจจัยใน Console ได้ - - **Personal access token**: สร้าง ดู เปลี่ยนชื่อ และลบ [personal access token](/user-management/personal-access-token) -- **ข้อมูลโปรไฟล์ผู้ใช้**: ชื่อ, URL อวาตาร์, ข้อมูล custom, และ OpenID Connect standard claims อื่น ๆ ที่ไม่ได้รวมไว้ ฟิลด์โปรไฟล์เหล่านี้สามารถแก้ไขได้ทั้งหมด + - **การยืนยันตัวตนหลายปัจจัย (Multi-factor authentication)** ([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)): ดูปัจจัยการยืนยันตัวตนทั้งหมด (เช่น passkey, แอป authenticator, รหัสสำรอง) ที่ผู้ใช้ตั้งค่าไว้ สามารถลบปัจจัยได้ใน Console + - **Personal access token**: สร้าง ดู เปลี่ยนชื่อ และลบ [personal access tokens](/user-management/personal-access-token) +- **การเชื่อมต่อ**: + - **การเชื่อมต่อโซเชียล (Social connections)** ([identities](/user-management/user-data#social-identities)): + - ดูบัญชีโซเชียลที่เชื่อมโยงของผู้ใช้ รวมถึง social ID และรายละเอียดโปรไฟล์ที่ซิงก์จากผู้ให้บริการโซเชียล (เช่น จะมีรายการ "Facebook" หากผู้ใช้ลงชื่อเข้าใช้ผ่าน Facebook) + - สามารถลบ social identity ที่มีอยู่ได้ แต่ไม่สามารถเชื่อมโยงบัญชีโซเชียลใหม่แทนผู้ใช้ได้ + - สำหรับตัวเชื่อมต่อโซเชียลที่เปิดใช้งาน [token storage](/secret-vault/federated-token-set) สามารถดูและจัดการ access token และ refresh token ได้ในหน้ารายละเอียดการเชื่อมต่อ + - **การเชื่อมต่อ Enterprise SSO** ([sso_identities](/user-management/user-data#sso-identities)): + - ดู enterprise identity ที่เชื่อมโยงของผู้ใช้ รวมถึง enterprise ID และรายละเอียดโปรไฟล์ที่ซิงก์จากผู้ให้บริการข้อมูลระบุตัวตนขององค์กร + - ไม่สามารถเพิ่มหรือลบ enterprise SSO identity ใน Console ได้ + - สำหรับตัวเชื่อมต่อองค์กรแบบ OIDC ที่เปิดใช้งาน [token storage](/secret-vault/federated-token-set) สามารถดูและลบ token ได้ในหน้ารายละเอียดการเชื่อมต่อ +- **ข้อมูลโปรไฟล์ผู้ใช้**: ชื่อ, URL อวาตาร์, ข้อมูลกำหนดเอง และ OpenID Connect standard claims อื่น ๆ ที่ไม่ได้รวมไว้ ฟิลด์โปรไฟล์เหล่านี้สามารถแก้ไขได้ทั้งหมด :::warning -ควรตรวจสอบให้แน่ใจว่าผู้ใช้มีวิธีลงชื่อเข้าใช้อื่นก่อนลบบัญชีโซเชียล เช่น มีบัญชีโซเชียลอื่น หมายเลขโทรศัพท์ อีเมล หรือชื่อผู้ใช้พร้อมรหัสผ่าน หากไม่มีวิธีอื่น ผู้ใช้จะไม่สามารถเข้าถึงบัญชีได้อีกหลังจากลบการเชื่อมต่อโซเชียล +ควรตรวจสอบให้แน่ใจว่าผู้ใช้มีวิธีลงชื่อเข้าใช้อื่นก่อนลบการเชื่อมต่อโซเชียล เช่น การเชื่อมต่อโซเชียลอื่น หมายเลขโทรศัพท์ อีเมล หรือชื่อผู้ใช้พร้อมรหัสผ่าน หากไม่มีวิธีอื่น ผู้ใช้จะไม่สามารถเข้าถึงบัญชีได้อีกหลังจากลบการเชื่อมต่อโซเชียล ::: ### ดูกิจกรรมของผู้ใช้ \{#view-user-activities} -หากต้องการดูประวัติกิจกรรมล่าสุดของผู้ใช้ ให้ไปที่แท็บย่อย "User logs" ในหน้า "รายละเอียดผู้ใช้" จะมีตารางแสดงกิจกรรมล่าสุดของผู้ใช้ เช่น การกระทำที่เกิดขึ้น ผลลัพธ์ของการกระทำนั้น แอปที่เกี่ยวข้อง และเวลาที่ผู้ใช้กระทำ +เพื่อดูประวัติกิจกรรมล่าสุดของผู้ใช้ ให้ไปที่แท็บย่อย "User logs" ในหน้า "รายละเอียดผู้ใช้" จะมีตารางแสดงกิจกรรมล่าสุดของผู้ใช้ เช่น การกระทำที่เกิดขึ้น ผลลัพธ์ของการกระทำนั้น แอปที่เกี่ยวข้อง และเวลาที่ผู้ใช้ดำเนินการ คลิกแถวในตารางเพื่อดูรายละเอียดเพิ่มเติมใน user log เช่น IP address, user agent, raw data ฯลฯ @@ -65,7 +72,7 @@ sidebar_position: 2 ในหน้า "รายละเอียดผู้ใช้" คลิก "จุดสามจุด" -> ปุ่ม "ระงับผู้ใช้" -เมื่อผู้ใช้ถูกระงับ จะไม่สามารถลงชื่อเข้าใช้แอปของคุณและไม่สามารถรับ access token ใหม่หลังจาก token ปัจจุบันหมดอายุได้ นอกจากนี้ คำขอ API ใด ๆ ที่ผู้ใช้นี้ทำจะล้มเหลว +เมื่อผู้ใช้ถูกระงับ จะไม่สามารถลงชื่อเข้าใช้แอปของคุณและจะไม่สามารถรับ access token ใหม่หลังจาก token ปัจจุบันหมดอายุ นอกจากนี้ คำขอ API ใด ๆ ที่ทำโดยผู้ใช้นี้จะล้มเหลว หากต้องการเปิดใช้งานผู้ใช้นี้อีกครั้ง ให้คลิก "จุดสามจุด" -> ปุ่ม "เปิดใช้งานผู้ใช้" @@ -77,13 +84,19 @@ sidebar_position: 2 ในหน้า "รายละเอียดผู้ใช้" คลิก "จุดสามจุด" -> ปุ่ม "รีเซ็ตรหัสผ่าน" จากนั้น Logto จะสร้างรหัสผ่านแบบสุ่มใหม่ให้อัตโนมัติ -หลังจากรีเซ็ตรหัสผ่านแล้ว ให้คัดลอกและส่งรหัสผ่านให้ผู้ใช้ปลายทาง เมื่อปิดหน้าต่าง "รีเซ็ตรหัสผ่าน" แล้วจะไม่สามารถดูรหัสผ่านได้อีก หากลืมบันทึกไว้ สามารถรีเซ็ตใหม่ได้ +หลังจากรีเซ็ตรหัสผ่านแล้ว ให้คัดลอกและส่งให้ผู้ใช้ปลายทาง เมื่อปิดหน้าต่าง "รีเซ็ตรหัสผ่าน" แล้ว จะไม่สามารถดูรหัสผ่านได้อีก หากลืมบันทึกไว้ สามารถรีเซ็ตใหม่ได้ -คุณไม่สามารถตั้งรหัสผ่านเฉพาะให้ผู้ใช้ใน Logto Console ได้ แต่สามารถใช้ [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` เพื่อกำหนดรหัสผ่านได้ +คุณไม่สามารถตั้งรหัสผ่านเฉพาะให้ผู้ใช้ใน Logto Console ได้ แต่สามารถใช้ [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` เพื่อระบุรหัสผ่านได้ + +## การตรวจสอบความสอดคล้องของรหัสผ่าน \{#password-compliance-check} + +หลังจากอัปเดต [นโยบายรหัสผ่าน](/security/password-policy) ใน Logto ผู้ใช้เดิมยังคงสามารถลงชื่อเข้าใช้ด้วยรหัสผ่านเดิมได้ เฉพาะบัญชีที่สร้างใหม่เท่านั้นที่ต้องปฏิบัติตามนโยบายรหัสผ่านที่อัปเดต + +เพื่อบังคับใช้ความปลอดภัยที่เข้มงวดยิ่งขึ้น คุณสามารถใช้ `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) เพื่อตรวจสอบว่ารหัสผ่านของผู้ใช้ตรงตามนโยบายปัจจุบันที่กำหนดไว้ในประสบการณ์การลงชื่อเข้าใช้เริ่มต้นหรือไม่ หากไม่ตรง คุณสามารถแจ้งให้ผู้ใช้อัปเดตรหัสผ่านผ่าน flow ที่กำหนดเองโดยใช้ [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) ### จัดการบทบาทของผู้ใช้ \{#manage-roles-of-users} -ในแท็บ "บทบาท" ของหน้า "รายละเอียดผู้ใช้" คุณสามารถกำหนดหรือลบบทบาทได้อย่างง่ายดาย ดูรายละเอียดที่ [การควบคุมการเข้าถึงตามบทบาท (RBAC)](/authorization/role-based-access-control) +ในแท็บ "บทบาท" ของหน้าโปรไฟล์ผู้ใช้ คุณสามารถกำหนดหรือลบบทบาทได้อย่างง่ายดาย ดูรายละเอียดที่ [การควบคุมการเข้าถึงตามบทบาท (RBAC)](/authorization/role-based-access-control) ### ดูองค์กรที่ผู้ใช้สังกัด \{#view-the-organizations-the-user-belongs-to} @@ -91,11 +104,11 @@ Logto รองรับ [องค์กร](/organizations/organization-manage ## จัดการผ่าน Logto Management API \{#manage-via-logto-management-api} -[Management API](/concepts/core-service/#management-api) คือชุด API ที่ให้เข้าถึงบริการ backend ของ Logto ดังที่กล่าวไปแล้ว API ที่เกี่ยวข้องกับผู้ใช้ถือเป็นส่วนสำคัญของบริการนี้และรองรับการใช้งานได้หลากหลาย +[Management API](/concepts/core-service/#management-api) คือชุด API ที่ให้เข้าถึงบริการ backend ของ Logto ตามที่กล่าวไว้ก่อนหน้านี้ user API เป็นส่วนสำคัญของบริการนี้และรองรับกรณีการใช้งานที่หลากหลาย -API ที่เกี่ยวข้องกับผู้ใช้แบบ [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) จะอยู่ที่ `/api/users` ยกเว้นกิจกรรมของผู้ใช้ (user logs) ซึ่งอยู่ที่ `/api/logs?userId=:userId` +[RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API ที่เกี่ยวข้องกับผู้ใช้จะอยู่ที่ `/api/users` ยกเว้นกิจกรรมของผู้ใช้ เช่น user logs `/api/logs?userId=:userId` -คุณสามารถจัดการผู้ใช้ผ่าน Management API ได้ในหลายกรณี เช่น [การค้นหาผู้ใช้ขั้นสูง](/user-management/advanced-user-search), [สร้างบัญชีจำนวนมาก](https://openapi.logto.io/operation/operation-createuser), [ลงทะเบียนเฉพาะผู้ที่ได้รับเชิญ](/end-user-flows/sign-up-and-sign-in/disable-user-registration) เป็นต้น +คุณสามารถจัดการผู้ใช้ผ่าน Management API ได้ในหลายกรณี เช่น [การค้นหาผู้ใช้ขั้นสูง](/user-management/advanced-user-search), [สร้างบัญชีจำนวนมาก](https://openapi.logto.io/operation/operation-createuser), [ลงทะเบียนแบบเชิญเท่านั้น](/end-user-flows/sign-up-and-sign-in/disable-user-registration) เป็นต้น ## คำถามที่พบบ่อย \{#faqs} @@ -103,10 +116,12 @@ API ที่เกี่ยวข้องกับผู้ใช้แบบ -### จะจำกัดการเข้าถึงแอปพลิเคชันบางตัวสำหรับผู้ใช้บางกลุ่มได้อย่างไร? \{#how-to-restrict-access-to-certain-application-for-specific-users} +### จะจำกัดการเข้าถึงแอปพลิเคชันบางตัวสำหรับผู้ใช้เฉพาะกลุ่มได้อย่างไร? \{#how-to-restrict-access-to-certain-application-for-specific-users} -เนื่องจากธรรมชาติของ [Omni-sign-in](https://logto.io/products/omni-sign-in) ของ Logto จึงไม่ได้ออกแบบมาเพื่อจำกัดการเข้าถึงแอปพลิเคชันบางตัวก่อนการยืนยันตัวตน อย่างไรก็ตาม คุณยังสามารถออกแบบบทบาทและสิทธิ์เฉพาะแอปเพื่อปกป้องทรัพยากร API ของคุณ และตรวจสอบสิทธิ์เมื่อผู้ใช้ลงชื่อเข้าใช้สำเร็จ ดูรายละเอียดที่ การอนุญาต: [การควบคุมการเข้าถึงตามบทบาท (RBAC)](/authorization/role-based-access-control) +เนื่องจากธรรมชาติของ [Omni-sign-in](https://logto.io/products/omni-sign-in) ของ Logto จึงไม่ได้ออกแบบมาเพื่อจำกัดการเข้าถึงแอปพลิเคชันบางตัวก่อนการยืนยันตัวตน +อย่างไรก็ตาม คุณยังสามารถออกแบบบทบาทและสิทธิ์ของผู้ใช้เฉพาะแอปเพื่อปกป้องทรัพยากร API ของคุณ และตรวจสอบสิทธิ์ในการเข้าถึง API หลังจากผู้ใช้ลงชื่อเข้าใช้สำเร็จ +ดูรายละเอียดที่ การอนุญาต: [การควบคุมการเข้าถึงตามบทบาท (RBAC)](/authorization/role-based-access-control) diff --git a/i18n/th/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/th/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index 035ffd3e859..10dfc8d9934 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -4,7 +4,7 @@ sidebar_position: 1 # โครงสร้างข้อมูลผู้ใช้ -ผู้ใช้คือเอนทิตีหลักในบริการข้อมูลระบุตัวตน ใน Logto ผู้ใช้จะมีข้อมูลการยืนยันตัวตนพื้นฐานตามโปรโตคอล [OpenID Connect](https://auth.wiki/openid-connect) พร้อมข้อมูลที่กำหนดเอง +ผู้ใช้เป็นเอนทิตีหลักในบริการข้อมูลระบุตัวตน ใน Logto ผู้ใช้จะมีข้อมูลการยืนยันตัวตนพื้นฐานตามโปรโตคอล [OpenID Connect](https://auth.wiki/openid-connect) พร้อมกับข้อมูลที่กำหนดเอง ## โปรไฟล์ผู้ใช้ \{#user-profile} @@ -13,8 +13,8 @@ sidebar_position: 1 ประกอบด้วยข้อมูลประเภทต่อไปนี้: - [ข้อมูลพื้นฐาน](/user-management/user-data#basic-data): คือข้อมูลพื้นฐานจากโปรไฟล์ผู้ใช้ เก็บคุณสมบัติอื่น ๆ ของ _ผู้ใช้_ ทั้งหมด ยกเว้น `identities` ทางโซเชียลและ `custom_data` เช่น รหัสผู้ใช้, ชื่อผู้ใช้, อีเมล, เบอร์โทรศัพท์ และเวลาที่ผู้ใช้ลงชื่อเข้าใช้ล่าสุด -- [ข้อมูลระบุตัวตนทางโซเชียล](/user-management/user-data#social-identities): เก็บข้อมูลผู้ใช้ที่ได้จากการลงชื่อเข้าใช้ผ่านโซเชียล (เช่น ลงชื่อเข้าใช้ด้วยตัวเชื่อมต่อโซเชียล) เช่น Facebook, GitHub และ WeChat -- [ข้อมูลที่กำหนดเอง](/user-management/user-data#custom-data): เก็บข้อมูลผู้ใช้เพิ่มเติมที่ไม่ได้อยู่ในคุณสมบัติผู้ใช้ที่กำหนดไว้ล่วงหน้า เช่น สีและภาษาที่ผู้ใช้ชื่นชอบ +- [ข้อมูลระบุตัวตนทางโซเชียล](/user-management/user-data#social-identities): เก็บข้อมูลผู้ใช้ที่ดึงมาจากการลงชื่อเข้าใช้ด้วยโซเชียล (เช่น ลงชื่อเข้าใช้ด้วยตัวเชื่อมต่อโซเชียล) เช่น Facebook, GitHub และ WeChat +- [ข้อมูลที่กำหนดเอง](/user-management/user-data#custom-data): เก็บข้อมูลผู้ใช้เพิ่มเติมที่ไม่ได้อยู่ในคุณสมบัติผู้ใช้ที่กำหนดไว้ล่วงหน้า เช่น สีและภาษาที่ผู้ใช้ชอบ ตัวอย่างข้อมูลผู้ใช้ที่ได้จากการลงชื่อเข้าใช้ Facebook: @@ -48,7 +48,7 @@ sidebar_position: 1 } ``` -คุณสามารถค้นหาโปรไฟล์ผู้ใช้ได้ผ่าน Logto Console หรือ Logto Management API เช่น [`GET /api/users/:userId`](https://openapi.logto.io/operation/operation-getuser) +คุณสามารถค้นหาโปรไฟล์ผู้ใช้ได้โดยใช้ Logto Console หรือ Logto Management API เช่น [`GET /api/users/:userId`](https://openapi.logto.io/operation/operation-getuser) ## ข้อมูลพื้นฐาน \{#basic-data} @@ -56,13 +56,13 @@ sidebar_position: 1 ### id \{#id} -_id_ คือคีย์ที่สร้างขึ้นอัตโนมัติแบบไม่ซ้ำกันเพื่อระบุผู้ใช้ใน Logto +_id_ คือคีย์ที่สร้างขึ้นโดยอัตโนมัติและไม่ซ้ำกันเพื่อระบุผู้ใช้ใน Logto ### username \{#username} _username_ ใช้สำหรับลงชื่อเข้าใช้ด้วย _username_ และรหัสผ่าน -ค่าของมันมาจากชื่อผู้ใช้ที่ผู้ใช้ลงทะเบียนครั้งแรก อาจเป็น `null` ได้ ค่าที่ไม่ใช่ null ต้องไม่เกิน 128 ตัวอักษร ประกอบด้วยตัวอักษร ตัวเลข และขีดล่าง (`_`) เท่านั้น และต้องไม่ขึ้นต้นด้วยตัวเลข ตัวพิมพ์เล็ก/ใหญ่มีผล +ค่าของมันมาจากชื่อผู้ใช้ที่ผู้ใช้ลงทะเบียนครั้งแรก อาจเป็น `null` ได้ ค่าที่ไม่ใช่ null ต้องไม่เกิน 128 ตัวอักษร ประกอบด้วยตัวอักษร ตัวเลข และขีดล่าง (`_`) เท่านั้น และต้องไม่ขึ้นต้นด้วยตัวเลข ตัวพิมพ์เล็ก / ใหญ่มีผล ### primary_email \{#primary_email} @@ -70,11 +70,15 @@ _primary_email_ คืออีเมลของผู้ใช้ ใช้ส ค่าของมันมักมาจากอีเมลที่ผู้ใช้ลงทะเบียนครั้งแรก อาจเป็น `null` ได้ ความยาวสูงสุด 128 ตัวอักษร +เฉพาะอีเมลที่ได้รับการยืนยันจากผู้ให้บริการข้อมูลระบุตัวตนทางโซเชียลหรือ Enterprise SSO เท่านั้นที่สามารถซิงก์และบันทึกเป็น `primary_email` ได้ + ### primary_phone \{#primary_phone} _primary_phone_ คือเบอร์โทรศัพท์ของผู้ใช้ ใช้สำหรับลงชื่อเข้าใช้ด้วยเบอร์โทรศัพท์และรหัสผ่าน / รหัสยืนยันจาก SMS -ค่าของมันมักมาจากเบอร์โทรศัพท์ที่ผู้ใช้ลงทะเบียนครั้งแรก อาจเป็น `null` ได้ ถ้าไม่ใช่ null ต้องเป็นตัวเลขที่มี [รหัสประเทศ](https://en.wikipedia.org/wiki/List_of_country_calling_codes) นำหน้า (ไม่รวมเครื่องหมายบวก `+`) +ค่าของมันมักมาจากเบอร์โทรศัพท์ที่ผู้ใช้ลงทะเบียนครั้งแรก อาจเป็น `null` ได้ ค่าที่ไม่ใช่ null ต้องเป็นตัวเลขที่ขึ้นต้นด้วย [รหัสประเทศ](https://en.wikipedia.org/wiki/List_of_country_calling_codes) (ไม่รวมเครื่องหมายบวก `+`) + +เฉพาะเบอร์โทรศัพท์ที่ได้รับการยืนยันจากผู้ให้บริการข้อมูลระบุตัวตนทางโซเชียลหรือ Enterprise SSO เท่านั้นที่สามารถซิงก์และบันทึกเป็น `primary_phone` ได้ ### name \{#name} @@ -84,17 +88,17 @@ _name_ คือชื่อเต็มของผู้ใช้ ความ _avatar_ คือ URL ที่ชี้ไปยังรูปโปรไฟล์ของผู้ใช้ ความยาวสูงสุด 2048 ตัวอักษร -หากผู้ใช้ลงทะเบียนด้วยตัวเชื่อมต่อโซเชียล เช่น Google หรือ Facebook ค่านี้อาจได้มาจากข้อมูลผู้ใช้โซเชียล +หากผู้ใช้ลงทะเบียนด้วยตัวเชื่อมต่อโซเชียล เช่น Google หรือ Facebook ค่านี้อาจถูกดึงมาจากข้อมูลผู้ใช้โซเชียล :::note -คุณสมบัตินี้จะถูกแมปกับ claim `picture` ในมาตรฐาน [OpenID Connect](https://openid.net/connect/) +คุณสมบัตินี้จะถูกแมปกับ `picture` claim ในมาตรฐาน [OpenID Connect](https://openid.net/connect/) ::: ### profile \{#profile} -_profile_ เก็บ [standard claims ของ OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) เพิ่มเติมที่ไม่ได้อยู่ในคุณสมบัติของผู้ใช้ +_profile_ เก็บ [standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) ของ OpenID Connect เพิ่มเติมที่ไม่ได้อยู่ในคุณสมบัติของผู้ใช้ สามารถดู type definition ได้ที่ [ไฟล์นี้](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6) ตัวอย่าง type definition: @@ -124,37 +128,37 @@ type UserProfile = Partial<{ :::note -`Partial` หมายถึงทุก property เป็น optional +`Partial` หมายถึงคุณสมบัติทั้งหมดเป็นตัวเลือก (optional) ::: -ความแตกต่างจาก standard claims อื่น ๆ คือ property ใน `profile` จะถูกใส่ใน [ID token](https://auth.wiki/id-token) หรือ response ของ userinfo endpoint เฉพาะเมื่อค่าของมันไม่ว่างเปล่า ในขณะที่ standard claims อื่น ๆ จะคืนค่า `null` หากค่าว่าง +ความแตกต่างจาก standard claims อื่น ๆ คือ คุณสมบัติใน `profile` จะถูกใส่ใน [ID token](https://auth.wiki/id-token) หรือ response ของ userinfo endpoint เฉพาะเมื่อค่าของมันไม่ว่างเปล่า ในขณะที่ standard claims อื่น ๆ จะคืนค่า `null` หากค่าว่าง ### application_id \{#application_id} -ค่า _application_id_ มาจากแอปพลิเคชันที่ผู้ใช้ลงชื่อเข้าใช้ครั้งแรก อาจเป็น `null` ได้ +ค่าของ _application_id_ มาจากแอปพลิเคชันที่ผู้ใช้ลงชื่อเข้าใช้ครั้งแรก อาจเป็น `null` ได้ ### last_sign_in_at \{#last_sign_in_at} -_last_sign_in_at_ คือ timestamp พร้อม timezone ที่ผู้ใช้ลงชื่อเข้าใช้ล่าสุด +_last_sign_in_at_ คือ timestamp พร้อม timezone เมื่อผู้ใช้ลงชื่อเข้าใช้ครั้งล่าสุด ### created_at \{#created_at} -_created_at_ คือ timestamp พร้อม timezone ที่ผู้ใช้ลงทะเบียนบัญชี +_created_at_ คือ timestamp พร้อม timezone เมื่อผู้ใช้ลงทะเบียนบัญชี ### updated_at \{#updated_at} -_updated_at_ คือ timestamp พร้อม timezone ที่ข้อมูลโปรไฟล์ผู้ใช้ถูกอัปเดตล่าสุด +_updated_at_ คือ timestamp พร้อม timezone เมื่อข้อมูลโปรไฟล์ผู้ใช้ถูกอัปเดตล่าสุด ### has_password \{#has_password} -_has_password_ เป็นค่า boolean ที่ระบุว่าผู้ใช้มีรหัสผ่านหรือไม่ คุณสามารถดูและจัดการสถานะนี้ รวมถึงตั้งค่าหรือรีเซ็ตรหัสผ่านใหม่ได้ที่หน้า Console > User management +_has_password_ เป็นค่า boolean ที่ระบุว่าผู้ใช้มีรหัสผ่านหรือไม่ คุณสามารถดูและจัดการสถานะนี้ รวมถึงตั้งค่าหรือรีเซ็ตรหัสผ่านใหม่ได้ที่หน้า Console > การจัดการผู้ใช้ ### password_encrypted \{#password_encrypted} _password_encrypted_ ใช้เก็บรหัสผ่านที่ถูกเข้ารหัสของผู้ใช้ -ค่าของมันมาจากรหัสผ่านที่ผู้ใช้ลงทะเบียนครั้งแรก อาจเป็น `null` ได้ ถ้าไม่ใช่ null เนื้อหาก่อนเข้ารหัสต้องมีอย่างน้อย 6 ตัวอักษร +ค่าของมันมาจากรหัสผ่านที่ผู้ใช้ลงทะเบียนครั้งแรก อาจเป็น `null` ได้ หากไม่ใช่ null เนื้อหาก่อนเข้ารหัสต้องมีอย่างน้อย 6 ตัวอักษร ### password_encryption_method \{#password_encryption_method} @@ -162,7 +166,7 @@ _password_encryption_method_ ใช้สำหรับเข้ารหัส Logto ใช้ [Argon2](https://en.wikipedia.org/wiki/Argon2) ที่ implement โดย [node-argon2](https://github.com/ranisalt/node-argon2) เป็นวิธีเข้ารหัสโดยค่าเริ่มต้น ดูรายละเอียดเพิ่มเติมได้ใน reference -ตัวอย่าง _password_encrypted_ และ _password_encryption_method_ ของผู้ใช้ที่มีรหัสผ่าน `123456`: +ตัวอย่าง _password_encrypted_ และ _password_encryption_method_ ของผู้ใช้ที่มีรหัสผ่านเป็น `123456`: ```json { @@ -173,13 +177,13 @@ Logto ใช้ [Argon2](https://en.wikipedia.org/wiki/Argon2) ที่ impleme ### is_suspended \{#is_suspended} -_is_suspended_ เป็นค่า boolean ที่ระบุว่าผู้ใช้ถูกระงับหรือไม่ สามารถจัดการค่าได้โดยเรียก [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) หรือใช้ Logto Console +_is_suspended_ เป็นค่า boolean ที่ระบุว่าผู้ใช้ถูกระงับหรือไม่ ค่านี้สามารถจัดการได้โดยเรียก [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) หรือใช้ Logto Console เมื่อผู้ใช้ถูกระงับ โทเค็นรีเฟรชที่ได้รับก่อนหน้าจะถูกเพิกถอนทันที และผู้ใช้จะไม่สามารถยืนยันตัวตนกับ Logto ได้อีก ### mfa_verification_factors \{#mfa_verification_factors} -_mfa_verification_factors_ คือ array ที่แสดงรายการวิธี [การยืนยันตัวตนหลายปัจจัย (MFA)](/end-user-flows/mfa) ที่เชื่อมโยงกับบัญชีผู้ใช้ ค่าที่เป็นไปได้ ได้แก่ _Totp_ (แอป OTP), _WebAuthn_ (Passkey), และ _BackupCode_ +_mfa_verification_factors_ เป็น array ที่แสดงรายการ [การยืนยันตัวตนหลายปัจจัย (MFA)](/end-user-flows/mfa) ที่เชื่อมโยงกับบัญชีผู้ใช้ ค่าที่เป็นไปได้ ได้แก่ _Totp_ (OTP จากแอป Authenticator), _WebAuthn_ (Passkey), และ _BackupCode_ ```tsx mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; @@ -187,17 +191,17 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; ## ข้อมูลระบุตัวตนทางโซเชียล \{#social-identities} -_identities_ เก็บข้อมูลผู้ใช้ที่ได้จาก [การลงชื่อเข้าใช้โซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in) (เช่น ลงชื่อเข้าใช้ด้วย [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors)) _identities_ ของผู้ใช้แต่ละคนจะถูกเก็บใน JSON object แยกกัน +_identities_ เก็บข้อมูลผู้ใช้ที่ดึงมาจาก [การลงชื่อเข้าใช้ด้วยโซเชียล](/end-user-flows/sign-up-and-sign-in/social-sign-in) (เช่น ลงชื่อเข้าใช้ด้วย [ตัวเชื่อมต่อโซเชียล](/connectors/social-connectors)) _identities_ ของผู้ใช้แต่ละคนจะถูกเก็บใน JSON object แยกกัน ข้อมูลผู้ใช้จะแตกต่างกันไปตามผู้ให้บริการข้อมูลระบุตัวตนทางโซเชียล (เช่น แพลตฟอร์มโซเชียลเน็ตเวิร์ก) โดยปกติจะประกอบด้วย: - _target_ ของผู้ให้บริการ เช่น "facebook" หรือ "google" - รหัสผู้ใช้เฉพาะสำหรับผู้ให้บริการนี้ - ชื่อผู้ใช้ -- อีเมลที่ยืนยันแล้วของผู้ใช้ +- อีเมลที่ได้รับการยืนยันของผู้ใช้ - รูปโปรไฟล์ของผู้ใช้ -บัญชีผู้ใช้อาจเชื่อมโยงกับผู้ให้บริการข้อมูลระบุตัวตนทางโซเชียลหลายรายผ่านการลงชื่อเข้าใช้โซเชียล ข้อมูลที่ได้จากแต่ละผู้ให้บริการจะถูกเก็บใน object _identities_ +บัญชีผู้ใช้อาจเชื่อมโยงกับผู้ให้บริการข้อมูลระบุตัวตนทางโซเชียลหลายรายผ่านการลงชื่อเข้าใช้โซเชียล ข้อมูลที่ดึงมาจากแต่ละผู้ให้บริการจะถูกเก็บใน object _identities_ ตัวอย่าง _identities_ ของผู้ใช้ที่ลงชื่อเข้าใช้ทั้ง Google และ Facebook: @@ -226,9 +230,9 @@ _identities_ เก็บข้อมูลผู้ใช้ที่ได้ ## ข้อมูลระบุตัวตน SSO \{#sso-identities} -_sso_identities_ เก็บข้อมูลผู้ใช้ที่ได้จาก [SSO สำหรับองค์กร (SSO)](/end-user-flows/enterprise-sso) (เช่น Single Sign-On login ด้วย [ตัวเชื่อมต่อองค์กร](/connectors/enterprise-connectors)) _ssoIdentities_ ของผู้ใช้แต่ละคนจะถูกเก็บใน JSON object แยกกัน +_sso_identities_ เก็บข้อมูลผู้ใช้ที่ดึงมาจาก [SSO สำหรับองค์กร (SSO)](/end-user-flows/enterprise-sso) (เช่น Single Sign-On login ด้วย [ตัวเชื่อมต่อองค์กร](/connectors/enterprise-connectors)) _ssoIdentities_ ของผู้ใช้แต่ละคนจะถูกเก็บใน JSON object แยกกัน -ข้อมูลที่ซิงค์จากผู้ให้บริการ SSO ขึ้นอยู่กับ scope ที่ตั้งค่าไว้ในตัวเชื่อมต่อองค์กร นี่คือตัวอย่าง type definition ของ TypeScript: +ข้อมูลที่ซิงก์จากผู้ให้บริการ SSO ขึ้นอยู่กับขอบเขต (scopes) ที่กำหนดไว้ในตัวเชื่อมต่อองค์กร ตัวอย่าง TypeScript type definition: ```ts type SSOIdentity = { @@ -244,9 +248,9 @@ _custom_data_ เก็บข้อมูลผู้ใช้เพิ่มเ คุณสามารถใช้ _custom_data_ เพื่อทำสิ่งต่อไปนี้: -- บันทึกว่าผู้ใช้ได้ดำเนินการบางอย่างแล้วหรือไม่ เช่น เคยเห็นหน้าต้อนรับแล้ว -- เก็บข้อมูลเฉพาะแอปในโปรไฟล์ผู้ใช้ เช่น ภาษาที่ผู้ใช้ชื่นชอบและโหมดการแสดงผลต่อแอป -- เก็บข้อมูลอื่น ๆ ที่เกี่ยวข้องกับผู้ใช้ +- บันทึกว่าผู้ใช้ได้ทำกิจกรรมเฉพาะหรือยัง เช่น ดูหน้าต้อนรับแล้วหรือไม่ +- เก็บข้อมูลเฉพาะแอปในโปรไฟล์ผู้ใช้ เช่น ภาษาและรูปแบบที่ผู้ใช้เลือกต่อแอป +- เก็บข้อมูลอื่น ๆ ที่เกี่ยวข้องกับผู้ใช้ตามต้องการ ตัวอย่าง _custom_data_ ของผู้ใช้แอดมินใน Logto: @@ -274,26 +278,26 @@ _custom_data_ ของผู้ใช้แต่ละคนจะถูกเ ::: -ข้อมูลที่กำหนดเองสามารถเข้าถึงได้ผ่าน [Custom JWT token claims](/developers/custom-token-claims) หลังจากผู้ใช้ลงชื่อเข้าใช้ และ JWT token จะถูกเข้ารหัสแบบ base64 (ไม่ได้เข้ารหัสลับ) และถูกส่งผ่านเครือข่ายบ่อยครั้ง ทำให้ข้อมูลสำคัญอาจถูกเปิดเผยได้ง่าย +ข้อมูลที่กำหนดเองสามารถเข้าถึงได้ผ่าน [Custom JWT token claims](/developers/custom-token-claims) หลังจากผู้ใช้ลงชื่อเข้าใช้ และ JWT token จะถูกเข้ารหัสแบบ base64 (ไม่ใช่การเข้ารหัสลับ) และถูกส่งผ่านเครือข่ายบ่อยครั้ง ทำให้ข้อมูลสำคัญอาจถูกเปิดเผยได้ง่าย -คุณอาจดึงโปรไฟล์ผู้ใช้ที่มี _custom_data_ ผ่าน [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) และส่งไปยังแอป frontend หรือบริการ backend ภายนอก ดังนั้นการใส่ข้อมูลสำคัญใน _custom_data_ อาจทำให้ข้อมูลรั่วไหล +คุณอาจดึงโปรไฟล์ผู้ใช้ที่มี _custom_data_ โดยใช้ [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) และส่งไปยังแอป frontend หรือบริการ backend ภายนอก ดังนั้นการใส่ข้อมูลสำคัญใน _custom_data_ อาจทำให้ข้อมูลรั่วไหล -หากคุณยังต้องการใส่ข้อมูลสำคัญใน _custom_data_ ขอแนะนำให้เข้ารหัสก่อน และให้เข้ารหัส/ถอดรหัสในระบบที่เชื่อถือได้ เช่น backend ของคุณเท่านั้น หลีกเลี่ยงการทำใน frontend เพื่อลดความเสียหายหาก _custom_data_ ของผู้ใช้รั่วไหลโดยไม่ตั้งใจ +หากคุณยังต้องการใส่ข้อมูลสำคัญใน _custom_data_ ขอแนะนำให้เข้ารหัสก่อน และให้เข้ารหัส / ถอดรหัสในระบบที่เชื่อถือได้ เช่น backend ของคุณเท่านั้น หลีกเลี่ยงการทำใน frontend เพื่อลดความเสียหายหาก _custom_data_ ของผู้ใช้รั่วไหลโดยไม่ตั้งใจ **วิธีเก็บและอัปเดตข้อมูล custom data ของผู้ใช้** -- ใช้ฟีเจอร์ [เก็บข้อมูลโปรไฟล์ผู้ใช้](/end-user-flows/collect-user-profile) เพื่อรวบรวม custom data ระหว่างการสมัครสมาชิก +- ใช้ฟีเจอร์ [เก็บโปรไฟล์ผู้ใช้](/end-user-flows/collect-user-profile) เพื่อรวบรวม custom data ระหว่างการสมัครสมาชิก - ใช้ [Account API](/end-user-flows/account-settings/by-account-api) เพื่อพัฒนาโปรไฟล์หรือการตั้งค่าบัญชีของผู้ใช้ปลายทาง - ใช้ [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) เพื่อดึงข้อมูลผู้ใช้ทั้งหมด - ใช้ [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) เพื่ออัปเดต _custom_data_ ของผู้ใช้ -- ใช้ [Management API](/user-management/manage-users/#manage-via-logto-management-api) สำหรับการจัดการผู้ใช้หรือ flow ขั้นสูง +- ใช้ [Management API](/user-management/manage-users/#manage-via-logto-management-api) สำหรับการจัดการผู้ใช้หรือโฟลว์ custom ขั้นสูง - ใช้ [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) เพื่อดึงข้อมูลผู้ใช้ทั้งหมด - ใช้ [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) เพื่ออัปเดต _custom_data_ ของผู้ใช้ -- ทีมสนับสนุนของคุณสามารถอัปเดต _custom_data_ ของผู้ใช้ได้โดยตรงใน Console > User management ดูเพิ่มเติมเกี่ยวกับ [การดูและอัปเดตโปรไฟล์ผู้ใช้](/user-management/manage-users/#view-and-update-the-user-profile) +- ทีมสนับสนุนของคุณสามารถอัปเดต _custom_data_ ของผู้ใช้ได้โดยตรงใน Console > การจัดการผู้ใช้ ดูเพิ่มเติมเกี่ยวกับ [การดูและอัปเดตโปรไฟล์ผู้ใช้](/user-management/manage-users/#view-and-update-the-user-profile) โปรดอัปเดตอย่างระมัดระวัง การอัปเดต _custom_data_ ของผู้ใช้จะเขียนทับข้อมูลเดิมทั้งหมดใน storage -ตัวอย่าง หาก input ที่ใช้เรียก API อัปเดต _custom_data_ เป็นดังนี้ (สมมติว่า _custom_data_ เดิมเป็นตัวอย่างข้างต้น): +ตัวอย่าง หาก input ที่ใช้เรียก API อัปเดต _custom_data_ เป็นแบบนี้ (สมมติว่า _custom_data_ เดิมเป็นตัวอย่างก่อนหน้า): ```json { @@ -319,26 +323,26 @@ _custom_data_ ของผู้ใช้แต่ละคนจะถูกเ คอลัมน์ในตารางผู้ใช้ของฐานข้อมูลต่อไปนี้ (ยกเว้น _password_encrypted_ และ _password_encryption_method_) จะแสดงในโปรไฟล์ผู้ใช้ ซึ่งหมายความว่าคุณสามารถค้นหาด้วย [Management API](https://openapi.logto.io/operation/operation-getuser) ได้ -| Name | Type | Description | Unique | Required | -| ----------------------------------------------------------------------------------- | --------- | ----------------------------------------- | ------ | -------- | -| [id](/user-management/user-data#id) | string | รหัสระบุเฉพาะ | ✅ | ✅ | -| [username](/user-management/user-data#username) | string | ชื่อผู้ใช้สำหรับลงชื่อเข้าใช้ | ✅ | ❌ | -| [primary_email](/user-management/user-data#primary_email) | string | อีเมลหลัก | ✅ | ❌ | -| [primary_phone](/user-management/user-data#primary_phone) | string | เบอร์โทรศัพท์หลัก | ✅ | ❌ | -| [name](/user-management/user-data#name) | string | ชื่อเต็ม | ❌ | ❌ | -| [avatar](/user-management/user-data#avatar) | string | URL รูปโปรไฟล์ผู้ใช้ | ❌ | ❌ | -| [profile](/user-management/user-data#profile) | object | โปรไฟล์ผู้ใช้ | ❌ | ✅ | -| [identities](/user-management/user-data#social-identities) | object | ข้อมูลผู้ใช้จากการลงชื่อเข้าใช้โซเชียล | ❌ | ✅ | -| [custom_data](/user-management/user-data#custom-data) | object | ข้อมูลเพิ่มเติมใน property ที่ปรับแต่งได้ | ❌ | ✅ | -| [application_id](/user-management/user-data#application_id) | string | รหัสแอปที่ผู้ใช้ลงทะเบียนครั้งแรก | ❌ | ✅ | -| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | เวลาที่ผู้ใช้ลงชื่อเข้าใช้ล่าสุด | ❌ | ✅ | -| [password_encrypted](/user-management/user-data#password_encrypted) | string | รหัสผ่านที่เข้ารหัสแล้ว | ❌ | ❌ | -| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | วิธีเข้ารหัสรหัสผ่าน | ❌ | ❌ | -| [is_suspended](/user-management/user-data#is_suspended) | bool | สถานะระงับผู้ใช้ | ❌ | ✅ | -| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | วิธีการยืนยันตัวตนหลายปัจจัย (MFA) | ❌ | ✅ | - -- **Unique**: รับประกัน [ความไม่ซ้ำ](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS) ของค่าที่ป้อนใน property ของตารางฐานข้อมูล -- **Required**: รับประกันว่าค่าที่ป้อนใน property ของตารางฐานข้อมูลจะไม่เป็น `null` +| ชื่อ | ประเภท | คำอธิบาย | ไม่ซ้ำ | จำเป็น | +| ----------------------------------------------------------------------------------- | --------- | -------------------------------------- | ------ | ------ | +| [id](/user-management/user-data#id) | string | รหัสระบุไม่ซ้ำ | ✅ | ✅ | +| [username](/user-management/user-data#username) | string | ชื่อผู้ใช้สำหรับลงชื่อเข้าใช้ | ✅ | ❌ | +| [primary_email](/user-management/user-data#primary_email) | string | อีเมลหลัก | ✅ | ❌ | +| [primary_phone](/user-management/user-data#primary_phone) | string | เบอร์โทรศัพท์หลัก | ✅ | ❌ | +| [name](/user-management/user-data#name) | string | ชื่อเต็ม | ❌ | ❌ | +| [avatar](/user-management/user-data#avatar) | string | URL รูปโปรไฟล์ผู้ใช้ | ❌ | ❌ | +| [profile](/user-management/user-data#profile) | object | โปรไฟล์ผู้ใช้ | ❌ | ✅ | +| [identities](/user-management/user-data#social-identities) | object | ข้อมูลผู้ใช้จากการลงชื่อเข้าใช้โซเชียล | ❌ | ✅ | +| [custom_data](/user-management/user-data#custom-data) | object | ข้อมูลเพิ่มเติมในคุณสมบัติที่กำหนดเอง | ❌ | ✅ | +| [application_id](/user-management/user-data#application_id) | string | รหัสแอปที่ผู้ใช้ลงทะเบียนครั้งแรก | ❌ | ✅ | +| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | เวลาที่ผู้ใช้ลงชื่อเข้าใช้ล่าสุด | ❌ | ✅ | +| [password_encrypted](/user-management/user-data#password_encrypted) | string | รหัสผ่านที่เข้ารหัส | ❌ | ❌ | +| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | วิธีเข้ารหัสรหัสผ่าน | ❌ | ❌ | +| [is_suspended](/user-management/user-data#is_suspended) | bool | สถานะระงับผู้ใช้ | ❌ | ✅ | +| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | ปัจจัยการยืนยันตัวตนหลายปัจจัย (MFA) | ❌ | ✅ | + +- **ไม่ซ้ำ**: รับประกัน [ความไม่ซ้ำ](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS) ของค่าที่กรอกในคุณสมบัติของตารางฐานข้อมูล +- **จำเป็น**: รับประกันว่าค่าที่กรอกในคุณสมบัติของตารางฐานข้อมูลจะไม่เป็น `null` ## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index 142d7524b75..b2aea8b168f 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -15,7 +15,7 @@ export const resource = 'https://api.your-app.com'; 使用 Logto 的基于角色的访问控制 (RBAC) 保护产品范围内的 API。分配全局角色和权限,以控制你应用中所有用户和客户端的访问。 -## 什么是全局 API 资源? \{#what-are-global-api-resources} +## 什么是全局 API 资源?\{#what-are-global-api-resources} 全局 API 资源是你应用中所有用户都可以访问的端点或服务,无论属于哪个组织或租户。这些通常是面向公众的 API、核心产品服务,或任何不限定于特定组织的端点。 @@ -23,29 +23,29 @@ export const resource = 'https://api.your-app.com'; - 在你的用户群体中共享的公共 API 或端点。 - 不绑定多租户的微服务。 -- 所有客户都在使用的核心应用 API(如 `/api/users`、`/api/products`)。 +- 所有客户都使用的核心应用 API(如 `/api/users`、`/api/products`)。 Logto 允许你结合 OAuth 2.1 和灵活的基于角色的访问控制来保护这些 API。 -## 在 Logto 中的工作原理 \{#how-it-works-in-logto} +## 在 Logto 中如何工作 \{#how-it-works-in-logto} - **API 资源和权限是全局注册的**:你想要保护的每个 API 都用唯一的资源指示器(URI)和一组控制访问的权限(scopes)进行定义。 - **访问由全局角色控制**:你可以将权限分配给角色,然后将角色分配给用户或客户端。 -- **与组织级权限分离**:全局 API 资源没有组织上下文。但如有需要,可以与组织角色结合使用,为访问提供额外的上下文。要保护组织级 API,请参见 [保护组织级 API 资源](/authorization/organization-level-api-resources)。 +- **与组织级权限分离**:全局 API 资源没有组织上下文。但如有需要,可以与组织角色结合使用,提供额外的上下文层。要保护组织级 API,请参见 [保护组织级 API 资源](/authorization/organization-level-api-resources)。 全局 API 资源 RBAC ### 实现概览 \{#implementation-overview} -1. **注册你的 API 资源**,并在 Logto 中定义其权限。 +1. **注册你的 API 资源** 并在 Logto 中定义其权限。 2. **定义角色**,为访问 API 分配所需权限。 -3. **分配角色**给用户或客户端。 -4. **使用 OAuth 2.0 授权流程**获取 API 的访问令牌(resource 参数必须与注册的 API 标识符一致)。 -5. **在你的 API 中验证访问令牌**以强制执行权限。 +3. **分配角色** 给用户或客户端。 +4. **使用 OAuth 2.0 授权流程** 获取 API 的访问令牌(resource 参数必须与注册的 API 标识符一致)。 +5. **在你的 API 中验证访问令牌**,以强制执行权限。 ### 理解资源指示器 \{#understanding-resource-indicators} -Logto 按照 [RFC 8707: OAuth 2.0 的资源指示器](https://www.rfc-editor.org/rfc/rfc8707.html) 建模 API 资源。**资源指示器**是唯一标识所请求目标 API 或服务的 URI。 +Logto 按照 [RFC 8707: OAuth 2.0 的资源指示器](https://www.rfc-editor.org/rfc/rfc8707.html) 建模 API 资源。**资源指示器** 是唯一标识所请求目标 API 或服务的 URI。 **要点** @@ -58,23 +58,23 @@ Logto 按照 [RFC 8707: OAuth 2.0 的资源指示器](https://www.rfc-editor.org - Management API: `https://my-tenant.logto.app/api` - 自定义全局 API: `https://api.yourapp.com` -### 授权 (Authorization) 流程:认证 (Authentication) 并保护你的 API \{#authorization-flow-authenticating-and-securing-your-api} +### 授权流程:认证 (Authentication) 并保护你的 API \{#authorization-flow-authenticating-and-securing-your-api} -下述流程适用于交互式用户认证 (Authentication)(浏览器 / 应用)和后端机器对机器 (M2M) 场景。 +以下流程适用于交互式用户认证 (Authentication)(浏览器 / 应用)和后端机器对机器 (M2M) 场景。 -请注意,该流程未包含所有必需参数或请求头的详细信息,重点展示关键步骤。继续阅读以了解实际流程。 +请注意,该流程未包含所有必需参数或头信息的详细说明,重点展示关键步骤。继续阅读以了解实际流程。 ```mermaid sequenceDiagram - participant Client + participant Client as 客户端 participant Logto participant API as API 资源 alt 用户认证 (Authentication) Client->>Logto: GET /oidc/auth Logto->>Logto: 重定向用户到登录页面 - Logto->>Client: 登录后重定向并返回 `authorization_code` - alt 使用 authorization_code 授权 (Authorization) 码模式 + Logto->>Client: 重定向回带有 `authorization_code` + alt 使用 authorization_code 授权码模式 Client->>Logto: POST /oidc/token,带 `grant_type=authorization_code`
和 `resource` 参数 else 使用 refresh_token 模式 Client->>Logto: POST /oidc/token,带 `grant_type=authorization_code` @@ -87,12 +87,12 @@ sequenceDiagram Logto->>Client: 返回访问令牌 (访问令牌 (Access token),JSON Web Token) Client->>API: 使用 Bearer 令牌请求 - API->>API: 验证访问令牌 (访问令牌 (Access token)) + API->>API: 验证访问令牌 alt 令牌有效 - API->>Client: 返回受保护资源数据 + API->>Client: 返回受保护的资源数据 else 令牌无效 - API->>Client: 401 未授权 (Unauthorized) + API->>Client: 401 未授权 end ``` @@ -119,43 +119,43 @@ _用户认证 (Authentication) = 浏览器 / 应用。M2M = 使用客户端凭 完整配置步骤见 [使用全局角色](/authorization/role-based-access-control#configure-global-roles)。 -### 获取全局 API 资源的访问令牌 (访问令牌 (Access token)) \{#obtain-access-tokens-for-global-api-resources} +### 获取全局 API 资源的访问令牌 \{#obtain-access-tokens-for-global-api-resources} -在访问全局 API 资源前,你的客户端必须获取访问令牌 (访问令牌 (Access token))。Logto 会为全局 API 资源签发 [JSON Web Token (JWT)](https://auth.wiki/jwt) 作为访问令牌 (访问令牌 (Access token))。这通常通过 [OAuth 2.0 授权码流程](https://auth.wiki/authorization-code-flow)、[刷新令牌 (刷新令牌 (Refresh token)) 流程](https://auth.wiki/refresh-token) 或 [客户端凭证流程](https://auth.wiki/client-credentials-flow) 完成。 +在访问全局 API 资源前,你的客户端必须获取访问令牌。Logto 会为全局 API 资源签发 [JSON Web Token (JWT)](https://auth.wiki/jwt) 作为访问令牌。通常使用 [OAuth 2.0 授权码流程](https://auth.wiki/authorization-code-flow)、[刷新令牌流程](https://auth.wiki/refresh-token) 或 [客户端凭证流程](https://auth.wiki/client-credentials-flow) 完成。 #### 授权码或刷新令牌流程 \{#authorization-code-or-refresh-token-flow} -所有 Logto 官方 SDK 都原生支持通过刷新令牌 (刷新令牌 (Refresh token)) 流程获取全局 API 资源的访问令牌 (访问令牌 (Access token))。你也可以使用标准 OAuth 2.0 / OIDC 客户端库实现该流程。 +所有 Logto 官方 SDK 都原生支持使用刷新令牌流程获取全局 API 资源的访问令牌。你也可以用标准 OAuth 2.0 / OIDC 客户端库实现该流程。 -初始化 Logto 客户端时,将资源指示器添加到 `resources` 参数(数组),再将所需权限(scopes)添加到 `scopes` 参数。 +初始化 Logto 客户端时,将资源指示器添加到 `resources` 参数(数组),然后将所需权限(scopes)添加到 `scopes` 参数。 -用户认证 (Authentication) 后,在请求访问令牌 (访问令牌 (Access token)) 时,将资源指示器传入 `resource` 参数或类似参数(如调用 `getAccessToken()`)。 +用户认证 (Authentication) 后,请在请求访问令牌时(如调用 `getAccessToken()`)传递资源指示器到 `resource` 参数或类似参数中。 -各 SDK 详情见 [快速上手](/quick-starts)。 +各 SDK 详情见 [快速开始](/quick-starts)。 - + 配置 OAuth 2.0 客户端或初始化授权码流程时,确保在授权请求中包含 `resource` 参数和所需 scopes。 -部分库可能不原生支持 `resource` 参数,但通常允许你在授权请求中传递额外参数。请查阅你的库文档获取详情。 +部分库可能不原生支持 `resource` 参数,但通常允许你在授权请求中传递额外参数。具体请查阅你的库文档。 以下是带 `resource` 和 `scope` 参数的授权请求非规范示例: -用户认证 (Authentication) 后,你将收到授权码。通过向 Logto 的 `/oidc/token` 端点发起 POST 请求,并在请求体中包含 `resource` 参数,将该授权码兑换为访问令牌 (访问令牌 (Access token))。 +用户认证 (Authentication) 后,你将收到授权码。通过向 Logto 的 `/oidc/token` 端点发起 POST 请求,并在请求体中包含 `resource` 参数,将该授权码兑换为访问令牌。 以下是使用授权码模式的令牌请求非规范示例: -你也可以使用 `refresh_token` 模式在无需用户交互的情况下获取新访问令牌 (访问令牌 (Access token)),只要在请求中包含 `resource` 参数即可。 +你也可以使用 `refresh_token` 模式,在请求中包含 `resource` 参数,无需用户交互即可获取新访问令牌。 -以下是使用刷新令牌 (刷新令牌 (Refresh token)) 模式的令牌请求非规范示例: +以下是使用刷新令牌模式的令牌请求非规范示例: @@ -164,7 +164,7 @@ _用户认证 (Authentication) = 浏览器 / 应用。M2M = 使用客户端凭 #### 客户端凭证流程 \{#client-credentials-flow} -对于机器对机器 (M2M) 场景,你可以使用客户端凭证流程获取全局 API 资源的访问令牌 (访问令牌 (Access token))。只需向 Logto 的 `/oidc/token` 端点发起 POST 请求,使用你的客户端 ID 和密钥即可请求访问令牌 (访问令牌 (Access token))。 +对于机器对机器 (M2M) 场景,你可以使用客户端凭证流程获取全局 API 资源的访问令牌。通过向 Logto 的 `/oidc/token` 端点发起 POST 请求,使用你的客户端 ID 和密钥请求访问令牌。 请求中需包含两个关键参数: @@ -178,19 +178,19 @@ _用户认证 (Authentication) = 浏览器 / 应用。M2M = 使用客户端凭 scope="read:products write:products" /> -### 在你的 API 中验证 JWT 访问令牌 (访问令牌 (Access token)) \{#validating-jwt-access-tokens-in-your-api} +### 在你的 API 中验证 JWT 访问令牌 \{#validating-jwt-access-tokens-in-your-api} Logto 签发的 JWT 包含你的 API 可用于强制授权 (Authorization) 的声明 (Claims)。 -当你的 API 收到带有 Logto 签发访问令牌 (访问令牌 (Access token)) 的请求时,你应: +当你的 API 收到带有 Logto 签发的访问令牌的请求时,你应: - 验证令牌签名(使用 Logto 的 JWKs)。 - 确认令牌未过期(`exp` 声明 (Claim))。 - 检查 `iss`(发行者 (Issuer))是否与你的 Logto 端点一致。 -- 确认 `aud`(受众 (Audience))是否与你注册的 API 资源标识符一致(如 `https://api.yourapp.com`)。 +- 确保 `aud`(受众 (Audience))与你注册的 API 资源标识符一致(如 `https://api.yourapp.com`)。 - 拆分 `scope` 声明 (Claim)(以空格分隔),检查所需权限。 -分步和特定语言指南见 [如何验证访问令牌 (访问令牌 (Access token))](/authorization/validate-access-tokens)。 +分步和特定语言指南见 [如何验证访问令牌](/authorization/validate-access-tokens)。 ### 可选:处理用户权限变更 \{#optional-handle-user-permission-change} @@ -200,17 +200,17 @@ Logto 签发的 JWT 包含你的 API 可用于强制授权 (Authorization) 的 ## 最佳实践与安全建议 \{#best-practices-and-security-tips} -- **权限应以业务为驱动**:使用清晰的名称映射到实际操作。 -- **令牌过期时间应短**:降低令牌泄露风险。 +- **权限应以业务为驱动**:使用能映射到实际操作的清晰名称。 +- **令牌过期时间应短**:如果令牌泄露可降低风险。 - **限制授予的权限 (Scopes)**:只给令牌实际需要的权限。 -- **使用受众 (Audience) 限制**:始终验证 `aud` 声明 (Claim) 以防止滥用。 +- **使用受众限制**:始终验证 `aud` 声明 (Claim),防止滥用。 ## 常见问题 \{#faqs}
-### 如果我的客户端不支持 resource 参数怎么办? \{#what-if-my-client-doesn-t-support-the-resource-parameter} +### 如果我的客户端不支持 resource 参数怎么办?\{what-if-my-client-doesn-t-support-the-resource-parameter} \{#what-if-my-client-doesn-t-support-the-resource-parameter} @@ -221,23 +221,23 @@ Logto 签发的 JWT 包含你的 API 可用于强制授权 (Authorization) 的
-### 为什么我的 API 返回 401 未授权 (Unauthorized)? \{#why-do-i-get-401-unauthorized-from-my-api} +### 为什么我的 API 返回 401 未授权?\{why-do-i-get-401-unauthorized-from-my-api} \{#why-do-i-get-401-unauthorized-from-my-api} 请检查以下常见问题: -- **令牌签名**:确认你的后端正在从 Logto 获取正确的 JWKs +- **令牌签名**:确认你的后端从 Logto 获取了正确的 JWKs - **令牌过期**:确保令牌未过期(`exp` 声明 (Claim)) - **受众 (Audience)**:确认 `aud` 声明 (Claim) 与你注册的 API 资源指示器一致 -- **所需权限 (Scopes)**:确认令牌在 `scope` 声明 (Claim) 中包含必要权限 +- **所需权限 (Scopes)**:确认令牌的 `scope` 声明 (Claim) 包含所需权限
-### 如何在没有完整客户端的情况下测试? \{#how-do-i-test-without-a-full-client} +### 如何在没有完整客户端的情况下测试?\{how-do-i-test-without-a-full-client} \{#how-do-i-test-without-a-full-client} @@ -245,11 +245,41 @@ Logto 签发的 JWT 包含你的 API 可用于强制授权 (Authorization) 的
+
+ + +### 请求权限时可以使用 scope 前缀或简写吗?\{can-i-use-scope-prefixes-or-shortened-versions} \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +不可以。Scope 名称必须**完全匹配**你在 API 资源中定义的权限名称。前缀和简写不能作为通配符使用。 + +**示例:** + +如果你的 API 资源定义了: + +- `read:elections` +- `write:elections` + +你必须请求: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +这样**不会生效**: + +```swift +scopes: ["read", "write"] // ❌ 不匹配权限名称 +``` + +
+ ## 延伸阅读 \{#further-reading} -如何验证访问令牌 (访问令牌 (Access token)) +如何验证访问令牌 RBAC 实践:为你的应用实现安全授权 (Authorization) 自定义令牌声明 (Claims) -RFC 8707:资源指示器 +RFC 8707: 资源指示器 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index 71c04e88dfa..2436cb0d579 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -4,7 +4,7 @@ sidebar_position: 4 # 本地化语言 -Logto 支持广泛的预定义语言,并提供 113 个额外的语言标签。这一强大的工具让你可以通过创建和管理自己的语言选项与翻译,定制登录体验。 +Logto 支持多种预定义语言,并提供 113 个额外的语言标签。这一强大的工具让你可以通过创建和管理自己的语言选项与翻译,自定义登录体验。 ## 在 Logto 控制台中的自定义步骤 \{#customization-steps-in-logto-console} @@ -14,18 +14,18 @@ Logto 支持广泛的预定义语言,并提供 113 个额外的语言标签。 2. **管理语言**:点击“管理语言”按钮,进入你的语言库。 - **编辑现有语言**:自定义 Logto 提供的语言的翻译。这些语言无法删除,但你的更改会覆盖默认值。 - **添加新语言**:点击“添加语言”按钮,选择一个语言标签,填写你的翻译,然后保存更改以添加新语言。 -3. **启用自动检测**:启用后,会根据用户设备设置自动以其偏好语言显示登录页面。 -4. **设置默认语言**:你可以从语言库中选择一个默认语言。当检测到的用户语言不在当前语言库中时,将使用该默认语言。 +3. **启用自动检测**:启用后,会根据用户设备设置自动以其首选语言显示登录页面。 +4. **设置默认语言**:你可以从语言库中选择一个默认语言。当检测到的用户语言不在当前语言库中时,将使用默认语言。 以下是管理语言时需要了解的一些关键术语: -| 定义 | 描述 | -| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -| 语言标签 | 语言标签用于标识内容的语言。一个语言标签由语言代码(如 en、fr、zh)和国家 / 地区代码(如 US、UK、KR)用连字符分隔组成。一个语言标签的格式如:en-US。 | -| Logto 提供的语言 | Logto 提供的语言是 Logto 官方语言,存储在 Logto 的原始代码库中。 | -| 添加的语言 | 添加的语言是用户自行添加的语言。 | -| Logto 源值 | Logto 源值是尚未被用户自定义的 Logto 提供的值。 | -| 自定义值 | 自定义值是已经被用户自定义过的值。Logto 源值会被覆盖。 | +| 定义 | 描述 | +| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | +| 语言标签 | 语言标签用于标识内容的语言。一个语言标签由语言代码(如 en、fr、zh)和国家 / 地区代码(如 US、UK、KR)用连字符分隔组成。语言标签示例:en-US。 | +| Logto 提供的语言 | Logto 提供的语言是 Logto 官方语言,存储在 Logto 原始代码库中。 | +| 添加的语言 | 添加的语言是用户自行添加的语言。 | +| Logto 源值 | Logto 源值是尚未被用户自定义的 Logto 提供的值。 | +| 自定义值 | 自定义值是已经被用户自定义过的值。Logto 源值会被覆盖。 | ## 使用 Management API 进行自定义 \{#customization-using-management-api} @@ -60,15 +60,15 @@ Logto 支持广泛的预定义语言,并提供 113 个额外的语言标签。 2. 否则,如果启用了“自动检测”,则使用检测到的用户客户端语言(例如来自 HTTP `Accept-Language` 头)。 3. 否则,使用登录体验中的租户默认语言。 -这种解析方式同样影响由交互触发的邮件本地化。了解更多:[邮件模板本地化](/connectors/email-connectors/email-templates#email-template-localization)。 +此解析方式同样影响由交互触发的邮件本地化。了解更多:[邮件模板本地化](/connectors/email-connectors/email-templates#email-template-localization)。 ## 使用场景 \{#use-cases} 添加的语言会如何呈现给终端客户? -假设你的网站默认语言为英文,并且开启了自动检测。一位来自日本的用户访问你的网站并决定创建账户。如果他 / 她的应用语言为日语,但 Logto 尚未支持该语言,则登录界面会显示为英文。 +假设你的网站默认语言为英文,并且已开启自动检测。一位来自日本的用户访问你的网站并决定创建账户。如果他 / 她的应用语言为日语,但 Logto 尚未支持该语言,则登录界面会以英文显示。 -Logto 登录体验的 i18n 让自定义语言成为可能。 +Logto 登录体验 i18n 让自定义语言成为可能。 点击 `ja` 语言标签,添加你自己的日语翻译。 @@ -83,7 +83,7 @@ Logto 登录体验的 i18n 让自定义语言成为可能。 -在左侧语言标签旁会出现 Logto 提供的标记,你添加的语言将无法再被移除。你修改过的值会继续生效并替换原有的 Logto 值。若要使用 Logto 默认配置提供的值,只需清除用户自定义的值即可。 +在左侧语言标签旁会出现 Logto 提供的标记,你添加的语言将无法再被移除。你修改过的值会继续生效并替换原有的 Logto 值。若想使用 Logto 默认配置提供的值,只需清除用户自定义的值即可。
@@ -94,8 +94,21 @@ Logto 登录体验的 i18n 让自定义语言成为可能。 -最终用户看到的是两列合并的结果。 -假设你只想调整 Logto 提供的原始内容副本中的一部分。你的注册界面与 Logto 提供的界面唯一的区别就是你编辑过的键。其余内容保持不变。 +最终用户看到的是两列内容合并的结果。 +假如你只想调整 Logto 提供的原始内容副本中的一部分,那么你的注册界面与 Logto 默认界面的唯一区别就是你编辑过的键。其余内容保持不变。 + + + +
+ + +### 如何为登录体验设置默认手机号国家代码? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +[登录体验](/end-user-flows/sign-up-and-sign-in/sign-up)中的手机号国家代码默认取自用户浏览器的本地语言。例如,如果用户浏览器语言设置为 `fr`,则国家代码会默认选择法国(+33)。 + +如需以编程方式为特定用户或地区控制默认国家代码,可以使用 [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 认证参数。例如,设置 `ui_locales=ja` 时,国家代码将默认选择日本(+81)。
diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index 989a6ae2aa4..83791d31f4c 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -6,13 +6,13 @@ sidebar_position: 1 ## 全局登录体验 \{#omni-sign-in-experience} -通过进入 控制台 > 登录体验 > 品牌设置,自定义你的登录页面的外观和风格。本部分允许你轻松调整关键品牌元素。 +通过前往 控制台 > 登录体验 > 品牌,自定义你的登录页面的外观和风格。本部分允许你轻松调整关键品牌元素。 -**品牌色** +### 品牌色 \{#brand-color} 定义登录体验中使用的主色,包括主按钮、链接和其他组件。将默认的 Logto 紫色替换为你的品牌色。对于深色模式,可以单独指定品牌色。 -**公司 Logo** +### 公司 Logo \{#company-logo} Logo 将显示在登录首页、注册首页、加载页以及我们扩展的其他界面。 @@ -20,45 +20,49 @@ Logo 将显示在登录首页、注册首页、加载页以及我们扩展的其 - 如果你将 logo 字段留空,界面中将不会显示 logo。 - 也可以上传深色模式下的 logo 版本。 -**Favicon** +### Favicon \{#favicon} -Favicon 是代表网站的小图标,会显示在浏览器标签页、书签和浏览器界面的其他区域。 +Favicon 是代表网站的小图标,会显示在浏览器标签页、书签以及浏览器界面的其他区域。 - 图片必须小于 500KB,且为 SVG、PNG、JPG、JPEG 或 ICO 格式。建议上传正方形图片以确保良好的展示效果。 - 也可以上传深色模式下的 favicon 版本。 - 此外,不同流程(登录 / 注册 / 忘记密码等)的浏览器标题现在会自动使用,无需自定义标题。 -**深色模式** +### 深色模式 \{#dark-mode} -启用深色模式后,登录页面会根据用户的系统偏好自动调整外观。 +启用深色模式后,登录页面的外观会根据用户的系统偏好自动调整。 -## 应用级品牌设置 \{#app-specific-branding} +### 隐藏 Logto 品牌 \{#hide-logto-branding} + +默认情况下,开箱即用的登录体验页面会在底部显示“Powered by Logto”。启用“隐藏 Logto 品牌”选项后,可以移除 Logto 标识,打造专属你品牌的简洁、专业的登录体验。 + +## 应用级品牌定制 \{#app-specific-branding} 如果你的多应用业务需要应用级的登录体验,可以在应用详情页进行配置。前往 控制台 > 应用。 -开启“应用级登录体验”后,你可以为每个应用单独设置品牌 logo、favicon、颜色,甚至 [自定义 CSS](/customization/custom-css)。当从启用了应用级品牌设置的应用发起登录时,登录体验将根据应用级品牌设置进行定制;否则,将回退到默认的全局登录体验设置。 +开启“应用级登录体验”后,你可以为每个应用设置专属的品牌 logo、favicon、颜色,甚至 [自定义 CSS](/customization/custom-css)。当从启用了应用级品牌的应用发起登录时,登录体验将根据应用级品牌设置进行定制;否则,将回退到默认的全局登录体验设置。 -应用级品牌设置支持明亮和深色模式。深色模式设置仅在 [全局登录体验](#omni-sign-in-experience) 启用深色模式时生效。 +应用级品牌定制支持明亮和深色模式。深色模式设置仅在 [全局登录体验](#omni-sign-in-experience) 启用深色模式时生效。 -## 组织级品牌设置 \{#organization-specific-branding} +## 组织级品牌定制 \{#organization-specific-branding} -如果你希望在登录体验中动态展示客户组织的 logo,可以在组织设置页面上传组织 logo。前往 控制台 > 组织 (Organizations)。 +如需在登录体验中动态展示客户组织的 logo,可以在组织设置页面上传组织 logo。前往 控制台 > 组织 (Organizations)。 -开启“组织级登录体验”后,和应用级品牌设置一样,你也可以为每个组织单独设置品牌 logo、favicon、颜色和 [自定义 CSS](/customization/custom-css)。 +开启“组织级登录体验”后,和应用级品牌一样,你也可以为每个组织设置专属的品牌 logo、favicon、颜色和 [自定义 CSS](/customization/custom-css)。 -然后,在触发登录时,你可以通过 `organization_id` 参数传递组织 ID,告诉 Logto 显示哪个组织的 logo。例如,要显示组织 ID 为 `123456` 的组织 logo: +然后,在触发登录时,你可以通过 `organization_id` 参数传递组织 ID,告知 Logto 显示哪个组织的 logo。例如,要显示组织 ID 为 `123456` 的组织 logo: - 如果你使用 Logto SDK,可以在 `signIn` 方法的 `extraParams` 对象中传递 `organization_id` 参数。 - 如果你使用 OIDC 客户端,可以在请求 [授权端点](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 时传递 `organization_id` 参数。 -组织级品牌设置同样支持明亮和深色模式。深色模式设置仅在 [全局登录体验](#omni-sign-in-experience) 启用深色模式时生效。 +组织级品牌定制同样支持明亮和深色模式。深色模式设置仅在 [全局登录体验](#omni-sign-in-experience) 启用深色模式时生效。 :::note -如果同时启用了应用级品牌设置和组织级品牌设置,则以组织级品牌设置为准。完整优先级顺序为: -组织级品牌设置 -> 应用级品牌设置 -> 全局登录体验 +如果同时启用了应用级品牌和组织级品牌,组织级品牌优先生效。完整优先级顺序为: +组织级品牌 -> 应用级品牌 -> 全局登录体验 ::: -以下是如何在 [Logto 浏览器 SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out) 的 `signIn` 方法中传递 `organization_id` 参数的示例: +以下是使用 [Logto 浏览器 SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out) 在 `signIn` 方法中传递 `organization_id` 参数的示例: **index.ts** @@ -74,12 +78,12 @@ logtoClient.signIn({ :::note -我们正在逐步向所有 Logto SDK 推出 `extraParams` 功能。如果你在你的 SDK 中还没有看到该功能,请联系我们。 +我们正在逐步向所有 Logto SDK 推出 `extraParams` 功能。如果你在自己的 SDK 中还未看到该功能,请联系我们。 ::: ## 相关资源 \{#related-resources} - 如何为每个应用或组织自定义登录体验? + 如何为每个应用或组织定制登录体验? diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index 4f02d049ff0..f59788cb988 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -10,9 +10,9 @@ sidebar_position: 1 Logto Account API 是一套全面的 API,允许终端用户直接通过 API 访问,无需经过 Management API。主要亮点如下: - 直接访问:Account API 让终端用户可以直接访问和管理自己的账户资料,无需通过 Management API 中转。 -- 用户资料与身份管理:用户可以完全管理自己的资料和安全设置,包括更新身份信息(如邮箱、手机号和密码),以及管理社交账号绑定。MFA 和 SSO 支持即将上线。 -- 全局访问控制:管理员可以对访问设置进行全局控制,并自定义每个字段的权限。 -- 无缝授权 (Authorization):授权 (Authorization) 变得前所未有的简单!只需使用 `client.getAccessToken()` 获取 OP(Logto)的不透明令牌 (Opaque token),并将其作为 `Bearer ` 附加到 Authorization 头部即可。 +- 用户资料和身份管理:用户可以完全管理自己的资料和安全设置,包括更新邮箱、手机号、密码等身份信息,以及管理社交账号绑定。MFA 和 SSO 支持即将上线。 +- 全局访问控制:管理员可以对访问设置进行全局控制,并可自定义每个字段的权限。 +- 无缝授权 (Authorization):授权 (Authorization) 变得前所未有的简单!只需使用 `client.getAccessToken()` 获取 OP (Logto) 的不透明令牌 (Opaque token),并将其作为 `Bearer ` 附加到 Authorization 头部即可。 通过 Logto Account API,你可以构建一个与 Logto 完全集成的自定义账户管理系统,比如个人资料页。 @@ -21,8 +21,8 @@ Logto Account API 是一套全面的 API,允许终端用户直接通过 API - 获取用户资料 - 更新用户资料 - 更新用户密码 -- 更新用户身份信息,包括邮箱、手机号和社交账号 -- 管理 MFA 因子(验证) +- 更新用户身份信息(包括邮箱、手机号和社交账号) +- 管理 MFA 因素(验证) 想了解更多可用 API,请访问 [Logto Account API 参考文档](https://openapi.logto.io/group/endpoint-my-account) 和 [Logto Verification API 参考文档](https://openapi.logto.io/group/endpoint-verifications)。 @@ -34,20 +34,20 @@ SSO 账户查看和账户删除功能目前通过 Logto Management API 提供。 ## 如何启用 Account API \{#how-to-enable-account-api} -进入 控制台 > 登录与账户 > 账户中心。 +前往 控制台 > 登录与账户 > 账户中心。 Account API 默认关闭,因此其访问控制是锁定的。切换 **启用 Account API** 开关即可开启。 -启用后,你可以为标识符、资料数据和第三方令牌访问配置每个字段的权限。每个字段支持 `关闭`、`只读` 或 `可编辑`,默认是 `关闭`。 +开启后,可以为标识符、资料数据和第三方令牌访问配置每个字段的权限。每个字段支持 `关闭`、`只读` 或 `可编辑`,默认是 `关闭`。 1. **安全字段**: - 包括:主邮箱、主手机号、社交身份、密码和 MFA。 - 终端用户在编辑这些字段前,必须通过密码、邮箱或短信验证身份,获取一个 10 分钟有效的验证记录 ID。详见 [获取验证记录 ID](#get-a-verification-record-id)。 - - 若要使用 WebAuthn 密钥作为 MFA,请将你的前端应用域名添加到 **WebAuthn 相关来源**,以便账户中心和登录体验共享密钥。详见 [绑定新的 WebAuthn 密钥](#link-a-new-webauthn-passkey)。 + - 若要使用 WebAuthn 密钥作为 MFA,请将前端应用域名添加到 **WebAuthn 相关来源**,以便账户中心和登录体验共享密钥。详见 [绑定新的 WebAuthn 密钥](#link-a-new-webauthn-passkey)。 2. **资料字段**: - - 包括:用户名、姓名、头像、[profile](/user-management/user-data#profile)(其他标准资料属性)和 [自定义数据](/user-management/user-data#custom-data)。 - - 终端用户可直接编辑这些字段,无需额外验证。 -3. **密钥库**:对于 OIDC 或 OAuth 社交和企业连接器,Logto [密钥库](/secret-vault/federated-token-set) 会在认证后安全存储第三方访问令牌和刷新令牌。应用可调用外部 API(如同步 Google 日历事件),无需再次提示用户登录。启用 Account API 后,令牌获取功能会自动开放。 + - 包括:用户名、姓名、头像、[profile](/user-management/user-data#profile)(其他标准资料属性)和 [custom data](/user-management/user-data#custom-data)。 + - 终端用户可直接编辑,无需额外验证。 +3. **密钥保险库**:对于 OIDC 或 OAuth 社交和企业连接器,Logto [密钥保险库](/secret-vault/federated-token-set) 会在认证后安全存储第三方访问令牌和刷新令牌。应用可调用外部 API(如同步 Google 日历事件),无需再次提示用户登录。开启 Account API 后,令牌获取功能自动可用。 ## 如何访问 Account API \{#how-to-access-account-api} @@ -77,9 +77,9 @@ const config: LogtoConfig = { ### 获取访问令牌 (Access token) \{#fetch-an-access-token} -在应用中配置好 SDK 后,可以使用 `client.getAccessToken()` 方法获取访问令牌 (Access token)。该令牌是不透明令牌 (Opaque token),可用于访问 Account API。 +在应用中配置好 SDK 后,可以使用 `client.getAccessToken()` 方法获取访问令牌 (Access token)。该令牌为不透明令牌 (Opaque token),可用于访问 Account API。 -如果你未使用官方 SDK,则应在向 `/oidc/token` 发起访问令牌授权请求时,将 `resource` 设为空。 +如果你未使用官方 SDK,请在向 `/oidc/token` 发起访问令牌授权请求时,将 `resource` 设为空。 ### 使用访问令牌访问 Account API \{#access-account-api-using-access-token} @@ -96,7 +96,7 @@ curl https://[tenant-id].logto.app/api/my-account \ ### 获取用户账户信息 \{#retrieve-user-account-information} -要获取用户数据,可调用 [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) 接口。 +获取用户数据可使用 [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) 接口。 ```bash curl https://[tenant-id].logto.app/api/my-account \ @@ -118,9 +118,9 @@ curl https://[tenant-id].logto.app/api/my-account \ ### 更新基础账户信息 \{#update-basic-account-information} -基础账户信息包括用户名、姓名、头像、自定义数据及其他资料信息。 +基础账户信息包括用户名、姓名、头像、自定义数据以及其他资料信息。 -要更新 **用户名、姓名、头像和 customData**,可调用 [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) 接口。 +要更新 **用户名、姓名、头像和 customData**,可使用 [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) 接口。 ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account \ @@ -129,7 +129,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account \ --data-raw '{"username":"...","name":"...","avatar":"..."}' ``` -要更新其他资料信息,包括 **familyName、givenName、middleName、nickname、profile(个人主页 URL)、website、gender、birthdate、zoneinfo、locale 和 address**,可调用 [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) 接口。 +要更新其他资料信息,包括 **familyName、givenName、middleName、nickname、profile(个人主页 URL)、website、gender、birthdate、zoneinfo、locale 和 address**,可使用 [`PATCH /api/my-account/profile`](https://openapi.logto.io/operation/operation-updateotherprofile) 接口。 ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ @@ -138,15 +138,15 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ --data-raw '{"familyName":"...","givenName":"..."}' ``` -## 管理标识符及其他敏感信息 \{#manage-identifiers-and-other-sensitive-information} +## 管理标识符和其他敏感信息 \{#manage-identifiers-and-other-sensitive-information} -出于安全考虑,涉及标识符及其他敏感信息的操作,Account API 需要额外的授权 (Authorization) 层。 +出于安全考虑,Account API 对涉及标识符和其他敏感信息的操作增加了一层授权 (Authorization)。 ### 获取验证记录 ID \{#get-a-verification-record-id} -首先,你需要获取一个 **验证记录 ID**,有效期为 10 分钟(TTL)。该 ID 可用于在更新敏感信息前验证用户身份。即用户通过密码、邮箱验证码或短信验证码验证身份后,有 10 分钟时间可更新与认证 (Authentication) 相关的数据,包括标识符、凭证、社交账号绑定和 MFA。 +首先,你需要获取一个 **验证记录 ID**,有效期为 10 分钟(TTL)。该 ID 可用于在更新敏感信息前验证用户身份。即用户通过密码、邮箱验证码或短信验证码验证身份后,有 10 分钟时间可更新认证 (Authentication) 相关数据,包括标识符、凭证、社交账号绑定和 MFA。 -获取验证记录 ID 的方式有:[验证用户密码](#verify-the-users-password) 或 [向用户邮箱或手机号发送验证码](#verify-by-sending-a-verification-code-to-the-users-email-or-phone)。 +获取验证记录 ID 的方式有 [验证用户密码](#verify-the-users-password) 或 [向用户邮箱或手机号发送验证码](#verify-by-sending-a-verification-code-to-the-users-email-or-phone)。 #### 验证用户密码 \{#verify-the-users-password} @@ -209,7 +209,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v ### 更新用户密码 \{#update-users-password} -要更新用户密码,可调用 [`POST /api/my-account/password`](https://openapi.logto.io/operation/operation-updatepassword) 接口。 +要更新用户密码,可使用 [`POST /api/my-account/password`](https://openapi.logto.io/operation/operation-updatepassword) 接口。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/password \ @@ -219,13 +219,17 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +与注册时设置的密码一样,通过 Account API 设置的密码也必须符合你在 控制台 > 安全 > 密码策略 配置的 [密码策略](/security/password-policy)。如不符合策略,Logto 会返回详细的校验结果和错误信息。 +::: + ### 更新或绑定新邮箱 \{#update-or-link-new-email} :::note 使用此方法需先 [配置邮箱连接器](/connectors/email-connectors/),并确保已配置 `BindNewIdentifier` 模板。 ::: -要更新或绑定新邮箱,需先证明对该邮箱的所有权。 +要更新或绑定新邮箱,需先证明邮箱归属权。 调用 [`POST /api/verifications/verification-code`](https://openapi.logto.io/operation/operation-createverificationbyverificationcode) 接口请求验证码。 @@ -236,7 +240,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ --data-raw '{"identifier":{"type":"email","value":"..."}}' ``` -你会在响应中获得 `verificationId`,并在邮箱中收到验证码,使用该验证码进行邮箱验证。 +你会在响应中获得 `verificationId`,并在邮箱中收到验证码,用其验证邮箱。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/verify \ @@ -255,9 +259,13 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +与注册时收集的邮箱一样,通过 Account API 绑定的邮箱也必须通过你在 控制台 > 安全 > 黑名单 配置的 [黑名单](/security/blocklist) 校验。如邮箱不符合策略,Logto 会拒绝请求并返回详细错误。 +::: + ### 移除用户邮箱 \{#remove-the-users-email} -要移除用户邮箱,可调用 [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) 接口。 +要移除用户邮箱,可使用 [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) 接口。 ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -271,11 +279,11 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ 使用此方法需先 [配置短信连接器](/connectors/sms-connectors/),并确保已配置 `BindNewIdentifier` 模板。 ::: -与更新邮箱类似,可通过 [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) 接口更新或绑定新手机号。通过 [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) 接口移除用户手机号。 +与更新邮箱类似,可使用 [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) 接口更新或绑定新手机号。使用 [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) 接口移除用户手机号。 ### 绑定新的社交账号 \{#link-a-new-social-connection} -要绑定新的社交账号,首先需通过 [`POST /api/verifications/social`](https://openapi.logto.io/operation/operation-createverificationbysocial) 请求授权 (Authorization) URL。 +要绑定新的社交账号,首先需通过 [`POST /api/verifications/social`](https://openapi.logto.io/operation/operation-createverificationbysocial) 请求授权 URL。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social \ @@ -285,12 +293,12 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ ``` - `connectorId`: [社交连接器](/connectors/social-connectors/) 的 ID。 -- `redirectUri`:用户授权应用后跳转的 URI,你需要在此 URL 上托管网页并捕获回调。 -- `state`:用户授权应用后返回的 state,用于防止 CSRF 攻击的随机字符串。 +- `redirectUri`:用户授权应用后跳转的 URI,你需在此 URL 下托管网页并捕获回调。 +- `state`:用户授权后返回的 state,用于防止 CSRF 攻击的随机字符串。 响应中会有 `verificationRecordId`,请妥善保存。 -用户授权应用后,你会在 `redirectUri` 收到带有 `state` 参数的回调。然后可通过 [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) 验证社交账号。 +用户授权应用后,你会在 `redirectUri` 收到带有 `state` 参数的回调。然后可使用 [`POST /api/verifications/social/verify`](https://openapi.logto.io/operation/operation-verifyverificationbysocial) 验证社交账号。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ @@ -299,9 +307,9 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social/verify \ --data-raw '{"connectorData":"...","verificationRecordId":"..."}' ``` -`connectorData` 是社交连接器在用户授权应用后返回的数据,你需要在回调页面解析并获取 `redirectUri` 的查询参数,并将其封装为 JSON 作为 `connectorData` 字段的值。 +`connectorData` 是社交连接器授权后返回的数据,你需在回调页面解析 `redirectUri` 的查询参数,并将其封装为 JSON 作为 `connectorData` 字段值。 -最后,可通过 [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) 绑定社交账号。 +最后,可使用 [`POST /api/my-account/identities`](https://openapi.logto.io/operation/operation-adduseridentities) 绑定社交账号。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/identities \ @@ -313,7 +321,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/identities \ ### 移除社交账号 \{#remove-a-social-connection} -要移除社交账号,可调用 [`DELETE /api/my-account/identities`](https://openapi.logto.io/operation/operation-deleteidentity) 接口。 +要移除社交账号,可使用 [`DELETE /api/my-account/identities`](https://openapi.logto.io/operation/operation-deleteidentity) 接口。 ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connector_target_id] \ @@ -328,23 +336,23 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connecto ::: :::note -使用此方法需在 [账户中心设置](#how-to-enable-account-api) 启用 `mfa` 字段。 +使用此方法需在 [账户中心设置](#how-to-enable-account-api) 中启用 `mfa` 字段。 ::: -**步骤 1:将前端应用的域名添加到相关来源** +**步骤 1:将前端应用域名添加到相关来源** -WebAuthn 密钥绑定到特定主机名(即 **Relying Party ID (RP ID)**)。只有托管在 RP ID 来源的应用才能注册或认证 (Authentication) 这些密钥。 +WebAuthn 密钥绑定到特定主机名(**Relying Party ID (RP ID)**)。只有托管在 RP ID 来源的应用才能注册或认证这些密钥。 -由于你的前端应用与 Logto 认证 (Authentication) 页面不在同一域名下,需配置 **相关来源** 以允许跨域密钥操作。 +由于你的前端应用与 Logto 认证页面域名不同,需配置 **相关来源** 以允许跨域密钥操作。 **Logto 如何确定 RP ID:** - **默认设置**:仅使用 Logto 默认域名 `https://[tenant-id].logto.app` 时,RP ID 为 `[tenant-id].logto.app` -- **自定义域名**:如配置了 [自定义域名](/logto-cloud/custom-domain) `https://auth.example.com`,RP ID 则为 `auth.example.com` +- **自定义域名**:如配置了 [自定义域名](/logto-cloud/custom-domain) `https://auth.example.com`,RP ID 为 `auth.example.com` **配置相关来源:** -通过 [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) 接口添加前端应用的来源。例如,账户中心运行在 `https://account.example.com`: +使用 [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) 接口添加前端应用的来源。例如,账户中心运行在 `https://account.example.com`: ```bash curl -X PATCH https://[tenant-id].logto.app/api/account-center \ @@ -353,11 +361,21 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -更多相关来源说明,请参考 [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) 文档。 +:::note + +WebAuthn 最多支持 5 个唯一 eTLD+1 标签作为相关来源。eTLD+1(有效顶级域加一标签)是可注册域部分。例如: + +- `https://example.com`、`https://app.example.com`、`https://auth.example.com` 计为 **一个** 标签(`example.com`) +- `https://shopping.com`、`https://shopping.co.uk`、`https://shopping.co.jp` 也计为 **一个** 标签(`shopping`) +- `https://example.com` 和 `https://another.com` 计为 **两个** 标签 + +如需支持超过 5 个不同域名作为相关来源,请参考 [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) 文档。 + +::: **步骤 2:请求新的注册选项** -通过 [`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) 接口请求注册新密钥。Logto 允许每个账户注册多个密钥。 +使用 [`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) 接口请求注册新密钥。Logto 允许每个账户注册多个密钥。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration \ @@ -391,7 +409,7 @@ const response = await startRegistration({ **步骤 4:验证密钥注册** -通过 [`POST /api/verifications/web-authn/registration/verify`](https://openapi.logto.io/operation/operation-verifywebauthnregistration) 接口验证密钥注册。 +使用 [`POST /api/verifications/web-authn/registration/verify`](https://openapi.logto.io/operation/operation-verifywebauthnregistration) 接口验证密钥注册。 此步骤会验证认证器生成的加密签名,确保密钥合法创建且传输过程中未被篡改。 @@ -423,7 +441,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ ### 管理已有 WebAuthn 密钥 \{#manage-existing-webauthn-passkeys} -要管理已有 WebAuthn 密钥,可通过 [`GET /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-getmfaverifications) 获取当前密钥及其他 MFA 验证因子。 +管理已有 WebAuthn 密钥可使用 [`GET /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-getmfaverifications) 接口获取当前密钥及其他 MFA 验证因子。 ```bash curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -445,12 +463,12 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications \ ] ``` -- `id`:验证因子的 ID。 +- `id`:验证因子 ID。 - `type`:验证类型,WebAuthn 密钥为 `WebAuthn`。 - `name`:密钥名称,选填。 - `agent`:密钥的 user agent。 -通过 [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname) 更新密钥名称: +更新密钥名称可用 [`PATCH /api/my-account/mfa-verifications/{verificationId}/name`](https://openapi.logto.io/operation/operation-updatemfaverificationname) 接口: ```bash curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId}/name \ @@ -460,7 +478,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{ve --data-raw '{"name":"..."}' ``` -通过 [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) 删除密钥: +删除密钥可用 [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) 接口: ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId} \ @@ -475,12 +493,12 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{v ::: :::note -使用此方法需在 [账户中心设置](#how-to-enable-account-api) 启用 `mfa` 字段。 +使用此方法需在 [账户中心设置](#how-to-enable-account-api) 中启用 `mfa` 字段。 ::: **步骤 1:生成 TOTP 密钥** -通过 [`POST /api/my-account/mfa-verifications/totp-secret/generate`](https://openapi.logto.io/operation/operation-generatetotpsecret) 接口生成 TOTP 密钥。 +使用 [`POST /api/my-account/mfa-verifications/totp-secret/generate`](https://openapi.logto.io/operation/operation-generatetotpsecret) 接口生成 TOTP 密钥。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp-secret/generate \ @@ -498,7 +516,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/totp **步骤 2:向用户展示 TOTP 密钥** -用该密钥生成二维码或直接展示给用户。用户需将其添加到认证器应用(如 Google Authenticator、Microsoft Authenticator 或 Authy)。 +用该密钥生成二维码或直接展示给用户。用户应将其添加到自己的认证器应用(如 Google Authenticator、Microsoft Authenticator 或 Authy)。 二维码的 URI 格式为: @@ -514,7 +532,7 @@ otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp **步骤 3:绑定 TOTP 因子** -用户将密钥添加到认证器应用后,需要验证并绑定到账户。通过 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 绑定 TOTP 因子。 +用户将密钥添加到认证器应用后,需要验证并绑定到账户。使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 接口绑定 TOTP 因子。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -529,7 +547,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ - `secret`:第 1 步生成的 TOTP 密钥。 :::note -每个用户只能拥有一个 TOTP 因子。如已存在 TOTP 因子,尝试添加会返回 422 错误。 +每个用户只能有一个 TOTP 因子。如已存在 TOTP 因子,尝试添加会返回 422 错误。 ::: ### 管理备份码 \{#manage-backup-codes} @@ -539,12 +557,12 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ ::: :::note -使用此方法需在 [账户中心设置](#how-to-enable-account-api) 启用 `mfa` 字段。 +使用此方法需在 [账户中心设置](#how-to-enable-account-api) 中启用 `mfa` 字段。 ::: **步骤 1:生成新备份码** -通过 [`POST /api/my-account/mfa-verifications/backup-codes/generate`](https://openapi.logto.io/operation/operation-generatemyaccountbackupcodes) 接口生成一组新的 10 个备份码。 +使用 [`POST /api/my-account/mfa-verifications/backup-codes/generate`](https://openapi.logto.io/operation/operation-generatemyaccountbackupcodes) 接口生成一组新的 10 个备份码。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes/generate \ @@ -562,18 +580,18 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/back **步骤 2:向用户展示备份码** -在将备份码绑定到用户账户前,必须展示给用户,并提示: +在绑定备份码到用户账户前,必须将其展示给用户,并提示: - 立即下载或抄写这些备份码 -- 妥善保管在安全的地方 +- 妥善保管在安全位置 - 每个备份码只能使用一次 - 这些码是丢失主 MFA 方法后的最后救援手段 -建议以清晰、易复制的格式展示,并提供下载选项(如文本文件或 PDF)。 +应以清晰、易复制的格式展示,并可提供下载(如 txt 或 PDF)。 -**步骤 3:将备份码绑定到用户账户** +**步骤 3:绑定备份码到用户账户** -通过 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 绑定备份码到用户账户。 +使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 接口绑定备份码到用户账户。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -589,15 +607,15 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ :::note -- 每个用户只能拥有一组备份码。如所有备份码已用完,需重新生成并绑定新备份码。 -- 备份码不能作为唯一的 MFA 因子。用户必须至少启用一种其他 MFA 因子(如 WebAuthn 或 TOTP)。 +- 每个用户只能有一组备份码。如全部用完,需重新生成并绑定新备份码。 +- 备份码不能作为唯一 MFA 因子。用户必须至少启用一种其他 MFA 因子(如 WebAuthn 或 TOTP)。 - 每个备份码只能使用一次。 ::: **查看已有备份码** -要查看已有备份码及其使用状态,可通过 [`GET /api/my-account/mfa-verifications/backup-codes`](https://openapi.logto.io/operation/operation-getbackupcodes) 接口: +要查看已有备份码及其使用状态,可用 [`GET /api/my-account/mfa-verifications/backup-codes`](https://openapi.logto.io/operation/operation-getbackupcodes) 接口: ```bash curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes \ @@ -622,4 +640,4 @@ curl https://[tenant-id].logto.app/api/my-account/mfa-verifications/backup-codes ``` - `code`:备份码。 -- `usedAt`:该备份码被使用的时间戳,未使用为 `null`。 +- `usedAt`:该码被使用的时间戳,未使用为 `null`。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index 28215e244ce..c080630be44 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -8,33 +8,37 @@ sidebar_position: 2 - `first_screen`:指定用户将看到的首屏。 - `identifier`:指定登录或注册表单将接受的标识符类型。 -- `login_hint`:用用户的邮箱地址或用户名填充标识符字段。(这是 OIDC 标准参数) +- `login_hint`:用用户的电子邮件地址或用户名填充标识符字段。(这是 OIDC 标准参数) ## first_screen \{#first_screen} -`first_screen` 参数是决定用户重定向到 Logto 登录页面时所见首屏的关键参数。默认情况下,将显示通用登录表单。你可以根据应用需求使用此参数自定义首屏。支持的值有: +`first_screen` 参数是决定用户在跳转到 Logto 登录页面时首先看到哪个页面的关键参数。默认情况下,将显示通用登录表单。你可以根据应用需求使用此参数自定义首屏。支持的值有: -- `sign_in`:显示登录表单。(默认) +- `sign_in`(默认):显示登录表单。 - `register`:显示注册表单。 -- `reset_password`:显示重置密码表单。 -- `single_sign_on`:显示企业单点登录 (SSO) 登录表单。(会要求输入邮箱地址以确定可用的 SSO 提供商) -- `identifier:sign-in`:显示特定标识符的登录表单。可以通过 `identifier` 参数指定标识符类型。当你启用了多种标识符登录方式时非常有用。 -- `identifier:register`:显示特定标识符的注册表单。可以通过 `identifier` 参数指定标识符类型。当你启用了多种标识符注册方式时非常有用。 +- `reset_password`:显示密码重置表单。 +- `single_sign_on`:显示企业单点登录 (SSO) 登录表单。(会要求输入电子邮件地址以确定可用的 SSO 提供商) +- `identifier:sign-in`:显示特定标识符的登录表单。标识符类型可通过 `identifier` 参数指定(可选)。当你启用了多种标识符登录方式时非常有用。 +- `identifier:register`:显示特定标识符的注册表单。标识符类型可通过 `identifier` 参数指定(可选)。当你启用了多种标识符注册方式时非常有用。 首屏参数 -例如,直接将用户引导到企业单点登录 (SSO) 登录表单: +例如,直接将用户跳转到企业单点登录 (SSO) 登录表单: ```sh curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +首屏将遵循 控制台 > 登录体验 中的设置。你需要先启用所需的认证 (Authentication) 方式,并配置品牌、条款与隐私政策以及国际化(i18n)。注意,只有 `sign-in` 和 `register` 页面默认显示 logo。 +::: + ## identifier \{#identifier} -`identifier` 参数用于指定登录或注册表单将接受的标识符类型。此参数仅在 `first_screen` 参数设置为 `identifier:sign-in`、`identifier:register` 或 `reset_password` 时适用。支持的值有:`username`、`email` 和 `phone`。如需支持多种标识符类型,请用空格分隔多个值。 +`identifier` 参数用于指定登录或注册表单将接受的标识符类型。此参数仅在 `first_screen` 参数设置为 `identifier:sign-in`、`identifier:register` 或 `reset_password` 时适用。支持的值有:`username`、`email` 和 `phone`。如需支持多种标识符类型,用空格分隔多个值。 -例如,直接将用户引导到邮箱或手机号注册页面: +例如,直接将用户跳转到电子邮件或手机号注册页面: ```sh curl --location \ @@ -47,9 +51,9 @@ curl --location \ ## login_hint \{#login_hint} -`login_hint` 参数在标准 [OpenID Connect 规范](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 中定义,用于在登录表单中预填用户的标识符(如邮箱、手机号或用户名)。在 Logto 中,可以与其他登录屏幕参数结合使用,以提升用户体验。此参数在你有自定义预认证 (Authentication) 表单并提前收集用户标识符时尤其有用,让用户在登录时无需再次输入。 +`login_hint` 参数在 [OpenID Connect 规范](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 中有定义,用于在登录表单中预填用户的标识符(如电子邮件、手机号或用户名)。在 Logto 中,可以与其他登录页面参数结合使用,以提升用户体验。此参数在你有自定义预认证 (Authentication) 表单并提前收集用户标识符时尤其有用,让用户在登录时无需重复输入。 -例如,在登录表单中预填收集到的邮箱地址: +例如,在登录表单中预填已收集的电子邮件地址: ```sh curl --location \ @@ -70,7 +74,7 @@ logtoClient.signIn({ ``` :::note -我们正在逐步为所有 Logto SDK 添加对 `first_screen`、`identifier` 和 `login_hint` 参数的支持。如果你在使用的 SDK 中没有看到这些参数,请提交 issue 或联系我们。 +我们正在逐步为所有 Logto SDK 添加对 `first_screen`、`identifier` 和 `login_hint` 参数的支持。如果你在所用 SDK 中没有看到这些参数,请提交 issue 或联系我们。 -对于 [Logto OSS](/logto-oss) 用户,这些参数自 1.15.0 版本起已支持。如果你使用的是旧版本,请[升级](/logto-oss/upgrading-oss-version)到最新版本。 +对于 [Logto OSS](/logto-oss) 用户,这些参数自 1.15.0 版本起支持。如果你使用的是旧版本,请[升级](/logto-oss/upgrading-oss-version)到最新版。 ::: diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index 5000aaa80ee..28179059914 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -8,9 +8,10 @@ Logto 支持标准 OIDC 认证 (Authentication) 参数 `ui_locales`,用于控 ## 功能说明 \{#what-it-does} -- 决定 Logto 托管的登录体验界面在运行时的 UI 语言。Logto 会选择 `ui_locales` 中在你租户语言库中支持的第一个语言标签。 -- 影响由该交互触发的邮件本地化(如验证码邮件)。详见 [邮件模板本地化](/connectors/email-connectors/email-templates#email-template-localization)。 -- 将原始值作为变量 `uiLocales` 暴露给邮件模板,你可以根据需要将其包含在邮件主题或内容中。 +- 在运行时决定 Logto 托管的登录体验的 UI 语言。Logto 会在 `ui_locales` 中选择你租户语言库中支持的第一个语言标签。 +- 影响由该交互触发的邮件本地化(例如,验证码邮件)。详见 [邮件模板本地化](/connectors/email-connectors/email-templates#email-template-localization)。 +- 将原始值作为变量 `uiLocales` 暴露给邮件模板,你可以在邮件主题 / 内容中引用它(如有需要)。 +- 设置登录体验中的默认手机号码国家区号。例如,如果 `ui_locales=fr`,则手机号输入框默认法国 (+33)。当你希望为特定用户群体或地区以编程方式控制默认国家区号时,这非常有用。 ## 参数格式 \{#parameter-format} @@ -21,7 +22,7 @@ Logto 支持标准 OIDC 认证 (Authentication) 参数 `ui_locales`,用于控 ## 解析顺序与优先级 \{#resolution-order-and-precedence} -在确定登录体验和相关邮件的 UI 语言时,Logto 按以下顺序解析终端用户语言: +在决定登录体验和相关邮件的 UI 语言时,Logto 按以下顺序解析终端用户语言: 1. 当前认证 (Authentication) 请求中的 `ui_locales`(第一个支持的标签优先)。 2. 否则,使用 `Accept-Language` 头(体验 (Experience) API / 用户账户 (Account) API)或 `messagePayload.locale`(如组织邀请等管理 (Management) API)。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index a65a2585498..8cef6d9af02 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -6,86 +6,87 @@ sidebar_position: 2 ## 配置标识符登录流程 \{#configure-the-identifier-sign-in-flow} -如前所述,可以在 [注册流程](/end-user-flows/sign-up-and-sign-in/sign-up) 或 [在 Logto 中直接创建账户](/user-management/manage-users#add-users) 时从用户那里收集各种标识符类型。此外,用户在探索和使用产品时可能会输入和完成其他信息。这些标识符可以用于在 Logto 的系统中唯一标识用户,并允许他们进行认证 (Authentication) 并登录到与 Logto 集成的应用程序。 +如前所述,可以在[注册流程](/end-user-flows/sign-up-and-sign-in/sign-up)或[在 Logto 中直接创建账户](/user-management/manage-users#add-users)时,从用户处收集多种标识符类型。此外,用户在探索和使用产品的过程中,也可能输入并完善更多信息。这些标识符可用于在 Logto 系统中唯一标识用户,并允许他们通过认证 (Authentication) 登录集成了 Logto 的应用程序。 -无论你选择使用 Logto 托管的预构建登录页面,还是计划 [构建你自己的自定义登录 UI](/customization#custom-ui),你都需要为终端用户配置可用的登录方法和验证设置。 +无论你选择使用 Logto 托管的预构建登录页面,还是计划[构建你自己的自定义登录界面](/customization#custom-ui),你都需要为终端用户配置可用的登录方式和验证设置。 ## 设置标识符和认证 (Authentication) 设置 \{#set-up-the-identifier-and-authentication-settings} ### 1. 设置支持的登录标识符 \{#1-set-the-supported-sign-in-identifiers} -你可以从下拉列表中添加多个支持的标识符作为终端用户的启用登录方法。可用选项包括: +你可以从下拉列表中添加多个支持的标识符,作为终端用户可用的登录方式。可选项包括: - **用户名** - **邮箱地址** - **手机号** -重新排序标识符将更改它们在登录页面上的显示顺序。第一个标识符将是用户的主要登录方法。 +调整标识符的顺序会改变它们在登录页面上的显示顺序。第一个标识符将作为用户的主要登录方式。 ### 2. 设置认证 (Authentication) 设置 \{#2-set-the-authentication-settings} -对于每个登录标识符,你需要配置至少一个有效的验证因素来验证用户的身份。你可以选择以下两种因素: +对于每个登录标识符,你需要配置至少一个有效的验证因子来验证用户身份。你可以选择以下两种因子: -- **密码**:适用于所有类型的登录标识符。一旦启用,用户必须提供密码才能完成登录过程。 -- **验证码**:仅适用于 **邮箱地址** 和 **手机号** 标识符。一旦启用,用户必须输入发送到其邮箱或手机号的验证码才能完成登录过程。 +- **密码**:适用于所有类型的登录标识符。启用后,用户必须输入密码才能完成登录流程。 +- **验证码**:仅适用于 **邮箱地址** 和 **手机号** 标识符。启用后,用户必须输入发送到其邮箱或手机号的验证码才能完成登录流程。 -如果同时启用了这两种因素,用户可以选择任意一种方法来完成登录过程。你还可以重新排序这些因素,以更改它们在登录页面上的显示顺序。第一个因素将用作用户的主要验证方法,第二个将显示为备用链接。 +如果同时启用了两种因子,用户可以选择任意一种方式完成登录流程。你还可以调整因子的顺序,以改变它们在登录页面上的显示顺序。第一个因子将作为用户的主要验证方式,第二个则作为备用链接显示。 ## 标识符登录流程用户体验 \{#identifier-sign-in-flow-user-experience} -登录体验会根据所选标识符和可用的认证 (Authentication) 因素进行调整。 +登录体验会根据所选标识符和可用认证 (Authentication) 因子自动适配。 -- **多标识符的智能输入:** - 如果启用了多种标识符登录方法,Logto 内置登录页面将自动检测用户输入的标识符类型并显示相应的验证选项。例如,如果同时启用了 **邮箱地址** 和 **手机号**,登录页面将自动检测用户输入的标识符类型并显示相应的验证选项。当连续输入数字时,它会切换到带有区号的手机号格式;当使用“@”符号时,则切换到邮箱格式。 -- **启用的验证因素:** - - **仅密码**:标识符和密码字段将显示在第一个屏幕上。 - - **仅验证码**:标识符字段出现在第一个屏幕上,验证码字段出现在第二个屏幕上。 - - **密码和验证码**:标识符字段最初在第一个屏幕上输入,然后根据验证顺序在第二个屏幕上输入密码或验证码。提供了切换链接,允许用户在两种验证方法之间切换。 +- **多标识符智能输入:** + 如果启用了多种标识符登录方式,Logto 内置登录页面会自动检测用户输入的标识符类型,并显示相应的验证选项。例如,如果同时启用了 **邮箱地址** 和 **手机号**,登录页面会自动检测用户输入的标识符类型,并显示相应的验证选项。当连续输入数字时会切换为带区号的手机号格式,输入“@”符号时会切换为邮箱格式。 + - 手机号国家区号默认根据用户浏览器语言环境设置,用户可手动切换。你可以使用 [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 参数设置特定的默认国家区号。详见[本地化语言](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience)。 +- **启用的验证因子:** + - **仅密码:** 登录页面首屏会同时显示标识符和密码输入框。 + - **仅验证码:** 首屏显示标识符输入框,第二屏显示验证码输入框。 + - **密码和验证码:** 首屏输入标识符,第二屏根据验证顺序输入密码或验证码,并提供切换链接,允许用户在两种验证方式间切换。 ### 示例 \{#examples}
-### 示例 1:邮箱地址与密码验证 \{#example-1-email-address-with-password-verification} +### 示例 1:邮箱地址 + 密码验证 \{#example-1-email-address-with-password-verification} -添加 **邮箱地址** 作为登录标识符,并启用 **密码** 因素进行验证。 +添加 **邮箱地址** 作为登录标识符,并启用 **密码** 验证因子。 -邮箱地址与密码验证 +邮箱地址 + 密码验证
-### 示例 2:邮箱 / 手机号启用密码(主要)和验证码(备用)验证 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} +### 示例 2:邮箱/手机号,启用密码(主)和验证码(备选)验证 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} 同时添加 **邮箱地址** 和 **手机号** 作为登录标识符。 -为这两个标识符启用 **密码** 和 **验证码** 因素。 +为两种标识符都启用 **密码** 和 **验证码** 验证因子。 邮箱 / 手机号与密码和验证码验证
-## 在登录时收集额外的用户资料 \{#collect-additional-user-profile-on-sign-in} +## 登录时补充用户资料 \{#collect-additional-user-profile-on-sign-in} -在 Logto 的登录流程中,如果注册标识符设置更新,可能会触发资料补全过程。这确保所有用户,包括现有用户,提供任何新要求的标识符。 +在 Logto 的登录流程中,如果注册标识符设置发生更新,可能会触发资料补全流程。这确保所有用户(包括已有用户)都能补充任何新增的必填标识符。 -当开发者添加新的标识符(如邮箱地址)时,它将成为所有用户的必填项。如果返回用户使用现有标识符(如用户名)登录,他们将被提示提供并验证新标识符(如果其资料中缺少)。只有在完成此步骤后,他们才能访问应用程序,确保顺利且一致地过渡到更新的要求。 +当开发者添加了新的标识符(如邮箱地址)后,所有用户都必须填写。如果已有用户用原有标识符(如用户名)登录,但资料中缺少新标识符,则会被提示补充并验证新标识符。只有完成此步骤后,才能访问应用,确保平滑且一致地过渡到新要求。 -分解流程: +流程分解如下: -1. **用户名** 之前被设置为注册标识符,并自动启用了 **创建你的密码** 设置。 -2. **邮箱地址** 后来被设置为注册标识符。**邮箱地址** 标识符自动添加为启用的登录选项。 -3. 返回用户使用其用户名和密码登录。 -4. 用户在初始登录步骤后被提示提供并验证邮箱地址。 +1. 之前设置 **用户名** 作为注册标识符,并自动启用 **创建密码** 设置。 +2. 后续将 **邮箱地址** 设置为注册标识符,**邮箱地址** 标识符会自动添加为启用的登录选项。 +3. 回访用户用用户名和密码登录。 +4. 用户在初步登录后被提示补充并验证邮箱地址。 ```mermaid flowchart TD @@ -93,17 +94,17 @@ flowchart TD B -.-> C{{需要邮箱地址且缺失?}} C -->|是| D[输入邮箱地址] D --> E[输入验证码] - E --> F[成功登录] + E --> F[登录成功] C --> |否| F ``` -同样的过程也适用于 **创建你的密码** 注册设置。如果在注册流程中新启用了 **创建你的密码** 设置,**密码** 因素将自动为你选择的所有登录标识符启用。所有没有密码的返回用户将在登录过程中被提示创建一个密码。 +同样的流程也适用于 **创建密码** 注册设置。如果在注册流程中新启用了 **创建密码** 设置,**密码** 因子会自动为你选择的所有登录标识符启用。所有没有密码的回访用户将在登录过程中被提示创建密码。 :::note -注意:对于自定义登录流程,请参考 [Bring your UI](/customization/bring-your-ui/) 功能。 +注意:如需自定义登录流程,请参考 [自定义界面 (Bring your UI)](/customization/bring-your-ui/) 功能。 ::: -## 常见问题解答 \{#faqs} +## 常见问题 \{#faqs}
@@ -112,12 +113,12 @@ flowchart TD -Logto 目前不支持无头 API 用于登录和注册。然而,你可以使用我们的 [Bring your UI](/customization/bring-your-ui/) 功能将自定义登录表单上传到 Logto。我们还支持多种登录参数,你可以使用这些参数预填充从你的应用程序收集的用户标识符到登录表单中,或直接通过第三方社交或企业单点登录 (SSO) 提供商登录。了解更多信息,请访问 [认证 (Authentication) 参数](/end-user-flows/authentication-parameters/)。 +Logto 目前不支持无界面 API 方式的登录和注册。但你可以使用我们的 [自定义界面 (Bring your UI)](/customization/bring-your-ui/) 功能,将自定义登录表单上传到 Logto。我们还支持多种登录参数,你可以用来预填充从你的应用收集到的用户标识符,或直接通过第三方社交或企业 SSO 提供商登录。详见 [认证参数](/end-user-flows/authentication-parameters/)。
## 相关资源 \{#related-resources} -邮箱注册和登录体验 +邮箱注册与登录体验 -用户名注册和登录体验 +用户名注册与登录体验 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index ff9baf513cf..7dec7e0e191 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -4,33 +4,43 @@ sidebar_position: 1 # 邮箱 / 手机号 / 用户名注册 -用户注册是用户参与你的应用的第一步。Logto 支持多种注册方式,包括用户名密码、邮箱或手机号验证、[社交注册](/end-user-flows/sign-up-and-sign-in/social-sign-in) 和 [企业单点登录 (SSO)](/end-user-flows/enterprise-sso)。你可以根据应用需求设置最合适的注册方式。 +用户注册是用户参与你的应用程序的第一步。Logto 支持多种注册方式,包括用户名密码、邮箱或手机号验证、[社交注册](/end-user-flows/sign-up-and-sign-in/social-sign-in) 和 [企业单点登录 (SSO)](/end-user-flows/enterprise-sso)。你可以根据应用需求设置最合适的注册方式。 -访问 控制台 > 登录体验 > 注册与登录 开始配置标识符注册流程。 +前往 控制台 > 登录体验 > 注册与登录 开始配置标识符注册流程。 注册设置 ## 设置注册标识符 \{#set-up-the-sign-up-identifier} -为了在 Logto 中成功创建新用户账户,用户必须提供至少一个**标识符**,以在 Logto 系统中唯一标识他们。第一步,选择用户在注册过程中必须提供的标识符。可选项包括: +为了在 Logto 中成功创建新用户账户,用户必须至少提供一个**标识符**,以在 Logto 系统内唯一标识他们。第一步,选择用户在注册过程中必须提供的标识符。可选项包括: - **用户名**:用户可用于登录应用的唯一 [用户名](/user-management/user-data#username)。 - **邮箱地址**:用户可用于登录应用的有效 [邮箱地址](/user-management/user-data#primary_email)。 - **手机号**:用户可用于登录应用的有效 [手机号](/user-management/user-data#primary_phone)。 -- **邮箱地址或手机号**:允许用户用有效的邮箱地址或手机号注册。 +- **邮箱地址或手机号**:允许用户使用有效邮箱地址或手机号注册。 在注册过程中收集的所有标识符,在同一租户下必须是唯一的。它们会被存储在[用户资料](/user-management/user-data#user-profile)中,并可用于登录集成了 Logto 的应用。 如果未选择任何标识符,则适用于仅 [社交](/end-user-flows/sign-up-and-sign-in/social-sign-in) 或仅 [企业单点登录 (SSO)](/end-user-flows/enterprise-sso) 的注册方式。 -你可以调整注册标识符的顺序,以优先让用户首先填写你想要的标识符。这个顺序会体现在注册流程中,第一个标识符会出现在初始注册界面,其余的会在后续步骤收集。 +你可以调整注册标识符的顺序,以优先让用户首先填写你希望的标识符。这个顺序会体现在注册流程中,第一个标识符会出现在初始注册界面,其余的在后续步骤收集。 -## 设置注册验证设置 \{#set-up-the-sign-up-verification-settings} +:::tip +如需在注册时屏蔽特定类型的邮箱地址(如一次性邮箱、带加号 (+) 的子地址、指定邮箱或整个域名),可在安全设置中使用 **黑名单** 功能。详见 [黑名单](/security/blocklist)。 +::: + +:::tip +手机号的**国家区号**默认根据用户浏览器的语言环境自动选择。例如,若用户浏览器语言为 `fr`,则默认区号为法国 (+33)。 + +你也可以使用 [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 认证参数设置登录体验的语言,这也会影响默认国家区号。 +::: + +## 设置注册验证方式 \{#set-up-the-sign-up-verification-settings} -为确保用户注册及后续登录过程的安全,你还需要为注册过程中收集的标识符配置验证设置。可用设置包括: +为确保用户注册及后续登录过程的安全,你还需要为注册时收集的标识符配置验证方式。可用设置包括: -- **创建密码:** 要求用户在注册时创建一个符合你登录体验设置中密码策略的密码。该密码与用户标识符一起作为登录应用的凭证。如果你将 **用户名** 设为注册标识符,则此项会自动启用,因为 **用户名** 只能与密码配合才能有效验证用户身份。[密码策略](/security/password-policy) 可根据你的安全需求自定义。 -- **注册时验证**:要求用户在注册时验证邮箱地址或手机号。目前,Logto 只接受已验证的邮箱和手机号作为标识符。当 **邮箱地址** 或 **手机号** 作为注册标识符时,此项会自动启用。用户必须在注册过程中输入发送到邮箱或手机号的验证码以确认归属权。 +- **创建密码**:要求用户在注册时创建一个符合你登录体验设置中密码策略的密码。该密码与用户标识符一起作为登录凭证。如果你将**用户名**设为注册标识符,则此项会自动启用,因为**用户名**只能与密码配合使用以有效验证用户身份。[密码策略](/security/password-policy) 可自定义以满足你的安全需求。 +- **注册时验证**:要求用户在注册时验证邮箱地址或手机号。目前,Logto 仅接受已验证的邮箱和手机号作为标识符。当**邮箱地址**或**手机号**作为注册标识符时,此项会自动启用。用户需在注册过程中输入发送到邮箱或手机号的验证码以确认归属权。 | 标识符 | 创建用户密码 | 注册时验证 | | ------------ | ------------ | ---------- | @@ -48,7 +58,7 @@ sidebar_position: 1 -选择 **用户名** 作为注册标识符。创建密码会自动启用。 +选择**用户名**作为注册标识符。创建密码自动启用。 用户名和密码注册 @@ -57,11 +67,11 @@ sidebar_position: 1
-### 类型 2:邮箱地址或手机号 + 验证流程 \{#type-2-email-address-or-phone-number-with-verification-flow} +### 类型 2:邮箱或手机号 + 验证流程 \{#type-2-email-address-or-phone-number-with-verification-flow} -选择 **邮箱地址或手机号** 作为注册标识符。**注册时验证** 强制启用。 +选择**邮箱地址或手机号**作为注册标识符。**注册时验证**强制启用。 邮箱或手机号注册并验证 @@ -70,39 +80,39 @@ sidebar_position: 1
-### 类型 3:邮箱地址 + 验证 + 创建密码 \{#type-3-email-address-with-verification-and-password-creation} +### 类型 3:邮箱 + 验证 + 创建密码 \{#type-3-email-address-with-verification-and-password-creation} -选择 **邮箱地址** 作为注册标识符。**注册时验证** 强制启用。启用 **创建密码**,要求用户在注册时创建密码。(手机号注册流程同理) +选择**邮箱地址**作为注册标识符。**注册时验证**强制启用。启用**创建密码**,要求用户注册时创建密码。(手机号注册流程同理) -邮箱注册并验证和创建密码 +邮箱注册并验证及创建密码
-### 类型 4:邮箱地址 + 验证 + 用户名 + 创建密码 \{#type-4-email-address-with-verification-username-and-password-creation} +### 类型 4:邮箱 + 验证 + 用户名 + 创建密码 \{#type-4-email-address-with-verification-username-and-password-creation} -选择 **邮箱地址** 和 **用户名** 作为注册标识符。**注册时验证** 强制启用。启用 **创建密码**,要求用户在注册时创建密码。 +选择**邮箱地址**和**用户名**作为注册标识符。**注册时验证**强制启用。启用**创建密码**,要求用户注册时创建密码。 -邮箱和用户名注册并验证和创建密码 +邮箱和用户名注册并验证及创建密码
## 使用社交或企业单点登录 (SSO) 注册 \{#sign-up-with-social-or-enterprise-sso} -除了这些传统的标识符注册方式,Logto 还支持通过社交和企业单点登录 (SSO) 身份提供商进行无密码注册,让用户注册流程更加顺畅和友好。 +除了这些传统的标识符注册方式,Logto 还支持通过社交和企业单点登录 (SSO) 身份提供商实现无密码注册,让用户注册流程更加顺畅和友好。 一旦在 Logto 配置并启用了 [社交连接器](/connectors/social-connectors) 或 [企业单点登录 (SSO) 连接器](/connectors/enterprise-connectors),用户即可使用已有的社交或企业身份便捷注册。社交和企业单点登录 (SSO) 注册方式允许用户跳过创建密码或验证邮箱 / 手机号等额外步骤。Logto 会自动通过已验证的社交或企业身份同步用户信息,并存储到用户资料中。 -查看 [社交登录](/end-user-flows/sign-up-and-sign-in/social-sign-in/) 和 [企业单点登录 (SSO)](/end-user-flows/enterprise-sso/) 章节,了解更多社交和企业单点登录 (SSO) 注册流程。 +详见 [社交登录](/end-user-flows/sign-up-and-sign-in/social-sign-in/) 和 [企业单点登录 (SSO)](/end-user-flows/enterprise-sso/) 章节,了解社交和企业单点登录 (SSO) 注册流程。 :::note -注意:如需自定义注册流程,请参考 [自定义 UI (Bring your UI)](/customization/bring-your-ui/) 功能。 +注意:如需自定义注册流程,请参考 [自定义界面 (Bring your UI)](/customization/bring-your-ui/) 功能。 ::: ## 注册时收集更多用户信息 \{#collect-additional-user-info-on-sign-up} @@ -111,13 +121,13 @@ sidebar_position: 1 **方式一:收集用户资料** -将 Logto 预置的“告诉我们你的信息”步骤直接加入注册流程。用户需填写所有必填项后才能完成注册。此方式无需编码,开箱即用。 +直接在注册流程中加入 Logto 预设的“完善个人信息”步骤。用户需填写所有必填项后才算注册完成。这种方式无需编写代码,开箱即用。 -通过 控制台 > 登录体验 > 收集用户资料 配置,选择预设基础数据字段或自定义字段并灵活校验。了解更多:[收集用户资料](/end-user-flows/collect-user-profile) +通过 控制台 > 登录体验 > 收集用户资料 设置,选择预设基础字段或自定义字段并灵活校验。了解更多:[收集用户资料](/end-user-flows/collect-user-profile) **方式二:自托管引导流程** -注册成功后将用户重定向到你自定义的引导流程,实现完全自定义的数据收集体验。此方式让你完全掌控用户体验,支持复杂的多步骤引导。 +注册成功后将用户重定向到你自定义的引导流程,实现完全自定义的数据收集体验。适合需要复杂多步引导的场景。 可通过 [Account API](/end-user-flows/account-settings/by-account-api) 编程方式管理用户资料数据。 @@ -130,7 +140,7 @@ sidebar_position: 1 -了解如何实现 [仅邀请注册流程](/end-user-flows/sign-up-and-sign-in/disable-user-registration/#implement-an-invitation-only-sign-up-flow) +了解如何实现 [仅邀请注册流程](/end-user-flows/sign-up-and-sign-in/disable-user-registration/#implement-an-invitation-only-sign-up-flow)。
@@ -141,7 +151,7 @@ sidebar_position: 1 -Logto 目前不支持无界面 API 进行注册和登录。你可以使用 [自定义 UI (Bring your UI)](/customization/bring-your-ui/) 功能上传自定义注册表单,或通过登录参数将用户信息从你的网站传递到 Logto。了解更多用户标识符传递方式:[认证 (Authentication) 参数](/end-user-flows/authentication-parameters/)。 +Logto 目前不支持无界面 API 方式注册和登录。你可以使用 [自定义界面 (Bring your UI)](/customization/bring-your-ui/) 功能上传自定义注册表单,或通过登录参数将用户信息从你的网站传递到 Logto。了解更多用户标识符传递方式见 [认证参数](/end-user-flows/authentication-parameters/)。 @@ -152,7 +162,7 @@ Logto 目前不支持无界面 API 进行注册和登录。你可以使用 [自 -订阅 `User.Created` webhook 事件,向新用户发送欢迎邮件。了解更多 [webhook 事件](/developers/webhooks/webhooks-events/#data-mutation-hook-events)。 +订阅 `User.Created` webhook 事件,即可在新用户注册时触发欢迎邮件。详见 [webhook 事件](/developers/webhooks/webhooks-events/#data-mutation-hook-events)。 @@ -163,8 +173,8 @@ Logto 目前不支持无界面 API 进行注册和登录。你可以使用 [自 -目前,Logto 只支持已验证的邮箱和手机号作为标识符。验证流程是确保用户标识符安全和归属的必要步骤。 -对未验证邮箱或手机号的支持已在我们的[路线图](https://feedback.logto.io/roadmap)中,敬请关注后续更新! +目前,Logto 仅支持已验证的邮箱和手机号作为标识符。验证流程是确保用户标识符安全和归属的必要步骤。 +对未验证邮箱或手机号的支持已在我们的 [路线图](https://feedback.logto.io/roadmap) 上,敬请关注后续更新! diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index fd969f2ba32..7b4fdc7c548 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,148 +1,155 @@ --- -description: 参考 OIDC 认证 (Authentication) 集成的关键应用参数,包括重定向 URI、端点、刷新令牌、后端注销等。 +description: 参考 OIDC 认证 (Authentication) 集成的关键应用参数,包括重定向 URI、端点、刷新令牌 (Refresh token)、后端注销等。 sidebar_position: 6 --- -# 应用数据结构 +# 应用程序数据结构 -## 介绍 \{#introduction} +## 简介 \{#introduction} -在 Logto 中,_应用_ 指的是在 Logto 平台上注册的软件程序或服务,并被授予访问用户信息或代表用户执行操作的授权。应用用于识别向 Logto API 发出的请求来源,以及管理用户访问这些应用的认证 (Authentication) 和授权 (Authorization) 过程。 +在 Logto 中,_应用程序_ 指的是在 Logto 平台上注册并被授权访问用户信息或代表用户执行操作的特定软件程序或服务。应用程序用于标识向 Logto API 发起请求的来源,并管理用户访问这些应用程序时的认证 (Authentication) 和授权 (Authorization) 流程。 -在 Logto 的登录体验中使用应用允许用户从一个位置轻松访问和管理他们授权的应用,并提供一致且安全的认证 (Authentication) 过程。这有助于简化用户体验,并确保只有授权的个人才能访问敏感信息或代表组织执行操作。 +在 Logto 的登录体验中使用应用程序,使用户能够从一个位置轻松访问和管理他们已授权的应用程序,并拥有一致且安全的认证 (Authentication) 流程。这有助于简化用户体验,并确保只有被授权的个人才能访问敏感信息或代表组织执行操作。 -应用还用于 Logto 的审计日志中,以跟踪用户活动并识别任何潜在的安全威胁或漏洞。通过将特定操作与特定应用关联,Logto 可以提供有关数据如何被访问和使用的详细见解,使组织能够更好地管理其安全和合规要求。如果你想将你的应用与 Logto 集成,请参阅 [Integrate Logto](/integrate-logto)。 +应用程序还用于 Logto 的审计日志中,用于跟踪用户活动并识别任何潜在的安全威胁或漏洞。通过将特定操作与某个应用程序关联,Logto 能够提供有关数据如何被访问和使用的详细洞察,帮助组织更好地管理其安全和合规性需求。 +如果你想将你的应用程序集成到 Logto,请参阅 [集成 Logto](/integrate-logto)。 ## 属性 \{#properties} -### 应用 ID \{#application-id} +### 应用程序 ID \{#application-id} -_应用 ID_ 是一个自动生成的唯一键,用于在 Logto 中标识你的应用,并在 OAuth 2.0 中被引用为 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)。 +_应用程序 ID_ 是用于在 Logto 中唯一标识你的应用程序的自动生成密钥,在 OAuth 2.0 中被称为 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)。 -### 应用类型 \{#application-types} +### 应用程序类型 \{#application-types} -_应用_ 可以是以下应用类型之一: +_应用程序_ 可以是以下类型之一: -- **原生应用** 是在本地环境中运行的应用。例如,iOS 应用,Android 应用。 -- **单页应用** 是在网页浏览器中运行的应用,它通过从服务器获取新数据来更新页面,而无需加载整个新页面。例如,React DOM 应用,Vue 应用。 -- **传统 Web 应用** 是由 Web 服务器单独渲染和更新页面的应用。例如,JSP,PHP。 -- **机器对机器 (M2M) 应用** 是在机器环境中运行的应用,用于直接的服务对服务通信,无需用户交互。 +- **原生应用**:运行在原生环境中的应用。例如,iOS 应用、Android 应用。 +- **单页应用**:运行在 Web 浏览器中的应用,通过从服务器获取新数据来更新页面,而无需加载整个新页面。例如,React DOM 应用、Vue 应用。 +- **传统 Web 应用**:仅由 Web 服务器渲染和更新页面的应用。例如,JSP、PHP。 +- **机器对机器 (M2M) 应用**:在机器环境中运行、用于直接服务间通信且无需用户交互的应用程序。 -### 应用密钥 \{#application-secret} +### 应用程序密钥 \{#application-secret} -_应用密钥_ 是用于在认证 (Authentication) 系统中认证应用的密钥,特别是对于私有客户端(传统 Web 和 M2M 应用)作为私有安全屏障。 +_应用程序密钥_ 是用于在认证 (Authentication) 系统中认证应用程序的密钥,专为私有客户端(传统 Web 和 M2M 应用)作为私有安全屏障。 -### 应用名称 \{#application-name} +:::tip +单页应用 (SPA) 和原生应用不提供应用密钥。SPA 和原生应用属于“公共客户端”,无法保密(浏览器代码或应用包可被检查)。Logto 通过 PKCE、严格的重定向 URI / CORS 校验、短生命周期访问令牌 (Access token) 和刷新令牌 (Refresh token) 轮换来保护它们,而不是使用应用密钥。 +::: + +### 应用程序名称 \{#application-name} -_应用名称_ 是应用的可读名称,将显示在管理控制台中。 +_应用程序名称_ 是应用程序的人类可读名称,将显示在管理控制台中。 -_应用名称_ 是在 Logto 中管理应用的重要组成部分,因为它允许管理员轻松识别和跟踪平台内各个应用的活动。 +_应用程序名称_ 是在 Logto 中管理应用程序的重要组成部分,因为它允许管理员在平台内轻松识别和跟踪各个应用程序的活动。 :::note -需要注意的是,_应用名称_ 应该被仔细选择,因为它将对所有有权访问管理控制台的用户可见。它应该准确反映应用的目的和功能,同时易于理解和识别。 +需要注意的是,_应用程序名称_ 应该谨慎选择,因为它将对所有有权访问管理控制台的用户可见。它应准确反映应用程序的用途和功能,同时易于理解和识别。 ::: ### 描述 \{#description} -应用的简要描述将显示在管理控制台的应用详情页面上。描述旨在为管理员提供有关应用的附加信息,例如其目的、功能和任何其他相关细节。 +应用程序的简要描述将显示在管理控制台的应用程序详情页。描述旨在为管理员提供有关应用程序的更多信息,例如其用途、功能以及其他相关细节。 ### 重定向 URI \{#redirect-uris} -_重定向 URI_ 是为应用预先配置的一组有效重定向 URI。当用户登录到 Logto 并尝试访问应用时,他们将被重定向到应用设置中指定的允许 URI 之一。 +_重定向 URI_ 是为应用程序预先配置的一组有效重定向 URI。当用户登录 Logto 并尝试访问应用程序时,他们会被重定向到应用程序设置中指定的允许 URI 之一。 -允许的 URI 列表用于验证应用在认证 (Authentication) 过程中发送给 Logto 的授权请求中包含的重定向 URI。如果授权请求中指定的重定向 URI 与应用设置中的允许 URI 之一匹配,则用户在成功认证 (Authentication) 后将被重定向到该 URI。如果重定向 URI 不在允许列表中,用户将不会被重定向,认证 (Authentication) 过程将失败。 +允许的 URI 列表用于校验应用程序在认证 (Authentication) 流程中向 Logto 发送的授权请求中包含的重定向 URI。如果授权请求中指定的重定向 URI 与应用程序设置中的允许 URI 之一匹配,则用户在认证 (Authentication) 成功后会被重定向到该 URI。如果重定向 URI 不在允许列表中,用户将不会被重定向,认证 (Authentication) 流程将失败。 :::note -确保所有有效的重定向 URI 都被添加到 Logto 中应用的允许列表中,以确保用户在认证 (Authentication) 后能够成功访问应用。 +务必确保所有有效的重定向 URI 都已添加到 Logto 应用程序的允许列表中,以确保用户在认证 (Authentication) 后能够成功访问应用程序。 ::: -你可以查看 [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) 以获取更多信息。 +你可以查阅 [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) 了解更多信息。 - 理解 OIDC 中的重定向 URI 与授权代码流程 + 理解 OIDC 授权码流程中的重定向 URI ### 注销后重定向 URI \{#post-sign-out-redirect-uris} -_注销后重定向 URI_ 是为应用预先配置的一组有效 URI,用于在用户从 Logto 注销后重定向用户。 +_注销后重定向 URI_ 是为应用程序预先配置的一组有效 URI,用于在用户从 Logto 注销后重定向用户。 -使用允许的 _注销后重定向 URI_ 进行注销是 OIDC 中 RP 发起(依赖方发起)注销规范的一部分。该规范为应用提供了一种标准化的方法来为用户发起注销请求,其中包括在用户注销后将其重定向到预先配置的端点。 +允许的 _注销后重定向 URI_ 用于注销,是 OIDC 中 RP-Initiated(依赖方发起)注销规范的一部分。该规范为应用程序发起用户注销请求提供了标准化方法,包括在用户注销后将其重定向到预先配置的端点。 -当用户从 Logto 注销时,他们的会话将被终止,并被重定向到应用设置中指定的允许 URI 之一。这确保了用户在注销后仅被引导到授权和有效的端点,有助于防止未经授权的访问和与将用户重定向到未知或未经验证的端点相关的安全风险。 +当用户从 Logto 注销时,他们的会话将被终止,并被重定向到应用程序设置中指定的允许 URI 之一。这确保用户在注销后只会被引导到授权且有效的端点,有助于防止将用户重定向到未知或未经验证端点所带来的未授权访问和安全风险。 -你可以查看 [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) 以获取更多信息。 +你可以查阅 [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) 了解更多信息。 ### CORS 允许的来源 \{#cors-allowed-origins} -_CORS(跨域资源共享)允许的来源_ 是一组允许的来源,应用可以从这些来源向 Logto 服务发出请求。任何不在允许列表中的来源将无法向 Logto 服务发出请求。 +_CORS(跨域资源共享)允许的来源_ 是允许应用程序向 Logto 服务发起请求的来源列表。不在允许列表中的来源将无法向 Logto 服务发起请求。 -CORS 允许的来源列表用于限制来自未经授权域的 Logto 服务访问,并帮助防止跨站请求伪造 (CSRF) 攻击。通过在 Logto 中为应用指定允许的来源,服务可以确保只有授权的域能够向服务发出请求。 +CORS 允许的来源列表用于限制来自未授权域的对 Logto 服务的访问,并有助于防止跨站请求伪造(CSRF)攻击。通过在 Logto 中为应用程序指定允许的来源,服务可以确保只有被授权的域能够向服务发起请求。 :::note -允许的来源列表应包含应用将被服务的来源。这确保了来自应用的请求被允许,而来自未经授权来源的请求被阻止。 +允许的来源列表应包含应用程序实际部署的来源。这确保来自应用程序的请求被允许,而来自未授权来源的请求会被阻止。 ::: -### OpenID 提供商配置端点 \{#openid-provider-configuration-endpoint} +### OpenID 提供方配置端点 \{#openid-provider-configuration-endpoint} -[OpenID Connect 发现](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) 的端点。 +[OpenID Connect 发现](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest)的端点。 ### 授权端点 \{#authorization-endpoint} -_授权端点_ 是一个 OIDC 术语,是用于启动用户认证 (Authentication) 过程的必需端点。当用户尝试访问已在 Logto 平台上注册的受保护资源或应用时,他们将被重定向到 _授权端点_ 以认证 (Authentication) 其身份并获得访问请求资源的授权 (Authorization)。 +_授权端点_ 是 OIDC 术语,是用于启动用户认证 (Authentication) 流程的必需端点。当用户尝试访问已在 Logto 平台注册的受保护资源或应用程序时,他们将被重定向到 _授权端点_ 以认证 (Authentication) 其身份并获得访问所请求资源的授权 (Authorization)。 -你可以查看 [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 以获取更多信息。 +你可以查阅 [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 了解更多信息。 ### 令牌端点 \{#token-endpoint} -_令牌端点_ 是一个 OIDC 术语,是一个 Web API 端点,OIDC 客户端用于从 OIDC 提供者获取访问令牌、ID 令牌或刷新令牌。 +_令牌端点_ 是 OIDC 术语,是 OIDC 客户端用于从 OIDC 提供方获取访问令牌 (Access token)、ID 令牌 (ID token) 或刷新令牌 (Refresh token) 的 Web API 端点。 -当 OIDC 客户端需要获取访问令牌或 ID 令牌时,它会向令牌端点发送一个包含授权 (Authorization) 授权的请求,通常是授权代码或刷新令牌。令牌端点验证授权 (Authorization) 授权,如果授权有效,则向客户端颁发访问令牌或 ID 令牌。 +当 OIDC 客户端需要获取访问令牌 (Access token) 或 ID 令牌 (ID token) 时,会携带授权许可(通常是授权码或刷新令牌 (Refresh token))向令牌端点发起请求。令牌端点会校验授权许可,如果有效,则向客户端颁发访问令牌 (Access token) 或 ID 令牌 (ID token)。 -你可以查看 [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) 以获取更多信息。 +你可以查阅 [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) 了解更多信息。 -### 用户信息端点 \{#userinfo-endpoint} +### Userinfo 端点 \{#userinfo-endpoint} -OpenID Connect [用户信息端点](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)。 +OpenID Connect [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)。 -### 始终颁发刷新令牌 \{#always-issue-refresh-token} +### 总是颁发刷新令牌 (Refresh token) \{#always-issue-refresh-token} -_可用性:传统 Web,SPA_ +_适用范围:传统 Web、SPA_ -启用后,Logto 将始终颁发刷新令牌,无论认证 (Authentication) 请求中是否出现 `prompt=consent`,也无论权限 (Scopes) 中是否出现 `offline_access`。 +启用后,无论认证请求中是否包含 `prompt=consent`,或权限 (Scope) 中是否包含 `offline_access`,Logto 都会始终颁发刷新令牌 (Refresh token)。 -然而,除非必要(通常对某些需要刷新令牌的第三方 OAuth 集成有用),否则不建议这样做,因为这与 OpenID Connect 不兼容,可能会导致问题。 +但除非必要(通常用于某些需要刷新令牌 (Refresh token) 的第三方 OAuth 集成),否则不建议这样做,因为这与 OpenID Connect 不兼容,且可能带来问题。 -### 刷新令牌轮换 \{#rotate-refresh-token} +### 刷新令牌 (Refresh token) 轮换 \{#rotate-refresh-token} -_默认:`true`_ +_默认值:`true`_ -启用后,Logto 将在以下条件下为令牌请求颁发新的刷新令牌: +启用后,Logto 会在以下情况下为令牌请求颁发新的刷新令牌 (Refresh token): -- 如果刷新令牌已被轮换(通过颁发新令牌延长其 TTL)一年;**或** -- 如果刷新令牌接近其过期时间(>=70% 的原始生存时间 (TTL) 已过);**或** -- 如果客户端是公共客户端,例如原生应用或单页应用 (SPA)。 +- 如果刷新令牌 (Refresh token) 已轮换(通过颁发新令牌延长其 TTL)一年;**或** +- 如果刷新令牌 (Refresh token) 接近过期时间(已过去原始 TTL 的 >=70%);**或** +- 如果客户端为公共客户端,例如原生应用或单页应用 (SPA)。 :::note -对于公共客户端,当启用此功能时,每当客户端使用刷新令牌交换新访问令牌时,都会颁发一个新的刷新令牌。 -虽然你仍然可以为这些公共客户端关闭此功能,但强烈建议出于安全原因保持启用。 +对于公共客户端,启用此功能后,客户端每次使用刷新令牌 (Refresh token) 换取新访问令牌 (Access token) 时,都会颁发新的刷新令牌 (Refresh token)。 +虽然你仍然可以为这些公共客户端关闭该功能,但出于安全考虑,强烈建议保持启用状态。 ::: -理解刷新令牌轮换 + + 理解刷新令牌 (Refresh token) 轮换 + -### 刷新令牌生存时间 (TTL)(天)\{#refresh-token-time-to-live-ttl-in-days} +### 刷新令牌 (Refresh token) 存活时间(TTL,天)\{#refresh-token-time-to-live-ttl-in-days} -_可用性:非 SPA;默认:14 天_ +_适用范围:非 SPA;默认值:14 天_ -刷新令牌在过期并失效之前可用于请求新访问令牌的持续时间。令牌请求将刷新令牌的 TTL 扩展到此值。 +刷新令牌 (Refresh token) 可用于请求新访问令牌 (Access token) 的有效期,过期后将失效。每次令牌请求会将刷新令牌 (Refresh token) 的 TTL 延长到该值。 -通常,较低的值是首选。 +通常建议设置较低的值。 -注意:出于安全原因,SPA(单页应用)中不提供 TTL 刷新。这意味着 Logto 不会通过令牌请求来扩展 TTL。为了增强用户体验,你可以启用“刷新令牌轮换”功能,允许 Logto 在必要时颁发新的刷新令牌。 +注意:出于安全原因,SPA(单页应用)不支持 TTL 刷新。这意味着 Logto 不会通过令牌请求延长 TTL。为提升用户体验,你可以启用“刷新令牌 (Refresh token) 轮换”功能,让 Logto 在必要时颁发新的刷新令牌 (Refresh token)。 ### 后端注销 URI \{#backchannel-logout-uri} -OpenID Connect 后端注销端点。有关更多信息,请参阅 [Federated sign-out: Back-channel logout](#)。 +OpenID Connect 后端注销端点。详见 [联合注销:后端注销](#)。 ### 自定义数据 \{#custom-data} -未列在预定义应用属性中的其他自定义应用信息,用户可以根据其特定需求定义自己的自定义数据字段,例如业务特定的设置和配置。 +未在预定义应用程序属性中列出的其他自定义应用信息,用户可根据自身需求定义自定义数据字段,如业务相关设置和配置。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index 9ec9aa37d98..0b2c9856bda 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -1,5 +1,5 @@ --- -description: 通过我们的快速入门指南,在几分钟内集成应用认证 (Authentication) 和身份联合。 +description: 只需几分钟,通过我们的快速入门指南集成应用认证 (Authentication) 和身份联合。 sidebar_position: 1 --- @@ -7,24 +7,39 @@ sidebar_position: 1 按照以下步骤,使用 Logto 为你的应用程序添加认证 (Authentication),无论是面向用户的应用还是机器对机器服务: -1. 前往 控制台 > 应用程序 +1. 进入 控制台 > 应用程序 2. 点击“创建应用程序”以添加新应用 3. 选择你的 [应用框架](/quick-starts) 开始。如果没有找到你的框架,请点击应用创建页面右下角的“无框架创建应用”按钮,通过选择 [应用类型](/integrate-logto/application-data-structure/#application-types) 创建应用,或者按照我们的 [SDK 规范](/developers/sdk-conventions) 提交功能请求或贡献 SDK。 -4. 选择框架后,你会看到该框架 SDK 的快速入门指南。按照步骤配置并集成你的应用。如果你需要帮助理解集成过程中涉及的概念,可以参考 [理解 Logto 认证 (Authentication) 流程](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) 以深入了解集成原理。 +4. 选择框架后,你会看到该框架 SDK 的快速入门指南。按照步骤配置并集成你的应用。如果你需要了解集成过程中涉及的概念,可以参考 [理解 Logto 认证 (Authentication) 流程](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) 以获得更深入的理解。 :::note -控制台中的指南仅用于使用我们的 SDK 快速开始 Logto。如需完整的集成指南,包括高级 SDK 用法,请查看 [快速入门](/quick-starts) 部分。 +控制台中的指南仅用于使用我们的 SDK 快速开始 Logto。如需完整集成指南,包括高级 SDK 用法,请查看 [快速入门](/quick-starts) 部分。 ::: -5. 完成后,你可以进一步探索 Logto 的更多内容: +5. 完成后,你就可以进一步探索 Logto 的更多内容: 终端用户流程 授权 (Authorization) 组织 (Organizations) +## 常见问题 \{#faqs} + +
+ + ### 我的后端服务如何使用 Logto 验证用户令牌并管理用户? + +要在你的后端 API(如 Python、Node.js、Go、Java、PHP 等)中安全地验证访问令牌,并以编程方式管理用户,请参考指南:[如何在 API 服务或后端验证访问令牌](/authorization/validate-access-tokens)。 + +该文档涵盖: + +- 如何在每次 API 调用中检查持有者令牌的有效性 +- 将 Logto 集成到多个前端应用和后端服务的最佳实践 + +
+ ## 相关资源 \{#related-resources} diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 6f7d9d24f53..14995b2ee16 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -1,5 +1,5 @@ --- -description: 使用 Logto 创建你自己的身份提供商 (Identity Provider, IdP),为第三方应用启用单点登录 (SSO)。轻松集成 OIDC / OAuth 应用。 +description: 使用 Logto 创建你自己的身份提供商 (IdP),为第三方应用启用单点登录 (SSO)。轻松集成 OIDC / OAuth 应用。 sidebar_position: 4 --- @@ -14,20 +14,20 @@ Logto 的第三方应用集成让你可以将 Logto 作为外部应用的 [身 与 [将 Logto 集成到你的应用](/integrate-logto/integrate-logto-into-your-application) 指南中你自己开发和完全控制的应用不同,第三方应用是由外部开发者或业务合作伙伴开发的独立服务。 -这种集成方式非常适合常见的业务场景。你可以让用户使用他们的 Logto 账户访问合作伙伴应用,就像企业用户用 Google Workspace 登录 Slack 一样。你也可以构建一个开放平台,让第三方应用可以添加“使用 Logto 登录”功能,类似于“使用 Google 登录”。 +这种集成方式非常适合常见的业务场景。你可以让用户使用他们的 Logto 账户访问合作伙伴应用,就像企业用户用 Google Workspace 登录 Slack 一样。你还可以构建一个开放平台,让第三方应用添加“使用 Logto 登录”功能,类似于“使用 Google 登录”。 Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议构建的身份服务,提供 [认证 (Authentication)](https://auth.wiki/authentication) 和 [授权 (Authorization)](https://auth.wiki/authorization) 能力。这使得集成 OIDC 第三方应用与传统 Web 应用一样简单。 -由于 OIDC 是在 [OAuth 2.0](https://auth.wiki/oauth-2.0) 基础上增加了认证 (Authentication) 层,因此你也可以使用 OAuth 协议集成第三方应用。 +由于 OIDC 是在 [OAuth 2.0](https://auth.wiki/oauth-2.0) 基础上增加了认证 (Authentication) 层,因此你也可以通过 OAuth 协议集成第三方应用。 ## 在 Logto 中创建第三方应用 \{#create-an-third-party-application-in-logto} -1. 前往 控制台 > 应用 -2. 选择“第三方应用”作为应用类型,并选择以下集成协议之一: +1. 前往 控制台 > 应用。 +2. 点击“创建应用”按钮,选择“第三方应用”作为应用类型,并选择以下集成协议之一: - OIDC / OAuth 3. 输入你的应用名称和描述,点击“创建”按钮。一个新的第三方应用就会被创建。 -所有已创建的第三方应用会在“应用”页面的“第三方应用”标签下进行分类。这种安排有助于你将它们与你自己的应用区分开,方便你在一个地方统一管理所有应用。 +所有创建的第三方应用都会在“应用”页面的“第三方应用”标签下进行分类。这种安排有助于你将它们与你自己的应用区分开来,更方便地统一管理所有应用。 ## 设置 OIDC 配置 \{#set-up-the-oidc-configurations} @@ -36,21 +36,21 @@ Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议 ::: 1. 提供你的 OIDC 第三方应用的 [**重定向 URI**](/integrate-logto/application-data-structure#redirect-uris)。这是第三方应用在用户通过 Logto 认证 (Authentication) 后重定向用户的 URL。 - 你通常可以在第三方应用的 IdP 连接设置页面找到这些信息。 + 你通常可以在第三方应用的 IdP 连接设置页面找到此信息。 -2. 从 Logto 应用详情页获取 [**client ID**](/integrate-logto/application-data-structure#application-id) 和 [**client secret**](/integrate-logto/application-data-structure#application-secret),并将它们填写到你的服务提供商的 IdP 连接设置页面。 +2. 从 Logto 应用详情页获取 [**client ID**](/integrate-logto/application-data-structure#application-id) 和 [**client secret**](/integrate-logto/application-data-structure#application-secret),并将其填写到你的服务提供商的 IdP 连接设置页面。 3. 从 Logto 应用详情页获取 [**授权端点**](/integrate-logto/application-data-structure#authorization-endpoint) 和 [**令牌端点**](/integrate-logto/application-data-structure#token-endpoint),并提供给你的服务提供商。 - 如果你的服务提供商支持 OIDC 发现,你只需复制 Logto 应用详情页的 **发现端点** 并提供给服务提供商。服务提供商会自动从发现端点获取所有最新的 OIDC 认证 (Authentication) 信息。 + 如果你的服务提供商支持 OIDC 发现,你只需从 Logto 应用详情页复制 **发现端点** 并提供给服务提供商。服务提供商会自动从发现端点获取所有最新的 OIDC 认证 (Authentication) 信息。 否则,点击 **显示端点详情** 按钮以查看所有 OIDC 认证 (Authentication) 端点。 ## OIDC 第三方应用的用户授权页面 (Consent screen) \{#consent-screen-for-oidc-third-party-applications} 出于安全考虑,所有 OIDC 第三方应用在通过 Logto 认证 (Authentication) 后都会被重定向到 [用户授权页面 (Consent screen)](/end-user-flows/consent-screen) 进行用户授权 (Authorization)。 -所有第三方请求的 [用户资料权限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API 资源权限](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[组织权限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) 以及组织成员信息都会在用户授权页面 (Consent screen) 上展示。 +所有第三方请求的 [用户资料权限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API 资源权限](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[组织权限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) 以及组织成员信息都会在用户授权页面上展示。 -只有当用户点击“授权 (Authorize)”按钮后,这些请求的权限才会被授予第三方应用。 +这些请求的权限只有在用户点击“授权”按钮后才会授予第三方应用。
consent screen @@ -73,8 +73,7 @@ Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议 type: 'link', label: '用户授权页面品牌定制', href: '/integrate-logto/third-party-applications/consent-screen-branding', - description: - '个性化用户授权页面 (Consent screen) 外观,使其与你的品牌形象保持一致,提供一致的用户体验。', + description: '个性化用户授权页面外观,使其与你的品牌形象一致,提供一致的用户体验。', customProps: { icon: , }, @@ -87,13 +86,13 @@ Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议
-### 我们如何确保用户在用户授权页面 (Consent screen) 上只能授权他们实际拥有的权限? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} +### 我们如何确保用户只能在用户授权页面 (Consent screen) 授予他们实际拥有的权限? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} -Logto 使用基于角色的访问控制 (RBAC) 来管理用户权限。在用户授权页面 (Consent screen) 上,只有已经通过角色分配给用户的权限 (Scopes) 会被展示。如果第三方应用请求了用户没有的权限 (Scopes),这些权限会被排除,以防止未经授权的授权 (Consent)。 +Logto 使用基于角色的访问控制 (RBAC) 来管理用户权限。在用户授权页面 (Consent screen) 上,只有已经通过角色分配给用户的权限 (Scopes) 会被展示。如果第三方应用请求了用户没有的权限 (Scopes),这些权限将被排除,以防止未经授权的授权 (Consent)。 -管理方式如下: +管理方法如下: - 定义带有特定权限 (Scopes) 的[全局角色](/authorization/role-based-access-control)或[组织角色](/authorization/organization-template)。 - 根据访问需求为用户分配角色。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index 5b1acae65bf..dad55cf538d 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,10 +3,11 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Logto 云服务 -[Logto Cloud](https://cloud.logto.io) 提供了一系列管理和运营服务,帮助你顺畅且轻松地管理身份和资源。由 Logto 托管,包含 [多区域支持](/logto-cloud/tenant-settings#tenant-region)、租户管理、[计费与定价](/logto-cloud/billing-and-pricing)、[成员管理](/logto-cloud/tenant-member-management) 以及控制台基于角色的访问控制 (RBAC) 等功能。 +[Logto Cloud](https://cloud.logto.io) 提供了一系列管理和运营服务,帮助你顺利且轻松地管理身份和资源。由 Logto 托管,包含 [多区域支持](/logto-cloud/tenant-settings#tenant-region)、租户管理、[计费与定价](/logto-cloud/billing-and-pricing)、[成员管理](/logto-cloud/tenant-member-management) 以及控制台基于角色的访问控制 (RBAC) 等功能。 如果你对云服务有任何疑问或需要额外支持,请联系我们。 @@ -25,9 +26,9 @@ import CustomDomains from '@site/src/assets/search.svg'; }, { type: 'link', - label: '开发租户数据保留政策', + label: '开发租户数据保留策略', href: '/logto-cloud/dev-tenant-data-retention', - description: '了解开发租户 90 天用户保留政策,以及如何高效使用 Logto 开发租户。', + description: '了解开发租户 90 天用户保留策略,以及如何高效使用 Logto 开发租户。', customProps: { icon: , }, @@ -54,10 +55,19 @@ import CustomDomains from '@site/src/assets/search.svg'; type: 'link', label: '计费与定价', href: '/logto-cloud/billing-and-pricing', - description: '轻松了解你的账单,自信地管理你的订阅。', + description: '轻松了解你的账单,并自信地管理你的订阅。', customProps: { icon: , }, }, + { + type: 'link', + label: '系统限制', + href: '/logto-cloud/system-limit', + description: '了解 Dev、Pro 和 Enterprise 租户的系统限制与速率保护。', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index c341dfca2ac..a87fe8a8071 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -11,9 +11,9 @@ sidebar_position: 4 你的自定义域名会用于以下几个功能: - [登录和注册页面](/end-user-flows/sign-up-and-sign-in) 的 URL -- [Passkey](/end-user-flows/mfa/webauthn) 绑定链接 URL(在用户已绑定 Passkey 后更改域名可能会阻止他们的认证 (Authentication)) -- [社交连接器](/connectors/social-connectors) 或 [企业 SSO 连接器](/connectors/enterprise-connectors) 的回调 URI -- 将 Logto 集成到你的应用时的 [SDK 端点](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) +- [Passkey](/end-user-flows/mfa/webauthn) 绑定链接的 URL(在用户已绑定 Passkey 后更改域名可能会导致他们无法进行认证 (Authentication))。 +- [社交连接器](/connectors/social-connectors) 或 [企业 SSO 连接器](/connectors/enterprise-connectors) 的回调 URI。 +- 将 Logto 集成到你的应用时的 [SDK 端点](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint)。 :::note 在服务上线后更改域名可能会带来麻烦,因为你的应用代码和集成可能仍然引用旧域名。为了确保平滑过渡,**请在生产租户创建时一开始就设置自定义域名**。 @@ -23,7 +23,7 @@ sidebar_position: 4 要在 Logto Console 中添加新的自定义域名,请按照以下步骤操作: -1. 进入 Console > 设置 > 域名。 +1. 前往 Console > 设置 > 域名。 2. 在“自定义域名”部分,输入你的域名并点击“添加域名”。 添加域名 @@ -32,9 +32,9 @@ sidebar_position: 4 自定义域名处理中 -4. 等待验证和 SSL 处理。 +4. 等待验证和 SSL 处理过程。 1. 我们会每 10 秒自动验证一次你的记录,直到自定义域名添加成功。只需确保输入的域名或 DNS 记录是准确的。 - 2. 验证通常只需几分钟,但根据 DNS 服务商不同,最长可能需要 24 小时。过程中你可以自由离开页面。 + 2. 验证通常只需几分钟,但根据 DNS 服务商不同,最长可能需要 24 小时。你可以在此过程中随意离开页面。 ## 故障排查 \{#troubleshooting} @@ -45,9 +45,9 @@ sidebar_position: 4 -如果你在设置自定义域名时遇到 SSL 证书问题,可能与你的 DNS 配置中的 CAA 记录有关。CAA 记录指定了哪些证书颁发机构(CA)被授权为你的域名颁发证书。如果你使用了 CAA 记录,需要为 Logto 授权 "letsencrypt.org" 和 "pki.goog" 这两个 CA。 +如果你在设置自定义域名时遇到 SSL 证书问题,可能与你 DNS 配置中的 CAA 记录有关。CAA 记录指定了哪些证书颁发机构(CA)被授权为你的域名颁发证书。如果你使用了 CAA 记录,需要为 Logto 授权 "letsencrypt.org" 和 "pki.goog" 这两个 CA。 -要排查和解决与 CAA 记录相关的 SSL 证书问题,请参考 [Cloudflare 的文档](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/)。 +如需排查和解决与 CAA 记录相关的 SSL 证书问题,请参考 [Cloudflare 的文档](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/)。
@@ -58,7 +58,7 @@ sidebar_position: 4 -如果你在添加自定义域名时遇到 “The hostname is associated with a held zone, please contact the owner to have the hold removed” 的错误提示,说明该域名已在 Cloudflare 区域中,并且被设置为 “Zone Hold” 状态。详见 [Cloudflare 文档](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/)。 +如果你在添加自定义域名时遇到 “The hostname is associated with a held zone, please contact the owner to have the hold removed” 的错误提示,说明该域名已在 Cloudflare 区域中,并被设置为 “Zone Hold” 状态。详见 [Cloudflare 文档](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/)。 要解决此问题,你需要解除 zone hold。请按照上述链接中的说明在 Cloudflare 中解除 zone hold。 @@ -67,7 +67,7 @@ sidebar_position: 4
-### Cloudflare 托管域名连接超时(错误码 522)\{#cloudflare-522-timeout} +### Cloudflare 托管域名出现连接超时(错误码 522)\{#cloudflare-522-timeout} @@ -75,9 +75,40 @@ sidebar_position: 4
+
+ + +### 设置自定义域名后出现 “Redirect URI does not match” 错误 \{#redirect-uri-mismatch} + + + +如果在添加自定义域名后出现 “redirect URI does not match” 错误,你需要将 SDK 配置更新为使用自定义域名作为端点。 + +**关于“主域名”:** + +Logto 没有单独的“主域名”设置。添加自定义域名后,你的自定义域名和默认的 `{tenant-id}.logto.app` 域名都会保持有效。你在 SDK 的 `endpoint` 参数中配置的域名决定了认证 (Authentication) 流程会使用哪个域名。 + +**解决方法:** + +将 SDK 初始化中的 `endpoint` 参数更新为你的自定义域名: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // 使用你的自定义域名 + appId: 'your-app-id', + // ... 其他选项 +}); +``` + +同时请确认在 Console → 应用程序 中注册的 redirect URI 与你正在使用的域名一致。 + +**注意:** Logto 会自动为你的自定义域名申请和管理 SSL 证书,无需你自行配置证书。 + +
+ ## 使用自定义域名 \{#use-custom-domain} -配置完成后,你的自定义域名和默认 Logto 域名都可以用于你的租户。但要激活自定义域名,还需要进行一些配置。 +配置完成后,你的自定义域名和默认 Logto 域名都可以用于你的租户。但要激活自定义域名,需要进行一些额外配置。 :::note @@ -85,9 +116,9 @@ sidebar_position: 4 ::: -### 为应用更新 SDK 端点 \{#updating-the-sdk-endpoint-for-applications} +### 为应用程序更新 SDK 端点 \{#updating-the-sdk-endpoint-for-applications} -修改 Logto SDK 的初始化代码,将端点的域名改为你的自定义域名。 +修改 Logto SDK 的初始化代码,将端点的域名更改为你的自定义域名。 ```typescript const client = new LogtoClient({ @@ -96,9 +127,9 @@ const client = new LogtoClient({ }); ``` -### 为其他应用修改认证 (Authentication) 端点 \{#modifying-auth-endpoints-for-other-applications} +### 为其他应用程序修改认证 (Authentication) 端点 \{#modifying-auth-endpoints-for-other-applications} -如果你的应用没有使用 Logto SDK,则需要更新它们的认证 (Authentication) 端点。 +如果你有未使用 Logto SDK 的应用程序,也需要更新它们的认证 (Authentication) 端点。 你可以在如下 well-known URL 找到认证 (Authentication) 端点: @@ -108,6 +139,6 @@ https://auth.example.com/oidc/.well-known/openid-configuration ### 更新社交连接器的回调 URI \{#updating-the-social-connectors-callback-uri} -如果你的用户正在使用自定义域名,社交连接器的回调 URI 会自动更新。但你还需要前往社交服务商的开发者控制台,手动更新回调 URI。 +如果你的用户正在使用自定义域名,社交连接器的回调 URI 会自动更新为新域名。你需要前往社交服务商的开发者控制台,手动更新回调 URI。 -当用户使用自定义域名时,社交连接器的回调 URI 会使用新域名。因此,你需要前往社交服务商的开发者控制台手动更新回调 URI。 +当用户使用自定义域名时,社交连接器的回调 URI 会使用新域名。因此,你需要前往社交服务商的开发者控制台,手动更新回调 URI。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..9235d05dfd7 --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# 系统限制 + +在 Logto,我们为所有套餐设置了宽松的限制,并提供灵活的按需付费选项,因此用户只需为实际使用的部分付费。 + +你可能会注意到,定价页面上的某些项目被标记为 _无限制_ 或 _持续按需付费无上限_。这意味着通常可以无限制使用,但 Logto 保留随时间调整这些实际限制的权利,以维护所有用户的公平使用。换句话说,实体限制是保护平台整体健康的严格上限。它们不是定价的一部分,但可能会因不同套餐组而有所不同。 + +如果你的使用场景合理但达到了系统限制,欢迎随时联系我们并分享你的反馈。这有助于我们更好地了解实际使用模式,并调整系统限制,以更好地支持我们的忠实客户。 + +## 租户级速率限制保护 \{#tenant-level-rate-limit-protection} + +### Dev 租户 \{#dev-tenants} + +对于 Dev 租户,用户可以免费享受 Logto 的功能和服务。为防止滥用并设定明确预期,我们定义了某些系统限制。这些限制帮助我们可持续地管理平台,同时仍为测试和开发提供免费访问。 + +如果你希望提升配额,可以联系我们寻求帮助。我们也推荐你从 **Dev** 升级到 **Pro**,这样可以立即移除上限并获得完整访问权限。 + +| **功能** | **实体限制** | +| ----------------------------- | ------------ | +| **包含令牌** | 每月 50,000 | +| **应用程序** | | +| 应用程序总数 | 100 | +| 机器对机器应用 | 100 | +| 第三方应用 | 100 | +| **API 资源** | | +| 资源数量 | 100 | +| **用户认证 (Authentication)** | | +| 社交连接器 | 100 | +| 企业单点登录 (SSO) | 100 | +| **用户管理** | | +| 用户角色 | 100 | +| 机器对机器角色 | 100 | +| 每个角色的权限 | 100 | +| **组织 (Organizations)** | | +| 组织数量 | 5,000 | +| 每个组织的用户 | 100,000 | +| 组织用户角色 | 1,000 | +| 组织机器对机器角色 | 100 | +| 组织权限 | 1,000 | +| **开发者与平台** | | +| Webhooks | 10 | +| 审计日志保留 | 14 天 | +| 租户成员 | 20 | + +### Pro 租户 \{#pro-tenant} + +对于 Pro 租户,实体限制定义了附加组件和其他“无限制”实体(如应用程序)的上限。Pro 套餐的系统限制详情如下。 + +| **功能** | **实体限制** | +| ----------------------------- | --------------- | +| **包含令牌** | 每月 10,000,000 | +| **应用程序** | | +| 应用程序总数 | 100 | +| 机器对机器应用 | 100 | +| OIDC/OAuth 第三方应用 | 100 | +| SAML 应用 | 100 | +| **API 资源** | | +| 资源数量 | 1,000 | +| 每个资源的权限 | 1,000 | +| **用户认证 (Authentication)** | | +| 社交连接器 | 100 | +| 企业单点登录 (SSO) | 100 | +| **用户管理** | | +| 用户角色 | 1,000 | +| 机器对机器角色 | 100 | +| **组织 (Organizations)** | | +| 组织数量 | 100,000 | +| 每个组织的用户 | 100,000 | +| 组织用户角色 | 1,000 | +| 组织机器对机器角色 | 100 | +| 组织权限 | 1,000 | +| **开发者与平台** | | +| Webhooks | 10 | +| 审计日志保留 | 14 天 | +| 自定义域名 | 10 | +| 租户成员 | 100 | + +### 企业版 \{#enterprise} + +对于企业版套餐,限制和功能均可完全自定义,并通过合同进行管理。请[联系我们](https://logto.io/contact)获取更多详情。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index 666d35011b6..5cb06fe6fc8 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -12,7 +12,7 @@ sidebar_position: 1 点击“创建租户”,然后: -- 为租户命名 +- 填写租户名称 - 选择一个 [租户数据区域](#tenant-region) - 选择 [租户类型](#tenant-types-dev-vs-prod)(环境) @@ -34,7 +34,7 @@ sidebar_position: 1 - 澳大利亚(澳大利亚东部) - 日本(日本东部) -通常,你应选择距离你的客户最近的区域,以最小化延迟并提升性能。 +通常,你应选择离你的客户最近的区域,以减少延迟并提升性能。 Logto 利用全球边缘网络,为你的应用提供最佳性能和可用性。请求路由经过优化,确保你的用户始终连接到表现最优的节点。 @@ -47,72 +47,46 @@ Logto 利用全球边缘网络,为你的应用提供最佳性能和可用性 ## 租户类型:开发 (Dev) 与生产 (Prod) \{#tenant-types-dev-vs-prod} -Logto Cloud 中有两种租户类型:开发 (Development, Dev) 和生产 (Production, Prod)。通过区分租户类型,你可以更高效地在不同环境下管理项目,同时充分享受 Logto 的全部价值。 +Logto Cloud 中有两种租户类型:开发 (Development, Dev) 和生产 (Production, Prod)。通过区分租户类型,你可以更高效地管理不同环境下的项目,同时充分享受 Logto 的全部价值。 你可以在创建时选择租户类型。当你准备上线生产环境时,有两种选择: - **创建新的生产租户** - 新建一个全新的生产租户并从头配置。如果你希望开发环境和生产环境完全隔离,推荐此方式。 + 新建一个全新的生产租户并从头配置。如果你希望开发和生产环境完全隔离,推荐此方式。 - **将当前 Dev 租户转换为生产租户** 如果你不想重新配置或迁移用户,可以将现有开发租户升级为付费生产租户。 - - **升级为 Pro 计划**:前往 控制台 > 租户设置 > 设置,点击“转换”即可自助升级。你在开发租户中使用的所有付费功能会自动计入 Stripe 结算。 - - **升级为企业计划**:请[联系我们](https://logto.io/contact),我们会协助你完成升级。 + - **升级为 Pro 方案**:前往 控制台 > 租户设置 > 设置,点击“转换”即可自助升级。你在 Dev 租户中使用的所有付费功能会自动计入 Stripe 结算。 + - **升级为企业方案**:请[联系我们](https://logto.io/contact),我们会协助你完成升级。 :::note 转换后,租户无法恢复为 Dev 环境;请确认准备就绪后再操作。 ::: -### 开发环境 \{#development} +### 开发 (Development) \{#development} -开发租户(dev tenant)主要用于测试目的,不应在生产环境中使用。这些租户可以免费访问付费计划中的高级功能,无需订阅。 +开发租户(Dev 租户)主要用于测试目的,不应在生产环境中使用。这些租户可以免费访问付费方案中的高级功能,无需订阅。 但开发租户有以下限制: - Dev 租户会自动删除 90 天以上的用户。详见 [Dev 租户数据保留政策](./dev-tenant-data-retention)。 -- 登录体验中会显示横幅,提示租户处于开发模式。 -- 开发租户的部分功能可能有配额限制,具体限制会在功能详情页说明。 -- Logto 可能会调整开发租户的配额限制,并会尽量提前通知你。 - -| 功能 | 实体上限 | -| ----------------------------- | --------- | -| **包含令牌** | 每月 5 万 | -| **应用程序** | -| 应用总数 | 100 | -| 机器对机器应用 | 100 | -| 第三方应用 | 100 | -| **API 资源** | | -| 资源数量 | 100 | -| **用户认证 (Authentication)** | | -| 社交连接器 | 100 | -| 企业单点登录 (SSO) | 100 | -| **用户管理** | | -| 用户角色 | 100 | -| 机器对机器角色 | 100 | -| 每个角色的权限 | 100 | -| **组织 (Organizations)** | | -| 组织数量 | 5,000 | -| 每个组织的用户数 | 5,000 | -| 组织角色 | 100 | -| 组织权限 | 100 | -| **开发者与平台** | | -| Webhook | 10 | -| 审计日志保留 | 14 天 | -| 租户成员 | 20 | - -### 生产环境 \{#production} - -生产租户是终端用户访问正式应用的环境,你可能需要[付费订阅](https://logto.io/pricing)。你可以订阅免费计划或 Pro 计划来创建生产租户。如果你订阅免费计划,最多只能创建 10 个租户。 +- 登录体验过程中会显示横幅,提示租户处于开发模式。 +- 开发租户的部分功能可能有配额限制。具体限制会在功能详情页说明。完整的 Dev 方案限制请参见 [系统限制](./system-limit) 页面。 +- Logto 可能会调整开发租户的配额限制,我们会尽量提前通知你。 + +### 生产 (Production) \{#production} + +生产租户是终端用户访问正式应用的环境,你可能需要[付费订阅](https://logto.io/pricing)。你可以订阅免费方案或 Pro 方案来创建生产租户。如果你选择免费方案,最多只能创建 10 个租户。 ## 启用 MFA \{#enable-mfa} 通过要求 Logto Pro/Enterprise 租户的所有成员启用多因素认证 (MFA),提升你的工作区安全性。 -由于暂未开放自助服务,请[联系我们](https://logto.io/contact)以启用此功能。 +由于暂不支持自助开启,请[联系我们](https://logto.io/contact)以启用此功能。 ## 启用企业单点登录 (SSO) \{#enable-enterprise-sso} -Logto Cloud 支持企业计划租户集成企业单点登录 (SSO),包括 Google Workspace、Okta、Azure AD 等提供商。 +Logto Cloud 支持企业方案租户集成企业单点登录 (SSO),包括 Google Workspace、Okta、Azure AD 等提供商。 如需开始,请[联系我们](https://logto.io/contact)。我们会协助你快速完成配置。 @@ -120,13 +94,13 @@ Logto Cloud 支持企业计划租户集成企业单点登录 (SSO),包括 Goog 管理员可以[邀请其他成员](/logto-cloud/tenant-member-management)加入该租户。 -如果至少还有一位其他 **管理员**(角色),或你是 **协作者**(角色),你可以选择离开租户。离开后,租户中的所有资源仍会保留,但你将无法再访问它们。 +如果还有至少一位其他 **管理员**(角色),或你是 **协作者**(角色),你可以选择离开租户。离开后,租户中的所有资源仍会保留,但你将无法再访问它们。 如果你是最后一位管理员,必须先将其他协作者设为管理员后才能离开。 ## 删除租户 \{#delete-tenant} -[管理员](/logto-cloud/tenant-member-management#invite-collaborators)可以删除 Logto 租户。删除租户会永久移除所有相关的用户数据和配置。此操作**无法撤销**。Logto 会要求你输入租户名称以确认,防止误删。 +[管理员](/logto-cloud/tenant-member-management#invite-collaborators)可以删除 Logto 租户。删除租户会永久移除所有相关用户数据和配置。此操作无法撤销。Logto 会要求你输入租户名称以确认并防止误删。 如需帮助,请通过邮件[联系我们](https://logto.io/contact)。 @@ -139,9 +113,9 @@ Logto Cloud 支持企业计划租户集成企业单点登录 (SSO),包括 Goog -你目前可以自行将 **开发 (Development)** 租户转换为付费计划的 **生产 (Production)** 租户。[了解详情](#tenant-types-dev-vs-prod) +你目前可以自行将 **开发 (Development)** 租户转换为付费方案的 **生产 (Production)** 租户。[了解更多](#tenant-types-dev-vs-prod) -但 Logto Cloud 与 OSS 版本之间的自助迁移(包括所有配置和用户数据)暂不支持。如需此服务,请[联系 Logto 团队](https://logto.io/contact)讨论你的方案。 +但 Logto Cloud 与 OSS 版本之间(包括所有配置和用户数据)的自助迁移暂不支持。如需此服务,请[联系 Logto 团队](https://logto.io/contact)讨论你的方案。 如果你计划停止在某项目中使用 Logto Cloud,Logto 可以协助你导出所有用户数据。请[联系我们](https://logto.io/contact)。 @@ -149,4 +123,6 @@ Logto Cloud 支持企业计划租户集成企业单点登录 (SSO),包括 Goog ## 相关资源 \{#related-resources} -在本地区域和专用计算资源中保护你的身份 + + 在本地区域和专用计算资源中保护你的身份信息 + diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index 756439bc597..236bc740b9c 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -1,5 +1,5 @@ --- -description: Logto 开源服务 (OSS) 初始化快速入门指南。 +description: Logto 开源服务 (OSS) 初始化的快速入门指南。 sidebar_position: 1 --- @@ -17,28 +17,28 @@ import Tabs from '@theme/Tabs'; ## GitPod \{#gitpod} -要启动 Logto 的在线 GitPod 工作区,点击这里。稍等片刻,你会看到如下信息: +要在线启动 Logto 的 GitPod 工作区,点击这里。稍等片刻,你会看到类似如下的信息:

Gitpod is running

-Logto 默认使用端口 `3001` 作为其核心服务,端口 `3002` 用于交互式管理控制台。 +Logto 默认使用端口 `3001` 作为核心服务端口,端口 `3002` 作为交互式管理控制台端口。 -要继续你的 Logto 之旅,按下 Ctrl(或 Cmd)并点击以 `https://3002-...` 开头的链接。享受吧! +要继续你的 Logto 之旅,按下 Ctrl(或 Cmd)并点击以 `https://3002-...` 开头的链接。祝你玩得开心! ## 本地 \{#local} -托管 Logto 的最低推荐硬件要求是: +托管 Logto 的最低推荐硬件要求为: -- **vCPU**: 2 -- **内存**: 8 GiB -- **磁盘**: 256 GiB +- **vCPU**:2 +- **内存**:8 GiB +- **磁盘**:256 GiB @@ -47,14 +47,15 @@ Logto 默认使用端口 `3001` 作为其核心服务,端口 `3002` 用于交 Docker Compose CLI 通常随 [Docker Desktop](https://www.docker.com/products/docker-desktop) 一起提供。 :::caution -不要在生产环境中使用我们的 docker compose 命令!由于我们目前在 `docker-compose.yml` 中将内置的 Postgres 数据库与 Logto 应用程序捆绑在一起,每次重新执行命令时都会创建一个新的数据库实例,之前持久化的任何数据都会丢失。 +不要在生产环境中使用我们的 docker compose 命令!由于我们目前在 `docker-compose.yml` 中将内置的 Postgres 数据库与 Logto 应用程序捆绑在一起, +每次你重新执行该命令时都会创建一个新的数据库实例,之前持久化的数据将会丢失。 ::: ```bash curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | docker compose -p logto -f - up ``` -成功组合后,你会看到如下信息: +组合成功后,你会看到类似如下的信息: @@ -62,7 +63,7 @@ curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.

步骤 1

-准备一个 [PostgreSQL](https://www.postgresql.org/)@^14.0 实例,并使用 [Logto CLI](/logto-oss/using-cli) 为 Logto 种子数据库: +准备一个 [PostgreSQL](https://www.postgresql.org/)@^14.0 实例,并使用 [Logto CLI](/logto-oss/using-cli) 为 Logto 初始化数据库: @@ -96,12 +97,12 @@ docker pull svhd/logto:latest

步骤 3

-将容器端口映射到 Logto 核心和管理应用程序,例如,`3001:3001` 和 `3002:3002`;并将以下环境变量设置到容器中: +将容器端口映射到 Logto 核心和管理应用,例如 `3001:3001` 和 `3002:3002`;并为容器设置以下环境变量: ```yml -TRUST_PROXY_HEADER: 1 # 如果在 Logto 前面有 HTTPS 代理(例如 Nginx),请设置为 1 -ENDPOINT: https:// # (可选)如果使用自定义域,请替换为你的 Logto 端点 URL -ADMIN_ENDPOINT: https:// # (可选)如果使用自定义域,请替换为你的 Logto 管理 URL +TRUST_PROXY_HEADER: 1 # 如果你在 Logto 前面有 HTTPS 代理(如 Nginx),请设置为 1 +ENDPOINT: https:// # (可选)如果你使用自定义域名,请替换为你的 Logto 端点 URL +ADMIN_ENDPOINT: https:// # (可选)如果你使用自定义域名,请替换为你的 Logto 管理端点 URL DB_URL: postgres://username:password@your_postgres_url:port/db_name # 替换为你的 Postgres DSN ``` @@ -121,25 +122,25 @@ docker run \ :::tip -- 如果你使用 Docker Hub,请使用 `svhd/logto:latest` 而不是 `ghcr.io/logto-io/logto:latest`。 -- 在 `DB_URL` 中使用 `host.docker.internal` 或 `172.17.0.1` 来引用主机 IP。 +- 如果你使用 Docker Hub,请将 `ghcr.io/logto-io/logto:latest` 替换为 `svhd/logto:latest`。 +- 在 `DB_URL` 中使用 `host.docker.internal` 或 `172.17.0.1` 指向主机 IP。 ::: -最后,你会看到如下信息: +最后,你会看到类似如下的信息: -**先决条件** +**前置条件** - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -更高版本通常可以工作,但不保证。 +更高版本通常也可用,但不保证兼容。 -我们建议使用一个新的空数据库专用于 Logto,尽管这不是硬性要求。 +我们建议为 Logto 使用一个新的空数据库,虽然这不是硬性要求。 **下载并启动** @@ -149,20 +150,20 @@ docker run \ npm init @logto@latest ``` -一旦你完成初始化过程并启动 Logto,你会看到如下信息: +完成初始化流程并启动 Logto 后,你会看到类似如下的信息:
```text -核心应用程序正在运行于 http://localhost:3001 -核心应用程序正在运行于 https://your-domain-url -管理应用程序正在运行于 http://localhost:3002 -管理应用程序正在运行于 https://your-admin-domain-url +Core app is running at http://localhost:3001 +Core app is running at https://your-domain-url +Admin app is running at http://localhost:3002 +Admin app is running at https://your-admin-domain-url ``` -前往 `http://localhost:3002/` 继续你的 Logto 之旅。享受吧! +前往 `http://localhost:3002/` 继续你的 Logto 之旅。祝你玩得开心!
@@ -172,13 +173,13 @@ npm init @logto@latest -如果你想为 Logto zip 文件指定一个 URL,请使用 `--download-url` 选项。例如: +如果你想为 Logto zip 文件指定下载 URL,可以使用 `--download-url` 选项。例如: ``` npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -注意需要额外的 `--` 以便 NPM 传递参数。 +注意需要额外的 `--`,以便 NPM 传递参数。
@@ -190,15 +191,15 @@ npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/relea -Logto 使用环境变量进行配置,并支持 `.env` 文件。有关详细用法和完整变量列表,请参阅 [配置](/concepts/core-service/configuration)。 +Logto 使用环境变量进行配置,并支持 `.env` 文件。详细用法和完整变量列表请参见 [配置](/concepts/core-service/configuration)。 -_查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 Logto 的编程访问。_ +_如果你需要更高级的控制或以编程方式访问 Logto,请查看 [核心服务](/concepts/core-service)。_ -## 托管服务提供商 \{#hosting-providers} +## 托管服务商 \{#hosting-providers} -这些可靠的托管服务提供商提供 Logto 的一键安装模板。通过易于部署的服务,你可以在几秒钟内使用 Logto 设置并启动你的 CIAM 系统。 +这些可靠的托管服务商为 Logto 提供了一键安装模板。通过便捷的可部署服务,你可以在几秒钟内使用 Logto 搭建并启动你的 CIAM 系统。 , }, @@ -215,7 +216,7 @@ _查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 type: 'link', label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', - description: '一个可自托管的 Heroku/Netlify 替代方案,便于应用程序和数据库管理。', + description: '一个可自托管的 Heroku/Netlify 替代方案,便于应用和数据库管理。', customProps: { icon: , }, @@ -224,7 +225,7 @@ _查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 type: 'link', label: 'Dokploy', href: 'https://docs.dokploy.com/docs/core', - description: '用于在你自己的基础设施上部署应用程序的轻量级工具。', + description: '轻量级工具,可在你自己的基础设施上部署应用。', customProps: { icon: , }, @@ -233,7 +234,7 @@ _查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 type: 'link', label: 'Easypanel', href: 'https://easypanel.io/docs/templates/logto', - description: '一个用于管理带有 Docker 的云服务器的现代控制面板。', + description: '一个现代化的控制面板,用于管理带有 Docker 的云服务器。', customProps: { icon: , }, @@ -242,7 +243,7 @@ _查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 type: 'link', label: 'Elestio', href: 'https://elest.io/open-source/logto', - description: '完全托管的 DevOps 平台,用于部署你的代码和开源软件。', + description: '全托管 DevOps 平台,部署你的代码和开源软件。', customProps: { icon: , }, @@ -251,7 +252,7 @@ _查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 type: 'link', label: 'Railway', href: 'https://railway.com/template/07_f_Z', - description: '简化应用程序部署和基础设施管理。', + description: '简化应用部署和基础设施管理。', customProps: { icon: , }, @@ -260,7 +261,7 @@ _查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 type: 'link', label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', - description: '简化应用程序部署、扩展和监控,为开发者提供便利。', + description: '为开发者简化应用部署、扩容和监控。', customProps: { icon: , }, @@ -268,12 +269,16 @@ _查看 [核心服务](/concepts/core-service) 以获取更高级的控制或对 ]} /> -请注意,我们不为第三方服务提供商提供客户支持。要访问我们的支持渠道,请在 [Logto Cloud](https://cloud.logto.io) 上部署。谢谢! +请注意,我们不为第三方服务商提供客户支持。如需访问我们的支持渠道,请在 [Logto Cloud](https://cloud.logto.io) 上部署。谢谢! ## 创建账户 \{#create-an-account} -一旦你成功在服务器上托管了 Logto,请在欢迎页面上点击“创建账户”。请记住,Logto 的开源版本仅允许在初次启动时创建一个账户,并且不支持多个账户。账户创建过程仅限于用户名和密码组合。 +当你成功在服务器上托管 Logto 后,在欢迎页面点击“创建账户”。请注意,Logto 开源版仅允许在首次启动时创建一个账户,不支持多账户。账户创建过程仅限于用户名和密码组合。 + +:::tip +Logto OSS(自托管)不支持配置多个管理员。如需团队协作或需要多个管理员用户的项目,建议使用 [Logto Cloud](https://cloud.logto.io),它提供完整的团队管理功能。 +::: ## 相关资源 \{#related-resources} -处理本地 HTTPS 开发 +本地 HTTPS 开发处理方法 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index 943f05aec70..51adf1b7391 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot 是一个用于 Java 的 Web 框架,使开发人员能够使用 Java 编程语言构建安全、快速和可扩展的服务器应用程序。 + description: Spring Boot 是一个 Java 的 Web 框架,使开发者能够使用 Java 编程语言构建安全、快速且可扩展的服务器应用程序。 logoFilename: 'spring-boot.svg' --- @@ -20,22 +20,22 @@ import ScopesAndClaims from './_scopes-and-claims.mdx'; :::tip -- 你可以在我们的 [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub 仓库中找到本指南的示例代码。 -- 将 Logto 集成到你的 Java Spring Boot 应用中不需要官方 SDK。我们将使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 库来处理 Logto 的 OIDC 认证 (Authentication) 流程。 +- 你可以在我们的 [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) github 仓库中找到本指南的示例代码。 +- 将 Logto 集成到你的 Java Spring Boot 应用中无需官方 SDK。我们将使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 库来处理与 Logto 的 OIDC 认证 (Authentication) 流程。 ::: -## 前提条件 \{#prerequisites} +## 前置条件 \{#prerequisites} -- 一个 [Logto Cloud](https://cloud.logto.io) 账户或一个 [自托管 Logto](/introduction/set-up-logto-oss)。 -- 我们的示例代码是使用 Spring Boot 的 [securing web starter](https://spring.io/guides/gs/securing-web) 创建的。如果你还没有应用程序,请按照说明启动一个新的 Web 应用程序。 -- 在本指南中,我们将使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 库来处理 Logto 的 OIDC 认证 (Authentication) 流程。请确保阅读官方文档以了解相关概念。 +- 一个 [Logto Cloud](https://cloud.logto.io) 账号或 [自托管 Logto](/introduction/set-up-logto-oss)。 +- 我们的示例代码是使用 Spring Boot 的 [securing web starter](https://spring.io/guides/gs/securing-web) 创建的。如果你还没有 Web 应用,请按照指引初始化一个新项目。 +- 在本指南中,我们将使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 库来处理与 Logto 的 OIDC 认证 (Authentication) 流程。请务必阅读官方文档以了解相关概念。 ## 配置你的 Java Spring Boot 应用 \{#configure-your-java-spring-boot-application} -### 添加依赖项 \{#adding-dependencies} +### 添加依赖 \{#adding-dependencies} -对于 [gradle](https://spring.io/guides/gs/gradle) 用户,将以下依赖项添加到你的 `build.gradle` 文件中: +对于 [gradle](https://spring.io/guides/gs/gradle) 用户,在你的 `build.gradle` 文件中添加以下依赖: ```groovy title="build.gradle" dependencies { @@ -46,7 +46,7 @@ dependencies { } ``` -对于 [maven](https://spring.io/guides/gs/maven) 用户,将以下依赖项添加到你的 `pom.xml` 文件中: +对于 [maven](https://spring.io/guides/gs/maven) 用户,在你的 `pom.xml` 文件中添加以下依赖: ```xml title="pom.xml" @@ -69,7 +69,7 @@ dependencies { ### OAuth2 客户端配置 \{#oauth2-client-configuration} -在 Logto 控制台中注册一个新的 `Java Spring Boot` 应用程序,并获取你的 Web 应用程序的客户端凭证和 IdP 配置。 +在 Logto 控制台注册一个新的 `Java Spring Boot` 应用,并获取你的 Web 应用所需的客户端凭证和 IdP 配置。 将以下配置添加到你的 `application.properties` 文件中: @@ -91,15 +91,15 @@ spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc -为了在用户登录后将其重定向回你的应用程序,你需要在上一步中使用 `client.registration.logto.redirect-uri` 属性设置重定向 URI。 +为了在用户登录后将其重定向回你的应用,你需要在上一步中通过 `client.registration.logto.redirect-uri` 属性设置重定向 URI。 - + ### 实现 WebSecurityConfig \{#implement-the-websecurityconfig} -#### 在你的项目中创建一个新的 `WebSecurityConfig` 类 \{#create-a-new-class-websecurityconfig-in-your-project} +#### 在你的项目中新建 `WebSecurityConfig` 类 \{#create-a-new-class-websecurityconfig-in-your-project} -`WebSecurityConfig` 类将用于配置应用程序的安全设置。它是处理认证 (Authentication) 和授权 (Authorization) 流程的关键类。请查看 [Spring Security 文档](https://spring.io/guides/topicals/spring-security-architecture) 以获取更多详细信息。 +`WebSecurityConfig` 类用于配置你的应用安全设置。它是处理认证 (Authentication) 和授权 (Authorization) 流程的关键类。更多细节请查阅 [Spring Security 文档](https://spring.io/guides/topicals/spring-security-architecture)。 ```java title="WebSecurityConfig.java" package com.example.securingweb; @@ -117,7 +117,7 @@ public class WebSecurityConfig { #### 创建一个 `idTokenDecoderFactory` bean \{#create-a-idtokendecoderfactory-bean} -这是必需的,因为 Logto 使用 `ES384` 作为默认算法,我们需要覆盖默认的 `OidcIdTokenDecoderFactory` 以使用相同的算法。 +由于 Logto 默认使用 `ES384` 算法,我们需要重写默认的 `OidcIdTokenDecoderFactory` 以使用相同算法。 ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -138,7 +138,7 @@ public class WebSecurityConfig { } ``` -#### 创建一个 LoginSuccessHandler 类来处理登录成功事件 \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} +#### 创建 LoginSuccessHandler 类以处理登录成功事件 \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} 我们将在登录成功后将用户重定向到 `/user` 页面。 @@ -163,9 +163,9 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { } ``` -#### 创建一个 LogoutSuccessHandler 类来处理注销成功事件 \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} +#### 创建 LogoutSuccessHandler 类以处理登出成功事件 \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} -清除会话并将用户重定向到主页。 +清除会话并将用户重定向到首页。 ```java title="CustomLogoutHandler.java" package com.example.securingweb; @@ -195,11 +195,11 @@ public class CustomLogoutHandler implements LogoutSuccessHandler { } ``` -#### 使用 `securityFilterChain` 更新 `WebSecurityConfig` 类 \{#update-the-websecurityconfig-class-with-a-securityfilterchain} +#### 在 `WebSecurityConfig` 类中添加 `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} [securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) 是负责处理传入请求和响应的过滤器链。 -我们将配置 `securityFilterChain` 以允许访问主页,并要求对所有其他请求进行认证 (Authentication)。使用 `CustomSuccessHandler` 和 `CustomLogoutHandler` 来处理登录和注销事件。 +我们将配置 `securityFilterChain`,允许访问首页,其他请求都需要认证 (Authentication)。使用 `CustomSuccessHandler` 和 `CustomLogoutHandler` 处理登录和登出事件。 ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -214,8 +214,8 @@ public class WebSecurityConfig { http .authorizeRequests(authorizeRequests -> authorizeRequests - .antMatchers("/", "/home").permitAll() // 允许访问主页 - .anyRequest().authenticated() // 所有其他请求需要认证 (Authentication) + .antMatchers("/", "/home").permitAll() // 允许访问首页 + .anyRequest().authenticated() // 其他请求需要认证 (Authentication) ) .oauth2Login(oauth2Login -> oauth2Login @@ -230,9 +230,9 @@ public class WebSecurityConfig { } ``` -### 创建主页 \{#create-a-home-page} +### 创建首页 \{#create-a-home-page} -(如果你的项目中已经有主页,可以跳过此步骤) +(如果你的项目已有首页可跳过此步骤) ```java title="HomeController.java" package com.example.securingweb; @@ -251,11 +251,11 @@ public class HomeController { } ``` -此控制器将在用户认证 (Authentication) 后将其重定向到用户页面,否则将显示主页。在主页上添加一个登录链接。 +该控制器会在用户已认证 (Authentication) 时重定向到用户页面,否则显示首页。请在首页添加登录链接。 ```html title="resources/templates/home.html" -

欢迎!

+

Welcome!

使用 Logto 登录

@@ -263,7 +263,7 @@ public class HomeController { ### 创建用户页面 \{#create-a-user-page} -创建一个新的控制器来处理用户页面: +新建控制器处理用户页面: ```java title="UserController.java" package com.example.securingweb; @@ -299,54 +299,54 @@ public class UserController { } ``` -一旦用户被认证 (Authentication),我们将从认证 (Authentication) 的主体对象中检索 `OAuth2User` 数据。请参考 [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) 和 [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) 以获取更多详细信息。 +用户认证 (Authentication) 后,我们将从认证 (Authentication) 的 principal 对象中获取 `OAuth2User` 数据。更多细节请参考 [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) 和 [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html)。 -读取用户数据并将其传递给 `user.html` 模板。 +读取用户数据并传递给 `user.html` 模板。 ```html title="resources/templates/user.html"

用户详情

-

姓名:
-
邮箱:
-
id:
+
name:
+
email:
+
id:

- +
``` -#### 请求额外的声明 (Claims) \{#request-additional-claims} +#### 请求额外声明 (Claims) \{#request-additional-claims} -要检索额外的用户信息,你可以在 `application.properties` 文件中添加额外的权限 (Scopes)。例如,要请求 `email`、`phone` 和 `urn:logto:scope:organizations` 权限 (Scope),请在 `application.properties` 文件中添加以下行: +如需获取更多用户信息,你可以在 `application.properties` 文件中添加额外的权限 (Scopes)。例如,若要请求 `email`、`phone` 和 `urn:logto:scope:organizations` 权限 (Scope),请在 `application.properties` 文件中添加如下内容: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -然后你可以在 `OAuth2User` 对象中访问额外的声明 (Claims)。 +然后你可以在 `OAuth2User` 对象中访问这些额外的声明 (Claims)。 -### 运行并测试应用程序 \{#run-and-test-the-application} +### 运行并测试应用 \{#run-and-test-the-application} -运行应用程序并导航到 `http://localhost:8080`。 +运行应用并访问 `http://localhost:8080`。 -- 你将看到带有登录链接的主页。 -- 点击链接以使用 Logto 登录。 -- 认证 (Authentication) 成功后,你将被重定向到包含用户详细信息的用户页面。 -- 点击注销按钮以退出登录。你将被重定向回主页。 +- 你会看到带有登录链接的首页。 +- 点击链接使用 Logto 登录。 +- 认证 (Authentication) 成功后,你会被重定向到用户页面并显示你的用户信息。 +- 点击登出按钮退出登录,你会被重定向回首页。 -## 权限 (Scopes) 和声明 (Claims) \{#scopes-and-claims} +## 权限 (Scopes) 与声明 (Claims) \{#scopes-and-claims} -## 进一步阅读 \{#further-readings} +## 延伸阅读 \{#further-readings} diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index eb1008e0a87..cfc21ef7823 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -12,32 +12,32 @@ import Availability from '@components/Availability'; ## 常见用例 \{#common-use-cases} -此功能对于现代应用程序(如 AI 代理、SaaS 平台、效率工具和需要代表用户与第三方服务交互的客户应用)至关重要。以下是一些实际示例: +此功能对于现代应用程序至关重要,例如 AI 代理、SaaS 平台、效率工具和需要代表用户与第三方服务交互的客户应用。以下是一些实际示例: -**📅 日历管理应用**:用户使用 Google 登录后,你的效率应用可以自动同步他们的日历事件、创建新会议并发送邀请,无需再次请求用户认证 (Authentication)。 +**📅 日历管理应用**:用户使用 Google 登录后,你的效率应用可以自动同步他们的日历事件、创建新会议并发送邀请,而无需再次请求认证 (Authentication)。 **🤖 AI 助手**:AI 代理可以访问用户的 GitHub 仓库以分析代码、创建拉取请求或管理问题。所有操作仅需用户在登录或账户绑定时一次性授权。 -**📊 分析仪表盘**:SaaS 平台可以从用户已连接的社交媒体账户(Facebook、LinkedIn)拉取数据,生成洞察和报告,无需频繁登录打断用户工作流。 +**📊 分析仪表盘**:SaaS 平台可以从用户关联的社交媒体账户(Facebook、LinkedIn)拉取数据,生成洞察和报告,无需频繁登录打断用户工作流。 ## 启用第三方令牌存储 \{#enable-third-party-token-storage} ### 社交连接器 \{#social-connectors} -该功能适用于支持令牌存储的 [社交连接器](/connectors/social-connectors)。第三方令牌可在 [社交登录](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[社交账户绑定](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) 以及 [为第三方 API 访问续期令牌时](/secret-vault/federated-token-set#reauthentication-and-token-renewal) 存储。目前支持的连接器包括:[GitHub](/integrations/github)、[Google](/integrations/google)、[Facebook](/integrations/facebook)、[标准 OAuth 2.0](/integrations/oauth2) 和 [标准 OIDC](/integrations/oidc)。更多连接器的支持将逐步推出。 +此功能适用于支持令牌存储的[社交连接器](/connectors/social-connectors)。第三方令牌可在[社交登录](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[社交账户绑定](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection)以及[为第三方 API 访问续期令牌时](/secret-vault/federated-token-set#reauthentication-and-token-renewal)进行存储。目前支持的连接器包括:[GitHub](/integrations/github)、[Google](/integrations/google)、[Facebook](/integrations/facebook)、[标准 OAuth 2.0](/integrations/oauth2) 和 [标准 OIDC](/integrations/oidc)。更多连接器的支持将逐步推出。 1. 进入 控制台 > 连接器 > 社交连接器。 -2. 选择你想为其启用第三方令牌存储的社交连接器。 -3. 按照设置教程配置连接器,包括添加访问特定第三方 API 所需的权限 (Scope)。 +2. 选择你想要启用第三方令牌存储的社交连接器。 +3. 按照设置教程配置连接器,包括添加访问特定第三方 API 所需的权限 (Scopes)。 4. 在“设置”页面,启用 **为持久 API 访问存储令牌** 选项。 ### 企业单点登录 (SSO) 连接器 \{#enterprise-sso-connectors} -所有 OIDC [企业连接器](/connectors/enterprise-connectors) 均支持令牌存储。访问令牌 (Access token) 和刷新令牌 (Refresh token) 可在 [企业单点登录 (SSO)](/end-user-flows/enterprise-sso) 过程中存储。目前支持的连接器包括:[Google Workspace](/integrations/google-workspace)、[Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc)、[Okta](/integrations/okta) 和 [OIDC (Enterprise)](/integrations/oidc-sso)。 +所有 OIDC [企业连接器](/connectors/enterprise-connectors)均支持令牌存储。访问令牌 (Access token) 和刷新令牌 (Refresh token) 可在[企业单点登录 (SSO)](/end-user-flows/enterprise-sso)过程中存储。目前支持的连接器包括:[Google Workspace](/integrations/google-workspace)、[Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc)、[Okta](/integrations/okta) 和 [OIDC (Enterprise)](/integrations/oidc-sso)。 1. 进入 控制台 > 企业单点登录 (SSO)。 -2. 选择你想为其启用第三方令牌存储的企业单点登录 (SSO) 连接器。 -3. 按照设置教程配置连接器,包括添加访问特定第三方 API 所需的权限 (Scope)。 +2. 选择你想要启用第三方令牌存储的企业单点登录 (SSO) 连接器。 +3. 按照设置教程配置连接器,包括添加访问特定第三方 API 所需的权限 (Scopes)。 4. 在“SSO 体验”标签页,启用 **为持久 API 访问存储令牌** 选项。 请确保保存你的更改。 @@ -50,19 +50,19 @@ import Availability from '@components/Availability'; - [企业单点登录 (SSO) 登录与注册](/end-user-flows/enterprise-sso) - [通过账户 API 进行社交账户绑定](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -存储的令牌会附加到用户的社交或企业单点登录 (SSO) 身份上,允许用户后续检索令牌以访问 API,无需再次认证 (Authentication)。 +存储的令牌会绑定到用户的社交或企业单点登录 (SSO) 身份上,允许用户后续无需再次认证 (Authentication) 即可检索令牌用于 API 访问。 ### 检查令牌存储状态 \{#checking-token-storage-status} 你可以在 Logto 控制台检查用户的第三方令牌存储状态: 1. 进入 控制台 > 用户。 -2. 点击你想查看的用户,进入该用户详情页。 -3. 滚动到 **连接** 区域。此处列出了与用户关联的所有社交和企业单点登录 (SSO) 连接。 +2. 点击你想要查看的用户,进入用户详情页。 +3. 滚动到 **连接** 区域。这里列出了该用户关联的所有社交和企业单点登录 (SSO) 连接。 4. 每个连接条目会显示一个令牌状态标签,指示该连接是否已存储令牌。 5. 点击连接条目可查看更多详情,包括已存储的访问令牌 (Access token) 元数据和刷新令牌 (Refresh token) 可用性(如有)。 -你也可以通过管理 API 检查用户第三方身份和令牌存储状态: +你也可以通过管理 API 检查用户的第三方身份和令牌存储状态: - `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`:通过指定连接器 target(如 `github`、`google` 等)获取用户的社交身份及其令牌存储状态。 - `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`:通过指定 SSO 连接器 ID 获取用户的企业单点登录 (SSO) 身份及其令牌存储状态。 @@ -76,18 +76,18 @@ import Availability from '@components/Availability'; ### 令牌元数据 \{#token-metadata} -为保证数据完整性和安全性,所有令牌在存储到密钥库前都会被加密。实际令牌值仅对具有适当授权的终端用户可见。开发者只能获取令牌集的元数据,以便了解存储令牌的状态,而不会暴露敏感内容。 +为保证数据完整性和安全性,所有令牌在存储到密钥库前都会被加密。实际令牌值仅对拥有适当授权的终端用户可见。开发者只能获取令牌集的元数据,以便了解存储令牌的状态,而不会暴露敏感内容。 - `createdAt`:首次建立连接并将令牌集存储到密钥库的时间戳。 -- `updatedAt`:令牌集最近一次被更新的时间。 +- `updatedAt`:令牌集最后一次被更新的时间。 - 如果没有刷新令牌 (Refresh token),该值与 **createdAt** 相同。 - 如果有刷新令牌 (Refresh token),该值反映最近一次访问令牌 (Access token) 被刷新时的时间。 - `hasRefreshToken`:指示是否有刷新令牌 (Refresh token) 可用。 - 如果连接器支持离线访问且授权请求配置正确,Logto 会在身份提供商颁发刷新令牌 (Refresh token) 时与访问令牌 (Access token) 一起存储。 - 当访问令牌 (Access token) 过期且存在有效刷新令牌 (Refresh token) 时,Logto 会在用户请求访问已连接提供商时自动尝试使用存储的刷新令牌 (Refresh token) 获取新的访问令牌 (Access token)。 + 如果连接器支持离线访问且授权请求配置正确,Logto 会在身份提供商颁发刷新令牌 (Refresh token) 时与访问令牌 (Access token) 一同存储。 + 当访问令牌 (Access token) 过期且存在有效刷新令牌 (Refresh token) 时,用户请求访问已连接的提供商时,Logto 会自动尝试使用存储的刷新令牌 (Refresh token) 获取新的访问令牌 (Access token)。 - `expiresAt`:访问令牌 (Access token) 的预计过期时间(单位:**秒**)。 该值基于身份提供商的 token endpoint 返回的 `expires_in` 计算。(仅当提供商在令牌响应中包含 `expires_in` 字段时可用。) -- `scope`:访问令牌 (Access token) 的权限 (Scope),指示身份提供商授予的权限。 +- `scope`:访问令牌 (Access token) 的权限 (Scope),指示身份提供商授予的权限 (Permissions)。 这有助于了解存储的访问令牌 (Access token) 可执行哪些操作。(仅当提供商在令牌响应中包含 `scope` 字段时可用。) - `tokenType`:访问令牌 (Access token) 的类型,通常为 "Bearer"。 (仅当提供商在令牌响应中包含 `token_type` 字段时可用。) @@ -101,7 +101,7 @@ import Availability from '@components/Availability'; - `GET /my-account/sso-identities/:connectorId/access-token`:通过指定连接器 ID 获取企业单点登录 (SSO) 身份的访问令牌 (Access token)。 :::info -了解如何使用 Logto 颁发的访问令牌 (Access token) [启用](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) 和 [访问](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token) 账户 API。 +要检索第三方访问令牌 (Access token),你必须先在 控制台 > 登录与账户 > 账户中心 为终端用户启用 Account API。了解如何[启用 Account API](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api)以及[如何使用 Logto 颁发的访问令牌 (Access token) 访问它](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token)。 ::: ### 令牌轮换 \{#token-rotation} @@ -112,7 +112,7 @@ import Availability from '@components/Availability'; - `404` Not Found:用户没有与指定 target 或连接器 ID 关联的社交或企业单点登录 (SSO) 身份,或未存储访问令牌 (Access token)。 - `401` Unauthorized:访问令牌 (Access token) 已过期。 -如果访问令牌 (Access token) 已过期且有刷新令牌 (Refresh token) 可用,Logto 会自动尝试刷新访问令牌 (Access token),并在响应中返回新的访问令牌 (Access token)。密钥库中的令牌存储也会同步更新为新的访问令牌 (Access token) 及其元数据。 +如果访问令牌 (Access token) 已过期且有刷新令牌 (Refresh token) 可用,Logto 会自动尝试刷新访问令牌 (Access token) 并在响应中返回新的访问令牌 (Access token)。密钥库中的令牌存储也会同步更新为新的访问令牌 (Access token) 及其元数据。 ## 令牌存储删除 \{#token-storage-deletion} @@ -129,13 +129,13 @@ import Availability from '@components/Availability'; - 通过控制台: 进入用户身份详情页,滚动到 **访问令牌 (Access token)** 区域(如有令牌存储),点击该区域末尾的 **删除令牌** 按钮。 - 通过管理 API: - - `DELETE /api/secret/:id`:通过密钥 ID 删除指定密钥,可在用户身份详情中获取该 ID。 + - `DELETE /api/secret/:id`:通过密钥 ID 删除指定密钥,该 ID 可在用户身份详情中获取。 -撤销令牌集后,用户需重新通过第三方提供商认证 (Authentication) 才能再次获取访问第三方 API 的访问令牌 (Access token)。 +撤销令牌集后,用户需重新通过第三方提供商认证 (Authentication) 才能再次获取新的访问令牌 (Access token) 并访问第三方 API。 ## 重新认证与令牌续期 \{#reauthentication-and-token-renewal} -在存储的访问令牌 (Access token) 已过期或应用需要请求更多 API 权限 (Scope) 的场景下,终端用户可以通过第三方提供商重新认证 (Authentication) 以获取新的访问令牌 (Access token)——无需再次登录 Logto。 +在存储的访问令牌 (Access token) 已过期或应用需要请求更多 API 权限 (Scopes) 的场景下,终端用户可以通过第三方提供商重新认证 (Authentication) 以获取新的访问令牌 (Access token)——无需再次登录 Logto。 这可以通过 Logto 的 [社交验证 API](https://openapi.logto.io/operation/operation-createverificationbysocial) 实现,允许用户重新发起联合社交授权流程并更新其存储的令牌集。 :::note @@ -154,13 +154,13 @@ sequenceDiagram User->>Logto: post /api/verification/social Logto->>User: 跳转到第三方提供商 User->>Provider: 认证 (Authentication) 并授权 - Provider->>User: 跳转回并携带授权码 + Provider->>User: 跳转回带有授权码 User->>Logto: post /api/verification/social/verify 携带授权码 Logto->>User: 返回社交验证 ID User->>Logto: patch /my-account/identities/:target/access-token ``` -1. 用户通过调用 `POST /api/verification/social` 接口发起社交验证请求。用户可以指定自定义权限 (Scope) 以请求第三方提供商的额外权限。 +1. 用户通过调用 `POST /api/verification/social` 接口发起社交验证请求。用户可指定自定义权限 (Scopes) 以请求第三方提供商的额外权限 (Permissions)。 ```sh curl -X POST https:///api/verification/social \ @@ -177,7 +177,7 @@ sequenceDiagram - **authorization header**:Logto 颁发的用户访问令牌 (Access token)。 - **connectorId**:Logto 中的社交连接器 ID。 - **redirectUri**:认证 (Authentication) 后将用户跳转回你应用的 URI。你需要在提供商的应用设置中注册该 URI。 - - **scope**:(可选)自定义权限 (Scope),用于请求第三方提供商的额外权限。如果未指定,则使用连接器中配置的默认权限 (Scope)。 + - **scope**:(可选)自定义权限 (Scopes),用于请求第三方提供商的额外权限 (Permissions)。如未指定,则使用连接器中配置的默认权限 (Scopes)。 2. Logto 创建新的社交验证记录,并返回社交验证 ID 及授权 URL,用于将用户跳转到第三方提供商进行认证 (Authentication)。 @@ -215,7 +215,7 @@ sequenceDiagram - **connectorData**:授权码及第三方提供商回调时返回的其他数据。 :::note - 不要忘记校验 `state` 参数,以防止 CSRF 攻击。 + 别忘了校验 `state` 参数以防止 CSRF 攻击。 ::: 6. Logto 验证授权码,并向第三方提供商换取新的访问令牌 (Access token) 和刷新令牌 (Refresh token),然后在响应中返回社交验证 ID。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/blocklist.md index 0ffc6f54a96..d2247d3b050 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -1,37 +1,37 @@ --- slug: /security/blocklist -sidebar_label: 黑名单 +sidebar_label: Blocklist sidebar_position: 3 --- -# 黑名单 +# 阻止列表 -## 邮箱黑名单 {#email-blocklist} +## 邮箱阻止列表 {#email-blocklist} -邮箱黑名单策略允许自定义邮箱黑名单设置,以防止账号注册滥用。它会监控用于注册和账户设置的邮箱地址。如果用户尝试注册或绑定违反任何黑名单规则的邮箱地址,系统将拒绝该请求,从而帮助减少垃圾账号并提升整体账户安全性。 +邮箱阻止列表策略允许自定义邮箱阻止设置,以防止账号注册滥用。它会监控用于注册和账号设置的邮箱地址。如果用户尝试注册或关联违反任何阻止规则的邮箱地址,系统将拒绝该请求,从而帮助减少垃圾账号并提升整体账号安全性。 -前往 控制台 > 安全 > 黑名单 配置邮箱黑名单设置。 +前往 控制台 > 安全 > 阻止列表 配置邮箱阻止列表设置。 -### 屏蔽一次性邮箱地址 {#block-disposable-email-addresses} +### 阻止一次性邮箱地址 {#block-disposable-email-addresses} 这是一个**仅限云端**的功能。启用后,系统会自动将所提供邮箱地址的域名与已知一次性邮箱域名列表进行校验。如果该域名在列表中,系统将拒绝该请求。一次性邮箱域名列表会定期更新,以确保其有效性。 -### 屏蔽邮箱子地址 {#block-email-subaddressing} +### 阻止邮箱子地址 {#block-email-subaddressing} -邮箱子地址允许用户通过在邮箱地址中添加加号(+)及附加字符(如 user+tag@example.com)来创建邮箱变体。恶意用户可能会利用此功能绕过黑名单限制。启用屏蔽邮箱子地址功能后,系统将拒绝所有使用子地址格式进行注册或账户绑定的尝试。 +邮箱子地址允许用户通过在邮箱名后添加加号(+)及附加字符(如 user+tag@example.com)来创建邮箱地址的变体。恶意用户可能利用此功能绕过阻止限制。启用阻止邮箱子地址功能后,系统将拒绝任何使用子地址格式进行注册或账号关联的尝试。 -### 自定义邮箱黑名单 {#custom-email-blocklist} +### 自定义邮箱阻止列表 {#custom-email-blocklist} -你可以通过指定要屏蔽的邮箱地址或域名来创建自定义邮箱黑名单。系统会拒绝所有与这些条目匹配的注册或账户绑定尝试。黑名单支持完整邮箱地址和域名匹配。 +你可以通过指定要阻止的邮箱地址或域名,创建自定义邮箱阻止列表。系统会拒绝所有与这些条目匹配的注册或账号关联尝试。阻止列表支持完整邮箱地址和域名匹配。 -例如,将 `@example.com` 添加到黑名单后,将屏蔽所有该域名下的邮箱地址。同样,添加 `foo@example.com` 将只屏蔽该邮箱地址。 +例如,将 `@example.com` 添加到阻止列表后,将阻止所有该域名下的邮箱地址。同样,添加 `foo@example.com` 将只阻止该邮箱地址。 :::note -一次性邮箱、子地址和自定义邮箱在注册和账户绑定时会被限制。已有这些邮箱地址的现有用户仍可登录。 +一次性邮箱、子地址和自定义邮箱会在[新用户注册](/end-user-flows/sign-up-and-sign-in/sign-up)、[社交登录时收集注册标识符](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers)、以及通过 [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email) 更新邮箱时被限制。已有这些邮箱地址的用户仍可登录。 -- 管理员可以通过在 控制台 > 用户管理 手动添加用户,或通过 [Management API](https://openapi.logto.io/operation/operation-createuser) “绕过限制”。例如,在屏蔽子地址时创建一个带有子地址邮箱的用户。 -- 可通过在 控制台 > 用户管理 删除或暂停账号来屏蔽现有账户。 +- 管理员可以通过在 控制台 > 用户管理 手动添加用户,或通过 [Management API](https://openapi.logto.io/operation/operation-createuser)“绕过限制”。例如,在阻止子地址时创建带子地址邮箱的用户。 +- 可通过在 控制台 > 用户管理 删除或暂停账号来阻止现有账号。 ::: diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/password-policy.mdx index 4aedd34de84..74fc8ffd2ce 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,27 +6,36 @@ sidebar_position: 1 # 密码策略 +Logto 会根据密码的创建或更新方式以不同方式应用密码策略: + +- 终端用户流程,如 [开箱即用的登录体验](/end-user-flows/sign-up-and-sign-in/sign-up)、[体验 API](/customization/bring-your-ui) 和 [Account API](/end-user-flows/account-settings/by-account-api#update-users-password) 总是强制执行当前的[密码策略](#set-up-password-policy)。 +- 管理员通过 Management API [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) 的操作则不受限制,允许你在需要时无需策略检查即可配置或重置凭据。 +- 若要根据当前规则审计现有密码,请调用 [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 并根据返回的验证结果采取措施。阅读[密码合规性检查](#password-compliance-check)以了解更多信息。 + ## 设置密码策略 \{#set-up-password-policy} -对于新用户或正在更新密码的用户,你可以设置密码策略以强制执行密码强度要求。请访问 控制台 > 安全 > 密码策略 来配置密码策略设置。 +对于新用户或正在更新密码的用户,你可以设置密码策略以强制执行密码强度要求。访问 控制台 > 安全 > 密码策略 配置密码策略设置。 -1. **最小密码长度**:设置密码所需的最小字符数。(NIST 建议至少使用 8 个 [字符](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) +1. **最小密码长度**:设置密码所需的最小字符数。(NIST 建议至少使用 8 个[字符](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) 2. **最少所需字符类型数**:设置密码所需的最少字符类型数。可用的字符类型包括: 1. 大写字母:`(A-Z)` 2. 小写字母:`(a-z)` 3. 数字:`(0-9)` 4. 特殊字符:``(!"#$%&'()*+,-./:;<>=?@[]^\_`|{}~ )`` -3. **泄露历史检查**:启用此设置后,将拒绝在数据泄露中已暴露过的密码。(由 [Have I Been Pwned](https://haveibeenpwned.com/Passwords) 提供支持) +3. **泄露历史检查**:启用此设置后,将拒绝在数据泄露中曾经暴露过的密码。(由 [Have I Been Pwned](https://haveibeenpwned.com/Passwords) 提供支持) 4. **重复字符检查**:启用此设置后,将拒绝包含重复字符的密码。(例如,“11111111”或“password123”) -5. **用户信息检查**:启用此设置后,将拒绝包含用户名、电子邮件地址或电话号码等用户信息的密码。 -6. **自定义词汇**:提供一个自定义词汇列表(不区分大小写),这些词汇将被拒绝用于密码中。 +5. **用户信息检查**:启用此设置后,将拒绝包含用户名、邮箱地址或手机号等用户信息的密码。 +6. **自定义词语**:提供一个自定义词语列表(不区分大小写),这些词语将被拒绝用于密码中。 ## 密码合规性检查 \{#password-compliance-check} 在你更新 Logto 中的密码策略后,现有用户仍然可以使用当前密码登录。只有新创建的账户才需要遵循更新后的策略。 -为了加强安全性,你可以使用 `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 检查用户的密码是否符合默认登录体验中定义的当前策略。如果不符合,你可以通过自定义流程,使用 [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) 提示用户更新密码。 +为了加强安全性,你可以使用 `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 检查用户的密码是否符合默认登录体验中定义的当前策略。如果不符合,你可以通过自定义流程,使用 [Account API](/end-user-flows/account-settings/by-account-api) 提示用户更新密码。 ## 相关资源 \{#related-resources} +管理用户 +注册与登录 +通过 Account API 进行账户设置 设计你的密码策略 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index 8d65f12c103..96c3bbfad01 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -8,24 +8,23 @@ sidebar_position: 2 ### 浏览和搜索用户 \{#browse-and-search-users} -要访问 Logto 控制台中的用户管理功能,请导航至 控制台 > 用户管理。 -进入后,你会看到所有用户的表格视图。 +要访问 Logto 控制台中的用户管理功能,请导航至 控制台 > 用户管理。进入后,你会看到所有用户的表格视图。 该表格包含三列: - **用户**:显示用户的信息,如头像、全名、用户名、手机号和邮箱 - **来自应用程序**:显示用户最初注册时所用的应用程序名称 -- **最近登录**:显示用户最近一次登录的时间戳。 +- **最近登录**:显示用户最近一次登录的时间戳 支持对 [`name`](/user-management/user-data#name)、[`id`](/user-management/user-data#id)、[`username`](/user-management/user-data#username)、[`primary-phone`](/user-management/user-data#primary_phone)、[`primary-email`](/user-management/user-data#primary_email) 进行关键词映射搜索。 ### 添加用户 \{#add-users} -通过控制台,开发者可以为终端用户创建新账号。只需点击屏幕右上角的“添加用户”按钮即可。 +通过控制台,开发者可以为终端用户创建新账号。只需点击页面右上角的“添加用户”按钮即可。 在 Logto 控制台或通过 Management API 创建用户时(不是终端用户通过 UI 自助注册),你必须至少提供一个标识符:`primary email`、`primary phone` 或 `username`。`name` 字段为可选项。 -用户创建后,Logto 会自动生成一个随机密码。初始密码只会显示一次,但你可以稍后[重置密码](./manage-users#reset-user-password)。如果你想设置特定密码,请在用户创建后使用 Management API 的 `patch /api/users/{userId}/password` 进行更新。 +用户创建后,Logto 会自动生成一个随机密码。初始密码只会显示一次,但你可以稍后[重置密码](./manage-users#reset-user-password)。如果你想设置特定密码,可在用户创建后使用 Management API 的 `patch /api/users/{userId}/password` 进行更新。 你可以一键复制**输入的标识符(邮箱地址 / 手机号 / 用户名)**和**初始密码**,方便将这些凭证分享给新用户,让他们可以登录并开始使用。 @@ -37,58 +36,71 @@ sidebar_position: 2 ### 查看和更新用户资料 \{#view-and-update-the-user-profile} -要查看用户详情,只需点击用户表格中的对应行。这将带你进入“**用户详情**”页面,你可以在此找到用户的资料信息,包括: +要查看用户详情,只需点击用户表格中的对应行。你将进入“**用户详情**”页面,在这里可以查看用户的资料信息,包括: - **认证 (Authentication) 相关数据**: - **邮箱地址**([primary_email](/user-management/user-data#primary_email)):可编辑 - **手机号**([primary_phone](/user-management/user-data#primary_phone)):可编辑 - **用户名**([username](/user-management/user-data#username)):可编辑 - - **密码**([has_password](/user-management/user-data#has_password)):你可以重新生成随机密码。了解更多“[重置用户密码](#reset-user-password)”。 - - **社交连接**([identities](/user-management/user-data#social-identities)):查看已绑定的社交账号及社交 ID。例如,如果用户通过 Facebook 登录,你会在列表中看到“Facebook”项。你可以在控制台移除已绑定的社交身份,但不能代替终端用户绑定新的社交身份。 - - **企业单点登录 (SSO) 连接**([sso_identities](/user-management/user-data#sso-identities)):查看已绑定的企业身份。你无法在控制台添加或移除 SSO 身份。 - - **多因素认证 (MFA)**([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)):查看该用户已设置的所有认证因子(如通行密钥、验证器应用、备份码)。可以在控制台移除因子。 + - **密码**([has_password](/user-management/user-data#has_password)):你可以重新生成随机密码。详见“[重置用户密码](#reset-user-password)”。 + - **多因素认证 (MFA)**([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)):查看该用户已设置的所有认证 (Authentication) 因子(如通行密钥、认证器应用、备用码)。可在控制台移除因子。 - **个人访问令牌**:创建、查看、重命名和删除[个人访问令牌](/user-management/personal-access-token)。 -- **用户资料数据**:姓名、头像 URL、自定义数据,以及未包含的其他 OpenID Connect 标准声明。这些资料字段均可编辑。 +- **连接**: + - **社交连接**([identities](/user-management/user-data#social-identities)): + - 查看用户已绑定的社交账号,包括社交 ID 及从社交平台同步的资料详情(如用户通过 Facebook 登录,则会显示“Facebook”条目)。 + - 你可以移除已有社交身份,但不能代用户绑定新的社交账号。 + - 对于启用了[token 存储](/secret-vault/federated-token-set)的社交连接器,可在连接详情页查看和管理访问令牌 (Access token) 与刷新令牌 (Refresh token)。 + - **企业单点登录 (SSO) 连接**([sso_identities](/user-management/user-data#sso-identities)): + - 查看用户已绑定的企业身份,包括企业 ID 及从企业身份提供商同步的资料详情。 + - 你无法在控制台添加或移除企业单点登录 (SSO) 身份。 + - 对于基于 OIDC 的企业连接器,若启用了[token 存储](/secret-vault/federated-token-set),可在连接详情页查看和删除令牌。 +- **用户资料数据**:姓名、头像 URL、自定义数据及未包含的其他 OpenID Connect 标准声明 (Claims)。所有这些资料字段均可编辑。 :::warning -在移除社交连接前,请务必确认用户还有其他登录方式,如其他社交连接、手机号、邮箱或用户名加密码。如果用户没有其他登录方式,移除社交连接后将无法再次访问其账号。 +在移除社交连接前,请务必确认用户还有其他登录方式,如其他社交连接、手机号、邮箱或用户名加密码。如果用户没有其他登录方式,移除社交连接后将无法再次访问其账户。 ::: ### 查看用户活动 \{#view-user-activities} -要查看用户的近期活动,请在“用户详情”页面切换到“用户日志”子标签页。你会看到一个表格,显示用户的近期活动,包括执行的操作、操作结果、相关应用程序以及操作时间。 +要查看用户的近期活动,请在“用户详情”页面切换到“用户日志”子标签。在这里,你可以看到一张表格,显示用户的近期操作,包括执行的动作、结果、相关应用和操作时间。 -点击表格行可查看更多日志详情,例如 IP 地址、用户代理、原始数据等。 +点击表格行可查看更多日志详情,如 IP 地址、用户代理、原始数据等。 ### 挂起用户 \{#suspend-user} 在“用户详情”页面,点击“三点”->“挂起用户”按钮。 -用户被挂起后,将无法登录你的应用,也无法在当前访问令牌过期后获取新的访问令牌。此外,该用户发起的任何 API 请求都会失败。 +用户被挂起后,将无法登录你的应用,也无法在当前访问令牌 (Access token) 过期后获取新的访问令牌 (Access token)。此外,该用户发起的任何 API 请求都会失败。 -如果你想重新激活该用户,只需点击“三点”->“重新激活用户”按钮即可。 +如需恢复该用户,只需点击“三点”->“恢复用户”按钮即可。 ### 删除用户 \{#delete-user} -在“用户详情”页面,点击“三点”->“删除”按钮。删除用户操作无法撤销。 +在“用户详情”页面,点击“三点”->“删除”按钮。删除用户操作不可撤销。 ### 重置用户密码 \{#reset-user-password} 在“用户详情”页面,点击“三点”->“重置密码”按钮,Logto 会自动重新生成一个随机密码。 -重置密码后,请复制并发送给终端用户。关闭“重置密码”弹窗后,你将无法再次查看该密码。如果忘记保存,可以再次重置。 +重置密码后,请复制并发送给终端用户。关闭“重置密码”弹窗后将无法再次查看密码。如果忘记保存,可以再次重置。 -你无法在 Logto 控制台为用户设置特定密码,但可以使用 [Management API](/integrate-logto/interact-with-management-api) 的 `PATCH /api/users/{userId}/password` 指定密码。 +你无法在 Logto 控制台为用户设置特定密码,但可以通过 [Management API](/integrate-logto/interact-with-management-api) 的 `PATCH /api/users/{userId}/password` 指定密码。 + +## 密码合规性检查 \{#password-compliance-check} + +在 Logto 更新[密码策略](/security/password-policy)后,现有用户仍可使用当前密码登录。只有新创建的账号才需遵循更新后的密码策略。 + +为加强安全性,你可以使用 `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 检查用户密码是否符合默认登录体验下的当前策略。如不符合,可通过自定义流程结合 [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) 提示用户更新密码。 ### 管理用户角色 \{#manage-roles-of-users} -在用户详情页面的“角色”标签页,你可以轻松分配或移除角色,以满足你的需求。详情请参考[基于角色的访问控制 (RBAC)](/authorization/role-based-access-control)。 +在用户详情页的“角色”标签下,你可以轻松分配或移除角色以满足需求。详情请查阅[基于角色的访问控制 (RBAC)](/authorization/role-based-access-control)。 ### 查看用户所属组织 \{#view-the-organizations-the-user-belongs-to} -Logto 支持[组织 (Organizations)](/organizations/organization-management)并可管理其成员。你可以轻松查看用户详情及其所属的组织。 +Logto 支持[组织 (Organizations)](/organizations/organization-management)并可管理其成员。你可以轻松查看用户详情及其所属组织。 ## 通过 Logto Management API 管理 \{#manage-via-logto-management-api} @@ -96,7 +108,7 @@ Logto 支持[组织 (Organizations)](/organizations/organization-management)并 与用户相关的 [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API 挂载在 `/api/users`,用户活动(即用户日志)除外,日志接口为 `/api/logs?userId=:userId`。 -你可以在多种场景下通过 Management API 管理用户。例如[高级用户搜索](/user-management/advanced-user-search)、[批量创建账号](https://openapi.logto.io/operation/operation-createuser)、[仅限邀请注册](/end-user-flows/sign-up-and-sign-in/disable-user-registration)等。 +你可以在多种场景下通过 Management API 管理用户,如[高级用户搜索](/user-management/advanced-user-search)、[批量创建账号](https://openapi.logto.io/operation/operation-createuser)、[仅限邀请注册](/end-user-flows/sign-up-and-sign-in/disable-user-registration)等。 ## 常见问题 \{#faqs} @@ -108,8 +120,8 @@ Logto 支持[组织 (Organizations)](/organizations/organization-management)并 -由于 Logto 的 [Omni-sign-in](https://logto.io/products/omni-sign-in) 特性,在认证 (Authentication) 前并不设计为限制用户访问特定应用。 -不过,你仍然可以为应用设计特定的用户角色和权限来保护你的 API 资源,并在用户成功登录后在 API 访问时校验权限。 +由于 Logto 的 [Omni-sign-in](https://logto.io/products/omni-sign-in) 特性,设计上并不支持在认证 (Authentication) 前限制用户访问某些应用。 +不过,你仍然可以为应用设计特定的用户角色和权限,保护你的 API 资源,并在用户成功登录后对 API 访问进行权限校验。 更多信息请参考授权 (Authorization):[基于角色的访问控制 (RBAC)](/authorization/role-based-access-control)。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index ae89172b84d..aa15919cbfd 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -12,9 +12,9 @@ sidebar_position: 1 它由以下类型的数据组成: -- [基础数据](/user-management/user-data#basic-data):来自用户资料的基本信息。它存储除社交 `identities` 和 `custom_data` 之外的所有 _用户_ 属性,如用户 id、用户名、邮箱、手机号以及用户上次登录时间等。 -- [社交身份](/user-management/user-data#social-identities):存储通过社交登录(即通过社交连接器登录)获取的用户信息,如 Facebook、GitHub 和微信等。 -- [自定义数据](/user-management/user-data#custom-data):存储未在预定义用户属性中列出的其他用户信息,如用户偏好的颜色和语言。 +- [基础数据](/user-management/user-data#basic-data):来自用户资料的基本信息。它存储除了社交 `identities` 和 `custom_data` 之外的所有 _用户_ 属性,如用户 id、用户名、邮箱、手机号以及用户上次登录时间等。 +- [社交身份](/user-management/user-data#social-identities):存储通过社交登录(即使用社交连接器登录)获取的用户信息,如 Facebook、GitHub 和微信。 +- [自定义数据](/user-management/user-data#custom-data):存储未在预定义用户属性中列出的额外用户信息,如用户偏好的颜色和语言。 以下是通过 Facebook 登录获取的用户数据示例: @@ -52,7 +52,7 @@ sidebar_position: 1 ## 基础数据 \{#basic-data} -下面我们来逐一介绍用户 _基础数据_ 中的所有属性。 +让我们逐一了解用户 _基础数据_ 中的所有属性。 ### id \{#id} @@ -62,7 +62,7 @@ _id_ 是在 Logto 中用于唯一标识用户的自动生成主键。 _username_ 用于通过 _用户名_ 和密码登录。 -其值来源于用户首次注册时填写的用户名。它可能为 `null`。非 null 值最长不超过 128 个字符,只能包含字母、数字和下划线(`_`),且不能以数字开头。区分大小写。 +其值来源于用户首次注册时填写的用户名。它可能为 `null`。非空值最长不超过 128 个字符,只能包含字母、数字和下划线(`_`),且不能以数字开头。区分大小写。 ### primary_email \{#primary_email} @@ -70,11 +70,15 @@ _primary_email_ 是用户的邮箱地址,用于通过邮箱和密码 / 验证 其值通常来源于用户首次注册时填写的邮箱地址。它可能为 `null`。最大长度为 128。 +只有来自社交或企业单点登录 (SSO) 身份提供商的已验证邮箱地址才能同步并保存为 `primary_email`。 + ### primary_phone \{#primary_phone} _primary_phone_ 是用户的手机号,用于通过手机号和密码 / 短信验证码登录。 -其值通常来源于用户首次注册时填写的手机号。它可能为 `null`。非 null 值应包含以[国家区号](https://en.wikipedia.org/wiki/List_of_country_calling_codes)(不含加号 `+`)开头的数字。 +其值通常来源于用户首次注册时填写的手机号。它可能为 `null`。非空值应包含以[国家区号](https://en.wikipedia.org/wiki/List_of_country_calling_codes)(不含加号 `+`)开头的数字。 + +只有来自社交或企业单点登录 (SSO) 身份提供商的已验证手机号才能同步并保存为 `primary_phone`。 ### name \{#name} @@ -84,17 +88,17 @@ _name_ 是用户的全名。最大长度为 128。 _avatar_ 是指向用户头像图片的 URL。最大长度为 2048。 -如果用户通过 Google、Facebook 等社交连接器注册,其值可能来自社交用户信息。 +如果用户通过 Google、Facebook 等社交连接器注册,其值可能会从社交用户信息中获取。 :::note -该属性映射到 [OpenID Connect](https://openid.net/connect/) 标准中的 `picture` 声明 (Claim)。 +此属性映射到 [OpenID Connect](https://openid.net/connect/) 标准中的 `picture` 声明 (Claim)。 ::: ### profile \{#profile} -_profile_ 存储了 OpenID Connect [标准声明 (Claims)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 中未包含在用户属性中的其他信息。 +_profile_ 存储了 OpenID Connect [标准声明 (Claims)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 中未包含在用户属性中的额外信息。 其类型定义可在[此文件](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6)中找到。以下是类型定义的副本: @@ -128,7 +132,7 @@ type UserProfile = Partial<{ ::: -与其他标准声明 (Claims) 不同的是,`profile` 中的属性只有在值不为空时才会包含在 [ID 令牌 (ID token)](https://auth.wiki/id-token) 或 userinfo 接口响应中,而其他标准声明 (Claims) 的值为空时会返回 `null`。 +与其他标准声明 (Claims) 不同的是,`profile` 中的属性只有在值不为空时,才会包含在 [ID 令牌 (ID token)](https://auth.wiki/id-token) 或 userinfo 端点响应中,而其他标准声明 (Claims) 的值为空时会返回 `null`。 ### application_id \{#application_id} @@ -144,7 +148,7 @@ _created_at_ 是用户注册账号时的带时区时间戳。 ### updated_at \{#updated_at} -_updated_at_ 是用户资料信息最后一次被更新时的带时区时间戳。 +_updated_at_ 是用户资料信息最后一次更新时的带时区时间戳。 ### has_password \{#has_password} @@ -154,13 +158,13 @@ _has_password_ 是一个布尔值,表示用户是否设置了密码。你可 _password_encrypted_ 用于存储用户的加密密码。 -其值来源于用户首次注册时填写的密码。它可能为 `null`。如果非 null,则加密前的原始内容至少为六个字符。 +其值来源于用户首次注册时填写的密码。它可能为 `null`。如果非空,原始内容(加密前)至少为六个字符。 ### password_encryption_method \{#password_encryption_method} _password_encryption_method_ 用于加密用户密码。其值在用户通过用户名和密码注册时初始化。它可能为 `null`。 -Logto 默认使用 [Argon2](https://en.wikipedia.org/wiki/Argon2) 的实现 [node-argon2](https://github.com/ranisalt/node-argon2) 作为加密方法;如有兴趣可参考相关文档。 +Logto 默认使用 [Argon2](https://en.wikipedia.org/wiki/Argon2) 的实现 [node-argon2](https://github.com/ranisalt/node-argon2) 作为加密方法;如有兴趣可参考文档了解详情。 以下是密码为 `123456` 的用户的 _password_encrypted_ 和 _password_encryption_method_ 示例: @@ -173,13 +177,13 @@ Logto 默认使用 [Argon2](https://en.wikipedia.org/wiki/Argon2) 的实现 [nod ### is_suspended \{#is_suspended} -_is_suspended_ 是一个布尔值,表示用户是否被停用。你可以通过 [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) 或 Logto 控制台管理该值。 +_is_suspended_ 是一个布尔值,表示用户是否被停用。你可以通过调用 [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) 或使用 Logto 控制台进行管理。 一旦用户被停用,已授予的刷新令牌 (Refresh tokens) 会立即被吊销,用户将无法再通过 Logto 进行认证 (Authentication)。 ### mfa_verification_factors \{#mfa_verification_factors} -_mfa_verification_factors_ 是一个数组,列出了与用户账户关联的[多因素认证 (MFA)](/end-user-flows/mfa)方式。可能的值包括:_Totp_(认证器应用 OTP)、_WebAuthn_(Passkey)、_BackupCode_。 +_mfa_verification_factors_ 是一个数组,列出了与用户账户关联的[多因素认证 (MFA)](/end-user-flows/mfa)方式。可能的值包括:_Totp_(身份验证器应用 OTP)、_WebAuthn_(Passkey)、_BackupCode_。 ```tsx mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; @@ -187,14 +191,14 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; ## 社交身份 \{#social-identities} -_identities_ 包含通过[社交登录](/end-user-flows/sign-up-and-sign-in/social-sign-in)(即通过[社交连接器](/connectors/social-connectors)登录)获取的用户信息。每个用户的 _identities_ 都存储在一个独立的 JSON 对象中。 +_identities_ 包含通过[社交登录](/end-user-flows/sign-up-and-sign-in/social-sign-in)(即使用[社交连接器](/connectors/social-connectors)登录)获取的用户信息。每个用户的 _identities_ 都存储在独立的 JSON 对象中。 -用户信息因社交身份提供商(即社交平台)不同而异,通常包括以下内容: +用户信息因社交身份提供商(即社交网络平台)而异,通常包括以下内容: - 身份提供商的 _target_,如 "facebook" 或 "google" - 用户在该提供商下的唯一标识 - 用户姓名 -- 用户已验证的邮箱 +- 用户已验证邮箱 - 用户头像 用户账户可以通过社交登录关联多个社交身份提供商;从这些提供商获取的对应用户信息会存储在 _identities_ 对象中。 @@ -226,7 +230,7 @@ _identities_ 包含通过[社交登录](/end-user-flows/sign-up-and-sign-in/soci ## SSO 身份 \{#sso-identities} -_sso_identities_ 包含通过[企业单点登录 (SSO)](/end-user-flows/enterprise-sso)(即通过企业连接器单点登录](/connectors/enterprise-connectors))获取的用户信息。每个用户的 _ssoIdentities_ 都存储在一个独立的 JSON 对象中。 +_sso_identities_ 包含通过[企业单点登录 (SSO)](/end-user-flows/enterprise-sso)(即使用企业连接器进行单点登录](/connectors/enterprise-connectors))获取的用户信息。每个用户的 _ssoIdentities_ 都存储在独立的 JSON 对象中。 从 SSO 身份提供商同步的数据取决于企业连接器中配置的 scopes。以下是 TypeScript 类型定义: @@ -240,12 +244,12 @@ type SSOIdentity = { ## 自定义数据 \{#custom-data} -_custom_data_ 用于存储未在预定义用户属性中列出的其他用户信息。 +_custom_data_ 存储未在预定义用户属性中列出的额外用户信息。 你可以使用 _custom_data_ 做以下事情: -- 记录用户是否完成了特定操作,如是否已看过欢迎页。 -- 在用户资料中存储应用特定的数据,如每个应用下用户偏好的语言和外观。 +- 记录用户是否完成了特定操作,如是否已查看欢迎页。 +- 在用户资料中存储应用特定的数据,如用户在每个应用中的偏好语言和外观。 - 维护与用户相关的其他任意数据。 以下是 Logto 管理员用户的 _custom_data_ 示例: @@ -266,7 +270,7 @@ _custom_data_ 用于存储未在预定义用户属性中列出的其他用户信 } ``` -每个用户的 _custom_data_ 都存储在一个独立的 JSON 对象中。 +每个用户的 _custom_data_ 都存储在独立的 JSON 对象中。 :::note @@ -274,11 +278,11 @@ _custom_data_ 用于存储未在预定义用户属性中列出的其他用户信 ::: -自定义数据可通过[自定义 JWT 令牌声明 (Claims)](/developers/custom-token-claims)在用户登录后访问,而 JWT 令牌是 base64 编码(非加密)的,并且经常在网络中传输,任何敏感数据都容易被暴露。 +自定义数据可通过[自定义 JWT 令牌声明 (Claims)](/developers/custom-token-claims)在用户登录后访问,而 JWT 令牌是 base64 编码(非加密)且经常在网络中传输,任何敏感数据都容易被泄露。 -你也可以通过 [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) 获取包含 _custom_data_ 的用户资料,并将其发送到前端应用或外部后端服务。因此,将敏感信息放在 _custom_data_ 中可能导致数据泄露。 +你也可以通过 [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) 获取包含 _custom_data_ 的用户资料,并将其发送到前端应用或外部后端服务。因此,将敏感信息放入 _custom_data_ 可能导致数据泄露。 -如果你仍然希望将敏感信息放入 _custom_data_,建议先进行加密。只在可信方(如你的后端服务)进行加解密,避免在前端应用中处理。这样可以最大程度减少用户 _custom_data_ 意外泄露时的损失。 +如果你仍然需要将敏感信息放入 _custom_data_,建议先加密。只在可信方(如你的后端服务)进行加解密,避免在前端应用中处理。这样可以最大程度减少用户 _custom_data_ 被误泄露时的损失。 **如何收集和更新用户自定义数据** @@ -289,11 +293,11 @@ _custom_data_ 用于存储未在预定义用户属性中列出的其他用户信 - 使用 [Management API](/user-management/manage-users/#manage-via-logto-management-api) 进行用户管理或高级自定义流程: - 使用 [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) 获取所有用户数据。 - 使用 [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) 更新用户的 _custom_data_。 -- 你的支持团队可以直接在 控制台 > 用户管理 中更新用户 _custom_data_。了解更多关于[查看和更新用户资料](/user-management/manage-users/#view-and-update-the-user-profile)。 +- 你的支持团队可以直接在 控制台 > 用户管理 中更新用户 _custom_data_。了解更多[查看和更新用户资料](/user-management/manage-users/#view-and-update-the-user-profile)。 请谨慎更新。更新用户的 _custom_data_ 会完全覆盖存储中的原始内容。 -例如,如果你调用更新 _custom_data_ API 时的输入如下(假设原始 _custom_data_ 如前面的示例数据): +例如,如果你调用更新 _custom_data_ API 时输入如下(假设原始 _custom_data_ 如前所示): ```json { @@ -319,26 +323,26 @@ _custom_data_ 用于存储未在预定义用户属性中列出的其他用户信 以下数据库用户表字段(除 _password_encrypted_ 和 _password_encryption_method_ 外)在用户资料中可见,这意味着你可以通过 [Management API](https://openapi.logto.io/operation/operation-getuser) 查询它们。 -| 名称 | 类型 | 描述 | 唯一 | 必填 | -| ----------------------------------------------------------------------------------- | --------- | -------------------------- | ---- | ---- | -| [id](/user-management/user-data#id) | string | 唯一标识符 | ✅ | ✅ | -| [username](/user-management/user-data#username) | string | 用于登录的用户名 | ✅ | ❌ | -| [primary_email](/user-management/user-data#primary_email) | string | 主邮箱 | ✅ | ❌ | -| [primary_phone](/user-management/user-data#primary_phone) | string | 主手机号 | ✅ | ❌ | -| [name](/user-management/user-data#name) | string | 全名 | ❌ | ❌ | -| [avatar](/user-management/user-data#avatar) | string | 指向用户头像图片的 URL | ❌ | ❌ | -| [profile](/user-management/user-data#profile) | object | 用户资料 | ❌ | ✅ | -| [identities](/user-management/user-data#social-identities) | object | 通过社交登录获取的用户信息 | ❌ | ✅ | -| [custom_data](/user-management/user-data#custom-data) | object | 可自定义属性中的附加信息 | ❌ | ✅ | -| [application_id](/user-management/user-data#application_id) | string | 用户首次注册的应用 ID | ❌ | ✅ | -| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | 用户上次登录时的时间戳 | ❌ | ✅ | -| [password_encrypted](/user-management/user-data#password_encrypted) | string | 加密密码 | ❌ | ❌ | -| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | 密码加密方式 | ❌ | ❌ | -| [is_suspended](/user-management/user-data#is_suspended) | bool | 用户停用标记 | ❌ | ✅ | -| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 验证因子 | ❌ | ✅ | - -- **唯一**:确保数据库表某属性值的[唯一性](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS)。 -- **必填**:确保数据库表某属性值不能为 `null`。 +| 名称 | 类型 | 描述 | 唯一 | 必填 | +| ----------------------------------------------------------------------------------- | --------- | ------------------------ | ---- | ---- | +| [id](/user-management/user-data#id) | string | 唯一标识符 | ✅ | ✅ | +| [username](/user-management/user-data#username) | string | 登录用户名 | ✅ | ❌ | +| [primary_email](/user-management/user-data#primary_email) | string | 主邮箱 | ✅ | ❌ | +| [primary_phone](/user-management/user-data#primary_phone) | string | 主手机号 | ✅ | ❌ | +| [name](/user-management/user-data#name) | string | 全名 | ❌ | ❌ | +| [avatar](/user-management/user-data#avatar) | string | 用户头像图片的 URL | ❌ | ❌ | +| [profile](/user-management/user-data#profile) | object | 用户资料 | ❌ | ✅ | +| [identities](/user-management/user-data#social-identities) | object | 社交登录获取的用户信息 | ❌ | ✅ | +| [custom_data](/user-management/user-data#custom-data) | object | 可自定义属性中的附加信息 | ❌ | ✅ | +| [application_id](/user-management/user-data#application_id) | string | 用户首次注册的应用 ID | ❌ | ✅ | +| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | 用户上次登录的时间戳 | ❌ | ✅ | +| [password_encrypted](/user-management/user-data#password_encrypted) | string | 加密密码 | ❌ | ❌ | +| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | 密码加密方法 | ❌ | ❌ | +| [is_suspended](/user-management/user-data#is_suspended) | bool | 用户停用标记 | ❌ | ✅ | +| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 验证因子 | ❌ | ✅ | + +- **唯一**:确保数据库表属性值的[唯一性](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS)。 +- **必填**:确保数据库表属性值不能为 `null`。 ## 相关资源 \{#related-resources} diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx index 3ed866441f6..8fbe2d3f081 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/authorization/global-api-resources.mdx @@ -13,43 +13,43 @@ import Tabs from '@theme/Tabs'; export const resource = 'https://api.your-app.com'; -在 Logto 中使用角色型存取控制 (RBAC, Role-based Access Control) 來保護產品層級的 API。指派全域角色 (Roles) 與權限 (Permissions),以控管所有使用者與用戶端在你的應用程式中的存取權限。 +使用 Logto 的角色型存取控制 (RBAC, Role-based Access Control) 來保護產品層級的 API。指派全域角色 (Roles) 與權限 (Permissions),以控管所有使用者與用戶端在你的應用程式中的存取權限。 -## 什麼是全域 API 資源 (API resources)? \{#what-are-global-api-resources} +## 什麼是全域 API 資源 (API resources)?\{#what-are-global-api-resources} -全域 API 資源是指在你的應用程式中,所有使用者皆可存取的端點或服務,無論其所屬組織或租戶。這些通常是對外公開的 API、核心產品服務,或任何未限定於特定組織的端點。 +全域 API 資源 (API resources) 是指在你的應用程式中,所有使用者皆可存取的端點或服務,不論其所屬組織或租戶。這些通常是對外公開的 API、核心產品服務,或任何未限定於特定組織的端點。 -**常見使用情境包括** +**常見應用情境包含** -- 供所有使用者共享的公開 API 或端點。 +- 供所有使用者共用的公開 API 或端點。 - 不屬於多租戶架構的微服務。 -- 所有客戶都會使用的核心應用程式 API(如 `/api/users`、`/api/products`)。 +- 所有客戶都會用到的核心應用程式 API(如 `/api/users`、`/api/products`)。 Logto 允許你結合 OAuth 2.1 與彈性的角色型存取控制來保護這些 API。 -## 在 Logto 中的運作方式 \{#how-it-works-in-logto} +## Logto 中的運作方式 \{#how-it-works-in-logto} -- **API 資源 (API resources) 與權限 (Permissions) 為全域註冊:** 每個你想保護的 API 都需以唯一的資源標示符 (Resource indicator, URI) 註冊,並設定一組控制存取的權限範圍 (Scopes)。 +- **API 資源 (API resources) 與權限 (Permissions) 全域註冊:** 你想保護的每個 API 都需以唯一的資源標示符 (Resource indicator, URI) 註冊,並設定一組控制存取的權限範圍 (Scopes)。 - **存取權由全域角色 (Roles) 控制:** 你可以將權限指派給角色,再將角色指派給使用者或用戶端。 -- **與組織層級權限分離:** 全域 API 資源不具組織上下文。但如有需要,可與組織角色 (Organization roles) 搭配使用,提供額外的上下文。若要保護組織層級 API,請參閱 [保護組織層級 API 資源](/authorization/organization-level-api-resources)。 +- **與組織層級權限分離:** 全域 API 資源 (API resources) 不具組織上下文。但如有需要,也可與組織角色 (Roles) 搭配,提供額外的上下文層。若要保護組織層級 API,請參閱 [保護組織層級 API 資源 (API resources)](/authorization/organization-level-api-resources)。 全域 API 資源 RBAC -### 實作概覽 \{#implementation-overview} +### 實作流程總覽 \{#implementation-overview} -1. **註冊你的 API 資源 (API resource)**,並在 Logto 中定義其權限。 +1. **註冊你的 API 資源 (API resource)** 並在 Logto 中定義其權限。 2. **定義角色 (Roles)**,並賦予存取 API 所需的權限。 3. **指派角色 (Roles)** 給使用者或用戶端。 4. **使用 OAuth 2.0 授權流程** 取得 API 的存取權杖 (Access token)(resource 參數必須與註冊的 API 標識符一致)。 -5. **在你的 API 中驗證存取權杖**,以強制執行權限。 +5. **在 API 端驗證存取權杖 (Access token)**,以強制執行權限控管。 ### 認識資源標示符 (Resource indicators) \{#understanding-resource-indicators} -Logto 依據 [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html) 建模 API 資源。**資源標示符 (Resource indicator)** 是唯一識別目標 API 或服務的 URI。 +Logto 依據 [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html) 建模 API 資源 (API resources)。**資源標示符 (Resource indicator)** 是唯一識別目標 API 或服務的 URI。 **重點說明** -- 資源標示符必須是絕對 URI(如 `https://api.example.com`) +- 資源標示符必須為絕對 URI(如 `https://api.example.com`) - 不可包含 fragment 元件;盡量避免使用查詢字串。 - 資源標示符可實現受眾限制權杖 (Audience-restricted tokens) 與多 API 架構支援。 @@ -60,14 +60,14 @@ Logto 依據 [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-edito ### 授權流程:驗證 (Authentication) 並保護你的 API \{#authorization-flow-authenticating-and-securing-your-api} -下列流程適用於互動式使用者驗證(瀏覽器 / 應用程式)與後端機器對機器 (M2M) 情境。 +下方流程適用於互動式使用者驗證(瀏覽器 / 應用程式)與後端機器對機器 (M2M) 情境。 -請注意,流程未詳列所有必要參數或標頭,僅聚焦於主要步驟。繼續閱讀可了解實際運作方式。 +請注意,流程未詳列所有必要參數或標頭,僅聚焦於主要步驟。繼續閱讀可瞭解實際運作方式。 ```mermaid sequenceDiagram participant Client as 用戶端 (Client) - participant Logto as Logto + participant Logto participant API as API 資源 (API resource) alt 使用者驗證 (User authentication) @@ -87,7 +87,7 @@ sequenceDiagram Logto->>Client: 回傳存取權杖 (Access token, JSON Web Token) Client->>API: 以 Bearer token 請求 - API->>API: 驗證存取權杖 + API->>API: 驗證存取權杖 (Access token) alt 權杖有效 API->>Client: 回傳受保護資源資料 @@ -106,33 +106,33 @@ _使用者驗證 = 瀏覽器 / 應用程式。M2M = 使用 client credentials ### 註冊你的 API 資源 (API resources) \{#register-your-api-resources} -1. 前往 Console → API resources。 -2. 建立新的 API 資源(如 `https://api.yourapp.com/org`),並定義其權限(scopes)。 +1. 前往 主控台 → API 資源 (API resources)。 +2. 建立新的 API 資源(如 `https://api.yourapp.com/org`),並定義其權限(Scopes)。 -完整設定步驟請參閱 [定義帶權限的 API 資源](/authorization/role-based-access-control#define-api-resources-with-permissions)。 +完整設定步驟請參閱 [定義具權限的 API 資源 (API resources)](/authorization/role-based-access-control#define-api-resources-with-permissions)。 ### 設定全域角色 (Roles) \{#set-up-global-roles} -1. 前往 Console → Roles。 +1. 前往 主控台 → 角色 (Roles)。 2. 建立對應 API 權限的角色(如 `read:products`、`write:products`)。 3. 將這些角色指派給需要存取 API 的使用者或用戶端。 -完整設定步驟請參閱 [使用全域角色](/authorization/role-based-access-control#configure-global-roles)。 +完整設定步驟請參閱 [使用全域角色 (Roles)](/authorization/role-based-access-control#configure-global-roles)。 -### 取得全域 API 資源的存取權杖 (Access tokens) \{#obtain-access-tokens-for-global-api-resources} +### 取得全域 API 資源 (API resources) 的存取權杖 (Access tokens) \{#obtain-access-tokens-for-global-api-resources} -在存取全域 API 資源前,你的用戶端必須先取得存取權杖。Logto 會針對全域 API 資源簽發 [JSON Web Token (JWT)](https://auth.wiki/jwt) 作為存取權杖。這通常透過 [OAuth 2.0 授權碼流程](https://auth.wiki/authorization-code-flow)、[重新整理權杖流程 (refresh token flow)](https://auth.wiki/refresh-token) 或 [client credentials 流程](https://auth.wiki/client-credentials-flow) 完成。 +在存取全域 API 資源 (API resources) 前,你的用戶端必須先取得存取權杖 (Access token)。Logto 會針對全域 API 資源 (API resources) 發行 [JSON Web Token (JWT)](https://auth.wiki/jwt) 作為存取權杖。這通常透過 [OAuth 2.0 授權碼流程 (authorization code flow)](https://auth.wiki/authorization-code-flow)、[重新整理權杖流程 (refresh token flow)](https://auth.wiki/refresh-token) 或 [client credentials 流程](https://auth.wiki/client-credentials-flow) 完成。 #### 授權碼或重新整理權杖流程 \{#authorization-code-or-refresh-token-flow} -所有 Logto 官方 SDK 均原生支援使用重新整理權杖流程取得全域 API 資源的存取權杖。你也可使用標準 OAuth 2.0 / OIDC 用戶端函式庫實作此流程。 +所有 Logto 官方 SDK 均原生支援使用重新整理權杖流程取得全域 API 資源 (API resources) 的存取權杖 (Access token)。你也可以使用標準 OAuth 2.0 / OIDC 用戶端函式庫實作此流程。 -初始化 Logto client 時,將資源標示符加入 `resources` 參數(陣列),再將所需權限(scopes)加入 `scopes` 參數。 +初始化 Logto 用戶端時,將資源標示符 (Resource indicator) 加入 `resources` 參數(陣列),再將所需權限(Scopes)加入 `scopes` 參數。 -使用者驗證後,請在請求存取權杖時(如呼叫 `getAccessToken()`)傳入資源標示符於 `resource` 參數或同名參數。 +使用者驗證後,請在請求存取權杖 (Access token) 時,於 `resource` 參數或同名參數傳入資源標示符(如呼叫 `getAccessToken()`)。 各 SDK 詳細用法請參閱 [快速入門](/quick-starts)。 @@ -147,13 +147,13 @@ _使用者驗證 = 瀏覽器 / 應用程式。M2M = 使用 client credentials -使用者驗證後,你會收到授權碼。請將此授權碼透過 POST 請求交換存取權杖,請求 Logto 的 `/oidc/token` 端點,並在請求主體中包含 `resource` 參數。 +使用者驗證後,你會取得授權碼。將此授權碼透過 POST 請求傳送至 Logto 的 `/oidc/token` 端點,並在請求主體中包含 `resource` 參數,以換取存取權杖 (Access token)。 以下為使用授權碼 grant type 的權杖請求非正式範例: -你也可以使用 `refresh_token` grant type,在請求中包含 `resource` 參數,即可無需使用者互動取得新存取權杖。 +你也可以使用 `refresh_token` grant type,在請求中包含 `resource` 參數,即可於無需使用者互動下取得新存取權杖 (Access token)。 以下為使用重新整理權杖 grant type 的權杖請求非正式範例: @@ -164,7 +164,7 @@ _使用者驗證 = 瀏覽器 / 應用程式。M2M = 使用 client credentials #### Client credentials 流程 \{#client-credentials-flow} -針對機器對機器 (M2M) 情境,你可以使用 client credentials 流程取得全域 API 資源的存取權杖。只需對 Logto 的 `/oidc/token` 端點發送 POST 請求,並使用你的 client ID 與 secret。 +針對機器對機器 (M2M) 情境,你可以使用 client credentials 流程取得全域 API 資源 (API resources) 的存取權杖 (Access token)。只需對 Logto 的 `/oidc/token` 端點發送 POST 請求,並使用你的 client ID 與 secret。 請在請求中包含兩個關鍵參數: @@ -178,50 +178,50 @@ _使用者驗證 = 瀏覽器 / 應用程式。M2M = 使用 client credentials scope="read:products write:products" /> -### 在你的 API 中驗證 JWT 存取權杖 \{#validating-jwt-access-tokens-in-your-api} +### 在 API 端驗證 JWT 存取權杖 (Access tokens) \{#validating-jwt-access-tokens-in-your-api} -Logto 簽發的 JWT 內含宣告 (Claims),你的 API 可據此執行授權 (Authorization)。 +Logto 發行的 JWT 內含宣告 (Claims),你的 API 可據此執行授權 (Authorization)。 -當你的 API 收到帶有 Logto 簽發存取權杖的請求時,應: +當 API 收到帶有 Logto 發行的存取權杖 (Access token) 的請求時,應: - 驗證權杖簽章(使用 Logto 的 JWKs)。 - 確認權杖未過期(`exp` 宣告)。 -- 檢查 `iss`(簽發者)是否符合你的 Logto 端點。 -- 確認 `aud`(受眾)是否符合你註冊的 API 資源標示符(如 `https://api.yourapp.com`)。 +- 檢查 `iss`(簽發者)是否與你的 Logto 端點一致。 +- 確認 `aud`(受眾)是否與你註冊的 API 資源標示符一致(如 `https://api.yourapp.com`)。 - 拆解 `scope` 宣告(以空格分隔),檢查是否具備所需權限。 -各語言詳細教學請參閱 [如何驗證存取權杖](/authorization/validate-access-tokens)。 +各語言詳細教學請參閱 [如何驗證存取權杖 (Access tokens)](/authorization/validate-access-tokens)。 ### 選用:處理使用者權限變更 \{#optional-handle-user-permission-change} :::info -👷 功能開發中 🚧 +👷 功能開發中。🚧 ::: ## 最佳實踐與安全建議 \{#best-practices-and-security-tips} - **權限設計以業務為導向:** 使用能對應實際操作的清楚名稱。 - **縮短權杖有效期:** 若權杖外洩可降低風險。 -- **限制授予的權限範圍 (Scopes):** 僅給予權杖實際所需權限。 -- **使用受眾限制:** 一定要驗證 `aud` 宣告,避免權杖被濫用。 +- **限制授予的權限範圍 (Scopes):** 權杖僅給予實際所需權限。 +- **使用受眾限制 (Audience restriction):** 務必驗證 `aud` 宣告,避免權杖被濫用。 ## 常見問題 \{#faqs}
-### 如果我的用戶端不支援 resource 參數怎麼辦? \{#what-if-my-client-doesn-t-support-the-resource-parameter} +### 如果我的用戶端不支援 resource 參數怎麼辦?\{what-if-my-client-doesn-t-support-the-resource-parameter} \{#what-if-my-client-doesn-t-support-the-resource-parameter} -請在 Logto Console 設定預設 API 資源。當權杖請求未指定 resource 參數時,權杖將預設指向此受眾 (Audience)。 +請在 Logto 主控台設定預設 API 資源。當權杖請求未指定 resource 參數時,將預設使用此受眾。
-### 為什麼我的 API 回傳 401 Unauthorized? \{#why-do-i-get-401-unauthorized-from-my-api} +### 為什麼我的 API 回傳 401 Unauthorized?\{why-do-i-get-401-unauthorized-from-my-api} \{#why-do-i-get-401-unauthorized-from-my-api} @@ -230,18 +230,48 @@ Logto 簽發的 JWT 內含宣告 (Claims),你的 API 可據此執行授權 (Au - **權杖簽章:** 確認你的後端有正確取得 Logto 的 JWKs - **權杖過期:** 確認權杖未過期(`exp` 宣告) - **受眾 (Audience):** 確認 `aud` 宣告與你註冊的 API 資源標示符一致 -- **所需權限範圍 (Scopes):** 確認權杖的 `scope` 宣告包含必要權限 +- **所需權限範圍 (Scopes):** 確認權杖內含必要權限(`scope` 宣告)
-### 沒有完整用戶端要怎麼測試? \{#how-do-i-test-without-a-full-client} +### 沒有完整用戶端時如何測試?\{how-do-i-test-without-a-full-client} \{#how-do-i-test-without-a-full-client} -可使用 [個人存取權杖 (Personal access token)](/user-management/personal-access-token) 模擬驗證呼叫。這讓你能在未實作完整 OAuth 流程的情況下測試 API 端點。 +可使用 [個人存取權杖 (Personal access token)](/user-management/personal-access-token) 模擬驗證呼叫。這讓你無需在用戶端應用程式實作完整 OAuth 流程即可測試 API 端點。 + +
+ +
+ + +### 請求權限時可以用 scope 前綴或簡寫嗎?\{can-i-use-scope-prefixes-or-shortened-versions} \{#can-i-use-scope-prefixes-or-shortened-versions} + + + +不行。Scope 名稱必須**完全符合**你在 API 資源 (API resource) 中定義的權限名稱。前綴或簡寫無法作為萬用字元。 + +**範例:** + +若你的 API 資源 (API resource) 定義了: + +- `read:elections` +- `write:elections` + +你必須請求: + +```swift +scopes: ["read:elections", "write:elections"] +``` + +這樣**無法運作**: + +```swift +scopes: ["read", "write"] // ❌ 不符合權限名稱 +```
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx index 5fc00f31557..a178822e2ec 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/localized-languages.mdx @@ -2,40 +2,40 @@ sidebar_position: 4 --- -# 多語系在地化 +# 在地化語言 -Logto 支援多種預設語言,並提供 113 個額外語言標籤。這個強大的工具讓你能夠自訂登入體驗,建立並管理你自己的語言選項與翻譯內容。 +Logto 支援多種預設語言,並提供 113 個額外的語言標籤。這個強大的工具讓你能夠自訂登入體驗,建立並管理你自己的語言選項與翻譯內容。 ## 在 Logto Console 中的自訂步驟 \{#customization-steps-in-logto-console} -你可以在 Logto Console 輕鬆自訂語言設定,無需撰寫程式碼。 +你可以在 Logto Console 中輕鬆自訂語言設定,無需撰寫程式碼。 -1. **前往**:Console > 登入體驗 (Sign-in experience) > 內容 (Content) > 語言 (Languages)。 +1. **前往**:Console > 登入體驗 > 內容 > 語言。 2. **管理語言**:點擊「管理語言」按鈕以進入你的語言庫。 - **編輯現有語言**:自訂 Logto 提供語言的翻譯。這些語言無法刪除,但你的變更會覆蓋預設值。 - **新增語言**:點擊「新增語言」按鈕,選擇語言標籤,填寫你的翻譯內容,儲存後即可新增語言。 -3. **啟用自動偵測**:啟用後,登入頁面會根據使用者裝置設定,自動顯示其偏好的語言。 +3. **啟用自動偵測**:啟用後,登入頁面會根據使用者裝置設定,自動顯示為偏好的語言。 4. **設定預設語言**:你可以從語言庫中選擇一個預設語言。當偵測到的使用者語言不在目前語言庫時,將會使用預設語言。 -管理語言時,以下是一些關鍵術語的說明: +管理語言時,以下是一些重要術語: -| 定義 | 說明 | -| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------- | -| 語言標籤 (Language tag) | 語言標籤用於識別內容所屬語言。語言標籤由語言代碼(如 en、fr、zh)與國家/地區代碼(如 US、UK、KR)以連字號分隔組成。例如:en-US。 | -| Logto 提供語言 | Logto 提供語言為 Logto 官方語言,儲存在 Logto 原始碼中。 | -| 新增語言 | 新增語言是由使用者自行新增的語言。 | -| Logto 原始值 | Logto 原始值為尚未被使用者自訂的 Logto 預設內容。 | -| 自訂值 | 自訂值為已被使用者自訂的內容,將會覆蓋 Logto 原始值。 | +| 定義 | 說明 | +| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | +| 語言標籤 (Language tag) | 語言標籤用於識別內容的語言。語言標籤由語言代碼(如 en、fr、zh)和國家/地區代碼(如 US、UK、KR)以連字號分隔組成。例如:en-US。 | +| Logto 提供語言 | Logto 提供語言是 Logto 官方語言,儲存在 Logto 原始碼中。 | +| 新增語言 (Added language) | 新增語言是由使用者自行新增的語言。 | +| Logto 原始值 (Logto source values) | Logto 原始值是尚未被使用者自訂的 Logto 預設值。 | +| 自訂值 (Custom values) | 自訂值是已被使用者自訂過的內容,會覆蓋 Logto 原始值。 | ## 使用 Management API 進行自訂 \{#customization-using-management-api} -你可以透過 Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) 來自訂語言翻譯。API 請求主體是一個部分語系物件,例如: +你可以使用 Management API [PUT /api/custom-phrases/\{languageTag\}](https://openapi.logto.io/operation/operation-replacecustomphrase) 來自訂語言翻譯。API 請求主體是一個部分的 locale 物件,例如: ```json { "input": { "username": "Username", "password": "Password" }, "secondary": { - "social_bind_with": "已經有帳號?登入以將 {{methods, list(type: disjunction;)}} 與你的社交身分連結。" + "social_bind_with": "已經有帳號了嗎?登入以將 {{methods, list(type: disjunction;)}} 與你的社交身分連結。" }, "action": { "sign_in": "登入" }, "error": { @@ -54,25 +54,25 @@ Logto 支援多種預設語言,並提供 113 個額外語言標籤。這個強 ## 執行時語言解析邏輯 \{#runtime-language-resolution} -執行時,登入體驗的語言解析優先順序如下: +在執行時,登入體驗的語言解析優先順序如下: 1. 來自當前驗證請求的 `ui_locales` OIDC 參數(使用第一個支援的標籤)。詳見 [ui_locales](/end-user-flows/authentication-parameters/ui-locales)。 2. 若未指定,且已啟用「自動偵測」,則使用偵測到的使用者端語言(例如 HTTP `Accept-Language` 標頭)。 3. 若仍未命中,則使用登入體驗中的租戶預設語言。 -此解析邏輯同樣影響互動觸發的郵件在地化。詳見:[郵件範本在地化](/connectors/email-connectors/email-templates#email-template-localization)。 +此解析邏輯同樣影響互動過程中觸發的郵件本地化。進一步了解:[郵件範本在地化](/connectors/email-connectors/email-templates#email-template-localization)。 ## 使用情境 \{#use-cases} 新增語言會如何呈現給終端客戶? -假設你有一個網站,預設語言為英文且已開啟自動偵測。一位來自日本的使用者造訪並決定註冊帳號。如果他/她的應用程式語言設為日文,但 Logto 尚未支援該語言,登入畫面將會顯示英文。 +假設你有一個網站,預設語言為英文且已開啟自動偵測。一位來自日本的使用者造訪並決定註冊帳號。如果他/她的應用程式語言設為日文,但 Logto 尚未支援該語言,登入畫面將顯示為英文。 -Logto 登入體驗 i18n 讓自訂語言成為可能。 +Logto 登入體驗的 i18n 讓自訂語言成為可能。 點擊 `ja` 語言標籤即可新增你自己的日文翻譯。 -如此一來,來自日本的使用者就能看到你剛從英文翻譯過來的日文內容。 +如此一來,來自日本的使用者就能看到你從英文翻譯過來的日文內容。 ## 常見問題 \{#faqs} @@ -83,7 +83,7 @@ Logto 登入體驗 i18n 讓自訂語言成為可能。 -在語言標籤左側會出現 Logto 提供標記,你新增的語言將無法再移除。你修改過的內容仍會生效並覆蓋原本的 Logto 值。若要使用 Logto 預設設定,請清除你自訂的內容。 +在左側語言標籤旁會出現 Logto 提供標記,且你新增的語言將無法再移除。你修改過的內容仍會生效並覆蓋原本的 Logto 值。若要恢復 Logto 預設值,只需清除使用者自訂內容即可。 @@ -95,7 +95,20 @@ Logto 登入體驗 i18n 讓自訂語言成為可能。 最終使用者看到的內容是兩欄合併的結果。 -假設你只想調整 Logto 原始內容中的部分文案,則你的註冊畫面與 Logto 預設畫面的差異僅在於你編輯過的鍵值,其餘內容將維持不變。 +假設你只想調整 Logto 原始內容中的部分文案,則你的註冊畫面與 Logto 預設畫面的差異僅在於你編輯過的 key,其餘內容將保持不變。 + + + +
+ + +### 如何為登入體驗設定預設手機國碼? \{#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience} + + + +[登入體驗](/end-user-flows/sign-up-and-sign-in/sign-up)中的手機國碼預設會根據使用者瀏覽器語系設定。例如,若使用者瀏覽器語言為 `fr`,則國碼預設為法國(+33)。 + +若需針對特定使用者或地區以程式方式控制預設國碼,可使用 [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 驗證參數。例如,設定 `ui_locales=ja` 時,國碼將預設為日本(+81)。
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx index e9959c3558b..efcdb6257c8 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/customization/match-your-brand.mdx @@ -2,63 +2,67 @@ sidebar_position: 1 --- -# 契合你的品牌 +# 符合你的品牌風格 ## 全域登入體驗 (Omni sign-in experience) \{#omni-sign-in-experience} 前往 主控台 > 登入體驗 > 品牌設定,即可自訂登入頁面的外觀與風格。這個區域讓你輕鬆調整關鍵品牌元素。 -**品牌色** +### 品牌色彩 \{#brand-color} 定義登入體驗中主要使用的顏色,包括主按鈕、連結及其他元件。你可以將預設的 Logto 紫色替換為你的品牌色。針對深色模式,也可指定不同的品牌色。 -**公司標誌** +### 公司標誌 \{#company-logo} 標誌會顯示在登入首頁、註冊首頁、載入頁及其他我們擴展的介面上。 - 圖片有一些限制:必須小於 500KB,且格式為 SVG、PNG、JPG、JPEG 或 ICO。 - 若標誌欄位留空,介面上將不顯示標誌。 -- 也可上傳深色模式版本的標誌。 +- 也可以上傳深色模式專用的標誌。 -**網站小圖示 (Favicon)** +### Favicon \{#favicon} Favicon 是代表網站的小圖示,會顯示在瀏覽器分頁、書籤及其他瀏覽器介面區域。 - 圖片必須小於 500KB,且格式為 SVG、PNG、JPG、JPEG 或 ICO。建議上傳正方形圖片以確保良好呈現效果。 -- 也可上傳深色模式版本的 favicon。 +- 也可上傳深色模式專用的 favicon。 - 此外,不同流程(登入 / 註冊 / 忘記密碼等)現在會顯示對應的瀏覽器標題,而非自訂標題。 -**深色模式 (Dark mode)** +### 深色模式 \{#dark-mode} 啟用深色模式後,登入頁面會根據使用者系統偏好自動調整外觀。 +### 隱藏 Logto 品牌 \{#hide-logto-branding} + +預設情況下,現成的登入體驗頁面會在底部顯示「Powered by Logto」。啟用「隱藏 Logto 品牌」選項,即可移除 Logto 標記,打造專屬於你品牌、乾淨且專業的登入體驗。 + ## 應用程式專屬品牌設定 (App-specific branding) \{#app-specific-branding} -若你的多應用程式業務需要應用程式層級的登入體驗,可在應用程式詳情頁進行設定。前往 主控台 > 應用程式。 +如果你的多應用程式業務需要應用層級的登入體驗,可在應用程式詳細頁進行設定。前往 主控台 > 應用程式。 -開啟「應用程式層級登入體驗」後,你可以為每個應用程式設定專屬品牌標誌、favicon、顏色,甚至 [自訂 CSS](/customization/custom-css)。當從啟用應用程式層級品牌設定的應用程式發起登入時,登入體驗將依據該應用程式的品牌設定自訂;否則將回退至預設的全域登入體驗設定。 +開啟「應用層級登入體驗」後,你可以為每個應用程式分別設定品牌標誌、favicon、色彩,甚至 [自訂 CSS](/customization/custom-css)。當從啟用應用層級品牌的應用程式發起登入時,登入體驗會依據應用層級品牌設定進行自訂;否則將回退至預設的全域登入體驗設定。 -應用程式層級品牌設定同時支援明亮與深色模式。深色模式設定僅在 [全域登入體驗](#omni-sign-in-experience) 啟用深色模式時生效。 +應用層級品牌設定同時支援明亮與深色模式。深色模式設定僅在 [全域登入體驗](#omni-sign-in-experience) 啟用深色模式時生效。 ## 組織專屬品牌設定 (Organization-specific branding) \{#organization-specific-branding} -若要在登入體驗中動態顯示客戶組織標誌,可在組織設定頁上傳組織標誌。前往 主控台 > 組織。 +若需在登入體驗中動態顯示客戶組織標誌,可於組織設定頁上傳組織標誌。前往 主控台 > 組織。 -開啟「組織層級登入體驗」後,與應用程式層級品牌設定類似,你也可以為每個組織設定專屬品牌標誌、favicon、顏色及 [自訂 CSS](/customization/custom-css)。 +開啟「組織層級登入體驗」後,與應用層級品牌設定類似,你也可以為每個組織分別設定品牌標誌、favicon、色彩及 [自訂 CSS](/customization/custom-css)。 -接著,觸發登入時,你可以在 `organization_id` 參數中傳遞組織 ID,告訴 Logto 要顯示哪個組織的標誌。例如,若要顯示組織 ID 為 `123456` 的組織標誌: +接著,在觸發登入時,你可以於 `organization_id` 參數中傳入組織 ID,告訴 Logto 要顯示哪個組織的標誌。例如,若要顯示組織 ID 為 `123456` 的組織標誌: -- 若你使用 Logto SDK,可在 `signIn` 方法的 `extraParams` 物件中傳遞 `organization_id` 參數。 -- 若你使用 OIDC client,可在請求 [授權端點 (authorization endpoint)](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 時傳遞 `organization_id` 參數。 +- 若你使用 Logto SDK,可在 `signIn` 方法的 `extraParams` 物件中傳入 `organization_id` 參數。 +- 若你使用 OIDC client,可在請求 [授權端點 (authorization endpoint)](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 時傳入 `organization_id` 參數。 組織層級品牌設定同時支援明亮與深色模式。深色模式設定僅在 [全域登入體驗](#omni-sign-in-experience) 啟用深色模式時生效。 :::note -若同時啟用應用程式層級品牌設定與組織層級品牌設定,將以組織層級品牌設定為優先。完整優先順序如下: -組織層級品牌設定 -> 應用程式層級品牌設定 -> 全域登入體驗 +若同時啟用應用層級品牌與組織層級品牌,將以組織層級品牌優先。完整優先順序為: +組織層級品牌 → 應用層級品牌 → 全域登入體驗 ::: -以下為使用 [Logto browser SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out) 在 `signIn` 方法中傳遞 `organization_id` 參數的範例: +以下為使用 [Logto browser SDK](/quick-starts/vanilla-js/#implement-sign-in-and-sign-out) 在 `signIn` 方法中傳入 `organization_id` 參數的範例: **index.ts** @@ -74,7 +78,7 @@ logtoClient.signIn({ :::note -我們正逐步將 `extraParams` 功能推廣至所有 Logto SDK。如你的 SDK 尚未支援,請聯絡我們。 +我們正逐步將 `extraParams` 功能推廣至所有 Logto SDK。如果你尚未在 SDK 中看到此功能,請聯絡我們。 ::: diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx index 2ba6a9989b4..a7c05c7a2e6 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/account-settings/by-account-api.mdx @@ -3,18 +3,18 @@ description: 瞭解如何使用 Account API 管理使用者 sidebar_position: 1 --- -# 透過 Account API 管理帳號設定 +# 透過 Account API 管理帳戶設定 ## 什麼是 Logto Account API \{#what-is-logto-account-api} -Logto Account API 是一組完整的 API,讓終端使用者可以直接透過 API 存取帳號,而無需經過 Management API。重點如下: +Logto Account API 是一套完整的 API,讓終端使用者可直接透過 API 存取帳戶,而無需經過 Management API。重點如下: -- 直接存取:Account API 讓終端使用者能直接存取並管理自己的帳號資料,無需透過 Management API 中繼。 -- 使用者資料與身分管理:使用者可完整管理個人資料與安全設定,包括更新電子郵件、手機、密碼等身分資訊,以及管理社交連結。MFA 與 SSO 支援即將推出。 -- 全域存取控制:管理員可全域掌控存取設定,並自訂每個欄位。 -- 無縫授權 (Authorization):授權 (Authorization) 更簡單!只需使用 `client.getAccessToken()` 取得 OP (Logto) 的不透明權杖 (Opaque token),並以 `Bearer ` 附加於 Authorization 標頭。 +- 直接存取:Account API 讓終端使用者能直接存取並管理自己的帳戶資料,無需透過 Management API 中繼。 +- 使用者資料與身分管理:使用者可完整管理個人資料與安全設定,包括更新身分資訊(如電子郵件、手機、密碼)及管理社交連結。MFA 與 SSO 支援即將推出。 +- 全域存取控制:管理員可對存取設定進行全域控制,並自訂每個欄位。 +- 無縫授權 (Authorization):授權 (Authorization) 更簡單!只需使用 `client.getAccessToken()` 取得 OP(Logto)用的不透明存取權杖 (Opaque token),並以 `Bearer ` 附加於 Authorization 標頭。 -透過 Logto Account API,你可以打造如個人資料頁等完全整合 Logto 的自訂帳號管理系統。 +透過 Logto Account API,你可以打造如個人資料頁等完全整合 Logto 的自訂帳戶管理系統。 常見應用場景如下: @@ -22,28 +22,28 @@ Logto Account API 是一組完整的 API,讓終端使用者可以直接透過 - 更新使用者資料 - 更新使用者密碼 - 更新使用者身分(包含電子郵件、手機、社交連結) -- 管理 MFA 因子(驗證) +- 管理 MFA 因子(驗證項目) -更多可用 API,請參閱 [Logto Account API Reference](https://openapi.logto.io/group/endpoint-my-account) 與 [Logto Verification API Reference](https://openapi.logto.io/group/endpoint-verifications)。 +想瞭解更多可用 API,請參閱 [Logto Account API 參考文件](https://openapi.logto.io/group/endpoint-my-account) 與 [Logto Verification API 參考文件](https://openapi.logto.io/group/endpoint-verifications)。 :::note -SSO 帳號檢視與帳號刪除功能目前僅能透過 Logto Management API 使用。詳見 [透過 Management API 管理帳號設定](/end-user-flows/account-settings/by-management-api) 以取得實作細節。 +SSO 帳戶檢視與帳戶刪除功能目前僅能透過 Logto Management API 使用。詳見 [透過 Management API 管理帳戶設定](/end-user-flows/account-settings/by-management-api) 的實作細節。 ::: ## 如何啟用 Account API \{#how-to-enable-account-api} -前往 Console > 登入與帳號 > 帳號中心。 +前往 Console > 登入與帳戶 > 帳戶中心。 -Account API 預設為關閉,存取控制也會被鎖定。切換 **啟用 Account API** 來開啟功能。 +Account API 預設為關閉,因此其存取控制設定為鎖定。切換 **啟用 Account API** 以開啟功能。 啟用後,可針對識別資訊、個人資料、第三方權杖存取等欄位設定權限。每個欄位支援 `Off`、`ReadOnly` 或 `Edit`,預設為 `Off`。 1. **安全欄位**: - 包含:主要電子郵件、主要手機、社交身分、密碼、MFA。 - 終端使用者編輯這些欄位前,必須先透過密碼、電子郵件或簡訊驗證身分,取得 10 分鐘有效的驗證紀錄 ID。詳見 [取得驗證紀錄 ID](#get-a-verification-record-id)。 - - 若要使用 WebAuthn Passkey 作為 MFA,請將前端應用程式網域加入 **WebAuthn 相關來源**,讓帳號中心與登入體驗可共用 Passkey。詳見 [連結新 WebAuthn Passkey](#link-a-new-webauthn-passkey)。 + - 若要使用 WebAuthn Passkey 作為 MFA,請將前端應用程式網域加入 **WebAuthn 相關來源**,讓帳戶中心與登入體驗可共用 Passkey。詳見 [連結新的 WebAuthn Passkey](#link-a-new-webauthn-passkey)。 2. **個人資料欄位**: - 包含:使用者名稱、姓名、大頭貼、[profile](/user-management/user-data#profile)(其他標準個人資料屬性)、[自訂資料](/user-management/user-data#custom-data)。 - 終端使用者可直接編輯,無需額外驗證。 @@ -52,7 +52,7 @@ Account API 預設為關閉,存取控制也會被鎖定。切換 **啟用 Acco ## 如何存取 Account API \{#how-to-access-account-api} :::note -為確保存取權杖 (Access token) 具備正確權限,請在 Logto 設定中正確配置對應的權限範圍 (Scopes)。 +為確保存取權杖 (Access token) 具備正確權限,請在 Logto 設定中妥善配置對應的權限範圍 (Scopes)。 例如,`POST /api/my-account/primary-email` API 需配置 `email` 權限範圍;`POST /api/my-account/primary-phone` API 需配置 `phone` 權限範圍。 @@ -61,13 +61,13 @@ import { type LogtoConfig, UserScope } from '@logto/js'; const config: LogtoConfig = { // ...其他選項 - // 根據需求新增適當的權限範圍 + // 根據需求新增合適的權限範圍 (Scopes) scopes: [ - UserScope.Email, // 對應 `{POST,DELETE} /api/my-account/primary-email` API - UserScope.Phone, // 對應 `{POST,DELETE} /api/my-account/primary-phone` API + UserScope.Email, // 用於 `{POST,DELETE} /api/my-account/primary-email` API + UserScope.Phone, // 用於 `{POST,DELETE} /api/my-account/primary-phone` API UserScope.CustomData, // 管理自訂資料 UserScope.Address, // 管理地址 - UserScope.Identities, // 身分與 MFA 相關 API + UserScope.Identities, // 用於身分與 MFA 相關 API UserScope.Profile, // 管理使用者個人資料 ], }; @@ -77,24 +77,24 @@ const config: LogtoConfig = { ### 取得存取權杖 (Access token) \{#fetch-an-access-token} -在應用程式中設定好 SDK 後,可透過 `client.getAccessToken()` 方法取得存取權杖 (Access token)。此權杖為不透明權杖 (Opaque token),可用於存取 Account API。 +在應用程式中設定好 SDK 後,可使用 `client.getAccessToken()` 方法取得存取權杖 (Access token)。此權杖為不透明權杖 (Opaque token),可用於存取 Account API。 若未使用官方 SDK,請在存取權杖請求 `/oidc/token` 時將 `resource` 設為空。 ### 使用存取權杖存取 Account API \{#access-account-api-using-access-token} -與 Account API 互動時,請將存取權杖 (Access token) 以 Bearer 格式(`Bearer YOUR_TOKEN`)放在 HTTP 標頭的 `Authorization` 欄位。 +呼叫 Account API 時,請將存取權杖 (Access token) 以 Bearer 格式(`Bearer YOUR_TOKEN`)放入 HTTP 標頭的 `Authorization` 欄位。 -以下為取得使用者帳號資訊的範例: +以下為取得使用者帳戶資訊的範例: ```bash curl https://[tenant-id].logto.app/api/my-account \ -H 'authorization: Bearer ' ``` -## 管理基本帳號資訊 \{#manage-basic-account-information} +## 管理基本帳戶資訊 \{#manage-basic-account-information} -### 取得使用者帳號資訊 \{#retrieve-user-account-information} +### 取得使用者帳戶資訊 \{#retrieve-user-account-information} 可透過 [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) 端點取得使用者資料。 @@ -114,11 +114,11 @@ curl https://[tenant-id].logto.app/api/my-account \ } ``` -實際回應欄位會依帳號中心設定而異。 +實際回應欄位會依帳戶中心設定而異。 -### 更新基本帳號資訊 \{#update-basic-account-information} +### 更新基本帳戶資訊 \{#update-basic-account-information} -基本帳號資訊包含使用者名稱、姓名、大頭貼、自訂資料及其他個人資料。 +基本帳戶資訊包含使用者名稱、姓名、大頭貼、自訂資料及其他個人資料。 若要更新 **username、name、avatar、customData**,可使用 [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) 端點。 @@ -140,11 +140,11 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/profile \ ## 管理識別資訊與其他敏感資料 \{#manage-identifiers-and-other-sensitive-information} -出於安全考量,Account API 針對涉及識別資訊與敏感資料的操作,需額外授權。 +出於安全考量,Account API 針對涉及識別資訊與其他敏感資料的操作,需額外授權 (Authorization) 驗證。 ### 取得驗證紀錄 ID \{#get-a-verification-record-id} -首先,需取得一組 **驗證紀錄 ID**,有效期限為 10 分鐘(TTL)。此 ID 用於在更新敏感資料前驗證使用者身分。也就是說,使用者只要透過密碼、電子郵件驗證碼或簡訊驗證碼成功驗證身分後,10 分鐘內可更新與驗證 (Authentication) 相關的資料(如識別資訊、憑證、社交帳號連結、MFA)。 +首先,需取得一組 **驗證紀錄 ID**,有效期限為 10 分鐘(TTL)。此 ID 用於在更新敏感資料前驗證使用者身分。也就是說,當使用者透過密碼、電子郵件驗證碼或簡訊驗證碼成功驗證身分後,有 10 分鐘可更新與驗證 (Authentication) 相關的資料,包括識別資訊、憑證、社交帳號連結與 MFA。 取得驗證紀錄 ID 的方式有:[驗證使用者密碼](#verify-the-users-password) 或 [發送驗證碼至使用者電子郵件或手機](#verify-by-sending-a-verification-code-to-the-users-email-or-phone)。 @@ -169,10 +169,10 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/password \ #### 發送驗證碼至使用者電子郵件或手機 \{#verify-by-sending-a-verification-code-to-the-users-email-or-phone} :::note -使用此方式前,需先[設定電子郵件連接器](/connectors/email-connectors/)或[簡訊連接器](/connectors/sms-connectors/),並確保已設定 `UserPermissionValidation` 範本。 +使用此方法前,需先 [設定電子郵件連接器](/connectors/email-connectors/) 或 [簡訊連接器](/connectors/sms-connectors/),並確保已配置 `UserPermissionValidation` 範本。 ::: -以電子郵件為例,請求新驗證碼並取得驗證紀錄 ID: +以電子郵件為例,請求新的驗證碼並取得驗證紀錄 ID: ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code \ @@ -205,7 +205,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v ### 夾帶驗證紀錄 ID 發送請求 \{#send-request-with-verification-record-id} -更新使用者識別資訊時,請在請求標頭加上 `logto-verification-id` 欄位,內容為驗證紀錄 ID。 +更新使用者識別資訊時,請於請求標頭加上 `logto-verification-id` 欄位,內容為驗證紀錄 ID。 ### 更新使用者密碼 \{#update-users-password} @@ -219,13 +219,17 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/password \ --data-raw '{"password":"..."}' ``` +:::tip +如同註冊時設定密碼,透過 Account API 設定的密碼也必須符合你在 Console > 安全性 > 密碼政策 設定的 [密碼政策](/security/password-policy)。若密碼不符政策,Logto 會回傳詳細驗證結果與錯誤訊息。 +::: + ### 更新或連結新電子郵件 \{#update-or-link-new-email} :::note -使用此方式前,需先[設定電子郵件連接器](/connectors/email-connectors/),並確保已設定 `BindNewIdentifier` 範本。 +使用此方法前,需先 [設定電子郵件連接器](/connectors/email-connectors/),並確保已配置 `BindNewIdentifier` 範本。 ::: -更新或連結新電子郵件前,需先驗證電子郵件擁有權。 +更新或連結新電子郵件前,需先驗證該電子郵件的擁有權。 呼叫 [`POST /api/verifications/verification-code`](https://openapi.logto.io/operation/operation-createverificationbyverificationcode) 端點請求驗證碼。 @@ -245,7 +249,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/verification-code/v --data-raw '{"identifier":{"type":"email","value":"..."},"verificationId":"...","code":"..."}' ``` -驗證成功後,呼叫 [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) 更新使用者電子郵件,並將 `verificationId` 設為請求內容的 `newIdentifierVerificationRecordId`。 +驗證成功後,即可呼叫 [`PATCH /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-updateprimaryemail) 更新使用者電子郵件,並將 `verificationId` 作為 `newIdentifierVerificationRecordId` 放入請求內容。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ @@ -255,6 +259,10 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/primary-email \ --data-raw '{"email":"...","newIdentifierVerificationRecordId":"..."}' ``` +:::tip +如同註冊時收集的電子郵件,透過 Account API 連結的電子郵件也必須通過你在 Console > 安全性 > 封鎖清單 設定的 [封鎖清單](/security/blocklist) 驗證。若違反政策,Logto 會拒絕請求並回傳詳細錯誤。 +::: + ### 移除使用者電子郵件 \{#remove-the-users-email} 移除使用者電子郵件可使用 [`DELETE /api/my-account/primary-email`](https://openapi.logto.io/operation/operation-deleteprimaryemail) 端點。 @@ -268,12 +276,12 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/primary-email \ ### 管理手機 \{#manage-phone} :::note -使用此方式前,需先[設定簡訊連接器](/connectors/sms-connectors/),並確保已設定 `BindNewIdentifier` 範本。 +使用此方法前,需先 [設定簡訊連接器](/connectors/sms-connectors/),並確保已配置 `BindNewIdentifier` 範本。 ::: -與更新電子郵件類似,可使用 [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) 端點更新或連結新手機。移除手機則使用 [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) 端點。 +與更新電子郵件類似,可使用 [`PATCH /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-updateprimaryphone) 端點更新或連結新手機;使用 [`DELETE /api/my-account/primary-phone`](https://openapi.logto.io/operation/operation-deleteprimaryphone) 端點移除手機。 -### 連結新社交帳號 \{#link-a-new-social-connection} +### 連結新的社交帳號 \{#link-a-new-social-connection} 連結新社交帳號前,需先透過 [`POST /api/verifications/social`](https://openapi.logto.io/operation/operation-createverificationbysocial) 取得授權網址。 @@ -284,9 +292,9 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/social \ --data-raw '{"connectorId":"...","redirectUri":"...","state":"..."}' ``` -- `connectorId`:對應 [社交連接器](/connectors/social-connectors/)的 ID。 +- `connectorId`:對應 [社交連接器](/connectors/social-connectors/) 的 ID。 - `redirectUri`:使用者授權後的導向網址,需自行架設網頁並接收回呼。 -- `state`:授權後回傳的狀態,為防止 CSRF 攻擊的隨機字串。 +- `state`:授權後回傳的狀態,用於防止 CSRF 攻擊的隨機字串。 回應中會有 `verificationRecordId`,請妥善保存。 @@ -321,30 +329,30 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/identities/[connecto -H 'logto-verification-id: ' ``` -### 連結新 WebAuthn Passkey \{#link-a-new-webauthn-passkey} +### 連結新的 WebAuthn Passkey \{#link-a-new-webauthn-passkey} :::note -請先[啟用 MFA 與 WebAuthn](/end-user-flows/mfa)。 +請先 [啟用 MFA 與 WebAuthn](/end-user-flows/mfa)。 ::: :::note -使用此方式前,需於[帳號中心設定](#how-to-enable-account-api)啟用 `mfa` 欄位。 +使用此方法前,需於 [帳戶中心設定](#how-to-enable-account-api) 啟用 `mfa` 欄位。 ::: **步驟 1:將前端應用程式來源加入相關來源** -WebAuthn Passkey 綁定於特定主機名稱(**Relying Party ID,RP ID**)。僅 RP ID 網域下的應用程式可註冊或驗證該 Passkey。 +WebAuthn Passkey 綁定於特定主機名稱(**Relying Party ID, RP ID**)。僅 RP ID 網域下的應用程式可註冊或驗證該 Passkey。 -由於前端應用程式與 Logto 驗證頁面網域不同,需設定 **相關來源 (Related Origins)** 以允許跨來源 Passkey 操作。 +由於前端應用程式與 Logto 驗證頁面網域不同,需於 **相關來源** 設定允許跨來源 Passkey 操作。 **Logto 如何判斷 RP ID:** - **預設情境**:僅使用 Logto 預設網域 `https://[tenant-id].logto.app`,RP ID 為 `[tenant-id].logto.app` -- **自訂網域**:若設定 [自訂網域](/logto-cloud/custom-domain) 如 `https://auth.example.com`,RP ID 為 `auth.example.com` +- **自訂網域**:若設定 [自訂網域](/logto-cloud/custom-domain)(如 `https://auth.example.com`),RP ID 為 `auth.example.com` **設定相關來源:** -使用 [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) 端點新增前端應用程式來源。例如帳號中心運行於 `https://account.example.com`: +使用 [`PATCH /api/account-center`](https://openapi.logto.io/operation/operation-updateaccountcentersettings) 端點新增前端應用程式來源。例如帳戶中心運行於 `https://account.example.com`: ```bash curl -X PATCH https://[tenant-id].logto.app/api/account-center \ @@ -353,11 +361,21 @@ curl -X PATCH https://[tenant-id].logto.app/api/account-center \ --data-raw '{"webauthnRelatedOrigins":["https://account.example.com"]}' ``` -更多相關來源說明,請參閱 [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) 文件。 +:::note + +WebAuthn 最多支援 5 組唯一 eTLD+1 標籤作為相關來源。eTLD+1(有效頂級網域加一層)為可註冊的網域部分。例如: + +- `https://example.com`、`https://app.example.com`、`https://auth.example.com` 算作 **一** 組標籤(`example.com`) +- `https://shopping.com`、`https://shopping.co.uk`、`https://shopping.co.jp` 也算作 **一** 組標籤(`shopping`) +- `https://example.com` 與 `https://another.com` 算作 **兩** 組標籤 + +若需支援超過 5 個不同網域,請參閱 [Related Origin Requests](https://passkeys.dev/docs/advanced/related-origins/) 文件。 + +::: **步驟 2:請求註冊選項** -使用 [`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) 端點請求註冊新 Passkey。Logto 允許每個帳號註冊多組 Passkey。 +使用 [`POST /api/verifications/web-authn/registration`](https://openapi.logto.io/operation/operation-generatewebauthnregistrationoptions) 端點請求註冊新 Passkey。Logto 允許每個帳戶註冊多組 Passkey。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration \ @@ -377,7 +395,7 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registrat **步驟 3:於本地瀏覽器註冊 Passkey** -以 [`@simplewebauthn/browser`](https://simplewebauthn.dev/) 為例,可用 `startRegistration` 於本地瀏覽器註冊 Passkey。 +以 [`@simplewebauthn/browser`](https://simplewebauthn.dev/) 為例,可用 `startRegistration` 函式於本地瀏覽器註冊 Passkey。 ```ts import { startRegistration } from '@simplewebauthn/browser'; @@ -386,14 +404,14 @@ import { startRegistration } from '@simplewebauthn/browser'; const response = await startRegistration({ optionsJSON: registrationOptions, // 步驟 1 伺服器回傳資料 }); -// 儲存 response 以供後續使用 +// 保存 response 以供後續使用 ``` **步驟 4:驗證 Passkey 註冊** 使用 [`POST /api/verifications/web-authn/registration/verify`](https://openapi.logto.io/operation/operation-verifywebauthnregistration) 端點驗證 Passkey 註冊。 -此步驟會驗證驗證器產生的加密簽章,確保 Passkey 合法產生且傳輸過程未被竄改。 +此步驟會驗證認證器產生的加密簽章,確保 Passkey 合法建立且傳輸過程未遭竄改。 ```bash curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registration/verify \ @@ -402,12 +420,12 @@ curl -X POST https://[tenant-id].logto.app/api/verifications/web-authn/registrat --data-raw '{"payload":"...","verificationRecordId":"..."}' ``` -- `payload`:步驟 2 本地瀏覽器回傳資料 +- `payload`:步驟 2 本地瀏覽器回傳的資料 - `verificationRecordId`:步驟 1 伺服器回傳的驗證紀錄 ID **步驟 5:連結 Passkey** -最後,使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 端點將 Passkey 連結至使用者帳號。 +最後,使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 端點將 Passkey 連結至使用者帳戶。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -417,7 +435,7 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"WebAuthn","newIdentifierVerificationRecordId":"..."}' ``` -- `verification_record_id`:有效驗證紀錄 ID,需先驗證現有因子,詳見 [取得驗證紀錄 ID](#get-a-verification-record-id) +- `verification_record_id`:有效驗證紀錄 ID,需先驗證使用者現有因子,詳見 [取得驗證紀錄 ID](#get-a-verification-record-id) - `type`:MFA 因子類型,目前僅支援 `WebAuthn` - `newIdentifierVerificationRecordId`:步驟 1 伺服器回傳的驗證紀錄 ID @@ -460,7 +478,7 @@ curl -X PATCH https://[tenant-id].logto.app/api/my-account/mfa-verifications/{ve --data-raw '{"name":"..."}' ``` -刪除 Passkey 則使用 [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) 端點: +刪除 Passkey 可使用 [`DELETE /api/my-account/mfa-verifications/{verificationId}`](https://openapi.logto.io/operation/operation-deletemfaverification) 端點: ```bash curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{verificationId} \ @@ -468,14 +486,14 @@ curl -X DELETE https://[tenant-id].logto.app/api/my-account/mfa-verifications/{v -H 'logto-verification-id: ' ``` -### 連結新 TOTP \{#link-a-new-totp} +### 連結新的 TOTP \{#link-a-new-totp} :::note -請先[啟用 MFA 與 TOTP](/end-user-flows/mfa)。 +請先 [啟用 MFA 與 TOTP](/end-user-flows/mfa)。 ::: :::note -使用此方式前,需於[帳號中心設定](#how-to-enable-account-api)啟用 `mfa` 欄位。 +使用此方法前,需於 [帳戶中心設定](#how-to-enable-account-api) 啟用 `mfa` 欄位。 ::: **步驟 1:產生 TOTP 密鑰** @@ -514,7 +532,7 @@ otpauth://totp/YourApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=YourApp **步驟 3:綁定 TOTP 因子** -使用者將密鑰加入驗證器 App 後,需驗證並綁定至帳號。使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 端點綁定 TOTP 因子。 +使用者將密鑰加入驗證器 App 後,需驗證並綁定至帳戶。使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 端點綁定 TOTP 因子。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -524,22 +542,22 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"Totp","secret":"..."}' ``` -- `verification_record_id`:有效驗證紀錄 ID,需先驗證現有因子,詳見 [取得驗證紀錄 ID](#get-a-verification-record-id) +- `verification_record_id`:有效驗證紀錄 ID,需先驗證使用者現有因子,詳見 [取得驗證紀錄 ID](#get-a-verification-record-id) - `type`:必須為 `Totp` - `secret`:步驟 1 產生的 TOTP 密鑰 :::note -每位使用者僅能有一組 TOTP 因子。若已存在 TOTP 因子,新增時會回傳 422 錯誤。 +每位使用者僅能有一組 TOTP 因子。若已存在 TOTP 因子,重複新增會回傳 422 錯誤。 ::: ### 管理備用驗證碼 (Backup codes) \{#manage-backup-codes} :::note -請先[啟用 MFA 與備用驗證碼](/end-user-flows/mfa)。 +請先 [啟用 MFA 與備用驗證碼](/end-user-flows/mfa)。 ::: :::note -使用此方式前,需於[帳號中心設定](#how-to-enable-account-api)啟用 `mfa` 欄位。 +使用此方法前,需於 [帳戶中心設定](#how-to-enable-account-api) 啟用 `mfa` 欄位。 ::: **步驟 1:產生新備用驗證碼** @@ -567,13 +585,13 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications/back - 立即下載或抄寫這些驗證碼 - 妥善保存於安全處 - 每組驗證碼僅能使用一次 -- 這些驗證碼是遺失主要 MFA 方法時的最後救援 +- 這些驗證碼為遺失主要 MFA 方法時的最後救援 -建議以清楚、易於複製的格式顯示,並提供下載選項(如文字檔或 PDF)。 +建議以清楚、易於複製的格式顯示,並提供下載(如文字檔或 PDF)選項。 -**步驟 3:綁定備用驗證碼至帳號** +**步驟 3:綁定備用驗證碼至帳戶** -使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 端點綁定備用驗證碼至帳號。 +使用 [`POST /api/my-account/mfa-verifications`](https://openapi.logto.io/operation/operation-addmfaverification) 端點綁定備用驗證碼至帳戶。 ```bash curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ @@ -583,14 +601,14 @@ curl -X POST https://[tenant-id].logto.app/api/my-account/mfa-verifications \ --data-raw '{"type":"BackupCode","codes":["...","...","..."]}' ``` -- `verification_record_id`:有效驗證紀錄 ID,需先驗證現有因子,詳見 [取得驗證紀錄 ID](#get-a-verification-record-id) +- `verification_record_id`:有效驗證紀錄 ID,需先驗證使用者現有因子,詳見 [取得驗證紀錄 ID](#get-a-verification-record-id) - `type`:必須為 `BackupCode` - `codes`:前一步產生的備用驗證碼陣列 :::note - 每位使用者僅能有一組備用驗證碼。若全部用完,需重新產生並綁定新組。 -- 備用驗證碼不能是唯一 MFA 因子。使用者必須至少啟用一種其他 MFA(如 WebAuthn 或 TOTP)。 +- 備用驗證碼不能是唯一 MFA 因子,必須至少啟用一種其他 MFA(如 WebAuthn 或 TOTP)。 - 每組備用驗證碼僅能使用一次。 ::: diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx index a8ae2645868..e19bb2926aa 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/first-screen.mdx @@ -7,19 +7,19 @@ sidebar_position: 2 一組自訂驗證 (Authentication) 參數,讓你能根據需求調整終端使用者的首頁體驗。 - `first_screen`:指定使用者將看到的第一個畫面。 -- `identifier`:指定登入或註冊表單可接受的識別碼類型。 -- `login_hint`:將使用者的電子郵件地址或使用者名稱預填入識別碼欄位。(這是 OIDC 標準參數) +- `identifier`:指定登入或註冊表單可接受的識別子類型。 +- `login_hint`:自動填入使用者的電子郵件地址或使用者名稱於識別子欄位。(這是 OIDC 標準參數) ## first_screen \{#first_screen} -`first_screen` 參數是決定使用者導向 Logto 登入頁時所見首頁的關鍵參數。預設會顯示通用登入表單。你可以根據應用程式需求,利用此參數自訂首頁。支援的值如下: +`first_screen` 參數是決定使用者導向 Logto 登入頁時所見首頁的關鍵參數。預設會顯示通用登入表單。你可以根據應用程式需求,透過此參數自訂首頁。支援的值如下: -- `sign_in`:顯示登入表單。(預設值) +- `sign_in`(預設):顯示登入表單。 - `register`:顯示註冊表單。 - `reset_password`:顯示重設密碼表單。 - `single_sign_on`:顯示企業級單一登入 (SSO, Single Sign-On) 登入表單。(會要求輸入電子郵件地址以判斷啟用的 SSO 提供者) -- `identifier:sign-in`:顯示特定識別碼登入表單。可透過 `identifier` 參數指定識別碼類型。當你啟用多種識別碼登入方式時特別有用。 -- `identifier:register`:顯示特定識別碼註冊表單。可透過 `identifier` 參數指定識別碼類型。當你啟用多種識別碼註冊方式時特別有用。 +- `identifier:sign-in`:顯示特定識別子登入表單。可透過 `identifier` 參數(選填)指定識別子類型。當你啟用多種識別子登入方式時非常實用。 +- `identifier:register`:顯示特定識別子註冊表單。可透過 `identifier` 參數(選填)指定識別子類型。當你啟用多種識別子註冊方式時非常實用。 首頁參數(First screen parameter) @@ -30,9 +30,13 @@ curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=single_sign_on' ``` +:::tip +首頁將遵循 Console > 登入體驗 (Sign-in experience) 中的設定。你需先啟用所需的驗證 (Authentication) 方法,並設定品牌、條款與隱私政策,以及國際化(i18n)。請注意,僅 `sign-in` 與 `register` 頁面預設會顯示標誌。 +::: + ## identifier \{#identifier} -`identifier` 參數用於指定登入或註冊表單可接受的識別碼類型。此參數僅適用於 `first_screen` 設為 `identifier:sign-in`、`identifier:register` 或 `reset_password` 時。支援的值有:`username`、`email` 和 `phone`。如需支援多種識別碼類型,請以空格分隔多個值。 +`identifier` 參數用於指定登入或註冊表單可接受的識別子類型。此參數僅適用於 `first_screen` 設為 `identifier:sign-in`、`identifier:register` 或 `reset_password` 時。支援的值有:`username`、`email`、`phone`。如需多種識別子,請以空格分隔。 例如,直接將使用者導向電子郵件或手機號碼註冊頁: @@ -41,15 +45,15 @@ curl --location \ --request GET 'https://.logto.app/oidc/auth?client_id=&...&first_screen=identifier:register&identifier=email phone' ``` -你在此參數中指定的所有識別碼類型,必須已在 Logto Console 的登入或註冊設定中啟用。 +你必須在 Logto Console 的登入或註冊設定中啟用所有於此參數指定的識別子類型。 -任何不支援或未啟用的識別碼類型將被忽略。若所有指定識別碼皆不支援,則會使用預設登入體驗設定。 +任何不支援或未啟用的識別子類型將被忽略。若所有指定識別子皆不支援,則會使用預設登入體驗設定。 ## login_hint \{#login_hint} -`login_hint` 參數定義於 [OpenID Connect 標準規範](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint),用於預先填入使用者的識別碼(如電子郵件、手機號碼或使用者名稱)於登入表單。結合 Logto 其他登入畫面參數,可提升使用者體驗。此參數特別適合你有自訂前置驗證 (Authentication) 表單,預先收集使用者識別碼時,讓使用者在登入時免於重複輸入。 +`login_hint` 參數定義於 [OpenID Connect 標準規範](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint),用於預先填入登入表單的使用者識別子(如電子郵件、手機號碼或使用者名稱)。在 Logto 中,你可將其與其他登入畫面參數結合,提升使用者體驗。此參數特別適合你有自訂預驗證 (Authentication) 表單,預先收集使用者識別子,讓使用者登入時可省略再次輸入。 -例如,將已收集的電子郵件地址預填入登入表單: +例如,預先填入收集到的電子郵件地址於登入表單: ```sh curl --location \ @@ -70,7 +74,7 @@ logtoClient.signIn({ ``` :::note -我們正逐步將 `first_screen`、`identifier` 與 `login_hint` 參數支援加入所有 Logto SDK。如你的 SDK 尚未支援,歡迎提交 issue 或聯絡我們。 +我們正逐步將 `first_screen`、`identifier` 與 `login_hint` 參數支援加入所有 Logto SDK。如你的 SDK 尚未支援,請提交 issue 或聯絡我們。 -對於 [Logto OSS](/logto-oss) 使用者,這些參數自 1.15.0 版起支援。若你使用較舊版本,請[升級](/logto-oss/upgrading-oss-version)至最新版。 +對於 [Logto OSS](/logto-oss) 使用者,這些參數自 1.15.0 版起支援。若你使用舊版本,請[升級](/logto-oss/upgrading-oss-version)至最新版。 ::: diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx index 222fc636a5a..116b425279e 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/authentication-parameters/ui-locales.mdx @@ -2,36 +2,37 @@ sidebar_position: 1 --- -# UI 語言區域 (UI locales) +# UI 語系 (UI locales) Logto 支援標準 OIDC 驗證 (Authentication) 參數 `ui_locales`,用於控制特定互動流程中的登入體驗 (Sign-in experience) 及後續溝通語言。 ## 功能說明 \{#what-it-does} -- 決定 Logto 託管登入體驗 (Sign-in experience) 的 UI 語言。Logto 會於 `ui_locales` 中選擇租戶語言庫支援的第一個語言標籤。 -- 影響互動過程觸發的郵件本地化(例如驗證碼郵件)。詳見 [郵件範本本地化](/connectors/email-connectors/email-templates#email-template-localization)。 -- 將原始值以變數 `uiLocales` 暴露給郵件範本,方便你在郵件主旨/內容中引用。 +- 決定 Logto 託管登入體驗 (Sign-in experience) 的 UI 語言。Logto 會從 `ui_locales` 中選擇租戶語言庫支援的第一個語言標籤。 +- 影響互動過程中觸發的電子郵件本地化(例如驗證碼郵件)。詳見 [電子郵件範本本地化](/connectors/email-connectors/email-templates#email-template-localization)。 +- 將原始值以變數 `uiLocales` 暴露給電子郵件範本,若有需要可在郵件主旨/內容中引用。 +- 設定登入體驗 (Sign-in experience) 中電話號碼預設國碼。例如 `ui_locales=fr` 時,電話欄位預設為法國(+33)。這對於需針對特定用戶群或地區程式化控制預設國碼時特別有用。 ## 參數格式 \{#parameter-format} - 名稱:`ui_locales` - 類型:`string` -- 值:以空格分隔的 BCP 47 語言標籤列表,例如 `fr-CA fr en`。 +- 值:以空格分隔的 BCP 47 語言標籤清單,例如 `fr-CA fr en`。 - 參考:[OpenID Connect Core - ui_locales](https://openid.net/specs/openid-connect-core-1_0.html) ## 決議順序與優先權 \{#resolution-order-and-precedence} -決定登入體驗 (Sign-in experience) 及相關郵件的 UI 語言時,Logto 依下列順序解析終端使用者語言: +Logto 決定登入體驗 (Sign-in experience) 及相關郵件的 UI 語言時,會依下列順序解析終端使用者語言: -1. 目前驗證 (Authentication) 請求中的 `ui_locales`(優先採用第一個支援的標籤)。 -2. 若無,則採用 `Accept-Language` 標頭(使用體驗 (Experience) API/使用者帳號 (Account) API)或 `messagePayload.locale`(如組織邀請等 Management API)。 +1. 當前驗證請求 (Authentication request) 的 `ui_locales`(第一個支援的標籤優先)。 +2. 若無,則使用 `Accept-Language` 標頭(使用體驗 (Experience) API/使用者帳號 (Account) API)或 `messagePayload.locale`(如組織邀請等 Management API)。 3. 若仍無,則採用登入體驗 (Sign-in experience) 設定的租戶預設語言。 -此行為不會永久變更你的語言設定,僅適用於當前互動。 +此行為僅適用於當前互動,不會永久變更你的語言設定。 ## SDK 使用方式 \{#sdk-usage} -若你使用 Logto SDK,請於登入呼叫的 `extraParams` 傳入 `ui_locales`,以便轉發至授權 (Authorization) 請求: +若你使用 Logto SDK,請於登入呼叫的 `extraParams` 傳入 `ui_locales`,以便轉發至授權請求 (Authorization request): ```ts await logtoClient.signIn({ @@ -44,11 +45,11 @@ await logtoClient.signIn({ ## 範例 \{#examples} -- `ui_locales=fr-CA fr en` → 若語言庫中有 `fr-CA`,登入 UI 以加拿大法語顯示;否則依序退回 `fr`、`en`。 +- `ui_locales=fr-CA fr en` → 若語言庫中有 `fr-CA`,登入 UI 將以法語(加拿大)顯示;否則依序退回 `fr`、`en`。 - `ui_locales=ja` 但未啟用日文 → 退回至 `Accept-Language` 或租戶預設語言。 ## 相關連結 \{#related} - [本地化語言](/customization/localized-languages) -- [郵件範本](/connectors/email-connectors/email-templates#email-template-localization) +- [電子郵件範本](/connectors/email-connectors/email-templates#email-template-localization) - [驗證 (Authentication) 參數](/end-user-flows/authentication-parameters) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx index 38ad7517eee..134af8d51a7 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-in.mdx @@ -4,103 +4,104 @@ sidebar_position: 2 # 電子郵件 / 電話 / 使用者名稱登入 -## 設定識別碼登入流程 \{#configure-the-identifier-sign-in-flow} +## 設定識別子登入流程 \{#configure-the-identifier-sign-in-flow} -如前所述,各種識別碼類型可能會在 [註冊流程](/end-user-flows/sign-up-and-sign-in/sign-up) 或 [在 Logto 中直接建立帳戶](/user-management/manage-users#add-users) 時從使用者那裡收集。此外,使用者在探索和使用產品時可能會輸入並完成其他資訊。這些識別碼可用於在 Logto 系統中唯一識別使用者,並允許他們驗證並登入與 Logto 整合的應用程式。 +如前所述,可以在 [註冊流程](/end-user-flows/sign-up-and-sign-in/sign-up) 或 [在 Logto 直接建立帳號](/user-management/manage-users#add-users) 時,從使用者收集各種識別子類型。此外,使用者在探索與使用產品時,也可能輸入並補全額外資訊。這些識別子可用於在 Logto 系統中唯一識別使用者,並允許他們驗證並登入與 Logto 整合的應用程式。 -無論你選擇使用 Logto 提供的預建登入頁面,或計劃 [建立自訂登入 UI](/customization#custom-ui),你都需要為終端使用者設定可用的登入方法和驗證設置。 +無論你選擇使用 Logto 提供的預設登入頁面,還是計劃 [自訂登入 UI](/customization#custom-ui),你都需要為終端使用者設定可用的登入方式與驗證設定。 -## 設定識別碼和驗證設置 \{#set-up-the-identifier-and-authentication-settings} +## 設定識別子與驗證設定 \{#set-up-the-identifier-and-authentication-settings} -### 1. 設定支援的登入識別碼 \{#1-set-the-supported-sign-in-identifiers} +### 1. 設定支援的登入識別子 \{#1-set-the-supported-sign-in-identifiers} -你可以從下拉列表中新增多個支援的識別碼作為終端使用者的啟用登入方法。可用選項有: +你可以從下拉選單新增多個支援的識別子,作為終端使用者可用的登入方式。可用選項包括: -- **使用者名稱** -- **電子郵件地址** -- **電話號碼** +- **使用者名稱 (Username)** +- **電子郵件地址 (Email address)** +- **電話號碼 (Phone number)** -重新排序識別碼將改變它們在登入頁面上的顯示順序。第一個識別碼將是使用者的主要登入方法。 +調整識別子的順序會改變它們在登入頁面上的顯示順序。第一個識別子將成為主要登入方式。 -### 2. 設定驗證設置 \{#2-set-the-authentication-settings} +### 2. 設定驗證設定 \{#2-set-the-authentication-settings} -對於每個登入識別碼,你需要至少設定一個有效的驗證因素來驗證使用者的身分。你可以選擇以下兩個因素: +對於每個登入識別子,你需要設定至少一種有效的驗證因子來驗證使用者身分。你可以選擇以下兩種因子: -- **密碼**:適用於所有類型的登入識別碼。一旦啟用,使用者必須提供密碼才能完成登入流程。 -- **驗證碼**:僅適用於 **電子郵件地址** 和 **電話號碼** 識別碼。一旦啟用,使用者必須輸入發送到其電子郵件或電話號碼的驗證碼才能完成登入流程。 +- **密碼 (Password)**:適用於所有類型的登入識別子。啟用後,使用者必須輸入密碼才能完成登入流程。 +- **驗證碼 (Verification code)**:僅適用於 **電子郵件地址 (Email address)** 與 **電話號碼 (Phone number)** 識別子。啟用後,使用者必須輸入發送到其電子郵件或電話號碼的驗證碼才能完成登入流程。 -如果兩個因素都啟用,使用者可以選擇任一方法來完成登入流程。你也可以重新排序因素以改變它們在登入頁面上的顯示順序。第一個因素將用作使用者的主要驗證方法,第二個將顯示為替代連結。 +若同時啟用兩種因子,使用者可選擇任一方式完成登入。你也可以調整因子的順序,改變它們在登入頁面上的顯示順序。第一個因子將作為主要驗證方式,第二個則以替代連結顯示。 -## 識別碼登入流程使用者體驗 \{#identifier-sign-in-flow-user-experience} +## 識別子登入流程使用者體驗 \{#identifier-sign-in-flow-user-experience} -登入體驗會根據選擇的識別碼和可用的驗證因素進行調整。 +登入體驗會根據所選識別子與可用驗證因子自動調整。 -- **多重識別碼的智能輸入:** - 如果啟用了多個識別碼登入方法,Logto 的內建登入頁面將自動檢測使用者輸入的識別碼類型並顯示相應的驗證選項。例如,如果啟用了 **電子郵件地址** 和 **電話號碼**,登入頁面將自動檢測使用者輸入的識別碼類型並顯示相應的驗證選項。當連續輸入數字時,會切換到帶有區域代碼的電話號碼格式;當使用「@」符號時,則切換到電子郵件格式。 -- **啟用的驗證因素:** - - **僅密碼:** 第一個畫面將顯示識別碼和密碼欄位。 - - **僅驗證碼:** 第一個畫面顯示識別碼欄位,接著在第二個畫面顯示驗證碼欄位。 - - **密碼和驗證碼:** 首先在第一個畫面輸入識別碼,接著根據驗證順序在第二個畫面輸入密碼或驗證碼。提供切換連結以允許使用者在兩種驗證方法之間切換。 +- **多識別子智慧輸入:** + 若啟用多種識別子登入方式,Logto 內建登入頁面會自動偵測使用者輸入的識別子類型,並顯示對應的驗證選項。例如,若同時啟用 **電子郵件地址 (Email address)** 與 **電話號碼 (Phone number)**,登入頁面會自動偵測使用者輸入的識別子類型並顯示對應驗證選項。若連續輸入數字則切換為帶區碼的電話號碼格式,輸入「@」符號則切換為電子郵件格式。 + - 電話號碼國碼預設為使用者瀏覽器語系;使用者可手動切換。你可以使用 [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 參數設定特定預設國碼。詳見 [多語系設定](/customization/localized-languages#how-can-i-set-a-default-phone-number-country-code-for-the-sign-in-experience)。 +- **啟用的驗證因子:** + - **僅密碼 (Password only):** 首頁面同時顯示識別子與密碼欄位。 + - **僅驗證碼 (Verification code only):** 首頁面顯示識別子欄位,下一頁顯示驗證碼欄位。 + - **密碼與驗證碼 (Password and verification code):** 首頁面先輸入識別子,下一頁依驗證順序輸入密碼或驗證碼。頁面提供切換連結,讓使用者選擇驗證方式。 ### 範例 \{#examples}
-### 範例 1:電子郵件地址與密碼驗證 \{#example-1-email-address-with-password-verification} +### 範例 1:電子郵件地址搭配密碼驗證 \{#example-1-email-address-with-password-verification} -新增 **電子郵件地址** 作為登入識別碼,並啟用 **密碼** 因素進行驗證。 +新增 **電子郵件地址 (Email address)** 作為登入識別子,並啟用 **密碼 (Password)** 驗證因子。 -Email address with password verification +電子郵件地址搭配密碼驗證
-### 範例 2:電子郵件 / 電話號碼啟用密碼(主要)和驗證碼(替代)驗證 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} +### 範例 2:電子郵件 / 電話同時啟用密碼(主要)與驗證碼(替代)驗證 \{#example-2-emailphone-with-passwordprimary-and-verification-code-alternative-verification-enabled} -新增 **電子郵件地址** 和 **電話號碼** 作為登入識別碼。 -啟用 **密碼** 和 **驗證碼** 因素以供兩個識別碼使用。 +同時新增 **電子郵件地址 (Email address)** 與 **電話號碼 (Phone number)** 作為登入識別子。 +並為兩者啟用 **密碼 (Password)** 與 **驗證碼 (Verification code)** 驗證因子。 Email/Phone with password and verification code verification
-## 在登入時收集額外的使用者資料 \{#collect-additional-user-profile-on-sign-in} +## 登入時收集額外使用者資料 \{#collect-additional-user-profile-on-sign-in} -在 Logto 的登入流程中,如果註冊識別碼設置更新,可能會觸發資料填充流程。這確保所有使用者,包括現有使用者,提供任何新要求的識別碼。 +在 Logto 的登入流程中,若註冊識別子設定有更新,可能會觸發資料補全流程,確保所有使用者(包含既有使用者)都需補齊新要求的識別子。 -當開發者新增新識別碼(如電子郵件地址)時,這將成為所有使用者的必填項。如果回訪使用者使用現有識別碼(如使用者名稱)登入,且其資料中缺少新識別碼,將提示他們提供並驗證新識別碼。只有完成此步驟後,他們才能訪問應用程式,確保順利且一致地過渡到更新的要求。 +當開發者新增新的識別子(如電子郵件地址)時,所有使用者都必須填寫。若回訪使用者以既有識別子(如使用者名稱)登入,且其資料中缺少新識別子,則會被要求補填並驗證新識別子。完成此步驟後,才能進入應用程式,確保平順且一致地過渡到新規則。 -流程分解: +流程拆解如下: -1. **使用者名稱** 先前設為註冊識別碼,並自動啟用 **建立你的密碼** 設置。 -2. **電子郵件地址** 後來設為註冊識別碼。**電子郵件地址** 識別碼自動新增為啟用的登入選項。 -3. 回訪使用者使用其使用者名稱和密碼登入。 -4. 使用者在初次登入步驟後被提示提供並驗證電子郵件地址。 +1. 先前設定 **使用者名稱 (Username)** 為註冊識別子,並自動啟用 **建立密碼 (Create your password)** 設定。 +2. 之後設定 **電子郵件地址 (Email address)** 為註冊識別子,該識別子會自動新增為啟用的登入選項。 +3. 回訪使用者以使用者名稱與密碼登入。 +4. 使用者登入後會被要求補填並驗證電子郵件地址。 ```mermaid flowchart TD - A[訪問登入頁面] --> B[輸入使用者名稱和密碼] - B -.-> C{{需要且缺少電子郵件地址?}} + A[造訪登入頁面] --> B[輸入使用者名稱與密碼] + B -.-> C{{需要電子郵件地址且尚未填寫?}} C -->|是| D[輸入電子郵件地址] D --> E[輸入驗證碼] - E --> F[成功登入] + E --> F[登入成功] C --> |否| F ``` -同樣的流程也適用於 **建立你的密碼** 註冊設置。如果在註冊流程中新啟用了 **建立你的密碼** 設置,則 **密碼** 因素將自動啟用於你選擇的所有登入識別碼。所有沒有密碼的回訪使用者將在登入過程中被提示建立一個密碼。 +同樣流程也適用於 **建立密碼 (Create your password)** 註冊設定。若在註冊流程中啟用 **建立密碼**,則你選擇的所有登入識別子都會自動啟用 **密碼 (Password)** 驗證因子。所有尚未設定密碼的回訪使用者,登入時都會被要求建立密碼。 :::note -注意:對於自訂登入流程,請參考 [Bring your UI](/customization/bring-your-ui/) 功能。 +注意:如需自訂登入流程,請參考 [自帶 UI (Bring your UI)](/customization/bring-your-ui/) 功能。 ::: ## 常見問題 \{#faqs} @@ -108,16 +109,16 @@ flowchart TD
-### 自託管登入體驗(嵌入式登入) \{#self-hosted-sign-in-experience-embedded-sign-in} +### 自架登入體驗(嵌入式登入) \{#self-hosted-sign-in-experience-embedded-sign-in} -Logto 目前不支援無頭 API 進行登入和註冊。不過,你可以使用我們的 [Bring your UI](/customization/bring-your-ui/) 功能將自訂登入表單上傳到 Logto。我們還支援多個登入參數,你可以用來預填從應用程式收集的使用者識別碼,或直接使用第三方社交或企業級單一登入 (SSO) 提供者進行登入。詳情請參閱 [驗證參數](/end-user-flows/authentication-parameters/)。 +Logto 目前尚未支援 headless API 進行登入與註冊。不過,你可以利用 [自帶 UI (Bring your UI)](/customization/bring-your-ui/) 功能,將自訂登入表單上傳至 Logto。我們也支援多種登入參數,可用於預填從你的應用程式收集的使用者識別子,或直接以第三方社交或企業級單一登入 (SSO) 供應商登入。詳見 [驗證參數 (Authentication parameters)](/end-user-flows/authentication-parameters/)。
## 相關資源 \{#related-resources} -電子郵件註冊和登入體驗 +電子郵件註冊與登入體驗 -使用者名稱註冊和登入體驗 +使用者名稱註冊與登入體驗 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx index 90e6ba3025d..eba2afb13c5 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/sign-up-and-sign-in/sign-up.mdx @@ -4,7 +4,7 @@ sidebar_position: 1 # 電子郵件 / 電話 / 使用者名稱註冊 -使用者註冊是使用者參與你的應用程式的第一步。Logto 支援多種註冊方式,包括使用者名稱密碼、電子郵件或電話號碼驗證、[社交註冊](/end-user-flows/sign-up-and-sign-in/social-sign-in) 以及 [企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso)。你可以根據應用程式需求設定最合適的註冊方式。 +使用者註冊是使用者參與你應用程式的第一步。Logto 支援多種註冊方式,包括使用者名稱密碼、電子郵件或電話號碼驗證、[社交註冊](/end-user-flows/sign-up-and-sign-in/social-sign-in) 以及 [企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso)。你可以根據應用程式需求設定最合適的註冊方式。 前往 控制台 > 登入體驗 > 註冊與登入 開始設定識別碼註冊流程。 @@ -14,41 +14,51 @@ sidebar_position: 1 為了在 Logto 成功建立新使用者帳號,使用者必須提供至少一個能在 Logto 系統中唯一識別他們的 **識別碼**。首先,請選擇使用者在註冊流程中必須提供的識別碼。可用選項如下: -- **使用者名稱**:使用者可用於登入應用程式的唯一 [使用者名稱](/user-management/user-data#username)。 -- **電子郵件地址**:使用者可用於登入應用程式的有效 [電子郵件地址](/user-management/user-data#primary_email)。 -- **電話號碼**:使用者可用於登入應用程式的有效 [電話號碼](/user-management/user-data#primary_phone)。 -- **電子郵件地址或電話號碼**:允許使用者以有效的電子郵件地址或電話號碼註冊。 +- **使用者名稱 (Username)**:使用者可用於登入應用程式的唯一 [使用者名稱](/user-management/user-data#username)。 +- **電子郵件地址 (Email address)**:使用者可用於登入應用程式的有效 [電子郵件地址](/user-management/user-data#primary_email)。 +- **電話號碼 (Phone number)**:使用者可用於登入應用程式的有效 [電話號碼](/user-management/user-data#primary_phone)。 +- **電子郵件地址或電話號碼 (Email address or phone number)**:允許使用者以有效電子郵件地址或電話號碼註冊。 -所有在註冊流程中收集的識別碼,必須在同一租戶下對所有使用者保持唯一。這些識別碼會儲存在 [使用者個人檔案](/user-management/user-data#user-profile) 中,並可用於登入與 Logto 整合的應用程式。 +在註冊過程中收集的所有識別碼,必須在同一租戶下對所有使用者保持唯一。這些識別碼將儲存在 [使用者個人檔案](/user-management/user-data#user-profile) 中,並可用於登入與 Logto 整合的應用程式。 -若未選擇任何識別碼,則適用於僅限 [社交](/end-user-flows/sign-up-and-sign-in/social-sign-in) 或 [企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso) 的註冊方式。 +若未選擇任何識別碼,則適用於僅限 [社交](/end-user-flows/sign-up-and-sign-in/social-sign-in) 或僅限 [企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso) 的註冊方式。 -你可以調整註冊識別碼的順序,以優先讓使用者在註冊時先填寫你想要的識別碼。此順序會反映在註冊流程中,第一個識別碼會出現在初始註冊畫面,其餘則於後續步驟收集。 +你可以調整註冊識別碼的順序,以優先顯示你希望使用者首先填寫的識別碼。此順序會反映在註冊流程中,第一個識別碼會出現在初始註冊畫面,其餘則於後續步驟收集。 + +:::tip +若需在註冊時封鎖特定類型的電子郵件地址(如一次性信箱、帶加號 (+) 的子地址、特定電子郵件或整個網域),請使用安全性區段的 **封鎖清單 (blocklist)** 功能。詳情請參閱 [封鎖清單](/security/blocklist)。 +::: + +:::tip +電話號碼的 **國碼** 會預設為使用者瀏覽器的語系。例如,若使用者瀏覽器語言設定為 `fr`,則國碼預設為法國 (+33)。 + +你也可以使用 [`ui_locales`](/end-user-flows/authentication-parameters/ui-locales) 驗證 (Authentication) 參數設定登入體驗語言,這也會決定預設國碼。 +::: ## 設定註冊驗證設定 \{#set-up-the-sign-up-verification-settings} -為確保使用者註冊及未來登入流程的安全性,你還需要針對註冊時收集的識別碼設定驗證方式。可用設定如下: +為確保使用者註冊及未來登入流程的安全性,你還需針對註冊時收集的識別碼設定驗證機制。可用設定如下: -- **建立密碼**:要求使用者在註冊時建立一組符合你登入體驗設定中密碼政策的密碼。此密碼將與使用者識別碼一同作為登入應用程式的憑證。若你將 **使用者名稱** 設為註冊識別碼,則此需求會自動啟用,因為 **使用者名稱** 只能搭配密碼有效驗證使用者身分。[密碼政策](/security/password-policy) 可依你的安全需求自訂。 -- **註冊時驗證**:要求使用者在註冊時驗證其電子郵件地址或電話號碼。目前,Logto 僅接受已驗證的電子郵件與電話號碼作為識別碼。當 **電子郵件地址** 或 **電話號碼** 作為註冊識別碼時,此設定會自動啟用。使用者必須在註冊流程中輸入發送至其電子郵件或電話號碼的驗證碼,以確認擁有權。 +- **建立密碼 (Create your password):** 要求使用者在註冊時建立符合登入體驗設定中密碼政策的密碼。此密碼將與使用者識別碼一同作為登入應用程式的憑證。若你將 **使用者名稱 (Username)** 設為註冊識別碼,則此需求會自動啟用,因為 **使用者名稱** 只能搭配密碼有效驗證使用者身分。[密碼政策](/security/password-policy) 可自訂以符合你的安全需求。 +- **註冊時驗證 (Verify at sign-up):** 要求使用者在註冊時驗證其電子郵件地址或電話號碼。目前,Logto 僅接受已驗證的電子郵件與電話號碼作為識別碼。當 **電子郵件地址** 或 **電話號碼** 作為註冊識別碼時,此設定會自動啟用。使用者必須在註冊過程中輸入發送至其電子郵件或電話的驗證碼以確認擁有權。 -| 識別碼 | 建立使用者密碼 | 註冊時驗證 | -| ------------------ | -------------- | ---------- | -| 使用者名稱 | 選用 | 不適用 | -| 電子郵件地址 | 選用 | 必要 | -| 電話號碼 | 選用 | 必要 | -| 電子郵件或電話號碼 | 選用 | 必要 | +| 識別碼 | 建立使用者密碼 | 註冊時驗證 | +| ------------------------------------------ | -------------- | ---------- | +| 使用者名稱 (Username) | 選用 | 不適用 | +| 電子郵件地址 (Email address) | 選用 | 必要 | +| 電話號碼 (Phone number) | 選用 | 必要 | +| 電子郵件或電話號碼 (Email or phone number) | 選用 | 必要 | ## 註冊流程範例 \{#sign-up-flow-examples}
-### 類型 1:使用者名稱與密碼建立 \{#type-1-username-with-password-creation} +### 類型 1:使用者名稱搭配密碼建立 \{#type-1-username-with-password-creation} -選擇 **使用者名稱** 作為註冊識別碼。建立密碼會自動啟用。 +選擇 **使用者名稱 (Username)** 作為註冊識別碼。建立密碼會自動啟用。 使用者名稱與密碼註冊 @@ -57,11 +67,11 @@ sidebar_position: 1
-### 類型 2:電子郵件地址或電話號碼驗證流程 \{#type-2-email-address-or-phone-number-with-verification-flow} +### 類型 2:電子郵件地址或電話號碼搭配驗證流程 \{#type-2-email-address-or-phone-number-with-verification-flow} -選擇 **電子郵件地址或電話號碼** 作為註冊識別碼。**註冊時驗證** 強制啟用。 +選擇 **電子郵件地址或電話號碼 (Email address or phone number)** 作為註冊識別碼。**註冊時驗證 (Verify at sign-up)** 會強制啟用。 電子郵件或電話號碼註冊並驗證 @@ -70,11 +80,11 @@ sidebar_position: 1
-### 類型 3:電子郵件地址驗證與密碼建立 \{#type-3-email-address-with-verification-and-password-creation} +### 類型 3:電子郵件地址搭配驗證與密碼建立 \{#type-3-email-address-with-verification-and-password-creation} -選擇 **電子郵件地址** 作為註冊識別碼。**註冊時驗證** 強制啟用。啟用 **建立密碼**,要求使用者在註冊時建立密碼。(電話號碼註冊流程同理) +選擇 **電子郵件地址 (Email address)** 作為註冊識別碼。**註冊時驗證 (Verify at sign-up)** 會強制啟用。啟用 **建立密碼 (Create your password)**,要求使用者在註冊時建立密碼。(電話號碼註冊流程同理) 電子郵件註冊並驗證與密碼建立 @@ -83,11 +93,11 @@ sidebar_position: 1
-### 類型 4:電子郵件驗證、使用者名稱與密碼建立 \{#type-4-email-address-with-verification-username-and-password-creation} +### 類型 4:電子郵件地址搭配驗證、使用者名稱與密碼建立 \{#type-4-email-address-with-verification-username-and-password-creation} -選擇 **電子郵件地址** 與 **使用者名稱** 作為註冊識別碼。**註冊時驗證** 強制啟用。啟用 **建立密碼**,要求使用者在註冊時建立密碼。 +選擇 **電子郵件地址 (Email address)** 與 **使用者名稱 (Username)** 作為註冊識別碼。**註冊時驗證 (Verify at sign-up)** 會強制啟用。啟用 **建立密碼 (Create your password)**,要求使用者在註冊時建立密碼。 控制台 > 登入體驗 > 收集使用者個人資料 設定,可選擇預設基本資料欄位或自訂欄位並彈性驗證。詳見:[收集使用者個人資料](/end-user-flows/collect-user-profile) +透過 控制台 > 登入體驗 > 收集使用者個人檔案 設定,選擇預設基本資料欄位或自訂欄位並彈性驗證。詳情請見:[收集使用者個人檔案](/end-user-flows/collect-user-profile) -**選項 2:自託管導入流程** +**選項 2:自架導入流程** -註冊成功後將使用者導向你自訂的導入流程,以完全自訂資料收集體驗。此方式讓你能完全掌控使用者體驗,並支援複雜、多步驟的導入流程。 +註冊成功後將使用者導向你自訂的導入流程,以完全自訂資料收集體驗。此方式讓你能完全掌控使用者體驗,並支援複雜的多步驟導入流程。 -可透過 [Account API](/end-user-flows/account-settings/by-account-api) 程式化管理使用者個人資料。 +可透過 [Account API](/end-user-flows/account-settings/by-account-api) 程式化管理使用者個人檔案資料。 ## 常見問題 \{#faqs} @@ -144,7 +154,7 @@ sidebar_position: 1 -Logto 目前尚未支援無頭 API 進行登入與註冊。你可以使用 [自帶 UI (Bring your UI)](/customization/bring-your-ui/) 功能將自訂註冊表單上傳至 Logto,或利用登入參數將網站上的使用者資訊帶入 Logto。詳見 [驗證 (Authentication) 參數](/end-user-flows/authentication-parameters/) 以瞭解使用者識別碼帶入方式。 +Logto 目前尚未支援無頭 API 進行登入與註冊。你可以利用 [自帶 UI (Bring your UI)](/customization/bring-your-ui/) 功能將自訂註冊表單上傳至 Logto,或利用登入參數將網站上的使用者資訊帶入 Logto。更多關於使用者識別碼帶入方式,請參閱 [驗證 (Authentication) 參數](/end-user-flows/authentication-parameters/)。
@@ -155,7 +165,7 @@ Logto 目前尚未支援無頭 API 進行登入與註冊。你可以使用 [自 -訂閱 `User.Created` webhook 事件,即可向新使用者發送歡迎郵件。詳見 [Webhook 事件](/developers/webhooks/webhooks-events/#data-mutation-hook-events)。 +訂閱 `User.Created` webhook 事件以觸發向新使用者發送歡迎郵件。詳情請見 [Webhook 事件](/developers/webhooks/webhooks-events/#data-mutation-hook-events)。
@@ -166,8 +176,8 @@ Logto 目前尚未支援無頭 API 進行登入與註冊。你可以使用 [自 -目前 Logto 僅支援已驗證的電子郵件與電話號碼作為識別碼。驗證流程是為了確保使用者識別碼的安全性與擁有權。 -支援未驗證電子郵件或電話號碼已在我們的 [roadmap](https://feedback.logto.io/roadmap) 上,敬請期待! +目前,Logto 僅支援已驗證的電子郵件與電話號碼作為識別碼。驗證流程是為了確保使用者識別碼的安全性與擁有權。 +支援未驗證電子郵件或電話號碼已在我們的 [產品路線圖](https://feedback.logto.io/roadmap) 上,敬請期待!
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 3b379dfdf49..e0076c75cb6 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,148 +1,155 @@ --- -description: 參考 OIDC 驗證整合的關鍵應用程式參數,包括重定向 URI、端點、重新整理權杖、後台登出等。 +description: 參考 OIDC 驗證 (Authentication) 整合的關鍵應用程式參數,包括重導 URI、端點、重新整理權杖 (Refresh token)、後台登出 (Backchannel logout) 等。 sidebar_position: 6 --- # 應用程式資料結構 -## 介紹 \{#introduction} +## 簡介 \{#introduction} -在 Logto 中,_應用程式_ 是指在 Logto 平台上註冊的特定軟體程式或服務,並已獲得授權以存取使用者資訊或代表使用者執行操作。應用程式用於識別向 Logto API 發出的請求來源,並管理使用者存取這些應用程式的驗證 (Authentication) 和授權 (Authorization) 流程。 +在 Logto 中,_應用程式_ 指的是已註冊於 Logto 平台,並獲授權可存取使用者資訊或代表使用者執行操作的特定軟體程式或服務。應用程式用於識別向 Logto API 發出的請求來源,同時管理使用者存取這些應用程式時的驗證 (Authentication) 與授權 (Authorization) 流程。 -在 Logto 的登入體驗中使用應用程式,讓使用者能夠輕鬆地從單一位置存取和管理其授權的應用程式,並提供一致且安全的驗證流程。這有助於簡化使用者體驗,確保只有授權的個人能夠存取敏感資訊或代表組織執行操作。 +在 Logto 的登入體驗 (Sign-in experience) 中使用應用程式,讓使用者能從單一位置輕鬆存取並管理其已授權的應用程式,並享有一致且安全的驗證流程。這有助於簡化使用者體驗,並確保只有經授權的人員能存取敏感資訊或代表組織執行操作。 -應用程式也用於 Logto 的審計日誌中,以追蹤使用者活動並識別任何潛在的安全威脅或漏洞。透過將特定操作與特定應用程式關聯,Logto 可以提供有關資料如何被存取和使用的詳細見解,讓組織更好地管理其安全性和合規性需求。如果你想將應用程式與 Logto 整合,請參閱 [整合 Logto](/integrate-logto)。 +應用程式也用於 Logto 的稽核日誌 (Audit logs) 中,以追蹤使用者活動並識別潛在的安全威脅或違規行為。透過將特定操作與特定應用程式關聯,Logto 能提供資料存取與使用的詳細洞察,協助組織更好地管理安全性與合規需求。 +若你想將應用程式與 Logto 整合,請參閱 [整合 Logto](/integrate-logto)。 ## 屬性 \{#properties} ### 應用程式 ID \{#application-id} -_應用程式 ID_ 是在 Logto 中識別應用程式的唯一自動生成鍵,在 OAuth 2.0 中被稱為 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)。 +_應用程式 ID_ 是用於在 Logto 中識別應用程式的唯一自動產生金鑰,在 OAuth 2.0 中稱為 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)。 ### 應用程式類型 \{#application-types} -_應用程式_ 可以是以下應用程式類型之一: +_應用程式_ 可為下列其中一種類型: -- **原生應用程式** 是在原生環境中運行的應用程式。例如,iOS 應用程式、Android 應用程式。 -- **單頁應用程式 (SPA)** 是在網頁瀏覽器中運行的應用程式,從伺服器獲取新資料時不需重新載入整個頁面。例如,React DOM 應用程式、Vue 應用程式。 -- **傳統網頁應用程式** 是由網頁伺服器單獨渲染和更新頁面的應用程式。例如,JSP、PHP。 -- **機器對機器 (M2M) 應用程式** 是在機器環境中運行的應用程式,用於直接的服務對服務通信,無需使用者互動。 +- **原生應用程式 (Native app)**:運行於原生環境的應用程式。例如 iOS app、Android app。 +- **單頁應用程式 (Single page app)**:運行於網頁瀏覽器中,透過伺服器新資料更新頁面而不需整頁重新載入的應用程式。例如 React DOM app、Vue app。 +- **傳統網頁應用程式 (Traditional web app)**:僅由網頁伺服器渲染與更新頁面的應用程式。例如 JSP、PHP。 +- **機器對機器 (M2M) 應用程式**:運行於機器環境、用於直接服務對服務通訊且無需使用者互動的應用程式。 ### 應用程式密鑰 \{#application-secret} -_應用程式密鑰_ 是用於在驗證系統中驗證應用程式的密鑰,特別是對於私有客戶端(傳統網頁和 M2M 應用程式)作為私有安全屏障。 +_應用程式密鑰_ 是用於驗證 (Authentication) 系統中應用程式身分的金鑰,專為私有用戶端(傳統網頁與 M2M 應用程式)作為私有安全屏障。 + +:::tip +單頁應用程式 (SPA) 與原生應用程式不提供應用程式密鑰。SPA 與原生應用程式屬於「公開用戶端」,無法安全保存密鑰(瀏覽器程式碼或 app bundle 可被檢查)。Logto 以 PKCE、嚴格的重導 URI / CORS 驗證、短效存取權杖 (Access token) 與重新整理權杖 (Refresh token) 輪替來保護這些應用程式。 +::: ### 應用程式名稱 \{#application-name} -_應用程式名稱_ 是應用程式的人類可讀名稱,將顯示在管理控制台中。 +_應用程式名稱_ 是應用程式的人類可讀名稱,會顯示於管理主控台。 -_應用程式名稱_ 是在 Logto 中管理應用程式的重要組成部分,因為它允許管理員輕鬆識別和追蹤平台中各個應用程式的活動。 +_應用程式名稱_ 是 Logto 應用程式管理的重要組成,讓管理員能輕鬆識別並追蹤平台內各應用程式的活動。 :::note -需要注意的是,_應用程式名稱_ 應謹慎選擇,因為它將對所有有權訪問管理控制台的使用者可見。它應準確反映應用程式的目的和功能,同時易於理解和識別。 +請注意,_應用程式名稱_ 應謹慎選擇,因為所有有權存取管理主控台的使用者都能看到。名稱應準確反映應用程式的用途與功能,並易於理解與辨識。 ::: ### 描述 \{#description} -應用程式的簡短描述將顯示在管理控制台的應用程式詳細資訊頁面上。描述旨在為管理員提供有關應用程式的其他資訊,例如其目的、功能和任何其他相關細節。 +應用程式的簡要描述,會顯示於管理主控台的應用程式詳細頁。描述旨在為管理員提供應用程式的額外資訊,例如用途、功能及其他相關細節。 -### 重定向 URI \{#redirect-uris} +### 重導 URI \{#redirect-uris} -_重定向 URI_ 是為應用程式預先配置的一組有效重定向 URI 列表。當使用者登入 Logto 並嘗試存取應用程式時,他們將被重定向到應用程式設定中指定的允許 URI 之一。 +_重導 URI_ 是預先為應用程式設定的一組有效重導 URI。當使用者登入 Logto 並嘗試存取應用程式時,會被重導至應用程式設定中允許的 URI 之一。 -允許的 URI 列表用於驗證應用程式在驗證過程中發送給 Logto 的授權請求中包含的重定向 URI。如果授權請求中指定的重定向 URI 與應用程式設定中的允許 URI 之一匹配,則使用者在成功驗證後將被重定向到該 URI。如果重定向 URI 不在允許列表中,則使用者將不會被重定向,驗證過程將失敗。 +允許的 URI 清單用於驗證應用程式在驗證 (Authentication) 流程中發送給 Logto 的授權請求所包含的重導 URI。若授權請求中的重導 URI 與應用程式設定中的允許 URI 相符,則使用者驗證成功後會被重導至該 URI。若不在允許清單中,則不會重導且驗證流程會失敗。 :::note -確保所有有效的重定向 URI 都已添加到 Logto 中應用程式的允許列表中,以確保使用者在驗證後能夠成功存取應用程式。 +請確保所有有效的重導 URI 都已加入 Logto 應用程式的允許清單,以確保使用者驗證後能順利存取應用程式。 ::: -你可以查看 [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) 以獲取更多資訊。 +你可以參考 [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) 以獲得更多資訊。 - 理解 OIDC 中的重定向 URI 與授權碼流程 + 了解 OIDC 授權碼流程中的重導 URI -### 登出後重定向 URI \{#post-sign-out-redirect-uris} +### 登出後重導 URI \{#post-sign-out-redirect-uris} -_登出後重定向 URI_ 是為應用程式預先配置的一組有效 URI 列表,用於在使用者從 Logto 登出後重定向使用者。 +_登出後重導 URI_ 是預先為應用程式設定的一組有效 URI,供使用者自 Logto 登出後重導之用。 -使用允許的 _登出後重定向 URI_ 是 OIDC 中 RP 發起(Relying Party Initiated)登出規範的一部分。此規範提供了一種標準化的方法,讓應用程式為使用者發起登出請求,這包括在使用者登出後將其重定向到預先配置的端點。 +允許的 _登出後重導 URI_ 用於 OIDC 的 RP 發起(Relying Party Initiated)登出規範。此規範為應用程式發起使用者登出請求提供標準化方法,包含在使用者登出後重導至預先設定的端點。 -當使用者從 Logto 登出時,他們的會話將被終止,並被重定向到應用程式設定中指定的允許 URI 之一。這確保使用者在登出後僅被引導到授權和有效的端點,有助於防止未經授權的訪問和與重定向使用者到未知或未驗證端點相關的安全風險。 +當使用者自 Logto 登出時,其工作階段會終止,並被重導至應用程式設定中允許的 URI 之一。這確保使用者僅被導向授權且有效的端點,避免將使用者重導至未知或未驗證端點所帶來的未授權存取與安全風險。 -你可以查看 [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) 以獲取更多資訊。 +你可以參考 [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) 以獲得更多資訊。 -### CORS 允許的來源 \{#cors-allowed-origins} +### CORS 允許來源 \{#cors-allowed-origins} -_CORS(跨來源資源共享)允許的來源_ 是應用程式可以從中向 Logto 服務發出請求的允許來源列表。任何不在允許列表中的來源將無法向 Logto 服務發出請求。 +_CORS(跨來源資源共用)允許來源_ 是允許應用程式向 Logto 服務發送請求的來源清單。不在允許清單中的來源將無法向 Logto 服務發送請求。 -CORS 允許的來源列表用於限制未經授權的網域對 Logto 服務的訪問,並有助於防止跨站請求偽造(CSRF)攻擊。通過在 Logto 中為應用程式指定允許的來源,服務可以確保只有授權的網域能夠向服務發出請求。 +CORS 允許來源清單用於限制未授權網域存取 Logto 服務,並協助防範跨站請求偽造(CSRF)攻擊。透過在 Logto 中為應用程式指定允許來源,服務能確保僅授權網域能發送請求。 :::note -允許的來源列表應包含應用程式將被提供的來源。這確保來自應用程式的請求被允許,而來自未經授權來源的請求被阻止。 +允許來源清單應包含應用程式實際服務的來源。這可確保應用程式的請求被允許,而未授權來源的請求則會被阻擋。 ::: -### OpenID 提供者配置端點 \{#openid-provider-configuration-endpoint} +### OpenID 提供者設定端點 \{#openid-provider-configuration-endpoint} [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) 的端點。 ### 授權端點 \{#authorization-endpoint} -_授權端點_ 是 OIDC 的一個術語,是用於啟動使用者驗證過程的必需端點。當使用者嘗試存取已在 Logto 平台上註冊的受保護資源或應用程式時,他們將被重定向到 _授權端點_ 以驗證其身分並獲得存取請求資源的授權。 +_授權端點 (Authorization Endpoint)_ 為 OIDC 術語,是用於啟動使用者驗證流程的必要端點。當使用者嘗試存取已註冊於 Logto 平台的受保護資源或應用程式時,會被重導至 _授權端點_ 以驗證身分並取得存取所需資源的授權。 -你可以查看 [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 以獲取更多資訊。 +你可以參考 [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 以獲得更多資訊。 ### 權杖端點 \{#token-endpoint} -_權杖端點_ 是 OIDC 的一個術語,是 OIDC 客戶端用於從 OIDC 提供者獲取存取權杖、ID 權杖或重新整理權杖的 Web API 端點。 +_權杖端點 (Token Endpoint)_ 為 OIDC 術語,是 OIDC 用戶端用來向 OIDC 提供者取得存取權杖 (Access token)、ID 權杖 (ID token) 或重新整理權杖 (Refresh token) 的 Web API 端點。 -當 OIDC 客戶端需要獲取存取權杖或 ID 權杖時,它會向權杖端點發送一個授權授權請求,通常是授權碼或重新整理權杖。權杖端點然後驗證授權授權,如果授權有效,則向客戶端發出存取權杖或 ID 權杖。 +當 OIDC 用戶端需要取得存取權杖或 ID 權杖時,會攜帶授權授權(通常為授權碼或重新整理權杖)向權杖端點發送請求。權杖端點驗證授權授權後,若有效則發放存取權杖或 ID 權杖給用戶端。 -你可以查看 [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) 以獲取更多資訊。 +你可以參考 [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) 以獲得更多資訊。 -### 使用者資訊端點 \{#userinfo-endpoint} +### Userinfo 端點 \{#userinfo-endpoint} OpenID Connect [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)。 -### 總是發出重新整理權杖 \{#always-issue-refresh-token} +### 總是發放重新整理權杖 (Refresh token) \{#always-issue-refresh-token} -_可用性:傳統網頁、SPA_ +_適用範圍:傳統網頁、SPA_ -啟用後,Logto 將始終發出重新整理權杖,無論驗證請求中是否出現 `prompt=consent`,或 `offline_access` 是否出現在權限範圍中。 +啟用後,Logto 將總是發放重新整理權杖 (Refresh token),無論驗證請求中是否帶有 `prompt=consent`,或權限範圍 (Scopes) 中是否帶有 `offline_access`。 -然而,除非必要(通常對於某些需要重新整理權杖的第三方 OAuth 整合有用),否則不建議這樣做,因為這與 OpenID Connect 不兼容,可能會導致問題。 +但除非必要(通常僅用於某些需要重新整理權杖的第三方 OAuth 整合),否則不建議這麼做,因為這不符合 OpenID Connect 標準,且可能導致問題。 -### 旋轉重新整理權杖 \{#rotate-refresh-token} +### 重新整理權杖 (Refresh token) 輪替 \{#rotate-refresh-token} -_預設:`true`_ +_預設值:`true`_ -啟用後,Logto 將在以下情況下為權杖請求發出新的重新整理權杖: +啟用後,Logto 會在下列情況下於權杖請求時發放新的重新整理權杖 (Refresh token): -- 如果重新整理權杖已旋轉(通過發出新權杖延長其 TTL)一年;**或** -- 如果重新整理權杖接近其到期時間(>=70% 的原始存活時間 (TTL) 已過);**或** -- 如果客戶端是公共客戶端,例如原生應用程式或單頁應用程式 (SPA)。 +- 若重新整理權杖已輪替(TTL 已延長並發放新權杖)達一年;**或** +- 若重新整理權杖即將到期(已過原始存活時間 (TTL) 的 70% 以上);**或** +- 若用戶端為公開用戶端,例如原生應用程式或單頁應用程式 (SPA)。 :::note -對於公共客戶端,啟用此功能時,當客戶端使用重新整理權杖交換新存取權杖時,將始終發出新的重新整理權杖。 -雖然你仍然可以為這些公共客戶端關閉此功能,但強烈建議為安全原因保持啟用。 +對於公開用戶端,啟用此功能時,每當用戶端以重新整理權杖換取新存取權杖時,總會發放新的重新整理權杖。 +雖然你仍可為這些公開用戶端關閉此功能,但強烈建議為安全考量保持啟用。 ::: -理解重新整理權杖旋轉 + + 了解重新整理權杖 (Refresh token) 輪替 + -### 重新整理權杖存活時間 (TTL)(以天為單位)\{#refresh-token-time-to-live-ttl-in-days} +### 重新整理權杖 (Refresh token) 存活時間(TTL,天)\{#refresh-token-time-to-live-ttl-in-days} -_可用性:非 SPA;預設:14 天_ +_適用範圍:非 SPA;預設值:14 天_ -重新整理權杖在過期並失效之前可用於請求新存取權杖的持續時間。權杖請求將延長重新整理權杖的 TTL 至此值。 +重新整理權杖可用於請求新存取權杖的有效期間,過期後即失效。權杖請求會將重新整理權杖的 TTL 延長至此值。 -通常,較低的值是首選。 +通常建議設為較低的值。 -注意:出於安全原因,SPA(單頁應用程式)中無法刷新 TTL。這意味著 Logto 不會通過權杖請求延長 TTL。為了提升使用者體驗,你可以啟用「旋轉重新整理權杖」功能,允許 Logto 在必要時發出新的重新整理權杖。 +注意:SPA(單頁應用程式)因安全考量不支援 TTL 延長。這表示 Logto 不會透過權杖請求延長 TTL。為提升使用者體驗,可啟用「重新整理權杖輪替」功能,讓 Logto 在必要時發放新的重新整理權杖。 ### 後台登出 URI \{#backchannel-logout-uri} -OpenID Connect 後台登出端點。參見 [聯邦登出:後台登出](#) 以獲取更多資訊。 +OpenID Connect 後台登出 (Backchannel logout) 端點。詳情請參閱 [聯邦登出:後台登出](#)。 ### 自訂資料 \{#custom-data} -未列在預定義應用程式屬性中的其他自訂應用程式資訊,使用者可以根據其特定需求定義自己的自訂資料欄位,例如業務特定的設定和配置。 +未列於預設應用程式屬性中的額外自訂應用程式資訊,使用者可依自身需求定義自訂資料欄位,例如業務專屬設定與配置。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx index ae0e3cfd02a..55b31c9f0b7 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/integrate-logto-into-your-application/README.mdx @@ -1,30 +1,45 @@ --- -description: 只需幾分鐘,即可透過我們的快速入門指南整合應用程式驗證 (Authentication) 與身分聯盟。 +description: 只需幾分鐘,透過我們的快速入門指南整合應用程式驗證 (Authentication) 與身分聯盟。 sidebar_position: 1 --- # 將 Logto 整合進你的應用程式 -按照以下步驟,無論是面向使用者的應用程式還是機器對機器服務,都能輕鬆為你的應用程式新增驗證 (Authentication) 功能: +依照以下步驟,無論是面向使用者的應用程式還是機器對機器服務,都能輕鬆為你的應用程式新增驗證 (Authentication): 1. 前往 控制台 > 應用程式 -2. 點擊「建立應用程式」以新增應用程式 +2. 點擊「建立應用程式」以新增一個應用程式 -3. 選擇你的 [應用程式框架](/quick-starts) 開始。如果找不到你的框架,請點擊應用程式建立頁面右下角的「不選框架建立應用程式」按鈕,透過選擇 [應用程式類型](/integrate-logto/application-data-structure/#application-types) 建立應用程式,或根據我們的 [SDK 規範](/developers/sdk-conventions) 提出功能需求或貢獻 SDK。 +3. 選擇你的 [應用程式框架](/quick-starts) 開始。如果找不到你的框架,請點擊應用程式建立頁面右下角的「不選框架建立應用程式」按鈕,透過選擇 [應用程式類型](/integrate-logto/application-data-structure/#application-types) 建立應用程式,或依照我們的 [SDK 規範](/developers/sdk-conventions) 提出功能需求或貢獻 SDK。 -4. 選擇框架後,會看到該框架 SDK 的快速入門指南。請依照步驟設定並整合你的應用程式。如果你需要進一步瞭解整合過程中的相關概念,可參考 [理解 Logto 驗證流程](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) 以獲得更深入的說明。 +4. 選擇框架後,將看到該框架 SDK 的快速入門指南。請依照步驟設定並整合你的應用程式。如果你需要進一步瞭解整合過程中的相關概念,可參考 [瞭解 Logto 驗證流程](/integrate-logto/integrate-logto-into-your-application/understand-authentication-flow/) 以獲得更深入的說明。 :::note -控制台中的指南僅適用於使用我們 SDK 快速開始 Logto。若需完整整合指南(包含進階 SDK 用法),請參閱 [快速入門](/quick-starts) 區段。 +控制台中的指南僅適用於使用我們 SDK 的 Logto 快速入門。如需完整整合指南(包含進階 SDK 用法),請參閱 [快速入門](/quick-starts) 區段。 ::: -5. 完成後,你就可以進一步探索 Logto 的更多功能: +5. 完成後,你可以進一步探索更多 Logto 相關內容: 終端使用者流程 授權 (Authorization) 組織 (Organizations) +## 常見問題 \{#faqs} + +
+ + ### 我的後端服務如何驗證使用者權杖並管理使用者? + +若要在你的後端 API(如 Python、Node.js、Go、Java、PHP 等)安全驗證存取權杖 (Access tokens),並以程式方式管理使用者,請參考指南:[如何在 API 服務或後端驗證存取權杖](/authorization/validate-access-tokens)。 + +本文件涵蓋: + +- 如何在每次 API 呼叫時檢查持有者權杖 (Bearer tokens) 的有效性 +- 將 Logto 與多個前端應用程式及後端服務整合的最佳實踐 + +
+ ## 相關資源 \{#related-resources} @@ -40,9 +55,9 @@ sidebar_position: 1 - 解析「iat」權杖宣告 (Claim) 與「Invalid issued at time」錯誤排查 + 瞭解「iat」權杖宣告 (Claim) 與「Invalid issued at time」錯誤排查 - 解析與排查「invalid_grant」錯誤 + 瞭解並排查「invalid_grant」錯誤 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index d3b07b5a488..65622c6d1dc 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -10,24 +10,24 @@ import CustomizationIcon from '@site/src/assets/customization.svg'; Logto 的第三方應用程式整合功能,讓你能將 Logto 作為外部應用程式的 [身分提供者 (IdP, Identity Provider)](https://auth.wiki/identity-provider)。 -身分提供者 (IdP) 是一種驗證使用者身分並管理其登入憑證的服務。確認使用者身分後,IdP 會產生驗證權杖或斷言,並允許使用者存取各種應用程式或服務,而無需再次登入。 +身分提供者 (IdP) 是一種驗證使用者身分並管理其登入憑證的服務。確認使用者身分後,IdP 會產生驗證權杖或斷言,讓使用者無需再次登入即可存取各種應用程式或服務。 -與你在 [將 Logto 整合到你的應用程式](/integrate-logto/integrate-logto-into-your-application) 指南中建立、由你完全控制的應用程式不同,第三方應用程式是由外部開發者或商業夥伴開發的獨立服務。 +與你在 [整合 Logto 至你的應用程式](/integrate-logto/integrate-logto-into-your-application) 指南中建立、完全由你開發與控制的應用程式不同,第三方應用程式是由外部開發者或商業夥伴開發的獨立服務。 -這種整合方式非常適合常見的商業場景。你可以讓使用者用 Logto 帳號存取合作夥伴的應用程式,就像企業用戶用 Google Workspace 登入 Slack 一樣。你也可以打造開放平台,讓第三方應用程式新增「使用 Logto 登入」功能,類似「使用 Google 登入」。 +這種整合方式非常適合常見的商業場景。你可以讓使用者用 Logto 帳號存取合作夥伴的應用程式,就像企業用戶用 Google Workspace 登入 Slack 一樣。你也可以打造一個開放平台,讓第三方應用程式新增「使用 Logto 登入」功能,類似「使用 Google 登入」。 Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 協議的身分服務,提供 [驗證 (Authentication)](https://auth.wiki/authentication) 與 [授權 (Authorization)](https://auth.wiki/authorization) 能力。這讓整合 OIDC 第三方應用程式就像傳統網頁應用程式一樣簡單。 -由於 OIDC 建立在 [OAuth 2.0](https://auth.wiki/oauth-2.0) 之上,並新增了驗證層,因此你也可以使用 OAuth 協議整合第三方應用程式。 +由於 OIDC 建立於 [OAuth 2.0](https://auth.wiki/oauth-2.0) 之上,並新增了驗證層,因此你也可以使用 OAuth 協議整合第三方應用程式。 ## 在 Logto 建立第三方應用程式 \{#create-an-third-party-application-in-logto} -1. 前往 控制台 > 應用程式 -2. 選擇「第三方應用程式」作為應用程式類型,並選擇以下其中一種整合協議: +1. 前往 控制台 > 應用程式。 +2. 點擊「建立應用程式」按鈕,選擇「第三方應用程式」作為應用程式類型,並選擇以下其中一種整合協議: - OIDC / OAuth -3. 輸入應用程式名稱與描述,然後點擊「建立」按鈕。系統將建立一個新的第三方應用程式。 +3. 輸入你的應用程式名稱與描述,然後點擊「建立」按鈕。系統將建立一個新的第三方應用程式。 -所有建立的第三方應用程式都會在「應用程式」頁面的「第三方應用程式」分頁下分類顯示。這樣有助於你區分自有應用程式與第三方應用程式,方便統一管理。 +所有建立的第三方應用程式都會在應用程式頁面的「第三方應用程式」分頁下分類顯示。這樣有助於你區分自有應用程式與第三方應用程式,方便集中管理。 ## 設定 OIDC 組態 \{#set-up-the-oidc-configurations} @@ -35,18 +35,18 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 在設定 OIDC 組態前,請確保你已[建立 OIDC 第三方應用程式](/quick-starts/third-party-oidc)。 ::: -1. 提供 OIDC 第三方應用程式的 [**redirect URI**](/integrate-logto/application-data-structure#redirect-uris)。這是第三方應用程式在使用者通過 Logto 驗證後,將使用者導向的 URL。 - 你通常可以在第三方應用程式的 IdP 連線設定頁面找到這個資訊。 +1. 提供 OIDC 第三方應用程式的 [**redirect URI**](/integrate-logto/application-data-structure#redirect-uris)。這是第三方應用程式在使用者經 Logto 驗證後將其導向的 URL。 + 你通常可以在第三方應用程式的 IdP 連線設定頁找到這個資訊。 -2. 從 Logto 應用程式詳細頁面取得 [**client ID**](/integrate-logto/application-data-structure#application-id) 與 [**client secret**](/integrate-logto/application-data-structure#application-secret),並填入你的服務提供者的 IdP 連線設定頁面。 +2. 從 Logto 應用程式詳細頁取得 [**client ID**](/integrate-logto/application-data-structure#application-id) 與 [**client secret**](/integrate-logto/application-data-structure#application-secret),並填入你的服務提供者的 IdP 連線設定頁。 -3. 從 Logto 應用程式詳細頁面取得 [**authorization endpoint**](/integrate-logto/application-data-structure#authorization-endpoint) 與 [**token endpoint**](/integrate-logto/application-data-structure#token-endpoint),並提供給你的服務提供者。 - 如果你的服務提供者支援 OIDC 探索(discovery),你只需複製 Logto 應用程式詳細頁面的 **discovery endpoint**,並提供給服務提供者。服務提供者將能自動從 discovery endpoint 取得所有最新的 OIDC 驗證資訊。 - 否則,請點擊 **顯示端點詳細資訊** 按鈕,以檢視所有 OIDC 驗證端點。 +3. 從 Logto 應用程式詳細頁取得 [**authorization endpoint**](/integrate-logto/application-data-structure#authorization-endpoint) 與 [**token endpoint**](/integrate-logto/application-data-structure#token-endpoint),並提供給你的服務提供者。 + 如果你的服務提供者支援 OIDC discovery,只需複製 Logto 應用程式詳細頁的 **discovery endpoint** 並提供給服務提供者即可。服務提供者會自動從 discovery endpoint 取得所有最新的 OIDC 驗證資訊。 + 否則,請點擊 **顯示端點詳細資訊** 按鈕以檢視所有 OIDC 驗證端點。 ## OIDC 第三方應用程式的使用者授權頁面 (Consent screen) \{#consent-screen-for-oidc-third-party-applications} -出於安全考量,所有 OIDC 第三方應用程式在通過 Logto 驗證後,將會導向 [使用者授權頁面 (Consent screen)](/end-user-flows/consent-screen) 進行授權。 +出於安全考量,所有 OIDC 第三方應用程式在經 Logto 驗證後,將會導向 [使用者授權頁面 (Consent screen)](/end-user-flows/consent-screen) 進行授權。 所有第三方應用程式請求的 [使用者資料權限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API 資源權限範圍](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[組織權限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) 以及組織成員資訊都會顯示在授權頁面上。 @@ -64,14 +64,14 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) type: 'link', label: '權限管理', href: '/integrate-logto/third-party-applications/permission-management', - description: '瞭解如何管理 OIDC 第三方應用程式的權限。', + description: '瞭解如何管理你的 OIDC 第三方應用程式的權限。', customProps: { icon: , }, }, { type: 'link', - label: '授權頁面品牌設定', + label: '使用者授權頁面品牌設定', href: '/integrate-logto/third-party-applications/consent-screen-branding', description: '自訂授權頁面外觀,讓其符合你的品牌識別,並提供一致的使用者體驗。', customProps: { @@ -86,11 +86,11 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect)
-### 我們如何確保使用者在授權頁面上只能授予他們實際擁有的權限? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} +### 我們如何確保使用者在授權頁面只能授予自己實際擁有的權限? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} -Logto 使用 **角色型存取控制 (RBAC, Role-Based Access Control)** 來管理使用者權限。在授權頁面上,僅會顯示已經透過角色分配給使用者的權限範圍(scopes)。如果第三方應用程式請求使用者未擁有的權限範圍,這些權限將不會顯示,以防止未經授權的授權行為。 +Logto 透過角色型存取控制 (RBAC, Role-Based Access Control) 管理使用者權限。在授權頁面上,僅會顯示已透過角色分配給使用者的權限範圍(scopes)。如果第三方應用程式請求使用者未擁有的權限範圍,這些權限將被排除,以防止未經授權的授權行為。 管理方式如下: diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx index 1e0e0da00de..8667d3d5172 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/README.mdx @@ -3,12 +3,13 @@ import Developer from '@site/src/assets/developer.svg'; import TenantMemberManagement from '@site/src/assets/gear.svg'; import PricingAndBilling from '@site/src/assets/key.svg'; import CustomDomains from '@site/src/assets/search.svg'; +import SystemLimit from '@site/src/assets/security.svg'; # Logto 雲端服務 [Logto Cloud](https://cloud.logto.io) 提供一系列管理與營運服務,協助你順利且輕鬆地管理身分與資源。由 Logto 託管,包含 [多區域支援](/logto-cloud/tenant-settings#tenant-region)、租戶管理、[計費與價格](/logto-cloud/billing-and-pricing)、[成員管理](/logto-cloud/tenant-member-management) 以及主控台角色型存取控制等功能。 -若你對雲端服務有任何疑問或需要額外協助,歡迎聯絡我們。 +若你對雲端服務有任何疑問或需要額外協助,歡迎聯繫我們。 ## 雲端服務功能 \{#features-for-cloud-service} @@ -18,7 +19,7 @@ import CustomDomains from '@site/src/assets/search.svg'; type: 'link', label: '租戶設定 (Tenant settings)', href: '/logto-cloud/tenant-settings', - description: '更新或變更租戶名稱、檢查區域,並刪除或退出租戶。', + description: '更新或變更租戶名稱、檢查區域,以及刪除或退出租戶。', customProps: { icon: , }, @@ -45,7 +46,7 @@ import CustomDomains from '@site/src/assets/search.svg'; type: 'link', label: '自訂網域 (Custom domains)', href: '/logto-cloud/custom-domain', - description: '為你的 Logto 租戶使用自有網域,讓登入體驗品牌一致。', + description: '為你的 Logto 租戶使用自有網域,讓登入體驗中的品牌一致。', customProps: { icon: , }, @@ -54,10 +55,19 @@ import CustomDomains from '@site/src/assets/search.svg'; type: 'link', label: '計費與價格 (Billing and pricing)', href: '/logto-cloud/billing-and-pricing', - description: '輕鬆瞭解帳單並自信管理訂閱。', + description: '輕鬆瞭解帳單並自信管理你的訂閱。', customProps: { icon: , }, }, + { + type: 'link', + label: '系統限制 (System limit)', + href: '/logto-cloud/system-limit', + description: '瞭解 Dev、Pro 與 Enterprise 租戶的系統限制與流量保護。', + customProps: { + icon: , + }, + }, ]} /> diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx index 91ab1394958..b8332a98cc0 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/custom-domain.mdx @@ -6,25 +6,25 @@ sidebar_position: 4 # 自訂網域 (Custom domain) -你的 Logto 租戶預設會有一個免費網域 `{{tenant-id}}.app.logto`。不過,你可以透過使用自訂網域(例如 `auth.example.com`)來提升使用者體驗與品牌辨識度。 +你的 Logto 租戶預設會有一個免費網域 `{{tenant-id}}.app.logto`。不過,你可以透過自訂網域(如 `auth.example.com`)來提升使用體驗與品牌辨識度。 自訂網域會用於多個功能: - [登入與註冊頁面](/end-user-flows/sign-up-and-sign-in) 的網址 -- [通行密鑰 (Passkey)](/end-user-flows/mfa/webauthn) 綁定網址(若在使用者已綁定通行密鑰後變更網域,可能會導致驗證失敗) +- [Passkey](/end-user-flows/mfa/webauthn) 連結網址(若在使用者已綁定 Passkey 後更換網域,可能會導致驗證失敗) - [社交連接器](/connectors/social-connectors) 或 [企業級單一登入 (Enterprise SSO) 連接器](/connectors/enterprise-connectors) 的回呼 URI - 與應用程式整合 Logto 時的 [SDK 端點](/integrate-logto/application-data-structure#openid-provider-configuration-endpoint) :::note -在服務上線後變更網域可能會造成問題,因為你的應用程式程式碼與整合可能仍參考舊網域。為確保順利遷移,**請在建立正式環境租戶時就設定自訂網域**。 +服務上線後更換網域可能會造成問題,因為你的應用程式程式碼與整合可能仍指向舊網域。為確保順利遷移,**請在建立正式環境租戶時就設定自訂網域**。 ::: ## 在 Console 設定自訂網域 \{#configure-custom-domain-in-console} -要在 Logto Console 新增自訂網域,請依下列步驟操作: +在 Logto Console 新增自訂網域,請依下列步驟操作: 1. 前往 Console > 設定 > 網域。 -2. 在「自訂網域 (Custom Domain)」區塊輸入你的網域名稱並點擊「新增網域 (add domain)」。 +2. 在「自訂網域 (Custom Domain)」區塊輸入你的網域名稱並點擊「新增網域」。 新增網域 @@ -32,9 +32,9 @@ sidebar_position: 4 自訂網域處理中 -4. 等待驗證與 SSL 處理。 - 1. 系統會每 10 秒自動驗證一次紀錄,直到自訂網域新增完成。只需確保輸入的網域名稱或 DNS 紀錄正確即可。 - 2. 驗證通常只需幾分鐘,但依 DNS 供應商不同,最長可能需 24 小時。過程中可自由切換頁面。 +4. 等待驗證與 SSL 流程完成。 + 1. 系統會每 10 秒自動驗證一次紀錄,直到自訂網域新增成功。只需確保輸入的網域名稱或 DNS 紀錄正確即可。 + 2. 驗證通常只需幾分鐘,但視 DNS 供應商可能最長需 24 小時。過程中可自由切換頁面。 ## 疑難排解 \{#troubleshooting} @@ -45,9 +45,9 @@ sidebar_position: 4 -若在設定自訂網域時遇到 SSL 憑證問題,可能與 DNS 設定中的 CAA 紀錄有關。CAA 紀錄用於指定哪些憑證授權單位(CA)可為你的網域簽發憑證。若你有使用 CAA 紀錄,請務必授權 "letsencrypt.org" 與 "pki.goog",以便 Logto 簽發 SSL 憑證。 +若設定自訂網域時遇到 SSL 憑證問題,可能與 DNS 設定中的 CAA 紀錄有關。CAA 紀錄用來指定哪些憑證授權單位(CA)可為你的網域簽發憑證。若你有使用 CAA 紀錄,需授權 "letsencrypt.org" 與 "pki.goog",Logto 才能簽發 SSL 憑證。 -如需排查與解決 CAA 紀錄相關的 SSL 憑證問題,請參考 [Cloudflare 的官方文件](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/)。 +請參考 [Cloudflare 官方文件](https://developers.cloudflare.com/ssl/edge-certificates/caa-records/) 以排查並解決與 CAA 紀錄相關的 SSL 憑證問題。
@@ -58,9 +58,9 @@ sidebar_position: 4 -若新增自訂網域時出現「The hostname is associated with a held zone, please contact the owner to have the hold removed」錯誤訊息,代表該網域已在 Cloudflare 區域中,且狀態為「Zone Hold」。詳情請參閱 [Cloudflare 官方文件](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/)。 +若新增自訂網域時出現「The hostname is associated with a held zone, please contact the owner to have the hold removed」錯誤訊息,代表該網域已在 Cloudflare 區域中,且狀態為「Zone Hold」。詳情請參閱 [Cloudflare 文件](https://developers.cloudflare.com/fundamentals/setup/account/account-security/zone-holds/)。 -要解決此問題,需解除 zone hold。請依上述連結說明操作。 +解決方式:你需要解除 zone hold。請依上述連結說明操作。
@@ -71,13 +71,44 @@ sidebar_position: 4 -若你的網域由 Cloudflare 託管,請將 CNAME 紀錄的 Cloudflare 代理(proxy)功能關閉。 +若你的網域由 Cloudflare 託管,請將 CNAME 紀錄的 Cloudflare 代理(Proxy)功能關閉。 + + + +
+ + +### 設定自訂網域後出現「Redirect URI does not match」錯誤 \{#redirect-uri-mismatch} + + + +若新增自訂網域後出現「redirect URI does not match」錯誤,請將 SDK 設定更新為使用自訂網域作為端點。 + +**關於「主要網域 (primary domain)」:** + +Logto 沒有獨立的「主要網域」設定。新增自訂網域後,你的自訂網域與預設 `{tenant-id}.logto.app` 網域都會同時有效。實際驗證流程會依你在 SDK `endpoint` 參數設定的網域為主。 + +**解決方式:** + +將 SDK 初始化時的 `endpoint` 參數改為你的自訂網域: + +```typescript +const client = new LogtoClient({ + endpoint: 'https://auth.example.com', // 使用你的自訂網域 + appId: 'your-app-id', + // ... 其他選項 +}); +``` + +同時請確認 Console → 應用程式 中註冊的 redirect URI 與你實際使用的網域一致。 + +**注意:** Logto 會自動為你的自訂網域申請並管理 SSL 憑證,無需自行設定。
## 使用自訂網域 \{#use-custom-domain} -完成設定後,你的租戶將同時支援自訂網域名稱與預設 Logto 網域名稱。不過,需進行部分設定才能啟用自訂網域。 +完成設定後,你的自訂網域與預設 Logto 網域都可用於租戶。不過,需進行部分設定才能啟用自訂網域。 :::note @@ -87,7 +118,7 @@ sidebar_position: 4 ### 更新應用程式的 SDK 端點 \{#updating-the-sdk-endpoint-for-applications} -請在 Logto SDK 初始化程式碼中,將端點網域名稱修改為自訂網域。 +請將 Logto SDK 初始化程式碼中的 endpoint 網域名稱修改為自訂網域。 ```typescript const client = new LogtoClient({ @@ -98,9 +129,9 @@ const client = new LogtoClient({ ### 修改其他應用程式的驗證端點 \{#modifying-auth-endpoints-for-other-applications} -若你的應用程式未使用 Logto SDK,則需手動更新其驗證端點。 +若有未使用 Logto SDK 的應用程式,需手動更新其驗證端點。 -你可以在以下 well-known URL 查詢驗證端點: +你可以在 well-known URL 查詢驗證端點: ``` https://auth.example.com/oidc/.well-known/openid-configuration @@ -108,6 +139,6 @@ https://auth.example.com/oidc/.well-known/openid-configuration ### 更新社交連接器的回呼 URI \{#updating-the-social-connectors-callback-uri} -當使用者使用自訂網域時,社交連接器的回呼 URI 會自動更新為新網域。你需要前往社交平台的開發者後台,手動更新回呼 URI。 +若使用者透過自訂網域登入,社交連接器的回呼 URI 會自動更新。不過,你仍需前往社交平台的開發者後台,手動將回呼 URI 更新為新網域。 -當使用者使用自訂網域時,社交連接器的回呼 URI 會改用新網域,因此請務必到社交平台的開發者後台手動更新回呼 URI。 +當使用者使用自訂網域時,社交連接器的回呼 URI 會改用新網域,因此請務必到社交平台開發者後台手動更新回呼 URI。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx new file mode 100644 index 00000000000..0600ae50a23 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/system-limit.mdx @@ -0,0 +1,79 @@ +# 系統限制 + +在 Logto,我們為所有方案設定了寬鬆的限制,並提供彈性的按量付費選項,讓使用者只需為實際使用的部分付費。 + +你可能會注意到,部分定價頁上的項目標註為 _無限制_ 或 _持續按量付費無上限_。這代表通常可無限制使用,但 Logto 保留隨時間調整實際限制的權利,以維護所有使用者的公平使用。換句話說,實體限制是為了保護平台整體健康而設立的嚴格上限,並非定價的一部分,但可能會因不同方案組而有所差異。 + +如果你的使用情境合理但達到系統限制,歡迎隨時聯繫我們並提供回饋。這有助於我們更好地理解實際使用模式,並調整系統限制以更好地支持忠實客戶。 + +## 租戶層級速率限制保護 \{#tenant-level-rate-limit-protection} + +### Dev 租戶 \{#dev-tenants} + +對於 Dev 租戶,使用者可免費體驗 Logto 的功能與服務。為防止濫用並設定明確預期,我們定義了部分系統限制。這些限制有助於我們可持續管理平台,同時仍提供免費測試與開發用途。 + +若你希望提升配額,歡迎聯繫我們協助。也建議你從 **Dev** 升級至 **Pro**,即可移除上限並立即獲得完整存取權。 + +| **功能** | **實體限制** | +| ------------------------------------------ | ------------ | +| **內含權杖 (Included tokens)** | 每月 50,000 | +| **應用程式 (Applications)** | | +| 應用程式總數 | 100 | +| 機器對機器應用程式 | 100 | +| 第三方應用程式 | 100 | +| **API 資源 (API resources)** | | +| 資源數量 | 100 | +| **使用者驗證 (User authentication)** | | +| 社交連接器 (Social connector) | 100 | +| 企業級單一登入 (Enterprise SSO) | 100 | +| **使用者管理 (User management)** | | +| 使用者角色 (User roles) | 100 | +| 機器對機器角色 | 100 | +| 每個角色的權限 | 100 | +| **組織 (Organizations)** | | +| 組織數量 | 5,000 | +| 每個組織的使用者 | 100,000 | +| 組織使用者角色 | 1,000 | +| 組織機器對機器角色 | 100 | +| 組織權限 | 1,000 | +| **開發者與平台 (Developers and platform)** | | +| Webhook | 10 | +| 稽核日誌保留 | 14 天 | +| 租戶成員 | 20 | + +### Pro 租戶 \{#pro-tenant} + +對於 Pro 租戶,實體限制定義了附加元件與其他「無限制」實體(如應用程式)的上限。Pro 方案的系統限制詳情如下: + +| **功能** | **實體限制** | +| ------------------------------------------ | --------------- | +| **內含權杖 (Included tokens)** | 每月 10,000,000 | +| **應用程式 (Applications)** | | +| 應用程式總數 | 100 | +| 機器對機器應用程式 | 100 | +| OIDC/OAuth 第三方應用程式 | 100 | +| SAML 應用程式 | 100 | +| **API 資源 (API resources)** | | +| 資源數量 | 1,000 | +| 每個資源的權限 | 1,000 | +| **使用者驗證 (User authentication)** | | +| 社交連接器 (Social connectors) | 100 | +| 企業級單一登入 (Enterprise SSO) | 100 | +| **使用者管理 (User management)** | | +| 使用者角色 (User roles) | 1,000 | +| 機器對機器角色 | 100 | +| **組織 (Organizations)** | | +| 組織數量 | 100,000 | +| 每個組織的使用者 | 100,000 | +| 組織使用者角色 | 1,000 | +| 組織機器對機器角色 | 100 | +| 組織權限 | 1,000 | +| **開發者與平台 (Developers and platform)** | | +| Webhook | 10 | +| 稽核日誌保留 | 14 天 | +| 自訂網域 | 10 | +| 租戶成員 | 100 | + +### 企業級方案 (Enterprise) \{#enterprise} + +對於企業級方案,限制與功能皆可完全自訂,並透過合約管理。請[聯繫我們](https://logto.io/contact)以獲得更多資訊。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx index aea78e93cbc..96f58be3265 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-cloud/tenant-settings.mdx @@ -6,9 +6,9 @@ sidebar_position: 1 # 租戶設定 -新註冊 Logto Cloud 的使用者會自動加入一個免費的 **開發 (Development, Dev)** 環境租戶。你可以在這個租戶中探索所有功能。 +新註冊 Logto Cloud 的使用者會自動加入一個免費的 **開發 (Development, Dev)** 環境租戶。你可以在此租戶中探索所有功能。 -如果你想為 **生產 (Production, Prod)** 環境或新專案建立獨立租戶,請點擊頂部工具列左上角的當前租戶名稱。在此選單中,你可以切換租戶或建立新租戶。 +如果你想為 **生產 (Production, Prod)** 環境或新專案建立獨立租戶,請點擊頂部欄左上角的當前租戶名稱。在此選單中,你可以切換租戶或建立新租戶。 點擊「建立租戶」,然後: @@ -20,14 +20,14 @@ sidebar_position: 1 - 查看租戶 ID - 更新租戶名稱 -- 查看 [租戶區域](#tenant-region)。此項目建立後無法變更。 +- 查看 [租戶區域](#tenant-region)。此項目建立後無法更改。 - 查看 [租戶類型](#tenant-types-dev-vs-prod)。如有需要,你可以將 Dev 租戶轉換為 Prod 租戶。 - [離開租戶](#leave-tenant) - [刪除租戶](#delete-tenant) ## 租戶區域 \{#tenant-region} -建立租戶時,你可以選擇租戶資料儲存的區域。租戶建立後無法變更。可用區域如下: +建立租戶時,你可以選擇租戶資料儲存的區域。租戶建立後無法更改。可用區域如下: - 歐洲(荷蘭) - 美國西部(亞利桑那) @@ -45,19 +45,19 @@ Logto 利用全球邊緣網路,為你的應用程式提供最佳效能與可 - 詢問在你偏好的地點部署 Logto 私有雲 (Private Cloud) ::: -## 租戶類型:Dev vs. Prod \{#tenant-types-dev-vs-prod} +## 租戶類型:開發 (Dev) vs. 生產 (Prod) \{#tenant-types-dev-vs-prod} -Logto Cloud 有兩種租戶類型:開發 (Development, Dev) 與生產 (Production, Prod)。透過租戶區分,你可以更有效率地管理不同環境的專案,同時充分享受 Logto 的完整價值。 +Logto Cloud 有兩種租戶類型:開發 (Development, Dev) 與生產 (Production, Prod)。透過區分租戶類型,你可以更有效率地管理不同環境下的專案,同時充分享受 Logto 的完整價值。 -你可以在建立時選擇租戶類型。當你準備好正式上線時,有兩種選擇: +你可以在建立時選擇租戶類型。當你準備好進入生產環境時,有兩種選擇: - **建立新的生產租戶** - 建立全新的生產租戶並從頭設定。適合希望開發與生產環境完全分離的情境。 + 從零開始設置全新的生產租戶。若你希望開發與生產環境完全分離,這是理想選擇。 - **將現有 Dev 租戶轉換為生產租戶** - 如果你不想重新設定或遷移使用者,可以將現有開發租戶升級為付費生產租戶。 + 如果你不想重新設定或遷移使用者,可以將現有的開發租戶升級為付費生產租戶。 - - **升級為 Pro 方案**:前往 主控台 > 租戶設定 > 設定,點擊「轉換」即可自助升級。你在 dev 租戶中已使用的付費功能會自動帶入 Stripe 結帳流程。 - - **升級為 Enterprise 方案**:[聯絡我們](https://logto.io/contact),我們將協助你完成升級。 + - **轉換為 Pro 方案**:前往 主控台 > 租戶設定 > 設定,點擊「轉換」即可自助升級。你在 Dev 租戶中使用的所有付費功能都會帶入 Stripe 結帳流程。 + - **轉換為企業方案 (Enterprise plan)**:[聯絡我們](https://logto.io/contact),我們將協助你完成升級。 :::note 轉換後,租戶無法再回復為 Dev 環境;請確認準備好再進行操作。 @@ -65,68 +65,42 @@ Logto Cloud 有兩種租戶類型:開發 (Development, Dev) 與生產 (Product ### 開發 (Development) \{#development} -開發租戶(dev tenant)主要用於測試,不應用於生產環境。這些租戶可免費存取付費方案中的高級功能,且無需訂閱。 +開發租戶(Dev 租戶)主要用於測試,不應用於生產環境。這些租戶可免費存取付費方案中的進階功能,無需訂閱。 但開發租戶有以下限制: -- Dev 租戶會自動刪除 90 天以上的使用者。詳情請參閱 [Dev 租戶資料保留政策](./dev-tenant-data-retention)。 -- 登入體驗期間會顯示橫幅,提示租戶處於開發模式。 -- 開發租戶的部分功能可能有配額限制,若有適用,會在功能詳情頁說明。 +- Dev 租戶中的使用者超過 90 天會自動刪除。詳情請參閱 [Dev 租戶資料保留政策](./dev-tenant-data-retention)。 +- 登入體驗時會顯示橫幅,提示租戶處於開發模式。 +- 開發租戶的部分功能可能有配額限制。若有,會在功能詳情頁說明。完整 Dev 方案限制請參閱 [系統限制](./system-limit) 頁面。 - Logto 可能會調整開發租戶的配額限制,並盡力提前通知你。 -| 功能 | 實體上限 | -| ------------------------------------------ | ----------- | -| **包含權杖 (Included tokens)** | 每月 50,000 | -| **應用程式 (Applications)** | | -| 總應用程式數 | 100 | -| 機器對機器應用程式 | 100 | -| 第三方應用程式 | 100 | -| **API 資源 (API resources)** | | -| 資源數量 | 100 | -| **使用者驗證 (User authentication)** | | -| 社交連接器 | 100 | -| 企業級單一登入 (Enterprise SSO) | 100 | -| **使用者管理 (User management)** | | -| 使用者角色 | 100 | -| 機器對機器角色 | 100 | -| 每個角色的權限 | 100 | -| **組織 (Organizations)** | | -| 組織數量 | 5,000 | -| 每個組織的使用者數 | 5,000 | -| 組織角色 | 100 | -| 組織權限 | 100 | -| **開發者與平台 (Developers and platform)** | | -| Webhook | 10 | -| 稽核日誌保留 | 14 天 | -| 租戶成員 | 20 | - ### 生產 (Production) \{#production} -生產租戶是終端使用者存取正式應用程式的地方,你可能需要[付費訂閱](https://logto.io/pricing)。你可以訂閱 Free 方案或 Pro 方案來建立生產租戶。若訂閱 Free 方案,最多只能建立 10 個租戶。 +生產租戶是終端使用者存取正式應用程式的地方,你可能需要[付費訂閱](https://logto.io/pricing)。你可以訂閱免費方案或 Pro 方案來建立生產租戶。若訂閱免費方案,最多只能建立 10 個租戶。 -## 啟用 MFA \{#enable-mfa} +## 啟用多重要素驗證 (MFA) \{#enable-mfa} -透過要求所有 Logto Pro/Enterprise 租戶成員啟用多重要素驗證 (MFA, Multi-Factor Authentication),提升工作區安全性。 +透過要求所有 Logto Pro/Enterprise 租戶成員啟用多重要素驗證 (MFA),提升工作區安全性。 目前尚未開放自助啟用,請[聯絡我們](https://logto.io/contact)以啟用此功能。 ## 啟用企業級單一登入 (Enterprise SSO) \{#enable-enterprise-sso} -Logto Cloud 支援 Enterprise 方案租戶整合企業級單一登入 (Enterprise SSO),包含 Google Workspace、Okta、Azure AD 等供應商。 +Logto Cloud 支援企業方案租戶整合企業級單一登入 (Enterprise SSO),包含 Google Workspace、Okta、Azure AD 等供應商。 -如需開始設定,請[聯絡我們](https://logto.io/contact)。我們將協助你快速完成設定。 +如需開始設定,請[聯絡我們](https://logto.io/contact)。我們將協助你快速完成設置。 ## 離開租戶 \{#leave-tenant} 管理員可以[邀請其他成員](/logto-cloud/tenant-member-management)加入此租戶。 -若至少還有一位 **管理員 (admin)**(角色),或你是 **協作者 (collaborator)**(角色),你可以選擇離開租戶。離開後,租戶內所有資源仍會保留,但你將無法再存取。 +若至少還有一位 **管理員 (admin)**,或你是 **協作者 (collaborator)**,你可以選擇離開租戶。離開後,租戶內的所有資源仍會保留,但你將無法再存取。 如果你是最後一位管理員,必須先將其他協作者指派為管理員後才能離開。 ## 刪除租戶 \{#delete-tenant} -[管理員](/logto-cloud/tenant-member-management#invite-collaborators)可以刪除 Logto 租戶。刪除租戶會永久移除所有相關的使用者資料與設定。此操作**無法復原**。Logto 會要求你輸入租戶名稱以確認,避免誤刪。 +[管理員](/logto-cloud/tenant-member-management#invite-collaborators)可以刪除 Logto 租戶。刪除租戶會永久移除所有相關使用者資料與設定。此操作**無法復原**。Logto 會要求你輸入租戶名稱以確認,避免誤刪。 如需協助,請透過電子郵件[聯絡我們](https://logto.io/contact)。 @@ -139,11 +113,11 @@ Logto Cloud 支援 Enterprise 方案租戶整合企業級單一登入 (Enterpris -你目前可以自行將 **開發 (Development)** 租戶轉換為付費方案的 **生產 (Production)** 租戶。[了解詳情](#tenant-types-dev-vs-prod) +你目前可以自行將 **開發 (Development)** 租戶轉換為付費方案的 **生產 (Production)** 租戶。[了解更多](#tenant-types-dev-vs-prod) -但 Logto Cloud 與 OSS 版本間(包含所有設定與使用者資料)的自助遷移尚未支援。如需此服務,請[聯絡 Logto 團隊](https://logto.io/contact)討論你的選項。 +但 Logto Cloud 與 OSS 版本間(包含所有設定與使用者資料)的自助遷移尚未支援。如需此服務,請[聯絡 Logto 團隊](https://logto.io/contact)討論你的需求。 -如果你計畫停止在某專案中使用 Logto Cloud,Logto 可協助你匯出所有使用者資料。請[聯絡我們](https://logto.io/contact)。 +若你計畫停止在某專案中使用 Logto Cloud,Logto 可協助你匯出所有使用者資料。請[聯絡我們](https://logto.io/contact)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx index 1455188ad0d..1af56794674 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/logto-oss/get-started-with-oss.mdx @@ -1,5 +1,5 @@ --- -description: Logto 開源服務 (OSS) 初始化的快速入門指南。 +description: Logto 開源服務(OSS)初始化快速入門指南。 sidebar_position: 1 --- @@ -17,7 +17,7 @@ import Tabs from '@theme/Tabs'; ## GitPod \{#gitpod} -要啟動 Logto 的線上 GitPod 工作區,點擊這裡。稍等片刻,你會看到如下訊息: +要在線上啟動 Logto 的 GitPod 工作區,請點此。稍等片刻,你會看到如下訊息:

-Logto 預設使用埠 `3001` 作為核心服務,埠 `3002` 作為互動式管理控制台。 +Logto 預設使用埠號 `3001` 作為核心服務,`3002` 作為互動式管理主控台。 -要繼續你的 Logto 旅程,按下 Ctrl(或 Cmd)並點擊以 `https://3002-...` 開頭的連結。享受吧! +要繼續你的 Logto 之旅,請按下 Ctrl(或 Cmd)並點擊以 `https://3002-...` 開頭的連結。祝你使用愉快! -## 本地 \{#local} +## 本地端 \{#local} -託管 Logto 的最低建議硬體要求為: +建議用於部署 Logto 的最低硬體需求如下: - **vCPU**:2 - **記憶體**:8 GiB @@ -44,17 +44,18 @@ Logto 預設使用埠 `3001` 作為核心服務,埠 `3002` 作為互動式管 -Docker Compose CLI 通常隨 [Docker Desktop](https://www.docker.com/products/docker-desktop) 一同提供。 +Docker Compose CLI 通常隨 [Docker Desktop](https://www.docker.com/products/docker-desktop) 一同安裝。 :::caution -不要在生產環境中使用我們的 docker compose 指令!由於我們目前將內建的 Postgres 資料庫與 Logto 應用程式一起打包在 `docker-compose.yml` 中,每次重新執行指令時都會創建一個新的資料庫實例,之前保存的任何資料都將丟失。 +請勿在生產環境中使用我們的 docker compose 指令!目前我們在 `docker-compose.yml` 中將內建的 Postgres 資料庫與 Logto 應用程式綁定在一起, +每次重新執行指令都會建立新的資料庫實例,先前儲存的資料將會遺失。 ::: ```bash curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | docker compose -p logto -f - up ``` -成功組合後,你會看到如下訊息: +組合成功後,你會看到如下訊息: @@ -96,16 +97,16 @@ docker pull svhd/logto:latest

步驟 3

-將容器埠映射到 Logto 核心和管理應用程式,例如 `3001:3001` 和 `3002:3002`;並將以下環境變數設置到容器中: +將容器埠號對應到 Logto 核心與管理應用程式,例如 `3001:3001` 和 `3002:3002`;並設定下列環境變數至容器: ```yml -TRUST_PROXY_HEADER: 1 # 如果在 Logto 前有 HTTPS 代理(例如 Nginx),設置為 1 -ENDPOINT: https:// # (可選)如果使用自訂域名,替換為你的 Logto 端點 URL -ADMIN_ENDPOINT: https:// # (可選)如果使用自訂域名,替換為你的 Logto 管理 URL -DB_URL: postgres://username:password@your_postgres_url:port/db_name # 替換為你的 Postgres DSN +TRUST_PROXY_HEADER: 1 # 如果 Logto 前方有 HTTPS 代理(如 Nginx),請設為 1 +ENDPOINT: https:// # (選填)若使用自訂網域,請替換為你的 Logto 端點 URL +ADMIN_ENDPOINT: https:// # (選填)若使用自訂網域,請替換為你的 Logto 管理端點 URL +DB_URL: postgres://username:password@your_postgres_url:port/db_name # 請替換為你的 Postgres DSN ``` -使用上述所有環境變數運行容器: +使用上述所有環境變數啟動容器: ```bash docker run \ @@ -121,8 +122,8 @@ docker run \ :::tip -- 如果使用 Docker Hub,請使用 `svhd/logto:latest` 而非 `ghcr.io/logto-io/logto:latest`。 -- 在 `DB_URL` 中使用 `host.docker.internal` 或 `172.17.0.1` 來指代主機 IP。 +- 若使用 Docker Hub,請將 `ghcr.io/logto-io/logto:latest` 替換為 `svhd/logto:latest`。 +- 在 `DB_URL` 中可使用 `host.docker.internal` 或 `172.17.0.1` 指向主機 IP。 ::: @@ -137,48 +138,48 @@ docker run \ - [Node.js](https://nodejs.org/) `^18.12.0` - [PostgreSQL](https://postgresql.org/) `^14.0` -較高版本通常可行,但不保證。 +較高版本通常可用,但不保證。 -我們建議使用專為 Logto 設置的新空資料庫,雖然這不是硬性要求。 +建議使用一個全新且專屬於 Logto 的空資料庫,雖然這不是強制要求。 **下載並啟動** -在你的終端中: +在終端機執行: ```bash npm init @logto@latest ``` -一旦完成初始化過程並啟動 Logto,你會看到如下訊息: +完成初始化流程並啟動 Logto 後,你會看到如下訊息:
```text -核心應用程式正在運行於 http://localhost:3001 -核心應用程式正在運行於 https://your-domain-url -管理應用程式正在運行於 http://localhost:3002 -管理應用程式正在運行於 https://your-admin-domain-url +Core app is running at http://localhost:3001 +Core app is running at https://your-domain-url +Admin app is running at http://localhost:3002 +Admin app is running at https://your-admin-domain-url ``` -前往 `http://localhost:3002/` 繼續你的 Logto 旅程。享受吧! +前往 `http://localhost:3002/` 繼續你的 Logto 之旅。祝你使用愉快!
-### 使用替代 URL 下載 \{#using-an-alternative-url-for-downloading} +### 使用替代下載網址 \{#using-an-alternative-url-for-downloading} -如果你想指定 Logto zip 文件的 URL,請使用 `--download-url` 選項。例如: +如果你想指定 Logto zip 檔案的下載網址,請使用 `--download-url` 參數。例如: ``` npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/releases/download/v1.2.2/logto.tar.gz ``` -注意,NPM 需要額外的 `--` 來傳遞參數。 +請注意,NPM 需額外加上 `--` 才能傳遞參數。
@@ -186,19 +187,19 @@ npm init @logto@latest -- --download-url=https://github.com/logto-io/logto/relea -### 配置(可選)\{#configuration-optional} +### 設定(選填) \{#configuration-optional} -Logto 使用環境變數進行配置,並支持 `.env` 文件。詳細用法和完整變數列表請參閱 [配置](/concepts/core-service/configuration)。 +Logto 透過環境變數進行設定,並支援 `.env` 檔案。詳細用法與完整變數列表請參閱 [設定說明](/concepts/core-service/configuration)。 -_如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心服務](/concepts/core-service)。_ +_若你需要更進階的控制或程式化存取 Logto,請參閱 [核心服務](/concepts/core-service)。_ -## 託管提供商 \{#hosting-providers} +## 主機服務商 \{#hosting-providers} -這些可靠的託管提供商提供 Logto 的一鍵安裝模板。通過易於部署的服務,你可以在幾秒鐘內使用 Logto 設置並啟動你的 CIAM 系統。 +這些可靠的主機服務商提供 Logto 一鍵安裝範本。透過簡易部署服務,你可以在數秒內完成 CIAM 系統的建置與啟動。 , }, @@ -215,7 +216,7 @@ _如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心 type: 'link', label: 'Coolify', href: 'https://coolify.io/docs/services/logto/', - description: '一個可自託管的 Heroku/Netlify 替代方案,便於應用程式和資料庫管理。', + description: '可自架的 Heroku/Netlify 替代方案,輕鬆管理應用與資料庫。', customProps: { icon: , }, @@ -224,7 +225,7 @@ _如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心 type: 'link', label: 'Dokploy', href: 'https://docs.dokploy.com/docs/core', - description: '輕量級工具,用於在自己的基礎設施上部署應用程式。', + description: '輕量級工具,讓你在自有基礎設施上部署應用。', customProps: { icon: , }, @@ -233,7 +234,7 @@ _如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心 type: 'link', label: 'Easypanel', href: 'https://easypanel.io/docs/templates/logto', - description: '一個現代化的控制面板,用於管理帶有 Docker 的雲伺服器。', + description: '現代化控制面板,透過 Docker 管理雲端伺服器。', customProps: { icon: , }, @@ -242,7 +243,7 @@ _如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心 type: 'link', label: 'Elestio', href: 'https://elest.io/open-source/logto', - description: '完全管理的 DevOps 平台,用於部署你的代碼和開源軟體。', + description: '全託管 DevOps 平台,部署你的程式碼與開源軟體。', customProps: { icon: , }, @@ -251,7 +252,7 @@ _如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心 type: 'link', label: 'Railway', href: 'https://railway.com/template/07_f_Z', - description: '簡化應用程式部署和基礎設施管理。', + description: '簡化應用部署與基礎設施管理。', customProps: { icon: , }, @@ -260,7 +261,7 @@ _如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心 type: 'link', label: 'Zeabur', href: 'https://zeabur.com/docs/marketplace/logto', - description: '簡化應用程式部署、擴展和監控,適合開發者。', + description: '協助開發者簡化應用部署、擴展與監控。', customProps: { icon: , }, @@ -268,12 +269,16 @@ _如果你想要更高級的控制或程式化訪問 Logto,請查看 [核心 ]} /> -請注意,我們不提供第三方服務提供商的客戶支持。如需訪問我們的支持渠道,請在 [Logto Cloud](https://cloud.logto.io) 上部署。謝謝! +請注意,我們不提供第三方服務商的客戶支援。如需官方支援,請部署於 [Logto Cloud](https://cloud.logto.io)。感謝你的理解! -## 創建帳戶 \{#create-an-account} +## 建立帳號 \{#create-an-account} -當你成功在伺服器上託管 Logto 後,點擊歡迎頁面上的「創建帳戶」。請記住,Logto 的開源版本僅允許在初次啟動時創建一個帳戶,且不支持多帳戶。帳戶創建過程僅限於用戶名和密碼組合。 +當你成功在伺服器上部署 Logto 後,請在歡迎頁點擊「建立帳號」。請注意,Logto 開源版僅允許首次啟動時建立一個帳號,且不支援多帳號。帳號建立僅支援使用者名稱與密碼組合。 + +:::tip +Logto OSS(自架版)不支援多位管理員設定。若需團隊協作或多管理員專案,建議使用 [Logto Cloud](https://cloud.logto.io),該服務提供完整團隊管理功能。 +::: ## 相關資源 \{#related-resources} -處理本地 HTTPS 開發 +本地 HTTPS 開發實務 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx index 1a197731bc3..96631c9ea0d 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/framework/java-spring-boot/README.mdx @@ -2,7 +2,7 @@ slug: /quick-starts/java-spring-boot sidebar_label: Java Spring Boot sidebar_custom_props: - description: Spring Boot 是一個 Java 的網頁框架,讓開發者能夠使用 Java 程式語言構建安全、快速且可擴展的伺服器應用程式。 + description: Spring Boot 是一個 Java 的網頁框架,讓開發者能以 Java 程式語言打造安全、快速且可擴展的伺服器應用程式。 logoFilename: 'spring-boot.svg' --- @@ -16,26 +16,26 @@ import ScopesAndClaims from './_scopes-and-claims.mdx'; # 為你的 Java Spring Boot 應用程式新增驗證 (Authentication) -本指南將向你展示如何將 Logto 整合到你的 Java Spring Boot 應用程式中。 +本指南將帶你將 Logto 整合進你的 Java Spring Boot 應用程式。 :::tip -- 你可以在我們的 [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub 儲存庫中找到本指南的範例程式碼。 -- 將 Logto 與你的 Java Spring Boot 應用程式整合不需要官方 SDK。我們將使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 庫來處理與 Logto 的 OIDC 驗證流程。 +- 你可以在我們的 [spring-boot-sample](https://github.com/logto-io/spring-boot-sample) GitHub 儲存庫找到本指南的範例程式碼。 +- 整合 Logto 到 Java Spring Boot 應用程式不需要官方 SDK。我們將使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 套件來處理與 Logto 的 OIDC 驗證流程。 ::: ## 先決條件 \{#prerequisites} -- 一個 [Logto Cloud](https://cloud.logto.io) 帳戶或 [自行託管的 Logto](/introduction/set-up-logto-oss)。 -- 我們的範例程式碼是使用 Spring Boot 的 [securing web starter](https://spring.io/guides/gs/securing-web) 創建的。如果你還沒有應用程式,請按照指示啟動一個新的網頁應用程式。 -- 在本指南中,我們將使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 庫來處理與 Logto 的 OIDC 驗證流程。請確保閱讀官方文件以了解相關概念。 +- 一個 [Logto Cloud](https://cloud.logto.io) 帳號或 [自行架設 Logto](/introduction/set-up-logto-oss)。 +- 我們的範例程式碼是使用 Spring Boot 的 [securing web starter](https://spring.io/guides/gs/securing-web) 建立的。如果你還沒有專案,請依照官方指引建立新的網頁應用程式。 +- 本指南將使用 [Spring Security](https://spring.io/projects/spring-security) 和 [Spring Security OAuth2](https://spring.io/guides/tutorials/spring-boot-oauth2) 套件來處理與 Logto 的 OIDC 驗證流程。請務必閱讀官方文件以瞭解相關概念。 -## 配置你的 Java Spring Boot 應用程式 \{#configure-your-java-spring-boot-application} +## 設定你的 Java Spring Boot 應用程式 \{#configure-your-java-spring-boot-application} -### 新增依賴項 \{#adding-dependencies} +### 新增相依套件 \{#adding-dependencies} -對於 [gradle](https://spring.io/guides/gs/gradle) 使用者,將以下依賴項新增到你的 `build.gradle` 檔案中: +對於 [gradle](https://spring.io/guides/gs/gradle) 使用者,請在 `build.gradle` 檔案中加入以下相依套件: ```groovy title="build.gradle" dependencies { @@ -46,7 +46,7 @@ dependencies { } ``` -對於 [maven](https://spring.io/guides/gs/maven) 使用者,將以下依賴項新增到你的 `pom.xml` 檔案中: +對於 [maven](https://spring.io/guides/gs/maven) 使用者,請在 `pom.xml` 檔案中加入以下相依套件: ```xml title="pom.xml" @@ -67,11 +67,11 @@ dependencies { ``` -### OAuth2 客戶端配置 \{#oauth2-client-configuration} +### OAuth2 Client 設定 \{#oauth2-client-configuration} -在 Logto Console 中註冊一個新的 `Java Spring Boot` 應用程式,並獲取你的網頁應用程式的客戶端憑證和 IdP 配置。 +在 Logto Console 註冊一個新的 `Java Spring Boot` 應用程式,並取得你的 Web 應用程式所需的 client credential 與 IdP 設定。 -將以下配置新增到你的 `application.properties` 檔案中: +將以下設定加入你的 `application.properties` 檔案: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.client-name=logto @@ -87,19 +87,19 @@ spring.security.oauth2.client.provider.logto.authorization-uri={{LOGTO_ENDPOINT} spring.security.oauth2.client.provider.logto.jwk-set-uri={{LOGTO_ENDPOINT}}/oidc/jwks ``` -## 實作 \{#implementation} +## 實作流程 \{#implementation} -為了在使用者登入後將其重定向回你的應用程式,你需要在前一步中使用 `client.registration.logto.redirect-uri` 屬性設置重定向 URI。 +為了讓使用者登入後能被導回你的應用程式,你需要在前述步驟中透過 `client.registration.logto.redirect-uri` 屬性設定 redirect URI。 - + ### 實作 WebSecurityConfig \{#implement-the-websecurityconfig} -#### 在你的專案中創建一個新的 `WebSecurityConfig` 類別 \{#create-a-new-class-websecurityconfig-in-your-project} +#### 在專案中建立新的 `WebSecurityConfig` 類別 \{#create-a-new-class-websecurityconfig-in-your-project} -`WebSecurityConfig` 類別將用於配置應用程式的安全設置。它是處理驗證和授權流程的關鍵類別。請查看 [Spring Security 文件](https://spring.io/guides/topicals/spring-security-architecture) 以獲取更多詳細資訊。 +`WebSecurityConfig` 類別將用來設定應用程式的安全性,是處理驗證 (Authentication) 與授權 (Authorization) 流程的關鍵類別。詳情請參閱 [Spring Security 文件](https://spring.io/guides/topicals/spring-security-architecture)。 ```java title="WebSecurityConfig.java" package com.example.securingweb; @@ -115,9 +115,9 @@ public class WebSecurityConfig { } ``` -#### 創建一個 `idTokenDecoderFactory` bean \{#create-a-idtokendecoderfactory-bean} +#### 建立 `idTokenDecoderFactory` bean \{#create-a-idtokendecoderfactory-bean} -這是必需的,因為 Logto 使用 `ES384` 作為預設算法,我們需要覆寫預設的 `OidcIdTokenDecoderFactory` 以使用相同的算法。 +這是因為 Logto 預設使用 `ES384` 演算法,我們需要覆寫預設的 `OidcIdTokenDecoderFactory` 以使用相同演算法。 ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -138,9 +138,9 @@ public class WebSecurityConfig { } ``` -#### 創建一個 LoginSuccessHandler 類別來處理登入成功事件 \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} +#### 建立 LoginSuccessHandler 類別以處理登入成功事件 \{#create-a-loginsuccesshandler-class-to-handle-the-login-success-event} -我們將在成功登入後將使用者重定向到 `/user` 頁面。 +登入成功後將使用者導向 `/user` 頁面。 ```java title="CustomSuccessHandler.java" package com.example.securingweb; @@ -163,9 +163,9 @@ public class CustomSuccessHandler implements AuthenticationSuccessHandler { } ``` -#### 創建一個 LogoutSuccessHandler 類別來處理登出成功事件 \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} +#### 建立 LogoutSuccessHandler 類別以處理登出成功事件 \{#create-a-logoutsuccesshandler-class-to-handle-the-logout-success-event} -清除會話並將使用者重定向到主頁。 +清除 session 並將使用者導回首頁。 ```java title="CustomLogoutHandler.java" package com.example.securingweb; @@ -195,11 +195,11 @@ public class CustomLogoutHandler implements LogoutSuccessHandler { } ``` -#### 使用 `securityFilterChain` 更新 `WebSecurityConfig` 類別 \{#update-the-websecurityconfig-class-with-a-securityfilterchain} +#### 在 `WebSecurityConfig` 類別中加入 `securityFilterChain` \{#update-the-websecurityconfig-class-with-a-securityfilterchain} -[securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) 是一個負責處理傳入請求和回應的過濾器鏈。 +[securityFilterChain](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/DefaultSecurityFilterChain.html) 是一組負責處理進入請求與回應的過濾器鏈。 -我們將配置 `securityFilterChain` 以允許訪問主頁,並要求對所有其他請求進行驗證。使用 `CustomSuccessHandler` 和 `CustomLogoutHandler` 來處理登入和登出事件。 +我們將設定 `securityFilterChain` 允許首頁存取,其他請求則需驗證 (Authentication)。登入與登出事件分別交由 `CustomSuccessHandler` 與 `CustomLogoutHandler` 處理。 ```java title="WebSecurityConfig.java" import org.springframework.context.annotation.Bean; @@ -214,8 +214,8 @@ public class WebSecurityConfig { http .authorizeRequests(authorizeRequests -> authorizeRequests - .antMatchers("/", "/home").permitAll() // 允許訪問主頁 - .anyRequest().authenticated() // 所有其他請求需要驗證 + .antMatchers("/", "/home").permitAll() // 允許首頁存取 + .anyRequest().authenticated() // 其他請求需驗證 (Authentication) ) .oauth2Login(oauth2Login -> oauth2Login @@ -230,9 +230,9 @@ public class WebSecurityConfig { } ``` -### 創建主頁 \{#create-a-home-page} +### 建立首頁 \{#create-a-home-page} -(如果你的專案中已經有主頁,可以跳過此步驟) +(如果你的專案已有首頁可略過此步驟) ```java title="HomeController.java" package com.example.securingweb; @@ -251,19 +251,19 @@ public class HomeController { } ``` -此控制器將在使用者驗證後將其重定向到使用者頁面,否則將顯示主頁。在主頁上新增一個登入連結。 +此 controller 會在使用者已驗證時導向 user 頁面,否則顯示首頁。請在首頁加入登入連結。 ```html title="resources/templates/home.html"

Welcome!

-

Login with Logto

+

使用 Logto 登入

``` -### 創建使用者頁面 \{#create-a-user-page} +### 建立 user 頁面 \{#create-a-user-page} -創建一個新的控制器來處理使用者頁面: +建立新的 controller 處理 user 頁面: ```java title="UserController.java" package com.example.securingweb; @@ -299,13 +299,13 @@ public class UserController { } ``` -一旦使用者驗證成功,我們將從已驗證的 principal 物件中檢索 `OAuth2User` 資料。請參閱 [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) 和 [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html) 以獲取更多詳細資訊。 +使用者驗證後,我們會從已驗證的 principal 物件中取得 `OAuth2User` 資料。詳情請參閱 [OAuth2AuthenticationToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/client/authentication/OAuth2AuthenticationToken.html) 與 [OAuth2User](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/core/user/OAuth2User.html)。 -讀取使用者資料並將其傳遞給 `user.html` 模板。 +讀取使用者資料並傳遞給 `user.html` 模板。 ```html title="resources/templates/user.html" -

User Details

+

使用者資訊

name:
@@ -315,38 +315,38 @@ public class UserController {
- +
``` -#### 請求額外的宣告 (Claims) \{#request-additional-claims} +#### 請求額外宣告 (Claims) \{#request-additional-claims} -若要檢索額外的使用者資訊,你可以在 `application.properties` 檔案中新增額外的權限範圍 (Scopes)。例如,要請求 `email`、`phone` 和 `urn:logto:scope:organizations` 權限範圍,請在 `application.properties` 檔案中新增以下行: +若需取得更多使用者資訊,可在 `application.properties` 檔案中加入額外的權限範圍 (scopes)。例如,若要請求 `email`、`phone` 與 `urn:logto:scope:organizations` 權限範圍,請加入下列設定: ```properties title="application.properties" spring.security.oauth2.client.registration.logto.scope=openid,profile,offline_access,email,phone,urn:logto:scope:organizations ``` -然後你可以在 `OAuth2User` 物件中訪問額外的宣告 (Claims)。 +之後你就能在 `OAuth2User` 物件中存取這些額外宣告 (claims)。 ### 執行並測試應用程式 \{#run-and-test-the-application} -執行應用程式並導航至 `http://localhost:8080`。 +執行應用程式並前往 `http://localhost:8080`。 -- 你將看到帶有登入連結的主頁。 +- 你會看到首頁與登入連結。 - 點擊連結以使用 Logto 登入。 -- 驗證成功後,你將被重定向到顯示使用者詳細資訊的使用者頁面。 -- 點擊登出按鈕以登出。你將被重定向回主頁。 +- 驗證 (Authentication) 成功後,會被導向 user 頁面並顯示你的使用者資訊。 +- 點擊登出按鈕即可登出,並會被導回首頁。 -## 權限範圍 (Scopes) 和宣告 (Claims) \{#scopes-and-claims} +## 權限範圍 (Scopes) 與宣告 (Claims) \{#scopes-and-claims} -## 進一步閱讀 \{#further-readings} +## 延伸閱讀 \{#further-readings} diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx index a6518668a5f..e5b4976badb 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/secret-vault/federated-token-set.mdx @@ -8,100 +8,100 @@ import Availability from '@components/Availability'; -第三方權杖集(又稱聯邦權杖集)是一種儲存在 Logto [秘密保管庫](/secret-vault)中的秘密類型,用於安全管理由第三方身分提供者簽發的存取權杖 (Access token) 與重新整理權杖 (Refresh token)。當使用者透過社交或企業級單一登入 (SSO) 連接器驗證時,Logto 會將簽發的權杖儲存在保管庫中。這些權杖日後可被取出,代表使用者存取第三方 API,而無需再次驗證。 +第三方權杖集(又稱為聯邦權杖集,federated token set)是一種儲存在 Logto [秘密保管庫](/secret-vault)中的密鑰類型,用於安全管理由第三方身分提供者 (IdP) 發出的存取權杖 (Access token) 與重新整理權杖 (Refresh token)。當使用者透過社交或企業級單一登入 (SSO) 連接器進行驗證時,Logto 會將發出的權杖儲存在保管庫中。這些權杖日後可被取出,代表使用者存取第三方 API,而無需再次驗證。 ## 常見應用場景 \{#common-use-cases} -這項能力對於現代應用程式(如 AI 代理、SaaS 平台、生產力工具與需代表使用者與第三方服務互動的客戶應用程式)至關重要。以下是一些實際範例: +這項能力對於現代應用程式(如 AI 代理人、SaaS 平台、生產力工具與需代表使用者與第三方服務互動的客戶應用程式)至關重要。以下是一些實際範例: -**📅 行事曆管理應用**:使用者以 Google 登入後,你的生產力應用可自動同步行事曆事件、建立新會議並發送邀請,無需再次要求驗證。 +**📅 行事曆管理應用**:使用者以 Google 登入後,你的生產力應用可自動同步其行事曆事件、建立新會議並發送邀請,無需再次要求驗證。 -**🤖 AI 助理**:AI 代理可存取使用者的 GitHub 儲存庫以分析程式碼、建立 pull request 或管理議題。這一切僅需使用者在登入或帳號連結時一次性授權。 +**🤖 AI 助理**:AI 代理人可存取使用者的 GitHub 儲存庫,進行程式碼分析、建立 Pull Request 或管理議題。這一切僅需使用者在登入或帳號連結時一次性授權。 -**📊 分析儀表板**:SaaS 平台可從使用者連結的社群帳號(Facebook、LinkedIn)拉取資料,產生洞察與報告,無需重複登入中斷工作流程。 +**📊 分析儀表板**:SaaS 平台可從使用者連結的社群帳號(Facebook、LinkedIn)擷取資料,產生洞察與報告,無需重複登入中斷其工作流程。 ## 啟用第三方權杖儲存 \{#enable-third-party-token-storage} ### 社交連接器 \{#social-connectors} -此功能適用於支援權杖儲存的 [社交連接器](/connectors/social-connectors)。第三方權杖可於 [社交登入](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[社交帳號連結](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection)及[為第三方 API 存取續約權杖時](/secret-vault/federated-token-set#reauthentication-and-token-renewal)儲存。目前支援的連接器包括:[GitHub](/integrations/github)、[Google](/integrations/google)、[Facebook](/integrations/facebook)、[標準 OAuth 2.0](/integrations/oauth2) 及 [標準 OIDC](/integrations/oidc)。未來將陸續支援更多連接器。 +此功能適用於支援權杖儲存的 [社交連接器](/connectors/social-connectors)。第三方權杖可於 [社交登入](/end-user-flows/sign-up-and-sign-in/social-sign-in)、[社交帳號連結](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) 及 [為第三方 API 存取續約權杖時](/secret-vault/federated-token-set#reauthentication-and-token-renewal) 儲存。目前支援的連接器包括:[GitHub](/integrations/github)、[Google](/integrations/google)、[Facebook](/integrations/facebook)、[標準 OAuth 2.0](/integrations/oauth2)、[標準 OIDC](/integrations/oidc)。更多連接器將陸續支援。 1. 前往 Console > Connectors > Social Connectors。 2. 選擇你要啟用第三方權杖儲存的社交連接器。 -3. 依照設定教學配置連接器,包含新增存取特定第三方 API 所需的權限範圍 (scope)。 -4. 在「Setting」頁面啟用 **Store tokens for persistent API access** 選項。 +3. 依照設定教學配置連接器,包含新增存取特定第三方 API 所需的權限範圍 (Scopes)。 +4. 在「Setting」頁面啟用 **持久 API 存取權杖儲存 (Store tokens for persistent API access)** 選項。 ### 企業級 SSO 連接器 \{#enterprise-sso-connectors} -所有 OIDC [企業連接器](/connectors/enterprise-connectors)皆支援權杖儲存。存取權杖與重新整理權杖可於 [企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso) 時儲存。目前支援的連接器包括:[Google Workspace](/integrations/google-workspace)、[Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc)、[Okta](/integrations/okta) 及 [OIDC (Enterprise)](/integrations/oidc-sso)。 +所有 OIDC [企業連接器](/connectors/enterprise-connectors)皆支援權杖儲存。存取權杖與重新整理權杖可於 [企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso) 流程中儲存。目前支援的連接器包括:[Google Workspace](/integrations/google-workspace)、[Microsoft Entra ID (OIDC)](/integrations/entra-id-oidc)、[Okta](/integrations/okta)、[OIDC (Enterprise)](/integrations/oidc-sso)。 1. 前往 Console > Enterprise SSO。 2. 選擇你要啟用第三方權杖儲存的企業級 SSO 連接器。 -3. 依照設定教學配置連接器,包含新增存取特定第三方 API 所需的權限範圍 (scope)。 -4. 在「SSO Experience」分頁啟用 **Store tokens for persistent API access** 選項。 +3. 依照設定教學配置連接器,包含新增存取特定第三方 API 所需的權限範圍 (Scopes)。 +4. 在「SSO Experience」分頁啟用 **持久 API 存取權杖儲存 (Store tokens for persistent API access)** 選項。 請記得儲存你的變更。 ## 權杖儲存 \{#token-storage} -啟用第三方權杖儲存後,Logto 會在使用者透過社交或企業級 SSO 連接器驗證時,自動儲存由聯邦身分提供者簽發的存取權杖 (Access token) 與重新整理權杖 (Refresh token)。包含: +啟用第三方權杖儲存後,Logto 會在使用者透過社交或企業級 SSO 連接器驗證時,自動儲存由聯邦身分提供者發出的存取權杖 (Access token) 與重新整理權杖 (Refresh token)。包含: - [社交登入與註冊](/end-user-flows/sign-up-and-sign-in/social-sign-in) - [企業級 SSO 登入與註冊](/end-user-flows/enterprise-sso) - [透過帳號 API 進行社交帳號連結](/end-user-flows/account-settings/by-account-api#link-a-new-social-connection) -儲存的權杖會綁定於使用者的社交或企業級 SSO 身分,讓他們日後可取出權杖以存取 API,無需再次驗證。 +儲存的權杖會綁定於使用者的社交或企業級 SSO 身分,讓他們日後可於 API 存取時取回權杖,無需再次驗證。 ### 檢查權杖儲存狀態 \{#checking-token-storage-status} 你可以在 Logto Console 檢查使用者的第三方權杖儲存狀態: 1. 前往 Console > Users。 -2. 點擊你要檢查的使用者,進入該使用者詳細頁。 -3. 捲動至 **Connections** 區塊,這裡會列出所有與該使用者關聯的社交與企業級 SSO 連線。 +2. 點擊你要檢查的使用者,進入其詳細頁面。 +3. 捲動至 **Connections** 區塊,這裡列出所有與該使用者關聯的社交與企業級 SSO 連線。 4. 每個連線條目會顯示權杖狀態標籤,指示該連線是否有儲存權杖。 -5. 點擊連線條目可查看更多細節,包括儲存的存取權杖 (Access token) 中繼資料與重新整理權杖 (Refresh token) 是否可用(如有)。 +5. 點擊連線條目可查看更多細節,包括已儲存的存取權杖中繼資料與重新整理權杖可用性(如有)。 -你也可以透過管理 API 檢查使用者第三方身分與權杖儲存狀態: +你也可以透過 Management API 檢查使用者第三方身分與權杖儲存狀態: - `GET /api/users/{userId}/identities/{target}?includeTokenSecret=true`:根據指定連接器 target(如 `github`、`google` 等)查詢使用者的社交身分與權杖儲存狀態。 - `GET /api/users/{userId}/sso-identities/{ssoConnectorId}?includeTokenSecret=true`:根據指定 SSO 連接器 ID 查詢使用者的企業級 SSO 身分與權杖儲存狀態。 ### 權杖儲存狀態 \{#token-storage-status} -- **Active**:存取權杖 (Access token) 已儲存且有效。 -- **Expired**:存取權杖已儲存但已過期。若有重新整理權杖 (Refresh token),可用於取得新存取權杖。 +- **Active**:存取權杖已儲存且有效。 +- **Expired**:存取權杖已儲存但已過期。若有重新整理權杖,可用於取得新存取權杖。 - **Inactive**:此連線未儲存存取權杖。可能是使用者尚未透過此連線驗證,或權杖儲存已被刪除。 - **Not applicable**:此連接器不支援權杖儲存。 ### 權杖中繼資料 \{#token-metadata} -為確保資料完整性與安全性,所有權杖在儲存進秘密保管庫前皆會加密。實際權杖值僅授權的終端使用者可存取。開發者僅能取得權杖集的中繼資料,以瞭解儲存狀態而不暴露敏感內容。 +為確保資料完整性與安全性,所有權杖在儲存至秘密保管庫前皆經過加密。實際權杖值僅授權的終端使用者可存取。開發者僅能取得權杖集的中繼資料,以瞭解儲存狀態而不暴露敏感內容。 -- `createdAt`:首次建立連線並將權杖集儲存進秘密保管庫的時間戳記。 +- `createdAt`:首次建立連線並將權杖集儲存至秘密保管庫的時間戳。 - `updatedAt`:權杖集最後一次更新的時間。 - - 若無重新整理權杖,該值與 **createdAt** 相同。 - - 若有重新整理權杖,該值反映最近一次存取權杖被刷新時的時間。 + - 若無重新整理權杖,此值與 **createdAt** 相同。 + - 若有重新整理權杖,此值反映最近一次存取權杖被刷新時的時間。 - `hasRefreshToken`:是否有重新整理權杖可用。 - 若連接器支援離線存取且授權請求正確配置,Logto 會在身分提供者簽發時同時儲存重新整理權杖與存取權杖。 - 當存取權杖過期且有有效重新整理權杖時,Logto 會在使用者請求存取連接的服務時自動嘗試以重新整理權杖取得新存取權杖。 -- `expiresAt`:存取權杖預估過期時間(單位:秒)。 - 根據身分提供者權杖端點回傳的 `expires_in` 計算。(僅當提供者回傳 `expires_in` 時才有此欄位。) + 若連接器支援離線存取且授權請求正確配置,Logto 會在身分提供者發出時同時儲存重新整理權杖與存取權杖。 + 當存取權杖過期且有有效重新整理權杖時,Logto 會在使用者請求存取連接的提供者時自動嘗試以重新整理權杖取得新存取權杖。 +- `expiresAt`:存取權杖的預估過期時間(單位:**秒**)。 + 此值根據身分提供者權杖端點回傳的 `expires_in` 計算。(僅當提供者回傳 `expires_in` 時才有此欄位。) - `scope`:存取權杖的權限範圍,表示身分提供者授予的權限。 有助於瞭解儲存的存取權杖可執行哪些操作。(僅當提供者回傳 `scope` 時才有此欄位。) -- `tokenType`:存取權杖型態,通常為 "Bearer"。 +- `tokenType`:存取權杖的型別,通常為 "Bearer"。 (僅當提供者回傳 `token_type` 時才有此欄位。) ## 權杖擷取 \{#token-retrieval} -啟用權杖儲存並將權杖安全儲存於 Logto 秘密保管庫後,終端使用者可透過你的客戶端應用程式,結合 Logto 的 [使用者帳號 API](/end-user-flows/account-settings/by-account-api) 取得第三方存取權杖。 +啟用權杖儲存並將權杖安全儲存於 Logto 秘密保管庫後,終端使用者可透過你的用戶端應用程式,整合 Logto [Account API](/end-user-flows/account-settings/by-account-api) 來擷取其第三方存取權杖。 -- `GET /my-account/identities/:target/access-token`:指定連接器 target(如 github、google)取得社交身分的存取權杖。 +- `GET /my-account/identities/:target/access-token`:指定連接器 target(如 github、google)以取得社交身分的存取權杖。 -- `GET /my-account/sso-identities/:connectorId/access-token`:指定連接器 ID 取得企業級 SSO 身分的存取權杖。 +- `GET /my-account/sso-identities/:connectorId/access-token`:指定連接器 ID 以取得企業級 SSO 身分的存取權杖。 :::info -瞭解如何[啟用](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api)與[存取](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token)帳號 API(使用 Logto 簽發的存取權杖)。 +要擷取第三方存取權杖,必須先於 Console > Sign-in & Account > Account center 為終端使用者啟用 Account API。請參閱[如何啟用 Account API](/end-user-flows/account-settings/by-account-api#how-to-enable-account-api) 及[如何使用 Logto 發出的存取權杖存取 Account API](/end-user-flows/account-settings/by-account-api#access-account-api-using-access-token)。 ::: ### 權杖輪替 \{#token-rotation} @@ -112,15 +112,15 @@ import Availability from '@components/Availability'; - `404` Not Found:使用者未有指定 target 或連接器 ID 的社交或企業級 SSO 身分,或未儲存存取權杖。 - `401` Unauthorized:存取權杖已過期。 -若存取權杖已過期且有重新整理權杖,Logto 會自動嘗試刷新存取權杖並於回應中回傳新權杖。秘密保管庫中的權杖儲存也會同步更新。 +若存取權杖已過期且有重新整理權杖,Logto 會自動嘗試刷新存取權杖,並於回應中回傳新存取權杖。秘密保管庫中的權杖儲存也會同步更新。 ## 權杖儲存刪除 \{#token-storage-deletion} 第三方權杖儲存直接綁定於每位使用者的社交或企業級 SSO 連線。這表示在下列情況下,儲存的權杖集會自動刪除: - 關聯的社交或企業級 SSO 身分自使用者帳號移除。 -- 使用者帳號自你的租戶中刪除。 -- 社交或企業級 SSO 連接器自你的租戶中刪除。 +- 使用者帳號自租戶中刪除。 +- 社交或企業級 SSO 連接器自租戶中刪除。 ### 撤銷權杖 \{#revoking-tokens} @@ -128,19 +128,19 @@ import Availability from '@components/Availability'; - 透過 Console: 前往使用者身分詳細頁,捲動至 **Access token** 區塊(如有權杖儲存),點擊區塊底部的 **Delete tokens** 按鈕。 -- 透過管理 API: - - `DELETE /api/secret/:id`:根據身分詳細頁取得的 ID 刪除指定秘密。 +- 透過 Management API: + - `DELETE /api/secret/:id`:根據 ID 刪除特定密鑰,可於使用者身分詳細頁取得 ID。 -撤銷權杖集後,使用者需再次與第三方提供者驗證,才能取得新存取權杖並再次存取第三方 API。 +撤銷權杖集後,使用者需重新與第三方提供者驗證,才能再次取得存取權杖並存取第三方 API。 ## 重新驗證與權杖續期 \{#reauthentication-and-token-renewal} -當儲存的存取權杖已過期,或應用程式需請求額外 API 權限範圍時,終端使用者可重新驗證第三方提供者以取得新存取權杖——無需再次登入 Logto。 -這可透過 Logto 的 [Social Verification API](https://openapi.logto.io/operation/operation-createverificationbysocial) 實現,允許使用者重新啟動聯邦社交授權流程並更新儲存的權杖集。 +當儲存的存取權杖已過期,或應用程式需請求額外 API 權限範圍時,終端使用者可重新與第三方提供者驗證以取得新存取權杖——無需再次登入 Logto。 +這可透過 Logto [社交驗證 API](https://openapi.logto.io/operation/operation-createverificationbysocial) 實現,允許使用者重新啟動聯邦社交授權流程並更新其儲存的權杖集。 :::note 重新啟動聯邦授權目前僅限於社交連接器。 -對於企業級 SSO 連接器,重新驗證與權杖續期需使用者重新啟動完整 Logto 驗證流程,因目前尚不支援登入後直接與企業級 SSO 提供者重新授權。 +對於企業級 SSO 連接器,重新驗證與權杖續期需使用者重新啟動完整 Logto 驗證流程,因目前登入後不支援直接與企業級 SSO 提供者重新授權。 ::: ```mermaid @@ -154,13 +154,13 @@ sequenceDiagram User->>Logto: post /api/verification/social Logto->>User: 重新導向至第三方提供者 User->>Provider: 驗證並授權 - Provider->>User: 重新導向回帶有授權碼 - User->>Logto: post /api/verification/social/verify 並附上授權碼 + Provider->>User: 以授權碼導回 + User->>Logto: post /api/verification/social/verify,帶授權碼 Logto->>User: 回傳社交驗證 ID User->>Logto: patch /my-account/identities/:target/access-token ``` -1. 使用者呼叫 `POST /api/verification/social` 端點發起社交驗證請求。可指定自訂權限範圍 (scope) 以請求第三方提供者額外權限。 +1. 使用者呼叫 `POST /api/verification/social` 端點發起社交驗證請求。可指定自訂權限範圍 (Scopes) 以請求第三方提供者額外權限。 ```sh curl -X POST https:///api/verification/social \ @@ -174,12 +174,12 @@ sequenceDiagram }' ``` - - **authorization header**:Logto 簽發的使用者存取權杖。 + - **authorization header**:Logto 發出的使用者存取權杖。 - **connectorId**:Logto 中的社交連接器 ID。 - - **redirectUri**:驗證後將使用者導回你應用程式的 URI。你需在提供者應用程式設定中註冊此 URI。 + - **redirectUri**:驗證後將使用者導回應用程式的 URI。需於提供者應用程式設定中註冊此 URI。 - **scope**:(選填)自訂權限範圍,請求第三方提供者額外權限。未指定則使用連接器預設權限範圍。 -2. Logto 建立新的社交驗證紀錄,並回傳社交驗證 ID 及授權 URL,讓你將使用者導向第三方提供者進行驗證。 +2. Logto 建立新的社交驗證紀錄,並回傳社交驗證 ID 及授權 URL,供你將使用者導向第三方提供者進行驗證。 回應範例如下: @@ -193,9 +193,9 @@ sequenceDiagram 3. 將使用者導向授權 URL。使用者於第三方提供者驗證並授權。 -4. 第三方提供者將使用者導回你的應用程式,並附上授權碼。 +4. 第三方提供者以授權碼將使用者導回你的用戶端應用程式。 -5. 處理授權回呼,將授權碼轉發至 Logto 的驗證端點: +5. 處理授權回呼,將授權碼轉發至 Logto 驗證端點: ```sh curl -X POST https:///api/verification/social/verify \ @@ -210,9 +210,9 @@ sequenceDiagram }' ``` - - **authorization header**:Logto 簽發的使用者存取權杖。 + - **authorization header**:Logto 發出的使用者存取權杖。 - **verificationRecordId**:前一步回傳的社交驗證 ID。 - - **connectorData**:授權碼及第三方提供者於回呼時回傳的其他資料。 + - **connectorData**:授權回呼時第三方提供者回傳的授權碼及其他資料。 :::note 請務必驗證 `state` 參數以防止 CSRF 攻擊。 @@ -220,7 +220,7 @@ sequenceDiagram 6. Logto 驗證授權碼,並向第三方提供者換取新存取權杖與重新整理權杖,然後於回應中回傳社交驗證 ID。 -7. 最後,呼叫 `PATCH /my-account/identities/:target/access-token` 端點並附上社交驗證 ID,更新使用者的權杖儲存: +7. 最後,呼叫 `PATCH /my-account/identities/:target/access-token` 端點,帶入社交驗證 ID,更新使用者的權杖儲存: ```sh curl -X PATCH https:///my-account/identities//access-token \ @@ -231,8 +231,8 @@ sequenceDiagram }' ``` - - **authorization header**:Logto 簽發的使用者存取權杖。 - - **socialVerificationId**:前一步回傳的社交驗證紀錄 ID。 + - **authorization header**:Logto 發出的使用者存取權杖。 + - **socialVerificationId**:前一步回傳的已驗證社交驗證紀錄 ID。 這將以新存取權杖與重新整理權杖更新 Logto 秘密保管庫中的使用者權杖集,讓使用者無需再次登入 Logto 即可存取第三方 API。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/blocklist.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/blocklist.md index 262bfcaaf5d..12059414bcf 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/blocklist.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/blocklist.md @@ -8,9 +8,9 @@ sidebar_position: 3 ## 電子郵件封鎖清單 (Email blocklist) {#email-blocklist} -電子郵件封鎖清單政策允許你自訂電子郵件封鎖規則,以防止帳號註冊濫用。系統會監控用於註冊與帳號設定的電子郵件地址。如果使用者嘗試註冊或連結違反任何封鎖規則的電子郵件地址,系統將拒絕該請求,有助於減少垃圾帳號並提升整體帳號安全性。 +電子郵件封鎖清單政策允許你自訂電子郵件封鎖規則,以防止帳號註冊濫用。系統會監控用於註冊與帳號設定的電子郵件地址。若使用者嘗試註冊或連結違反任何封鎖規則的電子郵件地址,系統將拒絕該請求,有助於減少垃圾帳號並提升整體帳號安全性。 -請前往 主控台 (Console) > 安全性 (Security) > 封鎖清單 (Blocklist) 設定電子郵件封鎖清單。 +請前往 主控台 > 安全性 > 封鎖清單 (Blocklist) 設定電子郵件封鎖規則。 ### 封鎖一次性電子郵件地址 (Block disposable email addresses) {#block-disposable-email-addresses} @@ -18,23 +18,23 @@ sidebar_position: 3 ### 封鎖電子郵件子地址 (Block email subaddressing) {#block-email-subaddressing} -電子郵件子地址 (subaddressing) 允許使用者在電子郵件地址中加入加號(+)及額外字元來產生變化(例如 user+tag@example.com)。惡意使用者可能利用此功能繞過封鎖規則。啟用封鎖電子郵件子地址功能後,系統將拒絕所有使用子地址格式進行註冊或帳號連結的請求。 +電子郵件子地址 (subaddressing) 允許使用者在電子郵件地址中加入加號(+)及額外字元(例如 user+tag@example.com)來產生變化。惡意使用者可能利用此功能繞過封鎖規則。啟用封鎖電子郵件子地址功能後,系統將拒絕所有使用子地址格式進行註冊或帳號連結的請求。 ### 自訂電子郵件封鎖清單 (Custom email blocklist) {#custom-email-blocklist} -你可以自訂電子郵件封鎖清單,指定要封鎖的電子郵件地址或網域。系統將拒絕所有符合這些條件的註冊或帳號連結請求。封鎖清單同時支援完整電子郵件地址與網域比對。 +你可以自訂電子郵件封鎖清單,指定要封鎖的電子郵件地址或網域。系統會拒絕所有符合這些條件的註冊或帳號連結請求。封鎖清單同時支援完整電子郵件地址與網域比對。 -例如,將 `@example.com` 加入封鎖清單,將封鎖所有該網域的電子郵件地址。類似地,加入 `foo@example.com` 則只會封鎖該特定電子郵件地址。 +例如,將 `@example.com` 加入封鎖清單,將封鎖所有該網域的電子郵件地址。若加入 `foo@example.com`,則僅封鎖該特定電子郵件地址。 :::note -一次性電子郵件、子地址與自訂電子郵件封鎖僅在註冊與帳號連結時生效。現有使用這些電子郵件地址的使用者仍可登入。 +一次性電子郵件、子地址與自訂電子郵件封鎖規則,會在[新使用者註冊](/end-user-flows/sign-up-and-sign-in/sign-up)、[社交登入時收集註冊識別資訊](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers)、以及透過 [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email) 更新電子郵件時生效。已存在的使用者若已綁定這些電子郵件地址,仍可登入。 -- 管理員可在 主控台 (Console) > 使用者管理 (User management) 或透過 [Management API](https://openapi.logto.io/operation/operation-createuser)「繞過限制」手動新增使用者。例如:當子地址被封鎖時,仍可建立使用子地址的帳號。 -- 可在 主控台 (Console) > 使用者管理 (User management) 刪除或停用帳號以封鎖現有帳號。 +- 管理員可於 主控台 > 使用者管理 或透過 [Management API](https://openapi.logto.io/operation/operation-createuser)「繞過限制」手動新增使用者。例如:在封鎖子地址時,仍可建立使用子地址的帳號。 +- 若要封鎖現有帳號,請於 主控台 > 使用者管理 刪除或停用該帳號。 ::: -## 相關資源 {#related-resources} +## 相關資源 (Related resources) {#related-resources} 什麼是一次性電子郵件?如何在你的應用程式中處理? diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/password-policy.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/password-policy.mdx index 9df349f109c..508454f7bdb 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/password-policy.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/security/password-policy.mdx @@ -6,29 +6,36 @@ sidebar_position: 1 # 密碼政策 (Password Policy) -## 設定密碼政策 \{#set-up-password-policy} +Logto 會根據密碼的建立或更新方式,以不同方式套用密碼政策: -針對新使用者或更新密碼的使用者,你可以設定密碼政策來強制密碼強度要求。請前往 控制台 > 安全性 > 密碼政策 (Password policy) 進行密碼政策設定。 +- 端使用者流程,例如 [預設登入體驗](/end-user-flows/sign-up-and-sign-in/sign-up)、[使用體驗 API (Experience API)](/customization/bring-your-ui) 以及 [Account API](/end-user-flows/account-settings/by-account-api#update-users-password) 都會強制執行目前的 [密碼政策](#set-up-password-policy)。 +- 透過 Management API [`patch /api/users/{userId}/password`](https://openapi.logto.io/operation/operation-updateuserpassword) 進行的管理員操作則不受限制,讓你在需要時可不經政策檢查配置或重設憑證。 +- 若要依現行規則稽核現有密碼,請呼叫 [`POST /api/sign-in-exp/default/check-password`](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 並依回傳的驗證結果進行處理。詳情請參閱 [密碼合規性檢查](#password-compliance-check)。 -1. **最小密碼長度**:設定密碼所需的最少字元數。(NIST 建議至少使用 8 個 [字元](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) -2. **最少所需字元類型數**:設定密碼必須包含的最少字元類型數。可用的字元類型有: - 1. 大寫字母:`(A-Z)` - 2. 小寫字母:`(a-z)` - 3. 數字:`(0-9)` +## 設定密碼政策 (Set up password policy) \{#set-up-password-policy} + +針對新使用者或更新密碼的使用者,你可以設定密碼政策以強制密碼強度要求。請前往 控制台 > 安全性 > 密碼政策 (Password policy) 設定密碼政策。 + +1. **最小密碼長度**:設定密碼所需的最少字元數。(NIST 建議至少 8 個 [字元](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)) +2. **最少需包含的字元類型數**:設定密碼需包含的最少字元類型數。可用的字元類型有: + 1. 大寫字母:(A-Z) + 2. 小寫字母:(a-z) + 3. 數字:(0-9) 4. 特殊字元:``(!"#$%&'()\*+,-./:;<>=?@[]^\_`|{}~ )`` -3. **資料外洩歷史檢查**:啟用此設定可拒絕曾在資料外洩事件中曝光過的密碼。(由 [Have I Been Pwned](https://haveibeenpwned.com/Passwords) 提供支援) -4. **重複字元檢查**:啟用此設定可拒絕包含重複字元的密碼。(例如:"11111111" 或 "password123") +3. **資料外洩歷史檢查**:啟用此設定可拒絕曾在資料外洩事件中出現過的密碼。(由 [Have I Been Pwned](https://haveibeenpwned.com/Passwords) 提供支援) +4. **重複字元檢查**:啟用此設定可拒絕包含重複字元的密碼。(例如 "11111111" 或 "password123") 5. **使用者資訊檢查**:啟用此設定可拒絕包含使用者資訊(如使用者名稱、電子郵件地址或電話號碼)的密碼。 -6. **自訂關鍵字**:提供一組自訂關鍵字(不區分大小寫),密碼中若包含這些關鍵字將被拒絕。 +6. **自訂關鍵字**:提供一組自訂(不區分大小寫)關鍵字,密碼中若包含這些字詞將被拒絕。 -## 密碼合規性檢查 \{#password-compliance-check} +## 密碼合規性檢查 (Password compliance check) \{#password-compliance-check} 當你在 Logto 更新密碼政策後,現有使用者仍可使用原有密碼登入。只有新建立的帳號才會被要求遵循最新政策。 -若需強制更高安全性,你可以使用 `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 來檢查使用者密碼是否符合預設登入體驗中定義的現行政策。若不符合,你可以透過自訂流程,利用 [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) 提示使用者更新密碼。 +為加強安全性,你可以使用 `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 檢查使用者密碼是否符合預設登入體驗下的現行政策。若不符合,可透過自訂流程搭配 [Account API](/end-user-flows/account-settings/by-account-api) 提示使用者更新密碼。 -## 相關資源 \{#related-resources} +## 相關資源 (Related resources) \{#related-resources} - - 設計你的密碼政策 (Design your password policy) - +管理使用者 +註冊與登入 +透過 Account API 設定帳號 +設計你的密碼政策 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx index 5cdbc9a0d7f..ad704fcf50d 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/manage-users.mdx @@ -8,8 +8,7 @@ sidebar_position: 2 ### 瀏覽與搜尋使用者 \{#browse-and-search-users} -要在 Logto Console 存取使用者管理功能,請前往 Console > 使用者管理 -。進入後,你會看到所有使用者的表格檢視。 +要在 Logto Console 存取使用者管理功能,請前往 Console > 使用者管理。進入後,你會看到所有使用者的表格檢視。 此表格包含三個欄位: @@ -17,21 +16,21 @@ sidebar_position: 2 - **來自應用程式**:顯示該使用者最初註冊時所用的應用程式名稱 - **最近登入**:顯示使用者最近一次登入的時間戳記 -支援 [`name`](/user-management/user-data#name)、[`id`](/user-management/user-data#id)、[`username`](/user-management/user-data#username)、[`primary-phone`](/user-management/user-data#primary_phone)、[`primary-email`](/user-management/user-data#primary_email) 的關鍵字對應搜尋。 +支援針對 [`name`](/user-management/user-data#name)、[`id`](/user-management/user-data#id)、[`username`](/user-management/user-data#username)、[`primary-phone`](/user-management/user-data#primary_phone)、[`primary-email`](/user-management/user-data#primary_email) 進行關鍵字對應搜尋。 ### 新增使用者 \{#add-users} 開發者可透過 Console 為終端使用者建立新帳號。只需點擊畫面右上角的「新增使用者」按鈕。 -在 Logto Console 或透過 Management API 建立使用者時(非終端使用者自行 UI 註冊),你必須至少提供一個識別資訊:`primary email`、`primary phone` 或 `username`。`name` 欄位為選填。 +在 Logto Console 或透過 Management API 建立使用者時(非使用者自行於 UI 註冊),必須至少提供一個識別資訊:`primary email`、`primary phone` 或 `username`。`name` 欄位為選填。 -使用者建立後,Logto 會自動產生一組隨機密碼。初始密碼僅顯示一次,但你可以之後[重設密碼](./manage-users#reset-user-password)。若想設定特定密碼,請於建立後使用 Management API `patch /api/users/{userId}/password` 進行更新。 +使用者建立後,Logto 會自動產生一組隨機密碼。初始密碼僅會顯示一次,但你可於後續 [重設密碼](./manage-users#reset-user-password)。若需指定密碼,請於建立後使用 Management API `patch /api/users/{userId}/password` 進行更新。 -你可以一鍵複製**輸入的識別資訊(電子郵件 / 電話號碼 / 使用者名稱)**與**初始密碼**,方便將這些憑證分享給新使用者,讓他們登入並開始使用。 +你可一鍵複製**輸入的識別資訊(電子郵件 / 電話號碼 / 使用者名稱)**與**初始密碼**,方便將這些憑證分享給新使用者,讓他們能立即登入並開始使用。 :::tip -若你想實作僅限邀請註冊,建議[以魔術連結邀請使用者](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended)。這樣僅白名單使用者能自行註冊並設定密碼。 +若你想實作僅限邀請註冊,建議使用 [魔術連結邀請使用者](/end-user-flows/sign-up-and-sign-in/disable-user-registration#option-1-invite-user-with-magic-link-recommended)。這樣僅白名單使用者可自行註冊並設定密碼。 ::: @@ -44,59 +43,72 @@ sidebar_position: 2 - **電話號碼**([primary_phone](/user-management/user-data#primary_phone)):可編輯 - **使用者名稱**([username](/user-management/user-data#username)):可編輯 - **密碼**([has_password](/user-management/user-data#has_password)):可重新產生隨機密碼。詳見「[重設使用者密碼](#reset-user-password)」。 - - **社交連結**([identities](/user-management/user-data#social-identities)):檢視已綁定的社交帳號與社交 ID。例如,若使用者以 Facebook 登入,會在清單中看到「Facebook」項目。你可在 Console 移除已綁定的社交身分,但無法代替終端使用者新增新的社交連結。 - - **企業級單一登入 (Enterprise SSO) 連結**([sso_identities](/user-management/user-data#sso-identities)):檢視已綁定的企業身分。Console 無法新增或移除 SSO 身分。 - - **多重要素驗證 (MFA, Multi-factor authentication)**([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)):檢視此使用者已設置的所有驗證因子(如通行密鑰、驗證器 App、備用碼),可於 Console 移除驗證因子。 + - **多重要素驗證 (Multi-factor authentication)**([mfa_verification_factor](/user-management/user-data#mfa_verification_factors)):檢視該使用者已設定的所有驗證因子(如通行密鑰、驗證器 App、備用代碼),可於 Console 移除因子。 - **個人存取權杖 (Personal access token)**:建立、檢視、重新命名與刪除 [個人存取權杖](/user-management/personal-access-token)。 -- **使用者檔案資料**:姓名、頭像網址、自訂資料,以及其他未列出的 OpenID Connect 標準宣告。這些檔案欄位皆可編輯。 +- **連線**: + - **社交連線 (Social connections)**([identities](/user-management/user-data#social-identities)): + - 檢視使用者已連結的社交帳號,包括社交 ID 及從社交平台同步的個人資料(如使用 Facebook 登入則會顯示「Facebook」)。 + - 可移除現有社交身分,但無法代替使用者新增新社交帳號。 + - 對於啟用 [權杖儲存](/secret-vault/federated-token-set) 的社交連接器,可於連線詳情頁檢視與管理存取權杖 (Access tokens) 與重新整理權杖 (Refresh tokens)。 + - **企業級單一登入 (Enterprise SSO) 連線**([sso_identities](/user-management/user-data#sso-identities)): + - 檢視使用者已連結的企業身分,包括企業 ID 及從企業身分提供者同步的個人資料。 + - 無法於 Console 新增或移除企業 SSO 身分。 + - 對於基於 OIDC 的企業連接器且啟用 [權杖儲存](/secret-vault/federated-token-set) 時,可於連線詳情頁檢視與刪除權杖。 +- **使用者檔案資料**:姓名、頭像網址、自訂資料,以及其他未列出的 OpenID Connect 標準宣告。這些欄位皆可編輯。 :::warning -在移除社交連結前,請確認使用者有其他登入方式,例如另一個社交連結、電話號碼、電子郵件或使用者名稱 / 密碼。若無其他登入方式,移除後該使用者將無法再次存取帳號。 +在移除社交連線前,請務必確認該使用者還有其他登入方式,例如其他社交連線、電話號碼、電子郵件或使用者名稱加密碼。若無其他登入方式,移除後該使用者將無法再次存取帳號。 ::: ### 檢視使用者活動紀錄 \{#view-user-activities} -要檢視使用者近期活動,請至「使用者詳情」頁的「使用者日誌」子分頁。這裡有一個表格,顯示使用者最近的操作、結果、相關應用程式與操作時間。 +要檢視使用者近期活動,請於「使用者詳情」頁面切換至「使用者日誌」子分頁。這裡會顯示一個表格,列出使用者近期活動,包括執行動作、結果、相關應用程式及執行時間。 點擊表格列可查看更多日誌細節,例如 IP 位址、使用者代理、原始資料等。 ### 停用使用者 \{#suspend-user} -在「使用者詳情」頁,點擊「三點」->「停用使用者」按鈕。 +於「使用者詳情」頁面,點擊「三點」->「停用使用者」按鈕。 -使用者被停用後,將無法登入你的應用程式,且現有存取權杖過期後無法再取得新的存取權杖。此外,該使用者發出的任何 API 請求都會失敗。 +使用者被停用後,將無法登入你的應用程式,且現有存取權杖 (Access token) 失效後無法再取得新權杖。此外,該使用者發出的任何 API 請求都會失敗。 -若要重新啟用此使用者,可點擊「三點」->「重新啟用使用者」按鈕。 +若需重新啟用該使用者,可點擊「三點」->「重新啟用使用者」按鈕。 ### 刪除使用者 \{#delete-user} -在「使用者詳情」頁,點擊「三點」->「刪除」按鈕。刪除使用者無法復原。 +於「使用者詳情」頁面,點擊「三點」->「刪除」按鈕。刪除後無法復原。 ### 重設使用者密碼 \{#reset-user-password} -在「使用者詳情」頁,點擊「三點」->「重設密碼」按鈕,Logto 會自動重新產生一組隨機密碼。 +於「使用者詳情」頁面,點擊「三點」->「重設密碼」按鈕,Logto 將自動重新產生一組隨機密碼。 -重設密碼後,請複製並傳送給終端使用者。關閉「重設密碼」視窗後將無法再次查看密碼,若忘記保存可再次重設。 +重設密碼後,請複製並傳送給終端使用者。關閉「重設密碼」視窗後將無法再次檢視密碼,若忘記保存可再次重設。 你無法在 Logto Console 為使用者設定特定密碼,但可透過 [Management API](/integrate-logto/interact-with-management-api) `PATCH /api/users/{userId}/password` 指定密碼。 -### 管理使用者角色 (Roles) \{#manage-roles-of-users} +## 密碼合規性檢查 \{#password-compliance-check} -在使用者詳情頁的「角色 (Roles)」分頁,你可以輕鬆指派或移除角色以達到預期效果。詳見 [角色型存取控制 (RBAC)](/authorization/role-based-access-control)。 +當你於 Logto 更新 [密碼政策](/security/password-policy) 後,現有使用者仍可用原密碼登入。僅新建立帳號需遵循最新密碼政策。 -### 檢視使用者所屬組織 (Organizations) \{#view-the-organizations-the-user-belongs-to} +為強化安全性,你可使用 `POST /api/sign-in-exp/default/check-password` [API](https://openapi.logto.io/operation/operation-checkpasswordwithdefaultsigninexperience) 檢查使用者密碼是否符合預設登入體驗下的現行政策。若不符合,可透過 [Account API](/end-user-flows/account-settings/by-management-api#user-password-management) 自訂流程提示使用者更新密碼。 -Logto 支援 [組織 (Organizations)](/organizations/organization-management) 並可管理其成員。你可輕鬆檢視使用者詳情並查看其所屬組織。 +### 管理使用者角色 \{#manage-roles-of-users} + +在使用者詳情頁的「角色」分頁,你可輕鬆指派或移除角色以達成所需權限。詳見 [角色型存取控制 (RBAC)](/authorization/role-based-access-control)。 + +### 檢視使用者所屬組織 \{#view-the-organizations-the-user-belongs-to} + +Logto 支援 [組織](/organizations/organization-management) 並可管理其成員。你可輕鬆檢視使用者詳情及其所屬組織。 ## 透過 Logto Management API 管理 \{#manage-via-logto-management-api} [Management API](/concepts/core-service/#management-api) 是一組存取 Logto 後端服務的 API。如前所述,使用者 API 是此服務的重要組件,可支援多種情境。 -與使用者相關的 [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API 掛載於 `/api/users`,但使用者活動紀錄(即使用者日誌)則為 `/api/logs?userId=:userId`。 +與使用者相關的 [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) API 掛載於 `/api/users`,使用者活動(即使用者日誌)則為 `/api/logs?userId=:userId`。 -你可以在多種情境下透過 Management API 管理使用者,例如 [進階使用者搜尋](/user-management/advanced-user-search)、[批次建立帳號](https://openapi.logto.io/operation/operation-createuser)、[僅限邀請註冊](/end-user-flows/sign-up-and-sign-in/disable-user-registration) 等。 +你可於多種情境下透過 Management API 管理使用者,例如 [進階使用者搜尋](/user-management/advanced-user-search)、[批次建立帳號](https://openapi.logto.io/operation/operation-createuser)、[僅限邀請註冊](/end-user-flows/sign-up-and-sign-in/disable-user-registration) 等。 ## 常見問題 \{#faqs} @@ -108,8 +120,8 @@ Logto 支援 [組織 (Organizations)](/organizations/organization-management) -由於 Logto 的 [Omni-sign-in](https://logto.io/products/omni-sign-in) 特性,設計上不支援在驗證 (Authentication) 前限制使用者存取特定應用程式。 -不過,你仍可設計應用程式專屬的使用者角色 (Roles) 與權限 (Permissions) 來保護你的 API 資源,並於使用者成功登入後在 API 存取時驗證權限。 +由於 Logto 的 [Omni-sign-in](https://logto.io/products/omni-sign-in) 特性,設計上並非用於於驗證 (Authentication) 前限制使用者存取特定應用程式。 +不過,你仍可設計應用程式專屬的使用者角色與權限來保護你的 API 資源,並於使用者成功登入後於 API 存取時驗證權限。 詳見授權 (Authorization):[角色型存取控制 (RBAC)](/authorization/role-based-access-control)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/user-data.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/user-data.mdx index 7350b8e073f..7ddee7dc38f 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/user-data.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/user-management/user-data.mdx @@ -4,7 +4,7 @@ sidebar_position: 1 # 使用者資料結構 -使用者是身分服務的核心實體。在 Logto 中,使用者包含基於 [OpenID Connect](https://auth.wiki/openid-connect) 協議的基本驗證 (Authentication) 資料,以及自訂資料。 +使用者是身分服務的核心實體。在 Logto 中,使用者資料包含基於 [OpenID Connect](https://auth.wiki/openid-connect) 協議的基本驗證 (Authentication) 資料,以及自訂資料。 ## 使用者檔案 \{#user-profile} @@ -12,9 +12,9 @@ sidebar_position: 1 其內容包含以下類型的資料: -- [基本資料](/user-management/user-data#basic-data):來自使用者檔案的基本資訊。儲存除了社交 `identities` 與 `custom_data` 以外的所有 _user_ 屬性,例如使用者 ID、使用者名稱、電子郵件、手機號碼,以及最後一次登入時間。 +- [基本資料](/user-management/user-data#basic-data):來自使用者檔案的基本資訊。儲存除了社交 `identities` 和 `custom_data` 以外的所有 _使用者_ 屬性,例如使用者 ID、使用者名稱、電子郵件、手機號碼,以及最近一次登入時間。 - [社交身分](/user-management/user-data#social-identities):儲存從社交登入(即透過社交連接器登入)取得的使用者資訊,例如 Facebook、GitHub 和 WeChat。 -- [自訂資料](/user-management/user-data#custom-data):儲存未列於預設使用者屬性中的額外資訊,例如使用者偏好的顏色與語言。 +- [自訂資料](/user-management/user-data#custom-data):儲存未列於預設使用者屬性中的額外資訊,例如使用者偏好的顏色和語言。 以下是一個從 Facebook 登入取得的使用者資料範例: @@ -52,39 +52,43 @@ sidebar_position: 1 ## 基本資料 \{#basic-data} -以下將逐一說明使用者 _基本資料_ 的所有屬性。 +以下將逐一說明 _基本資料_ 中的所有屬性。 ### id \{#id} -_id_ 是 Logto 中用來識別使用者的唯一自動產生鍵值。 +_id_ 是 Logto 中用來唯一識別使用者的自動產生鍵值。 ### username \{#username} -_username_ 用於以 _username_ 與密碼登入。 +_username_ 用於以 _使用者名稱_ 和密碼登入。 -其值來自使用者首次註冊時填寫的使用者名稱。可能為 `null`。非 null 值最長 128 字元,只能包含字母、數字與底線(`_`),且不得以數字開頭。區分大小寫。 +其值來自使用者首次註冊時填寫的使用者名稱。可能為 `null`。非 null 值長度不得超過 128 字元,只能包含英文字母、數字和底線(`_`),且不得以數字開頭。區分大小寫。 ### primary_email \{#primary_email} -_primary_email_ 是使用者的電子郵件地址,用於以電子郵件與密碼 / 驗證碼登入。 +_primary_email_ 是使用者的電子郵件地址,用於以電子郵件和密碼 / 驗證碼登入。 -其值通常來自使用者首次註冊時填寫的電子郵件。可能為 `null`。最大長度為 128。 +其值通常來自使用者首次註冊時填寫的電子郵件地址。可能為 `null`。最大長度為 128。 + +只有經過驗證的電子郵件地址(來自社交或企業級單一登入 (SSO) 身分提供者)才能同步並儲存為 `primary_email`。 ### primary_phone \{#primary_phone} -_primary_phone_ 是使用者的手機號碼,用於以手機號碼與密碼 / 簡訊驗證碼登入。 +_primary_phone_ 是使用者的手機號碼,用於以手機號碼和密碼 / 簡訊驗證碼登入。 其值通常來自使用者首次註冊時填寫的手機號碼。可能為 `null`。非 null 值應包含以[國碼](https://en.wikipedia.org/wiki/List_of_country_calling_codes)(不含加號 `+`)開頭的數字。 +只有經過驗證的手機號碼(來自社交或企業級單一登入 (SSO) 身分提供者)才能同步並儲存為 `primary_phone`。 + ### name \{#name} -_name_ 是使用者全名。最大長度為 128。 +_name_ 是使用者的全名。最大長度為 128。 ### avatar \{#avatar} _avatar_ 是指向使用者頭像圖片的 URL。最大長度為 2048。 -若使用者透過 Google、Facebook 等社交連接器註冊,該值可能來自社交平台的使用者資訊。 +若使用者透過 Google、Facebook 等社交連接器註冊,該值可能來自社交使用者資訊。 :::note @@ -96,7 +100,7 @@ _avatar_ 是指向使用者頭像圖片的 URL。最大長度為 2048。 _profile_ 儲存額外的 OpenID Connect [標準宣告 (Standard Claims)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims),這些宣告未包含於使用者屬性中。 -其型別定義可參考 [此檔案](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6)。以下為型別定義複製內容: +其型別定義可參考[這個檔案](https://github.com/logto-io/logto/blob/HEAD/packages/schemas/src/foundations/jsonb-types/users.ts#L6)。以下為型別定義內容: ```tsx type UserProfile = Partial<{ @@ -128,7 +132,7 @@ type UserProfile = Partial<{ ::: -與其他標準宣告不同,`profile` 內的屬性僅在其值非空時才會包含於 [ID 權杖 (ID token)](https://auth.wiki/id-token) 或 userinfo 端點回應中,而其他標準宣告若值為空則會回傳 `null`。 +與其他標準宣告不同的是,`profile` 中的屬性僅在其值不為空時,才會包含於 [ID 權杖 (ID token)](https://auth.wiki/id-token) 或 userinfo 端點回應中;而其他標準宣告若值為空則會回傳 `null`。 ### application_id \{#application_id} @@ -136,7 +140,7 @@ _application_id_ 的值來自使用者首次登入的應用程式。可能為 `n ### last_sign_in_at \{#last_sign_in_at} -_last_sign_in_at_ 為使用者上次登入時的帶時區時間戳記。 +_last_sign_in_at_ 為使用者最近一次登入時的帶時區時間戳記。 ### created_at \{#created_at} @@ -144,23 +148,23 @@ _created_at_ 為使用者註冊帳號時的帶時區時間戳記。 ### updated_at \{#updated_at} -_updated_at_ 為使用者檔案資訊最後更新時的帶時區時間戳記。 +_updated_at_ 為使用者檔案資訊最近一次更新時的帶時區時間戳記。 ### has_password \{#has_password} -_has_password_ 為布林值,表示使用者是否有設定密碼。你可以在 Console > 使用者管理 詳細頁面檢視與管理此狀態,包括設定新密碼或重設密碼。 +_has_password_ 是布林值,表示使用者是否有設定密碼。你可以在 Console > 使用者管理 詳細頁面檢視與管理此狀態,包括設定新密碼或重設密碼。 ### password_encrypted \{#password_encrypted} _password_encrypted_ 用於儲存使用者加密後的密碼。 -其值來自使用者首次註冊時填寫的密碼。可能為 `null`。若非 null,則加密前原始內容至少需六個字元。 +其值來自使用者首次註冊時填寫的密碼。可能為 `null`。若非 null,則加密前的原始內容至少需六個字元。 ### password_encryption_method \{#password_encryption_method} -_password_encryption_method_ 用於加密使用者密碼。其值於使用者以使用者名稱與密碼註冊時初始化。可能為 `null`。 +_password_encryption_method_ 用於加密使用者密碼。其值於使用者以使用者名稱和密碼註冊時初始化。可能為 `null`。 -Logto 預設採用 [Argon2](https://en.wikipedia.org/wiki/Argon2) 的 [node-argon2](https://github.com/ranisalt/node-argon2) 實作作為加密方法;詳情可參考相關說明。 +Logto 預設使用 [Argon2](https://en.wikipedia.org/wiki/Argon2) 的 [node-argon2](https://github.com/ranisalt/node-argon2) 實作作為加密方法;如有興趣可參考相關說明。 以下為密碼為 `123456` 的使用者 _password_encrypted_ 與 _password_encryption_method_ 範例: @@ -173,13 +177,13 @@ Logto 預設採用 [Argon2](https://en.wikipedia.org/wiki/Argon2) 的 [node-argo ### is_suspended \{#is_suspended} -_is_suspended_ 為布林值,表示使用者是否被停用。可透過 [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) 或 Logto Console 管理。 +_is_suspended_ 是布林值,表示使用者是否被停用。可透過 [Logto Management API](https://openapi.logto.io/operation/operation-updateuserissuspended) 或 Logto Console 管理此值。 -一旦使用者被停用,先前授予的重新整理權杖 (Refresh tokens) 將立即失效,且該使用者將無法再通過 Logto 驗證。 +一旦使用者被停用,先前授予的重新整理權杖 (Refresh tokens) 會立即失效,且該使用者將無法再通過 Logto 驗證。 ### mfa_verification_factors \{#mfa_verification_factors} -_mfa_verification_factors_ 是一個陣列,列出與使用者帳號關聯的[多重要素驗證 (MFA, Multi-factor authentication)](/end-user-flows/mfa) 方法。可能值包括:_Totp_(驗證器 App OTP)、_WebAuthn_(Passkey)、_BackupCode_。 +_mfa_verification_factors_ 是一個陣列,列出與使用者帳號關聯的[多重要素驗證 (MFA, Multi-factor authentication)](/end-user-flows/mfa) 方法。可能的值包括:_Totp_(驗證器 App OTP)、_WebAuthn_(Passkey)、_BackupCode_。 ```tsx mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; @@ -189,10 +193,10 @@ mfaVerificationFactors: ("Totp" | "WebAuthn" | "BackupCode")[]; _identities_ 包含從[社交登入](/end-user-flows/sign-up-and-sign-in/social-sign-in)(即透過[社交連接器](/connectors/social-connectors)登入)取得的使用者資訊。每個使用者的 _identities_ 以獨立 JSON 物件儲存。 -不同社交身分提供者(即社交平台)取得的資訊略有不同,通常包含: +使用者資訊依社交身分提供者(即社群平台)而異,通常包含以下內容: - 身分提供者的 _target_,如 "facebook" 或 "google" -- 使用者於該提供者的唯一識別碼 +- 使用者在該提供者下的唯一識別碼 - 使用者名稱 - 使用者已驗證的電子郵件 - 使用者頭像 @@ -226,9 +230,9 @@ _identities_ 包含從[社交登入](/end-user-flows/sign-up-and-sign-in/social- ## SSO 身分 \{#sso-identities} -_sso_identities_ 包含從[企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso)(即透過企業連接器進行單一登入 (SSO, Single Sign-On)](/connectors/enterprise-connectors))取得的使用者資訊。每個使用者的 _ssoIdentities_ 以獨立 JSON 物件儲存。 +_sso_identities_ 包含從[企業級單一登入 (Enterprise SSO)](/end-user-flows/enterprise-sso)(即透過企業連接器進行單一登入 (SSO, Single Sign-On) 登入](/connectors/enterprise-connectors))取得的使用者資訊。每個使用者的 _ssoIdentities_ 以獨立 JSON 物件儲存。 -從 SSO 身分提供者同步的資料取決於企業連接器設定的權限範圍 (Scopes)。以下為 TypeScript 型別定義: +從 SSO 身分提供者同步的資料取決於企業連接器所設定的權限範圍 (Scopes)。以下為 TypeScript 型別定義: ```ts type SSOIdentity = { @@ -242,9 +246,9 @@ type SSOIdentity = { _custom_data_ 儲存未列於預設使用者屬性中的額外資訊。 -你可以利用 _custom_data_ 完成以下用途: +你可以利用 _custom_data_ 完成以下事項: -- 記錄使用者是否完成特定操作,例如是否看過歡迎頁。 +- 記錄使用者是否已執行特定動作,例如是否看過歡迎頁。 - 在使用者檔案中儲存應用程式專屬資料,例如每個應用程式的偏好語言與外觀。 - 維護與使用者相關的其他任意資料。 @@ -274,7 +278,7 @@ _custom_data_ 儲存未列於預設使用者屬性中的額外資訊。 ::: -自訂資料可透過[自訂 JWT 權杖宣告 (Custom JWT token claims)](/developers/custom-token-claims) 在使用者登入後取得,而 JWT 權杖僅以 base64 編碼(非加密)並經常在網路間傳輸,任何敏感資料都容易外洩。 +自訂資料可透過[自訂 JWT 權杖宣告 (Custom JWT token claims)](/developers/custom-token-claims) 在使用者登入後存取,而 JWT 權杖僅以 base64 編碼(未加密),且經常在網路間傳輸,任何敏感資料都容易外洩。 你也可能透過 [Management API](https://openapi.logto.io/operation/operation-listusercustomdata) 取得包含 _custom_data_ 的使用者檔案,並傳送給前端應用程式或外部後端服務。因此,將敏感資訊放入 _custom_data_ 可能導致資料外洩。 @@ -284,14 +288,14 @@ _custom_data_ 儲存未列於預設使用者屬性中的額外資訊。 - 使用 [收集使用者檔案](/end-user-flows/collect-user-profile) 功能於註冊時收集自訂資料。 - 使用 [Account API](/end-user-flows/account-settings/by-account-api) 實作終端使用者檔案或帳號設定。 - - 透過 [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) 取得所有使用者資料。 - - 透過 [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) 更新使用者 _custom_data_。 + - 使用 [`GET /api/my-account`](https://openapi.logto.io/operation/operation-getprofile) 取得所有使用者資料。 + - 使用 [`PATCH /api/my-account`](https://openapi.logto.io/operation/operation-updateprofile) 更新使用者 _custom_data_。 - 使用 [Management API](/user-management/manage-users/#manage-via-logto-management-api) 進行使用者管理或進階自訂流程: - - 透過 [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) 取得所有使用者資料。 - - 透過 [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) 更新使用者 _custom_data_。 -- 你的支援團隊可直接於 Console > 使用者管理 更新使用者 _custom_data_。詳情請參閱[檢視與更新使用者檔案](/user-management/manage-users/#view-and-update-the-user-profile)。 + - 使用 [`GET /api/users/{userId}`](https://openapi.logto.io/operation/operation-getuser) 取得所有使用者資料。 + - 使用 [`PATCH /api/users/{userId}/custom-data`](https://openapi.logto.io/operation/operation-updateusercustomdata) 更新使用者 _custom_data_。 +- 你的客服團隊可直接於 Console > 使用者管理 更新使用者 _custom_data_。詳見[檢視與更新使用者檔案](/user-management/manage-users/#view-and-update-the-user-profile)。 -請謹慎操作。更新使用者 _custom_data_ 會完全覆蓋原有內容。 +請謹慎更新。更新使用者 _custom_data_ 會完全覆蓋原本儲存的內容。 例如,若你呼叫更新 _custom_data_ API 時的輸入如下(假設原本的 _custom_data_ 如前述範例): @@ -313,29 +317,29 @@ _custom_data_ 儲存未列於預設使用者屬性中的額外資訊。 } ``` -也就是說,更新後的欄位值與先前內容無關。 +也就是說,更新後的欄位值與先前的值無關。 ## 屬性參考 \{#property-reference} -下列 DB 使用者資料表欄位(_password_encrypted_ 與 _password_encryption_method_ 除外)皆可於使用者檔案中查詢,亦可透過 [Management API](https://openapi.logto.io/operation/operation-getuser) 查詢。 - -| 名稱 | 型別 | 說明 | 唯一 | 必填 | -| ----------------------------------------------------------------------------------- | --------- | --------------------------- | ---- | ---- | -| [id](/user-management/user-data#id) | string | 唯一識別碼 | ✅ | ✅ | -| [username](/user-management/user-data#username) | string | 用於登入的使用者名稱 | ✅ | ❌ | -| [primary_email](/user-management/user-data#primary_email) | string | 主要電子郵件 | ✅ | ❌ | -| [primary_phone](/user-management/user-data#primary_phone) | string | 主要手機號碼 | ✅ | ❌ | -| [name](/user-management/user-data#name) | string | 全名 | ❌ | ❌ | -| [avatar](/user-management/user-data#avatar) | string | 指向使用者頭像圖片的 URL | ❌ | ❌ | -| [profile](/user-management/user-data#profile) | object | 使用者檔案 | ❌ | ✅ | -| [identities](/user-management/user-data#social-identities) | object | 從社交登入取得的使用者資訊 | ❌ | ✅ | -| [custom_data](/user-management/user-data#custom-data) | object | 可自訂屬性中的額外資訊 | ❌ | ✅ | -| [application_id](/user-management/user-data#application_id) | string | 使用者首次註冊的應用程式 ID | ❌ | ✅ | -| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | 使用者上次登入時的時間戳記 | ❌ | ✅ | -| [password_encrypted](/user-management/user-data#password_encrypted) | string | 加密後的密碼 | ❌ | ❌ | -| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | 密碼加密方法 | ❌ | ❌ | -| [is_suspended](/user-management/user-data#is_suspended) | bool | 使用者停用標記 | ❌ | ✅ | -| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 驗證因子 | ❌ | ✅ | +下列表格中的 DB 使用者資料表欄位(_password_encrypted_ 與 _password_encryption_method_ 除外)皆可於使用者檔案中查詢,亦可透過 [Management API](https://openapi.logto.io/operation/operation-getuser) 查詢。 + +| 名稱 | 型別 | 說明 | 唯一 | 必填 | +| ----------------------------------------------------------------------------------- | --------- | ---------------------------- | ---- | ---- | +| [id](/user-management/user-data#id) | string | 唯一識別碼 | ✅ | ✅ | +| [username](/user-management/user-data#username) | string | 登入用使用者名稱 | ✅ | ❌ | +| [primary_email](/user-management/user-data#primary_email) | string | 主要電子郵件 | ✅ | ❌ | +| [primary_phone](/user-management/user-data#primary_phone) | string | 主要手機號碼 | ✅ | ❌ | +| [name](/user-management/user-data#name) | string | 全名 | ❌ | ❌ | +| [avatar](/user-management/user-data#avatar) | string | 指向使用者頭像圖片的 URL | ❌ | ❌ | +| [profile](/user-management/user-data#profile) | object | 使用者檔案 | ❌ | ✅ | +| [identities](/user-management/user-data#social-identities) | object | 從社交登入取得的使用者資訊 | ❌ | ✅ | +| [custom_data](/user-management/user-data#custom-data) | object | 可自訂屬性中的額外資訊 | ❌ | ✅ | +| [application_id](/user-management/user-data#application_id) | string | 使用者首次註冊的應用程式 ID | ❌ | ✅ | +| [last_sign_in_at](/user-management/user-data#last_sign_in_at) | date time | 使用者最近一次登入的時間戳記 | ❌ | ✅ | +| [password_encrypted](/user-management/user-data#password_encrypted) | string | 加密後的密碼 | ❌ | ❌ | +| [password_encryption_method](/user-management/user-data#password_encryption_method) | string | 密碼加密方法 | ❌ | ❌ | +| [is_suspended](/user-management/user-data#is_suspended) | bool | 使用者停用標記 | ❌ | ✅ | +| [mfa_verifications](/user-management/user-data#mfa_verification_factors) | object[] | MFA 驗證因子 | ❌ | ✅ | - **唯一**:確保資料表屬性值的[唯一性](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS)。 - **必填**:確保資料表屬性值不可為 `null`。