diff --git a/i18n/de/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/de/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index 2956dd8ce47..121b3edb3de 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -2,13 +2,13 @@ sidebar_position: 6 --- -# Opaker Token +# Opaker Token (Opaque token) -Während des Authentifizierungsprozesses, wenn keine Ressource angegeben ist, stellt Logto ein opakes Zugangstoken anstelle eines JWT aus. Das opake Token ist eine zufällige Zeichenfolge und viel kürzer als ein JWT: +Während des Authentifizierungsprozesses gibt Logto, wenn keine Ressource angegeben ist, ein opakes Zugangstoken (Opaque token) anstelle eines JWT aus. Das opake Token ist eine zufällige Zeichenkette und deutlich kürzer als ein JWT: ```json { - "access_token": "some-random-string", // opakes Token + "access_token": "some-random-string", // opaker Token "expires_in": 3600, "id_token": "eyJhbGc...aBc", // JWT "scope": "openid profile email", @@ -18,20 +18,20 @@ Während des Authentifizierungsprozesses, wenn keine Ressource angegeben ist, st Das opake Token kann verwendet werden, um den [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) aufzurufen und auf geschützte Ressourcen zuzugreifen, die Authentifizierung erfordern. Da es sich nicht um ein JWT handelt, wie kann der Ressourcenserver es validieren? -Logto bietet einen [Introspektions-Endpunkt](https://www.rfc-editor.org/rfc/rfc7662.html), der zur Validierung opaker Tokens verwendet werden kann. Standardmäßig ist der Introspektions-Endpunkt `/oidc/token/introspection` und akzeptiert `POST`-Anfragen. Der folgende Parameter ist erforderlich: +Logto stellt einen [Introspektions-Endpunkt](https://www.rfc-editor.org/rfc/rfc7662.html) bereit, der zur Validierung opaker Tokens verwendet werden kann. Standardmäßig ist der Introspektions-Endpunkt `/oidc/token/introspection` und akzeptiert `POST`-Anfragen. Der folgende Parameter ist erforderlich: - `token`: das zu validierende opake Token -Der Endpunkt erfordert auch eine Client-Authentifizierung. Du kannst eine der folgenden Methoden verwenden: +Der Endpunkt erfordert außerdem eine Client-Authentifizierung. Du kannst eine der folgenden Methoden verwenden: -- HTTP-Basic-Authentifizierung: Verwende den `Authorization`-Header mit dem Wert `Basic `. Die Anmeldedaten müssen die Client-ID und das Client-Geheimnis sein, getrennt durch einen Doppelpunkt (`:`) und base64-codiert. -- HTTP-POST-Authentifizierung: Verwende die Parameter `client_id` und `client_secret`: +- HTTP Basic-Authentifizierung: Verwende den `Authorization`-Header mit dem Wert `Basic `. Die Zugangsdaten müssen die Client-ID und das Client-Secret sein, getrennt durch einen Doppelpunkt (`:`) und base64-codiert. +- HTTP POST-Authentifizierung: Verwende die Parameter `client_id` und `client_secret`: - `client_id`: die Client-ID der Anwendung, die das Token angefordert hat - - `client_secret`: das Client-Geheimnis der Anwendung, die das Token angefordert hat + - `client_secret`: das Client-Secret der Anwendung, die das Token angefordert hat -Die Client-ID (App-ID) und das Client-Geheimnis (App-Geheimnis) können die App-Anmeldedaten von jeder "traditionellen Web"- oder "Maschine-zu-Maschine"-Anwendung in Logto sein. Der Introspektions-Endpunkt gibt einen Fehler zurück, wenn die Anmeldedaten ungültig sind. +Die Client-ID (App-ID) und das Client-Secret (App-Secret) können die App-Zugangsdaten jeder "traditionellen Web"- oder "Maschine-zu-Maschine"-Anwendung in Logto sein. Der Introspektions-Endpunkt gibt einen Fehler zurück, wenn die Zugangsdaten ungültig sind. -Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen des Tokens zurück: +Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen (Claims) des Tokens zurück: ```json { @@ -40,9 +40,9 @@ Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen des Tokens } ``` -Wenn das Token ungültig ist, wird das `active`-Feld `false` sein und das `sub`-Feld wird weggelassen. +Wenn das Token ungültig ist, ist das Feld `active` auf `false` gesetzt und das Feld `sub` wird weggelassen. -Hier ist ein nicht-normatives Beispiel für die Introspektionsanfrage: +Hier ist ein nicht-normatives Beispiel für die Introspektions-Anfrage: ```bash curl --location \ @@ -54,3 +54,14 @@ curl --location \ ``` Denke daran, `[tenant-id]` durch deine Tenant-ID zu ersetzen. + +## Opaker Token und Organisationen \{#opaque-token-and-organizations} + +Opake Tokens können verwendet werden, um Organisationsmitgliedschaftsinformationen über den [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) abzurufen. Wenn du den `urn:logto:scope:organizations`-Scope anforderst, gibt der userinfo endpoint die organisationsbezogenen Ansprüche (Claims) des Benutzers zurück, wie z. B. `organizations` (Organisations-IDs) und `organization_data`. + +**Opake Tokens können jedoch nicht als Organisationstoken verwendet werden.** Organisationstokens werden immer im JWT-Format ausgegeben, weil: + +1. Organisationstokens enthalten organisationsspezifische Ansprüche (wie `organization_id` und bereichsspezifische Berechtigungen), die von Ressourcenservern validiert werden müssen. +2. Das JWT-Format ermöglicht es Ressourcenservern, das Token zu überprüfen und den Organisationskontext ohne zusätzliche API-Aufrufe zu extrahieren. + +Um ein Organisationstoken zu erhalten, musst du den [Auffrischungstoken-Flow](/authorization/organization-permissions#refresh-token-flow) oder den [Client-Credentials-Flow](/authorization/organization-permissions#client-credentials-flow) mit Organisationsparametern verwenden. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index c443b442279..a150837413b 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -6,7 +6,7 @@ sidebar_position: 1 ## MFA-Einstellungen in Logto konfigurieren \{#configure-mfa-settings-in-logto} -Logto bietet flexible Konfigurationsmöglichkeiten für Multi-Faktor-Authentifizierung (MFA), um unterschiedlichen Sicherheitsanforderungen gerecht zu werden. Du kannst MFA global für alle Benutzer konfigurieren oder sie für Multi-Tenant-Anwendungen organisationsspezifisch aktivieren. +Logto bietet flexible Konfigurationsmöglichkeiten für Multi-Faktor-Authentifizierung (MFA), um unterschiedlichen Sicherheitsanforderungen gerecht zu werden. Du kannst MFA global für alle Benutzer konfigurieren oder sie für Multi-Tenant-Anwendungen organisationsbasiert aktivieren. ### Globale MFA-Konfiguration \{#global-mfa-configuration} @@ -15,30 +15,30 @@ Folge diesen Schritten, um MFA im Logto-Anmeldeprozess für Benutzer zu aktivier 1. Navigiere zu: Konsole > Multi-Faktor-Authentifizierung. 2. Aktiviere die unterstützten Verifizierungsfaktoren für deine Benutzer. 1. Primäre Faktoren: - - [Passkeys (WebAuthn)](/end-user-flows/mfa/webauthn): Eine hochsichere Option, geeignet für Webprodukte mit Gerätebiometrie oder Sicherheitsschlüsseln usw., die einen robusten Schutz gewährleisten. + - [Passkeys (WebAuthn)](/end-user-flows/mfa/webauthn): Eine hochsichere Option, geeignet für Webprodukte mit Unterstützung für Gerätebiometrie oder Sicherheitsschlüssel usw., die einen robusten Schutz gewährleistet. - [Authenticator App OTP](/end-user-flows/mfa/authenticator-app-otp): Die gängigste und am weitesten akzeptierte Methode. Verwende ein zeitbasiertes Einmalpasswort (TOTP), das von einer Authenticator-App wie Google Authenticator oder Authy generiert wird. - - [SMS-Verifizierung](/end-user-flows/mfa/sms-mfa): Eine bequeme Methode, bei der Einmalcodes per SMS an die registrierte Telefonnummer des Benutzers gesendet werden – ideal für Nutzer, die eine mobile Authentifizierung ohne zusätzliche Apps bevorzugen. - - [E-Mail-Verifizierung](/end-user-flows/mfa/email-mfa): Eine weit verbreitete Methode, bei der Einmalcodes an die registrierte E-Mail-Adresse des Benutzers gesendet werden – geeignet für Nutzer auf allen Plattformen und Geräten. + - [SMS-Verifizierung](/end-user-flows/mfa/sms-mfa): Eine bequeme Methode, bei der Einmalcodes per SMS an die registrierte Telefonnummer des Benutzers gesendet werden – ideal für Benutzer, die eine mobile Authentifizierung ohne zusätzliche Apps bevorzugen. + - [E-Mail-Verifizierung](/end-user-flows/mfa/email-mfa): Eine weit verbreitete Methode, bei der Einmalcodes an die registrierte E-Mail-Adresse des Benutzers gesendet werden – geeignet für Benutzer auf allen Plattformen und Geräten. 2. Backup-Faktoren: - - [Backup-Codes](/end-user-flows/mfa/backup-codes): Dies dient als Backup-Option, wenn Benutzer keinen der oben genannten primären Faktoren verifizieren können. Die Aktivierung dieser Option reduziert die Hürden für einen erfolgreichen Zugang der Benutzer. + - [Backup-Codes](/end-user-flows/mfa/backup-codes): Dient als Backup-Option, wenn Benutzer keinen der oben genannten primären Faktoren verifizieren können. Das Aktivieren dieser Option verringert die Hürden für einen erfolgreichen Zugriff der Benutzer. 3. Wähle, ob du **MFA erforderlich** aktivieren möchtest: - **Aktivieren**: Benutzer werden während des Anmeldeprozesses aufgefordert, MFA einzurichten, was nicht übersprungen werden kann. Wenn der Benutzer MFA nicht einrichtet oder seine MFA-Einstellungen löscht, wird sein Konto gesperrt, bis MFA erneut eingerichtet wird. - **Deaktivieren**: Benutzer können den MFA-Einrichtungsprozess während der Registrierung überspringen. Sie können MFA später über deine Self-Service-Kontoeinstellungsseite einrichten. [Mehr erfahren](/end-user-flows/account-settings/) über die Implementierung einer Benutzerkontoeinstellungsseite. Wähle anschließend die Richtlinie für die MFA-Einrichtungsaufforderung: - **Benutzer nicht zur MFA-Einrichtung auffordern**: Benutzer werden während der Anmeldung nicht zur MFA-Einrichtung aufgefordert. - - **Benutzer während der Registrierung zur MFA-Einrichtung auffordern**: Neue Benutzer werden während der Registrierung zur MFA-Einrichtung aufgefordert, bestehende Benutzer sehen die Aufforderung bei ihrer nächsten Anmeldung. Benutzer können diesen Schritt überspringen, und er wird nicht erneut angezeigt. - - **Benutzer nach der Registrierung bei der nächsten Anmeldung zur MFA-Einrichtung auffordern**: Neue Benutzer werden bei ihrer zweiten Anmeldung nach der Registrierung zur MFA-Einrichtung aufgefordert, bestehende Benutzer sehen die Aufforderung bei ihrer nächsten Anmeldung. Benutzer können diesen Schritt überspringen, und er wird nicht erneut angezeigt. + - **Benutzer während der Registrierung zur MFA-Einrichtung auffordern**: Neue Benutzer werden während der Registrierung zur MFA-Einrichtung aufgefordert, bestehende Benutzer sehen die Aufforderung bei ihrer nächsten Anmeldung. Benutzer können diesen Schritt überspringen, und er erscheint nicht erneut. + - **Benutzer nach der Registrierung bei der nächsten Anmeldung zur MFA-Einrichtung auffordern**: Neue Benutzer werden bei ihrer zweiten Anmeldung nach der Registrierung zur MFA-Einrichtung aufgefordert, bestehende Benutzer sehen die Aufforderung bei ihrer nächsten Anmeldung. Benutzer können diesen Schritt überspringen, und er erscheint nicht erneut. :::tip -Wenn du einen Benutzer nach dem Überspringen der MFA-Einrichtung erneut auffordern möchtest, setze seinen Überspringen-Status zurück, damit der Einrichtungsbildschirm beim nächsten Anmelden erscheint. Admins können die Management API (`PATCH /api/users/{userId}/logto-configs`) verwenden, und Entwickler, die Self-Service-Flows bauen, können die Account API (`PATCH /api/my-account/logto-configs`) aufrufen. [Management API Referenz](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Account API Referenz](https://openapi.logto.io/operation/operation-updatelogtoconfig) +Wenn du einen Benutzer nach dem Überspringen der MFA-Einrichtung erneut auffordern möchtest, setze seinen Überspringen-Status zurück, damit der Einrichtungsbildschirm beim nächsten Anmelden erscheint. Admins können die Management API (`PATCH /api/users/{userId}/logto-configs`) verwenden, und Entwickler, die Self-Service-Flows bauen, können die Account API (`PATCH /api/my-account/logto-configs`) aufrufen. [Management API Referenz](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Account API Referenz](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: MFA-Einstellungen -### Organisationsspezifische MFA-Konfiguration \{#organization-level-mfa-configuration} +### MFA-Konfiguration auf Organisationsebene \{#organization-level-mfa-configuration} -Für Produkte mit Multi-Tenant-Architektur, die [Organisationen](/organizations) unterstützen, musst du in den meisten Fällen nicht für alle Benutzer MFA verlangen. Stattdessen kann MFA organisationsspezifisch aktiviert werden, sodass du die Anforderungen je nach Kundenbedarf anpassen kannst. Siehe dazu [MFA für Organisationsmitglieder erforderlich machen](/organizations/organization-management#require-mfa-for-organization-members). +Für Produkte mit Multi-Tenant-Architektur, die [Organisationen](/organizations) unterstützen, musst du in den meisten Fällen nicht für alle Benutzer MFA verlangen. Stattdessen kann MFA organisationsbasiert aktiviert werden, sodass du die Anforderungen je nach Bedarf des jeweiligen Kunden anpassen kannst. Weitere Informationen findest du unter [MFA für Organisationsmitglieder erforderlich machen](/organizations/organization-management#require-mfa-for-organization-members). -Im Abschnitt **Multi-Faktor-Authentifizierung** stelle **MFA-Einrichtungsaufforderung für Benutzer nach Aktivierung von MFA durch die Organisation** auf **Benutzer bei der nächsten Anmeldung zur MFA-Einrichtung auffordern (kein Überspringen)**. Mitglieder jeder Organisation, die MFA verlangt, werden dann bei ihrer nächsten Anmeldung zur MFA-Einrichtung aufgefordert, und die Aufforderung kann nicht übersprungen werden. +Im Abschnitt **Multi-Faktor-Authentifizierung** stelle **MFA-Einrichtungsaufforderung für Benutzer nach Aktivierung von MFA durch die Organisation** auf **Benutzer bei der nächsten Anmeldung zur MFA-Einrichtung auffordern (kein Überspringen möglich)**. Mitglieder jeder Organisation, für die MFA erforderlich ist, werden dann bei ihrer nächsten Anmeldung zur MFA-Einrichtung aufgefordert, und die Aufforderung kann nicht übersprungen werden. ## MFA-Benutzerfluss \{#mfa-user-flow} @@ -48,31 +48,31 @@ Sobald MFA aktiviert ist, werden Benutzer während des Anmelde- und Registrierun 1. **Anmelde- oder Registrierungsseite aufrufen**: Der Benutzer navigiert zur Anmelde- oder Registrierungsseite. 2. **Anmeldung oder Registrierung abschließen**: Der Benutzer durchläuft den Identitätsprüfungsprozess im Anmelde- oder Registrierungsablauf. -3. **Primären MFA-Faktor einrichten**: Der Benutzer wird aufgefordert, seinen primären MFA-Faktor einzurichten (entweder Passkey, Authenticator App OTP, SMS-Code oder E-Mail-Code). +3. **Primären MFA-Faktor einrichten**: Der Benutzer wird aufgefordert, seinen primären MFA-Faktor einzurichten (entweder Passkey, Authenticator-App-OTP, SMS-Code oder E-Mail-Code). - Wenn mehrere primäre Faktoren aktiviert sind, kann der Benutzer seine bevorzugte Option wählen. - - Ist der primäre Faktor identisch mit dem Registrierungskennzeichen (z. B. SMS oder E-Mail), wird dieser vorverifiziert, sodass der Benutzer den Verifizierungsschritt überspringen und direkt zum nächsten Schritt übergehen kann (z. B. „Eine weitere Zwei-Schritt-Verifizierung hinzufügen“ oder „Backup-Faktoren speichern“). - - Ist die „MFA erforderlich“-Richtlinie deaktiviert, kann dieser Schritt auch durch Auswahl der Schaltfläche „Überspringen“ übersprungen werden. -4. **MFA-Backup-Faktor einrichten**: Wenn **Backup-Codes** aktiviert sind, wird der Benutzer nach erfolgreicher Konfiguration seines primären Authentifizierungsfaktors aufgefordert, Backup-Codes zu speichern. Automatisch generierte Backup-Codes werden angezeigt, die der Benutzer herunterladen und sicher aufbewahren kann. Der Benutzer muss die Backup-Codes manuell bestätigen, um den MFA-Einrichtungsprozess abzuschließen. + - Wenn der primäre Faktor mit dem Registrierungskennzeichen übereinstimmt (z. B. SMS oder E-Mail), wird dieser vorverifiziert, sodass Benutzer den Verifizierungsschritt überspringen und direkt zum nächsten Schritt übergehen können (z. B. „Füge eine weitere 2-Schritt-Verifizierung hinzu“ oder „Speichere deine Backup-Faktoren“). + - Ist die „MFA erforderlich“-Richtlinie deaktiviert, kann dieser Schritt durch Auswahl der Schaltfläche „Überspringen“ ebenfalls übersprungen werden. +4. **Backup-MFA-Faktor einrichten**: Wenn **Backup-Codes** aktiviert sind, wird der Benutzer nach erfolgreicher Konfiguration seines primären Authentifizierungsfaktors aufgefordert, Backup-Codes zu speichern. Automatisch generierte Backup-Codes werden dem Benutzer angezeigt, die er herunterladen und sicher aufbewahren kann. Der Benutzer muss die Backup-Codes manuell bestätigen, um den MFA-Einrichtungsprozess abzuschließen. MFA-Einrichtungsprozess ### MFA-Verifizierungsprozess \{#mfa-verification-flow} -Benutzer, die MFA eingerichtet haben, werden bei der Anmeldung aufgefordert, ihre Identität mit den konfigurierten MFA-Faktoren zu verifizieren. Der Verifizierungsfaktor hängt von der MFA-Konfiguration in Logto und den Benutzereinstellungen ab. +Benutzer, die MFA eingerichtet haben, werden während der Anmeldung aufgefordert, ihre Identität mit den konfigurierten MFA-Faktoren zu verifizieren. Der Verifizierungsfaktor hängt von der MFA-Konfiguration in Logto und den Benutzereinstellungen ab. - Wenn ein Benutzer nur einen Faktor eingerichtet hat, wird dieser direkt verifiziert. - Wenn ein Benutzer mehrere Faktoren für 2FA eingerichtet hat, präsentiert das System Verifizierungsoptionen nach folgenden Prioritätsregeln: - **Passkey-Priorität**: Wenn der Benutzer einen Passkey konfiguriert hat, wird dieser als Standard-Verifizierungsmethode angezeigt. - - **Zuletzt verwendete Präferenz**: Ist kein Passkey verfügbar, priorisiert das System die zuletzt erfolgreich verwendete Verifizierungsmethode des Benutzers. - - **Auswahlliste**: Wenn keine der obigen Prioritäten zutrifft, zeigt die Zwei-Schritt-Verifizierungsseite alle verfügbaren gebundenen Verifizierungsmethoden zur Auswahl an. + - **Zuletzt verwendete Präferenz**: Wenn kein Passkey verfügbar ist, priorisiert das System die zuletzt erfolgreich verwendete Verifizierungsmethode des Benutzers. + - **Auswahlliste**: Wenn keine der obigen Prioritäten zutrifft, zeigt die 2-Schritt-Verifizierungsseite alle verfügbaren gebundenen Verifizierungsmethoden zur Auswahl an. - Benutzer können jederzeit auf „Andere Methode ausprobieren“ klicken, um zwischen verschiedenen Verifizierungsoptionen zu wechseln. -- Sind alle aktivierten primären Faktoren für den Benutzer nicht verfügbar und Backup-Codes aktiviert, kann er den Einmal-Backup-Code zur Verifizierung seiner Identität verwenden. +- Wenn keine der aktivierten primären Faktoren für den Benutzer verfügbar ist und Backup-Codes aktiviert sind, kann er den einmaligen Backup-Code zur Verifizierung seiner Identität verwenden. MFA-Verifizierungsprozess ## MFA-Verwaltung \{#mfa-management} -Über die anfängliche Einrichtung bei Anmeldung/Registrierung hinaus können Benutzer ihre MFA-Einstellungen über ein Self-Service-Kontozentrum verwalten. Dies bietet Flexibilität, MFA-Faktoren je nach Bedarf zu binden oder zu entfernen. +Über die erstmalige Einrichtung bei Anmeldung/Registrierung hinaus können Benutzer ihre MFA-Einstellungen über ein Self-Service-Kontozentrum verwalten. Dies bietet Flexibilität, um MFA-Faktoren je nach Bedarf zu binden oder zu entfernen. ### Ein Kontozentrum aufbauen \{#building-an-account-center} @@ -84,11 +84,11 @@ Du kannst ein umfassendes Kontozentrum mit der [Account API](/end-user-flows/acc ### MFA-Einrichtungsaufforderungen nach Anmeldung \{#post-login-mfa-setup-prompts} -Für Anwendungen, die bei der Erstregistrierung keine MFA verlangen, kannst du intelligente Aufforderungen implementieren, um die MFA-Einrichtung zu fördern: +Für Anwendungen, die MFA nicht während der Erstregistrierung verlangen, kannst du intelligente Aufforderungen implementieren, um die MFA-Einrichtung zu fördern: - **Bedingte Aufforderungen**: Zeige Empfehlungen zur MFA-Einrichtung basierend auf Benutzerverhalten oder Kontowert an -- **Sicherheits-Dashboards**: Zeige Sicherheitsbewertungen an, die sich verbessern, wenn MFA aktiviert ist -- **Schrittweise Einführung**: Präsentiere die MFA-Einrichtung als Teil eines fortschreitenden Sicherheitsverbesserungsprozesses +- **Sicherheits-Dashboards**: Zeige Sicherheitsbewertungen, die sich verbessern, wenn MFA aktiviert ist +- **Schrittweises Onboarding**: Präsentiere die MFA-Einrichtung als Teil eines fortschreitenden Sicherheitsverbesserungsprozesses Mehr zur Implementierung dieser Muster mit der [Account API](/end-user-flows/account-settings/by-account-api). @@ -105,17 +105,17 @@ In der Konsole > Benutzerverwaltung können Ad ### Was passiert, wenn Administratoren die bestehenden MFA-Faktoren eines Benutzers entfernen? \{#what-happens-when-administrators-remove-users-existing-mfa-factors} -Wenn Administratoren alle primären MFA-Faktoren eines Benutzers (Passkey, Authenticator App OTP, SMS oder E-Mail) entfernen, treten beim nächsten Anmeldeversuch des Benutzers folgende Szenarien auf: +Wenn Administratoren alle primären MFA-Faktoren eines Benutzers (Passkey, Authenticator-App-OTP, SMS oder E-Mail) entfernen, treten beim nächsten Anmeldeversuch des Benutzers folgende Szenarien auf: **Szenario 1: Keine MFA-Faktoren mehr vorhanden** -- Wenn keine MFA-Faktoren existieren (einschließlich keine Backup-Codes) und die [MFA-Richtlinie](#global-mfa-configuration) MFA verlangt, darf sich der Benutzer ohne MFA-Verifizierung anmelden und wird sofort zur erneuten MFA-Einrichtung aufgefordert. +- Wenn keine MFA-Faktoren existieren (einschließlich keine Backup-Codes) und die [MFA-Richtlinie](#global-mfa-configuration) MFA verlangt, darf sich der Benutzer ohne MFA-Verifizierung anmelden und wird sofort erneut zur MFA-Einrichtung aufgefordert. **Szenario 2: Backup-Codes sind noch vorhanden** - Wenn noch Backup-Codes verfügbar sind, muss sich der Benutzer bei der Anmeldung zunächst mit einem Backup-Code verifizieren. -- Nach erfolgreicher Backup-Code-Verifizierung wird der Benutzer zur Einrichtung eines neuen primären MFA-Faktors aufgefordert. -- Ob der Benutzer diese Einrichtung überspringen kann, hängt von deiner konfigurierten MFA-Richtlinie ab. +- Nach erfolgreicher Backup-Code-Verifizierung wird der Benutzer aufgefordert, einen neuen primären MFA-Faktor einzurichten. +- Ob der Benutzer diesen Schritt überspringen kann, hängt von deiner konfigurierten MFA-Richtlinie ab. - Dieser Ansatz verhindert, dass Benutzer ausgesperrt werden, wenn keine primären Faktoren mehr verfügbar sind. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index 6ad2ce1583f..f705ca94ada 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -8,13 +8,13 @@ sidebar_position: 4 Dies wird üblicherweise auf der Benutzerprofilseite verwendet, auf der Benutzer ihre Organisationsinformationen anzeigen müssen. -Organisations-Benutzerinfo +Organisation Benutzerinfo ## Wie wird es implementiert \{#how-to-implement-it} Es gibt zwei Möglichkeiten, Benutzerinformationen innerhalb einer Organisation abzurufen. -### ID-Token entschlüsseln \{#decode-the-id-token} +### ID-Token decodieren \{#decode-the-id-token} Das ID-Token (ID token) ist ein standardisiertes JWT, das Benutzerprofilinformationen und organisationsbezogene Ansprüche (Claims) enthält. Rufe die SDK-Methode `decodeIdToken()` auf, um ein JSON-Objekt wie dieses zu erhalten: @@ -42,7 +42,7 @@ Das ID-Token (ID token) ist ein standardisiertes JWT, das Benutzerprofilinformat } ``` -Das ID-Token (ID token) wird jedoch nur während der Authentifizierung ausgegeben und kann veraltet sein, wenn sich das Benutzerprofil danach ändert. +Das ID-Token (ID token) wird jedoch nur während der Authentifizierung ausgestellt und kann veraltet sein, wenn sich das Benutzerprofil danach ändert. Für die aktuellsten Informationen verwende die zweite Methode unten oder rufe `clearAllTokens()` auf und starte einen Authentifizierungsablauf neu, um ein frisches ID-Token (ID token) zu erhalten. ```ts @@ -53,8 +53,14 @@ logtoClient.signIn({ }); ``` -Wenn die Sitzung noch gültig ist, leitet der `signIn`-Aufruf ohne erneute Eingabe von Zugangsdaten zurück zu deiner App. Aus Sicht des Benutzers wird die App einfach aktualisiert und im Hintergrund ein neues ID-Token (ID token) ausgegeben. +Wenn die Sitzung noch gültig ist, leitet der `signIn`-Aufruf ohne erneute Eingabe von Zugangsdaten zurück zu deiner App. Aus Sicht des Benutzers wird die App einfach aktualisiert und im Hintergrund ein neues ID-Token (ID token) ausgestellt. ### Benutzerinformationen vom `/oidc/me`-Endpunkt abrufen \{#fetch-user-info-from-the-oidc-me-endpoint} Du kannst auch `/oidc/me` anfragen, um Benutzerinformationen in Echtzeit im Organisationskontext zu erhalten. Rufe dazu die SDK-Methode `fetchUserInfo()` auf. + +:::tip[Opaker Token Support] +Wenn du ein [opakes Token](/concepts/opaque-token) verwendest (ausgestellt, wenn keine API-Ressource angegeben ist), kannst du trotzdem Organisationsmitgliedschaftsinformationen über den userinfo-Endpunkt abrufen. Wenn du die Berechtigung (Scope) `urn:logto:scope:organizations` anforderst, enthält die Antwort `organizations` und andere organisationsbezogene Ansprüche (Claims). + +Beachte, dass opake Tokens nicht als Organisationstoken für den Zugriff auf organisationsspezifische Ressourcen verwendet werden können. Siehe [Opaker Token und Organisationen](/concepts/opaque-token#opaque-token-and-organizations) für weitere Details. +::: diff --git a/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index 811da1a6687..350cfb54e1d 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -2,21 +2,21 @@ Hier ist die Liste der unterstützten Berechtigungen (Scopes) und der entspreche **`openid`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | -| ------------- | -------- | ------------------------------------------ | ------------------ | -| sub | `string` | Der eindeutige Identifikator des Benutzers | Nein | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | +| ---------- | -------- | ------------------------------------------ | ------------------ | +| sub | `string` | Der eindeutige Identifikator des Benutzers | Nein | **`profile`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | -| ------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | -| name | `string` | Der vollständige Name des Benutzers | Nein | -| username | `string` | Der Benutzername des Benutzers | Nein | -| picture | `string` | URL des Profilbildes des Endbenutzers. Diese URL MUSS auf eine Bilddatei (zum Beispiel eine PNG-, JPEG- oder GIF-Bilddatei) verweisen, anstatt auf eine Webseite, die ein Bild enthält. Beachte, dass diese URL speziell auf ein Profilfoto des Endbenutzers verweisen SOLLTE, das geeignet ist, den Endbenutzer zu beschreiben, anstatt auf ein beliebiges vom Endbenutzer aufgenommenes Foto. | Nein | -| created_at | `number` | Zeitpunkt, zu dem der Endbenutzer erstellt wurde. Die Zeit wird als Anzahl der Millisekunden seit dem Unix-Epoch (1970-01-01T00:00:00Z) dargestellt. | Nein | -| updated_at | `number` | Zeitpunkt, zu dem die Informationen des Endbenutzers zuletzt aktualisiert wurden. Die Zeit wird als Anzahl der Millisekunden seit dem Unix-Epoch (1970-01-01T00:00:00Z) dargestellt. | Nein | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | +| ---------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------ | +| name | `string` | Der vollständige Name des Benutzers | Nein | +| username | `string` | Der Benutzername des Benutzers | Nein | +| picture | `string` | URL zum Profilbild des Endbenutzers. Diese URL MUSS auf eine Bilddatei (z. B. PNG, JPEG oder GIF) verweisen und nicht auf eine Webseite, die ein Bild enthält. Beachte, dass diese URL speziell auf ein Profilfoto des Endbenutzers verweisen SOLLTE, das sich zur Darstellung des Endbenutzers eignet, und nicht auf ein beliebiges vom Endbenutzer aufgenommenes Foto. | Nein | +| created_at | `number` | Zeitpunkt, zu dem der Endbenutzer erstellt wurde. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt. | Nein | +| updated_at | `number` | Zeitpunkt, zu dem die Informationen des Endbenutzers zuletzt aktualisiert wurden. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt. | Nein | -Andere [Standardansprüche](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) wie `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo` und `locale` werden ebenfalls im `profile`-Scope enthalten sein, ohne dass der userinfo-Endpunkt angefordert werden muss. Ein Unterschied im Vergleich zu den obigen Ansprüchen besteht darin, dass diese Ansprüche nur zurückgegeben werden, wenn ihre Werte nicht leer sind, während die obigen Ansprüche `null` zurückgeben, wenn die Werte leer sind. +Weitere [Standardansprüche](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) wie `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo` und `locale` werden ebenfalls im `profile`-Scope enthalten sein, ohne dass das Userinfo-Endpunkt abgefragt werden muss. Ein Unterschied zu den oben genannten Ansprüchen besteht darin, dass diese Ansprüche nur zurückgegeben werden, wenn ihre Werte nicht leer sind, während die oben genannten Ansprüche `null` zurückgeben, wenn die Werte leer sind. :::note Im Gegensatz zu den Standardansprüchen verwenden die Ansprüche `created_at` und `updated_at` Millisekunden anstelle von Sekunden. @@ -24,54 +24,58 @@ Im Gegensatz zu den Standardansprüchen verwenden die Ansprüche `created_at` un **`email`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | | -------------- | --------- | --------------------------------------- | ------------------ | | email | `string` | Die E-Mail-Adresse des Benutzers | Nein | | email_verified | `boolean` | Ob die E-Mail-Adresse verifiziert wurde | Nein | **`phone`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | | --------------------- | --------- | -------------------------------------- | ------------------ | | phone_number | `string` | Die Telefonnummer des Benutzers | Nein | | phone_number_verified | `boolean` | Ob die Telefonnummer verifiziert wurde | Nein | **`address`** -Bitte siehe [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) für die Details des Adressanspruchs. +Bitte siehe [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) für Details zum Address-Anspruch. **`custom_data`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | -| ------------- | -------- | ------------------------------------------- | ------------------ | -| custom_data | `object` | Die benutzerdefinierten Daten des Benutzers | Ja | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | +| ----------- | -------- | ----------------------------- | ------------------ | +| custom_data | `object` | Die benutzerdefinierten Daten | Ja | **`identities`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | | -------------- | -------- | --------------------------------------------- | ------------------ | | identities | `object` | Die verknüpften Identitäten des Benutzers | Ja | | sso_identities | `array` | Die verknüpften SSO-Identitäten des Benutzers | Ja | **`roles`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | -| ------------- | ---------- | ------------------------ | ------------------ | -| roles | `string[]` | Die Rollen des Benutzers | Nein | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | +| ---------- | ---------- | ------------------------ | ------------------ | +| roles | `string[]` | Die Rollen des Benutzers | Nein | **`urn:logto:scope:organizations`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | | ----------------- | ---------- | --------------------------------------------------- | ------------------ | | organizations | `string[]` | Die Organisations-IDs, denen der Benutzer angehört | Nein | | organization_data | `object[]` | Die Organisationsdaten, denen der Benutzer angehört | Ja | +:::note +Diese Organisationsansprüche können auch über das Userinfo-Endpunkt abgerufen werden, wenn ein [Opaker Token](/concepts/opaque-token) verwendet wird. Allerdings können opake Tokens nicht als Organisationstoken für den Zugriff auf organisationsspezifische Ressourcen verwendet werden. Siehe [Opaker Token und Organisationen](/concepts/opaque-token#opaque-token-and-organizations) für weitere Details. +::: + **`urn:logto:scope:organization_roles`** -| Anspruchsname | Typ | Beschreibung | Benötigt userinfo? | -| ------------------ | ---------- | ----------------------------------------------------------------------------------------------- | ------------------ | -| organization_roles | `string[]` | Die Organisationsrollen, denen der Benutzer angehört, im Format `:` | Nein | +| Claim-Name | Typ | Beschreibung | Benötigt userinfo? | +| ------------------ | ---------- | ------------------------------------------------------------------------------- | ------------------ | +| organization_roles | `string[]` | Die Organisationsrollen des Benutzers im Format `:` | Nein | --- -In Anbetracht der Leistung und der Datengröße bedeutet "Benötigt userinfo?" "Ja", dass der Anspruch nicht im ID-Token angezeigt wird, sondern in der Antwort des [userinfo-Endpunkts](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) zurückgegeben wird. +Im Hinblick auf Leistung und Datenmenge gilt: Wenn "Benötigt userinfo?" mit "Ja" angegeben ist, erscheint der Anspruch nicht im ID-Token, sondern wird in der Antwort des [Userinfo-Endpunkts](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) zurückgegeben. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/es/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index 5e5398d73c9..e803fc0bfae 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -2,7 +2,7 @@ sidebar_position: 6 --- -# Token opaco +# Token opaco (Opaque token) Durante el proceso de autenticación, si no se especifica un recurso, Logto emitirá un token de acceso opaco en lugar de un JWT. El token opaco es una cadena aleatoria y es mucho más corto que un JWT: @@ -16,22 +16,22 @@ Durante el proceso de autenticación, si no se especifica un recurso, Logto emit } ``` -El token opaco se puede usar para llamar al [endpoint de userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) y para acceder a recursos protegidos que requieren autenticación. Dado que no es un JWT, ¿cómo puede el servidor de recursos validarlo? +El token opaco se puede usar para llamar al [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) y para acceder a recursos protegidos que requieren autenticación. Dado que no es un JWT, ¿cómo puede el servidor de recursos validarlo? -Logto proporciona un [endpoint de introspección](https://www.rfc-editor.org/rfc/rfc7662.html) que se puede usar para validar tokens opacos. Por defecto, el endpoint de introspección es `/oidc/token/introspection` y acepta solicitudes `POST`. Se requiere el siguiente parámetro: +Logto proporciona un [endpoint de introspección](https://www.rfc-editor.org/rfc/rfc7662.html) que se puede usar para validar tokens opacos. Por defecto, el endpoint de introspección es `/oidc/token/introspection` y acepta solicitudes `POST`. El siguiente parámetro es obligatorio: - `token`: el token opaco a validar El endpoint también requiere autenticación del cliente. Puedes usar uno de los siguientes métodos: -- Autenticación HTTP Basic: Usa el encabezado `Authorization` con el valor `Basic `. Las credenciales deben ser el ID de cliente y el secreto de cliente separados por dos puntos (`:`) y codificados en base64. +- Autenticación HTTP Basic: Usa el encabezado `Authorization` con el valor `Basic `. Las credenciales deben ser el client ID y el client secret separados por dos puntos (`:`) y codificados en base64. - Autenticación HTTP POST: Usa los parámetros `client_id` y `client_secret`: - - `client_id`: el ID de cliente de la aplicación que solicitó el token - - `client_secret`: el secreto de cliente de la aplicación que solicitó el token + - `client_id`: el client ID de la aplicación que solicitó el token + - `client_secret`: el client secret de la aplicación que solicitó el token -El ID de cliente (ID de la aplicación) y el secreto de cliente (secreto de la aplicación) pueden ser las credenciales de la aplicación de cualquier aplicación "web tradicional" o "máquina a máquina" en Logto. El endpoint de introspección devolverá un error si las credenciales son inválidas. +El client ID (app ID) y el client secret (app secret) pueden ser las credenciales de cualquier aplicación "web tradicional" o "máquina a máquina" en Logto. El endpoint de introspección devolverá un error si las credenciales son inválidas. -El endpoint de introspección devuelve un objeto JSON con los reclamos del token: +El endpoint de introspección devuelve un objeto JSON con los reclamos (claims) del token: ```json { @@ -40,7 +40,7 @@ El endpoint de introspección devuelve un objeto JSON con los reclamos del token } ``` -Si el token es inválido, el campo `active` será `false` y el campo `sub` será omitido. +Si el token no es válido, el campo `active` será `false` y el campo `sub` se omitirá. Aquí tienes un ejemplo no normativo de la solicitud de introspección: @@ -53,4 +53,15 @@ curl --location \ --data-urlencode 'client_secret=1234567890' ``` -Recuerda reemplazar `[tenant-id]` con tu ID de inquilino. +Recuerda reemplazar `[tenant-id]` por tu tenant ID. + +## Token opaco y organizaciones \{#opaque-token-and-organizations} + +Los tokens opacos se pueden usar para obtener información de membresía de organización a través del [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). Cuando solicitas el alcance `urn:logto:scope:organizations`, el endpoint userinfo devolverá los reclamos relacionados con la organización del usuario, como `organizations` (IDs de organización) y `organization_data`. + +Sin embargo, **los tokens opacos no pueden usarse como tokens de organización**. Los tokens de organización siempre se emiten en formato JWT porque: + +1. Los tokens de organización contienen reclamos específicos de la organización (como `organization_id` y permisos con alcance) que deben ser validados por los servidores de recursos. +2. El formato JWT permite a los servidores de recursos verificar el token y extraer el contexto de la organización sin llamadas API adicionales. + +Para obtener un token de organización, necesitas usar el [flujo de refresh token](/authorization/organization-permissions#refresh-token-flow) o el [flujo de client credentials](/authorization/organization-permissions#client-credentials-flow) con parámetros de organización. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index 1f21ec2c281..5b4c9de46d3 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -15,56 +15,56 @@ Sigue estos pasos para habilitar MFA en el flujo de inicio de sesión de los usu 1. Navega a: Consola > Autenticación multifactor. 2. Habilita los factores de verificación compatibles para tus usuarios. 1. Factores primarios: - - [Llaves de acceso (WebAuthn)](/end-user-flows/mfa/webauthn): Una opción de alta seguridad adecuada para productos web que admiten biometría de dispositivos o llaves de seguridad, etc., garantizando una protección robusta. + - [Llaves de acceso (WebAuthn)](/end-user-flows/mfa/webauthn): Una opción de alta seguridad adecuada para productos web que admiten biometría de dispositivo o llaves de seguridad, etc., garantizando una protección robusta. - [OTP de aplicación autenticadora](/end-user-flows/mfa/authenticator-app-otp): El método más común y ampliamente aceptado. Utiliza una contraseña de un solo uso basada en tiempo (TOTP) generada por una aplicación autenticadora como Google Authenticator o Authy. - [Verificación por SMS](/end-user-flows/mfa/sms-mfa): Un método conveniente que envía códigos de verificación de un solo uso por SMS al número de teléfono registrado del usuario, ideal para quienes prefieren la autenticación móvil sin aplicaciones adicionales. - [Verificación por correo electrónico](/end-user-flows/mfa/email-mfa): Un método ampliamente accesible que entrega códigos de verificación de un solo uso al correo electrónico registrado del usuario, adecuado para usuarios en todas las plataformas y dispositivos. 2. Factores de respaldo: - - [Códigos de respaldo](/end-user-flows/mfa/backup-codes): Sirve como opción de respaldo cuando los usuarios no pueden verificar ninguno de los factores primarios mencionados. Habilitar esta opción reduce la fricción para que los usuarios accedan exitosamente. + - [Códigos de respaldo](/end-user-flows/mfa/backup-codes): Sirve como opción de respaldo cuando los usuarios no pueden verificar ninguno de los factores primarios mencionados. Habilitar esta opción reduce la fricción para el acceso exitoso de los usuarios. 3. Elige si deseas habilitar **Requerir MFA**: - - **Habilitar**: Se pedirá a los usuarios configurar MFA durante el proceso de inicio de sesión, el cual no se puede omitir. Si el usuario no configura MFA o elimina sus ajustes de MFA, quedará bloqueado de su cuenta hasta que configure MFA nuevamente. - - **Deshabilitar**: Los usuarios pueden omitir el proceso de configuración de MFA durante el flujo de registro. Pueden configurar MFA más tarde a través de la página de ajustes de cuenta de autoservicio. [Aprende más](/end-user-flows/account-settings/) sobre cómo implementar una página de ajustes de cuenta de usuario. Y continúa eligiendo la política para el aviso de configuración de MFA: - - **No pedir a los usuarios que configuren MFA**: No se pedirá a los usuarios configurar MFA durante el inicio de sesión. - - **Pedir a los usuarios que configuren MFA durante el registro**: Se pedirá a los nuevos usuarios configurar MFA durante el registro, y los usuarios existentes verán el aviso en su próximo inicio de sesión. Los usuarios pueden omitir este paso y no volverá a aparecer. - - **Pedir a los usuarios que configuren MFA en su inicio de sesión después del registro**: Se pedirá a los nuevos usuarios configurar MFA en su segundo inicio de sesión después del registro, y los usuarios existentes verán el aviso en su próximo inicio de sesión. Los usuarios pueden omitir este paso y no volverá a aparecer. + - **Habilitar**: Se solicitará a los usuarios configurar MFA durante el proceso de inicio de sesión, el cual no se puede omitir. Si el usuario no configura MFA o elimina sus ajustes de MFA, quedará bloqueado de su cuenta hasta que configure MFA nuevamente. + - **Deshabilitar**: Los usuarios pueden omitir el proceso de configuración de MFA durante el flujo de registro. Pueden configurar MFA más tarde a través de la página de configuración de cuenta de autoservicio. [Aprende más](/end-user-flows/account-settings/) sobre cómo implementar una página de configuración de cuenta de usuario. Y continúa eligiendo la política para el aviso de configuración de MFA: + - **No pedir a los usuarios que configuren MFA**: No se solicitará a los usuarios configurar MFA durante el inicio de sesión. + - **Pedir a los usuarios que configuren MFA durante el registro**: Se solicitará a los nuevos usuarios configurar MFA durante el registro, y los usuarios existentes verán el aviso en su próximo inicio de sesión. Los usuarios pueden omitir este paso y no volverá a aparecer. + - **Pedir a los usuarios que configuren MFA en su inicio de sesión después del registro**: Se solicitará a los nuevos usuarios configurar MFA en su segundo inicio de sesión después del registro, y los usuarios existentes verán el aviso en su próximo inicio de sesión. Los usuarios pueden omitir este paso y no volverá a aparecer. :::tip -Si necesitas volver a mostrar el aviso de configuración de MFA a un usuario que lo omitió, restablece su estado de omisión para que la pantalla de configuración aparezca la próxima vez que inicie sesión. Los administradores pueden usar la Management API (`PATCH /api/users/{userId}/logto-configs`), y los desarrolladores que construyan flujos de autoservicio pueden llamar a la Account API (`PATCH /api/my-account/logto-configs`). [Referencia de Management API](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Referencia de Account API](https://openapi.logto.io/operation/operation-updatelogtoconfig) +Si necesitas volver a solicitar a un usuario después de que haya omitido la inscripción en MFA, restablece su estado de omisión para que la pantalla de configuración aparezca la próxima vez que inicie sesión. Los administradores pueden usar la Management API (`PATCH /api/users/{userId}/logto-configs`), y los desarrolladores que construyan flujos de autoservicio pueden llamar a la Account API (`PATCH /api/my-account/logto-configs`). [Referencia de Management API](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Referencia de Account API](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: Configuración de MFA ### Configuración de MFA a nivel de organización \{#organization-level-mfa-configuration} -Para productos con una arquitectura multi-inquilino que admiten [Organizaciones](/organizations), en la mayoría de los casos no necesitas requerir MFA para todos los usuarios. En su lugar, MFA puede habilitarse por organización, permitiéndote adaptar los requisitos según las necesidades de cada cliente. Para comenzar, consulta [Requerir MFA para miembros de la organización](/organizations/organization-management#require-mfa-for-organization-members). +Para productos con una arquitectura multi-inquilino que admiten [Organizaciones](/organizations), en la mayoría de los casos no es necesario requerir MFA para todos los usuarios. En su lugar, MFA puede habilitarse por organización, lo que te permite adaptar los requisitos según las necesidades de cada cliente. Para comenzar, consulta [Requerir MFA para miembros de la organización](/organizations/organization-management#require-mfa-for-organization-members). -En la sección **Autenticación multifactor**, establece **Aviso de configuración de MFA para usuarios después de que la organización habilite MFA** en **Pedir a los usuarios que configuren MFA en el próximo inicio de sesión (sin omisión)**. Los miembros de cualquier organización que requiera MFA serán avisados para completar la configuración de MFA en su próximo inicio de sesión, y el aviso no podrá ser omitido. +En la sección **Autenticación multifactor**, establece **Aviso de configuración de MFA para usuarios después de que la organización habilite MFA** en **Pedir a los usuarios que configuren MFA en el próximo inicio de sesión (sin omisión)**. Los miembros de cualquier organización que requiera MFA serán solicitados a completar la configuración de MFA en su próximo inicio de sesión, y el aviso no se podrá omitir. ## Flujo de usuario de MFA \{#mfa-user-flow} ### Flujo de configuración de MFA \{#mfa-set-up-flow} -Una vez habilitado MFA, se pedirá a los usuarios configurar MFA durante el proceso de inicio de sesión y registro. Los usuarios pueden optar por omitir este proceso de configuración solo si la política “Requerir MFA” está deshabilitada. +Una vez que MFA está habilitado, se solicitará a los usuarios configurar MFA durante el proceso de inicio de sesión y registro. Los usuarios pueden optar por omitir este proceso de configuración solo si la política “Requerir MFA” está deshabilitada. 1. **Visitar la página de inicio de sesión o registro**: El usuario navega a la página de inicio de sesión o registro. -2. **Completa el inicio de sesión o registro**: El usuario completa el proceso de verificación de identidad dentro del flujo de inicio de sesión o registro. -3. **Configura el factor primario de MFA**: Se pide al usuario configurar su factor primario de MFA (ya sea llave de acceso, OTP de aplicación autenticadora, código SMS o código de correo electrónico). +2. **Completar el inicio de sesión o registro**: El usuario completa el proceso de verificación de identidad dentro del flujo de inicio de sesión o registro. +3. **Configurar el factor primario de MFA**: Se solicita al usuario configurar su factor primario de MFA (ya sea llave de acceso, OTP de aplicación autenticadora, código SMS o código de correo electrónico). - Si hay varios factores primarios habilitados, pueden elegir su opción preferida. - - Si el factor primario es el mismo que el identificador de registro (por ejemplo, SMS o correo electrónico), se verificará previamente, permitiendo a los usuarios omitir el paso de verificación y pasar directamente al siguiente paso (por ejemplo, "Agregar otra verificación en 2 pasos" o "Guarda tus factores de respaldo"). + - Si el factor primario es el mismo que el identificador de registro (por ejemplo, SMS o correo electrónico), se verificará previamente, permitiendo a los usuarios omitir el paso de verificación y proceder directamente al siguiente paso (por ejemplo, "Agregar otra verificación en dos pasos" o "Guarda tus factores de respaldo"). - Si la política “Requerir MFA” está deshabilitada, también pueden omitir este paso seleccionando el botón "Omitir". -4. **Configura el factor de respaldo de MFA**: Si los **Códigos de respaldo** están habilitados, se pedirá al usuario guardar los códigos de respaldo después de configurar exitosamente su factor de autenticación primario. Se mostrarán códigos de respaldo generados automáticamente, que el usuario puede descargar y almacenar de forma segura. El usuario debe confirmar manualmente los códigos de respaldo para completar el proceso de configuración de MFA. +4. **Configurar el factor de respaldo de MFA**: Si los **Códigos de respaldo** están habilitados, se solicitará al usuario guardar los códigos de respaldo después de configurar con éxito su factor de autenticación primario. Se mostrarán códigos de respaldo generados automáticamente, que el usuario puede descargar y almacenar de forma segura. El usuario debe confirmar manualmente los códigos de respaldo para completar el proceso de configuración de MFA. Flujo de configuración de MFA ### Flujo de verificación de MFA \{#mfa-verification-flow} -Los usuarios que hayan configurado MFA serán avisados para verificar su identidad usando los factores de MFA configurados durante el inicio de sesión. El factor de verificación dependerá de la configuración de MFA en Logto y de los ajustes del usuario. +A los usuarios que hayan configurado MFA se les solicitará verificar su identidad utilizando los factores de MFA configurados durante el inicio de sesión. El factor de verificación dependerá de la configuración de MFA en Logto y de los ajustes del usuario. -- Si un usuario solo ha configurado un factor, lo verificará directamente. +- Si un usuario ha configurado solo un factor, lo verificará directamente. - Si un usuario ha configurado varios factores para 2FA, el sistema presentará opciones de verificación según las siguientes reglas de prioridad: - **Prioridad de llave de acceso**: Si el usuario tiene una llave de acceso configurada, se presentará como el método de verificación predeterminado. - - **Preferencia de último uso**: Si no hay llave de acceso disponible, el sistema priorizará el método de verificación que el usuario usó exitosamente por última vez. - - **Lista de selección**: Si ninguna de las prioridades anteriores aplica, la página de verificación en 2 pasos mostrará todos los métodos de verificación vinculados disponibles para que el usuario elija. + - **Preferencia de último uso**: Si no hay llave de acceso disponible, el sistema priorizará el método de verificación que el usuario utilizó con éxito por última vez. + - **Lista de selección**: Si ninguna de las prioridades anteriores aplica, la página de verificación en dos pasos mostrará todos los métodos de verificación vinculados disponibles para que el usuario elija. - Los usuarios pueden hacer clic en "Probar otro método de verificación" para cambiar entre diferentes opciones de verificación en cualquier momento. - Si todos los factores primarios habilitados no están disponibles para el usuario, y el código de respaldo está habilitado, pueden usar el código de respaldo de un solo uso para verificar su identidad. @@ -72,11 +72,11 @@ Los usuarios que hayan configurado MFA serán avisados para verificar su identid ## Gestión de MFA \{#mfa-management} -Más allá de la configuración inicial durante el inicio de sesión / registro, los usuarios pueden gestionar sus ajustes de MFA a través de un centro de cuentas de autoservicio. Esto proporciona flexibilidad para que los usuarios vinculen o desvinculen factores de MFA según sus necesidades. +Más allá de la configuración inicial durante el inicio de sesión/registro, los usuarios pueden gestionar sus ajustes de MFA a través de un centro de cuentas de autoservicio. Esto proporciona flexibilidad para que los usuarios vinculen o desvinculen factores de MFA según sus necesidades. ### Construir un centro de cuentas \{#building-an-account-center} -Puedes construir un centro de cuentas integral usando la [Account API](/end-user-flows/account-settings/by-account-api) de Logto, que permite a los usuarios: +Puedes construir un centro de cuentas integral utilizando la [Account API](/end-user-flows/account-settings/by-account-api) de Logto, que permite a los usuarios: - **Vincular nuevos factores de MFA**: Agregar aplicaciones autenticadoras adicionales, llaves de acceso o regenerar códigos de respaldo - **Desvincular factores de MFA existentes**: Eliminar métodos de MFA que ya no deseen usar @@ -97,7 +97,7 @@ Aprende más sobre cómo implementar estos patrones con la [Account API](/end-us En la Consola > Gestión de usuarios, los administradores pueden gestionar eficazmente los ajustes de MFA de los usuarios: - **Ver el estado de MFA del usuario**: Comprobar qué factores de MFA están habilitados para cada usuario. -- **Eliminar el MFA del usuario**: Eliminar todos los factores de MFA de un usuario, requiriendo que configure MFA nuevamente. +- **Eliminar el MFA del usuario**: Eliminar todos los factores de MFA de un usuario, obligándolo a configurar MFA nuevamente. ### Preguntas frecuentes \{#faqs} @@ -109,12 +109,12 @@ Cuando los administradores eliminan todos los factores primarios de MFA de un us **Escenario 1: No quedan factores de MFA** -- Si no existen factores de MFA (incluyendo que no haya códigos de respaldo) y la [política de MFA](#global-mfa-configuration) requiere MFA, se permitirá al usuario iniciar sesión sin verificación de MFA y se le pedirá inmediatamente que configure MFA nuevamente. +- Si no existen factores de MFA (incluidos los códigos de respaldo) y la [política de MFA](#global-mfa-configuration) requiere MFA, se permitirá al usuario iniciar sesión sin verificación de MFA y se le solicitará inmediatamente configurar MFA nuevamente. **Escenario 2: Aún existen códigos de respaldo** - Si aún hay códigos de respaldo disponibles, el usuario debe primero verificar usando un código de respaldo durante el inicio de sesión. -- Tras la verificación exitosa del código de respaldo, se pedirá al usuario configurar un nuevo factor primario de MFA. +- Tras la verificación exitosa del código de respaldo, se solicitará al usuario configurar un nuevo factor primario de MFA. - Si el usuario puede omitir esta configuración depende de la política de MFA configurada. - Este enfoque evita que los usuarios queden bloqueados de sus cuentas cuando no hay factores primarios disponibles. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index e43bbf0cbd8..8dc15d1feb0 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -12,7 +12,7 @@ Esto se utiliza normalmente en la página de perfil de usuario donde los usuario ## Cómo implementarlo \{#how-to-implement-it} -Hay dos formas de obtener información del usuario dentro de una organización. +Hay dos formas de obtener la información del usuario dentro de una organización. ### Decodificar el token de ID \{#decode-the-id-token} @@ -42,8 +42,8 @@ El token de ID (ID token) es un JWT estándar que contiene información del perf } ``` -Sin embargo, el token de ID (ID token) solo se emite durante la autenticación y puede quedar desactualizado si el perfil del usuario cambia después. -Para obtener la información más actualizada, utiliza el segundo enfoque a continuación, o llama a `clearAllTokens()` y reinicia un flujo de autenticación para obtener un nuevo token de ID. +Sin embargo, el token de ID solo se emite durante la autenticación y puede quedar desactualizado si el perfil del usuario cambia después. +Para obtener la información más actualizada, utiliza el segundo enfoque a continuación, o llama a `clearAllTokens()` y reinicia un flujo de autenticación para obtener un token de ID nuevo. ```ts await logtoClient.clearAllTokens(); @@ -53,8 +53,14 @@ logtoClient.signIn({ }); ``` -Si la sesión sigue siendo válida, la llamada a `signIn` redirigirá de vuelta a tu aplicación sin requerir credenciales. Desde la perspectiva del usuario, la aplicación simplemente se actualiza y se emite un nuevo token de ID (ID token) en segundo plano. +Si la sesión sigue siendo válida, la llamada a `signIn` redirigirá de vuelta a tu aplicación sin requerir credenciales. Desde la perspectiva del usuario, la aplicación simplemente se actualiza y se emite un nuevo token de ID en segundo plano. ### Obtener información del usuario desde el endpoint `/oidc/me` \{#fetch-user-info-from-the-oidc-me-endpoint} También puedes solicitar `/oidc/me` para obtener información del usuario en tiempo real en el contexto de la organización. Llama al método del SDK `fetchUserInfo()`. + +:::tip[Soporte para token opaco] +Si estás utilizando un [token opaco](/concepts/opaque-token) (emitido cuando no se especifica un recurso de API), aún puedes recuperar la información de membresía de la organización a través del endpoint userinfo. Cuando solicitas el alcance `urn:logto:scope:organizations`, la respuesta incluirá `organizations` y otros reclamos relacionados con la organización. + +Ten en cuenta que los tokens opacos no pueden usarse como tokens de organización para acceder a recursos específicos de la organización. Consulta [Token opaco y organizaciones](/concepts/opaque-token#opaque-token-and-organizations) para más detalles. +::: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index c56675b44ce..02147e8e4bd 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/es/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -1,77 +1,81 @@ -Aquí está la lista de alcances (Scopes) soportados y los reclamos (Claims) correspondientes: +Aquí tienes la lista de alcances (Scopes) soportados y los reclamos (Claims) correspondientes: **`openid`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | -------- | ---------------------------------- | ------------------- | -| sub | `string` | El identificador único del usuario | No | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| ---------- | -------- | ---------------------------------- | ------------------- | +| sub | `string` | El identificador único del usuario | No | **`profile`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | -| name | `string` | El nombre completo del usuario | No | -| username | `string` | El nombre de usuario del usuario | No | -| picture | `string` | URL de la foto de perfil del Usuario Final. Esta URL DEBE referirse a un archivo de imagen (por ejemplo, un archivo de imagen PNG, JPEG o GIF), en lugar de a una página web que contenga una imagen. Ten en cuenta que esta URL DEBERÍA referirse específicamente a una foto de perfil del Usuario Final adecuada para mostrar al describir al Usuario Final, en lugar de una foto arbitraria tomada por el Usuario Final. | No | -| created_at | `number` | Momento en que se creó el Usuario Final. El tiempo se representa como el número de milisegundos desde la época Unix (1970-01-01T00:00:00Z). | No | -| updated_at | `number` | Momento en que la información del Usuario Final fue actualizada por última vez. El tiempo se representa como el número de milisegundos desde la época Unix (1970-01-01T00:00:00Z). | No | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| ---------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | +| name | `string` | El nombre completo del usuario | No | +| username | `string` | El nombre de usuario del usuario | No | +| picture | `string` | URL de la foto de perfil del usuario final. Esta URL DEBE referirse a un archivo de imagen (por ejemplo, un archivo de imagen PNG, JPEG o GIF), en lugar de a una página web que contenga una imagen. Ten en cuenta que esta URL DEBERÍA referenciar específicamente una foto de perfil del usuario final adecuada para mostrar al describir al usuario final, en lugar de una foto arbitraria tomada por el usuario final. | No | +| created_at | `number` | Momento en que se creó el usuario final. El tiempo se representa como el número de milisegundos desde la época Unix (1970-01-01T00:00:00Z). | No | +| updated_at | `number` | Momento en que se actualizó por última vez la información del usuario final. El tiempo se representa como el número de milisegundos desde la época Unix (1970-01-01T00:00:00Z). | No | -Otros [reclamos estándar](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) incluyen `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, y `locale` también se incluirán en el alcance `profile` sin la necesidad de solicitar el endpoint de userinfo. Una diferencia en comparación con los reclamos anteriores es que estos reclamos solo se devolverán cuando sus valores no estén vacíos, mientras que los reclamos anteriores devolverán `null` si los valores están vacíos. +Otros [reclamos estándar](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) como `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo` y `locale` también se incluirán en el alcance `profile` sin necesidad de solicitar el endpoint userinfo. Una diferencia respecto a los reclamos anteriores es que estos reclamos solo se devolverán cuando sus valores no estén vacíos, mientras que los reclamos anteriores devolverán `null` si los valores están vacíos. :::note -A diferencia de los reclamos estándar, los reclamos `created_at` y `updated_at` utilizan milisegundos en lugar de segundos. +A diferencia de los reclamos estándar, los reclamos `created_at` y `updated_at` usan milisegundos en lugar de segundos. ::: **`email`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | --------- | -------------------------------------------------------- | ------------------- | -| email | `string` | La dirección de correo electrónico del usuario | No | -| email_verified | `boolean` | Si la dirección de correo electrónico ha sido verificada | No | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| -------------- | --------- | -------------------------------------------------------- | ------------------- | +| email | `string` | La dirección de correo electrónico del usuario | No | +| email_verified | `boolean` | Si la dirección de correo electrónico ha sido verificada | No | **`phone`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | +| Claim name | Type | Descripción | ¿Necesita userinfo? | | --------------------- | --------- | ------------------------------------------- | ------------------- | | phone_number | `string` | El número de teléfono del usuario | No | | phone_number_verified | `boolean` | Si el número de teléfono ha sido verificado | No | **`address`** -Por favor, consulta el [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) para los detalles del reclamo de dirección. +Por favor, consulta [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) para los detalles del reclamo de dirección. **`custom_data`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | -------- | ------------------------------------ | ------------------- | -| custom_data | `object` | Los datos personalizados del usuario | Sí | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| ----------- | -------- | ------------------------------------ | ------------------- | +| custom_data | `object` | Los datos personalizados del usuario | Sí | **`identities`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | -------- | ------------------------------------------ | ------------------- | -| identities | `object` | Las identidades vinculadas del usuario | Sí | -| sso_identities | `array` | Las identidades SSO vinculadas del usuario | Sí | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| -------------- | -------- | ------------------------------------------ | ------------------- | +| identities | `object` | Las identidades vinculadas del usuario | Sí | +| sso_identities | `array` | Las identidades SSO vinculadas del usuario | Sí | **`roles`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | ---------- | --------------------- | ------------------- | -| roles | `string[]` | Los roles del usuario | No | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| ---------- | ---------- | --------------------- | ------------------- | +| roles | `string[]` | Los roles del usuario | No | **`urn:logto:scope:organizations`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | ---------- | -------------------------------------------------------------- | ------------------- | -| organizations | `string[]` | Los IDs de las organizaciones a las que pertenece el usuario | No | -| organization_data | `object[]` | Los datos de las organizaciones a las que pertenece el usuario | Sí | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| ----------------- | ---------- | -------------------------------------------------------------- | ------------------- | +| organizations | `string[]` | Los IDs de las organizaciones a las que pertenece el usuario | No | +| organization_data | `object[]` | Los datos de las organizaciones a las que pertenece el usuario | Sí | + +:::note +Estos reclamos de organización también pueden recuperarse a través del endpoint userinfo cuando se utiliza un [token opaco](/concepts/opaque-token). Sin embargo, los tokens opacos no pueden usarse como tokens de organización para acceder a recursos específicos de la organización. Consulta [Token opaco y organizaciones](/concepts/opaque-token#opaque-token-and-organizations) para más detalles. +::: **`urn:logto:scope:organization_roles`** -| Nombre del reclamo | Tipo | Descripción | ¿Necesita userinfo? | -| ------------------ | ---------- | ------------------------------------------------------------------------------------------------------------- | ------------------- | -| organization_roles | `string[]` | Los roles de las organizaciones a las que pertenece el usuario con el formato `:` | No | +| Claim name | Type | Descripción | ¿Necesita userinfo? | +| ------------------ | ---------- | ---------------------------------------------------------------------------------------------------------- | ------------------- | +| organization_roles | `string[]` | Los roles de la organización a los que pertenece el usuario con el formato `:` | No | --- -Considerando el rendimiento y el tamaño de los datos, si "¿Necesita userinfo?" es "Sí", significa que el reclamo no aparecerá en el token de ID, pero se devolverá en la respuesta del [endpoint de userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). +Considerando el rendimiento y el tamaño de los datos, si "¿Necesita userinfo?" es "Sí", significa que el reclamo no aparecerá en el token de ID, pero se devolverá en la respuesta del [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index eebf8523047..9e54f9db878 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -2,9 +2,9 @@ sidebar_position: 6 --- -# Jeton opaque +# Jeton opaque (Opaque token) -Au cours du processus d'authentification, si aucune ressource n'est spécifiée, Logto émettra un jeton d’accès (opaque token) au lieu d'un JWT. Le jeton opaque est une chaîne aléatoire et il est beaucoup plus court qu'un JWT : +Lors du processus d'authentification, si aucune ressource n'est spécifiée, Logto émettra un jeton d’accès opaque (opaque access token) au lieu d'un JWT. Le jeton opaque est une chaîne aléatoire et il est beaucoup plus court qu'un JWT : ```json { @@ -16,33 +16,33 @@ Au cours du processus d'authentification, si aucune ressource n'est spécifiée, } ``` -Le jeton opaque peut être utilisé pour appeler le [point de terminaison userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) et accéder aux ressources protégées qui nécessitent une Authentification. Puisqu'il ne s'agit pas d'un JWT, comment le serveur de ressources peut-il le valider ? +Le jeton opaque peut être utilisé pour appeler le [point de terminaison userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) et pour accéder aux ressources protégées nécessitant une authentification. Puisqu'il ne s'agit pas d'un JWT, comment le serveur de ressources peut-il le valider ? -Logto fournit un [point de terminaison d'introspection](https://www.rfc-editor.org/rfc/rfc7662.html) qui peut être utilisé pour valider les jetons opaques. Par défaut, le point de terminaison d'introspection est `/oidc/token/introspection` et accepte les requêtes `POST`. Le paramètre suivant est requis : +Logto fournit un [point de terminaison d’introspection](https://www.rfc-editor.org/rfc/rfc7662.html) qui peut être utilisé pour valider les jetons opaques. Par défaut, le point de terminaison d’introspection est `/oidc/token/introspection` et accepte les requêtes `POST`. Le paramètre suivant est requis : - `token` : le jeton opaque à valider -Le point de terminaison nécessite également une Authentification client. Vous pouvez utiliser l'une des méthodes suivantes : +Le point de terminaison nécessite également une authentification du client. Vous pouvez utiliser l'une des méthodes suivantes : -- Authentification HTTP Basic : Utilisez l'en-tête `Authorization` avec la valeur `Basic `. Les informations d'identification doivent être l'ID client et le secret client séparés par un deux-points (`:`) et encodés en base64. +- Authentification HTTP Basic : Utilisez l'en-tête `Authorization` avec la valeur `Basic `. Les identifiants doivent être l'ID client et le secret client séparés par un deux-points (`:`) et encodés en base64. - Authentification HTTP POST : Utilisez les paramètres `client_id` et `client_secret` : - - `client_id` : l'ID client de l'application qui a demandé le jeton - - `client_secret` : le secret client de l'application qui a demandé le jeton + - `client_id` : l'ID client de l'application ayant demandé le jeton + - `client_secret` : le secret client de l'application ayant demandé le jeton -L'ID client (ID de l'application) et le secret client (secret de l'application) peuvent être les informations d'identification de l'application de toute application "web traditionnelle" ou "machine à machine" dans Logto. Le point de terminaison d'introspection renverra une erreur si les informations d'identification sont invalides. +L'ID client (ID de l'application) et le secret client (secret de l'application) peuvent être les identifiants d'une application "web traditionnelle" ou "machine à machine" dans Logto. Le point de terminaison d’introspection renverra une erreur si les identifiants sont invalides. -Le point de terminaison d'introspection renvoie un objet JSON avec les Revendications du jeton : +Le point de terminaison d’introspection retourne un objet JSON avec les revendications (claims) du jeton : ```json { - "active": true, // si le jeton est valide ou non + "active": true, // indique si le jeton est valide ou non "sub": "1234567890" // le sujet du jeton (l'ID utilisateur) } ``` -Si le jeton est invalide, le champ `active` sera `false` et le champ `sub` sera omis. +Si le jeton est invalide, le champ `active` sera à `false` et le champ `sub` sera omis. -Voici un exemple non normatif de la requête d'introspection : +Voici un exemple non normatif de requête d’introspection : ```bash curl --location \ @@ -54,3 +54,14 @@ curl --location \ ``` N'oubliez pas de remplacer `[tenant-id]` par votre ID de locataire. + +## Jeton opaque et organisations \{#opaque-token-and-organizations} + +Les jetons opaques peuvent être utilisés pour récupérer les informations d'appartenance à une organisation via le [point de terminaison userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). Lorsque vous demandez la portée `urn:logto:scope:organizations`, le point de terminaison userinfo retournera les revendications liées à l'organisation de l'utilisateur, telles que `organizations` (IDs d'organisation) et `organization_data`. + +Cependant, **les jetons opaques ne peuvent pas être utilisés comme jetons d’organisation (organization tokens)**. Les jetons d’organisation sont toujours émis au format JWT car : + +1. Les jetons d’organisation contiennent des revendications spécifiques à l'organisation (comme `organization_id` et des permissions limitées) qui doivent être validées par les serveurs de ressources. +2. Le format JWT permet aux serveurs de ressources de vérifier le jeton et d'extraire le contexte organisationnel sans appels API supplémentaires. + +Pour obtenir un jeton d’organisation, vous devez utiliser le [flux de jeton de rafraîchissement](/authorization/organization-permissions#refresh-token-flow) ou le [flux client credentials](/authorization/organization-permissions#client-credentials-flow) avec des paramètres d'organisation. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index b89e5ed0745..5e41f2dd83d 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -16,20 +16,20 @@ Suivez ces étapes pour activer les MFA dans le flux de connexion Logto des util 2. Activez les facteurs de vérification pris en charge pour vos utilisateurs. 1. Facteurs principaux : - [Passkeys (WebAuthn)](/end-user-flows/mfa/webauthn) : Une option de haute sécurité adaptée aux produits web prenant en charge la biométrie des appareils ou les clés de sécurité, etc., garantissant une protection robuste. - - [OTP d’application d’authentification](/end-user-flows/mfa/authenticator-app-otp) : La méthode la plus courante et largement acceptée. Utilisez un mot de passe à usage unique basé sur le temps (TOTP) généré par une application d’authentification comme Google Authenticator ou Authy. - - [Vérification par SMS](/end-user-flows/mfa/sms-mfa) : Une méthode pratique qui envoie des codes de vérification à usage unique par SMS au numéro de téléphone enregistré de l’utilisateur, idéale pour ceux qui préfèrent l’authentification mobile sans application supplémentaire. + - [OTP via application d’authentification](/end-user-flows/mfa/authenticator-app-otp) : La méthode la plus courante et largement acceptée. Utilisez un mot de passe à usage unique basé sur le temps (TOTP) généré par une application d’authentification comme Google Authenticator ou Authy. + - [Vérification par SMS](/end-user-flows/mfa/sms-mfa) : Une méthode pratique qui envoie des codes de vérification à usage unique par SMS au numéro de téléphone enregistré de l’utilisateur, idéale pour les utilisateurs préférant l’authentification mobile sans applications supplémentaires. - [Vérification par e-mail](/end-user-flows/mfa/email-mfa) : Une méthode largement accessible qui envoie des codes de vérification à usage unique à l’adresse e-mail enregistrée de l’utilisateur, adaptée à tous les utilisateurs, plateformes et appareils. 2. Facteurs de secours : - - [Codes de secours](/end-user-flows/mfa/backup-codes) : Sert d’option de secours lorsque les utilisateurs ne peuvent pas vérifier l’un des facteurs principaux mentionnés ci-dessus. Activer cette option réduit les obstacles à l’accès des utilisateurs. + - [Codes de secours](/end-user-flows/mfa/backup-codes) : Sert d’option de secours lorsque les utilisateurs ne peuvent pas vérifier l’un des facteurs principaux mentionnés ci-dessus. Activer cette option réduit les obstacles pour l’accès des utilisateurs. 3. Choisissez si vous souhaitez activer **Exiger MFA** : - **Activer** : Les utilisateurs seront invités à configurer MFA lors du processus de connexion, ce qui ne peut pas être ignoré. Si l’utilisateur ne configure pas MFA ou supprime ses paramètres MFA, il sera bloqué de son compte jusqu’à ce qu’il configure à nouveau MFA. - - **Désactiver** : Les utilisateurs peuvent ignorer le processus de configuration MFA lors de l’inscription. Ils pourront configurer MFA ultérieurement via la page de paramètres de compte en libre-service. [En savoir plus](/end-user-flows/account-settings/) sur la mise en œuvre d’une page de paramètres de compte utilisateur. Continuez ensuite à choisir la politique pour l’invite de configuration MFA : + - **Désactiver** : Les utilisateurs peuvent ignorer le processus de configuration MFA lors de l’inscription. Ils pourront configurer MFA plus tard via votre page de paramètres de compte en libre-service. [En savoir plus](/end-user-flows/account-settings/) sur la mise en œuvre d’une page de paramètres de compte utilisateur. Continuez à choisir la politique pour l’invite de configuration MFA : - **Ne pas demander aux utilisateurs de configurer MFA** : Les utilisateurs ne seront pas invités à configurer MFA lors de la connexion. - - **Demander aux utilisateurs de configurer MFA lors de l’inscription** : Les nouveaux utilisateurs seront invités à configurer MFA lors de l’inscription, et les utilisateurs existants verront l’invite à leur prochaine connexion. Les utilisateurs peuvent ignorer cette étape, et elle ne s’affichera plus. - - **Demander aux utilisateurs de configurer MFA lors de leur connexion après l’inscription** : Les nouveaux utilisateurs seront invités à configurer MFA lors de leur deuxième connexion après l’inscription, et les utilisateurs existants verront l’invite à leur prochaine connexion. Les utilisateurs peuvent ignorer cette étape, et elle ne s’affichera plus. + - **Demander aux utilisateurs de configurer MFA lors de l’inscription** : Les nouveaux utilisateurs seront invités à configurer MFA lors de l’inscription, et les utilisateurs existants verront l’invite à leur prochaine connexion. Les utilisateurs peuvent ignorer cette étape, et elle ne réapparaîtra pas. + - **Demander aux utilisateurs de configurer MFA lors de leur connexion après inscription** : Les nouveaux utilisateurs seront invités à configurer MFA lors de leur deuxième connexion après inscription, et les utilisateurs existants verront l’invite à leur prochaine connexion. Les utilisateurs peuvent ignorer cette étape, et elle ne réapparaîtra pas. :::tip -Si vous devez inviter à nouveau un utilisateur après qu’il ait ignoré l’inscription MFA, réinitialisez son état d’ignorance afin que l’écran de configuration apparaisse lors de sa prochaine connexion. Les administrateurs peuvent utiliser le Management API (`PATCH /api/users/{userId}/logto-configs`), et les développeurs qui créent des flux en libre-service peuvent appeler l’Account API (`PATCH /api/my-account/logto-configs`). [Référence Management API](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Référence Account API](https://openapi.logto.io/operation/operation-updatelogtoconfig) +Si vous devez inviter à nouveau un utilisateur après qu’il ait ignoré l’inscription MFA, réinitialisez son état d’ignorance afin que l’écran de configuration apparaisse lors de sa prochaine connexion. Les administrateurs peuvent utiliser la Management API (`PATCH /api/users/{userId}/logto-configs`), et les développeurs construisant des flux en libre-service peuvent appeler l’Account API (`PATCH /api/my-account/logto-configs`). [Référence Management API](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Référence Account API](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: Paramètres MFA @@ -38,7 +38,7 @@ Si vous devez inviter à nouveau un utilisateur après qu’il ait ignoré l’i Pour les produits avec une architecture multi-locataire prenant en charge les [Organisations](/organizations), dans la plupart des cas, il n’est pas nécessaire d’exiger MFA pour tous les utilisateurs. Au lieu de cela, MFA peut être activé par organisation, ce qui vous permet d’adapter les exigences selon les besoins de chaque client. Pour commencer, consultez [Exiger MFA pour les membres d’une organisation](/organizations/organization-management#require-mfa-for-organization-members). -Dans la section **Authentification multi-facteurs**, définissez **Invite de configuration MFA pour les utilisateurs après activation MFA par l’organisation** sur **Demander aux utilisateurs de configurer MFA à la prochaine connexion (sans possibilité d’ignorer)**. Les membres de toute organisation qui exige MFA seront alors invités à compléter la configuration MFA lors de leur prochaine connexion, et l’invite ne pourra pas être ignorée. +Dans la section **Authentification multi-facteurs**, définissez **Invite de configuration MFA pour les utilisateurs après activation de MFA par l’organisation** sur **Demander aux utilisateurs de configurer MFA à la prochaine connexion (sans possibilité d’ignorer)**. Les membres de toute organisation exigeant MFA seront alors invités à compléter la configuration MFA lors de leur prochaine connexion, et l’invite ne pourra pas être ignorée. ## Parcours utilisateur MFA \{#mfa-user-flow} @@ -48,11 +48,11 @@ Une fois MFA activé, les utilisateurs seront invités à configurer MFA lors du 1. **Visiter la page de connexion ou d’inscription** : L’utilisateur accède à la page de connexion ou d’inscription. 2. **Compléter la connexion ou l’inscription** : L’utilisateur termine le processus de vérification d’identité dans le flux de connexion ou d’inscription. -3. **Configurer le facteur principal MFA** : L’utilisateur est invité à configurer son facteur principal MFA (soit passkey, OTP d’application d’authentification, code SMS ou code e-mail). +3. **Configurer le facteur principal MFA** : L’utilisateur est invité à configurer son facteur principal MFA (soit passkey, OTP via application d’authentification, code SMS ou code e-mail). - Si plusieurs facteurs principaux sont activés, il peut choisir son option préférée. - - Si le facteur principal est identique à l’identifiant d’inscription (par exemple, SMS ou e-mail), il sera pré-vérifié, permettant à l’utilisateur d’ignorer l’étape de vérification et de passer directement à l’étape suivante (par exemple, "Ajouter une autre vérification en 2 étapes" ou "Enregistrez vos facteurs de secours"). + - Si le facteur principal est identique à l’identifiant d’inscription (par exemple, SMS ou e-mail), il sera pré-vérifié, permettant à l’utilisateur de passer l’étape de vérification et de continuer directement à l’étape suivante (par exemple, "Ajouter une autre vérification en 2 étapes" ou "Sauvegardez vos facteurs de secours"). - Si la politique “Exiger MFA” est désactivée, il peut également ignorer cette étape en sélectionnant le bouton "Ignorer". -4. **Configurer le facteur de secours MFA** : Si les **codes de secours** sont activés, l’utilisateur est invité à enregistrer les codes de secours après avoir configuré avec succès son facteur principal d’authentification. Des codes de secours générés automatiquement seront affichés à l’utilisateur, qu’il pourra télécharger et stocker en toute sécurité. L’utilisateur doit confirmer manuellement les codes de secours pour terminer la configuration MFA. +4. **Configurer le facteur de secours MFA** : Si les **codes de secours** sont activés, l’utilisateur est invité à sauvegarder les codes de secours après avoir configuré avec succès son facteur principal d’authentification. Les codes de secours générés automatiquement seront affichés à l’utilisateur, qui pourra les télécharger et les stocker en toute sécurité. L’utilisateur doit confirmer manuellement les codes de secours pour terminer le processus de configuration MFA. Parcours de configuration MFA @@ -65,8 +65,8 @@ Les utilisateurs ayant configuré MFA seront invités à vérifier leur identit - **Priorité passkey** : Si l’utilisateur a configuré une passkey, elle sera proposée comme méthode de vérification par défaut. - **Préférence dernier utilisé** : Si aucune passkey n’est disponible, le système privilégiera la méthode de vérification que l’utilisateur a utilisée avec succès en dernier. - **Liste de sélection** : Si aucune des priorités ci-dessus ne s’applique, la page de vérification en 2 étapes affichera toutes les méthodes de vérification liées disponibles pour que l’utilisateur puisse choisir. - - Les utilisateurs peuvent cliquer sur "Essayer une autre méthode de vérification" pour passer d’une option à l’autre à tout moment. -- Si tous les facteurs principaux activés ne sont pas disponibles pour l’utilisateur, et que le code de secours est activé, il peut utiliser le code de secours à usage unique pour vérifier son identité. + - Les utilisateurs peuvent cliquer sur "Essayer une autre méthode de vérification" pour basculer entre les différentes options à tout moment. +- Si tous les facteurs principaux activés ne sont pas disponibles pour l’utilisateur, et que le code de secours est activé, il pourra utiliser le code de secours à usage unique pour vérifier son identité. Parcours de vérification MFA @@ -74,13 +74,13 @@ Les utilisateurs ayant configuré MFA seront invités à vérifier leur identit Au-delà de la configuration initiale lors de la connexion / inscription, les utilisateurs peuvent gérer leurs paramètres MFA via un centre de compte en libre-service. Cela offre une flexibilité permettant aux utilisateurs de lier ou délier des facteurs MFA selon leurs besoins. -### Créer un centre de compte \{#building-an-account-center} +### Construire un centre de compte \{#building-an-account-center} -Vous pouvez créer un centre de compte complet en utilisant l’[Account API](/end-user-flows/account-settings/by-account-api) de Logto, qui permet aux utilisateurs de : +Vous pouvez construire un centre de compte complet en utilisant l’[Account API](/end-user-flows/account-settings/by-account-api) de Logto, qui permet aux utilisateurs de : - **Lier de nouveaux facteurs MFA** : Ajouter des applications d’authentification supplémentaires, des passkeys ou régénérer des codes de secours - **Délier des facteurs MFA existants** : Supprimer les méthodes MFA qu’ils ne souhaitent plus utiliser -- **Voir le statut MFA actuel** : Voir quels facteurs MFA sont actuellement configurés +- **Voir le statut actuel MFA** : Voir quels facteurs MFA sont actuellement configurés ### Invites de configuration MFA après connexion \{#post-login-mfa-setup-prompts} @@ -94,7 +94,7 @@ En savoir plus sur la mise en œuvre de ces modèles avec l’[Account API](/end ### Gérer le MFA d’un utilisateur dans la Console \{#manage-users-mfa-in-console} -Dans le Console > Gestion des utilisateurs, les administrateurs peuvent gérer efficacement les paramètres MFA des utilisateurs : +Dans la Console > Gestion des utilisateurs, les administrateurs peuvent gérer efficacement les paramètres MFA des utilisateurs : - **Voir le statut MFA de l’utilisateur** : Vérifier quels facteurs MFA sont activés pour chaque utilisateur. - **Supprimer le MFA de l’utilisateur** : Supprimer tous les facteurs MFA d’un utilisateur, l’obligeant à configurer à nouveau MFA. @@ -105,7 +105,7 @@ Dans le Console > Gestion des utilisateurs, le ### Que se passe-t-il lorsque les administrateurs suppriment les facteurs MFA existants d’un utilisateur ? \{#what-happens-when-administrators-remove-users-existing-mfa-factors} -Lorsque les administrateurs suppriment tous les facteurs MFA principaux d’un utilisateur (passkey, OTP d’application d’authentification, SMS ou e-mail), les scénarios suivants se produiront lors de la prochaine connexion de l’utilisateur : +Lorsque les administrateurs suppriment tous les facteurs MFA principaux d’un utilisateur (passkey, OTP via application d’authentification, SMS ou e-mail), les scénarios suivants se produiront lors de la prochaine connexion de l’utilisateur : **Scénario 1 : Aucun facteur MFA ne reste** @@ -116,6 +116,6 @@ Lorsque les administrateurs suppriment tous les facteurs MFA principaux d’un u - Si des codes de secours sont encore disponibles, l’utilisateur devra d’abord vérifier à l’aide d’un code de secours lors de la connexion. - Après une vérification réussie par code de secours, l’utilisateur sera invité à configurer un nouveau facteur principal MFA. - La possibilité pour l’utilisateur d’ignorer cette configuration dépend de votre politique MFA configurée. -- Cette approche évite que les utilisateurs soient bloqués de leur compte lorsqu’aucun facteur principal n’est disponible. +- Cette approche empêche les utilisateurs d’être bloqués hors de leur compte lorsqu’aucun facteur principal n’est disponible. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index 8d9de5470a2..0d9370015d1 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -6,7 +6,7 @@ sidebar_position: 4 ## Où l'utiliser \{#where-to-use-it} -Ceci est généralement utilisé sur la page de profil utilisateur où les utilisateurs doivent afficher les informations de leur organisation. +Ceci est généralement utilisé dans la page de profil utilisateur où les utilisateurs doivent afficher les informations de leur organisation. Informations utilisateur de l'organisation @@ -14,7 +14,7 @@ Ceci est généralement utilisé sur la page de profil utilisateur où les utili Il existe deux façons d'obtenir les informations utilisateur au sein d'une organisation. -### Décoder le jeton d’identifiant (ID token) \{#decode-the-id-token} +### Décoder le jeton d’identifiant \{#decode-the-id-token} Le jeton d’identifiant (ID token) est un JWT standard qui contient les informations de profil utilisateur et les revendications liées à l’organisation. Appelez la méthode SDK `decodeIdToken()` pour obtenir un objet JSON comme celui-ci : @@ -43,7 +43,7 @@ Le jeton d’identifiant (ID token) est un JWT standard qui contient les informa ``` Cependant, le jeton d’identifiant (ID token) n’est émis que lors de l’authentification et peut devenir obsolète si le profil utilisateur change par la suite. -Pour obtenir les informations les plus à jour, utilisez la seconde approche ci-dessous, ou appelez `clearAllTokens()` et réinitialisez un flux d’authentification pour obtenir un nouveau jeton d’identifiant (ID token). +Pour obtenir les informations les plus à jour, utilisez la seconde approche ci-dessous, ou appelez `clearAllTokens()` et relancez un flux d’authentification pour obtenir un nouveau jeton d’identifiant. ```ts await logtoClient.clearAllTokens(); @@ -53,8 +53,14 @@ logtoClient.signIn({ }); ``` -Si la session est toujours valide, l’appel à `signIn` redirigera vers votre application sans demander de nouvelles informations d’identification. Du point de vue de l’utilisateur, l’application se rafraîchit simplement et un nouveau jeton d’identifiant (ID token) est émis en arrière-plan. +Si la session est toujours valide, l’appel à `signIn` redirigera vers votre application sans nécessiter de saisie d’identifiants. Du point de vue de l’utilisateur, l’application se rafraîchit simplement et un nouveau jeton d’identifiant est émis en arrière-plan. ### Récupérer les informations utilisateur depuis l’endpoint `/oidc/me` \{#fetch-user-info-from-the-oidc-me-endpoint} Vous pouvez également interroger `/oidc/me` pour obtenir en temps réel les informations utilisateur dans le contexte de l’organisation. Appelez la méthode SDK `fetchUserInfo()`. + +:::tip[Prise en charge du jeton opaque] +Si vous utilisez un [jeton opaque](/concepts/opaque-token) (émis lorsqu’aucune ressource API n’est spécifiée), vous pouvez tout de même récupérer les informations d’appartenance à l’organisation via l’endpoint userinfo. Lorsque vous demandez la portée `urn:logto:scope:organizations`, la réponse inclura `organizations` et d’autres revendications liées à l’organisation. + +Notez que les jetons opaques ne peuvent pas être utilisés comme jetons d’organisation pour accéder à des ressources spécifiques à l’organisation. Voir [Jeton opaque et organisations](/concepts/opaque-token#opaque-token-and-organizations) pour plus de détails. +::: diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index c1f566f1f47..06ebace91be 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -8,18 +8,18 @@ Voici la liste des portées prises en charge et les revendications correspondant **`profile`** -| Nom de la revendication | Type | Description | Besoin de userinfo ? | -| ----------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------- | -| name | `string` | Le nom complet de l'utilisateur | Non | -| username | `string` | Le nom d'utilisateur de l'utilisateur | Non | -| picture | `string` | URL de la photo de profil de l'utilisateur final. Cette URL DOIT faire référence à un fichier image (par exemple, un fichier PNG, JPEG ou GIF), plutôt qu'à une page Web contenant une image. Notez que cette URL DOIT spécifiquement référencer une photo de profil de l'utilisateur final adaptée à l'affichage lors de la description de l'utilisateur final, plutôt qu'une photo arbitraire prise par l'utilisateur final. | Non | -| created_at | `number` | Heure à laquelle l'utilisateur final a été créé. Le temps est représenté comme le nombre de millisecondes écoulées depuis l'époque Unix (1970-01-01T00:00:00Z). | Non | -| updated_at | `number` | Heure à laquelle les informations de l'utilisateur final ont été mises à jour pour la dernière fois. Le temps est représenté comme le nombre de millisecondes écoulées depuis l'époque Unix (1970-01-01T00:00:00Z). | Non | +| Nom de la revendication | Type | Description | Besoin de userinfo ? | +| ----------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | +| name | `string` | Le nom complet de l'utilisateur | Non | +| username | `string` | Le nom d'utilisateur de l'utilisateur | Non | +| picture | `string` | URL de la photo de profil de l'utilisateur final. Cette URL DOIT référencer un fichier image (par exemple, un fichier PNG, JPEG ou GIF), plutôt qu'une page Web contenant une image. Notez que cette URL DOIT référencer spécifiquement une photo de profil de l'utilisateur final adaptée à l'affichage lors de la description de l'utilisateur final, plutôt qu'une photo arbitraire prise par l'utilisateur final. | Non | +| created_at | `number` | Date de création de l'utilisateur final. L'heure est représentée par le nombre de millisecondes écoulées depuis l'époque Unix (1970-01-01T00:00:00Z). | Non | +| updated_at | `number` | Date de la dernière mise à jour des informations de l'utilisateur final. L'heure est représentée par le nombre de millisecondes écoulées depuis l'époque Unix (1970-01-01T00:00:00Z). | Non | -D'autres [revendications standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) incluent `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, et `locale` seront également incluses dans la portée `profile` sans avoir besoin de demander le point de terminaison userinfo. Une différence par rapport aux revendications ci-dessus est que ces revendications ne seront renvoyées que lorsque leurs valeurs ne sont pas vides, tandis que les revendications ci-dessus renverront `null` si les valeurs sont vides. +D'autres [revendications standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) telles que `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo` et `locale` seront également incluses dans la portée `profile` sans avoir besoin de demander l'endpoint userinfo. Une différence par rapport aux revendications ci-dessus est que ces revendications ne seront retournées que si leurs valeurs ne sont pas vides, tandis que les revendications ci-dessus retourneront `null` si les valeurs sont vides. :::note -Contrairement aux revendications standard, les revendications `created_at` et `updated_at` utilisent des millisecondes au lieu de secondes. +Contrairement aux revendications standard, les revendications `created_at` et `updated_at` utilisent les millisecondes au lieu des secondes. ::: **`email`** @@ -38,7 +38,7 @@ Contrairement aux revendications standard, les revendications `created_at` et `u **`address`** -Veuillez vous référer à [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) pour les détails de la revendication d'adresse. +Veuillez vous référer à la [spécification OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) pour les détails de la revendication d'adresse. **`custom_data`** @@ -55,23 +55,27 @@ Veuillez vous référer à [OpenID Connect Core 1.0](https://openid.net/specs/op **`roles`** -| Nom de la revendication | Type | Description | Besoin de userinfo ? | -| ----------------------- | ---------- | -------------------------- | -------------------- | -| roles | `string[]` | Les rôles de l'utilisateur | Non | +| Nom de la revendication | Type | Description | Besoin de userinfo ? | +| ----------------------- | ---------- | ---------------------------------- | -------------------- | +| roles | `string[]` | Les rôles (Roles) de l'utilisateur | Non | **`urn:logto:scope:organizations`** -| Nom de la revendication | Type | Description | Besoin de userinfo ? | -| ----------------------- | ---------- | ----------------------------------------------------------------- | -------------------- | -| organizations | `string[]` | Les identifiants d'organisation auxquels l'utilisateur appartient | Non | -| organization_data | `object[]` | Les données d'organisation auxquelles l'utilisateur appartient | Oui | +| Nom de la revendication | Type | Description | Besoin de userinfo ? | +| ----------------------- | ---------- | -------------------------------------------------------------------------------------- | -------------------- | +| organizations | `string[]` | Les identifiants des organisations (Organizations) auxquelles l'utilisateur appartient | Non | +| organization_data | `object[]` | Les données des organisations (Organizations) auxquelles l'utilisateur appartient | Oui | + +:::note +Ces revendications d'organisation peuvent également être récupérées via l'endpoint userinfo lors de l'utilisation d'un [jeton opaque (Opaque token)](/concepts/opaque-token). Cependant, les jetons opaques ne peuvent pas être utilisés comme jetons d’organisation (Organization tokens) pour accéder à des ressources spécifiques à une organisation. Voir [Jeton opaque et organisations](/concepts/opaque-token#opaque-token-and-organizations) pour plus de détails. +::: **`urn:logto:scope:organization_roles`** -| Nom de la revendication | Type | Description | Besoin de userinfo ? | -| ----------------------- | ---------- | --------------------------------------------------------------------------------------------------------- | -------------------- | -| organization_roles | `string[]` | Les rôles d'organisation auxquels l'utilisateur appartient avec le format `:` | Non | +| Nom de la revendication | Type | Description | Besoin de userinfo ? | +| ----------------------- | ---------- | -------------------------------------------------------------------------------------------------------- | -------------------- | +| organization_roles | `string[]` | Les rôles d'organisation (Organization roles) de l'utilisateur au format `:` | Non | --- -En considérant la performance et la taille des données, si "Besoin de userinfo ?" est "Oui", cela signifie que la revendication n'apparaîtra pas dans le jeton d’identifiant, mais sera renvoyée dans la réponse du [point de terminaison userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). +En tenant compte des performances et de la taille des données, si "Besoin de userinfo ?" est "Oui", cela signifie que la revendication n'apparaîtra pas dans le jeton d’identifiant (ID token), mais sera retournée dans la réponse de l'[endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index 738e2825f5e..e0acee9786b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -4,11 +4,11 @@ sidebar_position: 6 # 不透明トークン (Opaque token) -認証 (Authentication) プロセス中にリソースが指定されていない場合、Logto は JWT の代わりに不透明トークン (Opaque token) を発行します。不透明トークンはランダムな文字列であり、JWT よりもはるかに短いです： +認証 (Authentication) プロセス中にリソースが指定されていない場合、Logto は JWT ではなく不透明トークン (Opaque token) のアクセス トークンを発行します。不透明トークンはランダムな文字列であり、JWT よりもはるかに短いです： ```json { - "access_token": "some-random-string", // 不透明トークン + "access_token": "some-random-string", // 不透明トークン (opaque token) "expires_in": 3600, "id_token": "eyJhbGc...aBc", // JWT "scope": "openid profile email", @@ -16,22 +16,22 @@ sidebar_position: 6 } ``` -不透明トークンは、[userinfo エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) を呼び出すためや、認証 (Authentication) を必要とする保護されたリソースにアクセスするために使用できます。JWT ではないため、リソースサーバーはどのようにしてそれを検証できるのでしょうか？ +不透明トークンは、 [userinfo エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) の呼び出しや、認証 (Authentication) が必要な保護されたリソースへのアクセスに使用できます。JWT ではないため、リソースサーバーはどのようにしてこれを検証できるのでしょうか？ -Logto は、不透明トークンを検証するために使用できる [introspection エンドポイント](https://www.rfc-editor.org/rfc/rfc7662.html) を提供しています。デフォルトでは、introspection エンドポイントは `/oidc/token/introspection` であり、`POST` リクエストを受け付けます。次のパラメーターが必要です： +Logto は、不透明トークンの検証に使用できる [イントロスペクションエンドポイント](https://www.rfc-editor.org/rfc/rfc7662.html) を提供しています。デフォルトでは、イントロスペクションエンドポイントは `/oidc/token/introspection` であり、`POST` リクエストを受け付けます。必要なパラメーターは次のとおりです： - `token`: 検証する不透明トークン -このエンドポイントはクライアント認証も必要とします。次のいずれかの方法を使用できます： +このエンドポイントはクライアント認証も必要です。次のいずれかの方法を使用できます： -- HTTP Basic 認証: `Authorization` ヘッダーに `Basic ` の値を使用します。資格情報はクライアント ID とクライアントシークレットをコロン (`:`) で区切り、base64 エンコードしたものです。 -- HTTP POST 認証: `client_id` と `client_secret` パラメーターを使用します： - - `client_id`: トークンを要求したアプリケーションのクライアント ID - - `client_secret`: トークンを要求したアプリケーションのクライアントシークレット +- HTTP Basic 認証：`Authorization` ヘッダーに `Basic ` を指定します。認証情報はクライアント ID とクライアントシークレットをコロン（`:`）で区切り、base64 エンコードしたものです。 +- HTTP POST 認証：`client_id` および `client_secret` パラメーターを使用します： + - `client_id`: トークンをリクエストしたアプリケーションのクライアント ID + - `client_secret`: トークンをリクエストしたアプリケーションのクライアントシークレット -クライアント ID (アプリ ID) とクライアントシークレット (アプリシークレット) は、Logto の任意の「従来のウェブ」または「マシン間通信」アプリケーションからのアプリ資格情報であることができます。資格情報が無効な場合、introspection エンドポイントはエラーを返します。 +クライアント ID（アプリ ID）およびクライアントシークレット（アプリシークレット）は、Logto の「従来の Web」または「マシン間通信」アプリケーションのアプリ認証情報を使用できます。認証情報が無効な場合、イントロスペクションエンドポイントはエラーを返します。 -introspection エンドポイントは、トークンのクレームを含む JSON オブジェクトを返します： +イントロスペクションエンドポイントは、トークンのクレーム (Claims) を含む JSON オブジェクトを返します： ```json { @@ -40,9 +40,9 @@ introspection エンドポイントは、トークンのクレームを含む JS } ``` -トークンが無効な場合、`active` フィールドは `false` になり、`sub` フィールドは省略されます。 +トークンが無効な場合、`active` フィールドは `false` となり、`sub` フィールドは省略されます。 -以下は、introspection リクエストの非規範的な例です： +イントロスペクションリクエストの非公式な例を示します： ```bash curl --location \ @@ -53,4 +53,15 @@ curl --location \ --data-urlencode 'client_secret=1234567890' ``` -`[tenant-id]` をあなたのテナント ID に置き換えることを忘れないでください。 +`[tenant-id]` をテナント ID に置き換えてください。 + +## 不透明トークンと組織 (Organizations) \{#opaque-token-and-organizations} + +不透明トークンは、 [userinfo エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) を通じて組織 (Organization) メンバーシップ情報の取得に使用できます。`urn:logto:scope:organizations` スコープをリクエストすると、userinfo エンドポイントは `organizations`（組織 ID）や `organization_data` など、ユーザーの組織 (Organization) 関連のクレーム (Claims) を返します。 + +ただし、**不透明トークンは組織トークン (Organization token) として使用できません**。組織トークン (Organization token) は常に JWT 形式で発行されます。その理由は： + +1. 組織トークン (Organization token) には、`organization_id` やスコープされた権限など、リソースサーバーが検証する必要がある組織 (Organization) 固有のクレーム (Claims) が含まれています。 +2. JWT 形式であれば、リソースサーバーは追加の API コールなしでトークンを検証し、組織 (Organization) コンテキストを抽出できます。 + +組織トークン (Organization token) を取得するには、 [リフレッシュトークンフロー](/authorization/organization-permissions#refresh-token-flow) または [クライアントクレデンシャルフロー](/authorization/organization-permissions#client-credentials-flow) を組織 (Organization) パラメーターとともに使用してください。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index 953788539de..1f0d9a66ff8 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -6,39 +6,39 @@ sidebar_position: 1 ## Logto での MFA 設定 \{#configure-mfa-settings-in-logto} -Logto は、さまざまなセキュリティ要件に対応する柔軟な多要素認証 (MFA) 設定オプションを提供しています。すべてのユーザーに対してグローバルレベルで MFA を設定することも、マルチテナントアプリケーション向けに組織ごとに有効化することも可能です。 +Logto は、さまざまなセキュリティ要件に対応する柔軟な多要素認証 (MFA) 設定オプションを提供しています。すべてのユーザーに対してグローバルレベルで MFA を設定したり、マルチテナントアプリケーション向けに組織ごとに有効化したりできます。 ### グローバル MFA 設定 \{#global-mfa-configuration} -ユーザーの Logto サインインフローで MFA を有効にするには、次の手順に従ってください： +ユーザーの Logto サインインフローで MFA を有効にするには、以下の手順に従ってください： 1. コンソール > 多要素認証 に移動します。 2. ユーザー向けにサポートされている認証要素を有効にします。 1. プライマリ要素： - [パスキー (WebAuthn)](/end-user-flows/mfa/webauthn)：デバイスの生体認証やセキュリティキーなどをサポートする Web 製品に適した高セキュリティオプションで、強力な保護を実現します。 - - [認証アプリ OTP](/end-user-flows/mfa/authenticator-app-otp)：最も一般的で広く受け入れられている方法です。Google Authenticator や Authy などの認証アプリによって生成される時限ワンタイムパスワード (TOTP) を使用します。 + - [認証アプリ OTP](/end-user-flows/mfa/authenticator-app-otp)：最も一般的で広く受け入れられている方法です。Google Authenticator や Authy などの認証アプリで生成される時限ワンタイムパスワード (TOTP) を使用します。 - [SMS 認証](/end-user-flows/mfa/sms-mfa)：ユーザーの登録済み電話番号に SMS でワンタイム認証コードを送信する便利な方法で、追加アプリなしでモバイル認証を好むユーザーに最適です。 - [メール認証](/end-user-flows/mfa/email-mfa)：ユーザーの登録済みメールアドレスにワンタイム認証コードを送信する広く利用可能な方法で、すべてのプラットフォームやデバイスのユーザーに適しています。 2. バックアップ要素： - - [バックアップコード](/end-user-flows/mfa/backup-codes)：上記のプライマリ要素で認証できない場合のバックアップオプションとして機能します。このオプションを有効にすることで、ユーザーのアクセス成功率が向上します。 -3. **MFA 必須** を有効にするかどうかを選択します： - - **有効**：ユーザーはサインイン時に MFA の設定を求められ、スキップできません。ユーザーが MFA を設定しなかったり、MFA 設定を削除した場合、再度 MFA を設定するまでアカウントにアクセスできなくなります。 - - **無効**：ユーザーはサインアップフロー中に MFA 設定をスキップできます。後からセルフサービスのアカウント設定ページで MFA を設定することも可能です。ユーザーアカウント設定ページの実装については [詳細はこちら](/end-user-flows/account-settings/) をご覧ください。さらに MFA 設定プロンプトのポリシーを選択します： + - [バックアップコード](/end-user-flows/mfa/backup-codes)：上記のプライマリ要素で認証できない場合のバックアップオプションです。このオプションを有効にすると、ユーザーのアクセス成功率が向上します。 +3. **MFA 必須**を有効にするかどうかを選択します： + - **有効**：ユーザーはサインイン時に MFA の設定を求められ、スキップできません。MFA 設定を行わなかったり削除した場合、再度 MFA を設定するまでアカウントにアクセスできなくなります。 + - **無効**：ユーザーはサインアップフロー中に MFA 設定をスキップできます。後からセルフサービスのアカウント設定ページで MFA を設定できます。[詳細はこちら](/end-user-flows/account-settings/) でユーザーアカウント設定ページの実装方法を確認できます。さらに MFA 設定プロンプトのポリシーを選択します： - **ユーザーに MFA 設定を求めない**：サインイン時に MFA 設定を求めません。 - - **登録時に MFA 設定を求める**：新規ユーザーは登録時に MFA 設定を求められ、既存ユーザーは次回サインイン時にプロンプトが表示されます。ユーザーはこのステップをスキップでき、再度表示されることはありません。 - - **登録後のサインイン時に MFA 設定を求める**：新規ユーザーは登録後 2 回目のサインイン時に MFA 設定を求められ、既存ユーザーは次回サインイン時にプロンプトが表示されます。ユーザーはこのステップをスキップでき、再度表示されることはありません。 + - **登録時に MFA 設定を求める**：新規ユーザーは登録時に MFA 設定を求められ、既存ユーザーは次回サインイン時にプロンプトが表示されます。ユーザーはこのステップをスキップでき、再度表示されません。 + - **登録後のサインイン時に MFA 設定を求める**：新規ユーザーは登録後 2 回目のサインイン時に MFA 設定を求められ、既存ユーザーは次回サインイン時にプロンプトが表示されます。ユーザーはこのステップをスキップでき、再度表示されません。 :::tip -ユーザーが MFA 登録をスキップした後に再度プロンプトを表示したい場合は、スキップ状態をリセットしてください。これにより、次回サインイン時に設定画面が表示されます。管理者は Management API (`PATCH /api/users/{userId}/logto-configs`) を利用でき、セルフサービスフローを構築する開発者は Account API (`PATCH /api/my-account/logto-configs`) を呼び出せます。 [Management API リファレンス](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) ・ [Account API リファレンス](https://openapi.logto.io/operation/operation-updatelogtoconfig) +ユーザーが MFA 登録をスキップした後に再度プロンプトを表示したい場合は、スキップ状態をリセットしてください。管理者は Management API (`PATCH /api/users/{userId}/logto-configs`) を、セルフサービスフローを構築する開発者は Account API (`PATCH /api/my-account/logto-configs`) を利用できます。 [Management API リファレンス](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) ・ [Account API リファレンス](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: MFA 設定 ### 組織単位の MFA 設定 \{#organization-level-mfa-configuration} -[組織 (Organizations)](/organizations) をサポートするマルチテナントアーキテクチャの製品では、すべてのユーザーに MFA を必須とする必要はありません。代わりに、組織ごとに MFA を有効化でき、各クライアントのニーズに合わせて要件を調整できます。始めるには、[組織メンバーに MFA を必須にする](/organizations/organization-management#require-mfa-for-organization-members) を参照してください。 +[組織 (Organizations)](/organizations) をサポートするマルチテナントアーキテクチャの製品では、すべてのユーザーに MFA を必須とする必要はありません。代わりに、組織ごとに MFA を有効化でき、各クライアントのニーズに応じて要件を調整できます。始めるには [組織メンバーに MFA を必須化する](/organizations/organization-management#require-mfa-for-organization-members) を参照してください。 -**多要素認証** セクションで、**組織が MFA を有効にした後のユーザーへの MFA 設定プロンプト** を **次回サインイン時に MFA 設定を求める（スキップ不可）** に設定します。MFA が必須の組織のメンバーは、次回サインイン時に MFA 設定を完了するよう求められ、このプロンプトはスキップできません。 +**多要素認証**セクションで、**組織が MFA を有効化した後のユーザーへの MFA 設定プロンプト**を**次回サインイン時に MFA 設定を求める（スキップ不可）**に設定します。MFA が必須の組織のメンバーは、次回サインイン時に MFA 設定を完了するよう求められ、このプロンプトはスキップできません。 ## MFA ユーザーフロー \{#mfa-user-flow} @@ -50,35 +50,35 @@ MFA が有効になると、ユーザーはサインインやサインアップ 2. **サインインまたはサインアップを完了**：ユーザーがサインインまたはサインアップフロー内でアイデンティティ認証を完了します。 3. **MFA プライマリ要素の設定**：ユーザーはプライマリ MFA 要素（パスキー、認証アプリ OTP、SMS コード、メールコードのいずれか）の設定を求められます。 - 複数のプライマリ要素が有効な場合、ユーザーは希望するオプションを選択できます。 - - プライマリ要素がサインアップ識別子（例：SMS やメール）と同じ場合は事前認証され、ユーザーは認証ステップをスキップして次のステップ（例：「2段階認証を追加」や「バックアップ要素を保存」）に進めます。 - - 「MFA 必須」ポリシーが無効の場合、「スキップ」ボタンを選択してこのステップを省略できます。 + - プライマリ要素がサインアップ識別子（例：SMS やメール）と同じ場合は事前認証され、認証ステップをスキップして次のステップ（例：「別の 2 段階認証を追加」や「バックアップ要素を保存」）に進めます。 + - 「MFA 必須」ポリシーが無効な場合、「スキップ」ボタンを選択してこのステップを省略できます。 4. **MFA バックアップ要素の設定**：**バックアップコード**が有効な場合、ユーザーはプライマリ認証要素の設定完了後にバックアップコードの保存を求められます。自動生成されたバックアップコードが表示され、ユーザーはダウンロードして安全に保管できます。MFA 設定を完了するには、ユーザーがバックアップコードを手動で確認する必要があります。 MFA 設定フロー ### MFA 認証フロー \{#mfa-verification-flow} -MFA を設定したユーザーは、サインイン時に設定済みの MFA 要素で本人確認を求められます。認証要素は Logto の MFA 設定とユーザー設定に依存します。 +MFA を設定したユーザーは、サインイン時に設定済みの MFA 要素で本人確認を求められます。認証要素は Logto の MFA 設定とユーザーの設定に依存します。 - ユーザーが 1 つの要素のみ設定している場合は、その要素で直接認証します。 - 2 要素認証 (2FA) のために複数の要素を設定している場合、システムは以下の優先ルールに基づいて認証オプションを提示します： - **パスキー優先**：ユーザーがパスキーを設定している場合、それがデフォルトの認証方法として提示されます。 - **最終利用優先**：パスキーがない場合、システムはユーザーが最後に成功した認証方法を優先します。 - - **選択リスト**：上記のいずれにも該当しない場合、2段階認証ページで利用可能なすべての認証方法が表示され、ユーザーが選択できます。 - - ユーザーは「他の方法で認証する」をクリックして、いつでも認証オプションを切り替えられます。 + - **選択リスト**：上記のいずれにも該当しない場合、2 段階認証ページで利用可能なすべての認証方法が表示され、ユーザーが選択できます。 + - ユーザーは「別の方法で認証する」をクリックして、いつでも認証オプションを切り替えられます。 - 有効なプライマリ要素がすべて利用できず、バックアップコードが有効な場合は、ワンタイムバックアップコードで本人確認が可能です。 MFA 認証フロー ## MFA 管理 \{#mfa-management} -サインイン／サインアップ時の初期設定に加え、ユーザーはセルフサービスのアカウントセンターで MFA 設定を管理できます。これにより、ユーザーは必要に応じて MFA 要素の紐付けや解除が柔軟に行えます。 +サインイン／サインアップ時の初期設定に加え、ユーザーはセルフサービスのアカウントセンターで MFA 設定を管理できます。これにより、ユーザーは必要に応じて MFA 要素の追加や解除が柔軟に行えます。 ### アカウントセンターの構築 \{#building-an-account-center} Logto の [Account API](/end-user-flows/account-settings/by-account-api) を利用して、包括的なアカウントセンターを構築できます。ユーザーは以下の操作が可能です： -- **新しい MFA 要素の紐付け**：追加の認証アプリやパスキーの追加、バックアップコードの再生成 +- **新しい MFA 要素の追加**：追加の認証アプリやパスキーの登録、バックアップコードの再生成 - **既存の MFA 要素の解除**：不要になった MFA 方法の削除 - **現在の MFA 状態の確認**：現在設定されている MFA 要素の確認 @@ -87,8 +87,8 @@ Logto の [Account API](/end-user-flows/account-settings/by-account-api) を利 初回登録時に MFA を必須としないアプリケーションでは、MFA 設定を促すインテリジェントなプロンプトを実装できます： - **条件付きプロンプト**：ユーザーの行動やアカウント価値に基づいて MFA 設定を推奨 -- **セキュリティダッシュボード**：MFA 有効化でスコアが向上するセキュリティスコアの表示 -- **段階的オンボーディング**：MFA 設定を段階的なセキュリティ強化フローの一部として提示 +- **セキュリティダッシュボード**：MFA 有効化で向上するセキュリティスコアの表示 +- **段階的オンボーディング**：セキュリティ強化フローの一部として MFA 設定を案内 これらのパターンの実装方法は [Account API](/end-user-flows/account-settings/by-account-api) で詳しく解説しています。 @@ -115,7 +115,7 @@ Logto の [Account API](/end-user-flows/account-settings/by-account-api) を利 **シナリオ 2：バックアップコードが残っている場合** - バックアップコードが利用可能な場合、ユーザーはサインイン時にまずバックアップコードで認証する必要があります。 -- バックアップコードによる認証が成功すると、新しいプライマリ MFA 要素の設定を求められます。 +- バックアップコード認証に成功すると、新しいプライマリ MFA 要素の設定を求められます。 - この設定をスキップできるかどうかは、設定した MFA ポリシーによります。 - この方法により、プライマリ要素が利用できない場合でもユーザーがアカウントから締め出されることを防ぎます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index 32fed627cd9..bf31a6af347 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -6,7 +6,7 @@ sidebar_position: 4 ## 利用シーン \{#where-to-use-it} -これは通常、ユーザープロフィールページでユーザーの組織情報を表示する必要がある場合に使用されます。 +これは通常、ユーザープロフィールページで組織情報を表示する必要がある場合に使用されます。 組織ユーザー情報 @@ -16,7 +16,7 @@ sidebar_position: 4 ### ID トークン (ID token) をデコードする \{#decode-the-id-token} -ID トークン (ID token) は、ユーザープロフィール情報や組織に関連するクレーム (Claims) を含む標準的な JWT です。SDK の `decodeIdToken()` メソッドを呼び出すと、次のような JSON オブジェクトが取得できます： +ID トークン (ID token) は、ユーザープロフィール情報や組織関連のクレーム (Claims) を含む標準的な JWT です。SDK の `decodeIdToken()` メソッドを呼び出すと、次のような JSON オブジェクトが取得できます： ```json { @@ -43,7 +43,7 @@ ID トークン (ID token) は、ユーザープロフィール情報や組織 ``` ただし、ID トークン (ID token) は認証 (Authentication) 時にのみ発行されるため、その後ユーザープロフィールが変更された場合は古くなる可能性があります。 -最新の情報が必要な場合は、下記の 2 番目の方法を利用するか、`clearAllTokens()` を呼び出して認証 (Authentication) フローを再実行し、新しい ID トークン (ID token) を取得してください。 +最新の情報が必要な場合は、下記の 2 つ目の方法を利用するか、`clearAllTokens()` を呼び出して認証 (Authentication) フローを再実行し、新しい ID トークン (ID token) を取得してください。 ```ts await logtoClient.clearAllTokens(); @@ -53,8 +53,14 @@ logtoClient.signIn({ }); ``` -セッションが有効な場合、`signIn` の呼び出しは認証情報の入力を求めずにアプリへリダイレクトします。ユーザーから見ると、アプリが単にリフレッシュされ、裏側で新しい ID トークン (ID token) が発行されます。 +セッションが有効な場合、`signIn` の呼び出しは認証情報の入力なしでアプリにリダイレクトされます。ユーザーから見ると、アプリが単にリフレッシュされ、裏側で新しい ID トークン (ID token) が発行されます。 ### `/oidc/me` エンドポイントからユーザー情報を取得する \{#fetch-user-info-from-the-oidc-me-endpoint} また、`/oidc/me` にリクエストすることで、組織コンテキストでリアルタイムのユーザー情報を取得できます。SDK の `fetchUserInfo()` メソッドを呼び出してください。 + +:::tip[不透明トークン (Opaque token) サポート] +[不透明トークン (Opaque token)](/concepts/opaque-token)（API リソースが指定されていない場合に発行されます）を使用している場合でも、userinfo エンドポイントを通じて組織メンバーシップ情報を取得できます。`urn:logto:scope:organizations` スコープをリクエストすると、レスポンスに `organizations` やその他の組織関連クレーム (Claims) が含まれます。 + +不透明トークン (Opaque token) は、組織固有リソースへのアクセスのための組織トークン (Organization token) としては利用できませんのでご注意ください。詳細は [不透明トークン (Opaque token) と組織](/concepts/opaque-token#opaque-token-and-organizations) をご覧ください。 +::: diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index de74e738106..a5ff6f52308 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -1,77 +1,81 @@ -サポートされているスコープと対応するクレームのリストはこちらです： +こちらはサポートされているスコープと対応するクレーム (Claims) の一覧です： **`openid`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| ---------- | -------- | ---------------------- | ---------------------- | -| sub | `string` | ユーザーの一意の識別子 | いいえ | +| Claim name | Type | 説明 | Needs userinfo? | +| ---------- | -------- | ---------------------- | --------------- | +| sub | `string` | ユーザーの一意の識別子 | No | **`profile`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| ---------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | -| name | `string` | ユーザーのフルネーム | いいえ | -| username | `string` | ユーザーのユーザー名 | いいえ | -| picture | `string` | エンドユーザーのプロフィール画像の URL。この URL は画像ファイル（例：PNG、JPEG、または GIF 画像ファイル）を参照する必要があります。画像を含む Web ページを参照してはいけません。この URL は、エンドユーザーを説明する際に表示するのに適したプロフィール写真を特に参照するべきであり、エンドユーザーが撮影した任意の写真を参照するべきではありません。 | いいえ | -| created_at | `number` | エンドユーザーが作成された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。 | いいえ | -| updated_at | `number` | エンドユーザーの情報が最後に更新された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。 | いいえ | +| Claim name | Type | 説明 | Needs userinfo? | +| ---------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | +| name | `string` | ユーザーのフルネーム | No | +| username | `string` | ユーザーのユーザー名 | No | +| picture | `string` | エンドユーザーのプロフィール画像の URL。この URL は画像ファイル（例：PNG、JPEG、GIF 画像ファイル）を指す必要があります。画像を含む Web ページではありません。この URL は、エンドユーザーを説明する際に表示するのに適したプロフィール写真を参照するべきであり、エンドユーザーが撮影した任意の写真ではありません。 | No | +| created_at | `number` | エンドユーザーが作成された時刻。時刻は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。 | No | +| updated_at | `number` | エンドユーザーの情報が最後に更新された時刻。時刻は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。 | No | -その他の [標準クレーム](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) には、`family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`website`、`gender`、`birthdate`、`zoneinfo`、および `locale` が含まれ、ユーザー情報エンドポイントを要求することなく `profile` スコープに含まれます。上記のクレームと比較しての違いは、これらのクレームは値が空でない場合にのみ返されることであり、上記のクレームは値が空の場合に `null` を返します。 +その他の [標準クレーム (Standard Claims)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) には、`family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`website`、`gender`、`birthdate`、`zoneinfo`、`locale` などがあり、これらも `profile` スコープに含まれ、userinfo エンドポイントをリクエストする必要はありません。上記のクレームとの違いは、これらのクレームは値が空でない場合のみ返される点です。一方、上記のクレームは値が空の場合 `null` が返されます。 :::note -標準クレームとは異なり、`created_at` と `updated_at` クレームは秒ではなくミリ秒を使用しています。 +標準クレームと異なり、`created_at` および `updated_at` クレームは秒ではなくミリ秒を使用しています。 ::: **`email`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| -------------- | --------- | -------------------------------- | ---------------------- | -| email | `string` | ユーザーのメールアドレス | いいえ | -| email_verified | `boolean` | メールアドレスが確認済みかどうか | いいえ | +| Claim name | Type | 説明 | Needs userinfo? | +| -------------- | --------- | -------------------------------- | --------------- | +| email | `string` | ユーザーのメールアドレス | No | +| email_verified | `boolean` | メールアドレスが認証済みかどうか | No | **`phone`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| --------------------- | --------- | -------------------------- | ---------------------- | -| phone_number | `string` | ユーザーの電話番号 | いいえ | -| phone_number_verified | `boolean` | 電話番号が確認済みかどうか | いいえ | +| Claim name | Type | 説明 | Needs userinfo? | +| --------------------- | --------- | -------------------------- | --------------- | +| phone_number | `string` | ユーザーの電話番号 | No | +| phone_number_verified | `boolean` | 電話番号が認証済みかどうか | No | **`address`** -住所クレームの詳細については、[OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) を参照してください。 +アドレスクレームの詳細については [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) を参照してください。 **`custom_data`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| ----------- | -------- | ------------------------ | ---------------------- | -| custom_data | `object` | ユーザーのカスタムデータ | はい | +| Claim name | Type | 説明 | Needs userinfo? | +| ----------- | -------- | ------------------------ | --------------- | +| custom_data | `object` | ユーザーのカスタムデータ | Yes | **`identities`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| -------------- | -------- | ------------------------------------------- | ---------------------- | -| identities | `object` | ユーザーのリンクされたアイデンティティ | はい | -| sso_identities | `array` | ユーザーのリンクされた SSO アイデンティティ | はい | +| Claim name | Type | 説明 | Needs userinfo? | +| -------------- | -------- | ----------------------------------------- | --------------- | +| identities | `object` | ユーザーのリンク済みアイデンティティ | Yes | +| sso_identities | `array` | ユーザーのリンク済み SSO アイデンティティ | Yes | **`roles`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| ---------- | ---------- | ---------------- | ---------------------- | -| roles | `string[]` | ユーザーのロール | いいえ | +| Claim name | Type | 説明 | Needs userinfo? | +| ---------- | ---------- | ------------------------ | --------------- | +| roles | `string[]` | ユーザーのロール (Roles) | No | **`urn:logto:scope:organizations`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| ----------------- | ---------- | ------------------------------ | ---------------------- | -| organizations | `string[]` | ユーザーが所属する組織の ID | いいえ | -| organization_data | `object[]` | ユーザーが所属する組織のデータ | はい | +| Claim name | Type | 説明 | Needs userinfo? | +| ----------------- | ---------- | ----------------------------------------------- | --------------- | +| organizations | `string[]` | ユーザーが所属する組織 (Organizations) の ID | No | +| organization_data | `object[]` | ユーザーが所属する組織 (Organizations) のデータ | Yes | + +:::note +これらの組織 (Organizations) クレームは、[不透明トークン (Opaque token)](/concepts/opaque-token) を使用する場合にも userinfo エンドポイント経由で取得できます。ただし、不透明トークン (Opaque token) は組織トークン (Organization token) として組織固有リソースへのアクセスには使用できません。詳細は [不透明トークン (Opaque token) と組織 (Organizations)](/concepts/opaque-token#opaque-token-and-organizations) を参照してください。 +::: **`urn:logto:scope:organization_roles`** -| クレーム名 | タイプ | 説明 | ユーザー情報が必要か？ | -| ------------------ | ---------- | ------------------------------------------------------------------------ | ---------------------- | -| organization_roles | `string[]` | ユーザーが所属する組織のロール（`:` の形式） | いいえ | +| Claim name | Type | 説明 | Needs userinfo? | +| ------------------ | ---------- | ----------------------------------------------------------------------------------------------- | --------------- | +| organization_roles | `string[]` | ユーザーが所属する組織 (Organizations) のロール (Roles)。形式は `:` | No | --- -パフォーマンスとデータサイズを考慮して、「ユーザー情報が必要か？」が「はい」の場合、クレームは ID トークンには表示されず、[ユーザー情報エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) のレスポンスで返されます。 +パフォーマンスとデータサイズを考慮し、「Needs userinfo?」が「Yes」の場合、そのクレーム (Claim) は ID トークン (ID token) には表示されず、[userinfo エンドポイント](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) のレスポンスで返されます。 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index 97efd3491cd..8ec2de71c6e 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -4,11 +4,11 @@ sidebar_position: 6 # 불투명 토큰 (Opaque token) -인증 과정에서 리소스가 지정되지 않으면, Logto는 JWT 대신 불투명 액세스 토큰을 발급합니다. 불투명 토큰은 무작위 문자열이며, JWT보다 훨씬 짧습니다: +인증 (Authentication) 과정에서 리소스가 지정되지 않은 경우, Logto는 JWT 대신 불투명 토큰 (opaque token)을 액세스 토큰 (Access token)으로 발급합니다. 불투명 토큰은 무작위 문자열이며, JWT보다 훨씬 짧습니다: ```json { - "access_token": "some-random-string", // 불투명 토큰 + "access_token": "some-random-string", // 불투명 토큰 (opaque token) "expires_in": 3600, "id_token": "eyJhbGc...aBc", // JWT "scope": "openid profile email", @@ -16,33 +16,33 @@ sidebar_position: 6 } ``` -불투명 토큰은 [userinfo 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)를 호출하고 인증이 필요한 보호된 리소스에 접근하는 데 사용할 수 있습니다. JWT가 아니기 때문에, 리소스 서버는 이를 어떻게 검증할 수 있을까요? +불투명 토큰은 [userinfo 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 호출 및 인증 (Authentication)이 필요한 보호된 리소스에 접근하는 데 사용할 수 있습니다. JWT가 아니기 때문에, 리소스 서버는 이를 어떻게 검증할 수 있을까요? -Logto는 불투명 토큰을 검증할 수 있는 [introspection 엔드포인트](https://www.rfc-editor.org/rfc/rfc7662.html)를 제공합니다. 기본적으로 introspection 엔드포인트는 `/oidc/token/introspection`이며 `POST` 요청을 수락합니다. 다음 매개변수가 필요합니다: +Logto는 불투명 토큰을 검증할 수 있는 [introspection 엔드포인트](https://www.rfc-editor.org/rfc/rfc7662.html)를 제공합니다. 기본적으로 introspection 엔드포인트는 `/oidc/token/introspection`이며, `POST` 요청을 받습니다. 다음 파라미터가 필요합니다: - `token`: 검증할 불투명 토큰 -엔드포인트는 또한 클라이언트 인증이 필요합니다. 다음 방법 중 하나를 사용할 수 있습니다: +이 엔드포인트는 클라이언트 인증도 필요합니다. 다음 방법 중 하나를 사용할 수 있습니다: -- HTTP Basic 인증: `Authorization` 헤더에 `Basic ` 값을 사용합니다. 자격 증명은 클라이언트 ID와 클라이언트 시크릿을 콜론 (`:`)으로 구분하고 base64로 인코딩해야 합니다. -- HTTP POST 인증: `client_id` 및 `client_secret` 매개변수를 사용합니다: +- HTTP Basic 인증: `Authorization` 헤더에 `Basic ` 값을 사용합니다. 자격 증명은 클라이언트 ID와 클라이언트 시크릿을 콜론(`:`)으로 구분하여 base64로 인코딩한 값이어야 합니다. +- HTTP POST 인증: `client_id`와 `client_secret` 파라미터를 사용합니다: - `client_id`: 토큰을 요청한 애플리케이션의 클라이언트 ID - `client_secret`: 토큰을 요청한 애플리케이션의 클라이언트 시크릿 -클라이언트 ID (앱 ID)와 클라이언트 시크릿 (앱 시크릿)은 Logto의 "전통적인 웹" 또는 "기계 간" 애플리케이션의 앱 자격 증명일 수 있습니다. 자격 증명이 유효하지 않으면 introspection 엔드포인트는 오류를 반환합니다. +클라이언트 ID (앱 ID)와 클라이언트 시크릿 (앱 시크릿)은 Logto의 "전통적인 웹" 또는 "기계 간" 애플리케이션의 앱 자격 증명일 수 있습니다. 자격 증명이 올바르지 않으면 introspection 엔드포인트는 오류를 반환합니다. -introspection 엔드포인트는 토큰의 클레임을 포함한 JSON 객체를 반환합니다: +introspection 엔드포인트는 토큰의 클레임 (Claim) 정보를 담은 JSON 객체를 반환합니다: ```json { "active": true, // 토큰이 유효한지 여부 - "sub": "1234567890" // 토큰의 주체 (사용자 ID) + "sub": "1234567890" // 토큰의 주체 (Subject, 사용자 ID) } ``` -토큰이 유효하지 않으면, `active` 필드는 `false`가 되고 `sub` 필드는 생략됩니다. +토큰이 유효하지 않은 경우, `active` 필드는 `false`가 되고, `sub` 필드는 생략됩니다. -다음은 introspection 요청의 비규범적 예입니다: +다음은 introspection 요청의 비공식 예시입니다: ```bash curl --location \ @@ -53,4 +53,15 @@ curl --location \ --data-urlencode 'client_secret=1234567890' ``` -`[tenant-id]`를 자신의 테넌트 ID로 교체하는 것을 잊지 마세요. +`[tenant-id]`를 자신의 테넌트 ID로 교체해야 합니다. + +## 불투명 토큰과 조직 (Opaque token and organizations) \{#opaque-token-and-organizations} + +불투명 토큰은 [userinfo 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)를 통해 조직 (Organization) 멤버십 정보를 조회하는 데 사용할 수 있습니다. `urn:logto:scope:organizations` 스코프 (Scope)를 요청하면, userinfo 엔드포인트는 사용자의 조직 관련 클레임 (예: `organizations`(조직 ID) 및 `organization_data`)을 반환합니다. + +하지만, **불투명 토큰은 조직 토큰 (Organization token)으로 사용할 수 없습니다**. 조직 토큰은 항상 JWT 형식으로 발급됩니다. 그 이유는 다음과 같습니다: + +1. 조직 토큰에는 조직별 클레임 (예: `organization_id` 및 범위가 지정된 권한 (Permission))이 포함되어 있으며, 이는 리소스 서버에서 검증해야 합니다. +2. JWT 형식은 리소스 서버가 추가적인 API 호출 없이 토큰을 검증하고 조직 컨텍스트를 추출할 수 있게 해줍니다. + +조직 토큰을 얻으려면, [리프레시 토큰 플로우](/authorization/organization-permissions#refresh-token-flow) 또는 [클라이언트 자격 증명 플로우](/authorization/organization-permissions#client-credentials-flow)에서 조직 파라미터를 사용해야 합니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index 962faa1999c..22b711eb2d3 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -6,81 +6,81 @@ sidebar_position: 1 ## Logto에서 MFA 설정 구성하기 \{#configure-mfa-settings-in-logto} -Logto는 다양한 보안 요구 사항을 충족할 수 있도록 유연한 MFA 구성 옵션을 제공합니다. 모든 사용자에게 글로벌 수준에서 MFA를 구성하거나, 다중 테넌트 애플리케이션의 경우 조직별로 활성화할 수 있습니다. +Logto는 다양한 보안 요구 사항을 충족할 수 있도록 유연한 MFA 구성 옵션을 제공합니다. 모든 사용자에게 글로벌 수준에서 MFA를 설정하거나, 멀티 테넌트 애플리케이션의 경우 조직별로 활성화할 수 있습니다. ### 글로벌 MFA 구성 \{#global-mfa-configuration} -사용자의 Logto 로그인 흐름에서 MFA를 활성화하려면 다음 단계를 따르세요: +사용자의 Logto 로그인 플로우에서 MFA를 활성화하려면 다음 단계를 따르세요: -1. 이동: 콘솔 > 다단계 인증 (MFA). +1. 다음으로 이동하세요: 콘솔 > 다단계 인증 (MFA). 2. 사용자에게 지원할 인증 요소를 활성화하세요. 1. 주요 인증 요소: - - [패스키 (WebAuthn)](/end-user-flows/mfa/webauthn): 기기 생체 인증 또는 보안 키 등을 지원하는 웹 제품에 적합한 고보안 옵션으로, 강력한 보호를 보장합니다. - - [인증 앱 OTP](/end-user-flows/mfa/authenticator-app-otp): 가장 일반적이고 널리 사용되는 방법입니다. Google Authenticator 또는 Authy와 같은 인증 앱에서 생성된 시간 기반 일회용 비밀번호 (TOTP)를 사용합니다. + - [패스키 (WebAuthn)](/end-user-flows/mfa/webauthn): 웹 제품에서 디바이스 생체인식 또는 보안 키 등을 지원하는 경우에 적합한 고보안 옵션으로, 강력한 보호를 보장합니다. + - [인증 앱 OTP](/end-user-flows/mfa/authenticator-app-otp): 가장 일반적이고 널리 사용되는 방법입니다. Google Authenticator 또는 Authy와 같은 인증 앱에서 생성된 시간 기반 일회용 비밀번호(TOTP)를 사용합니다. - [SMS 인증](/end-user-flows/mfa/sms-mfa): 사용자의 등록된 휴대폰 번호로 SMS를 통해 일회용 인증 코드를 전송하는 편리한 방법으로, 별도의 앱 없이 모바일 인증을 선호하는 사용자에게 이상적입니다. - [이메일 인증](/end-user-flows/mfa/email-mfa): 사용자의 등록된 이메일 주소로 일회용 인증 코드를 전달하는 널리 접근 가능한 방법으로, 모든 플랫폼과 기기에서 사용하기 적합합니다. 2. 백업 인증 요소: - - [백업 코드](/end-user-flows/mfa/backup-codes): 사용자가 위의 주요 인증 요소로 인증할 수 없는 경우를 대비한 백업 옵션입니다. 이 옵션을 활성화하면 사용자의 접근 성공률이 높아집니다. + - [백업 코드](/end-user-flows/mfa/backup-codes): 위의 주요 인증 요소로 인증할 수 없는 경우를 대비한 백업 옵션입니다. 이 옵션을 활성화하면 사용자의 접근 성공률이 높아집니다. 3. **MFA 필수 설정(Require MFA)**을 활성화할지 선택하세요: - **활성화**: 사용자는 로그인 과정에서 MFA를 반드시 설정해야 하며, 이 과정을 건너뛸 수 없습니다. 사용자가 MFA를 설정하지 않거나 MFA 설정을 삭제하면, 다시 MFA를 설정할 때까지 계정에 접근할 수 없습니다. - - **비활성화**: 사용자는 회원가입 흐름에서 MFA 설정 과정을 건너뛸 수 있습니다. 이후 셀프 서비스 계정 설정 페이지를 통해 MFA를 설정할 수 있습니다. 사용자 계정 설정 페이지 구현에 대해 [자세히 알아보기](/end-user-flows/account-settings/). 그리고 MFA 설정 프롬프트 정책을 계속 선택하세요: + - **비활성화**: 사용자는 회원가입 과정에서 MFA 설정을 건너뛸 수 있습니다. 이후 셀프 서비스 계정 설정 페이지에서 MFA를 설정할 수 있습니다. 사용자 계정 설정 페이지 구현에 대해 [자세히 알아보기](/end-user-flows/account-settings/). 그리고 MFA 설정 프롬프트 정책을 계속 선택하세요: - **사용자에게 MFA 설정을 요청하지 않음**: 로그인 시 MFA 설정 프롬프트가 표시되지 않습니다. - - **회원가입 시 사용자에게 MFA 설정 요청**: 신규 사용자는 회원가입 시 MFA 설정 프롬프트가 표시되며, 기존 사용자는 다음 로그인 시 프롬프트를 보게 됩니다. 사용자는 이 단계를 건너뛸 수 있으며, 다시 표시되지 않습니다. - - **회원가입 후 로그인 시 사용자에게 MFA 설정 요청**: 신규 사용자는 회원가입 후 두 번째 로그인 시 MFA 설정 프롬프트가 표시되며, 기존 사용자는 다음 로그인 시 프롬프트를 보게 됩니다. 사용자는 이 단계를 건너뛸 수 있으며, 다시 표시되지 않습니다. + - **회원가입 시 사용자에게 MFA 설정 요청**: 신규 사용자는 회원가입 시 MFA 설정 프롬프트가 표시되며, 기존 사용자는 다음 로그인 시 프롬프트가 표시됩니다. 사용자는 이 단계를 건너뛸 수 있으며, 이후 다시 표시되지 않습니다. + - **회원가입 후 로그인 시 사용자에게 MFA 설정 요청**: 신규 사용자는 회원가입 후 두 번째 로그인 시 MFA 설정 프롬프트가 표시되며, 기존 사용자는 다음 로그인 시 프롬프트가 표시됩니다. 사용자는 이 단계를 건너뛸 수 있으며, 이후 다시 표시되지 않습니다. :::tip -사용자가 MFA 등록을 건너뛴 후 다시 프롬프트를 표시해야 하는 경우, 건너뛰기 상태를 재설정하여 다음 로그인 시 설정 화면이 나타나도록 하세요. 관리자는 Management API (`PATCH /api/users/{userId}/logto-configs`)를 사용할 수 있고, 셀프 서비스 흐름을 구축하는 개발자는 Account API (`PATCH /api/my-account/logto-configs`)를 호출할 수 있습니다. [Management API 참고](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Account API 참고](https://openapi.logto.io/operation/operation-updatelogtoconfig) +사용자가 MFA 등록을 건너뛴 후 다시 프롬프트를 표시하려면, 해당 사용자의 건너뛰기 상태를 초기화하여 다음 로그인 시 설정 화면이 나타나도록 하세요. 관리자는 Management API (`PATCH /api/users/{userId}/logto-configs`)를 사용할 수 있고, 셀프 서비스 플로우를 구축하는 개발자는 Account API (`PATCH /api/my-account/logto-configs`)를 호출할 수 있습니다. [Management API 참고](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Account API 참고](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: MFA 설정 ### 조직별 MFA 구성 \{#organization-level-mfa-configuration} -[조직](/organizations)을 지원하는 다중 테넌트 아키텍처 제품의 경우, 대부분 모든 사용자에게 MFA를 필수로 요구할 필요가 없습니다. 대신, 조직별로 MFA를 활성화하여 각 고객의 요구에 맞게 요구 사항을 맞춤화할 수 있습니다. 시작하려면 [조직 구성원에 대한 MFA 필수화](/organizations/organization-management#require-mfa-for-organization-members)를 참조하세요. +[조직](/organizations)을 지원하는 멀티 테넌트 아키텍처 제품의 경우, 대부분 모든 사용자에게 MFA를 필수로 요구할 필요가 없습니다. 대신, 조직별로 MFA를 활성화하여 각 고객의 요구에 맞게 요구 사항을 맞춤화할 수 있습니다. 시작하려면 [조직 구성원에게 MFA 요구하기](/organizations/organization-management#require-mfa-for-organization-members)를 참고하세요. -**다단계 인증 (MFA)** 섹션에서 **조직이 MFA를 활성화한 후 사용자에게 MFA 설정 프롬프트**를 **다음 로그인 시 MFA 설정 요청(건너뛰기 불가)**로 설정하세요. MFA가 필수인 조직의 모든 구성원은 다음 로그인 시 MFA 설정을 완료하라는 프롬프트를 받게 되며, 이 프롬프트는 건너뛸 수 없습니다. +**다단계 인증 (MFA)** 섹션에서 **조직에서 MFA를 활성화한 후 사용자를 위한 MFA 설정 프롬프트**를 **다음 로그인 시 MFA 설정 요청(건너뛰기 불가)**로 설정하세요. MFA가 필요한 조직의 구성원은 다음 로그인 시 반드시 MFA 설정을 완료해야 하며, 이 프롬프트는 건너뛸 수 없습니다. -## MFA 사용자 흐름 \{#mfa-user-flow} +## MFA 사용자 플로우 \{#mfa-user-flow} -### MFA 설정 흐름 \{#mfa-set-up-flow} +### MFA 설정 플로우 \{#mfa-set-up-flow} MFA가 활성화되면, 사용자는 로그인 및 회원가입 과정에서 MFA 설정을 요청받게 됩니다. “MFA 필수(Require MFA)” 정책이 비활성화된 경우에만 사용자가 이 설정 과정을 건너뛸 수 있습니다. 1. **로그인 또는 회원가입 페이지 방문**: 사용자가 로그인 또는 회원가입 페이지로 이동합니다. -2. **로그인 또는 회원가입 완료**: 사용자가 로그인 또는 회원가입 흐름 내에서 아이덴티티 인증 과정을 완료합니다. +2. **로그인 또는 회원가입 완료**: 사용자가 로그인 또는 회원가입 플로우 내에서 아이덴티티 인증 과정을 완료합니다. 3. **MFA 주요 인증 요소 설정**: 사용자는 주요 MFA 인증 요소(패스키, 인증 앱 OTP, SMS 코드, 이메일 코드 중 하나)를 설정하라는 프롬프트를 받습니다. - - 여러 주요 인증 요소가 활성화된 경우, 사용자는 선호하는 옵션을 선택할 수 있습니다. - - 주요 인증 요소가 회원가입 식별자와 동일한 경우(예: SMS 또는 이메일), 사전 인증되어 인증 단계를 건너뛰고 바로 다음 단계(예: "다른 2단계 인증 추가" 또는 "백업 인증 요소 저장")로 진행할 수 있습니다. + - 여러 주요 인증 요소가 활성화된 경우, 사용자는 원하는 옵션을 선택할 수 있습니다. + - 주요 인증 요소가 회원가입 식별자(SMS 또는 이메일 등)와 동일한 경우, 사전 인증되어 인증 단계를 건너뛰고 바로 다음 단계(예: "다른 2단계 인증 추가" 또는 "백업 인증 요소 저장")로 진행할 수 있습니다. - “MFA 필수(Require MFA)” 정책이 비활성화된 경우, "건너뛰기" 버튼을 선택하여 이 단계를 건너뛸 수 있습니다. -4. **MFA 백업 인증 요소 설정**: **백업 코드**가 활성화된 경우, 사용자는 주요 인증 요소 설정 후 백업 코드를 저장하라는 프롬프트를 받습니다. 자동 생성된 백업 코드는 사용자에게 표시되며, 다운로드하여 안전하게 보관할 수 있습니다. 사용자는 MFA 설정 과정을 완료하기 위해 백업 코드를 수동으로 확인해야 합니다. +4. **MFA 백업 인증 요소 설정**: **백업 코드**가 활성화된 경우, 사용자는 주요 인증 요소 설정 후 백업 코드를 저장하라는 프롬프트를 받습니다. 자동 생성된 백업 코드는 사용자에게 표시되며, 다운로드 및 안전하게 보관할 수 있습니다. 사용자는 MFA 설정을 완료하기 위해 백업 코드를 수동으로 확인해야 합니다. -MFA 설정 흐름 +MFA 설정 플로우 -### MFA 인증 흐름 \{#mfa-verification-flow} +### MFA 인증 플로우 \{#mfa-verification-flow} -MFA를 설정한 사용자는 로그인 시 구성된 MFA 인증 요소로 아이덴티티를 인증하라는 프롬프트를 받게 됩니다. 인증 요소는 Logto의 MFA 구성 및 사용자 설정에 따라 달라집니다. +MFA를 설정한 사용자는 로그인 시 구성된 MFA 인증 요소로 아이덴티티를 인증하라는 프롬프트를 받게 됩니다. 인증 요소는 Logto의 MFA 설정 및 사용자 설정에 따라 달라집니다. - 사용자가 하나의 인증 요소만 설정한 경우, 해당 요소로 바로 인증합니다. - 사용자가 2FA를 위해 여러 인증 요소를 설정한 경우, 시스템은 다음 우선순위 규칙에 따라 인증 옵션을 제시합니다: - **패스키 우선**: 사용자가 패스키를 설정한 경우, 기본 인증 방법으로 제시됩니다. - **마지막 사용 선호**: 패스키가 없는 경우, 사용자가 마지막으로 성공적으로 사용한 인증 방법이 우선시됩니다. - - **선택 목록**: 위의 우선순위가 모두 해당되지 않으면, 2단계 인증 페이지에 사용자가 연결한 모든 인증 방법이 표시되어 선택할 수 있습니다. - - 사용자는 언제든지 "다른 인증 방법 시도"를 클릭하여 다양한 인증 옵션을 전환할 수 있습니다. + - **선택 목록**: 위의 우선순위가 모두 해당되지 않으면, 2단계 인증 페이지에 사용자가 바인딩한 모든 인증 방법이 표시되어 선택할 수 있습니다. + - 사용자는 언제든지 "다른 인증 방법 시도"를 클릭하여 인증 옵션을 전환할 수 있습니다. - 활성화된 모든 주요 인증 요소를 사용할 수 없고 백업 코드가 활성화된 경우, 일회용 백업 코드를 사용하여 아이덴티티를 인증할 수 있습니다. -MFA 인증 흐름 +MFA 인증 플로우 ## MFA 관리 \{#mfa-management} -로그인/회원가입 시 초기 설정 외에도, 사용자는 셀프 서비스 계정 센터를 통해 MFA 설정을 관리할 수 있습니다. 이를 통해 사용자는 필요에 따라 MFA 인증 요소를 연결하거나 해제할 수 있습니다. +로그인/회원가입 시 최초 설정 외에도, 사용자는 셀프 서비스 계정 센터를 통해 MFA 설정을 관리할 수 있습니다. 이를 통해 사용자는 필요에 따라 MFA 인증 요소를 바인딩하거나 해제할 수 있습니다. ### 계정 센터 구축하기 \{#building-an-account-center} -Logto의 [Account API](/end-user-flows/account-settings/by-account-api)를 사용하여 포괄적인 계정 센터를 구축할 수 있습니다. 이를 통해 사용자는 다음을 할 수 있습니다: +Logto의 [Account API](/end-user-flows/account-settings/by-account-api)를 사용하여 종합적인 계정 센터를 구축할 수 있습니다. 사용자는 다음을 할 수 있습니다: -- **새 MFA 인증 요소 연결**: 추가 인증 앱, 패스키 추가 또는 백업 코드 재생성 +- **새로운 MFA 인증 요소 바인딩**: 추가 인증 앱, 패스키 추가 또는 백업 코드 재생성 - **기존 MFA 인증 요소 해제**: 더 이상 사용하지 않는 MFA 방법 제거 -- **현재 MFA 상태 보기**: 현재 구성된 MFA 인증 요소 확인 +- **현재 MFA 상태 확인**: 현재 설정된 MFA 인증 요소 확인 ### 로그인 후 MFA 설정 프롬프트 \{#post-login-mfa-setup-prompts} @@ -88,17 +88,17 @@ Logto의 [Account API](/end-user-flows/account-settings/by-account-api)를 사 - **조건부 프롬프트**: 사용자 행동 또는 계정 가치에 따라 MFA 설정 권장 메시지 표시 - **보안 대시보드**: MFA 활성화 시 보안 점수가 향상되는 대시보드 제공 -- **점진적 온보딩**: MFA 설정을 점진적 보안 강화 흐름의 일부로 제시 +- **점진적 온보딩**: MFA 설정을 점진적 보안 강화 플로우의 일부로 제시 -이러한 패턴 구현에 대해 [Account API](/end-user-flows/account-settings/by-account-api)로 자세히 알아보세요. +이러한 패턴 구현에 대해 [Account API](/end-user-flows/account-settings/by-account-api)에서 자세히 알아보세요. ### 콘솔에서 사용자 MFA 관리하기 \{#manage-users-mfa-in-console} 콘솔 > 사용자 관리에서 관리자는 사용자 MFA 설정을 효과적으로 관리할 수 있습니다: -- **사용자 MFA 상태 보기**: 각 사용자별로 활성화된 MFA 인증 요소 확인 -- **사용자 MFA 제거**: 사용자의 모든 MFA 인증 요소 삭제, 이후 MFA를 다시 설정해야 함 +- **사용자 MFA 상태 확인**: 각 사용자별로 활성화된 MFA 인증 요소 확인 +- **사용자 MFA 제거**: 사용자의 모든 MFA 인증 요소 삭제, 이후 사용자는 다시 MFA를 설정해야 함 ### 자주 묻는 질문 \{#faqs} @@ -106,17 +106,17 @@ Logto의 [Account API](/end-user-flows/account-settings/by-account-api)를 사 ### 관리자가 사용자의 기존 MFA 인증 요소를 제거하면 어떻게 되나요? \{#what-happens-when-administrators-remove-users-existing-mfa-factors} -관리자가 사용자의 모든 주요 MFA 인증 요소(패스키, 인증 앱 OTP, SMS, 이메일)를 제거하면, 사용자는 다음 로그인 시 다음과 같은 상황을 겪게 됩니다: +관리자가 사용자의 모든 주요 MFA 인증 요소(패스키, 인증 앱 OTP, SMS, 이메일)를 제거하면, 다음 로그인 시 다음과 같은 상황이 발생합니다: **상황 1: MFA 인증 요소가 남아 있지 않은 경우** -- MFA 인증 요소(백업 코드 포함)가 전혀 없고 [MFA 정책](#global-mfa-configuration)에서 MFA가 필수인 경우, 사용자는 MFA 인증 없이 로그인할 수 있으며, 즉시 MFA를 다시 설정하라는 프롬프트를 받게 됩니다. +- MFA 인증 요소(백업 코드 포함)가 전혀 없고, [MFA 정책](#global-mfa-configuration)에서 MFA가 필수인 경우, 사용자는 MFA 인증 없이 로그인할 수 있으며, 즉시 MFA를 다시 설정하라는 프롬프트가 표시됩니다. **상황 2: 백업 코드가 남아 있는 경우** - 백업 코드가 남아 있다면, 사용자는 로그인 시 먼저 백업 코드로 인증해야 합니다. - 백업 코드 인증에 성공하면, 새로운 주요 MFA 인증 요소를 설정하라는 프롬프트가 표시됩니다. -- 사용자가 이 설정을 건너뛸 수 있는지는 구성된 MFA 정책에 따라 다릅니다. -- 이 방식은 주요 인증 요소가 없을 때 사용자가 계정에서 잠기는 것을 방지합니다. +- 사용자가 이 설정을 건너뛸 수 있는지는 구성한 MFA 정책에 따라 다릅니다. +- 이 방식은 주요 인증 요소가 없을 때 사용자가 계정에 접근하지 못하는 상황을 방지합니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index 53f098e66ee..ff90ad5592c 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -42,7 +42,7 @@ ID 토큰(ID token)은 사용자 프로필 정보와 조직 관련 클레임(Cla } ``` -하지만 ID 토큰(ID token)은 인증(Authentication) 시에만 발급되며, 이후 사용자 프로필이 변경되면 정보가 오래될 수 있습니다. +하지만 ID 토큰(ID token)은 인증(Authentication) 시에만 발급되며, 이후 사용자 프로필이 변경될 경우 오래된 정보가 될 수 있습니다. 가장 최신 정보를 얻으려면 아래의 두 번째 방법을 사용하거나, `clearAllTokens()`를 호출한 후 인증(Authentication) 플로우를 다시 시작하여 새로운 ID 토큰(ID token)을 받아야 합니다. ```ts @@ -57,4 +57,10 @@ logtoClient.signIn({ ### `/oidc/me` 엔드포인트에서 사용자 정보 가져오기 \{#fetch-user-info-from-the-oidc-me-endpoint} -조직 컨텍스트에서 실시간 사용자 정보를 얻으려면 `/oidc/me`에 요청할 수도 있습니다. SDK의 `fetchUserInfo()` 메서드를 호출하세요. +조직 컨텍스트에서 실시간 사용자 정보를 얻으려면 `/oidc/me`를 요청할 수도 있습니다. SDK의 `fetchUserInfo()` 메서드를 호출하세요. + +:::tip[불투명 토큰(Opaque token) 지원] +[불투명 토큰(Opaque token)](/concepts/opaque-token) (API 리소스가 지정되지 않았을 때 발급됨)을 사용하는 경우에도 userinfo 엔드포인트를 통해 조직 멤버십 정보를 조회할 수 있습니다. `urn:logto:scope:organizations` 스코프(Scope)를 요청하면 응답에 `organizations` 및 기타 조직 관련 클레임(Claim)이 포함됩니다. + +불투명 토큰(Opaque token)은 조직별 리소스에 접근하는 조직 토큰(Organization token)으로 사용할 수 없다는 점에 유의하세요. 자세한 내용은 [불투명 토큰(Opaque token)과 조직](/concepts/opaque-token#opaque-token-and-organizations)을 참고하세요. +::: diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index 34fb89957ab..f51cbe90bd6 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/ko/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -1,77 +1,81 @@ -지원되는 스코프와 해당 클레임 (Claims) 목록은 다음과 같습니다: +다음은 지원되는 스코프와 해당 클레임(Claim)에 대한 목록입니다: **`openid`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| ----------- | -------- | -------------------- | --------------------- | -| sub | `string` | 사용자의 고유 식별자 | 아니요 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| ----------- | -------- | -------------------- | ------------------ | +| sub | `string` | 사용자의 고유 식별자 | 아니오 | **`profile`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| ----------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | -| name | `string` | 사용자의 전체 이름 | 아니요 | -| username | `string` | 사용자의 사용자 이름 | 아니요 | -| picture | `string` | 최종 사용자의 프로필 사진 URL. 이 URL은 이미지 파일 (예: PNG, JPEG, 또는 GIF 이미지 파일)을 참조해야 하며, 이미지를 포함하는 웹 페이지를 참조해서는 안 됩니다. 이 URL은 최종 사용자를 설명할 때 표시하기 적합한 프로필 사진을 구체적으로 참조해야 하며, 최종 사용자가 찍은 임의의 사진을 참조해서는 안 됩니다. | 아니요 | -| created_at | `number` | 최종 사용자가 생성된 시간. 시간은 유닉스 에포크 (1970-01-01T00:00:00Z) 이후 밀리초 수로 표현됩니다. | 아니요 | -| updated_at | `number` | 최종 사용자의 정보가 마지막으로 업데이트된 시간. 시간은 유닉스 에포크 (1970-01-01T00:00:00Z) 이후 밀리초 수로 표현됩니다. | 아니요 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| ----------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------ | +| name | `string` | 사용자의 전체 이름 | 아니오 | +| username | `string` | 사용자의 사용자명 | 아니오 | +| picture | `string` | 최종 사용자의 프로필 사진 URL. 이 URL은 이미지 파일(예: PNG, JPEG, GIF 이미지 파일)을 가리켜야 하며, 이미지를 포함한 웹 페이지가 아니어야 합니다. 이 URL은 최종 사용자를 설명할 때 표시하기에 적합한 프로필 사진을 구체적으로 참조해야 하며, 최종 사용자가 임의로 촬영한 사진이 아니어야 합니다. | 아니오 | +| created_at | `number` | 최종 사용자가 생성된 시간. 시간은 Unix epoch(1970-01-01T00:00:00Z) 이후 밀리초 단위로 표시됩니다. | 아니오 | +| updated_at | `number` | 최종 사용자의 정보가 마지막으로 업데이트된 시간. 시간은 Unix epoch(1970-01-01T00:00:00Z) 이후 밀리초 단위로 표시됩니다. | 아니오 | -다른 [표준 클레임](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)인 `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, 및 `locale`도 사용자 정보 엔드포인트를 요청할 필요 없이 `profile` 스코프에 포함됩니다. 위의 클레임과의 차이점은 이러한 클레임은 값이 비어 있지 않을 때만 반환되며, 위의 클레임은 값이 비어 있을 경우 `null`을 반환한다는 점입니다. +기타 [표준 클레임](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)에는 `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale` 등이 있으며, 이들은 userinfo 엔드포인트를 별도로 요청하지 않아도 `profile` 스코프에 포함됩니다. 위의 클레임과의 차이점은, 이러한 클레임들은 값이 비어 있지 않을 때만 반환되며, 위의 클레임들은 값이 비어 있으면 `null`을 반환한다는 점입니다. :::note -표준 클레임과 달리, `created_at` 및 `updated_at` 클레임은 초 대신 밀리초를 사용합니다. +표준 클레임과 달리, `created_at` 및 `updated_at` 클레임은 초 단위가 아닌 밀리초 단위를 사용합니다. ::: **`email`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| -------------- | --------- | ------------------------------- | --------------------- | -| email | `string` | 사용자의 이메일 주소 | 아니요 | -| email_verified | `boolean` | 이메일 주소가 검증되었는지 여부 | 아니요 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| -------------- | --------- | ------------------------------- | ------------------ | +| email | `string` | 사용자의 이메일 주소 | 아니오 | +| email_verified | `boolean` | 이메일 주소가 인증되었는지 여부 | 아니오 | **`phone`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| --------------------- | --------- | ---------------------------- | --------------------- | -| phone_number | `string` | 사용자의 전화번호 | 아니요 | -| phone_number_verified | `boolean` | 전화번호가 검증되었는지 여부 | 아니요 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| --------------------- | --------- | ---------------------------- | ------------------ | +| phone_number | `string` | 사용자의 전화번호 | 아니오 | +| phone_number_verified | `boolean` | 전화번호가 인증되었는지 여부 | 아니오 | **`address`** -주소 클레임의 세부 사항은 [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim)을 참조하세요. +주소 클레임에 대한 자세한 내용은 [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) 을 참고하세요. **`custom_data`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| ----------- | -------- | --------------------------- | --------------------- | -| custom_data | `object` | 사용자의 사용자 정의 데이터 | 예 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| ----------- | -------- | ---------------------- | ------------------ | +| custom_data | `object` | 사용자의 커스텀 데이터 | 예 | **`identities`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| -------------- | -------- | ------------------------------ | --------------------- | -| identities | `object` | 사용자의 연결된 아이덴티티 | 예 | -| sso_identities | `array` | 사용자의 연결된 SSO 아이덴티티 | 예 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| -------------- | -------- | ------------------------------ | ------------------ | +| identities | `object` | 사용자의 연결된 아이덴티티 | 예 | +| sso_identities | `array` | 사용자의 연결된 SSO 아이덴티티 | 예 | **`roles`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| ----------- | ---------- | ------------- | --------------------- | -| roles | `string[]` | 사용자의 역할 | 아니요 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| ----------- | ---------- | ------------- | ------------------ | +| roles | `string[]` | 사용자의 역할 | 아니오 | **`urn:logto:scope:organizations`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| ----------------- | ---------- | ------------------------- | --------------------- | -| organizations | `string[]` | 사용자가 속한 조직 ID | 아니요 | -| organization_data | `object[]` | 사용자가 속한 조직 데이터 | 예 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| ----------------- | ---------- | ------------------------- | ------------------ | +| organizations | `string[]` | 사용자가 속한 조직 ID | 아니오 | +| organization_data | `object[]` | 사용자가 속한 조직 데이터 | 예 | + +:::note +이러한 조직 클레임은 [불투명 토큰](/concepts/opaque-token) 사용 시에도 userinfo 엔드포인트를 통해 조회할 수 있습니다. 그러나 불투명 토큰은 조직별 리소스에 접근하는 조직 토큰으로 사용할 수 없습니다. 자세한 내용은 [불투명 토큰과 조직](/concepts/opaque-token#opaque-token-and-organizations) 을 참고하세요. +::: **`urn:logto:scope:organization_roles`** -| 클레임 이름 | 유형 | 설명 | 사용자 정보 필요 여부 | -| ------------------ | ---------- | --------------------------------------------------------------- | --------------------- | -| organization_roles | `string[]` | 사용자가 속한 조직 역할, 형식은 `:` | 아니요 | +| 클레임 이름 | 타입 | 설명 | userinfo 필요 여부 | +| ------------------ | ---------- | -------------------------------------------------------------- | ------------------ | +| organization_roles | `string[]` | 사용자가 속한 조직 역할 (`:` 형식) | 아니오 | --- -성능과 데이터 크기를 고려할 때, "사용자 정보 필요 여부"가 "예"인 경우, 해당 클레임은 ID 토큰에 나타나지 않으며, [userinfo 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 응답에서 반환됩니다. +성능 및 데이터 크기를 고려하여, "userinfo 필요 여부"가 "예"인 경우 해당 클레임은 ID 토큰에 포함되지 않고, [userinfo 엔드포인트](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 응답에서 반환됩니다. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index 60cddeb4752..b9a7429f36c 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -2,7 +2,7 @@ sidebar_position: 6 --- -# Token opaco +# Token opaco (Opaque token) Durante o processo de autenticação, se nenhum recurso for especificado, o Logto emitirá um token de acesso opaco em vez de um JWT. O token opaco é uma string aleatória e é muito mais curto que um JWT: @@ -16,22 +16,22 @@ Durante o processo de autenticação, se nenhum recurso for especificado, o Logt } ``` -O token opaco pode ser usado para chamar o [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) e acessar recursos protegidos que requerem autenticação. Como não é um JWT, como o servidor de recursos pode validá-lo? +O token opaco pode ser usado para chamar o [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) e acessar recursos protegidos que exigem autenticação. Como não é um JWT, como o servidor de recursos pode validá-lo? -O Logto fornece um [endpoint de introspecção](https://www.rfc-editor.org/rfc/rfc7662.html) que pode ser usado para validar tokens opacos. Por padrão, o endpoint de introspecção é `/oidc/token/introspection` e aceita requisições `POST`. O seguinte parâmetro é necessário: +O Logto fornece um [endpoint de introspecção](https://www.rfc-editor.org/rfc/rfc7662.html) que pode ser usado para validar tokens opacos. Por padrão, o endpoint de introspecção é `/oidc/token/introspection` e aceita requisições `POST`. O seguinte parâmetro é obrigatório: - `token`: o token opaco a ser validado -O endpoint também requer autenticação do cliente. Você pode usar um dos seguintes métodos: +O endpoint também exige autenticação do cliente. Você pode usar um dos seguintes métodos: -- Autenticação HTTP Basic: Use o cabeçalho `Authorization` com o valor `Basic `. As credenciais devem ser o client ID e o client secret separados por dois pontos (`:`) e codificados em base64. +- Autenticação HTTP Basic: Use o cabeçalho `Authorization` com o valor `Basic `. As credenciais devem ser o client ID e o client secret separados por dois-pontos (`:`) e codificados em base64. - Autenticação HTTP POST: Use os parâmetros `client_id` e `client_secret`: - `client_id`: o client ID do aplicativo que solicitou o token - `client_secret`: o client secret do aplicativo que solicitou o token -O client ID (app ID) e o client secret (app secret) podem ser as credenciais do aplicativo de qualquer aplicativo "web tradicional" ou "máquina para máquina" no Logto. O endpoint de introspecção retornará um erro se as credenciais forem inválidas. +O client ID (ID do app) e o client secret (segredo do app) podem ser as credenciais de qualquer aplicativo "web tradicional" ou "máquina para máquina" no Logto. O endpoint de introspecção retornará um erro se as credenciais forem inválidas. -O endpoint de introspecção retorna um objeto JSON com as reivindicações do token: +O endpoint de introspecção retorna um objeto JSON com as reivindicações (claims) do token: ```json { @@ -54,3 +54,14 @@ curl --location \ ``` Lembre-se de substituir `[tenant-id]` pelo seu tenant ID. + +## Token opaco (Opaque token) e organizações (Organizations) \{#opaque-token-and-organizations} + +Tokens opacos podem ser usados para recuperar informações de associação a organizações via o [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). Quando você solicita o escopo `urn:logto:scope:organizations`, o endpoint userinfo retornará as reivindicações relacionadas à organização do usuário, como `organizations` (IDs das organizações) e `organization_data`. + +No entanto, **tokens opacos não podem ser usados como tokens de organização (organization tokens)**. Tokens de organização são sempre emitidos no formato JWT porque: + +1. Tokens de organização contêm reivindicações específicas da organização (como `organization_id` e permissões com escopo) que precisam ser validadas pelos servidores de recursos. +2. O formato JWT permite que os servidores de recursos verifiquem o token e extraiam o contexto da organização sem chamadas adicionais de API. + +Para obter um token de organização, você precisa usar o [fluxo de token de atualização (refresh token flow)](/authorization/organization-permissions#refresh-token-flow) ou o [fluxo de credenciais do cliente (client credentials flow)](/authorization/organization-permissions#client-credentials-flow) com parâmetros de organização. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index 90c1d3ac82a..52379e23cf0 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -12,47 +12,47 @@ O Logto oferece opções flexíveis de configuração de MFA para atender a dife Siga estes passos para habilitar MFAs no fluxo de login dos usuários do Logto: -1. Navegue até: Console > Autenticação multifatorial (Multi-factor auth). +1. Navegue até: Console > Autenticação multifatorial (MFA). 2. Habilite os fatores de verificação suportados para seus usuários. 1. Fatores primários: - - [Chaves de acesso (Passkeys) (WebAuthn)](/end-user-flows/mfa/webauthn): Uma opção de alta segurança adequada para produtos web que suportam biometria de dispositivo ou chaves de segurança, garantindo proteção robusta. - - [OTP de aplicativo autenticador (Authenticator App OTP)](/end-user-flows/mfa/authenticator-app-otp): O método mais comum e amplamente aceito. Use uma senha única baseada em tempo (TOTP) gerada por um aplicativo autenticador como Google Authenticator ou Authy. - - [Verificação por SMS (SMS verification)](/end-user-flows/mfa/sms-mfa): Um método conveniente que envia códigos de verificação únicos via SMS para o número de telefone registrado do usuário, ideal para quem prefere autenticação baseada em celular sem aplicativos adicionais. - - [Verificação por e-mail (Email verification)](/end-user-flows/mfa/email-mfa): Um método amplamente acessível que entrega códigos de verificação únicos ao e-mail registrado do usuário, adequado para usuários em todas as plataformas e dispositivos. + - [Chaves de acesso (WebAuthn)](/end-user-flows/mfa/webauthn): Uma opção de alta segurança adequada para produtos web que suportam biometria de dispositivo ou chaves de segurança, garantindo proteção robusta. + - [OTP de aplicativo autenticador](/end-user-flows/mfa/authenticator-app-otp): O método mais comum e amplamente aceito. Use uma senha única baseada em tempo (TOTP) gerada por um aplicativo autenticador como Google Authenticator ou Authy. + - [Verificação por SMS](/end-user-flows/mfa/sms-mfa): Um método conveniente que envia códigos de verificação únicos via SMS para o número de telefone registrado do usuário, ideal para quem prefere autenticação baseada em celular sem aplicativos adicionais. + - [Verificação por email](/end-user-flows/mfa/email-mfa): Um método amplamente acessível que entrega códigos de verificação únicos ao endereço de email registrado do usuário, adequado para usuários em todas as plataformas e dispositivos. 2. Fatores de backup: - - [Códigos de backup (Backup codes)](/end-user-flows/mfa/backup-codes): Serve como opção de backup quando os usuários não conseguem verificar nenhum dos fatores primários mencionados acima. Habilitar esta opção reduz o atrito para o acesso bem-sucedido dos usuários. -3. Escolha se deseja habilitar **Exigir MFA (Require MFA)**: - - **Habilitar**: Os usuários serão solicitados a configurar o MFA durante o processo de login, o que não pode ser ignorado. Se o usuário não configurar o MFA ou excluir suas configurações de MFA, ficará bloqueado fora da conta até configurar novamente. + - [Códigos de backup](/end-user-flows/mfa/backup-codes): Serve como opção de backup quando os usuários não conseguem verificar nenhum dos fatores primários mencionados acima. Habilitar esta opção reduz o atrito para o acesso bem-sucedido dos usuários. +3. Escolha se deseja habilitar **Exigir MFA**: + - **Habilitar**: Os usuários serão solicitados a configurar o MFA durante o processo de login, o que não pode ser ignorado. Se o usuário não configurar o MFA ou excluir suas configurações de MFA, ficará bloqueado até configurar novamente. - **Desabilitar**: Os usuários podem pular o processo de configuração de MFA durante o fluxo de cadastro. Eles podem configurar o MFA posteriormente através da página de configurações de conta de autoatendimento. [Saiba mais](/end-user-flows/account-settings/) sobre como implementar uma página de configurações de conta do usuário. E continue escolhendo a política para o aviso de configuração de MFA: - - **Não pedir aos usuários para configurar MFA**: Os usuários não serão solicitados a configurar MFA durante o login. - - **Pedir aos usuários para configurar MFA durante o registro**: Novos usuários serão solicitados a configurar MFA durante o registro, e usuários existentes verão o aviso no próximo login. Os usuários podem pular esta etapa, e ela não aparecerá novamente. - - **Pedir aos usuários para configurar MFA no login após o registro**: Novos usuários serão solicitados a configurar MFA no segundo login após o registro, e usuários existentes verão o aviso no próximo login. Os usuários podem pular esta etapa, e ela não aparecerá novamente. + - **Não solicitar aos usuários que configurem MFA**: Os usuários não serão solicitados a configurar MFA durante o login. + - **Solicitar aos usuários que configurem MFA durante o cadastro**: Novos usuários serão solicitados a configurar MFA durante o cadastro, e usuários existentes verão o aviso no próximo login. Os usuários podem pular esta etapa, e ela não aparecerá novamente. + - **Solicitar aos usuários que configurem MFA no login após o cadastro**: Novos usuários serão solicitados a configurar MFA no segundo login após o cadastro, e usuários existentes verão o aviso no próximo login. Os usuários podem pular esta etapa, e ela não aparecerá novamente. :::tip -Se você precisar solicitar novamente a configuração de MFA para um usuário que pulou o cadastro, redefina o estado de pulo para que a tela de configuração apareça na próxima vez que ele fizer login. Os administradores podem usar a Management API (`PATCH /api/users/{userId}/logto-configs`), e desenvolvedores que constroem fluxos de autoatendimento podem chamar a Account API (`PATCH /api/my-account/logto-configs`). [Referência da Management API](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Referência da Account API](https://openapi.logto.io/operation/operation-updatelogtoconfig) +Se você precisar solicitar novamente a configuração de MFA para um usuário que pulou o cadastro, redefina o estado de pulo para que a tela de configuração apareça na próxima vez que ele fizer login. Os administradores podem usar a Management API (`PATCH /api/users/{userId}/logto-configs`), e desenvolvedores que constroem fluxos de autoatendimento podem chamar a Account API (`PATCH /api/my-account/logto-configs`). [Referência da Management API](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Referência da Account API](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: Configurações de MFA ### Configuração de MFA por organização \{#organization-level-mfa-configuration} -Para produtos com arquitetura multi-inquilino que suportam [Organizações (Organizations)](/organizations), na maioria dos casos não é necessário exigir MFA para todos os usuários. Em vez disso, o MFA pode ser habilitado por organização, permitindo adaptar os requisitos conforme a necessidade de cada cliente. Para começar, consulte [Exigir MFA para membros da organização](/organizations/organization-management#require-mfa-for-organization-members). +Para produtos com arquitetura multi-inquilino que suportam [Organizações](/organizations), na maioria dos casos não é necessário exigir MFA para todos os usuários. Em vez disso, o MFA pode ser habilitado por organização, permitindo adaptar os requisitos conforme a necessidade de cada cliente. Para começar, consulte [Exigir MFA para membros da organização](/organizations/organization-management#require-mfa-for-organization-members). -Na seção **Autenticação multifatorial (Multi-factor authentication)**, defina **Aviso de configuração de MFA para usuários após a organização habilitar MFA** como **Pedir aos usuários para configurar MFA no próximo login (sem pular)**. Membros de qualquer organização que exija MFA serão então solicitados a completar a configuração de MFA no próximo login, e o aviso não poderá ser ignorado. +Na seção **Autenticação multifatorial (MFA)**, defina **Aviso de configuração de MFA para usuários após a organização habilitar MFA** como **Solicitar aos usuários que configurem MFA no próximo login (sem pular)**. Membros de qualquer organização que exija MFA serão então solicitados a completar a configuração de MFA no próximo login, e o aviso não poderá ser ignorado. ## Fluxo do usuário MFA \{#mfa-user-flow} ### Fluxo de configuração de MFA \{#mfa-set-up-flow} -Uma vez que o MFA esteja habilitado, os usuários serão solicitados a configurar o MFA durante o processo de login e cadastro. Os usuários podem optar por pular esse processo de configuração se, e somente se, a política “Exigir MFA (Require MFA)” estiver desabilitada. +Uma vez que o MFA esteja habilitado, os usuários serão solicitados a configurar o MFA durante o processo de login e cadastro. Os usuários podem optar por pular esse processo de configuração se, e somente se, a política “Exigir MFA” estiver desabilitada. -1. **Acessar a página de login ou cadastro**: O usuário navega até a página de login ou cadastro. +1. **Acessar página de login ou cadastro**: O usuário navega até a página de login ou cadastro. 2. **Completar login ou cadastro**: O usuário completa o processo de verificação de identidade dentro do fluxo de login ou cadastro. -3. **Configurar fator primário de MFA**: O usuário é solicitado a configurar seu fator primário de MFA (chave de acesso, OTP de aplicativo autenticador, código SMS ou código de e-mail). - - Se vários fatores primários estiverem habilitados, o usuário pode escolher a opção preferida. - - Se o fator primário for o mesmo que o identificador de cadastro (por exemplo, SMS ou e-mail), ele será pré-verificado, permitindo que o usuário pule a etapa de verificação e prossiga diretamente para a próxima etapa (por exemplo, "Adicionar outra verificação em 2 etapas" ou "Salve seus fatores de backup"). - - Se a política “Exigir MFA” estiver desabilitada, o usuário também pode pular esta etapa selecionando o botão "Pular". -4. **Configurar fator de backup de MFA**: Se **Códigos de backup (Backup codes)** estiverem habilitados, o usuário será solicitado a salvar os códigos de backup após configurar com sucesso o fator primário de autenticação. Códigos de backup gerados automaticamente serão exibidos ao usuário, que poderá baixá-los e armazená-los com segurança. O usuário deve confirmar manualmente os códigos de backup para concluir o processo de configuração de MFA. +3. **Configurar fator primário de MFA**: O usuário é solicitado a configurar seu fator primário de MFA (chave de acesso, OTP de aplicativo autenticador, código SMS ou código de email). + - Se vários fatores primários estiverem habilitados, ele pode escolher a opção preferida. + - Se o fator primário for o mesmo que o identificador de cadastro (por exemplo, SMS ou email), ele será pré-verificado, permitindo que o usuário pule a etapa de verificação e prossiga diretamente para a próxima etapa (por exemplo, "Adicionar outra verificação em 2 etapas" ou "Salve seus fatores de backup"). + - Se a política “Exigir MFA” estiver desabilitada, ele também pode pular esta etapa selecionando o botão "Pular". +4. **Configurar fator de backup de MFA**: Se **Códigos de backup** estiverem habilitados, o usuário será solicitado a salvar os códigos de backup após configurar com sucesso o fator de autenticação primário. Códigos de backup gerados automaticamente serão exibidos ao usuário, que poderá baixá-los e armazená-los com segurança. O usuário deve confirmar manualmente os códigos de backup para concluir o processo de configuração de MFA. Fluxo de configuração de MFA @@ -60,11 +60,11 @@ Uma vez que o MFA esteja habilitado, os usuários serão solicitados a configura Usuários que configuraram MFA serão solicitados a verificar sua identidade usando os fatores de MFA configurados durante o login. O fator de verificação dependerá da configuração de MFA no Logto e das configurações do usuário. -- Se o usuário configurou apenas um fator, ele fará a verificação diretamente. +- Se o usuário configurou apenas um fator, ele o verificará diretamente. - Se o usuário configurou múltiplos fatores para 2FA, o sistema apresentará opções de verificação com base nas seguintes regras de prioridade: - - **Prioridade de chave de acesso (Passkey priority)**: Se o usuário tiver uma chave de acesso configurada, ela será apresentada como método padrão de verificação. - - **Preferência pelo último uso (Last-used preference)**: Se não houver chave de acesso disponível, o sistema priorizará o método de verificação que o usuário usou com sucesso pela última vez. - - **Lista de seleção (Selection list)**: Se nenhuma das prioridades acima se aplicar, a página de verificação em 2 etapas exibirá todos os métodos de verificação vinculados disponíveis para o usuário escolher. + - **Prioridade de chave de acesso**: Se o usuário tiver uma chave de acesso configurada, ela será apresentada como método padrão de verificação. + - **Preferência de último uso**: Se não houver chave de acesso disponível, o sistema priorizará o método de verificação que o usuário usou com sucesso pela última vez. + - **Lista de seleção**: Se nenhuma das prioridades acima se aplicar, a página de verificação em 2 etapas exibirá todos os métodos de verificação vinculados disponíveis para o usuário escolher. - Os usuários podem clicar em "Tentar outro método de verificação" para alternar entre diferentes opções de verificação a qualquer momento. - Se todos os fatores primários habilitados não estiverem disponíveis para o usuário, e o código de backup estiver habilitado, ele poderá usar o código de backup único para verificar sua identidade. @@ -72,11 +72,11 @@ Usuários que configuraram MFA serão solicitados a verificar sua identidade usa ## Gerenciamento de MFA \{#mfa-management} -Além da configuração inicial durante o login/cadastro, os usuários podem gerenciar suas configurações de MFA através de um centro de contas de autoatendimento. Isso oferece flexibilidade para os usuários vincularem ou desvincularem fatores de MFA conforme suas necessidades. +Além da configuração inicial durante o login/cadastro, os usuários podem gerenciar suas configurações de MFA por meio de um centro de conta de autoatendimento. Isso oferece flexibilidade para os usuários vincularem ou desvincularem fatores de MFA conforme suas necessidades. -### Construindo um centro de contas \{#building-an-account-center} +### Construindo um centro de conta \{#building-an-account-center} -Você pode construir um centro de contas completo usando a [Account API](/end-user-flows/account-settings/by-account-api) do Logto, que permite aos usuários: +Você pode construir um centro de conta abrangente usando a [Account API](/end-user-flows/account-settings/by-account-api) do Logto, que permite aos usuários: - **Vincular novos fatores de MFA**: Adicionar aplicativos autenticadores adicionais, chaves de acesso ou regenerar códigos de backup - **Desvincular fatores de MFA existentes**: Remover métodos de MFA que não desejam mais usar @@ -84,9 +84,9 @@ Você pode construir um centro de contas completo usando a [Account API](/end-us ### Avisos de configuração de MFA pós-login \{#post-login-mfa-setup-prompts} -Para aplicativos que não exigem MFA durante o registro inicial, você pode implementar avisos inteligentes para incentivar a configuração de MFA: +Para aplicativos que não exigem MFA durante o cadastro inicial, você pode implementar avisos inteligentes para incentivar a configuração de MFA: -- **Avisos condicionais**: Exibir recomendações de configuração de MFA com base no comportamento do usuário ou valor da conta +- **Avisos condicionais**: Mostrar recomendações de configuração de MFA com base no comportamento do usuário ou valor da conta - **Painéis de segurança**: Exibir pontuações de segurança que melhoram quando o MFA está habilitado - **Onboarding gradual**: Apresentar a configuração de MFA como parte de um fluxo progressivo de aprimoramento de segurança @@ -94,18 +94,18 @@ Saiba mais sobre como implementar esses padrões com a [Account API](/end-user-f ### Gerenciar MFA do usuário no Console \{#manage-users-mfa-in-console} -No Console > Gerenciamento de usuários (User management), administradores podem gerenciar as configurações de MFA dos usuários de forma eficaz: +No Console > Gerenciamento de usuários, administradores podem gerenciar as configurações de MFA dos usuários de forma eficaz: - **Visualizar status de MFA do usuário**: Verificar quais fatores de MFA estão habilitados para cada usuário. - **Remover MFA do usuário**: Excluir todos os fatores de MFA de um usuário, exigindo que ele configure o MFA novamente. -### Perguntas frequentes (FAQs) \{#faqs} +### Perguntas frequentes \{#faqs}
### O que acontece quando administradores removem os fatores de MFA existentes do usuário? \{#what-happens-when-administrators-remove-users-existing-mfa-factors} -Quando administradores removem todos os fatores primários de MFA de um usuário (chave de acesso, OTP de aplicativo autenticador, SMS ou e-mail), os seguintes cenários ocorrerão no próximo login do usuário: +Quando administradores removem todos os fatores primários de MFA de um usuário (chave de acesso, OTP de aplicativo autenticador, SMS ou email), os seguintes cenários ocorrerão no próximo login do usuário: **Cenário 1: Nenhum fator de MFA restante** @@ -113,9 +113,9 @@ Quando administradores removem todos os fatores primários de MFA de um usuário **Cenário 2: Códigos de backup ainda existem** -- Se os códigos de backup ainda estiverem disponíveis, o usuário deverá primeiro verificar usando um código de backup durante o login. +- Se ainda houver códigos de backup disponíveis, o usuário deverá primeiro verificar usando um código de backup durante o login. - Após a verificação bem-sucedida do código de backup, o usuário será solicitado a configurar um novo fator primário de MFA. - Se o usuário poderá pular essa configuração depende da política de MFA configurada. -- Essa abordagem impede que os usuários fiquem bloqueados fora de suas contas quando não houver fatores primários disponíveis. +- Essa abordagem evita que os usuários fiquem bloqueados em suas contas quando não houver fatores primários disponíveis.
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index e187d934dac..11331f0a9c4 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -6,7 +6,7 @@ sidebar_position: 4 ## Onde usar \{#where-to-use-it} -Isso geralmente é utilizado na página de perfil do usuário, onde é necessário exibir as informações da organização. +Isso geralmente é usado na página de perfil do usuário, onde os usuários precisam exibir suas informações de organização. Informações do usuário da organização @@ -42,8 +42,8 @@ O token de ID (ID token) é um JWT padrão que contém informações do perfil d } ``` -No entanto, o token de ID (ID token) só é emitido durante a autenticação e pode ficar desatualizado se o perfil do usuário for alterado posteriormente. -Para obter as informações mais atualizadas, utilize a segunda abordagem abaixo ou chame `clearAllTokens()` e reinicie um fluxo de autenticação para obter um novo token de ID. +No entanto, o token de ID (ID token) só é emitido durante a autenticação e pode ficar desatualizado se o perfil do usuário mudar depois disso. +Para obter as informações mais atualizadas, use a segunda abordagem abaixo ou chame `clearAllTokens()` e reinicie um fluxo de autenticação para obter um novo token de ID. ```ts await logtoClient.clearAllTokens(); @@ -57,4 +57,10 @@ Se a sessão ainda for válida, a chamada `signIn` irá redirecionar de volta pa ### Buscar informações do usuário no endpoint `/oidc/me` \{#fetch-user-info-from-the-oidc-me-endpoint} -Você também pode requisitar `/oidc/me` para obter informações do usuário em tempo real no contexto da organização. Chame o método do SDK `fetchUserInfo()`. +Você também pode requisitar `/oidc/me` para obter informações em tempo real do usuário no contexto da organização. Chame o método do SDK `fetchUserInfo()`. + +:::tip[Suporte a token opaco] +Se você estiver usando um [token opaco](/concepts/opaque-token) (emitido quando nenhum recurso de API é especificado), ainda poderá recuperar informações de associação à organização pelo endpoint userinfo. Ao solicitar o escopo `urn:logto:scope:organizations`, a resposta incluirá `organizations` e outras reivindicações relacionadas à organização. + +Observe que tokens opacos não podem ser usados como tokens de organização para acessar recursos específicos da organização. Veja [Token opaco e organizações](/concepts/opaque-token#opaque-token-and-organizations) para mais detalhes. +::: diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index c21d47190d6..1eda22d22fe 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -8,18 +8,18 @@ Aqui está a lista de escopos suportados e as reivindicações correspondentes: **`profile`** -| Nome da reivindicação | Tipo | Descrição | Precisa de userinfo? | -| --------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | -| name | `string` | O nome completo do usuário | Não | -| username | `string` | O nome de usuário do usuário | Não | -| picture | `string` | URL da foto de perfil do Usuário Final. Este URL DEVE referir-se a um arquivo de imagem (por exemplo, um arquivo de imagem PNG, JPEG ou GIF), em vez de uma página da Web contendo uma imagem. Note que este URL DEVE referir-se especificamente a uma foto de perfil do Usuário Final adequada para exibição ao descrever o Usuário Final, em vez de uma foto arbitrária tirada pelo Usuário Final. | Não | -| created_at | `number` | Hora em que o Usuário Final foi criado. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z). | Não | -| updated_at | `number` | Hora em que as informações do Usuário Final foram atualizadas pela última vez. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z). | Não | +| Nome da reivindicação | Tipo | Descrição | Precisa de userinfo? | +| --------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------- | +| name | `string` | O nome completo do usuário | Não | +| username | `string` | O nome de usuário do usuário | Não | +| picture | `string` | URL da foto de perfil do usuário final. Esta URL DEVE se referir a um arquivo de imagem (por exemplo, um arquivo de imagem PNG, JPEG ou GIF), em vez de uma página da Web contendo uma imagem. Observe que esta URL DEVE referenciar especificamente uma foto de perfil do usuário final adequada para exibição ao descrever o usuário final, em vez de uma foto arbitrária tirada pelo usuário final. | Não | +| created_at | `number` | Momento em que o usuário final foi criado. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z). | Não | +| updated_at | `number` | Momento em que as informações do usuário final foram atualizadas pela última vez. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z). | Não | -Outras [reivindicações padrão](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) incluem `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo` e `locale` também serão incluídas no escopo `profile` sem a necessidade de solicitar o endpoint userinfo. Uma diferença em relação às reivindicações acima é que essas reivindicações só serão retornadas quando seus valores não estiverem vazios, enquanto as reivindicações acima retornarão `null` se os valores estiverem vazios. +Outras [reivindicações padrão](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) incluem `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo` e `locale` também serão incluídas no escopo `profile` sem a necessidade de solicitar o endpoint userinfo. Uma diferença em relação às reivindicações acima é que essas reivindicações só serão retornadas quando seus valores não forem vazios, enquanto as reivindicações acima retornarão `null` se os valores estiverem vazios. :::note -Ao contrário das reivindicações padrão, as reivindicações `created_at` e `updated_at` estão usando milissegundos em vez de segundos. +Diferente das reivindicações padrão, as reivindicações `created_at` e `updated_at` usam milissegundos em vez de segundos. ::: **`email`** @@ -38,7 +38,7 @@ Ao contrário das reivindicações padrão, as reivindicações `created_at` e ` **`address`** -Por favor, consulte o [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) para os detalhes da reivindicação de endereço. +Consulte o [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) para detalhes da reivindicação de endereço. **`custom_data`** @@ -66,12 +66,16 @@ Por favor, consulte o [OpenID Connect Core 1.0](https://openid.net/specs/openid- | organizations | `string[]` | Os IDs das organizações às quais o usuário pertence | Não | | organization_data | `object[]` | Os dados das organizações às quais o usuário pertence | Sim | +:::note +Essas reivindicações de organização também podem ser recuperadas via endpoint userinfo ao usar um [token opaco](/concepts/opaque-token). No entanto, tokens opacos não podem ser usados como tokens de organização para acessar recursos específicos da organização. Veja [Token opaco e organizações](/concepts/opaque-token#opaque-token-and-organizations) para mais detalhes. +::: + **`urn:logto:scope:organization_roles`** -| Nome da reivindicação | Tipo | Descrição | Precisa de userinfo? | -| --------------------- | ---------- | ---------------------------------------------------------------------------------------------------- | -------------------- | -| organization_roles | `string[]` | Os papéis das organizações às quais o usuário pertence com o formato `:` | Não | +| Nome da reivindicação | Tipo | Descrição | Precisa de userinfo? | +| --------------------- | ---------- | ------------------------------------------------------------------------------------------------ | -------------------- | +| organization_roles | `string[]` | Os papéis da organização aos quais o usuário pertence no formato `:` | Não | --- -Considerando o desempenho e o tamanho dos dados, se "Precisa de userinfo?" for "Sim", isso significa que a reivindicação não aparecerá no Token de ID, mas será retornada na resposta do [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). +Considerando desempenho e o tamanho dos dados, se "Precisa de userinfo?" for "Sim", isso significa que a reivindicação não aparecerá no token de ID, mas será retornada na resposta do [endpoint userinfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). diff --git a/i18n/th/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/th/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index cc58849b173..bd966c9400d 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -4,11 +4,11 @@ sidebar_position: 6 # โทเค็นทึบ (Opaque token) -ระหว่างกระบวนการการยืนยันตัวตน (Authentication) หากไม่ได้ระบุ resource ใด Logto จะออกโทเค็นการเข้าถึงแบบทึบ (opaque access token) แทน JWT โดยโทเค็นทึบจะเป็นสตริงสุ่มและสั้นกว่า JWT มาก: +ระหว่างกระบวนการการยืนยันตัวตน (Authentication) หากไม่มีการระบุ resource Logto จะออกโทเค็นการเข้าถึงแบบทึบ (opaque access token) แทน JWT โดยโทเค็นทึบจะเป็นสตริงสุ่มและสั้นกว่า JWT มาก: ```json { - "access_token": "some-random-string", // โทเค็นทึบ + "access_token": "some-random-string", // โทเค็นทึบ (opaque token) "expires_in": 3600, "id_token": "eyJhbGc...aBc", // JWT "scope": "openid profile email", @@ -16,7 +16,7 @@ sidebar_position: 6 } ``` -โทเค็นทึบสามารถใช้เรียก [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) และเข้าถึงทรัพยากรที่ได้รับการป้องกันซึ่งต้องการการยืนยันตัวตน (Authentication) เนื่องจากมันไม่ใช่ JWT แล้ว resource server จะตรวจสอบความถูกต้องได้อย่างไร? +โทเค็นทึบสามารถใช้เรียก [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) และเข้าถึงทรัพยากรที่ต้องการการยืนยันตัวตน (Authentication) ได้ เนื่องจากมันไม่ใช่ JWT แล้ว resource server จะตรวจสอบความถูกต้องได้อย่างไร? Logto มี [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html) สำหรับตรวจสอบความถูกต้องของโทเค็นทึบ โดยค่าเริ่มต้น introspection endpoint คือ `/oidc/token/introspection` และรับ `POST` requests โดยต้องมีพารามิเตอร์ดังนี้: @@ -24,25 +24,25 @@ Logto มี [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.htm endpoint นี้ต้องการการยืนยันตัวตนของ client ด้วย คุณสามารถใช้วิธีใดวิธีหนึ่งต่อไปนี้: -- HTTP Basic authentication: ใช้ header `Authorization` ที่มีค่า `Basic ` โดย credentials ต้องเป็น client ID และ client secret คั่นด้วย colon (`:`) และเข้ารหัส base64 +- HTTP Basic authentication: ใช้ header `Authorization` ที่มีค่า `Basic ` โดย credentials คือ client ID และ client secret คั่นด้วย colon (`:`) และเข้ารหัส base64 - HTTP POST authentication: ใช้พารามิเตอร์ `client_id` และ `client_secret`: - `client_id`: client ID ของแอปที่ขอโทเค็น - `client_secret`: client secret ของแอปที่ขอโทเค็น -client ID (app ID) และ client secret (app secret) สามารถใช้ข้อมูลประจำตัวของแอปจากแอป "traditional web" หรือ "machine-to-machine" ใด ๆ ใน Logto ก็ได้ หาก credentials ไม่ถูกต้อง introspection endpoint จะส่ง error กลับมา +client ID (app ID) และ client secret (app secret) สามารถใช้ข้อมูลรับรองของแอปประเภท "traditional web" หรือ "machine-to-machine" ใด ๆ ใน Logto ได้ หาก credentials ไม่ถูกต้อง introspection endpoint จะส่ง error กลับ -introspection endpoint จะส่งคืนอ็อบเจกต์ JSON ที่มีการอ้างสิทธิ์ (claims) ของโทเค็น: +introspection endpoint จะคืนค่าเป็นอ็อบเจกต์ JSON ที่มีการอ้างสิทธิ์ (claims) ของโทเค็น: ```json { - "active": true, // โทเค็นนี้ใช้ได้หรือไม่ + "active": true, // โทเค็นนี้ถูกต้องหรือไม่ "sub": "1234567890" // ผู้ถูกอ้างถึง (subject) ของโทเค็น (user ID) } ``` หากโทเค็นไม่ถูกต้อง ฟิลด์ `active` จะเป็น `false` และจะไม่มีฟิลด์ `sub` -ตัวอย่างที่ไม่เป็นทางการของ introspection request: +ตัวอย่างคำขอ introspection (ตัวอย่างที่ไม่เป็นมาตรฐาน): ```bash curl --location \ @@ -54,3 +54,14 @@ curl --location \ ``` อย่าลืมแทนที่ `[tenant-id]` ด้วย tenant ID ของคุณ + +## โทเค็นทึบกับองค์กร \{#opaque-token-and-organizations} + +โทเค็นทึบสามารถใช้ดึงข้อมูลสมาชิกองค์กรผ่าน [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) ได้ เมื่อคุณร้องขอ scope `urn:logto:scope:organizations` userinfo endpoint จะคืนค่าการอ้างสิทธิ์ (claims) ที่เกี่ยวข้องกับองค์กรของผู้ใช้ เช่น `organizations` (organization IDs) และ `organization_data` + +อย่างไรก็ตาม **โทเค็นทึบไม่สามารถใช้เป็นโทเค็นองค์กร (organization token) ได้** โทเค็นองค์กรจะออกในรูปแบบ JWT เสมอ เพราะว่า: + +1. โทเค็นองค์กรมีการอ้างสิทธิ์เฉพาะองค์กร (เช่น `organization_id` และสิทธิ์แบบ scoped) ที่ resource server ต้องตรวจสอบ +2. รูปแบบ JWT ช่วยให้ resource server ตรวจสอบโทเค็นและดึง context ขององค์กรได้โดยไม่ต้องเรียก API เพิ่มเติม + +หากต้องการรับโทเค็นองค์กร คุณต้องใช้ [refresh token flow](/authorization/organization-permissions#refresh-token-flow) หรือ [client credentials flow](/authorization/organization-permissions#client-credentials-flow) พร้อมพารามิเตอร์ขององค์กร diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index 54dff7e7d30..89a9202010e 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -15,28 +15,28 @@ Logto มีตัวเลือกการตั้งค่า MFA ที่ 1. ไปที่: Console > Multi-factor auth 2. เปิดใช้งานปัจจัยการยืนยันตัวตนที่รองรับสำหรับผู้ใช้ของคุณ 1. ปัจจัยหลัก: - - [Passkeys (WebAuthn)](/end-user-flows/mfa/webauthn): ตัวเลือกความปลอดภัยสูง เหมาะสำหรับผลิตภัณฑ์เว็บที่รองรับไบโอเมตริกซ์ของอุปกรณ์หรือคีย์ความปลอดภัย ฯลฯ เพื่อการปกป้องที่แข็งแกร่ง - - [Authenticator App OTP](/end-user-flows/mfa/authenticator-app-otp): วิธีที่พบได้บ่อยและได้รับการยอมรับมากที่สุด ใช้รหัสผ่านแบบใช้ครั้งเดียวตามเวลา (TOTP) ที่สร้างโดยแอปยืนยันตัวตน เช่น Google Authenticator หรือ Authy - - [การยืนยัน SMS](/end-user-flows/mfa/sms-mfa): วิธีที่สะดวก ส่งรหัสยืนยันแบบใช้ครั้งเดียวผ่าน SMS ไปยังหมายเลขโทรศัพท์ที่ลงทะเบียน เหมาะสำหรับผู้ใช้ที่ต้องการยืนยันตัวตนผ่านมือถือโดยไม่ต้องใช้แอปเพิ่มเติม - - [การยืนยันอีเมล](/end-user-flows/mfa/email-mfa): วิธีที่เข้าถึงได้ง่าย ส่งรหัสยืนยันแบบใช้ครั้งเดียวไปยังอีเมลที่ลงทะเบียน เหมาะกับผู้ใช้ทุกแพลตฟอร์มและอุปกรณ์ + - [Passkeys (WebAuthn)](/end-user-flows/mfa/webauthn): ตัวเลือกความปลอดภัยสูง เหมาะสำหรับผลิตภัณฑ์เว็บที่รองรับไบโอเมตริกซ์ของอุปกรณ์หรือกุญแจความปลอดภัย ฯลฯ เพื่อการปกป้องที่แข็งแกร่ง + - [Authenticator App OTP](/end-user-flows/mfa/authenticator-app-otp): วิธีที่พบได้บ่อยและได้รับการยอมรับอย่างกว้างขวาง ใช้รหัสผ่านแบบใช้ครั้งเดียวตามเวลา (TOTP) ที่สร้างโดยแอป Authenticator เช่น Google Authenticator หรือ Authy + - [SMS verification](/end-user-flows/mfa/sms-mfa): วิธีที่สะดวก ส่งรหัสยืนยันแบบใช้ครั้งเดียวผ่าน SMS ไปยังหมายเลขโทรศัพท์ที่ลงทะเบียน เหมาะสำหรับผู้ใช้ที่ต้องการยืนยันตัวตนผ่านมือถือโดยไม่ต้องติดตั้งแอปเพิ่ม + - [Email verification](/end-user-flows/mfa/email-mfa): วิธีที่เข้าถึงได้ง่าย ส่งรหัสยืนยันแบบใช้ครั้งเดียวไปยังอีเมลที่ลงทะเบียน เหมาะสำหรับผู้ใช้ทุกแพลตฟอร์มและอุปกรณ์ 2. ปัจจัยสำรอง: - - [รหัสสำรอง](/end-user-flows/mfa/backup-codes): ใช้เป็นตัวเลือกสำรองเมื่อผู้ใช้ไม่สามารถยืนยันตัวตนด้วยปัจจัยหลักข้างต้น การเปิดใช้งานนี้ช่วยลดอุปสรรคในการเข้าถึงของผู้ใช้ + - [Backup codes](/end-user-flows/mfa/backup-codes): ใช้เป็นตัวเลือกสำรองเมื่อผู้ใช้ไม่สามารถยืนยันตัวตนด้วยปัจจัยหลักข้างต้น การเปิดใช้งานนี้ช่วยลดอุปสรรคในการเข้าถึงของผู้ใช้ 3. เลือกว่าต้องการเปิดใช้งาน **Require MFA** หรือไม่: - **Enable**: ผู้ใช้จะถูกบังคับให้ตั้งค่า MFA ระหว่างขั้นตอนการลงชื่อเข้าใช้และไม่สามารถข้ามได้ หากผู้ใช้ไม่ตั้งค่า MFA หรือทำการลบการตั้งค่า MFA จะไม่สามารถเข้าบัญชีได้จนกว่าจะตั้งค่า MFA ใหม่ - - **Disable**: ผู้ใช้สามารถข้ามขั้นตอนการตั้งค่า MFA ระหว่างการลงทะเบียนได้ และสามารถตั้งค่า MFA ภายหลังผ่านหน้าตั้งค่าบัญชีด้วยตนเอง [เรียนรู้เพิ่มเติม](/end-user-flows/account-settings/) เกี่ยวกับการสร้างหน้าตั้งค่าบัญชีผู้ใช้ และเลือกนโยบายสำหรับการแจ้งเตือนการตั้งค่า MFA ต่อไปนี้: + - **Disable**: ผู้ใช้สามารถข้ามขั้นตอนการตั้งค่า MFA ระหว่างการสมัครใช้งานได้ และสามารถตั้งค่า MFA ภายหลังผ่านหน้าตั้งค่าบัญชีด้วยตนเอง [เรียนรู้เพิ่มเติม](/end-user-flows/account-settings/) เกี่ยวกับการสร้างหน้าตั้งค่าบัญชีผู้ใช้ และเลือกนโยบายสำหรับการแจ้งเตือนการตั้งค่า MFA ต่อไปนี้: - **Do not ask users to set up MFA**: จะไม่มีการแจ้งเตือนให้ผู้ใช้ตั้งค่า MFA ระหว่างการลงชื่อเข้าใช้ - - **Ask users to set up MFA during registration**: ผู้ใช้ใหม่จะถูกแจ้งให้ตั้งค่า MFA ระหว่างการลงทะเบียน และผู้ใช้เดิมจะเห็นแจ้งเตือนนี้ในการลงชื่อเข้าใช้ครั้งถัดไป ผู้ใช้สามารถข้ามขั้นตอนนี้ได้ และจะไม่ถูกแจ้งเตือนอีก - - **Ask users to set up MFA on their sign-in after registration**: ผู้ใช้ใหม่จะถูกแจ้งให้ตั้งค่า MFA ในการลงชื่อเข้าใช้ครั้งที่สองหลังจากลงทะเบียน และผู้ใช้เดิมจะเห็นแจ้งเตือนนี้ในการลงชื่อเข้าใช้ครั้งถัดไป ผู้ใช้สามารถข้ามขั้นตอนนี้ได้ และจะไม่ถูกแจ้งเตือนอีก + - **Ask users to set up MFA during registration**: ผู้ใช้ใหม่จะถูกแจ้งให้ตั้งค่า MFA ระหว่างการสมัคร ส่วนผู้ใช้เดิมจะเห็นแจ้งเตือนนี้ในการลงชื่อเข้าใช้ครั้งถัดไป ผู้ใช้สามารถข้ามขั้นตอนนี้ได้ และจะไม่ถูกแจ้งเตือนอีก + - **Ask users to set up MFA on their sign-in after registration**: ผู้ใช้ใหม่จะถูกแจ้งให้ตั้งค่า MFA ในการลงชื่อเข้าใช้ครั้งที่สองหลังจากสมัคร ส่วนผู้ใช้เดิมจะเห็นแจ้งเตือนนี้ในการลงชื่อเข้าใช้ครั้งถัดไป ผู้ใช้สามารถข้ามขั้นตอนนี้ได้ และจะไม่ถูกแจ้งเตือนอีก :::tip -หากคุณต้องการแจ้งเตือนผู้ใช้อีกครั้งหลังจากที่ข้ามการลงทะเบียน MFA ให้รีเซ็ตสถานะการข้ามของพวกเขาเพื่อให้หน้าตั้งค่าปรากฏในการลงชื่อเข้าใช้ครั้งถัดไป ผู้ดูแลระบบสามารถใช้ Management API (`PATCH /api/users/{userId}/logto-configs`) และนักพัฒนาที่สร้าง flow แบบ self-service สามารถเรียก Account API (`PATCH /api/my-account/logto-configs`) [Management API reference](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Account API reference](https://openapi.logto.io/operation/operation-updatelogtoconfig) +หากคุณต้องการแจ้งเตือนผู้ใช้อีกครั้งหลังจากที่พวกเขาข้ามการลงทะเบียน MFA ให้รีเซ็ตสถานะการข้ามของพวกเขาเพื่อให้หน้าตั้งค่าปรากฏขึ้นในการลงชื่อเข้าใช้ครั้งถัดไป ผู้ดูแลระบบสามารถใช้ Management API (`PATCH /api/users/{userId}/logto-configs`) และนักพัฒนาที่สร้าง flow แบบบริการตนเองสามารถเรียก Account API (`PATCH /api/my-account/logto-configs`) [Management API reference](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Account API reference](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: การตั้งค่า MFA ### การตั้งค่า MFA ระดับองค์กร \{#organization-level-mfa-configuration} -สำหรับผลิตภัณฑ์ที่มีสถาปัตยกรรมแบบหลายผู้เช่า (multi-tenant) และรองรับ [องค์กร](/organizations) โดยส่วนใหญ่คุณไม่จำเป็นต้องบังคับใช้ MFA กับผู้ใช้ทุกคน แต่สามารถเปิดใช้งาน MFA เป็นรายองค์กร เพื่อปรับแต่งตามความต้องการของลูกค้าแต่ละรายได้ ดูวิธีเริ่มต้นที่ [บังคับใช้ MFA สำหรับสมาชิกองค์กร](/organizations/organization-management#require-mfa-for-organization-members) +สำหรับผลิตภัณฑ์ที่มีสถาปัตยกรรมหลายผู้เช่า (multi-tenant) และรองรับ [องค์กร (Organizations)](/organizations) โดยส่วนใหญ่คุณไม่จำเป็นต้องบังคับใช้ MFA กับผู้ใช้ทุกคน แต่สามารถเปิดใช้งาน MFA เป็นรายองค์กร เพื่อปรับแต่งตามความต้องการของลูกค้าแต่ละรายได้ ดูวิธีเริ่มต้นที่ [การบังคับใช้ MFA สำหรับสมาชิกองค์กร](/organizations/organization-management#require-mfa-for-organization-members) ในส่วน **Multi-factor authentication** ให้ตั้งค่า **MFA setup prompt for users after organization enables MFA** เป็น **Ask users to set up MFA on next sign-in (no skipping)** สมาชิกขององค์กรที่บังคับใช้ MFA จะถูกแจ้งให้ตั้งค่า MFA ในการลงชื่อเข้าใช้ครั้งถัดไป และไม่สามารถข้ามได้ @@ -44,15 +44,15 @@ Logto มีตัวเลือกการตั้งค่า MFA ที่ ### กระบวนการตั้งค่า MFA \{#mfa-set-up-flow} -เมื่อเปิดใช้งาน MFA แล้ว ผู้ใช้จะถูกแจ้งให้ตั้งค่า MFA ระหว่างขั้นตอนการลงชื่อเข้าใช้และลงทะเบียน ผู้ใช้สามารถเลือกข้ามขั้นตอนนี้ได้ **เฉพาะเมื่อ** นโยบาย “Require MFA” ถูกปิดใช้งาน +เมื่อเปิดใช้งาน MFA แล้ว ผู้ใช้จะถูกแจ้งให้ตั้งค่า MFA ระหว่างขั้นตอนการลงชื่อเข้าใช้และสมัครใช้งาน ผู้ใช้สามารถเลือกข้ามขั้นตอนนี้ได้ เฉพาะเมื่อปิดนโยบาย “Require MFA” เท่านั้น -1. **เข้าสู่หน้าลงชื่อเข้าใช้หรือสมัครสมาชิก**: ผู้ใช้ไปที่หน้าลงชื่อเข้าใช้หรือสมัครสมาชิก -2. **ดำเนินการลงชื่อเข้าใช้หรือสมัครสมาชิกให้เสร็จสิ้น**: ผู้ใช้ดำเนินการยืนยันตัวตนใน flow การลงชื่อเข้าใช้หรือสมัครสมาชิก +1. **เข้าสู่หน้าลงชื่อเข้าใช้หรือสมัครใช้งาน**: ผู้ใช้ไปยังหน้าลงชื่อเข้าใช้หรือสมัครใช้งาน +2. **ดำเนินการลงชื่อเข้าใช้หรือสมัครใช้งานให้เสร็จสิ้น**: ผู้ใช้ดำเนินการยืนยันตัวตนใน flow การลงชื่อเข้าใช้หรือสมัครใช้งาน 3. **ตั้งค่าปัจจัยหลักของ MFA**: ผู้ใช้จะถูกแจ้งให้ตั้งค่าปัจจัยหลักของ MFA (เช่น passkey, Authenticator app OTP, รหัส SMS หรือรหัสอีเมล) - - หากเปิดใช้งานปัจจัยหลักหลายอย่าง ผู้ใช้สามารถเลือกตัวเลือกที่ต้องการได้ - - หากปัจจัยหลักตรงกับตัวระบุที่ใช้สมัคร (เช่น SMS หรืออีเมล) จะได้รับการยืนยันล่วงหน้า ผู้ใช้สามารถข้ามขั้นตอนการยืนยันและไปยังขั้นตอนถัดไปได้ทันที (เช่น “เพิ่มการยืนยันสองขั้นตอนอื่น” หรือ “บันทึกรหัสสำรอง”) - - หากนโยบาย “Require MFA” ถูกปิดใช้งาน ผู้ใช้สามารถข้ามขั้นตอนนี้ได้โดยกดปุ่ม "ข้าม" -4. **ตั้งค่าปัจจัยสำรองของ MFA**: หากเปิดใช้งาน **รหัสสำรอง** ผู้ใช้จะถูกแจ้งให้บันทึกรหัสสำรองหลังจากตั้งค่าปัจจัยหลักสำเร็จ ระบบจะแสดงรหัสสำรองที่สร้างอัตโนมัติให้ผู้ใช้ดาวน์โหลดและเก็บไว้อย่างปลอดภัย ผู้ใช้ต้องยืนยันรหัสสำรองด้วยตนเองเพื่อให้การตั้งค่า MFA เสร็จสมบูรณ์ + - หากเปิดใช้งานปัจจัยหลักหลายแบบ ผู้ใช้สามารถเลือกวิธีที่ต้องการได้ + - หากปัจจัยหลักตรงกับตัวระบุที่ใช้สมัคร (เช่น SMS หรืออีเมล) จะได้รับการยืนยันล่วงหน้า ผู้ใช้สามารถข้ามขั้นตอนยืนยันและไปยังขั้นตอนถัดไปได้ทันที (เช่น “เพิ่มการยืนยัน 2 ขั้นตอนอื่น” หรือ “บันทึกปัจจัยสำรองของคุณ”) + - หากปิดนโยบาย “Require MFA” ผู้ใช้สามารถข้ามขั้นตอนนี้ได้โดยกดปุ่ม "ข้าม" +4. **ตั้งค่าปัจจัยสำรองของ MFA**: หากเปิดใช้งาน **Backup codes** ผู้ใช้จะถูกแจ้งให้บันทึกรหัสสำรองหลังจากตั้งค่าปัจจัยหลักสำเร็จ ระบบจะแสดงรหัสสำรองที่สร้างอัตโนมัติให้ผู้ใช้ดาวน์โหลดและเก็บไว้อย่างปลอดภัย ผู้ใช้ต้องยืนยันรหัสสำรองด้วยตนเองเพื่อให้การตั้งค่า MFA เสร็จสมบูรณ์ กระบวนการตั้งค่า MFA @@ -60,31 +60,31 @@ Logto มีตัวเลือกการตั้งค่า MFA ที่ ผู้ใช้ที่ตั้งค่า MFA แล้วจะถูกแจ้งให้ยืนยันตัวตนด้วยปัจจัย MFA ที่ตั้งค่าไว้ระหว่างการลงชื่อเข้าใช้ ปัจจัยที่ใช้ยืนยันขึ้นอยู่กับการตั้งค่า MFA ใน Logto และการตั้งค่าของผู้ใช้ -- หากผู้ใช้ตั้งค่าเพียงปัจจัยเดียว จะต้องยืนยันปัจจัยนั้นโดยตรง -- หากผู้ใช้ตั้งค่าหลายปัจจัยสำหรับ 2FA ระบบจะนำเสนอทางเลือกการยืนยันตามลำดับความสำคัญดังนี้: +- หากผู้ใช้ตั้งค่าเพียงปัจจัยเดียว จะต้องยืนยันด้วยวิธีนั้นโดยตรง +- หากผู้ใช้ตั้งค่าหลายปัจจัยสำหรับ 2FA ระบบจะนำเสนอทางเลือกตามลำดับความสำคัญดังนี้: - **Passkey priority**: หากผู้ใช้ตั้งค่า passkey จะถูกนำเสนอเป็นวิธีเริ่มต้น - **Last-used preference**: หากไม่มี passkey ระบบจะเลือกวิธีที่ผู้ใช้ใช้สำเร็จล่าสุด - - **Selection list**: หากไม่มีลำดับความสำคัญข้างต้น หน้า 2-step verification จะแสดงวิธีการยืนยันทั้งหมดที่ผู้ใช้ผูกไว้ให้เลือก - - ผู้ใช้สามารถคลิก "ลองวิธีอื่นเพื่อยืนยัน" เพื่อสลับวิธีการยืนยันได้ตลอดเวลา + - **Selection list**: หากไม่มีลำดับความสำคัญข้างต้น หน้า 2-step verification จะแสดงวิธีที่ผูกไว้ทั้งหมดให้ผู้ใช้เลือก + - ผู้ใช้สามารถคลิก "ลองวิธีอื่นในการยืนยัน" เพื่อสลับวิธีได้ตลอดเวลา - หากไม่มีปัจจัยหลักที่เปิดใช้งานใด ๆ ให้ผู้ใช้ และเปิดใช้งานรหัสสำรอง ผู้ใช้สามารถใช้รหัสสำรองแบบใช้ครั้งเดียวเพื่อยืนยันตัวตนได้ กระบวนการยืนยัน MFA ## การจัดการ MFA \{#mfa-management} -นอกเหนือจากการตั้งค่าเริ่มต้นระหว่างการลงชื่อเข้าใช้ / สมัครสมาชิก ผู้ใช้สามารถจัดการการตั้งค่า MFA ได้ด้วยตนเองผ่านศูนย์บัญชี (account center) เพื่อความยืดหยุ่นในการผูกหรือยกเลิกผูกปัจจัย MFA ตามต้องการ +นอกเหนือจากการตั้งค่าเบื้องต้นระหว่างการลงชื่อเข้าใช้ / สมัครใช้งาน ผู้ใช้สามารถจัดการการตั้งค่า MFA ได้ด้วยตนเองผ่านศูนย์บัญชี (account center) เพื่อความยืดหยุ่นในการผูกหรือยกเลิกการผูกปัจจัย MFA ตามต้องการ -### การสร้างศูนย์บัญชี \{#building-an-account-center} +### สร้างศูนย์บัญชี (Account Center) \{#building-an-account-center} -คุณสามารถสร้างศูนย์บัญชีที่ครบถ้วนโดยใช้ [Account API](/end-user-flows/account-settings/by-account-api) ของ Logto ซึ่งช่วยให้ผู้ใช้สามารถ: +คุณสามารถสร้างศูนย์บัญชีที่สมบูรณ์โดยใช้ [Account API](/end-user-flows/account-settings/by-account-api) ของ Logto ซึ่งช่วยให้ผู้ใช้สามารถ: -- **ผูกปัจจัย MFA ใหม่**: เพิ่มแอปยืนยันตัวตน, passkey หรือสร้างรหัสสำรองใหม่ -- **ยกเลิกผูกปัจจัย MFA เดิม**: ลบวิธี MFA ที่ไม่ต้องการใช้งาน -- **ดูสถานะ MFA ปัจจุบัน**: ตรวจสอบว่ามีการตั้งค่าปัจจัย MFA ใดบ้าง +- **ผูกปัจจัย MFA ใหม่**: เพิ่มแอป Authenticator, passkey หรือสร้างรหัสสำรองใหม่ +- **ยกเลิกการผูกปัจจัย MFA ที่มีอยู่**: ลบวิธี MFA ที่ไม่ต้องการใช้งาน +- **ดูสถานะ MFA ปัจจุบัน**: ตรวจสอบว่าตั้งค่าปัจจัย MFA ใดไว้บ้าง ### การแจ้งเตือนการตั้งค่า MFA หลังเข้าสู่ระบบ \{#post-login-mfa-setup-prompts} -สำหรับแอปที่ไม่บังคับใช้ MFA ระหว่างการลงทะเบียนครั้งแรก คุณสามารถสร้างการแจ้งเตือนอัจฉริยะเพื่อกระตุ้นให้ผู้ใช้ตั้งค่า MFA ได้ เช่น +สำหรับแอปที่ไม่บังคับใช้ MFA ระหว่างการสมัครใช้งานครั้งแรก คุณสามารถสร้างการแจ้งเตือนอัจฉริยะเพื่อกระตุ้นให้ผู้ใช้ตั้งค่า MFA ได้ เช่น - **Conditional prompts**: แนะนำการตั้งค่า MFA ตามพฤติกรรมหรือมูลค่าบัญชีของผู้ใช้ - **Security dashboards**: แสดงคะแนนความปลอดภัยที่เพิ่มขึ้นเมื่อเปิดใช้งาน MFA @@ -96,7 +96,7 @@ Logto มีตัวเลือกการตั้งค่า MFA ที่ ใน Console > User management ผู้ดูแลระบบสามารถจัดการการตั้งค่า MFA ของผู้ใช้ได้อย่างมีประสิทธิภาพ: -- **ดูสถานะ MFA ของผู้ใช้**: ตรวจสอบว่าผู้ใช้แต่ละรายเปิดใช้งานปัจจัย MFA ใดบ้าง +- **ดูสถานะ MFA ของผู้ใช้**: ตรวจสอบว่าผู้ใช้แต่ละคนเปิดใช้งานปัจจัย MFA ใดบ้าง - **ลบ MFA ของผู้ใช้**: ลบปัจจัย MFA ทั้งหมดของผู้ใช้ ทำให้ต้องตั้งค่า MFA ใหม่ ### คำถามที่พบบ่อย \{#faqs} @@ -113,7 +113,7 @@ Logto มีตัวเลือกการตั้งค่า MFA ที่ **สถานการณ์ที่ 2: ยังมีรหัสสำรองเหลืออยู่** -- หากยังมีรหัสสำรอง ผู้ใช้ต้องยืนยันตัวตนด้วยรหัสสำรองก่อนในขั้นตอนลงชื่อเข้าใช้ +- หากยังมีรหัสสำรอง ผู้ใช้ต้องยืนยันตัวตนด้วยรหัสสำรองก่อนระหว่างการลงชื่อเข้าใช้ - หลังจากยืนยันรหัสสำรองสำเร็จ ผู้ใช้จะถูกแจ้งให้ตั้งค่าปัจจัย MFA หลักใหม่ - ผู้ใช้จะสามารถข้ามขั้นตอนนี้ได้หรือไม่ขึ้นอยู่กับนโยบาย MFA ที่คุณตั้งค่าไว้ - วิธีนี้ช่วยป้องกันไม่ให้ผู้ใช้ถูกล็อกบัญชีเมื่อไม่มีปัจจัยหลักเหลืออยู่ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index 81fc9755887..83a045d2a44 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -6,7 +6,7 @@ sidebar_position: 4 ## ใช้งานเมื่อใด \{#where-to-use-it} -โดยปกติจะใช้ในหน้าข้อมูลโปรไฟล์ผู้ใช้ ซึ่งผู้ใช้ต้องการแสดงข้อมูลขององค์กรที่ตนเองสังกัด +โดยปกติจะใช้ในหน้าข้อมูลโปรไฟล์ผู้ใช้ที่ต้องแสดงข้อมูลขององค์กรที่ผู้ใช้สังกัด ข้อมูลผู้ใช้ในองค์กร @@ -16,7 +16,7 @@ sidebar_position: 4 ### ถอดรหัสโทเค็น ID (Decode the ID token) \{#decode-the-id-token} -โทเค็น ID (ID token) เป็น JWT มาตรฐานที่มีข้อมูลโปรไฟล์ผู้ใช้และการอ้างสิทธิ์ (claims) ที่เกี่ยวข้องกับองค์กร เรียกใช้เมธอด SDK `decodeIdToken()` เพื่อรับอ็อบเจกต์ JSON ดังนี้: +โทเค็น ID (ID token) เป็น JWT มาตรฐานที่มีข้อมูลโปรไฟล์ผู้ใช้และการอ้างสิทธิ์ (claims) ที่เกี่ยวข้องกับองค์กร เรียกใช้เมธอด SDK `decodeIdToken()` เพื่อรับอ็อบเจกต์ JSON เช่นนี้: ```json { @@ -42,7 +42,7 @@ sidebar_position: 4 } ``` -อย่างไรก็ตาม โทเค็น ID จะถูกออกให้เฉพาะระหว่างการยืนยันตัวตนเท่านั้น และอาจล้าสมัยหากโปรไฟล์ผู้ใช้มีการเปลี่ยนแปลงในภายหลัง +อย่างไรก็ตาม โทเค็น ID จะถูกออกให้เฉพาะระหว่างการยืนยันตัวตน (Authentication) เท่านั้น และอาจล้าสมัยหากโปรไฟล์ผู้ใช้มีการเปลี่ยนแปลงในภายหลัง หากต้องการข้อมูลล่าสุดที่สุด ให้ใช้วิธีที่สองด้านล่าง หรือเรียก `clearAllTokens()` และเริ่มกระบวนการยืนยันตัวตนใหม่เพื่อรับโทเค็น ID ที่สดใหม่ ```ts @@ -53,8 +53,14 @@ logtoClient.signIn({ }); ``` -หากเซสชันยังคงใช้งานได้ การเรียก `signIn` จะเปลี่ยนเส้นทางกลับไปยังแอปของคุณโดยไม่ต้องกรอกข้อมูลรับรองใหม่ สำหรับผู้ใช้แล้ว แอปจะรีเฟรชและมีการออกโทเค็น ID ใหม่โดยอัตโนมัติ +หากเซสชันยังคงใช้ได้ การเรียก `signIn` จะเปลี่ยนเส้นทางกลับไปยังแอปของคุณโดยไม่ต้องกรอกข้อมูลรับรองใหม่ สำหรับผู้ใช้แล้ว แอปจะรีเฟรชและมีการออกโทเค็น ID ใหม่โดยอัตโนมัติ ### ดึงข้อมูลผู้ใช้จาก endpoint `/oidc/me` \{#fetch-user-info-from-the-oidc-me-endpoint} คุณยังสามารถร้องขอ `/oidc/me` เพื่อรับข้อมูลผู้ใช้แบบเรียลไทม์ในบริบทขององค์กรได้ เรียกใช้เมธอด SDK `fetchUserInfo()` + +:::tip[รองรับโทเค็นทึบ (Opaque token)] +หากคุณใช้ [โทเค็นทึบ (Opaque token)](/concepts/opaque-token) (ออกให้เมื่อไม่ได้ระบุทรัพยากร API) คุณยังสามารถดึงข้อมูลสมาชิกองค์กรผ่าน userinfo endpoint ได้ เมื่อคุณร้องขอขอบเขต `urn:logto:scope:organizations` การตอบกลับจะมี `organizations` และการอ้างสิทธิ์ที่เกี่ยวข้องกับองค์กรอื่น ๆ + +โปรดทราบว่าโทเค็นทึบไม่สามารถใช้เป็นโทเค็นองค์กรสำหรับเข้าถึงทรัพยากรเฉพาะองค์กรได้ ดู [โทเค็นทึบและองค์กร](/concepts/opaque-token#opaque-token-and-organizations) สำหรับรายละเอียดเพิ่มเติม +::: diff --git a/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index f8ff1013f39..73c0f8b9fd4 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/th/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -1,40 +1,40 @@ -ต่อไปนี้คือรายการขอบเขต (Scopes) ที่รองรับและการอ้างสิทธิ์ (Claims) ที่เกี่ยวข้อง: +นี่คือรายการขอบเขต (scopes) ที่รองรับและการอ้างสิทธิ์ (claims) ที่เกี่ยวข้อง: **`openid`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ----------------- | -------- | ------------------------- | ------------------------- | -| sub | `string` | ตัวระบุที่ไม่ซ้ำของผู้ใช้ | ไม่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ----------------- | -------- | ------------------------- | ----------------- | +| sub | `string` | ตัวระบุที่ไม่ซ้ำของผู้ใช้ | ไม่ | **`profile`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ----------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------- | -| name | `string` | ชื่อเต็มของผู้ใช้ | ไม่ | -| username | `string` | ชื่อผู้ใช้ของผู้ใช้ | ไม่ | -| picture | `string` | URL ของรูปโปรไฟล์ของผู้ใช้ปลายทาง URL นี้ **ต้อง** อ้างอิงถึงไฟล์รูปภาพ (เช่น ไฟล์ PNG, JPEG หรือ GIF) ไม่ใช่หน้าเว็บที่มีรูปภาพ โปรดทราบว่า URL นี้ **ควร** อ้างอิงถึงรูปโปรไฟล์ของผู้ใช้ปลายทางที่เหมาะสมสำหรับการแสดงผลเมื่ออธิบายผู้ใช้ปลายทาง ไม่ใช่รูปภาพใด ๆ ที่ผู้ใช้ถ่ายเอง | ไม่ | -| created_at | `number` | เวลาที่สร้างผู้ใช้ปลายทาง เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | ไม่ | -| updated_at | `number` | เวลาที่ข้อมูลของผู้ใช้ปลายทางถูกอัปเดตล่าสุด เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | ไม่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ----------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | +| name | `string` | ชื่อเต็มของผู้ใช้ | ไม่ | +| username | `string` | ชื่อผู้ใช้ของผู้ใช้ | ไม่ | +| picture | `string` | URL ของรูปโปรไฟล์ของผู้ใช้ปลายทาง (End-User) URL นี้ **ต้อง** อ้างอิงถึงไฟล์รูปภาพ (เช่น ไฟล์ PNG, JPEG หรือ GIF) ไม่ใช่หน้าเว็บที่มีรูปภาพ โปรดทราบว่า URL นี้ **ควร** อ้างอิงถึงรูปโปรไฟล์ของผู้ใช้ปลายทางที่เหมาะสมสำหรับแสดงเมื่ออธิบายผู้ใช้ปลายทาง ไม่ใช่รูปภาพใด ๆ ที่ผู้ใช้ถ่ายมา | ไม่ | +| created_at | `number` | เวลาที่สร้างผู้ใช้ปลายทาง เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | ไม่ | +| updated_at | `number` | เวลาที่ข้อมูลของผู้ใช้ปลายทางถูกอัปเดตล่าสุด เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z) | ไม่ | -[การอ้างสิทธิ์มาตรฐาน](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) อื่น ๆ เช่น `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, และ `locale` จะถูกรวมอยู่ในขอบเขต `profile` ด้วยโดยไม่ต้องร้องขอ endpoint userinfo ความแตกต่างเมื่อเทียบกับการอ้างสิทธิ์ข้างต้นคือ การอ้างสิทธิ์เหล่านี้จะถูกส่งกลับมาเฉพาะเมื่อค่าของมันไม่ว่างเปล่า ในขณะที่การอ้างสิทธิ์ข้างต้นจะส่งกลับ `null` หากค่าเป็นค่าว่าง +[การอ้างสิทธิ์มาตรฐาน](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) อื่น ๆ เช่น `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `website`, `gender`, `birthdate`, `zoneinfo`, และ `locale` จะถูกรวมอยู่ในขอบเขต `profile` ด้วย โดยไม่จำเป็นต้องร้องขอ endpoint userinfo ความแตกต่างเมื่อเทียบกับการอ้างสิทธิ์ข้างต้นคือ การอ้างสิทธิ์เหล่านี้จะถูกส่งกลับเมื่อค่าของมันไม่ว่างเปล่าเท่านั้น ในขณะที่การอ้างสิทธิ์ข้างต้นจะส่งกลับ `null` หากค่าของมันว่างเปล่า :::note -ต่างจากการอ้างสิทธิ์มาตรฐาน การอ้างสิทธิ์ `created_at` และ `updated_at` ใช้หน่วยเป็นมิลลิวินาทีแทนที่จะเป็นวินาที +ต่างจากการอ้างสิทธิ์มาตรฐาน การอ้างสิทธิ์ `created_at` และ `updated_at` ใช้หน่วยมิลลิวินาทีแทนที่จะเป็นวินาที ::: **`email`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ----------------- | --------- | ------------------------------- | ------------------------- | -| email | `string` | อีเมลของผู้ใช้ | ไม่ | -| email_verified | `boolean` | อีเมลได้รับการยืนยันแล้วหรือไม่ | ไม่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ----------------- | --------- | ------------------------------- | ----------------- | +| email | `string` | อีเมลของผู้ใช้ | ไม่ | +| email_verified | `boolean` | อีเมลได้รับการยืนยันแล้วหรือไม่ | ไม่ | **`phone`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| --------------------- | --------- | ----------------------------------------- | ------------------------- | -| phone_number | `string` | หมายเลขโทรศัพท์ของผู้ใช้ | ไม่ | -| phone_number_verified | `boolean` | หมายเลขโทรศัพท์ได้รับการยืนยันแล้วหรือไม่ | ไม่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| --------------------- | --------- | ----------------------------------------- | ----------------- | +| phone_number | `string` | หมายเลขโทรศัพท์ของผู้ใช้ | ไม่ | +| phone_number_verified | `boolean` | หมายเลขโทรศัพท์ได้รับการยืนยันแล้วหรือไม่ | ไม่ | **`address`** @@ -42,36 +42,40 @@ **`custom_data`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ----------------- | -------- | ----------------------- | ------------------------- | -| custom_data | `object` | ข้อมูลกำหนดเองของผู้ใช้ | ใช่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ----------------- | -------- | ----------------------- | ----------------- | +| custom_data | `object` | ข้อมูลกำหนดเองของผู้ใช้ | ใช่ | **`identities`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ----------------- | -------- | -------------------------------- | ------------------------- | -| identities | `object` | ข้อมูลตัวตนที่เชื่อมโยงของผู้ใช้ | ใช่ | -| sso_identities | `array` | ข้อมูล SSO ที่เชื่อมโยงของผู้ใช้ | ใช่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ----------------- | -------- | -------------------------------- | ----------------- | +| identities | `object` | ข้อมูลตัวตนที่เชื่อมโยงของผู้ใช้ | ใช่ | +| sso_identities | `array` | ข้อมูล SSO ที่เชื่อมโยงของผู้ใช้ | ใช่ | **`roles`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ----------------- | ---------- | -------------- | ------------------------- | -| roles | `string[]` | บทบาทของผู้ใช้ | ไม่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ----------------- | ---------- | ---------------------- | ----------------- | +| roles | `string[]` | บทบาทของผู้ใช้ (Roles) | ไม่ | **`urn:logto:scope:organizations`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ----------------- | ---------- | ------------------------------ | ------------------------- | -| organizations | `string[]` | รหัสองค์กรที่ผู้ใช้สังกัด | ไม่ | -| organization_data | `object[]` | ข้อมูลขององค์กรที่ผู้ใช้สังกัด | ใช่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ----------------- | ---------- | --------------------------- | ----------------- | +| organizations | `string[]` | รหัสองค์กรที่ผู้ใช้สังกัด | ไม่ | +| organization_data | `object[]` | ข้อมูลองค์กรที่ผู้ใช้สังกัด | ใช่ | + +:::note +การอ้างสิทธิ์ขององค์กรเหล่านี้สามารถดึงได้ผ่าน endpoint userinfo เมื่อใช้ [โทเค็นทึบ (Opaque token)](/concepts/opaque-token) อย่างไรก็ตาม โทเค็นทึบไม่สามารถใช้เป็นโทเค็นองค์กรสำหรับเข้าถึงทรัพยากรเฉพาะองค์กร ดู [โทเค็นทึบและองค์กร](/concepts/opaque-token#opaque-token-and-organizations) สำหรับรายละเอียดเพิ่มเติม +::: **`urn:logto:scope:organization_roles`** -| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo หรือไม่? | -| ------------------ | ---------- | ------------------------------------------------------------------- | ------------------------- | -| organization_roles | `string[]` | บทบาทของผู้ใช้ในแต่ละองค์กรในรูปแบบ `:` | ไม่ | +| ชื่อการอ้างสิทธิ์ | ประเภท | คำอธิบาย | ต้องใช้ userinfo? | +| ------------------ | ---------- | --------------------------------------------------------------------- | ----------------- | +| organization_roles | `string[]` | บทบาทขององค์กรที่ผู้ใช้สังกัดในรูปแบบ `:` | ไม่ | --- -เพื่อประสิทธิภาพและขนาดข้อมูล หาก "ต้องใช้ userinfo หรือไม่?" เป็น "ใช่" หมายความว่าการอ้างสิทธิ์นั้นจะไม่ปรากฏในโทเค็น ID แต่จะถูกส่งกลับใน response ของ [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) +เพื่อประสิทธิภาพและขนาดข้อมูล หาก "ต้องใช้ userinfo?" เป็น "ใช่" หมายความว่าการอ้างสิทธิ์นั้นจะไม่แสดงในโทเค็น ID แต่จะถูกส่งกลับใน response ของ [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index a0cffec7985..6a45535a3fb 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -4,11 +4,11 @@ sidebar_position: 6 # 不透明令牌 (Opaque token) -在认证过程中，如果没有指定资源，Logto 将签发一个不透明访问令牌，而不是 JWT。不透明令牌是一个随机字符串，比 JWT 短得多： +在认证 (Authentication) 过程中，如果未指定资源，Logto 会签发一个不透明令牌 (Opaque token) 作为访问令牌 (Access token)，而不是 JWT。不透明令牌 (Opaque token) 是一个随机字符串，比 JWT 短得多： ```json { - "access_token": "some-random-string", // 不透明令牌 + "access_token": "some-random-string", // 不透明令牌 (Opaque token) "expires_in": 3600, "id_token": "eyJhbGc...aBc", // JWT "scope": "openid profile email", @@ -16,33 +16,33 @@ sidebar_position: 6 } ``` -不透明令牌可用于调用 [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 并访问需要认证的受保护资源。由于它不是 JWT，资源服务器如何验证它？ +不透明令牌 (Opaque token) 可用于调用 [userinfo 端点](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 和访问需要认证 (Authentication) 的受保护资源。由于它不是 JWT，资源服务器如何验证它呢？ -Logto 提供了一个 [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html)，可用于验证不透明令牌。默认情况下，introspection endpoint 是 `/oidc/token/introspection`，并接受 `POST` 请求。以下参数是必需的： +Logto 提供了一个 [introspection 端点](https://www.rfc-editor.org/rfc/rfc7662.html)，可用于验证不透明令牌 (Opaque token)。默认情况下，introspection 端点为 `/oidc/token/introspection`，并接受 `POST` 请求。需要以下参数： -- `token`: 要验证的不透明令牌 +- `token`：要验证的不透明令牌 (Opaque token) -该 endpoint 还需要客户端认证。你可以使用以下方法之一： +该端点还需要客户端认证 (Authentication)。你可以使用以下方法之一： -- HTTP Basic 认证：使用 `Authorization` 头，值为 `Basic `。凭据必须是用冒号（`:`）分隔的客户端 ID 和客户端密钥，并进行 base64 编码。 -- HTTP POST 认证：使用 `client_id` 和 `client_secret` 参数： - - `client_id`: 请求令牌的应用程序的客户端 ID - - `client_secret`: 请求令牌的应用程序的客户端密钥 +- HTTP Basic 认证 (Authentication)：使用 `Authorization` 头，值为 `Basic `。凭据必须是 client ID 和 client secret 用冒号（`:`）分隔后进行 base64 编码。 +- HTTP POST 认证 (Authentication)：使用 `client_id` 和 `client_secret` 参数： + - `client_id`：请求令牌的应用程序的 client ID + - `client_secret`：请求令牌的应用程序的 client secret -客户端 ID（应用 ID）和客户端密钥（应用密钥）可以是 Logto 中任何“传统 web”或“机器对机器”应用程序的应用凭据。如果凭据无效，introspection endpoint 将返回错误。 +client ID（应用 ID）和 client secret（应用密钥）可以是 Logto 中任何“传统 Web”或“机器对机器”应用的应用凭据。如果凭据无效，introspection 端点会返回错误。 -introspection endpoint 返回一个包含令牌声明的 JSON 对象： +introspection 端点会返回一个包含令牌声明 (Claims) 的 JSON 对象： ```json { "active": true, // 令牌是否有效 - "sub": "1234567890" // 令牌的主体（用户 ID） + "sub": "1234567890" // 令牌的主体 (Subject)（用户 ID） } ``` -如果令牌无效，`active` 字段将为 `false`，并且 `sub` 字段将被省略。 +如果令牌无效，`active` 字段将为 `false`，并且不会返回 `sub` 字段。 -以下是 introspection 请求的非规范示例： +以下是 introspection 请求的一个非规范示例： ```bash curl --location \ @@ -54,3 +54,14 @@ curl --location \ ``` 记得将 `[tenant-id]` 替换为你的租户 ID。 + +## 不透明令牌 (Opaque token) 与组织 (Organizations) \{#opaque-token-and-organizations} + +不透明令牌 (Opaque token) 可用于通过 [userinfo 端点](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 获取组织 (Organizations) 成员信息。当你请求 `urn:logto:scope:organizations` 权限 (Scope) 时，userinfo 端点会返回用户的组织 (Organizations) 相关声明 (Claims)，如 `organizations`（组织 ID）和 `organization_data`。 + +然而，**不透明令牌 (Opaque token) 不能用作组织令牌 (Organization token)**。组织令牌 (Organization token) 始终以 JWT 格式签发，原因如下： + +1. 组织令牌 (Organization token) 包含需要资源服务器验证的组织 (Organizations) 相关声明 (Claims)（如 `organization_id` 和权限 (Permissions) 范围）。 +2. JWT 格式允许资源服务器直接验证令牌并提取组织 (Organizations) 上下文，无需额外的 API 调用。 + +要获取组织令牌 (Organization token)，你需要使用带有组织参数的 [刷新令牌流程 (Refresh token flow)](/authorization/organization-permissions#refresh-token-flow) 或 [客户端凭据流程 (Client credentials flow)](/authorization/organization-permissions#client-credentials-flow)。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index 1fff1d5f5c7..d4594914d1e 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -10,33 +10,33 @@ Logto 提供灵活的多因素认证 (MFA) 配置选项，以满足不同的安 ### 全局 MFA 配置 \{#global-mfa-configuration} -按照以下步骤在用户的 Logto 登录流程中启用多因素认证 (MFA)： +按照以下步骤在用户的 Logto 登录流程中启用 MFA： -1. 前往：控制台 > 多因素认证 (MFA)。 +1. 导航至：控制台 > 多因素认证 (MFA)。 2. 为你的用户启用支持的验证因子。 - 1. 主要因子： + 1. 主验证因子： - [Passkeys (WebAuthn)](/end-user-flows/mfa/webauthn)：适用于支持设备生物识别或安全密钥等的 Web 产品的高安全性选项，确保强大保护。 - [身份验证器应用 OTP](/end-user-flows/mfa/authenticator-app-otp)：最常见且被广泛接受的方法。使用如 Google Authenticator 或 Authy 等身份验证器应用生成的基于时间的一次性密码 (TOTP)。 - [短信验证](/end-user-flows/mfa/sms-mfa)：通过短信向用户注册手机号发送一次性验证码的便捷方式，适合偏好移动端认证 (Authentication) 且无需额外应用的用户。 - - [邮箱验证](/end-user-flows/mfa/email-mfa)：向用户注册邮箱发送一次性验证码的广泛适用方式，适合所有平台和设备的用户。 - 2. 备份因子： - - [备份码](/end-user-flows/mfa/backup-codes)：当用户无法验证上述任何主要因子时，作为备选方案。启用此选项可降低用户访问的阻力。 -3. 选择是否启用 **强制要求 MFA**： - - **启用**：用户在登录过程中会被强制要求设置 MFA，无法跳过。如果用户未设置 MFA 或删除了 MFA 设置，他们将无法访问账户，直到重新设置 MFA。 - - **禁用**：用户可以在注册流程中跳过 MFA 设置。之后可通过自助账户设置页面设置 MFA。[了解更多](/end-user-flows/account-settings/) 关于实现用户账户设置页面。并继续选择 MFA 设置提示的策略： + - [邮箱验证](/end-user-flows/mfa/email-mfa)：向用户注册邮箱发送一次性验证码的广泛可用方式，适用于所有平台和设备的用户。 + 2. 备份验证因子： + - [备份码](/end-user-flows/mfa/backup-codes)：当用户无法验证上述主验证因子时，作为备选方案。启用此选项可降低用户成功访问的阻力。 +3. 选择是否启用 **强制 MFA**： + - **启用**：用户将在登录过程中被要求设置 MFA，且无法跳过。如果用户未能设置 MFA 或删除了 MFA 设置，他们将无法访问账户，直到重新设置 MFA。 + - **禁用**：用户可在注册流程中跳过 MFA 设置。之后可通过自助账户设置页面设置 MFA。[了解更多](/end-user-flows/account-settings/) 关于实现用户账户设置页面。并继续选择 MFA 设置提示的策略： - **不要求用户设置 MFA**：用户在登录时不会被提示设置 MFA。 - - **在注册时提示用户设置 MFA**：新用户在注册时会被提示设置 MFA，已有用户将在下次登录时看到提示。用户可跳过此步骤，且之后不会再次出现。 - - **在注册后首次登录时提示用户设置 MFA**：新用户在注册后第二次登录时会被提示设置 MFA，已有用户将在下次登录时看到提示。用户可跳过此步骤，且之后不会再次出现。 + - **在注册时提示用户设置 MFA**：新用户在注册时会被提示设置 MFA，现有用户将在下次登录时看到提示。用户可跳过此步骤，且不会再次出现。 + - **注册后首次登录时提示用户设置 MFA**：新用户在注册后第二次登录时会被提示设置 MFA，现有用户将在下次登录时看到提示。用户可跳过此步骤，且不会再次出现。 :::tip -如果你需要在用户跳过 MFA 注册后再次提示，请重置他们的跳过状态，这样下次登录时会再次显示设置界面。管理员可使用 Management API（`PATCH /api/users/{userId}/logto-configs`），开发者在自助流程中可调用 Account API（`PATCH /api/my-account/logto-configs`）。[Management API 参考](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Account API 参考](https://openapi.logto.io/operation/operation-updatelogtoconfig) +如果你需要在用户跳过 MFA 注册后再次提示，请重置其跳过状态，下次登录时会显示设置界面。管理员可使用 Management API（`PATCH /api/users/{userId}/logto-configs`），开发者在自助流程中可调用 Account API（`PATCH /api/my-account/logto-configs`）。[Management API 参考](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Account API 参考](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: MFA 设置 -### 组织 (Organization) 级别 MFA 配置 \{#organization-level-mfa-configuration} +### 组织 (Organization) 级 MFA 配置 \{#organization-level-mfa-configuration} -对于支持 [组织 (Organizations)](/organizations) 的多租户架构产品，大多数情况下你无需对所有用户强制要求 MFA。你可以按组织 (Organization) 启用 MFA，根据每个客户的需求定制要求。开始操作请参考 [为组织成员强制要求 MFA](/organizations/organization-management#require-mfa-for-organization-members)。 +对于支持 [组织 (Organizations)](/organizations) 的多租户架构产品，大多数情况下无需对所有用户强制要求 MFA。你可以按组织 (Organization) 启用 MFA，根据每个客户的需求定制要求。开始使用请参考 [为组织成员要求 MFA](/organizations/organization-management#require-mfa-for-organization-members)。 在 **多因素认证 (MFA)** 部分，将 **组织启用 MFA 后用户的 MFA 设置提示** 设置为 **下次登录时提示用户设置 MFA（不可跳过）**。任何要求 MFA 的组织成员将在下次登录时被强制要求完成 MFA 设置，且无法跳过。 @@ -44,35 +44,35 @@ Logto 提供灵活的多因素认证 (MFA) 配置选项，以满足不同的安 ### MFA 设置流程 \{#mfa-set-up-flow} -启用 MFA 后，用户将在登录和注册过程中被提示设置 MFA。仅当“强制要求 MFA”策略被禁用时，用户才可选择跳过设置流程。 +启用 MFA 后，用户将在登录和注册过程中被提示设置 MFA。仅当“强制 MFA”策略被禁用时，用户才可选择跳过设置流程。 1. **访问登录或注册页面**：用户进入登录或注册页面。 2. **完成登录或注册**：用户在登录或注册流程中完成身份验证 (Authentication)。 -3. **设置 MFA 主要因子**：用户被提示设置主要 MFA 因子（如 passkey、身份验证器应用 OTP、短信验证码或邮箱验证码）。 - - 如果启用了多个主要因子，用户可选择自己偏好的方式。 - - 如果主要因子与注册标识符相同（如短信或邮箱），则会自动预验证，用户可跳过验证步骤，直接进入下一步（如“添加另一个两步验证”或“保存你的备份因子”）。 - - 如果“强制要求 MFA”策略被禁用，用户也可通过点击“跳过”按钮跳过此步骤。 -4. **设置 MFA 备份因子**：如果启用了 **备份码**，用户在成功配置主要认证 (Authentication) 因子后会被提示保存备份码。系统会自动生成备份码并展示给用户，用户可下载并安全保存。用户需手动确认备份码以完成 MFA 设置流程。 +3. **设置主 MFA 验证因子**：用户被提示设置主 MFA 验证因子（如 passkey、身份验证器应用 OTP、短信码或邮箱码）。 + - 如果启用了多个主验证因子，用户可选择偏好方式。 + - 若主验证因子与注册标识符相同（如短信或邮箱），则会自动预验证，用户可跳过验证步骤，直接进入下一步（如“添加另一个两步验证”或“保存你的备份因子”）。 + - 若“强制 MFA”策略被禁用，用户也可通过点击“跳过”按钮跳过此步骤。 +4. **设置 MFA 备份因子**：若启用了 **备份码**，用户在成功配置主认证 (Authentication) 因子后会被提示保存备份码。系统会自动生成备份码并展示给用户，用户可下载并安全保存。用户需手动确认备份码以完成 MFA 设置流程。 MFA 设置流程 ### MFA 验证流程 \{#mfa-verification-flow} -已设置 MFA 的用户在登录时会被提示使用已配置的 MFA 因子验证身份。验证因子取决于 Logto 中的 MFA 配置和用户设置。 +已设置 MFA 的用户在登录时会被要求通过已配置的 MFA 因子验证身份。验证因子取决于 Logto 中的 MFA 配置和用户设置。 -- 如果用户只设置了一个因子，将直接验证该因子。 -- 如果用户为两步验证 (2FA) 设置了多个因子，系统会根据以下优先级规则展示验证选项： - - **Passkey 优先**：如果用户已配置 passkey，则默认以此作为验证方式。 - - **上次使用优先**：如无 passkey，系统优先展示用户上次成功使用的验证方式。 - - **选择列表**：如以上优先级均不适用，两步验证页面会展示所有可用的绑定验证方式供用户选择。 - - 用户可随时点击“尝试其他验证方式”在不同验证选项间切换。 -- 如果所有启用的主要因子用户均不可用，且已启用备份码，用户可使用一次性备份码验证身份。 +- 若用户仅设置了一个因子，将直接进行验证。 +- 若用户为两步验证 (2FA) 设置了多个因子，系统将根据以下优先级规则展示验证选项： + - **Passkey 优先**：若用户配置了 passkey，将默认作为验证方式。 + - **上次使用优先**：若无 passkey，系统优先展示用户上次成功使用的验证方式。 + - **选择列表**：若上述优先级均不适用，两步验证页面将展示所有可用的已绑定验证方式供用户选择。 + - 用户可随时点击“尝试其他验证方式”切换不同验证选项。 +- 若所有启用的主验证因子均不可用，且启用了备份码，用户可使用一次性备份码验证身份。 MFA 验证流程 ## MFA 管理 \{#mfa-management} -除了在登录 / 注册时的初始设置外，用户还可通过自助账户中心管理 MFA 设置。这为用户根据自身需求绑定或解绑 MFA 因子提供了灵活性。 +除登录 / 注册时的初始设置外，用户可通过自助账户中心管理 MFA 设置。这样用户可根据需求灵活绑定或解绑 MFA 因子。 ### 构建账户中心 \{#building-an-account-center} @@ -84,7 +84,7 @@ Logto 提供灵活的多因素认证 (MFA) 配置选项，以满足不同的安 ### 登录后 MFA 设置提示 \{#post-login-mfa-setup-prompts} -对于注册时不强制要求 MFA 的应用，你可以实现智能提示以鼓励用户设置 MFA： +对于注册时不强制 MFA 的应用，你可以实现智能提示以鼓励用户设置 MFA： - **条件提示**：根据用户行为或账户价值展示 MFA 设置建议 - **安全仪表盘**：展示安全分数，启用 MFA 后分数提升 @@ -94,10 +94,10 @@ Logto 提供灵活的多因素认证 (MFA) 配置选项，以满足不同的安 ### 在控制台管理用户 MFA \{#manage-users-mfa-in-console} -在 控制台 > 用户管理 中，管理员可以高效管理用户 MFA 设置： +在 控制台 > 用户管理 中，管理员可高效管理用户 MFA 设置： - **查看用户 MFA 状态**：检查每个用户已启用哪些 MFA 因子。 -- **移除用户 MFA**：删除用户的所有 MFA 因子，用户需重新设置 MFA。 +- **移除用户 MFA**：删除用户所有 MFA 因子，用户需重新设置 MFA。 ### 常见问题 \{#faqs} @@ -105,17 +105,17 @@ Logto 提供灵活的多因素认证 (MFA) 配置选项，以满足不同的安 ### 管理员移除用户现有 MFA 因子后会发生什么？ \{#what-happens-when-administrators-remove-users-existing-mfa-factors} -当管理员移除用户所有主要 MFA 因子（passkey、身份验证器应用 OTP、短信或邮箱）后，用户下次登录时会出现以下场景： +当管理员移除用户所有主 MFA 因子（passkey、身份验证器应用 OTP、短信或邮箱）后，用户下次登录时会出现以下情况： **场景 1：无 MFA 因子剩余** -- 如果没有任何 MFA 因子（包括无备份码），且 [MFA 策略](#global-mfa-configuration) 要求 MFA，用户将被允许无 MFA 验证直接登录，并会立即被提示重新设置 MFA。 +- 若不存在任何 MFA 因子（包括无备份码），且 [MFA 策略](#global-mfa-configuration) 要求 MFA，用户将被允许无 MFA 验证直接登录，并立即被提示重新设置 MFA。 -**场景 2：仍有备份码存在** +**场景 2：仍有备份码** -- 如果仍有备份码可用，用户登录时需先通过备份码验证。 -- 备份码验证成功后，用户会被提示设置新的主要 MFA 因子。 -- 用户是否可以跳过设置，取决于你配置的 MFA 策略。 -- 这种方式可防止用户在无主要因子可用时被锁定账户。 +- 若仍有备份码可用，用户登录时需先通过备份码验证。 +- 备份码验证成功后，用户会被提示设置新的主 MFA 因子。 +- 用户是否可跳过设置取决于你配置的 MFA 策略。 +- 这种方式可防止用户在无主因子的情况下被锁定账户。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index e74f505eb25..e9dc885884a 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -16,7 +16,7 @@ sidebar_position: 4 ### 解码 ID 令牌 (ID token) \{#decode-the-id-token} -ID 令牌 (ID token) 是一个标准的 JWT，其中包含用户资料信息和与组织 (Organization) 相关的声明 (Claims)。调用 SDK 方法 `decodeIdToken()` 可以获得如下的 JSON 对象： +ID 令牌 (ID token) 是一个标准的 JWT，包含用户资料信息和与组织 (Organization) 相关的声明 (Claims)。调用 SDK 方法 `decodeIdToken()` 可以获得如下的 JSON 对象： ```json { @@ -42,8 +42,8 @@ ID 令牌 (ID token) 是一个标准的 JWT，其中包含用户资料信息和 } ``` -但是，ID 令牌 (ID token) 只会在认证 (Authentication) 期间签发，如果用户资料之后发生更改，可能会变得过时。 -如需获取最新信息，请使用下面的第二种方式，或调用 `clearAllTokens()` 并重新发起认证 (Authentication) 流程以获取新的 ID 令牌 (ID token)。 +然而，ID 令牌 (ID token) 只会在认证 (Authentication) 时签发，如果用户资料之后发生变化，令牌内容可能会过时。 +如需获取最新信息，请使用下方第二种方式，或调用 `clearAllTokens()` 并重新发起认证 (Authentication) 流程以获取新的 ID 令牌 (ID token)。 ```ts await logtoClient.clearAllTokens(); @@ -57,4 +57,10 @@ logtoClient.signIn({ ### 从 `/oidc/me` 端点获取用户信息 \{#fetch-user-info-from-the-oidc-me-endpoint} -你也可以请求 `/oidc/me`，以在组织 (Organization) 上下文中获取实时的用户信息。调用 SDK 方法 `fetchUserInfo()`。 +你也可以请求 `/oidc/me`，在组织 (Organization) 上下文中实时获取用户信息。调用 SDK 方法 `fetchUserInfo()`。 + +:::tip[不透明令牌 (Opaque token) 支持] +如果你正在使用[不透明令牌 (Opaque token)](/concepts/opaque-token)（当未指定 API 资源时签发），你仍然可以通过 userinfo 端点获取组织 (Organization) 成员信息。当你请求 `urn:logto:scope:organizations` 权限 (Scope) 时，响应中会包含 `organizations` 及其他与组织 (Organization) 相关的声明 (Claims)。 + +注意，不透明令牌 (Opaque token) 不能作为组织令牌 (Organization token) 用于访问组织 (Organization) 专属资源。详见[不透明令牌 (Opaque token) 与组织 (Organizations)](/concepts/opaque-token#opaque-token-and-organizations)。 +::: diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index 74e2f326b55..8947cdad7ea 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -1,77 +1,81 @@ -以下是支持的权限 (Scopes) 列表及相应的声明 (Claims)： +以下是支持的权限 (Scopes) 列表及其对应的声明 (Claims)： **`openid`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| -------- | -------- | ---------------- | ---------------- | -| sub | `string` | 用户的唯一标识符 | 否 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| ---------- | -------- | ---------------- | ------------------ | +| sub | `string` | 用户的唯一标识符 | 否 | **`profile`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| ---------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | -| name | `string` | 用户的全名 | 否 | -| username | `string` | 用户名 | 否 | -| picture | `string` | 终端用户的个人资料图片的 URL。此 URL 必须指向一个图像文件（例如 PNG、JPEG 或 GIF 图像文件），而不是包含图像的网页。请注意，此 URL 应特别引用适合在描述终端用户时显示的终端用户的个人资料照片，而不是终端用户拍摄的任意照片。 | 否 | -| created_at | `number` | 终端用户创建的时间。时间表示为自 Unix 纪元（1970-01-01T00:00:00Z）以来的毫秒数。 | 否 | -| updated_at | `number` | 终端用户信息最后更新的时间。时间表示为自 Unix 纪元（1970-01-01T00:00:00Z）以来的毫秒数。 | 否 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| ---------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | +| name | `string` | 用户的全名 | 否 | +| username | `string` | 用户名 | 否 | +| picture | `string` | 终端用户头像的 URL。该 URL 必须指向图片文件（如 PNG、JPEG 或 GIF），而不是包含图片的网页。注意，该 URL 应专门指向适合在描述终端用户时展示的头像，而不是终端用户拍摄的任意照片。 | 否 | +| created_at | `number` | 终端用户的创建时间。该时间以自 Unix 纪元（1970-01-01T00:00:00Z）以来的毫秒数表示。 | 否 | +| updated_at | `number` | 终端用户信息最后更新时间。该时间以自 Unix 纪元（1970-01-01T00:00:00Z）以来的毫秒数表示。 | 否 | -其他 [标准声明](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 包括 `family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`website`、`gender`、`birthdate`、`zoneinfo` 和 `locale` 也将包含在 `profile` 权限中，无需请求用户信息端点。与上述声明的区别在于，这些声明只有在其值不为空时才会返回，而上述声明在值为空时将返回 `null`。 +其他 [标准声明 (Claims)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 包括 `family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`website`、`gender`、`birthdate`、`zoneinfo` 和 `locale` 也会包含在 `profile` 权限 (Scope) 中，无需请求 userinfo 端点。与上表声明 (Claims) 不同的是，这些声明 (Claims) 只有在值不为空时才会返回，而上表中的声明 (Claims) 如果值为空则会返回 `null`。 :::note -与标准声明不同，`created_at` 和 `updated_at` 声明使用毫秒而不是秒。 +与标准声明 (Claims) 不同，`created_at` 和 `updated_at` 声明 (Claims) 使用的是毫秒而不是秒。 ::: **`email`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| -------------- | --------- | ---------------------- | ---------------- | -| email | `string` | 用户的电子邮件地址 | 否 | -| email_verified | `boolean` | 电子邮件地址是否已验证 | 否 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| -------------- | --------- | ---------------------- | ------------------ | +| email | `string` | 用户的电子邮件地址 | 否 | +| email_verified | `boolean` | 电子邮件地址是否已验证 | 否 | **`phone`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| --------------------- | --------- | ------------------ | ---------------- | -| phone_number | `string` | 用户的电话号码 | 否 | -| phone_number_verified | `boolean` | 电话号码是否已验证 | 否 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| --------------------- | --------- | ------------------ | ------------------ | +| phone_number | `string` | 用户的电话号码 | 否 | +| phone_number_verified | `boolean` | 电话号码是否已验证 | 否 | **`address`** -有关地址声明的详细信息，请参阅 [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim)。 +关于 address 声明 (Claim) 的详细信息，请参阅 [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim)。 **`custom_data`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| ----------- | -------- | ---------------- | ---------------- | -| custom_data | `object` | 用户的自定义数据 | 是 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| ----------- | -------- | ---------------- | ------------------ | +| custom_data | `object` | 用户的自定义数据 | 是 | **`identities`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| -------------- | -------- | ------------------- | ---------------- | -| identities | `object` | 用户的关联身份 | 是 | -| sso_identities | `array` | 用户的关联 SSO 身份 | 是 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| -------------- | -------- | ----------------------- | ------------------ | +| identities | `object` | 用户关联的身份信息 | 是 | +| sso_identities | `array` | 用户关联的 SSO 身份信息 | 是 | **`roles`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| -------- | ---------- | ---------- | ---------------- | -| roles | `string[]` | 用户的角色 | 否 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| ---------- | ---------- | ------------------ | ------------------ | +| roles | `string[]` | 用户的角色 (Roles) | 否 | **`urn:logto:scope:organizations`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| ----------------- | ---------- | ------------------ | ---------------- | -| organizations | `string[]` | 用户所属的组织 ID | 否 | -| organization_data | `object[]` | 用户所属的组织数据 | 是 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| ----------------- | ---------- | -------------------------------------- | ------------------ | +| organizations | `string[]` | 用户所属的组织 (Organizations) ID 列表 | 否 | +| organization_data | `object[]` | 用户所属的组织 (Organizations) 数据 | 是 | + +:::note +这些组织 (Organizations) 声明 (Claims) 也可以通过 userinfo 端点获取，当使用 [不透明令牌 (Opaque token)](/concepts/opaque-token) 时也是如此。然而，不透明令牌 (Opaque tokens) 不能作为组织令牌 (Organization tokens) 用于访问组织专属资源。详情请参见 [不透明令牌 (Opaque token) 与组织 (Organizations)](/concepts/opaque-token#opaque-token-and-organizations)。 +::: **`urn:logto:scope:organization_roles`** -| 声明名称 | 类型 | 描述 | 需要用户信息吗？ | -| ------------------ | ---------- | ---------------------------------------------------------- | ---------------- | -| organization_roles | `string[]` | 用户所属的组织角色，格式为 `:` | 否 | +| Claim name | Type | 描述 | 需要 userinfo 吗？ | +| ------------------ | ---------- | ----------------------------------------------------------------------------------- | ------------------ | +| organization_roles | `string[]` | 用户所属组织 (Organizations) 的角色 (Roles)，格式为 `:` | 否 | --- -考虑到性能和数据大小，如果“需要用户信息吗？”为“是”，则表示声明不会显示在 ID 令牌中，而会在 [用户信息端点](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 响应中返回。 +考虑到性能和数据大小，如果“需要 userinfo 吗？”为“是”，则该声明 (Claim) 不会出现在 ID 令牌 (ID token) 中，而会在 [userinfo 端点](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 响应中返回。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx index 7f219eb8dcd..6aa365d4ba2 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx @@ -4,11 +4,11 @@ sidebar_position: 6 # 不透明權杖 (Opaque token) -在驗證 (Authentication) 過程中，如果未指定資源，Logto 將簽發不透明存取權杖 (Opaque token) 而非 JWT。不透明權杖是一個隨機字串，比 JWT 短得多： +在驗證 (Authentication) 流程中，若未指定資源，Logto 會簽發不透明存取權杖 (Opaque access token)，而非 JWT。不透明權杖是一串隨機字串，長度遠短於 JWT： ```json { - "access_token": "some-random-string", // 不透明權杖 (Opaque token) + "access_token": "some-random-string", // 不透明權杖 (opaque token) "expires_in": 3600, "id_token": "eyJhbGc...aBc", // JWT "scope": "openid profile email", @@ -16,33 +16,33 @@ sidebar_position: 6 } ``` -不透明權杖可用於呼叫 [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 並存取需要驗證的受保護資源。由於它不是 JWT，資源伺服器如何驗證它？ +不透明權杖可用於呼叫 [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 以及存取需要驗證 (Authentication) 的受保護資源。由於它不是 JWT，資源伺服器該如何驗證它的有效性？ -Logto 提供了一個 [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html) 可用於驗證不透明權杖。預設情況下，introspection endpoint 是 `/oidc/token/introspection`，並接受 `POST` 請求。以下參數是必需的： +Logto 提供 [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html) 來驗證不透明權杖。預設情況下，introspection endpoint 為 `/oidc/token/introspection`，並接受 `POST` 請求。需傳遞以下參數： - `token`：要驗證的不透明權杖 -此 endpoint 也需要客戶端驗證。你可以使用以下方法之一： +此 endpoint 也需要用戶端驗證 (client authentication)。你可以選擇以下其中一種方式： -- HTTP Basic 驗證：使用 `Authorization` 標頭，值為 `Basic `。憑證必須是客戶端 ID 和客戶端密鑰，以冒號（`:`）分隔並進行 base64 編碼。 -- HTTP POST 驗證：使用 `client_id` 和 `client_secret` 參數： - - `client_id`：請求權杖的應用程式的客戶端 ID - - `client_secret`：請求權杖的應用程式的客戶端密鑰 +- HTTP Basic authentication：在 `Authorization` 標頭中使用 `Basic `。憑證內容為 client ID 與 client secret 以冒號（`:`）分隔後進行 base64 編碼。 +- HTTP POST authentication：使用 `client_id` 與 `client_secret` 參數： + - `client_id`：申請權杖的應用程式 client ID + - `client_secret`：申請權杖的應用程式 client secret -客戶端 ID（應用程式 ID）和客戶端密鑰（應用程式密鑰）可以是 Logto 中任何「傳統網頁」或「機器對機器」應用程式的應用程式憑證。如果憑證無效，introspection endpoint 將返回錯誤。 +client ID（app ID）與 client secret（app secret）可為 Logto 中任何「傳統網頁」或「機器對機器」應用程式的應用程式憑證。若憑證無效，introspection endpoint 會回傳錯誤。 -introspection endpoint 返回一個包含權杖宣告的 JSON 物件： +introspection endpoint 會回傳一個包含權杖宣告 (Claims) 的 JSON 物件： ```json { "active": true, // 權杖是否有效 - "sub": "1234567890" // 權杖的主體 (Subject)（使用者 ID） + "sub": "1234567890" // 權杖主體 (Subject)，即使用者 ID } ``` -如果權杖無效，`active` 欄位將為 `false`，且 `sub` 欄位將被省略。 +若權杖無效，`active` 欄位會為 `false`，且不會有 `sub` 欄位。 -以下是 introspection 請求的非規範性範例： +以下為 introspection 請求的非正式範例： ```bash curl --location \ @@ -53,4 +53,15 @@ curl --location \ --data-urlencode 'client_secret=1234567890' ``` -記得將 `[tenant-id]` 替換為你的租戶 ID。 +請將 `[tenant-id]` 替換為你的 tenant ID。 + +## 不透明權杖與組織 (Organizations) \{#opaque-token-and-organizations} + +不透明權杖可用於透過 [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 取得組織 (Organization) 成員資訊。當你請求 `urn:logto:scope:organizations` 權限範圍 (Scope) 時，userinfo endpoint 會回傳使用者的組織相關宣告 (Claims)，如 `organizations`（組織 ID）與 `organization_data`。 + +然而，**不透明權杖無法作為組織權杖 (Organization token) 使用**。組織權杖一律以 JWT 格式簽發，原因如下： + +1. 組織權杖包含組織專屬宣告 (如 `organization_id` 與權限範圍)，資源伺服器需驗證這些資訊。 +2. JWT 格式允許資源伺服器直接驗證權杖並擷取組織上下文，無需額外 API 呼叫。 + +若要取得組織權杖，需使用帶有組織參數的 [重新整理權杖流程 (Refresh token flow)](/authorization/organization-permissions#refresh-token-flow) 或 [用戶端憑證流程 (Client credentials flow)](/authorization/organization-permissions#client-credentials-flow)。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx index 19b4879ada0..ff8dd1e73ad 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/mfa/configure-mfa.mdx @@ -4,41 +4,41 @@ sidebar_position: 1 # 設定多重要素驗證 (MFA, Multi-factor authentication) -## 在 Logto 設定 MFA \{#configure-mfa-settings-in-logto} +## 在 Logto 中設定 MFA \{#configure-mfa-settings-in-logto} -Logto 提供彈性的多重要素驗證 (MFA) 設定選項，以滿足不同的安全需求。你可以針對所有使用者進行全域 MFA 設定，或在多租戶應用程式中，依組織啟用 MFA。 +Logto 提供彈性的多重要素驗證 (MFA) 設定選項，以滿足不同的安全需求。你可以在全域層級為所有使用者設定 MFA，或針對多租戶應用程式按組織啟用。 ### 全域 MFA 設定 \{#global-mfa-configuration} -依照下列步驟，於使用者的 Logto 登入流程中啟用 MFA： +依照以下步驟，在使用者的 Logto 登入流程中啟用 MFA： -1. 前往：Console > Multi-factor auth。 -2. 啟用你希望提供給使用者的驗證因子。 +1. 前往：控制台 > 多重要素驗證。 +2. 啟用你希望使用者可用的驗證因子。 1. 主要因子： - - [Passkeys (WebAuthn)](/end-user-flows/mfa/webauthn)：高安全性的選擇，適用於支援裝置生物辨識或安全金鑰等的網頁產品，確保強大保護。 - - [驗證器 App OTP](/end-user-flows/mfa/authenticator-app-otp)：最常見且廣泛接受的方法。使用如 Google Authenticator 或 Authy 等驗證器 App 產生的基於時間的一次性密碼 (TOTP)。 - - [簡訊驗證](/end-user-flows/mfa/sms-mfa)：透過簡訊將一次性驗證碼發送至使用者註冊的手機號碼，適合偏好行動裝置驗證且不需額外 App 的使用者。 - - [電子郵件驗證](/end-user-flows/mfa/email-mfa)：將一次性驗證碼發送至使用者註冊的電子郵件信箱，適用於所有平台與裝置的使用者。 + - [通行密鑰 (Passkeys, WebAuthn)](/end-user-flows/mfa/webauthn)：高安全性的選擇，適用於支援裝置生物辨識或安全金鑰等網頁產品，確保強大防護。 + - [驗證器 App 一次性密碼 (Authenticator App OTP)](/end-user-flows/mfa/authenticator-app-otp)：最常見且廣泛接受的方法。使用如 Google Authenticator 或 Authy 等驗證器 App 產生的基於時間的一次性密碼 (TOTP)。 + - [簡訊驗證 (SMS verification)](/end-user-flows/mfa/sms-mfa)：透過簡訊將一次性驗證碼發送到使用者註冊的手機號碼，適合偏好行動裝置驗證且不需額外 App 的使用者。 + - [電子郵件驗證 (Email verification)](/end-user-flows/mfa/email-mfa)：將一次性驗證碼發送到使用者註冊的電子郵件信箱，適用於所有平台與裝置的使用者。 2. 備用因子： - - [備用代碼](/end-user-flows/mfa/backup-codes)：當使用者無法驗證上述任何主要因子時，作為備用選項。啟用此選項可降低使用者存取失敗的阻力。 -3. 選擇是否啟用 **強制 MFA（Require MFA）**： + - [備用碼 (Backup codes)](/end-user-flows/mfa/backup-codes)：當使用者無法驗證上述任何主要因子時，作為備用選項。啟用此選項可降低使用者存取失敗的阻力。 +3. 選擇是否啟用 **強制 MFA (Require MFA)**： - **啟用**：使用者在登入流程中會被強制要求設定 MFA，且無法跳過。若使用者未完成 MFA 設定或刪除 MFA 設定，將無法登入帳號，直到重新設定 MFA。 - - **停用**：使用者可於註冊流程中跳過 MFA 設定，日後可透過自助帳號設定頁面設定 MFA。你可以[進一步了解](/end-user-flows/account-settings/)如何實作使用者帳號設定頁面。並繼續選擇 MFA 設定提示的政策： + - **停用**：使用者可在註冊流程中跳過 MFA 設定，日後可透過自助帳號設定頁面補充設定。你可以[進一步了解](/end-user-flows/account-settings/)如何實作使用者帳號設定頁面。並繼續選擇 MFA 設定提示的政策： - **不提示使用者設定 MFA**：登入時不會提示使用者設定 MFA。 - - **註冊時提示使用者設定 MFA**：新使用者於註冊時會被提示設定 MFA，現有使用者則於下次登入時看到提示。使用者可跳過此步驟，且不會再次出現。 - - **註冊後首次登入時提示使用者設定 MFA**：新使用者於註冊後第二次登入時會被提示設定 MFA，現有使用者則於下次登入時看到提示。使用者可跳過此步驟，且不會再次出現。 + - **註冊時提示使用者設定 MFA**：新使用者在註冊時會被提示設定 MFA，現有使用者則會在下次登入時看到提示。使用者可跳過此步驟，且不會再次出現。 + - **註冊後首次登入時提示使用者設定 MFA**：新使用者在註冊後第二次登入時會被提示設定 MFA，現有使用者則會在下次登入時看到提示。使用者可跳過此步驟，且不會再次出現。 :::tip -若你希望在使用者跳過 MFA 註冊後再次提示，請重設其跳過狀態，讓下次登入時顯示設定畫面。管理員可使用 Management API（`PATCH /api/users/{userId}/logto-configs`），開發者在自助流程中可呼叫 Account API（`PATCH /api/my-account/logto-configs`）。[Management API 參考文件](https://openapi.logto.io/operation/operation-updateuserlogtoconfig) · [Account API 參考文件](https://openapi.logto.io/operation/operation-updatelogtoconfig) +若你需要在使用者跳過 MFA 註冊後再次提示，請重設其跳過狀態，讓下次登入時顯示設定畫面。管理員可使用 Management API（`PATCH /api/users/{userId}/logto-configs`），開發者在自助流程中可呼叫 Account API（`PATCH /api/my-account/logto-configs`）。[Management API 參考文件](https://openapi.logto.io/operation/operation-updateuserlogtoconfigs) · [Account API 參考文件](https://openapi.logto.io/operation/operation-updatelogtoconfig) ::: -MFA 設定 +MFA 設定畫面 ### 組織層級 MFA 設定 \{#organization-level-mfa-configuration} -對於支援 [組織 (Organizations)](/organizations) 的多租戶架構產品，大多數情況下你不需要對所有使用者強制啟用 MFA。你可以依組織啟用 MFA，根據每個客戶的需求量身訂做。請參考[要求組織成員啟用 MFA](/organizations/organization-management#require-mfa-for-organization-members)開始設定。 +對於支援 [組織 (Organizations)](/organizations) 的多租戶架構產品，大多數情況下你不需要對所有使用者強制啟用 MFA。你可以按組織啟用 MFA，根據每個客戶的需求量身訂做。請參考 [要求組織成員啟用 MFA](/organizations/organization-management#require-mfa-for-organization-members) 開始設定。 -於 **多重要素驗證 (Multi-factor authentication)** 區段，將 **組織啟用 MFA 後對使用者的 MFA 設定提示** 設為 **下次登入時提示使用者設定 MFA（不可跳過）**。任何要求 MFA 的組織成員，於下次登入時都會被強制提示完成 MFA 設定，且無法跳過。 +在 **多重要素驗證 (Multi-factor authentication)** 區塊中，將 **組織啟用 MFA 後的使用者 MFA 設定提示** 設為 **下次登入時提示使用者設定 MFA（不可跳過）**。任何要求 MFA 的組織成員，將於下次登入時被強制提示完成 MFA 設定，且無法跳過。 ## MFA 使用者流程 \{#mfa-user-flow} @@ -47,74 +47,74 @@ Logto 提供彈性的多重要素驗證 (MFA) 設定選項，以滿足不同的 啟用 MFA 後，使用者在登入與註冊流程中會被提示設定 MFA。僅當「強制 MFA」政策為停用時，使用者才可選擇跳過此設定流程。 1. **造訪登入或註冊頁面**：使用者前往登入或註冊頁面。 -2. **完成登入或註冊**：使用者於登入或註冊流程中完成身分驗證。 -3. **設定 MFA 主要因子**：系統提示使用者設定主要 MFA 因子（如 passkey、驗證器 App OTP、簡訊驗證碼或電子郵件驗證碼）。 - - 若啟用多個主要因子，使用者可選擇偏好的選項。 - - 若主要因子與註冊識別碼相同（如簡訊或電子郵件），將自動完成驗證，使用者可略過驗證步驟，直接進入下一步（如「新增另一個二步驟驗證」或「儲存備用因子」）。 - - 若「強制 MFA」政策為停用，使用者也可點選「跳過」按鈕略過此步驟。 -4. **設定 MFA 備用因子**：若啟用 **備用代碼**，使用者於成功設定主要驗證因子後，會被提示儲存備用代碼。系統會自動產生備用代碼並顯示給使用者，使用者可下載並妥善保存。必須手動確認備用代碼才能完成 MFA 設定流程。 +2. **完成登入或註冊**：使用者在登入或註冊流程中完成身分驗證。 +3. **設定 MFA 主要因子**：系統提示使用者設定主要 MFA 因子（通行密鑰、驗證器 App OTP、簡訊驗證碼或電子郵件驗證碼）。 + - 若啟用多個主要因子，使用者可選擇偏好的方式。 + - 若主要因子與註冊識別碼相同（如簡訊或電子郵件），將自動預先驗證，使用者可略過驗證步驟，直接進入下一步（如「新增另一個二步驟驗證」或「儲存備用因子」）。 + - 若「強制 MFA」政策為停用，使用者可點選「跳過」按鈕略過此步驟。 +4. **設定 MFA 備用因子**：若啟用 **備用碼 (Backup codes)**，使用者在成功設定主要驗證因子後會被提示儲存備用碼。系統會自動產生備用碼並顯示給使用者，使用者可下載並妥善保存。使用者必須手動確認備用碼，才能完成 MFA 設定流程。 MFA 設定流程 ### MFA 驗證流程 \{#mfa-verification-flow} -已設定 MFA 的使用者，在登入時會被提示以已綁定的 MFA 因子驗證身分。驗證因子將依 Logto 的 MFA 設定與使用者個人設定而定。 +已設定 MFA 的使用者，在登入時會被提示以已綁定的 MFA 因子驗證身分。驗證因子將依據 Logto 的 MFA 設定與使用者個人設定而定。 - 若使用者僅設定一種因子，將直接進行該因子的驗證。 -- 若設定多種因子進行二步驟驗證 (2FA)，系統會依下列優先規則呈現驗證選項： - - **Passkey 優先**：若已設定 passkey，預設以此作為驗證方式。 - - **上次使用偏好**：若無 passkey，系統優先選擇使用者上次成功驗證的方法。 - - **選擇清單**：若上述皆不適用，二步驟驗證頁面會顯示所有可用的驗證方法供選擇。 +- 若使用者設定多個二步驟驗證因子，系統將依下列優先規則呈現驗證選項： + - **通行密鑰優先**：若使用者已設定通行密鑰，預設以此作為驗證方式。 + - **上次使用偏好**：若無通行密鑰，系統將優先選擇使用者上次成功驗證的方法。 + - **選擇清單**：若上述皆不適用，二步驟驗證頁面會顯示所有可用的驗證方法供使用者選擇。 - 使用者可隨時點選「嘗試其他驗證方式」切換不同驗證選項。 -- 若所有啟用的主要因子皆不可用，且已啟用備用代碼，則可使用一次性備用代碼驗證身分。 +- 若所有啟用的主要因子皆不可用，且已啟用備用碼，使用者可使用一次性備用碼驗證身分。 MFA 驗證流程 ## MFA 管理 \{#mfa-management} -除了登入／註冊時的初始設定外，使用者可透過自助帳號中心管理 MFA 設定，靈活綁定或解除 MFA 因子。 +除了首次登入／註冊時的設定外，使用者可透過自助帳號中心管理 MFA 設定，靈活綁定或解除 MFA 因子。 ### 建立帳號中心 \{#building-an-account-center} 你可以利用 Logto 的 [Account API](/end-user-flows/account-settings/by-account-api) 建立完整的帳號中心，讓使用者： -- **綁定新 MFA 因子**：新增驗證器 App、passkey 或重新產生備用代碼 +- **綁定新 MFA 因子**：新增驗證器 App、通行密鑰，或重新產生備用碼 - **解除現有 MFA 因子**：移除不再使用的 MFA 方法 - **檢視目前 MFA 狀態**：查看目前已設定的 MFA 因子 ### 登入後 MFA 設定提示 \{#post-login-mfa-setup-prompts} -對於註冊時未強制 MFA 的應用程式，你可以實作智慧提示，鼓勵使用者設定 MFA： +對於註冊時不強制 MFA 的應用程式，你可以實作智慧提示，鼓勵使用者設定 MFA： - **條件式提示**：根據使用者行為或帳號價值顯示 MFA 設定建議 - **安全儀表板**：顯示安全分數，啟用 MFA 後分數提升 -- **漸進式導引**：將 MFA 設定納入逐步強化安全性的流程 +- **漸進式導入**：將 MFA 設定納入逐步提升安全性的流程 -進一步了解如何透過 [Account API](/end-user-flows/account-settings/by-account-api) 實作這些模式。 +進一步了解如何用 [Account API](/end-user-flows/account-settings/by-account-api) 實作這些模式。 -### 於 Console 管理使用者 MFA \{#manage-users-mfa-in-console} +### 在控制台管理使用者 MFA \{#manage-users-mfa-in-console} -在 Console > User management，管理員可有效管理使用者 MFA 設定： +於 控制台 > 使用者管理，管理員可有效管理使用者 MFA 設定： - **檢視使用者 MFA 狀態**：查看每位使用者啟用哪些 MFA 因子。 -- **移除使用者 MFA**：刪除使用者所有 MFA 因子，需重新設定 MFA。 +- **移除使用者 MFA**：刪除使用者所有 MFA 因子，強制其重新設定 MFA。 ### 常見問題 \{#faqs}
-### 管理員移除使用者現有 MFA 因子時會發生什麼事？ \{#what-happens-when-administrators-remove-users-existing-mfa-factors} +### 管理員移除使用者現有 MFA 因子後會發生什麼事？ \{#what-happens-when-administrators-remove-users-existing-mfa-factors} -當管理員移除使用者所有主要 MFA 因子（passkey、驗證器 App OTP、簡訊或電子郵件）後，使用者下次登入時會遇到以下情境： +當管理員移除使用者所有主要 MFA 因子（通行密鑰、驗證器 App OTP、簡訊或電子郵件）後，使用者下次登入時會遇到以下情境： **情境一：無任何 MFA 因子** -- 若不存在任何 MFA 因子（包含無備用代碼），且 [MFA 政策](#global-mfa-configuration) 強制要求 MFA，使用者將可直接登入且無需 MFA 驗證，並立即被提示重新設定 MFA。 +- 若不存在任何 MFA 因子（包含無備用碼），且 [MFA 政策](#global-mfa-configuration) 強制要求 MFA，使用者將可直接登入且無需 MFA 驗證，並立即被提示重新設定 MFA。 -**情境二：仍有備用代碼** +**情境二：仍有備用碼** -- 若仍有備用代碼可用，使用者登入時必須先以備用代碼驗證。 -- 成功驗證後，系統會提示使用者設定新的主要 MFA 因子。 +- 若仍有備用碼可用，使用者登入時必須先以備用碼驗證。 +- 成功驗證備用碼後，系統會提示使用者設定新的主要 MFA 因子。 - 使用者是否可跳過此設定，取決於你所設定的 MFA 政策。 - 此設計可避免使用者在無主要因子時被鎖定帳號。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx index 1520174e05f..f64d325768b 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/get-user-info.mdx @@ -8,7 +8,7 @@ sidebar_position: 4 這通常用於使用者個人資料頁面，需要顯示其所屬組織資訊時。 -組織使用者資訊 +組織使用者資訊 (Organization user info) ## 如何實作 \{#how-to-implement-it} @@ -16,7 +16,7 @@ sidebar_position: 4 ### 解碼 ID 權杖 (ID token) \{#decode-the-id-token} -ID 權杖 (ID token) 是一個標準的 JWT，內含使用者個人資料資訊與組織相關宣告 (claims)。呼叫 SDK 方法 `decodeIdToken()` 可取得如下的 JSON 物件： +ID 權杖 (ID token) 是一個標準 JWT，內含使用者個人資料資訊與組織相關宣告 (claims)。呼叫 SDK 方法 `decodeIdToken()` 可取得如下的 JSON 物件： ```json { @@ -42,8 +42,8 @@ ID 權杖 (ID token) 是一個標準的 JWT，內含使用者個人資料資訊 } ``` -但請注意，ID 權杖 (ID token) 僅於驗證 (Authentication) 時簽發，若使用者個人資料後續有變更，權杖內容可能會過時。 -若需取得最新資訊，請參考下方第二種方式，或呼叫 `clearAllTokens()` 並重新啟動驗證流程以取得新的 ID 權杖 (ID token)。 +然而，ID 權杖 (ID token) 僅於驗證 (Authentication) 時簽發，若使用者個人資料後續有變更，內容可能會過時。 +若需取得最新資訊，請參考下方第二種方式，或呼叫 `clearAllTokens()` 並重新啟動驗證流程以獲取新的 ID 權杖 (ID token)。 ```ts await logtoClient.clearAllTokens(); @@ -53,8 +53,14 @@ logtoClient.signIn({ }); ``` -如果會話仍有效，`signIn` 呼叫會直接導回你的應用程式，無需再次輸入憑證。對使用者來說，應用程式僅會刷新畫面，並於背景自動取得新的 ID 權杖 (ID token)。 +如果會話仍然有效，`signIn` 呼叫會直接導回你的應用程式，無需再次輸入憑證。對使用者來說，應用程式僅是重新整理，並於背景取得新的 ID 權杖 (ID token)。 ### 從 `/oidc/me` 端點取得使用者資訊 \{#fetch-user-info-from-the-oidc-me-endpoint} -你也可以請求 `/oidc/me`，以組織情境下即時取得使用者資訊。請呼叫 SDK 方法 `fetchUserInfo()`。 +你也可以請求 `/oidc/me` 以即時取得組織情境下的使用者資訊。呼叫 SDK 方法 `fetchUserInfo()`。 + +:::tip[不透明權杖 (Opaque token) 支援] +如果你使用 [不透明權杖 (Opaque token)](/concepts/opaque-token)（當未指定 API 資源時簽發），仍可透過 userinfo 端點取得組織成員資訊。當你請求 `urn:logto:scope:organizations` 權限範圍 (scope) 時，回應將包含 `organizations` 及其他組織相關宣告 (claims)。 + +請注意，不透明權杖 (Opaque token) 無法作為組織權杖 (Organization token) 用於存取組織專屬資源。詳見 [不透明權杖 (Opaque token) 與組織 (Organizations)](/concepts/opaque-token#opaque-token-and-organizations)。 +::: diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md index ef4700caad8..d0da4fea2b0 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/quick-starts/fragments/_scope-claim-list.md @@ -1,77 +1,81 @@ -以下是支援的權限範圍 (Scopes) 及其對應的宣告 (Claims)： +以下是支援的權限範圍 (Scopes) 及對應的宣告 (Claims) 清單： **`openid`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| -------- | -------- | ------------------ | ------------------ | -| sub | `string` | 使用者的唯一識別符 | 否 | +| Claim name | Type | Description | Needs userinfo? | +| ---------- | -------- | ------------------ | --------------- | +| sub | `string` | 使用者的唯一識別符 | No | **`profile`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| ---------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------ | -| name | `string` | 使用者的全名 | 否 | -| username | `string` | 使用者的用戶名 | 否 | -| picture | `string` | 使用者個人資料圖片的 URL。此 URL 必須指向圖像文件（例如 PNG、JPEG 或 GIF 圖像文件），而不是包含圖像的網頁。請注意，此 URL 應特別參考適合在描述使用者時顯示的個人資料照片，而不是使用者拍攝的任意照片。 | 否 | -| created_at | `number` | 使用者創建的時間。時間以自 Unix epoch（1970-01-01T00:00:00Z）以來的毫秒數表示。 | 否 | -| updated_at | `number` | 使用者資訊最後更新的時間。時間以自 Unix epoch（1970-01-01T00:00:00Z）以來的毫秒數表示。 | 否 | +| Claim name | Type | Description | Needs userinfo? | +| ---------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | +| name | `string` | 使用者的全名 | No | +| username | `string` | 使用者的使用者名稱 | No | +| picture | `string` | 終端使用者大頭貼的 URL。此 URL 必須指向圖片檔案（例如 PNG、JPEG 或 GIF），而非包含圖片的網頁。請注意，此 URL 應明確指向適合描述終端使用者的個人照片，而非終端使用者隨意拍攝的照片。 | No | +| created_at | `number` | 終端使用者建立的時間。時間以自 Unix 紀元（1970-01-01T00:00:00Z）以來的毫秒數表示。 | No | +| updated_at | `number` | 終端使用者資訊最後更新的時間。時間以自 Unix 紀元（1970-01-01T00:00:00Z）以來的毫秒數表示。 | No | -其他 [標準宣告](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 包括 `family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`website`、`gender`、`birthdate`、`zoneinfo` 和 `locale` 也將包含在 `profile` 權限範圍中，無需請求使用者資訊端點。與上述宣告的不同之處在於，這些宣告僅在其值不為空時返回，而上述宣告在值為空時將返回 `null`。 +其他 [標準宣告 (Standard claims)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 包含 `family_name`、`given_name`、`middle_name`、`nickname`、`preferred_username`、`profile`、`website`、`gender`、`birthdate`、`zoneinfo` 與 `locale` 也會包含在 `profile` 權限範圍內，無需額外請求 userinfo endpoint。與上表宣告不同的是，這些宣告僅在其值不為空時才會返回，而上表宣告若值為空則會返回 `null`。 :::note -與標準宣告不同，`created_at` 和 `updated_at` 宣告使用毫秒而非秒。 +與標準宣告不同，`created_at` 與 `updated_at` 宣告使用毫秒而非秒數。 ::: **`email`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| -------------- | --------- | ---------------------- | ------------------ | -| email | `string` | 使用者的電子郵件地址 | 否 | -| email_verified | `boolean` | 電子郵件地址是否已驗證 | 否 | +| Claim name | Type | Description | Needs userinfo? | +| -------------- | --------- | ---------------------- | --------------- | +| email | `string` | 使用者的電子郵件地址 | No | +| email_verified | `boolean` | 電子郵件地址是否已驗證 | No | **`phone`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| --------------------- | --------- | ------------------ | ------------------ | -| phone_number | `string` | 使用者的電話號碼 | 否 | -| phone_number_verified | `boolean` | 電話號碼是否已驗證 | 否 | +| Claim name | Type | Description | Needs userinfo? | +| --------------------- | --------- | ------------------ | --------------- | +| phone_number | `string` | 使用者的手機號碼 | No | +| phone_number_verified | `boolean` | 手機號碼是否已驗證 | No | **`address`** -請參閱 [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) 以獲取地址宣告的詳細資訊。 +請參閱 [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim) 以瞭解 address 宣告的詳細資訊。 **`custom_data`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| ----------- | -------- | ---------------- | ------------------ | -| custom_data | `object` | 使用者的自訂資料 | 是 | +| Claim name | Type | Description | Needs userinfo? | +| ----------- | -------- | ---------------- | --------------- | +| custom_data | `object` | 使用者的自訂資料 | Yes | **`identities`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| -------------- | -------- | --------------------- | ------------------ | -| identities | `object` | 使用者的連結身分 | 是 | -| sso_identities | `array` | 使用者的連結 SSO 身分 | 是 | +| Claim name | Type | Description | Needs userinfo? | +| -------------- | -------- | --------------------- | --------------- | +| identities | `object` | 使用者的連結身分 | Yes | +| sso_identities | `array` | 使用者的連結 SSO 身分 | Yes | **`roles`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| -------- | ---------- | ------------ | ------------------ | -| roles | `string[]` | 使用者的角色 | 否 | +| Claim name | Type | Description | Needs userinfo? | +| ---------- | ---------- | -------------------- | --------------- | +| roles | `string[]` | 使用者的角色 (Roles) | No | **`urn:logto:scope:organizations`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| ----------------- | ---------- | -------------------- | ------------------ | -| organizations | `string[]` | 使用者所屬的組織 ID | 否 | -| organization_data | `object[]` | 使用者所屬的組織資料 | 是 | +| Claim name | Type | Description | Needs userinfo? | +| ----------------- | ---------- | ------------------------------------- | --------------- | +| organizations | `string[]` | 使用者所屬的組織 (Organizations) ID | No | +| organization_data | `object[]` | 使用者所屬的組織 (Organizations) 資料 | Yes | + +:::note +這些組織 (Organizations) 宣告也可透過 userinfo endpoint 取得（當使用 [不透明權杖 (Opaque token)](/concepts/opaque-token) 時）。但不透明權杖 (Opaque tokens) 無法作為組織權杖 (Organization tokens) 存取組織專屬資源。詳情請見 [不透明權杖 (Opaque token) 與組織 (Organizations)](/concepts/opaque-token#opaque-token-and-organizations)。 +::: **`urn:logto:scope:organization_roles`** -| 宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎？ | -| ------------------ | ---------- | ------------------------------------------------------------ | ------------------ | -| organization_roles | `string[]` | 使用者所屬的組織角色，格式為 `:` | 否 | +| Claim name | Type | Description | Needs userinfo? | +| ------------------ | ---------- | ------------------------------------------------------------------------------------- | --------------- | +| organization_roles | `string[]` | 使用者所屬的組織 (Organizations) 角色 (Roles)，格式為 `:` | No | --- -考慮到效能和資料大小，如果「需要使用者資訊嗎？」為「是」，則表示該宣告不會顯示在 ID 權杖中，而會在 [使用者資訊端點](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 回應中返回。 +考量效能與資料大小，若 "Needs userinfo?" 為 "Yes"，表示該宣告 (Claim) 不會出現在 ID 權杖 (ID token) 中，而會在 [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 回應中返回。