diff --git a/i18n/de/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx b/i18n/de/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx index a960cf063d5..c181adb86eb 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx @@ -6,20 +6,20 @@ sidebar_position: 7 # Zugriffskontrolle auf App-Ebene -Die Zugriffskontrolle auf App-Ebene ermöglicht es dir, einzuschränken, wer sich bei einer bestimmten Anwendung anmelden darf. Anstatt jedem registrierten Benutzer in deinem Logto-Tenant den Zugriff auf jede App zu erlauben, kannst du für jede Anwendung Zulassungsregeln basierend auf Benutzern, Benutzerrollen, Organisationen oder Organisationsrollen erstellen. +Die Zugriffskontrolle auf App-Ebene ermöglicht es dir, einzuschränken, wer sich bei einer bestimmten Anwendung anmelden darf. Anstatt jedem registrierten Benutzer in deinem Logto-Mandanten Zugriff auf jede App zu gewähren, kannst du für jede Anwendung Zulassungsregeln auf Basis von Benutzern, Benutzerrollen, Organisationen oder Organisationsrollen erstellen. -Verwende die Zugriffskontrolle auf App-Ebene, wenn du: +Verwende die Zugriffskontrolle auf App-Ebene, wenn du Folgendes erreichen möchtest: -- Eine interne App nur für Mitarbeitende oder Admins verfügbar machen möchtest. -- Eine [geschützte App](/integrate-logto/protected-app) auf eine ausgewählte Benutzergruppe beschränken möchtest. -- Nur bestimmten Kunden oder Partnern den Zugriff auf eine [Drittanbieter-OIDC / OAuth-Anwendung](/integrate-logto/third-party-applications) erlauben möchtest. -- Eine neue Anwendung zunächst einer Pilotgruppe bereitstellen möchtest, bevor sie allen zur Verfügung steht. +- Eine interne App nur für Mitarbeitende oder Admins verfügbar machen. +- Eine [geschützte App](/integrate-logto/protected-app) auf eine ausgewählte Benutzergruppe beschränken. +- Nur bestimmten Kunden oder Partnern den Zugriff auf eine [Drittanbieter OIDC / OAuth Anwendung](/integrate-logto/third-party-applications) erlauben. +- Eine neue Anwendung zunächst einer Pilotgruppe bereitstellen, bevor sie für alle geöffnet wird. ## Funktionsweise \{#how-it-works} -Wenn die Zugriffskontrolle auf App-Ebene deaktiviert ist, können sich alle registrierten Benutzer in deinem Logto-Tenant bei der Anwendung anmelden. +Wenn die Zugriffskontrolle auf App-Ebene deaktiviert ist, können sich alle registrierten Benutzer in deinem Logto-Mandanten bei der Anwendung anmelden. -Wenn sie aktiviert ist, kann ein Benutzer die Anwendung nur nutzen, wenn er mindestens einer konfigurierten Regel entspricht. Entspricht der Benutzer keiner Regel, verweigert Logto den Anmeldeversuch und zeigt eine Zugriffsverweigerungsseite an, bevor die Anwendung Tokens erhält. +Wenn sie aktiviert ist, kann ein Benutzer nur dann auf die Anwendung zugreifen, wenn er mindestens einer konfigurierten Regel entspricht. Entspricht der Benutzer keiner Regel, verweigert Logto den Anmeldeversuch und zeigt eine Zugriffsverweigerungsseite an, bevor die Anwendung Tokens erhält. Die Zugriffskontrolle auf App-Ebene wird während des Autorisierungsflusses und der Token-Erneuerung ausgewertet. Das bedeutet: @@ -28,7 +28,7 @@ Die Zugriffskontrolle auf App-Ebene wird während des Autorisierungsflusses und - Das Aktualisieren von Regeln wirkt sich auf zukünftige Autorisierungs- und Token-Erneuerungsprüfungen aus, ohne die globale Logto-Sitzung des Benutzers zu verändern. :::note -Die Zugriffskontrolle auf App-Ebene ist getrennt von der rollenbasierten Zugangskontrolle (RBAC). RBAC steuert, was ein Benutzer nach der Authentifizierung tun kann, indem Berechtigungen (Scopes) in Zugangstokens ausgegeben werden. Die Zugriffskontrolle auf App-Ebene steuert, ob ein Benutzer überhaupt auf eine bestimmte Anwendung zugreifen darf. +Die Zugriffskontrolle auf App-Ebene ist getrennt von der [rollenbasierten Zugangskontrolle (RBAC)](/authorization/role-based-access-control). RBAC steuert, was ein Benutzer nach der Authentifizierung tun kann, indem Berechtigungen (Berechtigungen) in Zugangstokens ausgegeben werden. Die Zugriffskontrolle auf App-Ebene steuert, ob ein Benutzer überhaupt auf eine bestimmte Anwendung zugreifen darf. ::: ## Regeltypen \{#rule-types} @@ -38,13 +38,13 @@ Du kannst die folgenden Zulassungsregeln konfigurieren: | Regeltyp | Was erlaubt wird | | ----------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Benutzer** | Bestimmte Benutzer können auf die Anwendung zugreifen. | -| **Benutzerrollen** | Benutzern, denen ausgewählte Benutzerrollen zugewiesen sind, wird der Zugriff auf die Anwendung erlaubt. | +| **Benutzerrollen** | Benutzern, denen ausgewählte Benutzerrollen zugewiesen sind, können auf die Anwendung zugreifen. | | **Organisationen** | Alle aktuellen und zukünftigen Mitglieder ausgewählter Organisationen können auf die Anwendung zugreifen. | | **Organisationsrollen** | Mitglieder mit ausgewählten Organisationsrollen in ausgewählten Organisationen können auf die Anwendung zugreifen. | Regeln sind additiv. Ein Benutzer muss nur einer Regel entsprechen, um auf die Anwendung zugreifen zu können. -Beispiel: Wenn eine Anwendung sowohl eine Benutzerrollen-Regel „Support-Team“ als auch eine Organisationsrollen-Regel „BigTree - Admin“ hat, kann ein Benutzer auf die Anwendung zugreifen, wenn er entweder die Rolle Support-Team hat oder Admin in der Organisation BigTree ist. +Beispiel: Wenn eine Anwendung sowohl eine Benutzerrollenregel „Support-Team“ als auch eine Organisationsrollenregel „BigTree - Admin“ hat, kann ein Benutzer auf die Anwendung zugreifen, wenn er entweder die Rolle Support-Team zugewiesen bekommen hat oder Admin in der Organisation BigTree ist. ## Zugriffskontrolle auf App-Ebene konfigurieren \{#configure-app-level-access-control} @@ -62,7 +62,7 @@ Beispiel: Wenn eine Anwendung sowohl eine Benutzerrollen-Regel „Support-Team 8. Klicke auf **Änderungen speichern**. :::important -Du musst mindestens eine Zulassungsregel konfigurieren, bevor du die Zugriffskontrolle aktivierst. So wird verhindert, dass die Zugriffskontrolle versehentlich aktiviert wird, ohne dass Benutzer Zugriff auf die Anwendung haben. +Du musst mindestens eine Zulassungsregel konfigurieren, bevor du die Zugriffskontrolle aktivierst. So wird verhindert, dass versehentlich die Zugriffskontrolle aktiviert wird, ohne dass Benutzer Zugriff auf die Anwendung haben. ::: ## Regeln bearbeiten oder entfernen \{#edit-or-remove-rules} @@ -70,7 +70,7 @@ Du musst mindestens eine Zulassungsregel konfigurieren, bevor du die Zugriffskon Du kannst die Zulassungsliste im Tab **Regeln** der Anwendung aktualisieren. - Um weitere Regeln hinzuzufügen, klicke unterhalb der Regel-Tabelle auf **Weitere hinzufügen**. -- Um eine Regel zu entfernen, klicke auf die Löschtaste in der Regelzeile und bestätige die Aktion. +- Um eine Regel zu entfernen, klicke auf die Löschen-Schaltfläche in der Regelzeile und bestätige die Aktion. - Nach dem Hinzufügen oder Entfernen von Regeln klicke auf **Änderungen speichern**, um die Aktualisierung zu übernehmen. Wenn die Zugriffskontrolle aktiviert ist, verlangt Logto, dass mindestens eine Regel konfiguriert bleibt. Um alle Regeln zu entfernen, deaktiviere zuerst **Zugriffskontrolle aktivieren** und speichere dann die Änderungen. @@ -82,7 +82,7 @@ Die Zugriffskontrolle auf App-Ebene beendet nicht die globale Logto-Sitzung des Für die eingeschränkte Anwendung gilt: - Ein Benutzer, der keiner Zulassungsregel mehr entspricht, wird beim nächsten Durchlaufen des Autorisierungsflusses der Anwendung blockiert. -- Wenn der Benutzer bereits App-bezogene Berechtigungen hat, prüft Logto die Regeln erneut, wenn die Anwendung ein Auffrischungstoken verwendet, um neue Tokens anzufordern. Hat der Benutzer keinen Zugriff mehr, verweigert Logto die Token-Anfrage. +- Wenn der Benutzer bereits anwendungsbezogene Berechtigungen hat, prüft Logto die Regeln erneut, wenn die Anwendung ein Auffrischungstoken verwendet, um neue Tokens anzufordern. Hat der Benutzer keinen Zugriff mehr, verweigert Logto die Token-Anfrage. So bleiben Zugriffsentscheidungen an die Anwendung gebunden, ohne andere Anwendungen unnötig zu beeinträchtigen. @@ -91,15 +91,19 @@ So bleiben Zugriffsentscheidungen an die Anwendung gebunden, ohne andere Anwendu Für [Drittanbieter-Anwendungen](/integrate-logto/third-party-applications) lösen Zugriffskontrolle auf App-Ebene und Berechtigungsmanagement unterschiedliche Probleme: - **Zugriffskontrolle auf App-Ebene** bestimmt, ob ein Benutzer sich bei der Drittanbieter-Anwendung anmelden darf. -- **Berechtigungsmanagement** bestimmt, welche Benutzerprofil-Scopes, API-Ressourcen-Scopes und Organisations-Scopes die Drittanbieter-Anwendung auf dem Zustimmungsbildschirm anfordern darf. +- **Berechtigungsmanagement** bestimmt, welche Benutzerprofil-Berechtigungen, API-Ressourcen-Berechtigungen und Organisations-Berechtigungen die Drittanbieter-Anwendung auf dem Zustimmungsbildschirm anfordern darf. Wenn beides konfiguriert ist, muss der Benutzer zuerst die Zugriffskontrolle auf App-Ebene bestehen, bevor er die Drittanbieter-Anwendung autorisieren kann. +:::note +Die Zugriffskontrolle auf App-Ebene gilt nur für registrierte Anwendungen. [Dynamische App](/integrate-logto/third-party-applications/dynamic-apps) Clients haben keinen Anwendungsdatensatz und können daher nicht auf diese Weise eingeschränkt werden. Ihr Zugriff wird durch die Berechtigungen begrenzt, die du der dynamischen App gewährst, sowie durch die Zustimmung des Benutzers. +::: + ## Beziehung zur geschützten App \{#relationship-with-protected-app} -Für die [geschützte App](/integrate-logto/protected-app) beschränkt die Zugriffskontrolle auf App-Ebene, wer die Logto-Authentifizierungsschicht passieren und den geschützten Origin-Server erreichen darf. +Für [geschützte Apps](/integrate-logto/protected-app) beschränkt die Zugriffskontrolle auf App-Ebene, wer die Logto-Authentifizierungsschicht passieren und den geschützten Origin-Server erreichen darf. -Die Authentifizierungsregeln der geschützten App bestimmen weiterhin, welche Routen eine Authentifizierung erfordern. Die Zugriffskontrolle auf App-Ebene legt fest, welche authentifizierten Logto-Benutzer auf die geschützte App zugreifen dürfen. +Die Authentifizierungsregeln der geschützten App bestimmen weiterhin, welche Routen eine Authentifizierung erfordern. Die Zugriffskontrolle auf App-Ebene legt fest, welche authentifizierten Logto-Benutzer auf die geschützte App-Anwendung zugreifen dürfen. ## Best Practices \{#best-practices} @@ -107,4 +111,4 @@ Die Authentifizierungsregeln der geschützten App bestimmen weiterhin, welche Ro - Verwende Organisationsregeln, wenn alle Mitglieder einer Organisation auf die App zugreifen sollen. - Verwende Organisationsrollen-Regeln, wenn nur bestimmte Mitglieder einer Organisation auf die App zugreifen sollen. - Überprüfe die Zugriffsregeln, wenn Benutzer Rollen wechseln, Organisationen beitreten oder Organisationen verlassen. -- Halte RBAC-Berechtigungen und Zugriffskontrolle auf App-Ebene in deinem mentalen Modell getrennt: Die Zugriffskontrolle auf App-Ebene beantwortet „Kann dieser Benutzer auf diese App zugreifen?“, während RBAC beantwortet „Was kann dieser Benutzer nach dem Zugriff auf APIs oder Organisationsfunktionen tun?“ +- Halte RBAC-Berechtigungen und Zugriffskontrolle auf App-Ebene in deinem mentalen Modell getrennt: Zugriffskontrolle auf App-Ebene beantwortet „Kann dieser Benutzer auf diese App zugreifen?“, während RBAC beantwortet „Was kann dieser Benutzer nach dem Zugriff auf APIs oder Organisationsfunktionen tun?“ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/de/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index 408c5951f90..70bf1bc3364 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -24,28 +24,30 @@ Bei Standardwerten ist `protocol` entweder `http` oder `https` entsprechend dein | NODE_ENV | `undefined` | 'production' | 'test' | undefined | In welcher Art von Umgebung Logto ausgeführt wird. | | PORT | `3001` | `number` | Der lokale Port, auf dem Logto lauscht. | | ADMIN_PORT | `3002` | `number` | Der lokale Port, auf dem die Logto Admin Console lauscht. | -| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Setze es auf `1` oder `true`, um den Port für die Admin Console zu deaktivieren. Wenn `ADMIN_ENDPOINT` nicht gesetzt ist, wird die Admin Console vollständig deaktiviert. | +| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Setze diesen Wert auf `1` oder `true`, um den Port für die Admin Console zu deaktivieren. Wenn `ADMIN_ENDPOINT` nicht gesetzt ist, wird die Admin Console vollständig deaktiviert. | | DB_URL | N/A | `string` | Die [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6) für die Logto-Datenbank. | -| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout` in Millisekunden. Verwende einen numerischen String (z. B. `5000`), um ihn zu setzen, oder `DISABLE_TIMEOUT`, um den Startparameter zu überspringen (empfohlen für PgBouncer/RDS Proxy). Wenn nicht gesetzt oder ungültig, ist der Standardwert 60000 ms. | +| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout` in Millisekunden. Verwende einen numerischen String (z. B. `5000`), um ihn zu setzen, oder `DISABLE_TIMEOUT`, um den Startparameter wegzulassen (empfohlen für PgBouncer/RDS Proxy). Wenn nicht gesetzt oder ungültig, beträgt der Standardwert 60000 ms. | | HTTPS_CERT_PATH | `undefined` | string | undefined | Siehe [HTTPS aktivieren](#enabling-https) für Details. | | HTTPS_KEY_PATH | `undefined` | string | undefined | Siehe oben. | | TRUST_PROXY_HEADER | `false` | `boolean` | Siehe oben. | -| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | Du kannst eine URL mit deiner eigenen Domain für Online-Tests oder Produktion angeben. Dies beeinflusst auch den Wert des [OIDC-Aussteller-Identifiers](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier). | +| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | Du kannst eine URL mit deiner eigenen Domain für Online-Tests oder Produktion angeben. Dies beeinflusst auch den Wert des [OIDC Aussteller-Identifiers](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier). | | ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | Du kannst eine URL mit deiner eigenen Domain für die Produktion angeben (z. B. `ADMIN_ENDPOINT=https://admin.domain.com`). Dies beeinflusst auch die Redirect-URIs der Admin Console. | -| CASE_SENSITIVE_USERNAME | `true` | `boolean` | Gibt an, ob der Benutzername Groß- / Kleinschreibung beachtet. Sei vorsichtig beim Ändern dieses Wertes; Änderungen passen bestehende Daten in der Datenbank nicht automatisch an und erfordern manuelle Verwaltung. | +| CASE_SENSITIVE_USERNAME | `true` | `boolean` | Gibt an, ob der Benutzername Groß- / Kleinschreibung beachtet. Sei vorsichtig bei der Änderung dieses Wertes; Änderungen passen bestehende Daten in der Datenbank nicht automatisch an und erfordern manuelle Verwaltung. | | SECRET_VAULT_KEK | `undefined` | `string` | Der Key Encryption Key (KEK), der zum Verschlüsseln von Data Encryption Keys (DEK) im [Secret Vault](/secret-vault) verwendet wird. Erforderlich, damit der Secret Vault ordnungsgemäß funktioniert. Muss ein base64-codierter String sein. AES-256 (32 Bytes) wird empfohlen. Beispiel: `crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | Schonfrist in Sekunden für gestaffelte OIDC-Private-Key-Rotation. Bei einem positiven Wert wird der neue Private Key zuerst als `Next` erstellt und wird erst nach Ablauf der Schonfrist wirksam. | -| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | Nur für Self-Hosting. Setze auf `true` nur, wenn vertrauenswürdige OIDC-Relying-Party-Endpunkte auf private Netzwerkadressen aufgelöst werden müssen. Siehe [OIDC-Provider SSRF-Schutz](#oidc-provider-ssrf-protection). | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | Schonfrist in Sekunden für die gestaffelte OIDC-Private-Key-Rotation. Bei einem positiven Wert wird der neue Private Key zuerst als `Next` erstellt und wird erst nach Ablauf der Schonfrist wirksam. | +| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | Nur für Self-Hosted. Setze auf `true` nur, wenn vertrauenswürdige OIDC Relying-Party-Endpunkte auf private Netzwerkadressen zugreifen müssen. Siehe [OIDC Provider SSRF-Schutz](#oidc-provider-ssrf-protection). | -### OIDC-Provider SSRF-Schutz {#oidc-provider-ssrf-protection} +### OIDC Provider SSRF-Schutz {#oidc-provider-ssrf-protection} -Logto schützt die ausgehenden Anfragen des OIDC-Providers standardmäßig vor Server-Side Request Forgery (SSRF). Anfragen an spezielle Adressen, einschließlich Loopback- und privaten Netzwerkadressen, werden blockiert. Dieser Schutz umfasst Relying-Party-Endpunkte wie Back-Channel-Logout-URIs, `jwks_uri` und `sector_identifier_uri`. +Logto schützt die ausgehenden Anfragen des OIDC Providers standardmäßig vor Server-Side Request Forgery (SSRF). Anfragen an spezielle Adressen, einschließlich Loopback- und privaten Netzwerkadressen, werden blockiert. Dieser Schutz umfasst Relying-Party-Endpunkte wie Back-Channel-Logout-URIs, `jwks_uri` und `sector_identifier_uri` sowie die Client-ID-Metadaten-Dokumente, die für [dynamische Apps](/integrate-logto/third-party-applications/dynamic-apps) abgerufen werden. -Wenn deine selbst gehostete Bereitstellung absichtlich einen vertrauenswürdigen Relying-Party-Endpunkt in einem privaten Netzwerk erreichen muss, setze `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` und starte jede Logto-Instanz neu. +Wenn deine Self-Hosted-Bereitstellung absichtlich einen vertrauenswürdigen Relying-Party-Endpunkt in einem privaten Netzwerk erreichen muss, setze `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` und starte jede Logto-Instanz neu. :::caution -Diese Einstellung deaktiviert den SSRF-Schutz für alle ausgehenden OIDC-Provider-Anfragen, nicht nur für einen Endpunkt. Deaktiviere sie nur, wenn alle konfigurierten Relying-Party-Endpunkte vertrauenswürdig sind und deine Netzwerkkontrollen den Zugriff auf sensible interne Dienste verhindern. +Diese Einstellung deaktiviert den SSRF-Schutz für alle ausgehenden OIDC Provider-Anfragen, nicht nur für einen Endpunkt. Deaktiviere sie nur, wenn alle konfigurierten Relying-Party-Endpunkte vertrauenswürdig sind und deine Netzwerkkontrollen den Zugriff auf sensible interne Dienste verhindern. + +[Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) kann nicht aktiviert werden, solange dieser Schutz deaktiviert ist, da Metadaten-Dokumente von URLs abgerufen werden, die von den Clients selbst bereitgestellt werden. ::: @@ -63,7 +65,7 @@ Eine weitere gängige Praxis ist es, einen HTTPS-Proxy vor Node zu schalten (z. In diesem Fall möchtest du wahrscheinlich `TRUST_PROXY_HEADER` auf `true` setzen, was angibt, ob Proxy-Header-Felder vertraut werden sollen. Logto gibt den Wert an die [Koa-App-Einstellungen](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings) weiter. -Siehe [Vertrauen von TLS-Offloading-Proxies](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies), um zu erfahren, wann dieses Feld konfiguriert werden sollte. +Siehe [TLS-Offloading-Proxys vertrauen](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies), um zu erfahren, wann dieses Feld konfiguriert werden sollte. ## Datenbank-Konfigurationen {#database-configs} diff --git a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index 63da02b0bf4..03d4b9aeb62 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -8,32 +8,36 @@ sidebar_position: 6 Stell dir vor, du meldest dich bei Logto mit deinem Google-Konto an. Wenn du auf die Schaltfläche „Mit Google anmelden“ klickst, wirst du zur Anmeldeseite von Google weitergeleitet. Nachdem du deine Google-Zugangsdaten eingegeben hast, wirst du aufgefordert, Logto die Erlaubnis zu erteilen, auf deine Google-Kontoinformationen zuzugreifen. Dies ist der Zustimmungsbildschirm für den Benutzer. -Diese Seite nennen wir den **Zustimmungsbildschirm (consent screen)** oder **Zustimmungsseite (consent page)**. Es handelt sich um einen standardmäßigen [OIDC / OAuth 2.0 Flow](/integrate-logto/third-party-applications), der es Benutzern ermöglicht, [Drittanbieteranwendungen](/integrate-logto/third-party-applications) Berechtigungen zu erteilen, um in ihrem Namen auf ihre Daten zuzugreifen. Sein Hauptzweck ist es, Benutzer über die Erhebung, Verarbeitung und Nutzung ihrer personenbezogenen Daten zu informieren und ihre ausdrückliche Zustimmung für diese Aktivitäten einzuholen. +Diese Seite nennen wir den **Zustimmungsbildschirm (consent screen)** oder **Zustimmungsseite (consent page)**. Es handelt sich um einen standardmäßigen [OIDC / OAuth 2.0 Flow](/integrate-logto/third-party-applications), der es Benutzern ermöglicht, [Drittanbieteranwendungen](/integrate-logto/third-party-applications) Berechtigungen zu erteilen, um in ihrem Namen auf ihre Daten zuzugreifen. Sein Hauptzweck ist es, Benutzer über die Erhebung, Verarbeitung und Nutzung ihrer persönlichen Daten zu informieren und ihre ausdrückliche Zustimmung für diese Aktivitäten einzuholen. Auf einem Zustimmungsbildschirm werden den Benutzern in der Regel [Informationen](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information) darüber angezeigt, welche Arten von Daten erhoben werden, wie sie verwendet werden und ob sie mit Dritten geteilt werden. Diese Informationen sind entscheidend für Transparenz und ermöglichen es den Benutzern, fundierte Entscheidungen über ihre Privatsphäre und Datensicherheit zu treffen. -Zustimmungsseiten sind besonders wichtig im Zusammenhang mit Datenschutzbestimmungen wie der Datenschutz-Grundverordnung ([DSGVO](https://gdpr-info.eu/art-4-gdpr/)) in der Europäischen Union oder dem California Consumer Privacy Act ([CCPA](https://oag.ca.gov/privacy/ccpa)) in den Vereinigten Staaten, die von Organisationen verlangen, eine klare und eindeutige Zustimmung der Benutzer einzuholen, bevor sie deren personenbezogene Daten verarbeiten. +Zustimmungsseiten sind besonders wichtig im Zusammenhang mit Datenschutzbestimmungen wie der Datenschutz-Grundverordnung ([DSGVO](https://gdpr-info.eu/art-4-gdpr/)) in der Europäischen Union oder dem California Consumer Privacy Act ([CCPA](https://oag.ca.gov/privacy/ccpa)) in den Vereinigten Staaten, die von Organisationen verlangen, eine klare und eindeutige Zustimmung der Benutzer einzuholen, bevor sie deren persönliche Informationen verarbeiten. ## Wann sieht der Benutzer den Zustimmungsbildschirm in Logto? \{#when-does-user-see-the-consent-screen-in-logto} -Wie bereits erwähnt, erscheint der Zustimmungsbildschirm, wenn sich Benutzer bei Logto mit einem Drittanbieter-Identitätsanbieter (IdP) wie Google, Facebook oder Apple anmelden. In diesem Setup fungiert Logto als Service Provider (SP) und fordert Zugriff auf Benutzerinformationen vom IdP an. Der Zustimmungsbildschirm wird in der Regel angezeigt, wenn der [SP](https://auth.wiki/service-provider) und der [IdP](https://auth.wiki/identity-provider) unterschiedliche Organisationen sind und eine Benutzerautorisierung zur Datenfreigabe erforderlich ist. +Wie bereits erwähnt, erscheint der Zustimmungsbildschirm, wenn sich Benutzer bei Logto mit einem Drittanbieter-Identitätsanbieter (IdP) wie Google, Facebook oder Apple anmelden. In diesem Setup fungiert Logto als Service Provider (SP) und fordert Zugriff auf Benutzerinformationen vom IdP an. Der Zustimmungsbildschirm wird in der Regel angezeigt, wenn der [SP](https://auth.wiki/service-provider) und der [IdP](https://auth.wiki/identity-provider) verschiedene Organisationen sind und eine Benutzerautorisierung zur Datenfreigabe erforderlich ist. Consent screen Logto as SP -Ebenso wird in Logto, wenn Logto als IdP fungiert, der Zustimmungsbildschirm angezeigt, wenn sich Benutzer bei einer [**OIDC / OAuth Drittanbieteranwendung**](/integrate-logto/third-party-applications) anmelden, die mit Logto integriert ist. Dieser Bildschirm informiert die Benutzer über die Daten, die die Anwendung anfordert, und bittet um deren Erlaubnis, fortzufahren. Die Benutzer können die angeforderten Berechtigungen überprüfen und entscheiden, ob sie der Anwendung die Autorisierung erteilen möchten. +Ebenso wird in Logto, wenn Logto als IdP fungiert, der Zustimmungsbildschirm angezeigt, wenn sich Benutzer bei einer [**OIDC / OAuth Drittanbieteranwendung**](/integrate-logto/third-party-applications) anmelden, die mit Logto integriert ist. Dieser Bildschirm informiert die Benutzer über die Daten, die die Anwendung anfordert, und bittet um deren Erlaubnis, fortzufahren. Benutzer können die angeforderten Berechtigungen überprüfen und entscheiden, ob sie der Anwendung die Autorisierung erteilen. Consent screen Logto as IdP +### Nicht registrierte (dynamische) Clients \{#unregistered-dynamic-clients} + +Wenn [dynamische App](/integrate-logto/third-party-applications/dynamic-apps) aktiviert ist, können Clients ohne vorherige Registrierung eine Verbindung zu deinem Mandanten herstellen. Für diese Clients zeigt der Zustimmungsbildschirm einen zusätzlichen Hinweis sowie den Host der Client-ID-URL an. Der Clientname und das Logo stammen aus dem eigenen Metadaten-Dokument des Clients, sodass sie jede Marke imitieren können, während der Host nicht gefälscht werden kann. + ## Wie konfiguriere ich den Zustimmungsbildschirm? \{#how-to-configure-the-consent-screen} -Der Logto-Zustimmungsflow ermöglicht es dir, Anmeldungen von Drittanbieteranwendungen zu autorisieren. Du kannst das Branding und die Berechtigungsanfragen für jede OIDC-Drittanbieteranwendung individuell anpassen. +Der Logto-Zustimmungsflow ermöglicht es dir, Anmeldungen von Drittanbieteranwendungen zu autorisieren. Du kannst das Branding und die Berechtigungsanfragen für jede OIDC-Drittanbieteranwendung anpassen. Erfahre mehr über das Einrichten der [Drittanbieteranwendung](/integrate-logto/third-party-applications/) und die Konfiguration des [Zustimmungsbildschirms](/integrate-logto/third-party-applications/consent-screen-branding/) in Logto. ## Verwandte Ressourcen \{#related-resources} - Mache deinen Service zu einem sicheren OIDC-IdP mit Zustimmungsbildschirm. + Mache deinen Service zu einem sicheren OIDC IdP mit Zustimmungsbildschirm. Einführung in den Zustimmungsbildschirm für Benutzer. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index c740c594760..e7474c9ee13 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -7,11 +7,11 @@ sidebar_position: 7 ## Einführung \{#introduction} -In Logto bezeichnet eine _Anwendung_ ein bestimmtes Softwareprogramm oder einen Dienst, der bei der Logto-Plattform registriert ist und die Autorisierung erhalten hat, auf Benutzerinformationen zuzugreifen oder Aktionen im Namen eines Benutzers durchzuführen. Anwendungen werden verwendet, um die Quelle von Anfragen an die Logto API zu identifizieren sowie den Authentifizierungs- und Autorisierungsprozess für Benutzer zu verwalten, die auf diese Anwendungen zugreifen. +In Logto bezeichnet eine _Anwendung_ ein bestimmtes Softwareprogramm oder einen Dienst, der bei der Logto-Plattform registriert ist und die Autorisierung erhalten hat, auf Benutzerinformationen zuzugreifen oder Aktionen im Namen eines Benutzers durchzuführen. Anwendungen werden verwendet, um die Quelle von Anfragen an die Logto API zu identifizieren sowie den Authentifizierungs- und Autorisierungsprozess für Benutzer, die auf diese Anwendungen zugreifen, zu verwalten. Die Verwendung von Anwendungen in der Logto-Anmeldeerfahrung ermöglicht es Benutzern, ihre autorisierten Anwendungen einfach von einem zentralen Ort aus zu verwalten und darauf zuzugreifen – mit einem konsistenten und sicheren Authentifizierungsprozess. Dies trägt dazu bei, die Benutzererfahrung zu optimieren und sicherzustellen, dass nur autorisierte Personen auf sensible Informationen zugreifen oder im Namen der Organisation handeln. -Anwendungen werden auch in den Audit-Logs von Logto verwendet, um Benutzeraktivitäten zu verfolgen und potenzielle Sicherheitsbedrohungen oder -verletzungen zu identifizieren. Durch die Zuordnung bestimmter Aktionen zu einer bestimmten Anwendung kann Logto detaillierte Einblicke darüber geben, wie Daten abgerufen und verwendet werden, sodass Organisationen ihre Sicherheits- und Compliance-Anforderungen besser verwalten können. +Anwendungen werden auch in den Logto-Audit-Logs verwendet, um Benutzeraktivitäten zu verfolgen und potenzielle Sicherheitsbedrohungen oder -verletzungen zu identifizieren. Durch die Zuordnung bestimmter Aktionen zu einer bestimmten Anwendung kann Logto detaillierte Einblicke darüber geben, wie Daten abgerufen und verwendet werden, sodass Organisationen ihre Sicherheits- und Compliance-Anforderungen besser verwalten können. Wenn du deine Anwendung mit Logto integrieren möchtest, siehe [Logto integrieren](/integrate-logto). ## Eigenschaften \{#properties} @@ -20,19 +20,23 @@ Wenn du deine Anwendung mit Logto integrieren möchtest, siehe [Logto integriere _Anwendungs-ID_ ist ein eindeutiger, automatisch generierter Schlüssel zur Identifizierung deiner Anwendung in Logto und wird als [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) in OAuth 2.0 bezeichnet. +:::note +[Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) Clients sind nicht in Logto registriert. Ihre Client-ID ist eine öffentliche HTTPS-URL, die dem Client gehört und das Client-Metadaten-Dokument bereitstellt. +::: + ### Anwendungstypen \{#application-types} Eine _Anwendung_ kann einer der folgenden Anwendungstypen sein: - **Native App** ist eine App, die in einer nativen Umgebung läuft. Z. B. iOS-App, Android-App. - - **Device Flow App** ist ein spezieller Typ einer nativen App für Geräte mit eingeschränkter Eingabe oder Headless-Anwendungen (z. B. Smart-TVs, Spielkonsolen, CLI-Tools, IoT-Geräte). Sie verwendet den [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) anstelle des Standard-Redirect-basierten Flows. Siehe [Device Flow Schnellstart](/quick-starts/device-flow) für Details. + - **Device Flow App** ist ein spezieller Typ einer nativen App für geräte- oder kopflose Anwendungen mit eingeschränkter Eingabe (z. B. Smart-TVs, Spielkonsolen, CLI-Tools, IoT-Geräte). Sie verwendet den [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) anstelle des Standard-Redirect-basierten Flows. Siehe [Device Flow Schnellstart](/quick-starts/device-flow) für Details. - **Single Page App** ist eine App, die in einem Webbrowser läuft und die Seite mit neuen Daten vom Server aktualisiert, ohne ganze neue Seiten zu laden. Z. B. React DOM App, Vue App. - **Traditionelle Web-App** ist eine App, die Seiten ausschließlich durch den Webserver rendert und aktualisiert. Z. B. JSP, PHP. - **Maschine-zu-Maschine (M2M) App** ist eine Anwendung, die in einer Maschinenumgebung für die direkte Dienst-zu-Dienst-Kommunikation ohne Benutzerinteraktion läuft. ### Anwendungsschlüssel \{#application-secret} -_Anwendungsschlüssel_ ist ein Schlüssel, der zur Authentifizierung der Anwendung im Authentifizierungssystem verwendet wird, insbesondere für private Clients (Traditionelle Web- und M2M-Apps) als private Sicherheitsbarriere. +_Anwendungsschlüssel_ ist ein Schlüssel, der zur Authentifizierung der Anwendung im Authentifizierungssystem verwendet wird, speziell für private Clients (Traditionelle Web- und M2M-Apps) als private Sicherheitsbarriere. :::tip Single Page Apps (SPAs) und Native Apps stellen keinen App-Schlüssel bereit. SPAs und Native Apps sind "öffentliche Clients" und können keine Geheimnisse bewahren (Browser-Code oder App-Bundles sind einsehbar). Statt eines App-Schlüssels schützt Logto sie mit PKCE, strikter Redirect-URI/CORS-Validierung, kurzlebigen Zugangstokens und Auffrischungstoken-Rotation. @@ -42,7 +46,7 @@ Single Page Apps (SPAs) und Native Apps stellen keinen App-Schlüssel bereit. SP _Anwendungsname_ ist ein menschenlesbarer Name der Anwendung und wird in der Admin-Konsole angezeigt. -Der _Anwendungsname_ ist ein wichtiger Bestandteil der Verwaltung von Anwendungen in Logto, da Administratoren damit die Aktivitäten einzelner Anwendungen innerhalb der Plattform leicht identifizieren und nachverfolgen können. +Der _Anwendungsname_ ist ein wichtiger Bestandteil der Verwaltung von Anwendungen in Logto, da Administratoren damit die Aktivitäten einzelner Anwendungen innerhalb der Plattform leicht identifizieren und verfolgen können. :::note Es ist wichtig zu beachten, dass der _Anwendungsname_ sorgfältig gewählt werden sollte, da er für alle Benutzer sichtbar ist, die Zugriff auf die Admin-Konsole haben. Er sollte den Zweck und die Funktion der Anwendung genau widerspiegeln und gleichzeitig leicht verständlich und erkennbar sein. @@ -50,22 +54,22 @@ Es ist wichtig zu beachten, dass der _Anwendungsname_ sorgfältig gewählt werde ### Beschreibung \{#description} -Eine kurze Beschreibung der Anwendung wird auf der Detailseite der Anwendung in der Admin-Konsole angezeigt. Die Beschreibung soll Administratoren zusätzliche Informationen über die Anwendung geben, wie z. B. deren Zweck, Funktionalität und andere relevante Details. +Eine kurze Beschreibung der Anwendung wird auf der Detailseite der Anwendung in der Admin-Konsole angezeigt. Die Beschreibung soll Administratoren zusätzliche Informationen über die Anwendung geben, wie z. B. ihren Zweck, ihre Funktionalität und andere relevante Details. ### Redirect-URIs \{#redirect-uris} _Redirect-URIs_ sind eine Liste gültiger Redirect-URIs, die für eine Anwendung vorkonfiguriert wurden. Wenn sich ein Benutzer bei Logto anmeldet und versucht, auf die Anwendung zuzugreifen, wird er zu einer der in den Anwendungseinstellungen angegebenen erlaubten URIs weitergeleitet. -Die Liste der erlaubten URIs wird verwendet, um die Redirect-URI zu validieren, die in der Autorisierungsanfrage von der Anwendung an Logto während des Authentifizierungsprozesses gesendet wird. Wenn die in der Autorisierungsanfrage angegebene Redirect-URI mit einer der erlaubten URIs in den Anwendungseinstellungen übereinstimmt, wird der Benutzer nach erfolgreicher Authentifizierung zu dieser URI weitergeleitet. Wenn die Redirect-URI nicht auf der erlaubten Liste steht, wird der Benutzer nicht weitergeleitet und der Authentifizierungsprozess schlägt fehl. +Die Liste der erlaubten URIs wird verwendet, um die Redirect-URI zu validieren, die in der Autorisierungsanfrage enthalten ist, die von der Anwendung während des Authentifizierungsprozesses an Logto gesendet wird. Wenn die in der Autorisierungsanfrage angegebene Redirect-URI mit einer der erlaubten URIs in den Anwendungseinstellungen übereinstimmt, wird der Benutzer nach erfolgreicher Authentifizierung zu dieser URI weitergeleitet. Wenn die Redirect-URI nicht auf der erlaubten Liste steht, wird der Benutzer nicht weitergeleitet und der Authentifizierungsprozess schlägt fehl. :::note -Es ist wichtig sicherzustellen, dass alle gültigen Redirect-URIs zur erlaubten Liste einer Anwendung in Logto hinzugefügt werden, damit Benutzer nach der Authentifizierung erfolgreich auf die Anwendung zugreifen können. +Es ist wichtig sicherzustellen, dass alle gültigen Redirect-URIs zur erlaubten Liste für eine Anwendung in Logto hinzugefügt werden, damit Benutzer nach der Authentifizierung erfolgreich auf die Anwendung zugreifen können. ::: Weitere Informationen findest du beim [Redirection Endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2). - Redirect-URIs in OIDC mit Authorization Code Flow verstehen + Redirect-URIs im OIDC mit Authorization Code Flow verstehen #### Wildcard-Muster \{#wildcard-patterns} @@ -87,7 +91,7 @@ Redirect-URIs unterstützen Wildcard-Muster (`*`) für dynamische Umgebungen wie - `https://example.com/*/callback` – passt auf jedes Pfadsegment :::caution -Wildcard-Redirect-URIs sind kein Standard in OIDC und können die Angriffsfläche vergrößern. Verwende sie mit Bedacht und bevorzuge wann immer möglich exakte Redirect-URIs. +Wildcard-Redirect-URIs sind kein Standard-OIDC und können die Angriffsfläche vergrößern. Verwende sie mit Vorsicht und bevorzuge wann immer möglich exakte Redirect-URIs. ::: ### Post-Sign-out-Redirect-URIs \{#post-sign-out-redirect-uris} @@ -96,7 +100,7 @@ _Post-Sign-out-Redirect-URIs_ sind eine Liste gültiger URIs, die für eine Anwe Die Verwendung von erlaubten _Post-Sign-out-Redirect-URIs_ für Logout ist Teil der RP-Initiated (Relying Party Initiated) Logout-Spezifikation in OIDC. Diese Spezifikation bietet eine standardisierte Methode für Anwendungen, eine Logout-Anfrage für einen Benutzer zu initiieren, einschließlich der Weiterleitung des Benutzers zu einem vorkonfigurierten Endpunkt nach dem Abmelden. -Wenn sich ein Benutzer von Logto abmeldet, wird seine Sitzung beendet und er wird zu einer der in den Anwendungseinstellungen erlaubten URIs weitergeleitet. Dies stellt sicher, dass der Benutzer nur zu autorisierten und gültigen Endpunkten weitergeleitet wird, was dazu beiträgt, unbefugten Zugriff und Sicherheitsrisiken im Zusammenhang mit der Weiterleitung zu unbekannten oder nicht verifizierten Endpunkten zu verhindern. +Wenn sich ein Benutzer von Logto abmeldet, wird seine Sitzung beendet und er wird zu einer der in den Anwendungseinstellungen angegebenen erlaubten URIs weitergeleitet. Dies stellt sicher, dass der Benutzer nach dem Abmelden nur zu autorisierten und gültigen Endpunkten weitergeleitet wird, was dazu beiträgt, unbefugten Zugriff und Sicherheitsrisiken im Zusammenhang mit der Weiterleitung zu unbekannten oder nicht verifizierten Endpunkten zu verhindern. Weitere Informationen findest du beim [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout). @@ -104,10 +108,10 @@ Weitere Informationen findest du beim [RP-initiated logout](https://openid.net/s Die _CORS (Cross-Origin Resource Sharing) erlaubten Ursprünge_ sind eine Liste von erlaubten Ursprüngen, von denen eine Anwendung Anfragen an den Logto-Dienst stellen kann. Jeder Ursprung, der nicht in der erlaubten Liste enthalten ist, kann keine Anfragen an den Logto-Dienst stellen. -Die Liste der erlaubten Ursprünge wird verwendet, um den Zugriff auf den Logto-Dienst von nicht autorisierten Domains einzuschränken und um Cross-Site-Request-Forgery (CSRF)-Angriffe zu verhindern. Durch die Angabe der erlaubten Ursprünge für eine Anwendung in Logto kann der Dienst sicherstellen, dass nur autorisierte Domains Anfragen an den Dienst stellen können. +Die Liste der erlaubten Ursprünge wird verwendet, um den Zugriff auf den Logto-Dienst von nicht autorisierten Domains einzuschränken und Cross-Site-Request-Forgery (CSRF)-Angriffe zu verhindern. Durch die Angabe der erlaubten Ursprünge für eine Anwendung in Logto kann der Dienst sicherstellen, dass nur autorisierte Domains Anfragen an den Dienst stellen können. :::note -Die Liste der erlaubten Ursprünge sollte den Ursprung enthalten, unter dem die Anwendung bereitgestellt wird. So wird sichergestellt, dass Anfragen von der Anwendung erlaubt sind, während Anfragen von nicht autorisierten Ursprüngen blockiert werden. +Die Liste der erlaubten Ursprünge sollte den Ursprung enthalten, unter dem die Anwendung bereitgestellt wird. Dies stellt sicher, dass Anfragen von der Anwendung erlaubt sind, während Anfragen von nicht autorisierten Ursprüngen blockiert werden. ::: ### OpenID Provider-Konfigurationsendpunkt \{#openid-provider-configuration-endpoint} @@ -116,7 +120,7 @@ Der Endpunkt für [OpenID Connect Discovery](https://openid.net/specs/openid-con ### Autorisierungsendpunkt \{#authorization-endpoint} -_Autorisierungsendpunkt_ ist ein OIDC-Begriff und ein erforderlicher Endpunkt, der verwendet wird, um den Authentifizierungsprozess für einen Benutzer zu starten. Wenn ein Benutzer versucht, auf eine geschützte Ressource oder Anwendung zuzugreifen, die bei der Logto-Plattform registriert ist, wird er zum _Autorisierungsendpunkt_ weitergeleitet, um seine Identität zu authentifizieren und die Autorisierung für den Zugriff auf die angeforderte Ressource zu erhalten. +_Autorisierungsendpunkt_ ist ein OIDC-Begriff und ein erforderlicher Endpunkt, der verwendet wird, um den Authentifizierungsprozess für einen Benutzer zu starten. Wenn ein Benutzer versucht, auf eine geschützte Ressource oder Anwendung zuzugreifen, die bei der Logto-Plattform registriert ist, wird er zum _Autorisierungsendpunkt_ weitergeleitet, um seine Identität zu authentifizieren und die Autorisierung zum Zugriff auf die angeforderte Ressource zu erhalten. Weitere Informationen findest du beim [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). @@ -138,7 +142,7 @@ _Verfügbarkeit: Traditionelle Web, SPA_ Wenn aktiviert, stellt Logto immer Auffrischungstokens aus, unabhängig davon, ob `prompt=consent` in der Authentifizierungsanfrage angegeben ist oder `offline_access` in den Berechtigungen enthalten ist. -Diese Praxis wird jedoch nicht empfohlen, es sei denn, sie ist notwendig (in der Regel nützlich für einige OAuth-Integrationen von Drittanbietern, die ein Auffrischungstoken erfordern), da sie nicht mit OpenID Connect kompatibel ist und potenziell Probleme verursachen kann. +Diese Praxis wird jedoch nicht empfohlen, es sei denn, sie ist notwendig (in der Regel ist sie für einige OAuth-Integrationen von Drittanbietern nützlich, die ein Auffrischungstoken erfordern), da sie nicht mit OpenID Connect kompatibel ist und potenziell Probleme verursachen kann. ### Auffrischungstoken rotieren \{#rotate-refresh-token} @@ -148,7 +152,7 @@ Wenn aktiviert, kann Logto ein neues Auffrischungstoken ausstellen, wenn ein Cli - Auffrischungstokens können nur rotiert werden, bevor die Auffrischungstoken-Kette seit einem Jahr besteht. Dies ist eine interne Rotationssicherheitsgrenze; die eigene TTL des Auffrischungstokens oder die App-Grant-TTL kann früher ablaufen. Nach Erreichen der Grenze rotiert Logto das Auffrischungstoken nicht mehr und das aktuelle Ablaufdatum des Auffrischungstokens ist endgültig. - Für öffentliche Clients, die keine sender-constrained Auffrischungstokens verwenden (z. B. reguläre Native-Anwendungen und Single Page Applications), rotiert Logto das Auffrischungstoken bei jeder Auffrischungstoken-Anfrage, solange die Rotation erlaubt ist. -- Für andere Clients rotiert Logto das Auffrischungstoken nur, wenn es kurz vor dem Ablauf steht (>=70% seiner ursprünglichen Lebensdauer (TTL) sind vergangen). +- Für andere Clients rotiert Logto das Auffrischungstoken nur, wenn es kurz vor dem Ablauf steht (>=70 % seiner ursprünglichen Lebensdauer (TTL) sind vergangen). :::note Für öffentliche Clients wird dringend empfohlen, die Auffrischungstoken-Rotation aus Sicherheitsgründen aktiviert zu lassen. @@ -157,7 +161,7 @@ Sender-constrained Auffrischungstokens sind an einen vom Client gehaltenen Proof ::: :::caution Lebensdauer der Auffrischungstoken-Kette -Auffrischungstokens sind mit einem App-Grant verknüpft. Die Standard-Grant-TTL von Logto beträgt **180 Tage**. Wenn der Grant abläuft, schlagen Auffrischungstoken-Anfragen fehl und das Auffrischungstoken kann nicht mehr verwendet werden, um neue Tokens zu erhalten, selbst wenn die Auffrischungstoken-Rotation aktiviert ist. +Auffrischungstokens sind mit einem App-Grant verknüpft. Die Standard-Logto-Grant-TTL beträgt **180 Tage**. Wenn der Grant abläuft, schlagen Auffrischungstoken-Anfragen fehl und das Auffrischungstoken kann nicht mehr verwendet werden, um neue Tokens zu erhalten, selbst wenn die Auffrischungstoken-Rotation aktiviert ist. Das bedeutet, dass die praktische maximale Lebensdauer einer auf Auffrischungstoken basierenden Autorisierung derzeit durch die Grant-TTL, explizite Widerrufung oder das eigene Ablaufdatum des Auffrischungstokens begrenzt ist – je nachdem, was zuerst eintritt. ::: @@ -172,22 +176,22 @@ _Verfügbarkeit: Native App, Traditionelle Web, SPA; Standard: 14 Tage; Maximum: Die Dauer, für die ein Auffrischungstoken verwendet werden kann, um neue Zugangstokens anzufordern, bevor es abläuft und ungültig wird. Token-Anfragen verlängern die TTL des Auffrischungstokens auf diesen Wert. -In der Regel wird ein niedrigerer Wert bevorzugt. +Typischerweise wird ein niedrigerer Wert bevorzugt. :::note TTL-Aktualisierung ist in Single Page Applications (SPAs) aus Sicherheitsgründen nicht verfügbar. Für SPAs steuert diese Einstellung die feste Lebensdauer des Auffrischungstokens ab dem ursprünglichen Ausstellungszeitpunkt. Logto verlängert die TTL nicht durch Token-Anfragen, und die Auffrischungstoken-Rotation verhindert nicht das Ablaufen von SPA-Auffrischungstokens. ::: :::caution Auffrischungstoken-TTL und Grant-TTL -Die Auffrischungstoken-TTL ist nicht das einzige Ablauf-Limit. Auffrischungstokens sind an einen App-Grant gebunden, und die Standard-Grant-TTL von Logto beträgt **180 Tage**. Wenn der Grant abläuft, schlagen Auffrischungstoken-Anfragen fehl, auch wenn das Auffrischungstoken ansonsten noch gültig wäre. +Die Auffrischungstoken-TTL ist nicht das einzige Ablaufkriterium. Auffrischungstokens sind an einen App-Grant gebunden, und die Standard-Logto-Grant-TTL beträgt **180 Tage**. Wenn der Grant abläuft, schlagen Auffrischungstoken-Anfragen fehl, auch wenn das Auffrischungstoken ansonsten noch gültig wäre. Für Clients, bei denen Token-Anfragen die Auffrischungstoken-TTL aktualisieren, fungiert die Grant-TTL als absolute maximale Lebensdauer für die Auffrischungstoken-Kette. Für SPAs kann die feste TTL des Auffrischungstokens vor dem Grant ablaufen. ::: -:::caution Auffrischungstoken- und Sitzungsbindung -Wenn ein Auffrischungstoken **ohne** den `offline_access` Scope in der Autorisierungsanfrage ausgestellt wird, ist es an die Benutzersitzung gebunden. Die Sitzung hat eine feste TTL von **14 Tagen**. Nach Ablauf der Sitzung wird das Auffrischungstoken unabhängig von seiner eigenen TTL-Einstellung ungültig. +:::caution Auffrischungstoken und Sitzungsbindung +Wenn ein Auffrischungstoken **ohne** die Berechtigung `offline_access` in der Autorisierungsanfrage ausgestellt wird, ist es an die Benutzersitzung gebunden. Die Sitzung hat eine feste TTL von **14 Tagen**. Nach Ablauf der Sitzung wird das Auffrischungstoken unabhängig von seiner eigenen TTL-Einstellung ungültig. -Um sicherzustellen, dass die Auffrischungstoken-TTL-Einstellung vollständig wirksam ist, stelle sicher, dass du den `offline_access` Scope in deiner Autorisierungsanfrage einschließt. +Um sicherzustellen, dass die Auffrischungstoken-TTL-Einstellung vollständig wirksam ist, stelle sicher, dass du die Berechtigung `offline_access` in deiner Autorisierungsanfrage einschließt. ::: ### Backchannel-Logout-URI \{#backchannel-logout-uri} @@ -201,7 +205,7 @@ Der OpenID Connect Backchannel-Logout-Endpunkt. Siehe [Federated sign-out: Back- - **Standard**: `undefined` (kein Limit) - **Wenn konfiguriert**: Bei jeder erfolgreichen Autorisierung prüft Logto die Gesamtzahl aktiver Grants für den Benutzer in der aktuellen App (über Browser und Geräte hinweg). Wenn das Limit überschritten wird, widerruft Logto die ältesten Grants. -Diese Einstellung ist nützlich, wenn du die gleichzeitigen authentifizierten Geräte pro App begrenzen möchtest. +Diese Einstellung ist nützlich, wenn du gleichzeitige authentifizierte Geräte pro App begrenzen möchtest. Jede Ausweisung löst das `Grant.LimitExceeded` [Webhook-Ereignis](/developers/webhooks/webhooks-events#exception-hook-events) aus, sodass du den Benutzer benachrichtigen oder verfolgen kannst, wie oft das Limit erreicht wird. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 82ba21078fa..f8cba7daf27 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,42 +4,50 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; # Drittanbieter-App (OAuth / OIDC) -Die Integration von Drittanbieteranwendungen in Logto ermöglicht es dir, Logto als [Identitätsanbieter (IdP)](https://auth.wiki/identity-provider) für externe Anwendungen zu nutzen. +Die Drittanbieteranwendungsintegration von Logto ermöglicht es dir, Logto als [Identitätsanbieter (IdP)](https://auth.wiki/identity-provider) für externe Anwendungen zu nutzen. Ein Identitätsanbieter (IdP) ist ein Dienst, der Benutzeridentitäten überprüft und deren Anmeldedaten verwaltet. Nach der Bestätigung der Identität eines Benutzers generiert der IdP Authentifizierungstoken oder Assertions und ermöglicht dem Benutzer den Zugriff auf verschiedene Anwendungen oder Dienste, ohne sich erneut anmelden zu müssen. Im Gegensatz zu den Anwendungen, die du im Leitfaden [Logto in deine Anwendung integrieren](/integrate-logto/integrate-logto-into-your-application) erstellt hast und die von dir entwickelt und vollständig kontrolliert werden, sind Drittanbieteranwendungen unabhängige Dienste, die von externen Entwicklern oder Geschäftspartnern entwickelt werden. -Dieser Integrationsansatz eignet sich hervorragend für gängige Geschäftsszenarien. Du kannst es Benutzern ermöglichen, auf Partneranwendungen mit ihren Logto-Konten zuzugreifen, ähnlich wie Unternehmensbenutzer sich bei Slack mit Google Workspace anmelden. Du kannst auch eine offene Plattform aufbauen, auf der Drittanbieteranwendungen die Funktion „Mit Logto anmelden“ hinzufügen können, ähnlich wie „Mit Google anmelden“. +Dieser Integrationsansatz eignet sich hervorragend für gängige Geschäftsszenarien. Du kannst es deinen Nutzern ermöglichen, Partneranwendungen mit ihren Logto-Konten zu nutzen – ähnlich wie Unternehmensnutzer sich bei Slack mit Google Workspace anmelden. Du kannst auch eine offene Plattform aufbauen, auf der Drittanbieteranwendungen eine „Mit Logto anmelden“-Funktion hinzufügen können, ähnlich wie „Mit Google anmelden“. -Logto ist ein Identitätsdienst, der auf dem [OpenID Connect (OIDC)](https://auth.wiki/openid-connect)-Protokoll basiert und sowohl [Authentifizierung (Authentication)](https://auth.wiki/authentication) als auch [Autorisierung (Authorization)](https://auth.wiki/authorization) bereitstellt. Dadurch ist die Integration einer OIDC-Drittanbieteranwendung genauso unkompliziert wie bei einer traditionellen Webanwendung. +Logto ist ein Identitätsdienst, der auf dem [OpenID Connect (OIDC)](https://auth.wiki/openid-connect)-Protokoll basiert und sowohl [Authentifizierung (Authentication)](https://auth.wiki/authentication) als auch [Autorisierung (Authorization)](https://auth.wiki/authorization) bereitstellt. Dadurch ist die Integration einer OIDC-Drittanbieteranwendung genauso einfach wie bei einer klassischen Webanwendung. Da OIDC auf [OAuth 2.0](https://auth.wiki/oauth-2.0) aufbaut und eine Authentifizierungsschicht hinzufügt, kannst du Drittanbieteranwendungen auch über das OAuth-Protokoll integrieren. -## Drittanbieteranwendung in Logto erstellen \{#create-a-third-party-application-in-logto} +## Zwei Wege, eine Drittanbieter-App anzubinden \{#two-ways-to-onboard-a-third-party-app} + +- **Registriere die App in Logto** (dieser Leitfaden): Du erstellst die Anwendung und konfigurierst deren Berechtigungen und Weiterleitungs-URIs. Verwende dies, wenn du deine Partner kennst. +- **[Dynamische App](/integrate-logto/third-party-applications/dynamic-apps)**: Clients verbinden sich ohne vorherige Registrierung, indem sie eine öffentliche HTTPS-URL verwenden, die ihr eigenes Metadaten-Dokument als Client-ID bereitstellt. Verwende dies, wenn sich beliebige Clients verbinden können, z. B. MCP-Clients und KI-Agenten. + +Beide Methoden können gleichzeitig verwendet werden. + +## Erstelle eine Drittanbieteranwendung in Logto \{#create-a-third-party-application-in-logto} 1. Gehe zu Konsole > Anwendungen. 2. Klicke auf die Schaltfläche „Anwendung erstellen“. Wähle „Drittanbieter-App“ als Anwendungstyp und eines der folgenden Integrationsprotokolle: - OIDC / OAuth 3. Wähle einen Anwendungstyp basierend auf dem Typ der Drittanbieteranwendung: - - **Traditionelle Webanwendung**: Serverseitig gerenderte Anwendungen (z. B. Node.js, PHP, Java), die ein Client-Geheimnis sicher im Backend speichern können. + - **Traditionelles Web**: Serverseitig gerenderte Anwendungen (z. B. Node.js, PHP, Java), die ein Client-Geheimnis sicher im Backend speichern können. - **Single Page App (SPA)**: Clientseitig gerenderte Anwendungen (z. B. React, Vue, Angular), die vollständig im Browser laufen und keine Geheimnisse sicher speichern können. - **Native**: Mobile oder Desktop-Anwendungen (z. B. iOS, Android, Electron), die auf Benutzergeräten laufen. -4. Gib einen Namen und eine Beschreibung für deine Anwendung ein und klicke auf „Erstellen“. Eine neue Drittanbieteranwendung wird erstellt. +4. Gib einen Namen und eine Beschreibung für deine Anwendung ein und klicke auf „Erstellen“. Es wird eine neue Drittanbieteranwendung erstellt. -Alle erstellten Drittanbieteranwendungen werden auf der Anwendungsseite unter dem Tab „Drittanbieter-Apps“ katalogisiert. Diese Anordnung hilft dir, sie von deinen eigenen Anwendungen zu unterscheiden und alle Anwendungen an einem Ort zu verwalten. +Alle erstellten Drittanbieteranwendungen werden auf der Seite „Anwendungen“ unter dem Tab „Drittanbieter-Apps“ katalogisiert. Diese Anordnung hilft dir, sie von deinen eigenen Anwendungen zu unterscheiden und alle Anwendungen an einem Ort zu verwalten. -Um einzuschränken, welche Benutzer sich bei einer Drittanbieteranwendung anmelden können, konfiguriere die [App-Ebene Zugangskontrolle](/authorization/app-level-access-control) im Tab **Regeln** der Anwendung. +Um einzuschränken, welche Benutzer sich bei einer Drittanbieteranwendung anmelden können, konfiguriere die [App-spezifische Zugangskontrolle](/authorization/app-level-access-control) im Tab **Regeln** der Anwendung. -## Integrationsanleitung \{#integration-guide} +## Integrationsleitfaden \{#integration-guide} -### Anwendungskonfigurationen finden \{#find-the-application-configurations} +### Finde die Anwendungskonfigurationen \{#find-the-application-configurations} Auf der Detailseite der Anwendung findest du die [**Client-ID**](/integrate-logto/application-data-structure#application-id), das [**Client-Geheimnis**](/integrate-logto/application-data-structure#application-secret) (nur für traditionelle Webanwendungen) und die OIDC-Endpunkte, die für die Integration benötigt werden. @@ -47,35 +55,35 @@ Wenn der Drittanbieterdienst OIDC-Discovery unterstützt, gib einfach den **Disc ### Integration mit Diensten, die Drittanbieter-IdP unterstützen \{#integrate-with-services-that-support-third-party-idp} -Wenn du einen Dienst oder ein Produkt verbindest, das die Konfiguration eines externen Identitätsanbieters nativ unterstützt (z. B. Enterprise-SaaS-Plattformen, Kollaborationstools), ist die Einrichtung unkompliziert: +Wenn du einen Dienst oder ein Produkt verbindest, das nativ die Konfiguration eines externen Identitätsanbieters unterstützt (z. B. Enterprise-SaaS-Plattformen, Kollaborationstools), ist die Einrichtung unkompliziert: 1. Öffne die IdP- oder SSO-Konfigurationsseite des Dienstes. 2. Kopiere die **Client-ID** (und das **Client-Geheimnis**, falls erforderlich) aus Logto und füge sie in die Konfiguration des Dienstes ein. -3. Gib den **Discovery-Endpunkt** an, wenn der Dienst OIDC-Auto-Discovery unterstützt, oder kopiere manuell den **Autorisierungsendpunkt** und den **Token-Endpunkt**. +3. Gib den **Discovery-Endpunkt** an, wenn der Dienst OIDC-Auto-Discovery unterstützt, oder kopiere manuell den **Autorisierungsendpunkt** und **Token-Endpunkt**. 4. Kopiere die **Redirect-URI** von der Konfigurationsseite des Dienstes und füge sie zu den erlaubten Redirect-URIs deiner Logto-Anwendung hinzu. -5. Konfiguriere die **Berechtigungen (scopes)**, falls der Dienst dies zulässt. Da Logto ein OIDC-Anbieter ist, füge den `openid`-Scope hinzu, wenn du Benutzer authentifizieren möchtest (gewährt Zugriff auf ein ID-Token und den UserInfo-Endpunkt). Der `openid`-Scope ist optional, wenn du nur OAuth-Ressourcenzugriff benötigst. +5. Konfiguriere die **Scopes**, falls der Dienst dies zulässt. Da Logto ein OIDC-Anbieter ist, füge den `openid`-Scope hinzu, wenn du Benutzer authentifizieren möchtest (gewährt Zugriff auf ein ID-Token und den UserInfo-Endpunkt). Der `openid`-Scope ist optional, wenn du nur OAuth-Ressourcenzugriff benötigst. -Der Dienst übernimmt den OAuth / OIDC-Flow automatisch, sobald die Konfiguration abgeschlossen ist. +Der Dienst übernimmt den OAuth / OIDC-Flow automatisch, sobald er konfiguriert ist. ### Integration über OAuth / OIDC-Protokoll \{#integrate-via-oauth-protocol} -Wenn eine Drittanbieteranwendung programmgesteuert mit Logto als IdP integriert werden soll, sollte sie den Standard-[Autorisierungscode-Flow](https://auth.wiki/authorization-code-flow) implementieren. Wir empfehlen, eine OAuth 2.0 / OIDC-Clientbibliothek für deine Programmiersprache zu verwenden, um die Implementierung zu erleichtern. +Wenn eine Drittanbieteranwendung sich programmatisch mit Logto als IdP integrieren muss, sollte sie den Standard-[Authorization Code Flow](https://auth.wiki/authorization-code-flow) implementieren. Wir empfehlen, eine OAuth 2.0 / OIDC-Clientbibliothek für deine Programmiersprache zu verwenden, um die Implementierung zu erleichtern. - + -Traditionelle Webanwendungen sind **vertrauliche Clients**, die ein Client-Geheimnis sicher auf dem Backend-Server speichern können. Siehe [Autorisierungscode-Flow](https://auth.wiki/authorization-code-flow) für vollständige Implementierungsdetails. +Traditionelle Webanwendungen sind **vertrauliche Clients**, die ein Client-Geheimnis sicher auf dem Backend-Server speichern können. Siehe [Authorization Code Flow](https://auth.wiki/authorization-code-flow) für vollständige Implementierungsdetails. **Wichtige Schritte:** -1. **Autorisierung initiieren**: Benutzer zum Logto-Autorisierungsendpunkt mit `client_id`, `redirect_uri`, `response_type=code` und `scope` weiterleiten. +1. **Autorisierung initiieren**: Benutzer zum Autorisierungsendpunkt von Logto weiterleiten mit `client_id`, `redirect_uri`, `response_type=code` und `scope`. 2. **Callback verarbeiten**: Den Autorisierungscode (`code`) aus der Weiterleitung empfangen. 3. **Token austauschen**: Vom Backend aus einen POST an den Token-Endpunkt mit dem Code, `client_id` und `client_secret` senden. -Single Page Apps und Native Apps sind **öffentliche Clients**, die keine Geheimnisse sicher speichern können. Statt eines Client-Geheimnisses müssen diese Anwendungen [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) für eine sichere Autorisierung verwenden. Siehe [Autorisierungscode-Flow](https://auth.wiki/authorization-code-flow) und [PKCE](https://auth.wiki/pkce) für vollständige Implementierungsdetails. +Single Page Apps und Native Apps sind **öffentliche Clients**, die keine Geheimnisse sicher speichern können. Statt eines Client-Geheimnisses müssen diese Anwendungen [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) für eine sichere Autorisierung verwenden. Siehe [Authorization Code Flow](https://auth.wiki/authorization-code-flow) und [PKCE](https://auth.wiki/pkce) für vollständige Implementierungsdetails. **Wichtige Schritte:** @@ -89,12 +97,12 @@ Single Page Apps und Native Apps sind **öffentliche Clients**, die keine Geheim ### Integration über Device Flow \{#integrate-via-device-flow} -Für native Drittanbieteranwendungen, die auf Geräten mit eingeschränkter Eingabe laufen (z. B. Smart-TVs, Spielkonsolen, CLI-Tools), ist der standardmäßige, umleitungsbasierte Autorisierungscode-Flow möglicherweise nicht praktikabel. In diesen Fällen kann die Anwendung stattdessen den [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) verwenden. +Für native Drittanbieteranwendungen, die auf gerätebeschränkten Geräten laufen (z. B. Smart-TVs, Spielkonsolen, CLI-Tools), ist der standardmäßige, weiterleitungsbasierte Authorization Code Flow möglicherweise nicht praktikabel. In diesen Fällen kann die Anwendung stattdessen den [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) verwenden. -Beim Device Flow zeigt das Gerät einen Benutzercode und eine Verifizierungs-URL an. Der Benutzer besucht die URL auf einem separaten Gerät (Handy, Laptop), gibt den Code ein und schließt die Authentifizierung dort ab. Das Gerät fragt den Token-Endpunkt von Logto ab, bis die Autorisierung abgeschlossen ist. +Beim Device Flow zeigt das Gerät einen Benutzer-Code und eine Verifizierungs-URL an. Der Benutzer besucht die URL auf einem separaten Gerät (Handy, Laptop), gibt den Code ein und schließt die Authentifizierung dort ab. Das Gerät fragt den Token-Endpunkt von Logto ab, bis die Autorisierung abgeschlossen ist. :::note -Bevor du den Device Flow implementierst, stelle sicher, dass du die erforderlichen [Berechtigungen](/integrate-logto/third-party-applications/permission-management) für deine Drittanbieteranwendung in der Logto-Konsole konfiguriert hast. Drittanbieter-Apps, die nicht aktivierte Berechtigungen anfordern, wird der Zugriff verweigert. +Bevor du den Device Flow implementierst, stelle sicher, dass du die erforderlichen [Berechtigungen](/integrate-logto/third-party-applications/permission-management) für deine Drittanbieteranwendung in der Logto-Konsole konfiguriert hast. Drittanbieter-Apps, die nicht aktivierte Scopes anfordern, wird der Zugriff verweigert. ::: Siehe den [Device Flow Quick Start](/quick-starts/device-flow) für vollständige Implementierungsdetails. @@ -103,15 +111,15 @@ Siehe den [Device Flow Quick Start](/quick-starts/device-flow) für vollständig Aus Sicherheitsgründen werden alle OIDC-Drittanbieteranwendungen nach der Authentifizierung durch Logto zu einem [Zustimmungsbildschirm](/end-user-flows/consent-screen) für die Benutzerautorisierung weitergeleitet. -Alle von der Drittanbieteranwendung angeforderten [Berechtigungen für Benutzerprofile](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes), [API-Ressourcen-Berechtigungen](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [Organisationsberechtigungen](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) und Informationen zur Organisationsmitgliedschaft werden auf dem Zustimmungsbildschirm angezeigt. +Alle von der Drittanbieteranwendung angeforderten [Berechtigungen für Benutzerprofile](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes), [API-Ressourcen-Berechtigungen](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [Organisationsberechtigungen](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) und Organisationsmitgliedschaftsinformationen werden auf dem Zustimmungsbildschirm angezeigt. Diese angeforderten Berechtigungen werden den Drittanbieteranwendungen erst gewährt, nachdem der Benutzer auf die Schaltfläche „Autorisieren“ geklickt hat.
- Zustimmungsbildschirm + consent screen
-## Weitere Aktionen \{#further-actions} +## Weitere Schritte \{#further-actions} , }, }, + { + type: 'link', + label: 'Dynamische App (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + 'Erlaube OAuth-Clients die Verbindung ohne vorherige Registrierung, indem sie eine Client-ID-Metadaten-Dokument-URL als ihre Client-ID verwenden.', + customProps: { + icon: , + }, + }, ]} /> @@ -147,20 +165,20 @@ Diese angeforderten Berechtigungen werden den Drittanbieteranwendungen erst gew -Logto verwendet rollenbasierte Zugangskontrolle (RBAC), um Benutzerberechtigungen zu verwalten. Auf dem Zustimmungsbildschirm werden nur Berechtigungen (Scopes) angezeigt, die dem Benutzer bereits über seine Rollen zugewiesen wurden. Wenn eine Drittanbieter-App Berechtigungen anfordert, die der Benutzer nicht besitzt, werden diese ausgeschlossen, um eine unbefugte Zustimmung zu verhindern. +Logto verwendet rollenbasierte Zugangskontrolle (RBAC), um Benutzerberechtigungen zu verwalten. Auf dem Zustimmungsbildschirm werden nur Scopes (Berechtigungen) angezeigt, die dem Benutzer bereits durch seine Rollen zugewiesen wurden. Wenn eine Drittanbieter-App Scopes anfordert, die der Benutzer nicht besitzt, werden diese ausgeschlossen, um eine unbefugte Zustimmung zu verhindern. So verwaltest du dies: -- Definiere [globale Rollen](/authorization/role-based-access-control) oder [Organisationsrollen](/authorization/organization-template) mit spezifischen Berechtigungen. +- Definiere [globale Rollen](/authorization/role-based-access-control) oder [Organisationsrollen](/authorization/organization-template) mit bestimmten Scopes. - Weisen Sie Benutzern Rollen entsprechend ihrem Zugriffsbedarf zu. -- Benutzer erben die Berechtigungen automatisch von ihren Rollen. +- Benutzer erben die Scopes automatisch von ihren Rollen. ## Verwandte Ressourcen \{#related-resources} - Anwendungsfall: Apache Answer integrieren, um eine Community für deine Benutzer zu starten + Anwendungsfall: Apache Answer integrieren, um eine Community für deine Nutzer zu starten diff --git a/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..a598b0f09fd --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,99 @@ +--- +description: OAuth-Clients ermöglichen, sich ohne vorherige Registrierung mit deinem Mandanten zu verbinden, indem sie eine Client-ID-Metadaten-Dokument-URL als ihre Client-ID verwenden. +sidebar_label: Dynamische App (CIMD) +sidebar_position: 3 +--- + +# Dynamische App (CIMD) + +Die dynamische App ermöglicht es OAuth-Clients, sich ohne vorherige Registrierung mit deinem Mandanten zu verbinden. Anstelle einer von Logto ausgegebenen Client-ID verwendet der Client eine öffentliche HTTPS-URL als sein `client_id`. Die URL dient als JSON-Dokument, das den Client beschreibt und als [Client-ID-Metadaten-Dokument (CIMD)](https://auth.wiki/client-id-metadata-document) bezeichnet wird. Logto ruft das Dokument ab und behandelt den Client als [Drittanbieteranwendung](/integrate-logto/third-party-applications). + +Die dynamische App implementiert den IETF-Entwurf [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html). + +## Wann sollte die dynamische App verwendet werden \{#when-to-use-dynamic-app} + +Die Vorabregistrierung funktioniert, wenn du deine Partner kennst. Sie funktioniert nicht, wenn sich beliebige Clients verbinden können, was im [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents)-Ökosystem üblich ist: Ein Benutzer bittet seinen KI-Agenten, sich mit deinem Dienst zu verbinden, und der Agent hat noch nie zuvor mit deinem Mandanten kommuniziert. + +Mit der dynamischen App veröffentlicht der Client seine eigenen Metadaten unter einer von ihm kontrollierten URL, und diese URL ist seine Identität. Es muss im Vorfeld nichts in deinem Mandanten erstellt werden. + +| | Registrierte Drittanbieter-App | Dynamische App | +| -------------- | ------------------------------ | ----------------------------------------------- | +| Client-ID | Von Logto ausgegeben | Eine vom Client kontrollierte HTTPS-URL | +| Registrierung | Erforderlich | Nicht erforderlich | +| Client-Secret | Unterstützt | Nicht unterstützt | +| Berechtigungen | Pro Anwendung | Von allen dynamischen Clients gemeinsam genutzt | +| Grant-Typen | Abhängig vom App-Typ | `authorization_code` und `refresh_token` | + +Dynamische Clients sind öffentliche Clients und verwenden daher immer [PKCE](https://auth.wiki/pkce). Du kannst beide Modelle gleichzeitig verwenden. Ein Partner, dem du vertraust, kann weiterhin eine registrierte App mit eigenen Berechtigungen haben. + +## Dynamische App aktivieren \{#enable-dynamic-app} + +1. Gehe zu Konsole > Anwendungen und öffne den Tab **Drittanbieter-Apps**. +2. Klicke auf **Anwendung erstellen** und wähle die Karte **Dynamische App** aus. Dadurch wird eine mandantenweite Funktion aktiviert, anstatt eine Anwendung zu erstellen. +3. Bestätige im Dialog. Sobald aktiviert, kann jeder OAuth-Client mit einer gültigen öffentlichen HTTPS-Client-ID-URL eine Autorisierungsanfrage für deinen Mandanten starten. +4. Öffne die dynamische App aus der Anwendungsliste und gehe zum Tab **Berechtigungen**, um Berechtigungen zu vergeben. + +Die dynamische App hat keinen editierbaren Namen, keine Redirect-URIs oder Zugangsdaten. Jeder Client gibt diese in seinem Metadaten-Dokument an. + +:::note +Die dynamische App erfordert den [OIDC-Provider-SSRF-Schutz](/concepts/core-service/configuration#oidc-provider-ssrf-protection), da Logto Metadaten-Dokumente aus dem Internet abruft. Selbstgehostete Instanzen, die diesen Schutz deaktivieren, können die dynamische App nicht aktivieren. +::: + +### Berechtigungen vergeben \{#grant-permissions} + +Der Tab **Berechtigungen** definiert die maximalen Berechtigungen, die von allen dynamischen Clients gemeinsam genutzt werden. Er funktioniert wie das [Berechtigungsmanagement](/integrate-logto/third-party-applications/permission-management) einer registrierten Drittanbieter-App, mit den Abschnitten **Benutzer** und **Organisation**. + +Das Anfordern einer Benutzerberechtigung, die nicht gewährt wurde, führt zu einem Fehler, während API-Ressourcen- und Organisationsberechtigungen, die nicht gewährt wurden, ignoriert werden. Benutzer stimmen auch nur den Berechtigungen zu, die sie durch ihre [Rollen](/authorization/role-based-access-control) haben. + +Da jeder dynamische Client diesen Satz teilt, halte ihn möglichst minimal. + +## Ein Client-ID-Metadaten-Dokument veröffentlichen \{#publish-a-client-id-metadata-document} + +Wenn du einen Client entwickelst, der sich mit Logto verbindet, hoste ein Metadaten-Dokument und verwende dessen URL als dein `client_id`. Die URL muss das `https`-Schema verwenden und darf kein Fragment, keine Benutzerinformationen oder Punkt-Pfadsegmente enthalten. Logto sendet eine `GET`-Anfrage an die URL und erwartet ein JSON-Objekt. + +Zum Beispiel verwendet Claude Code `https://claude.ai/oauth/claude-code-client-metadata`, das folgendes bereitstellt: + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +Die Feldnamen entsprechen denen in [OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591#section-2). Beachte dabei: + +- `client_id` muss identisch mit der URL sein, unter der das Dokument bereitgestellt wird. +- Dynamische Clients sind öffentliche Clients. Das Dokument darf kein `client_secret` enthalten und `token_endpoint_auth_method` darf keine Shared-Secret-Methode sein. Verwende stattdessen [PKCE](https://auth.wiki/pkce). +- Metadaten-URIs wie `client_uri`, `logo_uri`, `tos_uri` und `policy_uri` müssen absolute `https`-URLs sein. Dies gilt nicht für `redirect_uris`, sodass native Clients weiterhin Loopback-Adressen wie im obigen Beispiel verwenden können. +- `redirect_uris` werden als exakte Zeichenfolgen abgeglichen, außer dass Loopback-Adressen mit jedem Port abgeglichen werden können. [Wildcard-Muster](/integrate-logto/application-data-structure#wildcard-patterns) werden ebenfalls unterstützt. +- `scope`, `grant_types` und `response_types` werden von Logto festgelegt. Falls das Dokument sie deklariert, werden die Werte ignoriert. Dynamische Clients können nur den Authorization-Code-Flow und Auffrischungstokens verwenden. + +Logto cached das Dokument bis zu 24 Stunden lang, entsprechend den `Cache-Control`- und `Expires`-Headern deiner Antwort. Setze diese entsprechend der erwarteten Aktualisierungshäufigkeit des Dokuments. + +## Zustimmungsbildschirm \{#consent-screen} + +Dynamische Clients sind Drittanbieteranwendungen, daher wird der [Zustimmungsbildschirm](/end-user-flows/consent-screen) immer angezeigt. + +Der Zustimmungsbildschirm zeigt außerdem einen Hinweis an, dass der Client nicht registriert ist. Der Clientname und das Logo stammen aus dem Metadaten-Dokument, sodass sie jede Marke imitieren können. Der Host der Client-ID-URL wird ebenfalls angezeigt, da dies der einzige Teil ist, den der Client nicht fälschen kann. + +## Autorisierungen verwalten \{#manage-authorizations} + +Autorisierungen, die dynamischen Clients gewährt werden, sind reguläre Drittanbieter-[Grants](/sessions/grants-management). Benutzer können sie in den Kontoeinstellungen überprüfen und widerrufen, und Administratoren können sie über die Management API verwalten. Die Client-ID-URL dient zur Identifizierung des Clients. + +Das Deaktivieren der dynamischen App stoppt neue Autorisierungsanfragen, während bestehende Grants erhalten bleiben. Das Widerrufen eines Grants erfordert, dass der Client erneut eine Benutzerautorisierung einholt, aber zuvor ausgestellte Zugangstokens können bis zu ihrem Ablauf gültig bleiben. + +## Einschränkungen \{#limitations} + +- Es werden nur der Authorization-Code-Flow mit PKCE und Auffrischungstokens unterstützt. Client-Credentials, Device-Flow und Token-Austausch sind nicht verfügbar. +- Berechtigungen und Branding können nicht pro Client konfiguriert werden. +- [App-Ebene Zugangskontrolle](/authorization/app-level-access-control) gilt nicht für dynamische Clients, da sie keinen Anwendungsdatensatz haben. + +## Verwandte Ressourcen \{#related-resources} + +Drittanbieter-App (OAuth / OIDC) + + Drittanbieter-KI-Agentenzugriff auf deinen MCP-Server ermöglichen + diff --git a/i18n/de/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/de/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index fac237529e8..7a3be0cafa5 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -4,25 +4,25 @@ sidebar_position: 2 # Verwaltung von autorisierten Benutzer-Apps (Grants) -App-Grants repräsentieren den Autorisierungsstatus eines Benutzers für spezifische Client-Anwendungen. +App-Grants repräsentieren den Autorisierungsstatus eines Benutzers für bestimmte Client-Anwendungen. -Verwende das Grants-Management, wenn Benutzer oder Administratoren autorisierte Apps überprüfen und den App-Zugriff widerrufen müssen, ohne die gesamte Logto-Sitzung zu widerrufen. +Verwende das Grants-Management, wenn Benutzer oder Administratoren autorisierte Apps überprüfen und den App-Zugriff widerrufen müssen, ohne die gesamte Logto-Sitzung zu beenden. -Wenn Grants widerrufen werden, werden zuvor ausgestellte opake Zugangstokens und Auffrischungstokens für diese Grants ungültig. +Wenn Grants widerrufen werden, werden zuvor ausgestellte opake Zugangstokens (Opaque tokens) und Auffrischungstokens (Refresh tokens) für diese Grants ungültig. JWT-Zugangstokens sind zustandslos, daher bleiben zuvor ausgestellte bis zum Ablauf gültig. ## Wähle den richtigen Weg \{#choose-the-right-path} -| Szenario | Empfohlener Weg | -| --------------------------------------------------------------------------------------------- | --------------- | -| Angemeldeten Benutzern erlauben, ihre eigenen App-Autorisierungen zu verwalten | Account API | -| Administratoren oder Support-Teams erlauben, Grants für einen Zielbenutzer zu verwalten | Management API | -| Operatoren erlauben, Drittanbieter-App-Autorisierungen in der Benutzeroberfläche zu verwalten | Admin Console | +| Szenario | Empfohlener Weg | +| -------------------------------------------------------------------------- | --------------- | +| Angemeldete Benutzer verwalten ihre eigenen App-Autorisierungen | Account API | +| Administratoren oder Support-Teams verwalten Grants für einen Zielbenutzer | Management API | +| Operatoren verwalten Autorisierungen von Drittanbieter-Apps in der UI | Admin Console | ## Direkte Grant-Management-APIs \{#direct-grant-management-apis} -### Account API (Selbstbedienung) \{#account-api-self-service} +### Account API (Self-Service) \{#account-api-self-service} -Verwende die Account API auf den Einstellungsseiten des Endbenutzerkontos: +Verwende die Account API auf den Kontoeinstellungsseiten für Endbenutzer: - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` @@ -38,34 +38,36 @@ Verwende die Management API in Admin-Tools und Support-Workflows: ### Grant-Liste nach App-Typ filtern \{#filter-grant-list-by-app-type} -Die Endpunkte zur Grant-Auflistung unterstützen den optionalen Abfrageparameter `appType`: +Die Endpunkte zur Grant-Auflistung unterstützen den optionalen Query-Parameter `appType`: - `appType=firstParty`: Nur Grants für First-Party-Apps auflisten. - `appType=thirdParty`: Nur Grants für Drittanbieter-Apps auflisten. - `appType` weglassen: Alle aktiven Grants zurückgeben. -## Verwaltung von Drittanbieter-App-Autorisierungen in der Konsole \{#manage-third-party-app-authorizations-in-console} +[Dynamic app](/integrate-logto/third-party-applications/dynamic-apps)-Clients sind Drittanbieter-Anwendungen, daher werden deren Grants mit `appType=thirdParty` zurückgegeben. Die Client-ID-URL wird als Anwendungs-ID verwendet. -In der Logto-Konsole kannst du auf der Benutzerdetailseite autorisierte Drittanbieter-Apps anzeigen und widerrufen. +## Verwaltung von Drittanbieter-App-Autorisierungen in der Console \{#manage-third-party-app-authorizations-in-console} -- Referenz: [Verwaltung von autorisierten Drittanbieter-Apps für Benutzer](/user-management/manage-users#manage-user-authorized-third-party-apps) +In der Logto Console kannst du auf der Benutzer-Detailseite autorisierte Drittanbieter-Apps anzeigen und widerrufen. -## Grants widerrufen, wenn eine Sitzung widerrufen wird \{#revoke-grants-when-revoking-a-session} +- Referenz: [Verwaltung von autorisierten Drittanbieter-Apps eines Benutzers](/user-management/manage-users#manage-user-authorized-third-party-apps) -Beim Widerrufen einer Sitzung über `DELETE /api/my-account/sessions/{sessionId}` verwende den optionalen Abfrageparameter `revokeGrantsTarget`, um den Umfang des Grant-Widerrufs zu steuern: +## Grants beim Widerrufen einer Sitzung widerrufen \{#revoke-grants-when-revoking-a-session} + +Beim Widerrufen einer Sitzung über `DELETE /api/my-account/sessions/{sessionId}` kannst du mit dem optionalen Query-Parameter `revokeGrantsTarget` den Umfang des Grant-Widerrufs steuern: - `all`: Grants für alle mit der Sitzung verbundenen Apps widerrufen. -- `firstParty`: Nur Grants für First-Party-Apps widerrufen. +- `firstParty`: Grants nur für First-Party-Apps widerrufen. -Für das Verhalten auf Sitzungsebene und den Endpunktkontext siehe [Verwaltung von Benutzersitzungen](/sessions/manage-user-sessions) und [Abmelden](/end-user-flows/sign-out). +Für das Sitzungsverhalten und den Endpunkt-Kontext siehe [Benutzersitzungen verwalten](/sessions/manage-user-sessions) und [Abmelden](/end-user-flows/sign-out). ## Verwandte Ressourcen \{#related-resources} Sitzungen -Verwaltung von Benutzersitzungen +Benutzersitzungen verwalten - Kontoeinstellungen über Account API: Verwaltung von autorisierten Benutzer-Apps (Grants) + Kontoeinstellungen per Account API: Verwaltung von autorisierten Benutzer-Apps (Grants) - Kontoeinstellungen über Management API: Verwaltung von autorisierten Benutzer-Apps (Grants) + Kontoeinstellungen per Management API: Verwaltung von autorisierten Benutzer-Apps (Grants) diff --git a/i18n/de/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/de/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index 44ef4dca885..357996342c5 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/de/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -5,38 +5,61 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- Um dem Drittanbieter-AI-Agent den Zugriff auf {props.serviceName ?? 'deinen Dienst'} zu ermöglichen, musst du eine **Drittanbieter-App** in Logto einrichten. Diese App wird verwendet, um den AI-Agent zu repräsentieren und die notwendigen Zugangsdaten für Authentifizierung (Authentifizierung) und Autorisierung (Autorisierung) zu erhalten. :::info[Was ist eine Drittanbieter-App?] -Eine **Drittanbieter-App** ist eine Anwendung, die von externen Entwicklern (nicht dem Ressourcenbesitzer) erstellt wurde und die Zustimmung des Benutzers benötigt, um auf geschützte Ressourcen zuzugreifen. Im Gegensatz zu First-Party-Apps (deine eigenen Anwendungen) zeigen Drittanbieter-Apps einen Zustimmungsbildschirm (Consent screen) an, auf dem Benutzer bestimmte Berechtigungen genehmigen müssen, bevor auf ihre Daten zugegriffen werden kann. Dies stellt sicher, dass Benutzer die Kontrolle darüber haben, welche Daten sie mit externen Diensten teilen. +Eine **Drittanbieter-App** ist eine Anwendung, die von externen Entwicklern (nicht dem Ressourceneigentümer) erstellt wurde und die Zustimmung des Benutzers benötigt, um auf geschützte Ressourcen zuzugreifen. Im Gegensatz zu First-Party-Apps (deinen eigenen Anwendungen) zeigen Drittanbieter-Apps einen Zustimmungsbildschirm (Consent screen) an, auf dem Benutzer bestimmte Berechtigungen genehmigen müssen, bevor auf ihre Daten zugegriffen werden kann. Dies stellt sicher, dass Benutzer die Kontrolle darüber haben, welche Daten sie mit externen Diensten teilen. Weitere Informationen findest du unter [Drittanbieter-Anwendungen](/integrate-logto/third-party-applications). ::: +Es gibt drei Möglichkeiten, AI-Agents einzubinden: + +- [App manuell in der Console erstellen](#manually-create-a-third-party-app-in-logto), für Tests oder einige bekannte Agents. +- [Registrierungsdienst auf der Management API aufbauen](#allow-developers-to-create-third-party-apps-in-logto), wenn du kontrollieren möchtest, wer Zugangsdaten erhält. +- [Dynamische App aktivieren](#let-any-ai-agent-connect-without-pre-registration), wenn sich beliebige Agents verbinden dürfen und du keinen Registrierungsschritt möchtest. + ### Entwicklern erlauben, Drittanbieter-Apps in Logto zu erstellen \{#allow-developers-to-create-third-party-apps-in-logto} -Wenn du einen Marktplatz aufbaust oder Entwicklern erlauben möchtest, Drittanbieter-Apps in Logto zu erstellen, kannst du die [Logto Management API](/integrate-logto/interact-with-management-api) nutzen, um Drittanbieter-Apps programmatisch zu erstellen. Dadurch können Entwickler ihre Anwendungen registrieren und die notwendigen Zugangsdaten für die Authentifizierung erhalten. +Wenn du einen Marktplatz aufbaust oder Entwicklern erlauben möchtest, Drittanbieter-Apps in Logto zu erstellen, kannst du die [Logto Management API](/integrate-logto/interact-with-management-api) nutzen, um Drittanbieter-Apps programmatisch zu erstellen. So können Entwickler ihre Anwendungen registrieren und die notwendigen Zugangsdaten für die Authentifizierung (Authentifizierung) erhalten. Du musst einen eigenen Dienst hosten, um den Client-Registrierungsprozess zu verwalten. Dieser Dienst interagiert mit der Logto Management API, um Drittanbieter-Apps im Namen der Entwickler zu erstellen. ```mermaid sequenceDiagram - actor Entwickler + actor Developer as Entwickler participant Server as Dein App-Registrierungsdienst participant Logto as Logto Management API - Entwickler->>Server: App registrieren + Developer->>Server: App registrieren Server->>Logto: App erstellen - Logto->>Server: App-ID, Secret, usw. - Server->>Entwickler: App-ID, Secret, usw. + Logto->>Server: App-ID, Secret usw. + Server->>Developer: App-ID, Secret usw. ``` Alternativ kannst du Drittanbieter-Apps auch manuell in der Logto Console erstellen, um dich mit dem Prozess vertraut zu machen. +### Beliebigen AI-Agent ohne Vorabregistrierung verbinden lassen \{#let-any-ai-agent-connect-without-pre-registration} + +In einem offenen MCP-Ökosystem kennst du die Agents in der Regel nicht im Voraus. [Dynamische App](/integrate-logto/third-party-applications/dynamic-apps) entfernt den Registrierungsschritt: Der Agent verwendet eine öffentliche HTTPS-URL, die sein eigenes Client-Metadaten-Dokument bereitstellt, als sein `client_id`, und Logto löst diese auf, wenn die Autorisierungsanfrage eintrifft. + +```mermaid +sequenceDiagram + participant Agent as AI-Agent (MCP-Client) + participant Logto + participant Metadata as Metadaten-Dokument-URL des Agents + Agent->>Logto: Autorisierungsanfrage mit der Client-ID-URL + Logto->>Metadata: Metadaten-Dokument der Client-ID abrufen + Metadata->>Logto: Client-Name, Logo, Redirect-URIs usw. + Logto->>Agent: Zustimmungsbildschirm, dann Autorisierungscode +``` + +Du kontrollierst weiterhin, welche Agents was anfragen dürfen, über die Berechtigungen, die der dynamischen App gewährt werden, und jede Autorisierung läuft über den Zustimmungsbildschirm (Consent screen) des Benutzers. + ### Drittanbieter-App manuell in Logto erstellen \{#manually-create-a-third-party-app-in-logto} Du kannst eine Drittanbieter-App manuell in der Logto Console für Testzwecke oder Ad-hoc-Integrationen erstellen. Das ist nützlich, wenn du die Integration schnell testen möchtest, ohne einen vollständigen Client-Registrierungs-Flow zu implementieren. -1. Melde dich in deiner Logto Console an. +1. Melde dich bei deiner Logto Console an. 2. Gehe zu **Anwendungen** → **Anwendung erstellen** → **Drittanbieter-App** -> **OIDC**. 3. Gib den App-Namen und andere erforderliche Felder ein und klicke dann auf **Anwendung erstellen**. -4. Klicke auf den Tab **Berechtigungen**, im Bereich **Benutzer** klicke auf "Hinzufügen". +4. Klicke auf den Tab **Berechtigungen**, im Bereich **Benutzer** auf "Hinzufügen" klicken. 5. Im geöffneten Dialog -> **Benutzerdaten** -> wähle die Berechtigungen **`profile`**, **`email`** aus und klicke dann auf **Speichern**. 6. Konfiguriere in der Drittanbieter-App die Scopes, um die Berechtigungen (Berechtigungen) `openid profile email` anzufordern. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx b/i18n/es/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx index bec37e569e1..c4cf8a9f7f4 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx @@ -11,7 +11,7 @@ El control de acceso a nivel de aplicación te permite restringir quién puede i Utiliza el control de acceso a nivel de aplicación cuando quieras: - Hacer que una aplicación interna esté disponible solo para empleados o administradores. -- Limitar una [Aplicación Protegida](/integrate-logto/protected-app) a un grupo seleccionado de usuarios. +- Limitar una [Aplicación protegida](/integrate-logto/protected-app) a un grupo seleccionado de usuarios. - Permitir solo a clientes o socios específicos acceder a una [aplicación OIDC / OAuth de terceros](/integrate-logto/third-party-applications). - Lanzar una nueva aplicación a un grupo piloto antes de abrirla a todos. @@ -19,16 +19,16 @@ Utiliza el control de acceso a nivel de aplicación cuando quieras: Cuando el control de acceso a nivel de aplicación está deshabilitado, todos los usuarios registrados en tu tenant de Logto pueden iniciar sesión en la aplicación. -Cuando está habilitado, un usuario solo puede acceder a la aplicación si cumple al menos una de las reglas configuradas. Si el usuario no cumple ninguna regla, Logto deniega el intento de inicio de sesión y muestra una página de acceso denegado antes de que la aplicación reciba tokens. +Cuando está habilitado, un usuario solo puede acceder a la aplicación si cumple al menos una regla configurada. Si el usuario no cumple ninguna regla, Logto deniega el intento de inicio de sesión y muestra una página de acceso denegado antes de que la aplicación reciba tokens. El control de acceso a nivel de aplicación se evalúa durante el flujo de autorización y la renovación de tokens. Esto significa que: -- Los usuarios sin acceso son bloqueados antes de que puedan completar el inicio de sesión en la aplicación. +- Los usuarios sin acceso son bloqueados antes de poder completar el inicio de sesión en la aplicación. - Las concesiones existentes de la aplicación se verifican nuevamente cuando se utilizan tokens de actualización para solicitar nuevos tokens. -- La actualización de reglas afecta las futuras comprobaciones de autorización y renovación de tokens, sin cambiar la sesión global de Logto del usuario. +- La actualización de las reglas afecta las futuras comprobaciones de autorización y renovación de tokens, sin cambiar la sesión global de Logto del usuario. :::note -El control de acceso a nivel de aplicación es independiente del [Control de acceso basado en roles (RBAC)](/authorization/role-based-access-control). RBAC controla lo que un usuario puede hacer después de la autenticación emitiendo permisos (alcances) en los tokens de acceso. El control de acceso a nivel de aplicación controla si un usuario puede acceder o no a una aplicación en particular. +El control de acceso a nivel de aplicación es independiente del [Control de acceso basado en roles (RBAC)](/authorization/role-based-access-control). RBAC controla lo que un usuario puede hacer después de la autenticación emitiendo permisos (alcances) en los tokens de acceso. El control de acceso a nivel de aplicación controla si un usuario puede acceder a una aplicación en particular. ::: ## Tipos de reglas \{#rule-types} @@ -79,12 +79,12 @@ Si el control de acceso está habilitado, Logto requiere que al menos una regla El control de acceso a nivel de aplicación no termina la sesión global de Logto del usuario. Un usuario puede seguir conectado a Logto y a otras aplicaciones. -Para la aplicación que está siendo restringida: +Para la aplicación restringida: - Un usuario que ya no cumpla ninguna regla de permiso será bloqueado la próxima vez que pase por el flujo de autorización de la aplicación. - Si el usuario ya tiene concesiones relacionadas con la aplicación, Logto verifica las reglas nuevamente cuando la aplicación utiliza un token de actualización para solicitar nuevos tokens. Si el usuario ya no tiene acceso, Logto deniega la solicitud de token. -Esto mantiene las decisiones de acceso vinculadas a la aplicación mientras se evita la interrupción innecesaria de aplicaciones no relacionadas. +Esto mantiene las decisiones de acceso ligadas a la aplicación, evitando interrupciones innecesarias en aplicaciones no relacionadas. ## Relación con los permisos de aplicaciones de terceros \{#relationship-with-third-party-app-permissions} @@ -95,11 +95,15 @@ Para [aplicaciones de terceros](/integrate-logto/third-party-applications), el c Si ambos están configurados, el usuario debe pasar el control de acceso a nivel de aplicación antes de poder autorizar la aplicación de terceros. -## Relación con Aplicación Protegida \{#relationship-with-protected-app} +:::note +El control de acceso a nivel de aplicación se aplica solo a aplicaciones registradas. Los clientes [aplicación dinámica](/integrate-logto/third-party-applications/dynamic-apps) no tienen un registro de aplicación, por lo que no pueden ser restringidos de esta manera. Su acceso está limitado por los permisos que otorgues a la aplicación dinámica y por el consentimiento del usuario. +::: + +## Relación con Aplicación protegida \{#relationship-with-protected-app} -Para [Aplicación Protegida](/integrate-logto/protected-app), el control de acceso a nivel de aplicación restringe quién puede pasar la capa de autenticación de Logto y llegar al servidor de origen protegido. +Para [Aplicación protegida](/integrate-logto/protected-app), el control de acceso a nivel de aplicación restringe quién puede pasar la capa de autenticación de Logto y llegar al servidor de origen protegido. -Las reglas de autenticación de Aplicación Protegida aún determinan qué rutas requieren autenticación. El control de acceso a nivel de aplicación determina qué usuarios autenticados de Logto pueden acceder a la aplicación Aplicación Protegida. +Las reglas de autenticación de Aplicación protegida siguen determinando qué rutas requieren autenticación. El control de acceso a nivel de aplicación determina qué usuarios autenticados de Logto pueden acceder a la aplicación Aplicación protegida. ## Mejores prácticas \{#best-practices} @@ -107,4 +111,4 @@ Las reglas de autenticación de Aplicación Protegida aún determinan qué rutas - Usa reglas de organización cuando todos en una organización deban acceder a la aplicación. - Usa reglas de rol de organización cuando solo miembros específicos de una organización deban acceder a la aplicación. - Revisa las reglas de acceso cuando los usuarios cambien de rol, se unan a organizaciones o abandonen organizaciones. -- Mantén separados los permisos RBAC y el control de acceso a nivel de aplicación en tu modelo mental: el control de acceso a nivel de aplicación responde "¿Puede este usuario acceder a esta aplicación?", mientras que RBAC responde "¿Qué puede hacer este usuario después de acceder a las APIs o funciones de la organización?" +- Mantén separados los permisos RBAC y el control de acceso a nivel de aplicación en tu modelo mental: el control de acceso a nivel de aplicación responde "¿Puede este usuario acceder a esta aplicación?", mientras que RBAC responde "¿Qué puede hacer este usuario después de acceder a las API o funciones de la organización?" diff --git a/i18n/es/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/es/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index d8ae092b2ab..55bc9f3b31c 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/es/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -19,33 +19,35 @@ Si ejecutas Logto mediante `npm start` en la raíz del proyecto, `NODE_ENV` siem En los valores predeterminados, `protocol` será `http` o `https` según tu configuración de HTTPS. -| Key | Valor predeterminado | Tipo | Descripción | -| -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| NODE_ENV | `undefined` | 'production' | 'test' | undefined | Qué tipo de entorno ejecuta Logto. | -| PORT | `3001` | `number` | El puerto local en el que Logto escucha. | -| ADMIN_PORT | `3002` | `number` | El puerto local en el que escucha la Consola de Administración de Logto. | -| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Establécelo en `1` o `true` para deshabilitar el puerto de la Consola de Administración. Si `ADMIN_ENDPOINT` no está establecido, deshabilitará completamente la Consola de Administración. | -| DB_URL | N/A | `string` | El [DSN de Postgres](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6) para la base de datos de Logto. | -| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) `statement_timeout` de PostgreSQL en milisegundos. Usa una cadena numérica (por ejemplo, `5000`) para establecerlo, o `DISABLE_TIMEOUT` para omitir el parámetro de inicio (recomendado para PgBouncer/RDS Proxy). Si no se establece o es inválido, el valor predeterminado del cliente es 60000 ms. | -| HTTPS_CERT_PATH | `undefined` | string | undefined | Consulta [Habilitar HTTPS](#enabling-https) para más detalles. | -| HTTPS_KEY_PATH | `undefined` | string | undefined | Ídem. | -| TRUST_PROXY_HEADER | `false` | `boolean` | Ídem. | -| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | Puedes especificar una URL con tu dominio personalizado para pruebas en línea o producción. Esto también afectará el valor del [identificador de emisor OIDC](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier). | -| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | Puedes especificar una URL con tu dominio personalizado para producción (Ejemplo: `ADMIN_ENDPOINT=https://admin.domain.com`). Esto también afectará el valor de los URI de redirección de la Consola de Administración. | -| CASE_SENSITIVE_USERNAME | `true` | `boolean` | Especifica si el nombre de usuario distingue entre mayúsculas y minúsculas. Ten cuidado al modificar este valor; los cambios no ajustarán automáticamente los datos existentes en la base de datos, requiriendo gestión manual. | -| SECRET_VAULT_KEK | `undefined` | `string` | La clave de cifrado de clave (KEK) utilizada para cifrar las claves de cifrado de datos (DEK) en el [Secret Vault](/secret-vault). Requerida para que el Secret Vault funcione correctamente. Debe ser una cadena codificada en base64. Se recomienda AES-256 (32 bytes). Ejemplo: `crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | Período de gracia en segundos para la rotación escalonada de la clave privada OIDC. Cuando se establece en un valor positivo, la nueva clave privada se crea primero como `Next` y solo se vuelve efectiva después del período de gracia. | -| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | Solo para autoalojado. Establécelo en `true` solo cuando los endpoints de relying-party OIDC de confianza deban resolverse a direcciones de red privadas. Consulta [Protección SSRF del proveedor OIDC](#oidc-provider-ssrf-protection). | +| Key | Valor predeterminado | Tipo | Descripción | +| -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| NODE_ENV | `undefined` | 'production' | 'test' | undefined | El tipo de entorno en el que se ejecuta Logto. | +| PORT | `3001` | `number` | El puerto local en el que Logto escucha. | +| ADMIN_PORT | `3002` | `number` | El puerto local en el que la Consola de Administración de Logto escucha. | +| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Establécelo en `1` o `true` para deshabilitar el puerto para la Consola de Administración. Si `ADMIN_ENDPOINT` no está configurado, deshabilitará completamente la Consola de Administración. | +| DB_URL | N/A | `string` | El [DSN de Postgres](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6) para la base de datos de Logto. | +| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) `statement_timeout` de PostgreSQL en milisegundos. Usa una cadena numérica (por ejemplo, `5000`) para configurarlo, o `DISABLE_TIMEOUT` para omitir el parámetro de inicio (recomendado para PgBouncer/RDS Proxy). Si no se configura o es inválido, el valor predeterminado es 60000 ms. | +| HTTPS_CERT_PATH | `undefined` | string | undefined | Consulta [Habilitar HTTPS](#enabling-https) para más detalles. | +| HTTPS_KEY_PATH | `undefined` | string | undefined | Ídem. | +| TRUST_PROXY_HEADER | `false` | `boolean` | Ídem. | +| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | Puedes especificar una URL con tu dominio personalizado para pruebas en línea o producción. Esto también afectará el valor del [identificador del emisor OIDC](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier). | +| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | Puedes especificar una URL con tu dominio personalizado para producción (Ejemplo: `ADMIN_ENDPOINT=https://admin.domain.com`). Esto también afectará el valor de los URIs de redirección de la Consola de Administración. | +| CASE_SENSITIVE_USERNAME | `true` | `boolean` | Especifica si el nombre de usuario distingue entre mayúsculas y minúsculas. Ten cuidado al modificar este valor; los cambios no ajustarán automáticamente los datos existentes en la base de datos, requiriendo gestión manual. | +| SECRET_VAULT_KEK | `undefined` | `string` | La Clave de Cifrado de Claves (KEK) utilizada para cifrar las Claves de Cifrado de Datos (DEK) en el [Secret Vault](/secret-vault). Requerida para que el Secret Vault funcione correctamente. Debe ser una cadena codificada en base64. Se recomienda AES-256 (32 bytes). Ejemplo: `crypto.randomBytes(32).toString('base64')` | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | Período de gracia en segundos para la rotación escalonada de la clave privada OIDC. Cuando se establece en un valor positivo, la nueva clave privada se crea primero como `Next` y solo se vuelve efectiva después del período de gracia. | +| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | Solo para autoalojados. Establécelo en `true` solo cuando los endpoints confiables de OIDC relying-party deban resolverse a direcciones de red privadas. Consulta [Protección SSRF del proveedor OIDC](#oidc-provider-ssrf-protection). | ### Protección SSRF del proveedor OIDC {#oidc-provider-ssrf-protection} -Logto protege por defecto las solicitudes salientes del proveedor OIDC contra la falsificación de solicitudes del lado del servidor (SSRF). Las solicitudes a direcciones de uso especial, incluidas las direcciones de loopback y de red privada, están bloqueadas. Esta protección cubre endpoints de relying-party como los URI de cierre de sesión back-channel, `jwks_uri` y `sector_identifier_uri`. +Logto protege las solicitudes salientes del proveedor OIDC contra ataques de falsificación de solicitudes del lado del servidor (SSRF) por defecto. Las solicitudes a direcciones de uso especial, incluidas las direcciones de loopback y de red privada, están bloqueadas. Esta protección cubre endpoints relying-party como URIs de cierre de sesión back-channel, `jwks_uri` y `sector_identifier_uri`, así como los documentos de metadatos de ID de cliente obtenidos para [aplicaciones dinámicas](/integrate-logto/third-party-applications/dynamic-apps). -Si tu despliegue autoalojado necesita intencionadamente acceder a un endpoint de relying-party de confianza en una red privada, establece `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` y reinicia cada instancia de Logto. +Si tu despliegue autoalojado necesita intencionalmente acceder a un endpoint relying-party confiable en una red privada, establece `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` y reinicia cada instancia de Logto. :::caution -Esta configuración desactiva la protección SSRF para todas las solicitudes salientes del proveedor OIDC, no solo para un endpoint. Desactívala solo cuando todos los endpoints de relying-party configurados sean de confianza y tus controles de red impidan el acceso a servicios internos sensibles. +Esta configuración desactiva la protección SSRF para todas las solicitudes salientes del proveedor OIDC, no solo para un endpoint. Solo desactívala cuando todos los endpoints relying-party configurados sean confiables y tus controles de red impidan el acceso a servicios internos sensibles. + +[Aplicación dinámica](/integrate-logto/third-party-applications/dynamic-apps) no puede habilitarse mientras esta protección esté desactivada, ya que obtiene documentos de metadatos desde URLs proporcionadas por los propios clientes. ::: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index f9e136407c1..88ed9f56045 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -6,7 +6,7 @@ sidebar_position: 6 ## ¿Qué es la pantalla de consentimiento? \{#what-is-consent-screen} -Imagina que te estás registrando en Logto usando tu cuenta de Google. Cuando haces clic en el botón "Iniciar sesión con Google", eres redirigido a la página de inicio de sesión de Google. Después de ingresar tus credenciales de Google, se te pedirá que concedas permiso a Logto para acceder a la información de tu cuenta de Google. Esta es la pantalla de consentimiento del usuario. +Imagina que te estás registrando en Logto usando tu cuenta de Google. Cuando haces clic en el botón "Iniciar sesión con Google", eres redirigido a la página de inicio de sesión de Google. Después de ingresar tus credenciales de Google, se te pedirá que otorgues permiso a Logto para acceder a la información de tu cuenta de Google. Esta es la pantalla de consentimiento del usuario. Esta página es lo que llamamos la **pantalla de consentimiento** o **página de consentimiento** del usuario. Es un flujo estándar de [OIDC / OAuth 2.0](/integrate-logto/third-party-applications) que permite a los usuarios otorgar permisos a [aplicaciones de terceros](/integrate-logto/third-party-applications) para acceder a sus datos en su nombre. Su propósito principal es informar a los usuarios sobre la recopilación, el procesamiento y el uso de sus datos personales y solicitar su acuerdo o consentimiento explícito para estas actividades. @@ -16,7 +16,7 @@ Las páginas de consentimiento son especialmente importantes en el contexto de r ## ¿Cuándo ve el usuario la pantalla de consentimiento en Logto? \{#when-does-user-see-the-consent-screen-in-logto} -Como se mencionó anteriormente, la pantalla de consentimiento aparece cuando los usuarios inician sesión en Logto utilizando un proveedor de identidad (IdP) de terceros como Google, Facebook o Apple. En esta configuración, Logto actúa como el proveedor de servicios (SP), solicitando acceso a la información del usuario desde el IdP. La pantalla de consentimiento generalmente se presenta cuando el [SP](https://auth.wiki/service-provider) y el [IdP](https://auth.wiki/identity-provider) son organizaciones separadas, requiriendo la autorización del usuario para facilitar el intercambio de datos. +Como se mencionó anteriormente, la pantalla de consentimiento aparece cuando los usuarios inician sesión en Logto usando un proveedor de identidad (IdP) de terceros como Google, Facebook o Apple. En esta configuración, Logto actúa como el proveedor de servicios (SP), solicitando acceso a la información del usuario desde el IdP. La pantalla de consentimiento generalmente se presenta cuando el [SP](https://auth.wiki/service-provider) y el [IdP](https://auth.wiki/identity-provider) son organizaciones separadas, requiriendo la autorización del usuario para facilitar el intercambio de datos. Consent screen Logto as SP @@ -24,6 +24,10 @@ De manera similar, en Logto, cuando Logto funciona como el IdP, la pantalla de c Consent screen Logto as IdP +### Clientes no registrados (dinámicos) \{#unregistered-dynamic-clients} + +Si la [aplicación dinámica](/integrate-logto/third-party-applications/dynamic-apps) está habilitada, los clientes pueden conectarse a tu tenant sin pre-registro. Para estos clientes, la pantalla de consentimiento muestra un aviso adicional, junto con el host de la URL del client ID. El nombre y el logo del cliente provienen del propio documento de metadatos del cliente, por lo que pueden imitar cualquier marca, mientras que el host no puede ser falsificado. + ## ¿Cómo configurar la pantalla de consentimiento? \{#how-to-configure-the-consent-screen} El flujo de consentimiento de Logto te permite autorizar inicios de sesión desde aplicaciones de terceros. Puedes personalizar la marca y las solicitudes de permisos para cada aplicación de terceros OIDC. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index ddf9412a51b..6881a683a9e 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -7,9 +7,9 @@ sidebar_position: 7 ## Introducción \{#introduction} -En Logto, una _aplicación_ se refiere a un programa de software o servicio específico que está registrado en la plataforma Logto y ha recibido autorización para acceder a la información del usuario o realizar acciones en nombre de un usuario. Las aplicaciones se utilizan para identificar la fuente de las solicitudes realizadas a la API de Logto, así como para gestionar el proceso de autenticación y autorización para los usuarios que acceden a esas aplicaciones. +En Logto, una _aplicación_ se refiere a un programa o servicio de software específico que está registrado en la plataforma Logto y ha recibido autorización para acceder a la información del usuario o realizar acciones en nombre de un usuario. Las aplicaciones se utilizan para identificar la fuente de las solicitudes realizadas a la API de Logto, así como para gestionar el proceso de autenticación y autorización para los usuarios que acceden a esas aplicaciones. -El uso de aplicaciones en la experiencia de inicio de sesión de Logto permite a los usuarios acceder y gestionar fácilmente sus aplicaciones autorizadas desde un solo lugar, con un proceso de autenticación coherente y seguro. Esto ayuda a simplificar la experiencia del usuario y garantiza que solo las personas autorizadas accedan a información sensible o realicen acciones en nombre de la organización. +El uso de aplicaciones en la experiencia de inicio de sesión de Logto permite a los usuarios acceder y gestionar fácilmente sus aplicaciones autorizadas desde un solo lugar, con un proceso de autenticación coherente y seguro. Esto ayuda a agilizar la experiencia del usuario y garantiza que solo las personas autorizadas accedan a información sensible o realicen acciones en nombre de la organización. Las aplicaciones también se utilizan en los registros de auditoría de Logto para rastrear la actividad del usuario e identificar posibles amenazas o brechas de seguridad. Al asociar acciones específicas con una aplicación en particular, Logto puede proporcionar información detallada sobre cómo se accede y utiliza la información, permitiendo a las organizaciones gestionar mejor sus requisitos de seguridad y cumplimiento. Si deseas integrar tu aplicación con Logto, consulta [Integrar Logto](/integrate-logto). @@ -20,27 +20,31 @@ Si deseas integrar tu aplicación con Logto, consulta [Integrar Logto](/integrat _Application ID_ es una clave única autogenerada para identificar tu aplicación en Logto, y se referencia como [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) en OAuth 2.0. +:::note +Los clientes [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) no están registrados en Logto. Su client ID es una URL HTTPS pública propiedad del cliente, que sirve el documento de metadatos del cliente. +::: + ### Tipos de aplicación \{#application-types} Una _aplicación_ puede ser uno de los siguientes tipos de aplicación: - **Aplicación nativa** es una app que se ejecuta en un entorno nativo. Ejemplo: app iOS, app Android. - - **Aplicación de flujo de dispositivo** es un tipo especial de aplicación nativa para dispositivos con entrada limitada o aplicaciones sin interfaz (por ejemplo, smart TVs, consolas de juegos, herramientas CLI, dispositivos IoT). Utiliza el [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) en lugar del flujo estándar basado en redirección. Consulta [Inicio rápido de Device flow](/quick-starts/device-flow) para más detalles. + - **Aplicación de flujo de dispositivo** es un tipo especial de aplicación nativa para dispositivos con entrada limitada o aplicaciones sin interfaz (por ejemplo, televisores inteligentes, consolas de juegos, herramientas CLI, dispositivos IoT). Utiliza el [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) en lugar del flujo estándar basado en redirección. Consulta [Inicio rápido de Device flow](/quick-starts/device-flow) para más detalles. - **Aplicación de una sola página (SPA)** es una app que se ejecuta en un navegador web, que actualiza la página con nuevos datos del servidor sin cargar páginas completas nuevas. Ejemplo: app React DOM, app Vue. -- **Aplicación web tradicional** es una app que renderiza y actualiza páginas únicamente por el servidor web. Ejemplo: JSP, PHP. +- **Aplicación web tradicional** es una app que renderiza y actualiza páginas solo por el servidor web. Ejemplo: JSP, PHP. - **Aplicación máquina a máquina (M2M)** es una aplicación que se ejecuta en un entorno de máquina para comunicación directa entre servicios sin interacción del usuario. ### Secreto de la aplicación \{#application-secret} -_Application secret_ es una clave utilizada para autenticar la aplicación en el sistema de autenticación, específicamente para clientes privados (aplicaciones web tradicionales y M2M) como una barrera de seguridad privada. +_Application secret_ es una clave utilizada para autenticar la aplicación en el sistema de autenticación, específicamente para clientes privados (aplicaciones web tradicionales y M2M) como barrera de seguridad privada. :::tip -Las aplicaciones de una sola página (SPA) y las aplicaciones nativas no proporcionan secreto de aplicación. Las SPA y las aplicaciones nativas son "clientes públicos" y no pueden mantener secretos (el código del navegador o los paquetes de la app son inspeccionables). En lugar de un secreto de aplicación, Logto las protege con PKCE, validación estricta de URI de redirección / CORS, tokens de acceso de corta duración y rotación de tokens de actualización. +Las aplicaciones de una sola página (SPA) y las aplicaciones nativas no proporcionan App secret. Las SPA y las aplicaciones nativas son "clientes públicos" y no pueden mantener secretos (el código del navegador o los paquetes de la app son inspeccionables). En lugar de un secreto de app, Logto las protege con PKCE, validación estricta de URI de redirección / CORS, tokens de acceso de corta duración y rotación de tokens de actualización. ::: ### Nombre de la aplicación \{#application-name} -_Application name_ es el nombre legible para humanos de la aplicación y se mostrará en la consola de administración. +_Application name_ es un nombre legible para humanos de la aplicación y se mostrará en la consola de administración. El _Application name_ es un componente importante para la gestión de aplicaciones en Logto, ya que permite a los administradores identificar y rastrear fácilmente la actividad de aplicaciones individuales dentro de la plataforma. @@ -56,7 +60,7 @@ Una breve descripción de la aplicación se mostrará en la página de detalles _Redirect URIs_ son una lista de URIs de redirección válidas que han sido preconfiguradas para una aplicación. Cuando un usuario inicia sesión en Logto e intenta acceder a la aplicación, es redirigido a uno de los URIs permitidos especificados en la configuración de la aplicación. -La lista de URIs permitidas se utiliza para validar el URI de redirección que se incluye en la solicitud de autorización enviada por la aplicación a Logto durante el proceso de autenticación. Si el URI de redirección especificado en la solicitud de autorización coincide con uno de los URIs permitidos en la configuración de la aplicación, el usuario es redirigido a ese URI tras la autenticación exitosa. Si el URI de redirección no está en la lista permitida, el usuario no será redirigido y el proceso de autenticación fallará. +La lista de URIs permitidas se utiliza para validar el URI de redirección que se incluye en la solicitud de autorización enviada por la aplicación a Logto durante el proceso de autenticación. Si el URI de redirección especificado en la solicitud de autorización coincide con uno de los URIs permitidos en la configuración de la aplicación, el usuario es redirigido a ese URI después de una autenticación exitosa. Si el URI de redirección no está en la lista permitida, el usuario no será redirigido y el proceso de autenticación fallará. :::note Es importante asegurarse de que todos los URIs de redirección válidos estén añadidos a la lista permitida para una aplicación en Logto, para garantizar que los usuarios puedan acceder correctamente a la aplicación después de la autenticación. @@ -70,9 +74,9 @@ Puedes consultar el [Redirection endpoint](https://datatracker.ietf.org/doc/html #### Patrones comodín \{#wildcard-patterns} -_Disponibilidad: Aplicación de una sola página, aplicación web tradicional_ +_Disponibilidad: Aplicación de una sola página, Aplicación web tradicional_ -Las URIs de redirección admiten patrones comodín (`*`) para entornos dinámicos como despliegues de vista previa. Los comodines pueden usarse en los componentes de hostname y pathname de los URIs HTTP / HTTPS. +Los URIs de redirección admiten patrones comodín (`*`) para entornos dinámicos como despliegues de vista previa. Los comodines pueden usarse en los componentes de hostname y pathname de los URIs HTTP / HTTPS. **Reglas:** @@ -87,24 +91,24 @@ Las URIs de redirección admiten patrones comodín (`*`) para entornos dinámico - `https://example.com/*/callback` - coincide con cualquier segmento de ruta :::caution -Las URIs de redirección con comodines no son estándar OIDC y pueden aumentar la superficie de ataque. Úsalas con precaución y prefiere URIs de redirección exactas siempre que sea posible. +Los URIs de redirección comodín no son estándar OIDC y pueden aumentar la superficie de ataque. Úsalos con precaución y prefiere URIs de redirección exactos siempre que sea posible. ::: ### URIs de redirección post cierre de sesión \{#post-sign-out-redirect-uris} _Post sign-out redirect URIs_ son una lista de URIs válidas que han sido preconfiguradas para una aplicación para redirigir al usuario después de que haya cerrado sesión en Logto. -El uso de _Post Sign-out Redirect URIs_ permitidos para el cierre de sesión forma parte de la especificación de Logout iniciado por la parte confiable (RP-Initiated Logout) en OIDC. Esta especificación proporciona un método estandarizado para que las aplicaciones inicien una solicitud de cierre de sesión para un usuario, que incluye redirigir al usuario a un endpoint preconfigurado después de cerrar sesión. +El uso de _Post Sign-out Redirect URIs_ permitidos para el cierre de sesión forma parte de la especificación de Logout iniciado por la parte confiable (RP-Initiated Logout) en OIDC. Esta especificación proporciona un método estandarizado para que las aplicaciones inicien una solicitud de cierre de sesión para un usuario, que incluye redirigir al usuario a un endpoint preconfigurado después de que haya cerrado sesión. Cuando un usuario cierra sesión en Logto, su sesión se termina y es redirigido a uno de los URIs permitidos especificados en la configuración de la aplicación. Esto garantiza que el usuario solo sea dirigido a endpoints autorizados y válidos después de cerrar sesión, ayudando a prevenir accesos no autorizados y riesgos de seguridad asociados con redirigir usuarios a endpoints desconocidos o no verificados. Puedes consultar el [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) para más información. -### Orígenes permitidos por CORS \{#cors-allowed-origins} +### Orígenes permitidos CORS \{#cors-allowed-origins} -_Los orígenes permitidos por CORS (Cross-origin resource sharing)_ son una lista de orígenes permitidos desde los cuales una aplicación puede realizar solicitudes al servicio Logto. Cualquier origen que no esté incluido en la lista permitida no podrá realizar solicitudes al servicio Logto. +_Los orígenes permitidos de CORS (Cross-origin resource sharing)_ son una lista de orígenes permitidos desde los cuales una aplicación puede realizar solicitudes al servicio Logto. Cualquier origen que no esté incluido en la lista permitida no podrá realizar solicitudes al servicio Logto. -La lista de orígenes permitidos por CORS se utiliza para restringir el acceso al servicio Logto desde dominios no autorizados y para ayudar a prevenir ataques de falsificación de solicitudes entre sitios (CSRF). Al especificar los orígenes permitidos para una aplicación en Logto, el servicio puede garantizar que solo los dominios autorizados puedan realizar solicitudes al servicio. +La lista de orígenes permitidos de CORS se utiliza para restringir el acceso al servicio Logto desde dominios no autorizados y para ayudar a prevenir ataques de falsificación de solicitudes entre sitios (CSRF). Al especificar los orígenes permitidos para una aplicación en Logto, el servicio puede garantizar que solo los dominios autorizados puedan realizar solicitudes al servicio. :::note La lista de orígenes permitidos debe contener el origen donde se servirá la aplicación. Esto garantiza que las solicitudes de la aplicación estén permitidas, mientras que las solicitudes de orígenes no autorizados sean bloqueadas. @@ -116,13 +120,13 @@ El endpoint para [OpenID Connect Discovery](https://openid.net/specs/openid-conn ### Endpoint de autorización \{#authorization-endpoint} -_Authorization Endpoint_ es un término de OIDC, y es un endpoint requerido que se utiliza para iniciar el proceso de autenticación de un usuario. Cuando un usuario intenta acceder a un recurso protegido o aplicación que ha sido registrada en la plataforma Logto, será redirigido al _Authorization Endpoint_ para autenticar su identidad y obtener autorización para acceder al recurso solicitado. +_Authorization Endpoint_ es un término de OIDC, y es un endpoint requerido que se utiliza para iniciar el proceso de autenticación para un usuario. Cuando un usuario intenta acceder a un recurso protegido o aplicación que ha sido registrada en la plataforma Logto, será redirigido al _Authorization Endpoint_ para autenticar su identidad y obtener autorización para acceder al recurso solicitado. Puedes consultar el [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) para más información. ### Endpoint de token \{#token-endpoint} -_Token Endpoint_ es un término de OIDC, es un endpoint de API web que utiliza un cliente OIDC para obtener un token de acceso, un token de ID o un token de actualización de un proveedor OIDC. +_Token Endpoint_ es un término de OIDC, es un endpoint de API web que es utilizado por un cliente OIDC para obtener un token de acceso, un token de ID o un token de actualización de un proveedor OIDC. Cuando un cliente OIDC necesita obtener un token de acceso o un token de ID, envía una solicitud al Token Endpoint con una concesión de autorización, que normalmente es un código de autorización o un token de actualización. El Token Endpoint valida la concesión de autorización y emite un token de acceso o un token de ID al cliente si la concesión es válida. @@ -136,7 +140,7 @@ El [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#Use _Disponibilidad: Web tradicional, SPA_ -Cuando está habilitado, Logto siempre emitirá tokens de actualización, independientemente de si `prompt=consent` está presente en la solicitud de autenticación, o si `offline_access` está presente en los alcances. +Cuando está habilitado, Logto siempre emitirá tokens de actualización, independientemente de si `prompt=consent` está presente en la solicitud de autenticación, ni si `offline_access` está presente en los alcances. Sin embargo, esta práctica no se recomienda a menos que sea necesario (normalmente es útil para algunas integraciones OAuth de terceros que requieren token de actualización), ya que no es compatible con OpenID Connect y puede causar problemas potenciales. @@ -144,20 +148,20 @@ Sin embargo, esta práctica no se recomienda a menos que sea necesario (normalme _Predeterminado: `true`_ -Cuando está habilitado, Logto puede emitir un nuevo token de actualización cuando un cliente utiliza un token de actualización para solicitar nuevos tokens. Si el token de actualización y su concesión de aplicación siguen siendo válidos, la política de rotación predeterminada es: +Cuando está habilitado, Logto puede emitir un nuevo token de actualización cuando un cliente utiliza un token de actualización para solicitar nuevos tokens. Si el token de actualización y su concesión de app siguen siendo válidos, la política de rotación predeterminada es: -- Los tokens de actualización solo pueden rotarse antes de que la cadena de tokens de actualización haya existido durante un año. Este es un límite de seguridad interno; el propio TTL del token de actualización o el TTL de la concesión de la aplicación pueden expirar antes. Una vez alcanzado el límite, Logto ya no rota el token de actualización y la expiración del token de actualización actual es definitiva. +- Los tokens de actualización solo pueden rotarse antes de que la cadena de tokens de actualización haya existido durante un año. Este es un límite de seguridad interno de rotación; el TTL propio del token de actualización o el TTL de la concesión de la app pueden expirar antes. Una vez alcanzado el límite, Logto ya no rota el token de actualización y la expiración del token de actualización actual es definitiva. - Para clientes públicos que no usan tokens de actualización restringidos al remitente (por ejemplo, aplicaciones nativas regulares y aplicaciones de una sola página), Logto rota el token de actualización en cada solicitud de token de actualización mientras la rotación esté permitida. - Para otros clientes, Logto rota el token de actualización solo cuando está cerca de expirar (>=70% de su Tiempo de Vida (TTL) original ha pasado). :::note -Para clientes públicos, se recomienda encarecidamente mantener habilitada la rotación de tokens de actualización por razones de seguridad. +Para clientes públicos, se recomienda encarecidamente mantener la rotación de tokens de actualización habilitada por razones de seguridad. Los tokens de actualización restringidos al remitente están vinculados a una clave de prueba o certificado en poder del cliente. Para SPA regulares, la rotación emite un nuevo token de actualización pero no extiende la vida útil del token de actualización. El nuevo token de actualización hereda el TTL restante del token de actualización anterior. ::: :::caution Duración de la cadena de tokens de actualización -Los tokens de actualización están asociados a una concesión de aplicación. El TTL predeterminado de la concesión en Logto es **180 días**. Cuando la concesión expira, las solicitudes de token de actualización fallan y el token de actualización ya no puede usarse para obtener nuevos tokens, incluso si la rotación de tokens de actualización está habilitada. +Los tokens de actualización están asociados a una concesión de app. El TTL predeterminado de la concesión en Logto es **180 días**. Cuando la concesión expira, las solicitudes de token de actualización fallan y el token de actualización ya no puede usarse para obtener nuevos tokens, incluso si la rotación de tokens de actualización está habilitada. Esto significa que la vida útil máxima práctica de una autorización respaldada por token de actualización está actualmente limitada por el TTL de la concesión, la revocación explícita o la expiración propia del token de actualización, lo que ocurra primero. ::: @@ -168,7 +172,7 @@ Esto significa que la vida útil máxima práctica de una autorización respalda ### Tiempo de vida (TTL) del token de actualización en días \{#refresh-token-time-to-live-ttl-in-days} -_Disponibilidad: Aplicación nativa, web tradicional, SPA; Predeterminado: 14 días; Máximo: 180 días_ +_Disponibilidad: Aplicación nativa, Web tradicional, SPA; Predeterminado: 14 días; Máximo: 180 días_ La duración durante la cual un token de actualización puede usarse para solicitar nuevos tokens de acceso antes de que expire y se vuelva inválido. Las solicitudes de token extenderán el TTL del token de actualización a este valor. @@ -179,13 +183,13 @@ La actualización del TTL no está disponible en aplicaciones de una sola págin ::: :::caution TTL del token de actualización y TTL de la concesión -El TTL del token de actualización no es el único límite de expiración. Los tokens de actualización están vinculados a una concesión de aplicación, y el TTL predeterminado de la concesión en Logto es **180 días**. Cuando la concesión expira, las solicitudes de token de actualización fallan incluso si el token de actualización aún sería válido. +El TTL del token de actualización no es el único límite de expiración. Los tokens de actualización están vinculados a una concesión de app, y el TTL predeterminado de la concesión en Logto es **180 días**. Cuando la concesión expira, las solicitudes de token de actualización fallan incluso si el token de actualización aún sería válido. Para clientes donde las solicitudes de token actualizan el TTL del token de actualización, el TTL de la concesión actúa como la vida útil máxima absoluta para la cadena de tokens de actualización. Para SPA, el TTL fijo del token de actualización puede expirar antes que la concesión. ::: :::caution Token de actualización y vinculación de sesión -Cuando se emite un token de actualización **sin** el alcance `offline_access` en la solicitud de autorización, estará vinculado a la sesión del usuario. La sesión tiene un TTL fijo de **14 días**. Después de que la sesión expire, el token de actualización se vuelve inválido independientemente de su propia configuración de TTL. +Cuando un token de actualización se emite **sin** el alcance `offline_access` en la solicitud de autorización, estará vinculado a la sesión del usuario. La sesión tiene un TTL fijo de **14 días**. Después de que la sesión expire, el token de actualización se vuelve inválido independientemente de su propia configuración de TTL. Para asegurar que la configuración de TTL del token de actualización tenga efecto completo, asegúrate de incluir el alcance `offline_access` en tu solicitud de autorización. ::: @@ -196,14 +200,14 @@ El endpoint de cierre de sesión backchannel de OpenID Connect. Consulta [Cierre ### Máximo de concesiones permitidas (`maxAllowedGrants`) \{#max-allowed-grants-maxallowedgrants} -`maxAllowedGrants` es un campo opcional a nivel de aplicación bajo `customClientMetadata` que controla el número máximo de concesiones activas concurrentes por usuario para la aplicación actual. +`maxAllowedGrants` es un campo opcional a nivel de app bajo `customClientMetadata` que controla el número máximo de concesiones activas concurrentes por usuario para la app actual. - **Predeterminado**: `undefined` (sin límite) -- **Cuando se configura**: En cada autorización exitosa, Logto verifica el total de concesiones activas para el usuario en la aplicación actual (a través de navegadores y dispositivos). Si se supera el límite, Logto revoca las concesiones más antiguas. +- **Cuando se configura**: En cada autorización exitosa, Logto verifica el total de concesiones activas para el usuario en la app actual (a través de navegadores y dispositivos). Si se supera el límite, Logto revoca las concesiones más antiguas. -Esta configuración es útil cuando deseas limitar los dispositivos autenticados concurrentes por aplicación. +Esta configuración es útil cuando deseas limitar los dispositivos autenticados concurrentes por app. -Cada expulsión activa el evento [webhook](/developers/webhooks/webhooks-events#exception-hook-events) `Grant.LimitExceeded`, por lo que puedes notificar al usuario o rastrear con qué frecuencia se alcanza el límite. +Cada expulsión activa el evento [webhook Grant.LimitExceeded](/developers/webhooks/webhooks-events#exception-hook-events), para que puedas notificar al usuario o rastrear con qué frecuencia se alcanza el límite. :::note @@ -217,4 +221,4 @@ Este campo no es compatible con: ### Datos personalizados \{#custom-data} -Información adicional personalizada de la aplicación que no está incluida en las propiedades predefinidas de la aplicación; los usuarios pueden definir sus propios campos de datos personalizados según sus necesidades específicas, como configuraciones y ajustes específicos del negocio. +Información adicional personalizada de la aplicación no listada en las propiedades predefinidas de la aplicación; los usuarios pueden definir sus propios campos de datos personalizados según sus necesidades específicas, como configuraciones y ajustes específicos del negocio. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 3d2ebd62315..7955903794c 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,6 +4,7 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; @@ -14,23 +15,30 @@ La integración de aplicaciones de terceros de Logto te permite aprovechar Logto Un Proveedor de Identidad (IdP) es un servicio que verifica las identidades de los usuarios y gestiona sus credenciales de inicio de sesión. Después de confirmar la identidad de un usuario, el IdP genera tokens de autenticación o aserciones y permite al usuario acceder a varias aplicaciones o servicios sin necesidad de iniciar sesión nuevamente. -A diferencia de las aplicaciones que creaste en la guía [Integra Logto en tu aplicación](/integrate-logto/integrate-logto-into-your-application), que son desarrolladas y totalmente controladas por ti, las aplicaciones de terceros son servicios independientes desarrollados por desarrolladores externos o socios comerciales. +A diferencia de las aplicaciones que creaste en la guía [Integra Logto en tu aplicación](/integrate-logto/integrate-logto-into-your-application) que son desarrolladas y totalmente controladas por ti, las aplicaciones de terceros son servicios independientes desarrollados por desarrolladores externos o socios comerciales. -Este enfoque de integración es ideal para escenarios empresariales comunes. Puedes permitir que los usuarios accedan a aplicaciones de socios usando sus cuentas de Logto, igual que los usuarios empresariales inician sesión en Slack con Google Workspace. También puedes construir una plataforma abierta donde las aplicaciones de terceros puedan añadir la funcionalidad "Iniciar sesión con Logto", similar a "Iniciar sesión con Google". +Este enfoque de integración es ideal para escenarios empresariales comunes. Puedes permitir que los usuarios accedan a aplicaciones de socios usando sus cuentas de Logto, al igual que los usuarios empresariales inician sesión en Slack con Google Workspace. También puedes construir una plataforma abierta donde las aplicaciones de terceros puedan añadir la funcionalidad "Iniciar sesión con Logto", similar a "Iniciar sesión con Google". Logto es un servicio de identidad construido sobre el protocolo [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), proporcionando capacidades tanto de [autenticación (Authentication)](https://auth.wiki/authentication) como de [autorización (Authorization)](https://auth.wiki/authorization). Esto hace que integrar una aplicación de terceros OIDC sea tan sencillo como una aplicación web tradicional. Así, debido a que OIDC se basa en [OAuth 2.0](https://auth.wiki/oauth-2.0) añadiendo una capa de autenticación, también puedes integrar aplicaciones de terceros usando el protocolo OAuth. +## Dos formas de incorporar una aplicación de terceros \{#two-ways-to-onboard-a-third-party-app} + +- **Registrar la aplicación en Logto** (esta guía): tú creas la aplicación y configuras sus permisos y URIs de redirección. Úsalo cuando conozcas a tus socios. +- **[Aplicación dinámica](/integrate-logto/third-party-applications/dynamic-apps)**: los clientes se conectan sin pre-registro, usando una URL pública HTTPS que sirve su propio documento de metadatos como el client ID. Úsalo cuando cualquier cliente pueda conectarse, como clientes MCP y agentes de IA. + +Ambos métodos pueden usarse al mismo tiempo. + ## Crear una aplicación de terceros en Logto \{#create-a-third-party-application-in-logto} 1. Ve a Consola > Aplicaciones. -2. Haz clic en el botón "Crear aplicación". Selecciona "Aplicación de terceros" como tipo de aplicación y elige uno de los siguientes protocolos de integración: +2. Haz clic en el botón "Crear aplicación". Selecciona "Aplicación de terceros" como el tipo de aplicación y elige uno de los siguientes protocolos de integración: - OIDC / OAuth 3. Selecciona un tipo de aplicación según el tipo de aplicación de terceros: - **Web tradicional**: Aplicaciones renderizadas en el servidor (por ejemplo, Node.js, PHP, Java) que pueden almacenar de forma segura un secreto de cliente en el backend. - **Aplicación de una sola página (SPA)**: Aplicaciones renderizadas del lado del cliente (por ejemplo, React, Vue, Angular) que se ejecutan completamente en el navegador y no pueden almacenar secretos de forma segura. - - **Nativa**: Aplicaciones móviles o de escritorio (por ejemplo, iOS, Android, Electron) que se ejecutan en dispositivos de usuario. + - **Nativa**: Aplicaciones móviles o de escritorio (por ejemplo, iOS, Android, Electron) que se ejecutan en dispositivos de los usuarios. 4. Ingresa un nombre y una descripción para tu aplicación y haz clic en el botón "Crear". Se creará una nueva aplicación de terceros. Todas las aplicaciones de terceros creadas se catalogarán en la página de Aplicaciones bajo la pestaña "Aplicaciones de terceros". Esta organización te ayuda a distinguirlas de tus propias aplicaciones, facilitando la gestión de todas tus aplicaciones en un solo lugar. @@ -41,71 +49,71 @@ Para restringir qué usuarios pueden iniciar sesión en una aplicación de terce ### Encuentra las configuraciones de la aplicación \{#find-the-application-configurations} -En la página de detalles de la aplicación, puedes encontrar el [**ID de cliente**](/integrate-logto/application-data-structure#application-id), el [**secreto de cliente**](/integrate-logto/application-data-structure#application-secret) (solo para aplicaciones web tradicionales) y los endpoints OIDC necesarios para la integración. +En la página de detalles de la aplicación, puedes encontrar el [**Client ID**](/integrate-logto/application-data-structure#application-id), [**Client secret**](/integrate-logto/application-data-structure#application-secret) (solo para aplicaciones web tradicionales) y los endpoints OIDC necesarios para la integración. -Si el servicio de terceros admite descubrimiento OIDC, simplemente proporciona el **endpoint de descubrimiento**. De lo contrario, haz clic en **Mostrar detalles de endpoint** para ver todos los endpoints, incluidos el [endpoint de autorización](/integrate-logto/application-data-structure#authorization-endpoint) y el [endpoint de token](/integrate-logto/application-data-structure#token-endpoint). +Si el servicio de terceros admite descubrimiento OIDC, simplemente proporciona el **Discovery endpoint**. De lo contrario, haz clic en **Mostrar detalles de endpoint** para ver todos los endpoints, incluidos el [authorization endpoint](/integrate-logto/application-data-structure#authorization-endpoint) y el [token endpoint](/integrate-logto/application-data-structure#token-endpoint). -### Integración con servicios que admiten IdP de terceros \{#integrate-with-services-that-support-third-party-idp} +### Integrar con servicios que admiten IdP de terceros \{#integrate-with-services-that-support-third-party-idp} Si estás conectando un servicio o producto que admite de forma nativa la configuración de un proveedor de identidad externo (por ejemplo, plataformas SaaS empresariales, herramientas de colaboración), la configuración es sencilla: 1. Abre la página de configuración de IdP o SSO del servicio. -2. Copia el **ID de cliente** (y el **secreto de cliente** si es necesario) desde Logto y pégalos en la configuración del servicio. -3. Proporciona el **endpoint de descubrimiento** si el servicio admite auto-descubrimiento OIDC, o copia manualmente el **endpoint de autorización** y el **endpoint de token**. -4. Copia el **URI de redirección** desde la página de configuración del servicio y agrégalo a los URI de redirección permitidos de tu aplicación Logto. -5. Configura los **alcances (scopes)** si el servicio lo permite. Dado que Logto es un proveedor OIDC, incluye el alcance `openid` si necesitas autenticar usuarios (otorga acceso a un Token de ID (ID token) y al endpoint UserInfo). El alcance `openid` es opcional si solo necesitas acceso a recursos OAuth. +2. Copia el **Client ID** (y **Client secret** si es necesario) de Logto y pégalos en la configuración del servicio. +3. Proporciona el **Discovery endpoint** si el servicio admite auto-descubrimiento OIDC, o copia manualmente el **Authorization endpoint** y el **Token endpoint**. +4. Copia el **Redirect URI** de la página de configuración del servicio y agrégalo a los URIs de redirección permitidos de tu aplicación Logto. +5. Configura los **scopes** si el servicio lo permite. Como Logto es un proveedor OIDC, incluye el scope `openid` si necesitas autenticar usuarios (otorga acceso a un Token de ID (ID token) y al endpoint UserInfo). El scope `openid` es opcional si solo necesitas acceso a recursos OAuth. -El servicio gestionará automáticamente el flujo OAuth / OIDC una vez configurado. +El servicio gestionará el flujo OAuth / OIDC automáticamente una vez configurado. -### Integración mediante el protocolo OAuth / OIDC \{#integrate-via-oauth-protocol} +### Integrar vía protocolo OAuth / OIDC \{#integrate-via-oauth-protocol} -Si una aplicación de terceros necesita integrarse con Logto como IdP de forma programática, debe implementar el [Flujo de código de autorización (Authorization Code Flow)](https://auth.wiki/authorization-code-flow) estándar. Recomendamos usar una biblioteca cliente OAuth 2.0 / OIDC para tu lenguaje de programación para gestionar la implementación. +Si una aplicación de terceros necesita integrarse con Logto como IdP de forma programática, debe implementar el [Authorization Code Flow](https://auth.wiki/authorization-code-flow) estándar. Recomendamos usar una librería cliente OAuth 2.0 / OIDC para tu lenguaje de programación para manejar la implementación. -Las aplicaciones web tradicionales son **clientes confidenciales** que pueden almacenar de forma segura un secreto de cliente en el servidor backend. Consulta el [Flujo de código de autorización (Authorization Code Flow)](https://auth.wiki/authorization-code-flow) para detalles completos de implementación. +Las aplicaciones web tradicionales son **clientes confidenciales** que pueden almacenar de forma segura un secreto de cliente en el servidor backend. Consulta [Authorization Code Flow](https://auth.wiki/authorization-code-flow) para detalles completos de implementación. **Pasos clave:** -1. **Iniciar autorización**: Redirige al usuario al endpoint de autorización de Logto con `client_id`, `redirect_uri`, `response_type=code` y `scope`. -2. **Gestionar la devolución**: Recibe el `code` de autorización desde la redirección. -3. **Intercambiar tokens**: Desde tu backend, haz un POST al endpoint de token con el código, `client_id` y `client_secret`. +1. **Iniciar autorización**: Redirige al usuario al authorization endpoint de Logto con `client_id`, `redirect_uri`, `response_type=code` y `scope`. +2. **Gestionar callback**: Recibe el `code` de autorización desde la redirección. +3. **Intercambiar tokens**: Desde tu backend, haz un POST al token endpoint con el código, `client_id` y `client_secret`. -Las aplicaciones de una sola página y las aplicaciones nativas son **clientes públicos** que no pueden almacenar secretos de forma segura. En lugar de usar un secreto de cliente, estas aplicaciones deben usar [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) para una autorización segura. Consulta el [Flujo de código de autorización (Authorization Code Flow)](https://auth.wiki/authorization-code-flow) y [PKCE](https://auth.wiki/pkce) para detalles completos de implementación. +Las aplicaciones de una sola página y las aplicaciones nativas son **clientes públicos** que no pueden almacenar secretos de forma segura. En lugar de usar un client secret, estas aplicaciones deben usar [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) para una autorización segura. Consulta [Authorization Code Flow](https://auth.wiki/authorization-code-flow) y [PKCE](https://auth.wiki/pkce) para detalles completos de implementación. **Pasos clave:** 1. **Generar parámetros PKCE**: Crea un `code_verifier` y deriva el `code_challenge` (SHA-256). -2. **Iniciar autorización**: Redirige al usuario al endpoint de autorización con `code_challenge` y `code_challenge_method=S256`. -3. **Gestionar la devolución**: Recibe el `code` de autorización desde la redirección. -4. **Intercambiar tokens**: Haz un POST al endpoint de token con el código y el `code_verifier` original. +2. **Iniciar autorización**: Redirige al usuario al authorization endpoint con `code_challenge` y `code_challenge_method=S256`. +3. **Gestionar callback**: Recibe el `code` de autorización desde la redirección. +4. **Intercambiar tokens**: Haz un POST al token endpoint con el código y el `code_verifier` original. -### Integración mediante device flow \{#integrate-via-device-flow} +### Integrar vía device flow \{#integrate-via-device-flow} -Para aplicaciones nativas de terceros que se ejecutan en dispositivos con entrada limitada (por ejemplo, smart TVs, consolas de juegos, herramientas CLI), el flujo estándar de código de autorización basado en redirección puede no ser factible. En estos casos, la aplicación puede usar el [Device Authorization Grant de OAuth 2.0](https://auth.wiki/device-flow). +Para aplicaciones nativas de terceros que se ejecutan en dispositivos con entrada limitada (por ejemplo, smart TVs, consolas de juegos, herramientas CLI), el flujo estándar de autorización basado en redirección puede no ser factible. En estos casos, la aplicación puede usar el [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow). -Con el device flow, el dispositivo muestra un código de usuario y una URL de verificación. El usuario visita la URL en un dispositivo separado (teléfono, portátil), introduce el código y completa la autenticación allí. El dispositivo consulta el endpoint de token de Logto hasta que la autorización se complete. +Con el device flow, el dispositivo muestra un código de usuario y una URL de verificación. El usuario visita la URL en un dispositivo separado (teléfono, portátil), ingresa el código y completa la autenticación allí. El dispositivo consulta el token endpoint de Logto hasta que la autorización se complete. :::note -Antes de implementar el device flow, asegúrate de configurar los [permisos](/integrate-logto/third-party-applications/permission-management) requeridos para tu aplicación de terceros en la Consola de Logto. Las aplicaciones de terceros que soliciten alcances no habilitados se les denegará el acceso. +Antes de implementar el device flow, asegúrate de configurar los [permisos](/integrate-logto/third-party-applications/permission-management) requeridos para tu aplicación de terceros en la Consola de Logto. Las aplicaciones de terceros que soliciten scopes no habilitados se les denegará el acceso. ::: Consulta la [Guía rápida de device flow](/quick-starts/device-flow) para detalles completos de implementación. -## Pantalla de consentimiento para aplicaciones de terceros OIDC \{#consent-screen-for-oidc-third-party-applications} +## Pantalla de consentimiento para aplicaciones OIDC de terceros \{#consent-screen-for-oidc-third-party-applications} -Por razones de seguridad, todas las aplicaciones de terceros OIDC serán redirigidas a una [pantalla de consentimiento (Consent screen)](/end-user-flows/consent-screen) para la autorización del usuario después de ser autenticadas por Logto. +Por razones de seguridad, todas las aplicaciones OIDC de terceros serán redirigidas a una [pantalla de consentimiento (Consent screen)](/end-user-flows/consent-screen) para la autorización del usuario después de ser autenticadas por Logto. -Todos los [permisos de perfil de usuario](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) solicitados por terceros, [alcances de recursos de API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [permisos de organización](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) e información de membresía de organización se mostrarán en la pantalla de consentimiento. +Todos los [permisos de perfil de usuario](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) solicitados por terceros, [alcances de recursos de API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [permisos de organización](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) e información de membresía de la organización se mostrarán en la pantalla de consentimiento. -Estos permisos solicitados solo se otorgarán a las aplicaciones de terceros después de que el usuario haga clic en el botón "Autorizar". +Estos permisos solicitados solo serán concedidos a las aplicaciones de terceros después de que el usuario haga clic en el botón "Autorizar".
pantalla de consentimiento @@ -119,7 +127,7 @@ Estos permisos solicitados solo se otorgarán a las aplicaciones de terceros des type: 'link', label: 'Gestión de permisos', href: '/integrate-logto/third-party-applications/permission-management', - description: 'Aprende cómo gestionar los permisos para tu aplicación de terceros OIDC.', + description: 'Aprende cómo gestionar permisos para tu aplicación OIDC de terceros.', customProps: { icon: , }, @@ -134,6 +142,16 @@ Estos permisos solicitados solo se otorgarán a las aplicaciones de terceros des icon: , }, }, + { + type: 'link', + label: 'Aplicación dinámica (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + 'Permite que los clientes OAuth se conecten sin pre-registro, usando una URL de documento de metadatos como su client ID.', + customProps: { + icon: , + }, + }, ]} /> @@ -142,11 +160,11 @@ Estos permisos solicitados solo se otorgarán a las aplicaciones de terceros des
-### ¿Cómo aseguramos que los usuarios solo puedan otorgar permisos que realmente tienen en la pantalla de consentimiento? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} +### ¿Cómo aseguramos que los usuarios solo puedan conceder permisos que realmente tienen en la pantalla de consentimiento? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} -Logto utiliza el Control de acceso basado en roles (RBAC) para gestionar los permisos de los usuarios. En la pantalla de consentimiento, solo se mostrarán los alcances (permisos) ya asignados al usuario, a través de sus roles. Si una aplicación de terceros solicita alcances que el usuario no tiene, estos serán excluidos para evitar consentimientos no autorizados. +Logto utiliza el Control de Acceso Basado en Roles (RBAC) para gestionar los permisos de los usuarios. En la pantalla de consentimiento, solo se mostrarán los alcances (permisos) ya asignados al usuario—a través de sus roles. Si una aplicación de terceros solicita alcances que el usuario no tiene, estos serán excluidos para evitar consentimientos no autorizados. Para gestionar esto: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..b633fbb79f6 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,99 @@ +--- +description: Permite que los clientes OAuth se conecten a tu tenant sin pre-registro utilizando una URL de documento de metadatos de ID de cliente como su client ID. +sidebar_label: Aplicación dinámica (CIMD) +sidebar_position: 3 +--- + +# Aplicación dinámica (CIMD) + +La aplicación dinámica permite que los clientes OAuth se conecten a tu tenant sin pre-registro. En lugar de un client ID emitido por Logto, el cliente utiliza una URL pública HTTPS como su `client_id`. La URL sirve un documento JSON que describe al cliente, llamado [documento de metadatos de ID de cliente (CIMD)](https://auth.wiki/client-id-metadata-document). Logto obtiene el documento y trata al cliente como una [aplicación de terceros](/integrate-logto/third-party-applications). + +La aplicación dinámica implementa el borrador IETF [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html). + +## Cuándo usar la aplicación dinámica \{#when-to-use-dynamic-app} + +El pre-registro funciona cuando conoces a tus socios. No funciona cuando cualquier cliente puede conectarse, lo cual es común en el ecosistema [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents): un usuario le pide a su agente de IA que se conecte a tu servicio, y el agente nunca ha interactuado con tu tenant antes. + +Con la aplicación dinámica, el cliente publica sus propios metadatos en una URL que posee, y esa URL es su identidad. No es necesario crear nada previamente en tu tenant. + +| | Aplicación de terceros registrada | Aplicación dinámica | +| ------------- | --------------------------------- | -------------------------------------------- | +| Client ID | Emitido por Logto | Una URL HTTPS propiedad del cliente | +| Registro | Requerido | No requerido | +| Client secret | Soportado | No soportado | +| Permisos | Por aplicación | Compartidos por todos los clientes dinámicos | +| Grant types | Depende del tipo de app | `authorization_code` y `refresh_token` | + +Los clientes dinámicos son clientes públicos, por lo que siempre usan [PKCE](https://auth.wiki/pkce). Puedes usar ambos modelos al mismo tiempo. Un socio en quien confías aún puede tener una aplicación registrada con sus propios permisos. + +## Habilitar la aplicación dinámica \{#enable-dynamic-app} + +1. Ve a Consola > Aplicaciones y abre la pestaña **Aplicaciones de terceros**. +2. Haz clic en **Crear aplicación** y selecciona la tarjeta **Aplicación dinámica**. Esto habilita una función a nivel de tenant en lugar de crear una aplicación. +3. Confirma en el diálogo. Una vez habilitado, cualquier cliente OAuth con una URL válida pública HTTPS como client ID puede iniciar una solicitud de autorización para tu tenant. +4. Abre la aplicación dinámica desde la lista de aplicaciones y ve a la pestaña **Permisos** para otorgar permisos. + +La aplicación dinámica no tiene nombre editable, URIs de redirección ni credenciales. Cada cliente proporciona los suyos en su documento de metadatos. + +:::note +La aplicación dinámica requiere la [protección SSRF del proveedor OIDC](/concepts/core-service/configuration#oidc-provider-ssrf-protection), ya que Logto obtiene documentos de metadatos de internet. Las instancias autogestionadas que la deshabiliten no pueden habilitar la aplicación dinámica. +::: + +### Otorgar permisos \{#grant-permissions} + +La pestaña **Permisos** define los permisos máximos compartidos por todos los clientes dinámicos. Funciona como la [gestión de permisos](/integrate-logto/third-party-applications/permission-management) de una aplicación de terceros registrada, con secciones de **Usuario** y **Organización**. + +Solicitar un permiso de usuario que no esté otorgado resulta en un error, mientras que los permisos de recursos de API y de organización que no estén otorgados se ignoran. Los usuarios también solo consienten los permisos que tienen a través de sus [roles](/authorization/role-based-access-control). + +Dado que todos los clientes dinámicos comparten este conjunto, mantenlo al mínimo. + +## Publicar un documento de metadatos de ID de cliente \{#publish-a-client-id-metadata-document} + +Si estás construyendo un cliente que se conecta a Logto, hospeda un documento de metadatos y usa su URL como tu `client_id`. La URL debe usar el esquema `https` y no contener fragmentos, información de usuario ni segmentos de ruta con punto. Logto envía una solicitud `GET` a la URL y espera un objeto JSON. + +Por ejemplo, Claude Code usa `https://claude.ai/oauth/claude-code-client-metadata`, que sirve: + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +Los nombres de los campos son los mismos que en [OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591#section-2). Ten en cuenta que: + +- `client_id` debe ser idéntico a la URL que sirve el documento. +- Los clientes dinámicos son clientes públicos. El documento no debe contener `client_secret`, y `token_endpoint_auth_method` no debe ser un método de secreto compartido. Usa [PKCE](https://auth.wiki/pkce) en su lugar. +- Las URIs de metadatos como `client_uri`, `logo_uri`, `tos_uri` y `policy_uri` deben ser URLs absolutas `https`. Esto no aplica a `redirect_uris`, por lo que los clientes nativos aún pueden usar direcciones loopback como en el ejemplo anterior. +- Las `redirect_uris` se comparan como cadenas exactas, excepto que las direcciones loopback pueden coincidir con cualquier puerto. También se admiten [patrones comodín](/integrate-logto/application-data-structure#wildcard-patterns). +- `scope`, `grant_types` y `response_types` son decididos por Logto. Si el documento los declara, los valores se ignoran. Los clientes dinámicos solo pueden usar el flujo de código de autorización y tokens de actualización. + +Logto almacena en caché el documento hasta por 24 horas, siguiendo los encabezados `Cache-Control` y `Expires` de tu respuesta. Establécelos según la frecuencia con la que esperas actualizar el documento. + +## Pantalla de consentimiento \{#consent-screen} + +Los clientes dinámicos son aplicaciones de terceros, por lo que la [pantalla de consentimiento (Consent screen)](/end-user-flows/consent-screen) siempre se muestra. + +La pantalla de consentimiento también muestra un aviso de que el cliente no está registrado. El nombre y el logo del cliente provienen del documento de metadatos, por lo que pueden imitar cualquier marca. También se muestra el host de la URL del client ID, ya que es la única parte que el cliente no puede falsificar. + +## Gestionar autorizaciones \{#manage-authorizations} + +Las autorizaciones otorgadas a clientes dinámicos son [concesiones (grants)](/sessions/grants-management) regulares de terceros. Los usuarios pueden revisarlas y revocarlas en la configuración de la cuenta, y los administradores pueden gestionarlas a través de la Management API. La URL del client ID se utiliza para identificar al cliente. + +Deshabilitar la aplicación dinámica detiene nuevas solicitudes de autorización, mientras que las concesiones existentes se mantienen. Revocar una concesión requiere que el cliente obtenga nuevamente la autorización del usuario, pero los tokens de acceso emitidos previamente pueden seguir siendo válidos hasta que expiren. + +## Limitaciones \{#limitations} + +- Solo se admite el flujo de código de autorización con PKCE y tokens de actualización. Las credenciales de cliente, el flujo de dispositivo y el intercambio de tokens no están disponibles. +- Los permisos y la personalización de marca no se pueden configurar por cliente. +- El [control de acceso a nivel de aplicación](/authorization/app-level-access-control) no aplica a los clientes dinámicos, ya que no tienen un registro de aplicación. + +## Recursos relacionados \{#related-resources} + +Aplicación de terceros (OAuth / OIDC) + + Habilita el acceso de agentes de IA de terceros a tu servidor MCP + diff --git a/i18n/es/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/es/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index 775ce73b05e..c29e0b151ae 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -6,23 +6,23 @@ sidebar_position: 2 Las concesiones de aplicaciones representan el estado de autorización del usuario para aplicaciones cliente específicas. -Utiliza la gestión de concesiones cuando los usuarios o administradores necesiten revisar las aplicaciones autorizadas y revocar el acceso a las aplicaciones sin revocar toda la sesión de Logto. +Utiliza la gestión de concesiones cuando los usuarios o administradores necesiten revisar las aplicaciones autorizadas y revocar el acceso de una aplicación sin revocar toda la sesión de Logto. -Cuando se revocan las concesiones, los tokens de acceso opacos y los tokens de actualización emitidos previamente para esas concesiones se invalidan. +Cuando se revocan las concesiones, los tokens opacos de acceso (opaque access tokens) y los tokens de actualización (refresh tokens) emitidos previamente para esas concesiones se invalidan. Los tokens de acceso JWT son sin estado, por lo que los emitidos previamente siguen siendo válidos hasta que expiran. ## Elige el camino correcto \{#choose-the-right-path} -| Escenario | Camino recomendado | -| -------------------------------------------------------------------------------------------------------------- | ------------------ | -| Permitir que los usuarios conectados gestionen sus propias autorizaciones de aplicaciones | Account API | -| Permitir que los administradores o equipos de soporte gestionen las concesiones para un usuario objetivo | Management API | -| Permitir que los operadores gestionen las autorizaciones de aplicaciones de terceros en la interfaz de usuario | Admin Console | +| Escenario | Ruta recomendada | +| -------------------------------------------------------------------------------------------------------- | ---------------- | +| Permitir que los usuarios autenticados gestionen sus propias autorizaciones de aplicaciones | Account API | +| Permitir que los administradores o equipos de soporte gestionen las concesiones para un usuario objetivo | Management API | +| Permitir que los operadores gestionen autorizaciones de aplicaciones de terceros en la interfaz | Admin Console | -## APIs de gestión directa de concesiones \{#direct-grant-management-apis} +## APIs directas para la gestión de concesiones \{#direct-grant-management-apis} ### Account API (autoservicio) \{#account-api-self-service} -Utiliza Account API en las páginas de configuración de cuentas de usuario final: +Utiliza Account API en las páginas de configuración de cuenta del usuario final: - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` @@ -30,20 +30,22 @@ Utiliza Account API en las páginas de configuración de cuentas de usuario fina ### Management API (herramientas de administración) \{#management-api-admin-tools} -Utiliza Management API en herramientas de administración y flujos de trabajo de soporte: +Utiliza Management API en herramientas de administración y flujos de soporte: - `GET /api/users/{userId}/grants` - `DELETE /api/users/{userId}/grants/{grantId}` - Referencia: [Gestionar aplicaciones autorizadas por el usuario (concesiones)](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) -### Filtrar lista de concesiones por tipo de aplicación \{#filter-grant-list-by-app-type} +### Filtrar la lista de concesiones por tipo de aplicación \{#filter-grant-list-by-app-type} -Los puntos finales de listado de concesiones admiten el parámetro de consulta opcional `appType`: +Los endpoints de listado de concesiones admiten el parámetro de consulta opcional `appType`: -- `appType=firstParty`: Lista solo las concesiones de aplicaciones de primera parte. -- `appType=thirdParty`: Lista solo las concesiones de aplicaciones de terceros. +- `appType=firstParty`: Listar solo concesiones de aplicaciones de primera parte. +- `appType=thirdParty`: Listar solo concesiones de aplicaciones de terceros. - Omitir `appType`: Devuelve todas las concesiones activas. +Los clientes [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) son aplicaciones de terceros, por lo que sus concesiones se devuelven con `appType=thirdParty`. La URL del ID de cliente se utiliza como el ID de la aplicación. + ## Gestionar autorizaciones de aplicaciones de terceros en la Consola \{#manage-third-party-app-authorizations-in-console} En Logto Console, utiliza la página de detalles del usuario para ver y revocar aplicaciones de terceros autorizadas. @@ -52,12 +54,12 @@ En Logto Console, utiliza la página de detalles del usuario para ver y revocar ## Revocar concesiones al revocar una sesión \{#revoke-grants-when-revoking-a-session} -Al revocar una sesión a través de `DELETE /api/my-account/sessions/{sessionId}`, utiliza el parámetro de consulta opcional `revokeGrantsTarget` para controlar el alcance de la revocación de concesiones: +Al revocar una sesión mediante `DELETE /api/my-account/sessions/{sessionId}`, utiliza el parámetro de consulta opcional `revokeGrantsTarget` para controlar el alcance de la revocación de concesiones: -- `all`: Revoca concesiones para todas las aplicaciones asociadas con la sesión. -- `firstParty`: Revoca concesiones solo para aplicaciones de primera parte. +- `all`: Revoca las concesiones para todas las aplicaciones asociadas con la sesión. +- `firstParty`: Revoca las concesiones solo para aplicaciones de primera parte. -Para el comportamiento a nivel de sesión y el contexto del punto final, consulta [Gestionar sesiones de usuario](/sessions/manage-user-sessions) y [Cerrar sesión](/end-user-flows/sign-out). +Para el comportamiento a nivel de sesión y el contexto del endpoint, consulta [Gestionar sesiones de usuario](/sessions/manage-user-sessions) y [Cerrar sesión](/end-user-flows/sign-out). ## Recursos relacionados \{#related-resources} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/es/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index cb7dc97bee5..092a70fabcb 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/es/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -2,14 +2,20 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- ## Configura un agente de IA de terceros en Logto \{#configure-third-party-ai-agent-in-logto} -Para permitir que el agente de IA de terceros acceda a {props.serviceName ?? 'tu servicio'}, necesitas configurar una **aplicación de terceros (third-party app)** en Logto. Esta aplicación se utilizará para representar al agente de IA y obtener las credenciales necesarias para la autenticación y autorización. +Para permitir que el agente de IA de terceros acceda a {props.serviceName ?? 'tu servicio'}, necesitas configurar una **aplicación de terceros** en Logto. Esta aplicación se utilizará para representar al agente de IA y obtener las credenciales necesarias para la autenticación y autorización. :::info[¿Qué es una aplicación de terceros?] -Una **aplicación de terceros (third-party app)** es una aplicación creada por desarrolladores externos (no el propietario del recurso) que necesita el consentimiento del usuario para acceder a recursos protegidos. A diferencia de las aplicaciones de primera parte (tus propias aplicaciones), las aplicaciones de terceros mostrarán una pantalla de consentimiento solicitando a los usuarios aprobar permisos específicos antes de acceder a sus datos. Esto asegura que los usuarios tengan control sobre qué datos comparten con servicios externos. +Una **aplicación de terceros** es una aplicación creada por desarrolladores externos (no el propietario del recurso) que necesita el consentimiento del usuario para acceder a recursos protegidos. A diferencia de las aplicaciones de primer partido (tus propias aplicaciones), las aplicaciones de terceros mostrarán una pantalla de consentimiento solicitando a los usuarios que aprueben permisos específicos antes de acceder a sus datos. Esto garantiza que los usuarios tengan control sobre qué datos comparten con servicios externos. Para obtener más información, consulta [Aplicaciones de terceros](/integrate-logto/third-party-applications). ::: +Hay tres formas de incorporar agentes de IA: + +- [Crear manualmente la aplicación en la Consola](#manually-create-a-third-party-app-in-logto), para pruebas o algunos agentes conocidos. +- [Construir un servicio de registro sobre la Management API](#allow-developers-to-create-third-party-apps-in-logto), si deseas controlar quién obtiene credenciales. +- [Habilitar aplicación dinámica](#let-any-ai-agent-connect-without-pre-registration), si cualquier agente puede conectarse y no quieres un paso de registro. + ### Permitir que los desarrolladores creen aplicaciones de terceros en Logto \{#allow-developers-to-create-third-party-apps-in-logto} Si estás construyendo un marketplace o deseas permitir que los desarrolladores creen aplicaciones de terceros en Logto, puedes aprovechar la [Logto Management API](/integrate-logto/interact-with-management-api) para crear aplicaciones de terceros de forma programática. Esto permite a los desarrolladores registrar sus aplicaciones y obtener las credenciales necesarias para la autenticación. @@ -23,30 +29,47 @@ sequenceDiagram participant Logto as Logto Management API Developer->>Server: Registrar aplicación Server->>Logto: Crear aplicación - Logto->>Server: ID de la app, secreto, etc. - Server->>Developer: ID de la app, secreto, etc. + Logto->>Server: ID de la aplicación, secreto, etc. + Server->>Developer: ID de la aplicación, secreto, etc. +``` + +Alternativamente, puedes crear manualmente aplicaciones de terceros en la Consola de Logto para familiarizarte con el proceso. + +### Permitir que cualquier agente de IA se conecte sin pre-registro \{#let-any-ai-agent-connect-without-pre-registration} + +En un ecosistema MCP abierto, normalmente no conoces los agentes de antemano. [Aplicación dinámica](/integrate-logto/third-party-applications/dynamic-apps) elimina el paso de registro: el agente utiliza una URL pública HTTPS que sirve su propio documento de metadatos de cliente como su `client_id`, y Logto lo resuelve cuando llega la solicitud de autorización. + +```mermaid +sequenceDiagram + participant Agent as Agente de IA (cliente MCP) + participant Logto + participant Metadata as URL del documento de metadatos del agente + Agent->>Logto: Solicitud de autorización con la URL del client ID + Logto->>Metadata: Obtener el documento de metadatos del client ID + Metadata->>Logto: Nombre del cliente, logo, URIs de redirección, etc. + Logto->>Agent: Pantalla de consentimiento, luego código de autorización ``` -Alternativamente, puedes crear manualmente aplicaciones de terceros en Logto Console para familiarizarte con el proceso. +Aún controlas qué agentes pueden solicitar a través de los permisos otorgados a la aplicación dinámica, y cada autorización pasa por la pantalla de consentimiento del usuario. ### Crear manualmente una aplicación de terceros en Logto \{#manually-create-a-third-party-app-in-logto} -Puedes crear manualmente una aplicación de terceros en Logto Console para fines de prueba o integraciones puntuales. Esto es útil cuando deseas probar rápidamente la integración sin implementar un flujo completo de registro de clientes. +Puedes crear manualmente una aplicación de terceros en la Consola de Logto para fines de prueba o integraciones ad-hoc. Esto es útil cuando deseas probar rápidamente la integración sin implementar un flujo completo de registro de clientes. -1. Inicia sesión en tu Logto Console. +1. Inicia sesión en tu Consola de Logto. 2. Ve a **Aplicaciones** → **Crear aplicación** → **Aplicación de terceros** -> **OIDC**. 3. Rellena el nombre de la aplicación y otros campos requeridos, luego haz clic en **Crear aplicación**. 4. Haz clic en la pestaña **Permisos**, en la sección **Usuario**, haz clic en "Agregar". 5. En el diálogo que se abre -> **Datos de usuario** -> selecciona los permisos **`profile`**, **`email`**, luego haz clic en **Guardar**. -6. En la aplicación de terceros, configura los alcances (scopes) para solicitar los permisos `openid profile email`. +6. En la aplicación de terceros, configura los alcances para solicitar los permisos (alcances) `openid profile email`. - **Nota**: `openid` es requerido para OIDC, y `profile` y `email` son los permisos que agregaste en el paso anterior. + **Nota**: `openid` es obligatorio para OIDC, y `profile` y `email` son los permisos que agregaste en el paso anterior. -7. Configura el **redirect URI** de tu aplicación de terceros según corresponda. Recuerda actualizar también el redirect URI en Logto. +7. Configura la **URI de redirección** de tu aplicación de terceros en consecuencia. Recuerda actualizar también la URI de redirección en Logto. Permisos de la aplicación de terceros diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx index 541696b4b84..e80e147a9fb 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx @@ -21,21 +21,21 @@ Lorsque le contrôle d’accès au niveau de l’application est désactivé, to Lorsqu’il est activé, un utilisateur ne peut accéder à l’application que s’il correspond à au moins une règle configurée. Si l’utilisateur ne correspond à aucune règle, Logto refuse la tentative de connexion et affiche une page d’accès refusé avant que l’application ne reçoive des jetons. -Le contrôle d’accès au niveau de l’application est évalué lors du flux d’autorisation et du renouvellement de jeton. Cela signifie : +Le contrôle d’accès au niveau de l’application est évalué pendant le flux d’autorisation et le renouvellement de jeton. Cela signifie : - Les utilisateurs sans accès sont bloqués avant de pouvoir terminer la connexion à l’application. - Les autorisations d’application existantes sont vérifiées à nouveau lorsque des jetons de rafraîchissement sont utilisés pour demander de nouveaux jetons. -- La mise à jour des règles affecte les futures vérifications d’autorisation et de renouvellement de jeton, sans modifier la session globale Logto de l’utilisateur. +- La mise à jour des règles affecte les vérifications futures d’autorisation et de renouvellement de jeton, sans modifier la session globale Logto de l’utilisateur. :::note -Le contrôle d’accès au niveau de l’application est distinct du [contrôle d’accès basé sur les rôles (RBAC)](/authorization/role-based-access-control). Le RBAC contrôle ce qu’un utilisateur peut faire après l’authentification en délivrant des permissions (portées) dans les jetons d’accès. Le contrôle d’accès au niveau de l’application contrôle si un utilisateur peut accéder à une application particulière ou non. +Le contrôle d’accès au niveau de l’application est distinct du [contrôle d’accès basé sur les rôles (RBAC)](/authorization/role-based-access-control). Le RBAC contrôle ce qu’un utilisateur peut faire après l’authentification en émettant des permissions (portées) dans les jetons d’accès. Le contrôle d’accès au niveau de l’application contrôle si un utilisateur peut accéder à une application particulière ou non. ::: ## Types de règles \{#rule-types} Vous pouvez configurer les règles d’autorisation suivantes : -| Type de règle | Ce qu’elle autorise | +| Type de règle | Ce qu’elle permet | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | **Utilisateurs** | Des utilisateurs spécifiques peuvent accéder à l’application. | | **Rôles d’utilisateur** | Les utilisateurs affectés à des rôles d’utilisateur sélectionnés peuvent accéder à l’application. | @@ -44,7 +44,7 @@ Vous pouvez configurer les règles d’autorisation suivantes : Les règles sont additives. Un utilisateur n’a besoin de correspondre qu’à une seule règle pour accéder à l’application. -Par exemple, si une application possède à la fois une règle de rôle d’utilisateur "Équipe support" et une règle de rôle d’organisation "BigTree - Admin", un utilisateur peut accéder à l’application s’il est affecté au rôle Équipe support, ou s’il est Admin dans l’organisation BigTree. +Par exemple, si une application possède à la fois une règle de rôle d’utilisateur « Équipe support » et une règle de rôle d’organisation « BigTree - Admin », un utilisateur peut accéder à l’application s’il a le rôle Équipe support, ou s’il est Admin dans l’organisation BigTree. ## Configurer le contrôle d’accès au niveau de l’application \{#configure-app-level-access-control} @@ -82,7 +82,7 @@ Le contrôle d’accès au niveau de l’application ne termine pas la session g Pour l’application restreinte : - Un utilisateur qui ne correspond plus à aucune règle d’autorisation sera bloqué la prochaine fois qu’il passera par le flux d’autorisation de l’application. -- Si l’utilisateur dispose déjà d’autorisations liées à l’application, Logto vérifie à nouveau les règles lorsque l’application utilise un jeton de rafraîchissement pour demander de nouveaux jetons. Si l’utilisateur n’a plus accès, Logto refuse la requête de jeton. +- Si l’utilisateur dispose déjà d’autorisations liées à l’application, Logto vérifie à nouveau les règles lorsque l’application utilise un jeton de rafraîchissement pour demander de nouveaux jetons. Si l’utilisateur n’a plus accès, Logto refuse la demande de jeton. Cela permet de lier les décisions d’accès à l’application tout en évitant des perturbations inutiles pour les autres applications. @@ -91,20 +91,24 @@ Cela permet de lier les décisions d’accès à l’application tout en évitan Pour les [applications tierces](/integrate-logto/third-party-applications), le contrôle d’accès au niveau de l’application et la gestion des permissions résolvent des problèmes différents : - **Contrôle d’accès au niveau de l’application** détermine si un utilisateur est autorisé à se connecter à l’application tierce. -- **Gestion des permissions** détermine quels portées de profil utilisateur, portées de ressource API et portées d’organisation l’application tierce peut demander sur l’écran de consentement. +- **Gestion des permissions** détermine quels portées de profil utilisateur, portées de ressources API et portées d’organisation l’application tierce peut demander sur l’écran de consentement. Si les deux sont configurés, l’utilisateur doit passer le contrôle d’accès au niveau de l’application avant de pouvoir autoriser l’application tierce. +:::note +Le contrôle d’accès au niveau de l’application s’applique uniquement aux applications enregistrées. Les clients [application dynamique](/integrate-logto/third-party-applications/dynamic-apps) n’ont pas d’enregistrement d’application, ils ne peuvent donc pas être restreints de cette manière. Leur accès est limité par les permissions que vous accordez à l’application dynamique et par le consentement de l’utilisateur. +::: + ## Relation avec Application protégée \{#relationship-with-protected-app} Pour une [Application protégée](/integrate-logto/protected-app), le contrôle d’accès au niveau de l’application restreint qui peut passer la couche d’authentification Logto et atteindre le serveur d’origine protégé. -Les règles d’authentification de l’Application protégée déterminent toujours quelles routes nécessitent une authentification. Le contrôle d’accès au niveau de l’application détermine quels utilisateurs Logto authentifiés sont autorisés à accéder à l’application protégée. +Les règles d’authentification de l’Application protégée déterminent toujours quelles routes nécessitent une authentification. Le contrôle d’accès au niveau de l’application détermine quels utilisateurs Logto authentifiés sont autorisés à accéder à l’application Application protégée. ## Bonnes pratiques \{#best-practices} - Commencez par des règles de rôle d’utilisateur ou de rôle d’organisation lorsque c’est possible. Elles sont plus faciles à maintenir que de longues listes d’utilisateurs individuels. - Utilisez des règles d’organisation lorsque tous les membres d’une organisation doivent accéder à l’application. - Utilisez des règles de rôle d’organisation lorsque seuls certains membres d’une organisation doivent accéder à l’application. -- Révisez les règles d’accès lorsque les utilisateurs changent de rôle, rejoignent ou quittent des organisations. -- Gardez les permissions RBAC et le contrôle d’accès au niveau de l’application séparés dans votre modèle mental : le contrôle d’accès au niveau de l’application répond à "Cet utilisateur peut-il accéder à cette application ?", tandis que le RBAC répond à "Que peut faire cet utilisateur après avoir accédé aux API ou aux fonctionnalités d’organisation ?" +- Passez en revue les règles d’accès lorsque les utilisateurs changent de rôle, rejoignent des organisations ou quittent des organisations. +- Gardez les permissions RBAC et le contrôle d’accès au niveau de l’application séparés dans votre modèle mental : le contrôle d’accès au niveau de l’application répond à « Cet utilisateur peut-il accéder à cette application ? », tandis que le RBAC répond à « Que peut faire cet utilisateur après avoir accédé aux API ou aux fonctionnalités d’organisation ? » diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/fr/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index a1dd1406272..333e4d3ad72 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/fr/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -24,28 +24,30 @@ Dans les valeurs par défaut, `protocol` sera soit `http` soit `https` selon vot | NODE_ENV | `undefined` | 'production' | 'test' | undefined | Le type d'environnement dans lequel Logto s'exécute. | | PORT | `3001` | `number` | Le port local sur lequel Logto écoute. | | ADMIN_PORT | `3002` | `number` | Le port local sur lequel la Console d'administration Logto écoute. | -| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Définissez-le à `1` ou `true` pour désactiver le port de la Console d'administration. Si `ADMIN_ENDPOINT` n'est pas défini, cela désactivera complètement la Console d'administration. | +| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Définissez-le à `1` ou `true` pour désactiver le port pour la Console d'administration. Si `ADMIN_ENDPOINT` n'est pas défini, cela désactivera complètement la Console d'administration. | | DB_URL | N/A | `string` | Le [DSN Postgres](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6) pour la base de données Logto. | | DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) `statement_timeout` PostgreSQL en millisecondes. Utilisez une chaîne numérique (par exemple, `5000`) pour le définir, ou `DISABLE_TIMEOUT` pour omettre le paramètre de démarrage (recommandé pour PgBouncer/RDS Proxy). Si non défini ou invalide, la valeur par défaut est 60000 ms. | | HTTPS_CERT_PATH | `undefined` | string | undefined | Voir [Activation de HTTPS](#enabling-https) pour plus de détails. | | HTTPS_KEY_PATH | `undefined` | string | undefined | Idem. | | TRUST_PROXY_HEADER | `false` | `boolean` | Idem. | -| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | Vous pouvez spécifier une URL avec votre domaine personnalisé pour les tests en ligne ou la production. Cela affectera également la valeur de l'[identifiant d'émetteur OIDC](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier). | +| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | Vous pouvez spécifier une URL avec votre domaine personnalisé pour les tests en ligne ou la production. Cela affectera également la valeur de l'[identifiant d’émetteur OIDC](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier). | | ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | Vous pouvez spécifier une URL avec votre domaine personnalisé pour la production (par exemple `ADMIN_ENDPOINT=https://admin.domain.com`). Cela affectera également la valeur des URI de redirection de la Console d'administration. | | CASE_SENSITIVE_USERNAME | `true` | `boolean` | Spécifie si le nom d'utilisateur est sensible à la casse. Faites attention lors de la modification de cette valeur ; les changements n'ajusteront pas automatiquement les données existantes de la base de données, nécessitant une gestion manuelle. | | SECRET_VAULT_KEK | `undefined` | `string` | La clé de chiffrement principale (KEK) utilisée pour chiffrer les clés de chiffrement des données (DEK) dans le [Secret Vault](/secret-vault). Requise pour le bon fonctionnement du Secret Vault. Doit être une chaîne encodée en base64. AES-256 (32 octets) est recommandé. Exemple : `crypto.randomBytes(32).toString('base64')` | | PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | Période de grâce en secondes pour la rotation progressive de la clé privée OIDC. Lorsqu'une valeur positive est définie, la nouvelle clé privée est d'abord créée comme `Next` et ne devient effective qu'après la période de grâce. | -| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | Uniquement pour l'auto-hébergement. Définissez à `true` uniquement lorsque des points de terminaison OIDC de confiance doivent être résolus vers des adresses de réseau privé. Voir [Protection SSRF du fournisseur OIDC](#oidc-provider-ssrf-protection). | +| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | Uniquement pour l'auto-hébergement. Définissez sur `true` uniquement lorsque des points de terminaison OIDC de confiance doivent être résolus vers des adresses de réseau privé. Voir [Protection SSRF du fournisseur OIDC](#oidc-provider-ssrf-protection). | ### Protection SSRF du fournisseur OIDC {#oidc-provider-ssrf-protection} -Logto protège par défaut les requêtes sortantes du fournisseur OIDC contre la falsification de requête côté serveur (SSRF). Les requêtes vers des adresses à usage spécial, y compris les adresses de boucle locale et de réseau privé, sont bloquées. Cette protection couvre les points de terminaison des parties de confiance tels que les URI de déconnexion back-channel, `jwks_uri` et `sector_identifier_uri`. +Logto protège par défaut les requêtes sortantes du fournisseur OIDC contre la falsification de requête côté serveur (SSRF). Les requêtes vers des adresses à usage spécial, y compris les adresses de boucle locale et de réseau privé, sont bloquées. Cette protection couvre les points de terminaison des parties utilisatrices tels que les URI de déconnexion back-channel, `jwks_uri` et `sector_identifier_uri`, ainsi que les documents de métadonnées d’ID client récupérés pour les [applications dynamiques](/integrate-logto/third-party-applications/dynamic-apps). Si votre déploiement auto-hébergé doit intentionnellement atteindre un point de terminaison de confiance sur un réseau privé, définissez `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` et redémarrez chaque instance Logto. :::caution -Ce paramètre désactive la protection SSRF pour toutes les requêtes sortantes du fournisseur OIDC, pas seulement pour un point de terminaison. Ne le désactivez que lorsque tous les points de terminaison configurés sont de confiance et que vos contrôles réseau empêchent l'accès aux services internes sensibles. +Ce paramètre désactive la protection SSRF pour toutes les requêtes sortantes du fournisseur OIDC, pas seulement pour un point de terminaison. Ne le désactivez que lorsque tous les points de terminaison configurés sont de confiance et que vos contrôles réseau empêchent l'accès à des services internes sensibles. + +[Application dynamique](/integrate-logto/third-party-applications/dynamic-apps) ne peut pas être activée tant que cette protection est désactivée, car elle récupère des documents de métadonnées à partir d'URL fournies par les clients eux-mêmes. ::: @@ -55,17 +57,17 @@ Ce paramètre désactive la protection SSRF pour toutes les requêtes sortantes Node prend en charge HTTPS nativement. Fournissez **LES DEUX** `HTTPS_CERT_PATH` et `HTTPS_KEY_PATH` pour activer HTTPS via Node. -`HTTPS_CERT_PATH` indique le chemin vers votre certificat HTTPS, tandis que `HTTPS_KEY_PATH` indique le chemin vers votre clé HTTPS. +`HTTPS_CERT_PATH` correspond au chemin de votre certificat HTTPS, tandis que `HTTPS_KEY_PATH` correspond au chemin de votre clé HTTPS. #### Utilisation d'un proxy HTTPS {#using-a-https-proxy} Une autre pratique courante consiste à placer un proxy HTTPS devant Node (par exemple Nginx). -Dans ce cas, vous souhaiterez probablement définir `TRUST_PROXY_HEADER` à `true`, ce qui indique si les champs d'en-tête du proxy doivent être approuvés. Logto transmettra la valeur aux [paramètres de l'application Koa](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings). +Dans ce cas, vous souhaiterez probablement définir `TRUST_PROXY_HEADER` sur `true`, ce qui indique si les champs d'en-tête du proxy doivent être approuvés. Logto transmettra la valeur aux [paramètres de l'application Koa](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings). -Voir [Faire confiance aux proxies de déchargement TLS](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies) pour savoir quand configurer ce champ. +Voir [Trusting TLS offloading proxies](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies) pour savoir quand configurer ce champ. -## Configurations de base de données {#database-configs} +## Configurations de la base de données {#database-configs} Gérer trop de variables d'environnement n'est ni efficace ni flexible, c'est pourquoi la plupart de nos configurations générales sont stockées dans la table de base de données `logto_configs`. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index 0edcbd77bed..8ff5704d3d6 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -6,29 +6,27 @@ sidebar_position: 6 ## Qu'est-ce qu'un écran de consentement ? \{#what-is-consent-screen} -Imaginez que vous vous inscrivez sur Logto en utilisant votre compte Google. Lorsque vous cliquez sur le bouton "Se connecter avec Google", vous êtes redirigé vers la page de connexion de Google. Après avoir saisi vos identifiants Google, il vous sera demandé d'accorder à Logto l'autorisation d'accéder aux informations de votre compte Google. Il s'agit de l'écran de consentement utilisateur. +Imaginez que vous vous inscrivez sur Logto en utilisant votre compte Google. Lorsque vous cliquez sur le bouton "Se connecter avec Google", vous êtes redirigé vers la page de connexion de Google. Après avoir saisi vos identifiants Google, il vous sera demandé d'accorder à Logto l'autorisation d'accéder aux informations de votre compte Google. C'est l'écran de consentement utilisateur. Cette page est ce que nous appelons l'**écran de consentement** ou **page de consentement** utilisateur. Il s'agit d'un flux standard [OIDC / OAuth 2.0](/integrate-logto/third-party-applications) qui permet aux utilisateurs d'accorder des permissions à des [applications tierces](/integrate-logto/third-party-applications) pour accéder à leurs données en leur nom. Son objectif principal est d'informer les utilisateurs sur la collecte, le traitement et l'utilisation de leurs données personnelles et de solliciter leur accord explicite ou consentement pour ces activités. -Sur un écran de consentement, les utilisateurs se voient généralement présenter des [informations](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information) sur les types de données qui seront collectées, la manière dont elles seront utilisées et si elles seront partagées avec des tiers. Ces informations sont essentielles pour la transparence, permettant aux utilisateurs de prendre des décisions éclairées concernant leur vie privée et la sécurité de leurs données. +Sur un écran de consentement, les utilisateurs voient généralement des [informations](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information) sur les types de données qui seront collectées, la manière dont elles seront utilisées et si elles seront partagées avec des tiers. Ces informations sont essentielles pour la transparence, permettant aux utilisateurs de prendre des décisions éclairées concernant leur vie privée et la sécurité de leurs données. Les pages de consentement sont particulièrement importantes dans le contexte des réglementations sur la confidentialité telles que le Règlement Général sur la Protection des Données ([RGPD](https://gdpr-info.eu/art-4-gdpr/)) dans l'Union européenne ou le California Consumer Privacy Act ([CCPA](https://oag.ca.gov/privacy/ccpa)) aux États-Unis, qui exigent des organisations qu'elles obtiennent un consentement clair et affirmatif des utilisateurs avant de traiter leurs informations personnelles. ## Quand l'utilisateur voit-il l'écran de consentement dans Logto ? \{#when-does-user-see-the-consent-screen-in-logto} -Comme mentionné précédemment, l'écran de consentement apparaît lorsque les utilisateurs se connectent à Logto en utilisant un fournisseur d'identité (IdP) tiers comme Google, Facebook ou Apple. Dans cette configuration, Logto agit en tant que fournisseur de services (SP), demandant l'accès aux informations utilisateur auprès de l'IdP. L'écran de consentement est généralement présenté lorsque le [SP](https://auth.wiki/service-provider) et l'[IdP](https://auth.wiki/identity-provider) sont des organisations distinctes, nécessitant l'autorisation de l'utilisateur pour faciliter le partage des données. +Comme mentionné précédemment, l'écran de consentement apparaît lorsque les utilisateurs se connectent à Logto en utilisant un fournisseur d'identité tiers (IdP) comme Google, Facebook ou Apple. Dans cette configuration, Logto agit en tant que fournisseur de service (SP), demandant l'accès aux informations utilisateur auprès de l'IdP. L'écran de consentement est généralement présenté lorsque le [SP](https://auth.wiki/service-provider) et l'[IdP](https://auth.wiki/identity-provider) sont des organisations distinctes, nécessitant l'autorisation de l'utilisateur pour faciliter le partage des données. -Écran de consentement Logto en tant que SP +Consent screen Logto as SP -De même, dans Logto, lorsque Logto fonctionne en tant qu'IdP, l'écran de consentement est affiché lorsque les utilisateurs se connectent à une [**application tierce OIDC / OAuth**](/integrate-logto/third-party-applications) intégrée à Logto. Cet écran informe les utilisateurs sur les données demandées par l'application et sollicite leur autorisation pour continuer. Les utilisateurs peuvent examiner les permissions demandées et décider d'accorder ou non l'autorisation à l'application. +De même, dans Logto, lorsque Logto fonctionne en tant qu'IdP, l'écran de consentement s'affiche lorsque les utilisateurs se connectent à une [**application tierce OIDC / OAuth**](/integrate-logto/third-party-applications) intégrée à Logto. Cet écran informe les utilisateurs sur les données demandées par l'application et sollicite leur autorisation pour continuer. Les utilisateurs peuvent examiner les permissions demandées et décider d'accorder ou non l'autorisation à l'application. -Écran de consentement Logto en tant qu'IdP +Consent screen Logto as IdP + +### Clients non enregistrés (dynamiques) \{#unregistered-dynamic-clients} + +Si l'[application dynamique](/integrate-logto/third-party-applications/dynamic-apps) est activée, les clients peuvent se connecter à votre tenant sans pré-enregistrement. Pour ces clients, l'écran de consentement affiche un avis supplémentaire, ainsi que l'hôte de l'URL du client ID. Le nom et le logo du client proviennent de son propre document de métadonnées, ils peuvent donc imiter n'importe quelle marque, tandis que l'hôte ne peut pas être falsifié. ## Comment configurer l'écran de consentement ? \{#how-to-configure-the-consent-screen} @@ -39,7 +37,7 @@ En savoir plus sur la configuration de l'[application tierce](/integrate-logto/t ## Ressources associées \{#related-resources} - Transformez votre service en un IdP OIDC sécurisé doté d'un écran de consentement. + Transformez votre service en un IdP OIDC sécurisé équipé d'un écran de consentement. Introduction à l'écran de consentement utilisateur. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index e1b25ba59f4..56ac05df5bb 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -9,9 +9,9 @@ sidebar_position: 7 Dans Logto, une _application_ désigne un programme ou service logiciel spécifique qui est enregistré sur la plateforme Logto et qui a reçu l’autorisation d’accéder aux informations utilisateur ou d’effectuer des actions au nom d’un utilisateur. Les applications servent à identifier la source des requêtes faites à l’API Logto, ainsi qu’à gérer le processus d’authentification et d’autorisation pour les utilisateurs accédant à ces applications. -L’utilisation des applications dans l’expérience de connexion Logto permet aux utilisateurs d’accéder facilement à leurs applications autorisées et de les gérer depuis un seul endroit, avec un processus d’authentification cohérent et sécurisé. Cela permet de simplifier l’expérience utilisateur et de garantir que seules les personnes autorisées accèdent à des informations sensibles ou effectuent des actions au nom de l’organisation. +L’utilisation des applications dans l’expérience de connexion Logto permet aux utilisateurs d’accéder facilement à leurs applications autorisées et de les gérer depuis un emplacement unique, avec un processus d’authentification cohérent et sécurisé. Cela contribue à simplifier l’expérience utilisateur et à garantir que seules les personnes autorisées accèdent à des informations sensibles ou effectuent des actions au nom de l’organisation. -Les applications sont également utilisées dans les journaux d’audit de Logto pour suivre l’activité des utilisateurs et identifier toute menace ou violation potentielle de sécurité. En associant des actions spécifiques à une application particulière, Logto peut fournir des informations détaillées sur la façon dont les données sont consultées et utilisées, permettant ainsi aux organisations de mieux gérer leurs exigences de sécurité et de conformité. +Les applications sont également utilisées dans les journaux d’audit de Logto pour suivre l’activité des utilisateurs et identifier toute menace ou violation potentielle de sécurité. En associant des actions spécifiques à une application particulière, Logto peut fournir des informations détaillées sur la façon dont les données sont consultées et utilisées, permettant ainsi aux organisations de mieux gérer leurs exigences en matière de sécurité et de conformité. Si vous souhaitez intégrer votre application à Logto, consultez [Intégrer Logto](/integrate-logto). ## Propriétés \{#properties} @@ -20,12 +20,16 @@ Si vous souhaitez intégrer votre application à Logto, consultez [Intégrer Log _L’ID d’application_ est une clé unique générée automatiquement pour identifier votre application dans Logto, et est référencée comme [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) dans OAuth 2.0. +:::note +Les clients [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) ne sont pas enregistrés dans Logto. Leur client ID est une URL HTTPS publique détenue par le client, qui sert le document de métadonnées du client. +::: + ### Types d’application \{#application-types} Une _application_ peut être l’un des types suivants : - **Application native** : une application qui s’exécute dans un environnement natif. Par exemple, application iOS, application Android. - - **Application device flow** : un type spécial d’application native pour les appareils à saisie limitée ou les applications sans interface (par exemple, téléviseurs intelligents, consoles de jeux, outils CLI, appareils IoT). Elle utilise le [Device Authorization Grant OAuth 2.0](https://auth.wiki/device-flow) au lieu du flux standard basé sur la redirection. Voir [Démarrage rapide device flow](/quick-starts/device-flow) pour plus de détails. + - **Application device flow** : un type spécial d’application native pour les appareils à saisie limitée ou les applications sans interface (par exemple, smart TV, consoles de jeux, outils CLI, appareils IoT). Elle utilise le [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) au lieu du flux standard basé sur la redirection. Voir [Démarrage rapide device flow](/quick-starts/device-flow) pour plus de détails. - **Application monopage (SPA)** : une application qui s’exécute dans un navigateur web, qui met à jour la page avec de nouvelles données du serveur sans recharger entièrement la page. Par exemple, application React DOM, application Vue. - **Application web traditionnelle** : une application qui rend et met à jour les pages uniquement via le serveur web. Par exemple, JSP, PHP. - **Application machine à machine (M2M)** : une application qui s’exécute dans un environnement machine pour une communication directe service à service sans interaction utilisateur. @@ -35,17 +39,17 @@ Une _application_ peut être l’un des types suivants : _Le secret d’application_ est une clé utilisée pour authentifier l’application dans le système d’authentification, spécifiquement pour les clients privés (applications web traditionnelles et M2M) en tant que barrière de sécurité privée. :::tip -Les applications monopage (SPA) et les applications natives ne fournissent pas de secret d’application. Les SPA et les applications natives sont des "clients publics" et ne peuvent pas garder de secrets (le code du navigateur ou les bundles d’application sont inspectables). À la place d’un secret d’application, Logto les protège avec PKCE, une validation stricte des URI de redirection / CORS, des jetons d’accès à durée de vie courte et la rotation des jetons de rafraîchissement. +Les applications monopage (SPA) et les applications natives ne fournissent pas de secret d’application. Les SPA et les applications natives sont des "clients publics" et ne peuvent pas conserver de secrets (le code du navigateur ou les bundles d’application sont inspectables). Au lieu d’un secret d’application, Logto les protège avec PKCE, une validation stricte des URI de redirection / CORS, des jetons d’accès à courte durée de vie et la rotation des jetons de rafraîchissement. ::: ### Nom de l’application \{#application-name} -_Le nom de l’application_ est un nom lisible par l’homme de l’application et sera affiché dans la console d’administration. +_Le nom de l’application_ est un nom lisible par l’humain de l’application et sera affiché dans la console d’administration. Le _nom de l’application_ est un élément important de la gestion des applications dans Logto, car il permet aux administrateurs d’identifier facilement et de suivre l’activité des applications individuelles au sein de la plateforme. :::note -Il est important de noter que le _nom de l’application_ doit être choisi avec soin, car il sera visible par tous les utilisateurs ayant accès à la console d’administration. Il doit refléter fidèlement l’objectif et la fonction de l’application, tout en étant facile à comprendre et à reconnaître. +Il est important de noter que le _nom de l’application_ doit être choisi avec soin, car il sera visible par tous les utilisateurs ayant accès à la console d’administration. Il doit refléter fidèlement le but et la fonction de l’application, tout en étant facile à comprendre et à reconnaître. ::: ### Description \{#description} @@ -56,29 +60,29 @@ Une brève description de l’application sera affichée sur la page de détails _Les URI de redirection_ sont une liste d’URI de redirection valides qui ont été préconfigurées pour une application. Lorsqu’un utilisateur se connecte à Logto et tente d’accéder à l’application, il est redirigé vers l’un des URI autorisés spécifiés dans les paramètres de l’application. -La liste des URI autorisées est utilisée pour valider l’URI de redirection inclus dans la requête d’autorisation envoyée par l’application à Logto lors du processus d’authentification. Si l’URI de redirection spécifiée dans la requête d’autorisation correspond à l’une des URI autorisées dans les paramètres de l’application, l’utilisateur est redirigé vers cet URI après une authentification réussie. Si l’URI de redirection ne figure pas dans la liste autorisée, l’utilisateur ne sera pas redirigé et le processus d’authentification échouera. +La liste des URI autorisés est utilisée pour valider l’URI de redirection inclus dans la requête d’autorisation envoyée par l’application à Logto lors du processus d’authentification. Si l’URI de redirection spécifié dans la requête d’autorisation correspond à l’un des URI autorisés dans les paramètres de l’application, l’utilisateur est redirigé vers cet URI après une authentification réussie. Si l’URI de redirection ne figure pas dans la liste autorisée, l’utilisateur ne sera pas redirigé et le processus d’authentification échouera. :::note Il est important de s’assurer que tous les URI de redirection valides sont ajoutés à la liste autorisée pour une application dans Logto, afin de garantir que les utilisateurs puissent accéder à l’application après authentification. ::: -Vous pouvez consulter le [point de terminaison de redirection](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) pour plus d’informations. +Vous pouvez consulter le [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) pour plus d’informations. Comprendre les URI de redirection en OIDC avec le flux Authorization Code -#### Modèles génériques (wildcards) \{#wildcard-patterns} +#### Modèles génériques (wildcard) \{#wildcard-patterns} _Disponibilité : Application monopage, Application web traditionnelle_ -Les URI de redirection prennent en charge les modèles génériques (`*`) pour les environnements dynamiques tels que les déploiements de prévisualisation. Les wildcards peuvent être utilisées dans les composants hostname et pathname des URI HTTP / HTTPS. +Les URI de redirection prennent en charge les modèles génériques (`*`) pour les environnements dynamiques tels que les déploiements de prévisualisation. Les génériques peuvent être utilisés dans les composants hostname et pathname des URI HTTP / HTTPS. **Règles :** -- Les wildcards ne sont autorisées que dans le hostname et le pathname -- Les wildcards ne sont pas autorisées dans le schéma, le port, les paramètres de requête ou les fragments hash -- Les wildcards dans le hostname doivent inclure au moins un point (par exemple, `https://*.example.com/callback`) +- Les génériques ne sont autorisés que dans le hostname et le pathname +- Les génériques ne sont pas autorisés dans le schéma, le port, les paramètres de requête ou les fragments hash +- Les génériques dans le hostname doivent inclure au moins un point (par exemple, `https://*.example.com/callback`) **Exemples :** @@ -87,7 +91,7 @@ Les URI de redirection prennent en charge les modèles génériques (`*`) pour l - `https://example.com/*/callback` - correspond à n’importe quel segment de chemin :::caution -Les URI de redirection avec wildcards ne sont pas standard OIDC et peuvent augmenter la surface d’attaque. À utiliser avec précaution et privilégier les URI de redirection exactes autant que possible. +Les URI de redirection génériques ne sont pas standard OIDC et peuvent augmenter la surface d’attaque. À utiliser avec précaution et privilégier les URI de redirection exacts autant que possible. ::: ### URI de redirection après déconnexion \{#post-sign-out-redirect-uris} @@ -96,15 +100,15 @@ _Les URI de redirection après déconnexion_ sont une liste d’URI valides qui L’utilisation des _URI de redirection après déconnexion_ autorisées pour la déconnexion fait partie de la spécification RP-Initiated (Relying Party Initiated) Logout dans OIDC. Cette spécification fournit une méthode standardisée permettant aux applications d’initier une demande de déconnexion pour un utilisateur, ce qui inclut la redirection de l’utilisateur vers un point de terminaison préconfiguré après sa déconnexion. -Lorsqu’un utilisateur se déconnecte de Logto, sa session est terminée et il est redirigé vers l’un des URI autorisés spécifiés dans les paramètres de l’application. Cela garantit que l’utilisateur est dirigé uniquement vers des points de terminaison autorisés et valides après sa déconnexion, ce qui aide à prévenir les accès non autorisés et les risques de sécurité associés à la redirection vers des points de terminaison inconnus ou non vérifiés. +Lorsqu’un utilisateur se déconnecte de Logto, sa session est terminée et il est redirigé vers l’un des URI autorisés spécifiés dans les paramètres de l’application. Cela garantit que l’utilisateur est dirigé uniquement vers des points de terminaison autorisés et valides après sa déconnexion, ce qui aide à prévenir les accès non autorisés et les risques de sécurité associés à la redirection des utilisateurs vers des points de terminaison inconnus ou non vérifiés. Vous pouvez consulter la [déconnexion initiée par le RP](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) pour plus d’informations. ### Origines autorisées CORS \{#cors-allowed-origins} -_Les origines autorisées CORS (Cross-origin resource sharing)_ sont une liste d’origines autorisées à partir desquelles une application peut effectuer des requêtes vers le service Logto. Toute origine qui ne figure pas dans la liste autorisée ne pourra pas effectuer de requêtes vers le service Logto. +_Les origines autorisées CORS (Cross-origin resource sharing)_ sont une liste d’origines autorisées à partir desquelles une application peut effectuer des requêtes vers le service Logto. Toute origine qui n’est pas incluse dans la liste autorisée ne pourra pas effectuer de requêtes vers le service Logto. -La liste des origines autorisées CORS est utilisée pour restreindre l’accès au service Logto depuis des domaines non autorisés, et pour aider à prévenir les attaques CSRF (Cross-site request forgery). En spécifiant les origines autorisées pour une application dans Logto, le service peut s’assurer que seuls les domaines autorisés peuvent effectuer des requêtes vers le service. +La liste des origines autorisées CORS est utilisée pour restreindre l’accès au service Logto depuis des domaines non autorisés, et pour aider à prévenir les attaques CSRF (Cross-Site Request Forgery). En spécifiant les origines autorisées pour une application dans Logto, le service peut s’assurer que seuls les domaines autorisés peuvent effectuer des requêtes vers le service. :::note La liste des origines autorisées doit contenir l’origine où l’application sera servie. Cela garantit que les requêtes provenant de l’application sont autorisées, tandis que celles provenant d’origines non autorisées sont bloquées. @@ -116,13 +120,13 @@ Le point de terminaison pour la [découverte OpenID Connect](https://openid.net/ ### Point de terminaison d’autorisation \{#authorization-endpoint} -_Le point de terminaison d’autorisation_ est un terme OIDC, et il s’agit d’un point de terminaison requis utilisé pour initier le processus d’authentification d’un utilisateur. Lorsqu’un utilisateur tente d’accéder à une ressource ou application protégée enregistrée sur la plateforme Logto, il sera redirigé vers le _point de terminaison d’autorisation_ pour authentifier son identité et obtenir l’autorisation d’accéder à la ressource demandée. +_Le point de terminaison d’autorisation_ est un terme OIDC, et c’est un point de terminaison requis utilisé pour initier le processus d’authentification pour un utilisateur. Lorsqu’un utilisateur tente d’accéder à une ressource ou application protégée enregistrée sur la plateforme Logto, il sera redirigé vers le _point de terminaison d’autorisation_ pour authentifier son identité et obtenir l’autorisation d’accéder à la ressource demandée. Vous pouvez consulter le [point de terminaison d’autorisation](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) pour plus d’informations. ### Point de terminaison de jeton \{#token-endpoint} -_Le point de terminaison de jeton_ est un terme OIDC, il s’agit d’un point de terminaison d’API web utilisé par un client OIDC pour obtenir un jeton d’accès, un jeton d’identifiant ou un jeton de rafraîchissement auprès d’un fournisseur OIDC. +_Le point de terminaison de jeton_ est un terme OIDC, c’est un point de terminaison d’API web utilisé par un client OIDC pour obtenir un jeton d’accès, un jeton d’identifiant ou un jeton de rafraîchissement auprès d’un fournisseur OIDC. Lorsqu’un client OIDC a besoin d’obtenir un jeton d’accès ou un jeton d’identifiant, il envoie une requête au point de terminaison de jeton avec une autorisation, qui est généralement un code d’autorisation ou un jeton de rafraîchissement. Le point de terminaison de jeton valide alors l’autorisation et délivre un jeton d’accès ou un jeton d’identifiant au client si l’autorisation est valide. @@ -130,7 +134,7 @@ Vous pouvez consulter le [point de terminaison de jeton](https://openid.net/spec ### Point de terminaison Userinfo \{#userinfo-endpoint} -Le point de terminaison [UserInfo OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). +Le point de terminaison [UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) d’OpenID Connect. ### Toujours émettre un jeton de rafraîchissement \{#always-issue-refresh-token} @@ -146,20 +150,20 @@ _Défaut : `true`_ Lorsqu’elle est activée, Logto peut émettre un nouveau jeton de rafraîchissement lorsqu’un client utilise un jeton de rafraîchissement pour demander de nouveaux jetons. Si le jeton de rafraîchissement et son app grant sont toujours valides, la politique de rotation par défaut est la suivante : -- Les jetons de rafraîchissement ne peuvent être rotatés que tant que la chaîne de jetons de rafraîchissement existe depuis moins d’un an. Il s’agit d’une limite de sécurité interne ; la durée de vie propre du jeton de rafraîchissement ou celle du grant de l’application peuvent expirer plus tôt. Une fois la limite atteinte, Logto ne fait plus de rotation du jeton de rafraîchissement, et l’expiration du jeton de rafraîchissement courant est définitive. +- Les jetons de rafraîchissement ne peuvent être rotatés que tant que la chaîne de jetons de rafraîchissement existe depuis moins d’un an. Il s’agit d’une limite de sécurité interne ; la durée de vie propre du jeton de rafraîchissement ou celle du grant de l’application peuvent expirer plus tôt. Une fois la limite atteinte, Logto ne fait plus tourner le jeton de rafraîchissement, et l’expiration du jeton de rafraîchissement courant est définitive. - Pour les clients publics qui n’utilisent pas de jetons de rafraîchissement liés à l’expéditeur (par exemple, applications natives classiques et applications monopage), Logto fait tourner le jeton de rafraîchissement à chaque demande de jeton de rafraîchissement tant que la rotation est autorisée. - Pour les autres clients, Logto fait tourner le jeton de rafraîchissement uniquement lorsqu’il est proche de l’expiration (>=70% de sa durée de vie initiale est écoulée). :::note Pour les clients publics, il est fortement recommandé de garder la rotation du jeton de rafraîchissement activée pour des raisons de sécurité. -Les jetons de rafraîchissement liés à l’expéditeur sont associés à une clé de preuve ou un certificat détenu par le client. Pour les SPA classiques, la rotation émet un nouveau jeton de rafraîchissement mais n’étend pas la durée de vie du jeton de rafraîchissement. Le nouveau jeton de rafraîchissement hérite du TTL restant du jeton précédent. +Les jetons de rafraîchissement liés à l’expéditeur sont associés à une clé de preuve ou un certificat détenu par le client. Pour les SPA classiques, la rotation émet un nouveau jeton de rafraîchissement mais n’étend pas la durée de vie du jeton de rafraîchissement. Le nouveau jeton de rafraîchissement hérite de la durée de vie restante du jeton précédent. ::: :::caution Durée de vie de la chaîne de jetons de rafraîchissement -Les jetons de rafraîchissement sont associés à un app grant. Le TTL par défaut d’un grant Logto est de **180 jours**. Lorsque le grant expire, les demandes de jeton de rafraîchissement échouent et le jeton de rafraîchissement ne peut plus être utilisé pour obtenir de nouveaux jetons, même si la rotation est activée. +Les jetons de rafraîchissement sont associés à un app grant. La durée de vie par défaut d’un grant Logto est de **180 jours**. Lorsque le grant expire, les demandes de jeton de rafraîchissement échouent et le jeton de rafraîchissement ne peut plus être utilisé pour obtenir de nouveaux jetons, même si la rotation est activée. -Cela signifie que la durée de vie maximale pratique d’une autorisation basée sur un jeton de rafraîchissement est actuellement limitée par le TTL du grant, la révocation explicite ou l’expiration propre du jeton de rafraîchissement, selon ce qui arrive en premier. +Cela signifie que la durée de vie maximale pratique d’une autorisation basée sur un jeton de rafraîchissement est actuellement limitée par la durée de vie du grant, la révocation explicite ou l’expiration propre du jeton de rafraîchissement, selon ce qui arrive en premier. ::: @@ -170,24 +174,24 @@ Cela signifie que la durée de vie maximale pratique d’une autorisation basée _Disponibilité : Application native, Web traditionnel, SPA ; Défaut : 14 jours ; Maximum : 180 jours_ -La durée pendant laquelle un jeton de rafraîchissement peut être utilisé pour demander de nouveaux jetons d’accès avant d’expirer et de devenir invalide. Les demandes de jeton prolongeront le TTL du jeton de rafraîchissement à cette valeur. +La durée pendant laquelle un jeton de rafraîchissement peut être utilisé pour demander de nouveaux jetons d’accès avant d’expirer et de devenir invalide. Les demandes de jeton prolongeront la durée de vie du jeton de rafraîchissement à cette valeur. En général, une valeur plus basse est préférable. :::note -Le rafraîchissement du TTL n’est pas disponible dans les applications monopage (SPA) pour des raisons de sécurité. Pour les SPA, ce paramètre contrôle la durée de vie fixe du jeton de rafraîchissement à partir de l’émission initiale. Logto n’étendra pas le TTL via les demandes de jeton, et la rotation du jeton de rafraîchissement n’empêche pas l’expiration des jetons de rafraîchissement SPA. +Le rafraîchissement du TTL n’est pas disponible dans les applications monopage (SPA) pour des raisons de sécurité. Pour les SPA, ce paramètre contrôle la durée de vie fixe du jeton de rafraîchissement à partir de l’émission initiale. Logto n’étendra pas la durée de vie via les demandes de jeton, et la rotation du jeton de rafraîchissement n’empêche pas l’expiration des jetons de rafraîchissement SPA. ::: :::caution TTL du jeton de rafraîchissement et TTL du grant -Le TTL du jeton de rafraîchissement n’est pas la seule limite d’expiration. Les jetons de rafraîchissement sont liés à un app grant, et le TTL par défaut d’un grant Logto est de **180 jours**. Lorsque le grant expire, les demandes de jeton de rafraîchissement échouent même si le jeton de rafraîchissement serait encore valide. +Le TTL du jeton de rafraîchissement n’est pas la seule limite d’expiration. Les jetons de rafraîchissement sont liés à un app grant, et la durée de vie par défaut d’un grant Logto est de **180 jours**. Lorsque le grant expire, les demandes de jeton de rafraîchissement échouent même si le jeton de rafraîchissement serait encore valide. Pour les clients où les demandes de jeton rafraîchissent le TTL du jeton de rafraîchissement, le TTL du grant agit comme la durée de vie maximale absolue pour la chaîne de jetons de rafraîchissement. Pour les SPA, le TTL fixe du jeton de rafraîchissement peut expirer avant le grant. ::: -:::caution Jeton de rafraîchissement et liaison à la session -Lorsqu’un jeton de rafraîchissement est émis **sans** la portée `offline_access` dans la requête d’autorisation, il sera lié à la session utilisateur. La session a un TTL fixe de **14 jours**. Après l’expiration de la session, le jeton de rafraîchissement devient invalide, quelle que soit sa propre durée de vie. +:::caution Jeton de rafraîchissement et liaison de session +Lorsqu’un jeton de rafraîchissement est émis **sans** la portée `offline_access` dans la requête d’autorisation, il sera lié à la session utilisateur. La session a une durée de vie fixe de **14 jours**. Après l’expiration de la session, le jeton de rafraîchissement devient invalide, quelle que soit sa propre durée de vie. -Pour garantir que le paramètre TTL du jeton de rafraîchissement prenne pleinement effet, assurez-vous d’inclure la portée `offline_access` dans votre requête d’autorisation. +Pour garantir que le paramètre de durée de vie du jeton de rafraîchissement prenne pleinement effet, assurez-vous d’inclure la portée `offline_access` dans votre requête d’autorisation. ::: ### URI de déconnexion backchannel \{#backchannel-logout-uri} @@ -203,7 +207,7 @@ Le point de terminaison de déconnexion backchannel OpenID Connect. Voir [Décon Ce paramètre est utile si vous souhaitez limiter le nombre d’appareils authentifiés simultanément par application. -Chaque éviction déclenche l’événement webhook `Grant.LimitExceeded` [webhook event](/developers/webhooks/webhooks-events#exception-hook-events), ce qui vous permet de notifier l’utilisateur ou de suivre la fréquence à laquelle la limite est atteinte. +Chaque éviction déclenche l’événement webhook `Grant.LimitExceeded` [webhook event](/developers/webhooks/webhooks-events#exception-hook-events), afin que vous puissiez notifier l’utilisateur ou suivre la fréquence à laquelle la limite est atteinte. :::note diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 41f1cc2b453..7b3e99a0394 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,6 +4,7 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; @@ -12,92 +13,99 @@ import Tabs from '@theme/Tabs'; L'intégration d'applications tierces de Logto vous permet d'utiliser Logto comme [Fournisseur d’identité (IdP)](https://auth.wiki/identity-provider) pour des applications externes. -Un Fournisseur d’identité (IdP) est un service qui vérifie les identités des utilisateurs et gère leurs identifiants de connexion. Après avoir confirmé l'identité d'un utilisateur, l'IdP génère des jetons d’authentification ou des assertions et permet à l'utilisateur d'accéder à diverses applications ou services sans avoir à se reconnecter. +Un fournisseur d'identité (IdP) est un service qui vérifie les identités des utilisateurs et gère leurs identifiants de connexion. Après avoir confirmé l'identité d'un utilisateur, l'IdP génère des jetons d’authentification ou des assertions et permet à l'utilisateur d'accéder à diverses applications ou services sans avoir à se reconnecter. Contrairement aux applications que vous avez créées dans le guide [Intégrer Logto à votre application](/integrate-logto/integrate-logto-into-your-application) qui sont développées et entièrement contrôlées par vous, les applications tierces sont des services indépendants développés par des développeurs externes ou des partenaires commerciaux. -Cette approche d'intégration est particulièrement adaptée aux scénarios métier courants. Vous pouvez permettre aux utilisateurs d'accéder à des applications partenaires en utilisant leurs comptes Logto, tout comme les utilisateurs d'entreprise se connectent à Slack avec Google Workspace. Vous pouvez également créer une plateforme ouverte où les applications tierces peuvent ajouter la fonctionnalité "Se connecter avec Logto", similaire à "Se connecter avec Google". +Cette approche d'intégration est bien adaptée aux scénarios d'affaires courants. Vous pouvez permettre aux utilisateurs d'accéder à des applications partenaires en utilisant leurs comptes Logto, tout comme les utilisateurs d'entreprise se connectent à Slack avec Google Workspace. Vous pouvez également créer une plateforme ouverte où des applications tierces peuvent ajouter la fonctionnalité "Se connecter avec Logto", similaire à "Se connecter avec Google". -Logto est un service d'identité basé sur le protocole [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), offrant des capacités d’[authentification (Authentication)](https://auth.wiki/authentication) et d’[autorisation (Authorization)](https://auth.wiki/authorization). Cela rend l'intégration d'une application tierce OIDC aussi simple qu'une application web traditionnelle. +Logto est un service d'identité basé sur le protocole [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), offrant des capacités d’[authentification](https://auth.wiki/authentication) et d’[autorisation](https://auth.wiki/authorization). Cela rend l'intégration d'une application tierce OIDC aussi simple qu'une application web traditionnelle. -Ainsi, puisque OIDC s'appuie sur [OAuth 2.0](https://auth.wiki/oauth-2.0) en ajoutant une couche d’authentification, vous pouvez également intégrer une application tierce en utilisant le protocole OAuth. +Ainsi, puisque OIDC s'appuie sur [OAuth 2.0](https://auth.wiki/oauth-2.0) en ajoutant une couche d'authentification, vous pouvez également intégrer une application tierce en utilisant le protocole OAuth. + +## Deux façons d’intégrer une application tierce \{#two-ways-to-onboard-a-third-party-app} + +- **Enregistrez l’application dans Logto** (ce guide) : vous créez l’application et configurez ses permissions et URI de redirection. À utiliser lorsque vous connaissez vos partenaires. +- **[Application dynamique](/integrate-logto/third-party-applications/dynamic-apps)** : les clients se connectent sans pré-enregistrement, en utilisant une URL HTTPS publique qui fournit leur propre document de métadonnées comme identifiant client. À utiliser lorsque n'importe quel client peut se connecter, comme les clients MCP et les agents IA. + +Les deux méthodes peuvent être utilisées simultanément. ## Créer une application tierce dans Logto \{#create-a-third-party-application-in-logto} -1. Rendez-vous sur Console > Applications. -2. Cliquez sur le bouton "Créer une application". Sélectionnez "Application tierce" comme type d'application et choisissez l'un des protocoles d'intégration suivants : +1. Allez dans Console > Applications. +2. Cliquez sur le bouton "Créer une application". Sélectionnez "Application tierce" comme type d’application et choisissez l’un des protocoles d’intégration suivants : - OIDC / OAuth -3. Sélectionnez un type d'application en fonction du type de l'application tierce : - - **Web traditionnel** : Applications rendues côté serveur (par exemple, Node.js, PHP, Java) pouvant stocker un secret client de manière sécurisée sur le backend. - - **Application monopage (SPA)** : Applications rendues côté client (par exemple, React, Vue, Angular) qui s'exécutent entièrement dans le navigateur et ne peuvent pas stocker de secrets de manière sécurisée. - - **Native** : Applications mobiles ou de bureau (par exemple, iOS, Android, Electron) qui s'exécutent sur les appareils des utilisateurs. -4. Saisissez un nom et une description pour votre application puis cliquez sur le bouton "Créer". Une nouvelle application tierce sera créée. +3. Sélectionnez un type d’application en fonction du type de l’application tierce : + - **Web traditionnel** : Applications rendues côté serveur (ex. Node.js, PHP, Java) pouvant stocker un secret client en toute sécurité côté serveur. + - **Application monopage (SPA)** : Applications rendues côté client (ex. React, Vue, Angular) qui s’exécutent entièrement dans le navigateur et ne peuvent pas stocker de secrets en toute sécurité. + - **Native** : Applications mobiles ou de bureau (ex. iOS, Android, Electron) qui s’exécutent sur les appareils des utilisateurs. +4. Saisissez un nom et une description pour votre application et cliquez sur le bouton "Créer". Une nouvelle application tierce sera créée. -Toutes les applications tierces créées seront répertoriées sur la page Applications sous l'onglet "Applications tierces". Cette organisation vous aide à les distinguer de vos propres applications, facilitant ainsi la gestion de toutes vos applications en un seul endroit. +Toutes les applications tierces créées seront répertoriées sur la page Applications sous l’onglet "Applications tierces". Cette organisation vous aide à les distinguer de vos propres applications, facilitant ainsi la gestion de toutes vos applications en un seul endroit. -Pour restreindre quels utilisateurs peuvent se connecter à une application tierce, configurez le [contrôle d'accès au niveau de l'application](/authorization/app-level-access-control) dans l'onglet **Règles** de l'application. +Pour restreindre quels utilisateurs peuvent se connecter à une application tierce, configurez le [contrôle d’accès au niveau de l’application](/authorization/app-level-access-control) dans l’onglet **Règles** de l’application. -## Guide d'intégration \{#integration-guide} +## Guide d’intégration \{#integration-guide} -### Trouver les configurations de l'application \{#find-the-application-configurations} +### Trouver les configurations de l’application \{#find-the-application-configurations} -Sur la page de détails de l'application, vous pouvez trouver le [**Client ID**](/integrate-logto/application-data-structure#application-id), le [**Client secret**](/integrate-logto/application-data-structure#application-secret) (pour les applications web traditionnelles uniquement), et les points de terminaison OIDC nécessaires à l'intégration. +Sur la page de détails de l’application, vous trouverez le [**Client ID**](/integrate-logto/application-data-structure#application-id), le [**Client secret**](/integrate-logto/application-data-structure#application-secret) (pour les applications web traditionnelles uniquement), et les points de terminaison OIDC nécessaires à l’intégration. Si le service tiers prend en charge la découverte OIDC, fournissez simplement le **point de terminaison de découverte**. Sinon, cliquez sur **Afficher les détails des points de terminaison** pour voir tous les points de terminaison, y compris le [point de terminaison d’autorisation](/integrate-logto/application-data-structure#authorization-endpoint) et le [point de terminaison de jeton](/integrate-logto/application-data-structure#token-endpoint). ### Intégrer avec des services prenant en charge un IdP tiers \{#integrate-with-services-that-support-third-party-idp} -Si vous connectez un service ou un produit qui prend en charge nativement la configuration d'un fournisseur d'identité externe (par exemple, plateformes SaaS d'entreprise, outils de collaboration), la configuration est simple : +Si vous connectez un service ou produit qui prend en charge nativement la configuration d’un fournisseur d’identité externe (ex. plateformes SaaS d’entreprise, outils de collaboration), la configuration est simple : 1. Ouvrez la page de configuration IdP ou SSO du service. 2. Copiez le **Client ID** (et le **Client secret** si nécessaire) depuis Logto et collez-les dans la configuration du service. 3. Fournissez le **point de terminaison de découverte** si le service prend en charge la découverte automatique OIDC, ou copiez manuellement le **point de terminaison d’autorisation** et le **point de terminaison de jeton**. -4. Copiez l'**URI de redirection** depuis la page de configuration du service et ajoutez-le aux URI de redirection autorisés de votre application Logto. -5. Configurez les **scopes** si le service le permet. Puisque Logto est un fournisseur OIDC, incluez la portée `openid` si vous devez authentifier les utilisateurs (donne accès à un jeton d’identifiant et au point de terminaison UserInfo). La portée `openid` est facultative si vous n'avez besoin que de l'accès aux ressources OAuth. +4. Copiez l’**URI de redirection** depuis la page de configuration du service et ajoutez-le aux URI de redirection autorisées de votre application Logto. +5. Configurez les **scopes** si le service le permet. Puisque Logto est un fournisseur OIDC, incluez le scope `openid` si vous devez authentifier les utilisateurs (donne accès à un jeton d’identifiant et au point de terminaison UserInfo). Le scope `openid` est optionnel si vous n’avez besoin que de l’accès aux ressources OAuth. Le service gérera automatiquement le flux OAuth / OIDC une fois configuré. ### Intégrer via le protocole OAuth / OIDC \{#integrate-via-oauth-protocol} -Si une application tierce doit s'intégrer à Logto en tant qu'IdP de manière programmatique, elle doit implémenter le [flux d’autorisation par code](https://auth.wiki/authorization-code-flow) standard. Nous recommandons d'utiliser une bibliothèque cliente OAuth 2.0 / OIDC pour votre langage de programmation afin de gérer l'implémentation. +Si une application tierce doit s’intégrer à Logto comme IdP de manière programmatique, elle doit implémenter le [flux d’autorisation par code](https://auth.wiki/authorization-code-flow) standard. Nous recommandons d’utiliser une bibliothèque cliente OAuth 2.0 / OIDC adaptée à votre langage de programmation pour gérer l’implémentation. -Les applications web traditionnelles sont des **clients confidentiels** pouvant stocker un secret client de manière sécurisée sur le serveur backend. Voir [flux d’autorisation par code](https://auth.wiki/authorization-code-flow) pour tous les détails d’implémentation. +Les applications web traditionnelles sont des **clients confidentiels** qui peuvent stocker un secret client en toute sécurité côté serveur. Voir [Flux d’autorisation par code](https://auth.wiki/authorization-code-flow) pour tous les détails d’implémentation. **Étapes clés :** -1. **Initier l’autorisation** : Redirigez l'utilisateur vers le point de terminaison d’autorisation de Logto avec `client_id`, `redirect_uri`, `response_type=code` et `scope`. +1. **Initier l’autorisation** : Redirigez l’utilisateur vers le point de terminaison d’autorisation de Logto avec `client_id`, `redirect_uri`, `response_type=code` et `scope`. 2. **Gérer le callback** : Recevez le `code` d’autorisation depuis la redirection. -3. **Échanger les jetons** : Depuis votre backend, effectuez une requête POST vers le point de terminaison de jeton avec le code, le `client_id` et le `client_secret`. +3. **Échanger les jetons** : Depuis votre backend, effectuez un POST vers le point de terminaison de jeton avec le code, le `client_id` et le `client_secret`. -Les applications monopage et les applications natives sont des **clients publics** qui ne peuvent pas stocker de secrets de manière sécurisée. Au lieu d'utiliser un secret client, ces applications doivent utiliser [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) pour une autorisation sécurisée. Voir [flux d’autorisation par code](https://auth.wiki/authorization-code-flow) et [PKCE](https://auth.wiki/pkce) pour tous les détails d’implémentation. +Les applications monopage et les applications natives sont des **clients publics** qui ne peuvent pas stocker de secrets en toute sécurité. Au lieu d’utiliser un secret client, ces applications doivent utiliser [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) pour une autorisation sécurisée. Voir [Flux d’autorisation par code](https://auth.wiki/authorization-code-flow) et [PKCE](https://auth.wiki/pkce) pour tous les détails d’implémentation. **Étapes clés :** 1. **Générer les paramètres PKCE** : Créez un `code_verifier` et dérivez un `code_challenge` (SHA-256). -2. **Initier l’autorisation** : Redirigez l'utilisateur vers le point de terminaison d’autorisation avec `code_challenge` et `code_challenge_method=S256`. +2. **Initier l’autorisation** : Redirigez l’utilisateur vers le point de terminaison d’autorisation avec `code_challenge` et `code_challenge_method=S256`. 3. **Gérer le callback** : Recevez le `code` d’autorisation depuis la redirection. -4. **Échanger les jetons** : Effectuez une requête POST vers le point de terminaison de jeton avec le code et le `code_verifier` original. +4. **Échanger les jetons** : Effectuez un POST vers le point de terminaison de jeton avec le code et le `code_verifier` original. ### Intégrer via le device flow \{#integrate-via-device-flow} -Pour les applications tierces natives fonctionnant sur des appareils à saisie limitée (par exemple, smart TV, consoles de jeux, outils CLI), le flux d’autorisation par code basé sur la redirection peut ne pas être réalisable. Dans ces cas, l'application peut utiliser la [subvention d’autorisation de périphérique OAuth 2.0](https://auth.wiki/device-flow). +Pour les applications tierces natives fonctionnant sur des appareils à saisie limitée (ex. smart TV, consoles de jeux, outils CLI), le flux d’autorisation par code basé sur la redirection peut ne pas être réalisable. Dans ces cas, l’application peut utiliser la [Device Authorization Grant OAuth 2.0](https://auth.wiki/device-flow). -Avec le device flow, l'appareil affiche un code utilisateur et une URL de vérification. L'utilisateur visite l'URL sur un autre appareil (téléphone, ordinateur portable), saisit le code et termine l'authentification là-bas. L'appareil interroge le point de terminaison de jeton de Logto jusqu'à ce que l'autorisation soit terminée. +Avec le device flow, l’appareil affiche un code utilisateur et une URL de vérification. L’utilisateur visite l’URL sur un autre appareil (téléphone, ordinateur portable), saisit le code et termine l’authentification là-bas. L’appareil interroge le point de terminaison de jeton de Logto jusqu’à ce que l’autorisation soit terminée. :::note -Avant d’implémenter le device flow, assurez-vous de configurer les [permissions](/integrate-logto/third-party-applications/permission-management) requises pour votre application tierce dans la Console Logto. Les applications tierces demandant des portées non activées se verront refuser l'accès. +Avant d’implémenter le device flow, assurez-vous de configurer les [permissions](/integrate-logto/third-party-applications/permission-management) requises pour votre application tierce dans la Console Logto. Les applications tierces demandant des scopes non activés se verront refuser l’accès. ::: -Voir le [démarrage rapide du device flow](/quick-starts/device-flow) pour tous les détails d’implémentation. +Voir le [Guide de démarrage rapide du device flow](/quick-starts/device-flow) pour tous les détails d’implémentation. ## Écran de consentement pour les applications tierces OIDC \{#consent-screen-for-oidc-third-party-applications} @@ -111,7 +119,7 @@ Ces permissions demandées ne seront accordées à l’application tierce qu’a écran de consentement
-## Actions supplémentaires \{#further-actions} +## Actions complémentaires \{#further-actions} , }, }, + { + type: 'link', + label: 'Application dynamique (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + 'Permettez aux clients OAuth de se connecter sans pré-enregistrement, en utilisant une URL de document de métadonnées comme identifiant client.', + customProps: { + icon: , + }, + }, ]} /> @@ -146,13 +164,13 @@ Ces permissions demandées ne seront accordées à l’application tierce qu’a -Logto utilise le Contrôle d’accès basé sur les rôles (RBAC) pour gérer les permissions des utilisateurs. Sur l’écran de consentement, seules les portées (permissions) déjà attribuées à l’utilisateur — via ses rôles — seront affichées. Si une application tierce demande des portées que l’utilisateur ne possède pas, celles-ci seront exclues pour empêcher un consentement non autorisé. +Logto utilise le Contrôle d’accès basé sur les rôles (RBAC) pour gérer les permissions des utilisateurs. Sur l’écran de consentement, seuls les scopes (permissions) déjà attribués à l’utilisateur — via ses rôles — seront affichés. Si une application tierce demande des scopes que l’utilisateur ne possède pas, ceux-ci seront exclus pour éviter un consentement non autorisé. Pour gérer cela : -- Définissez des [rôles globaux](/authorization/role-based-access-control) ou des [rôles d’organisation](/authorization/organization-template) avec des portées spécifiques. +- Définissez des [rôles globaux](/authorization/role-based-access-control) ou [rôles d’organisation](/authorization/organization-template) avec des scopes spécifiques. - Attribuez des rôles aux utilisateurs selon leurs besoins d’accès. -- Les utilisateurs hériteront automatiquement des portées de leurs rôles. +- Les utilisateurs hériteront automatiquement des scopes de leurs rôles. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..9ca7fe770c2 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,99 @@ +--- +description: Permettez aux clients OAuth de se connecter à votre tenant sans pré-enregistrement en utilisant une URL de document de métadonnées d’ID client comme leur ID client. +sidebar_label: Application dynamique (CIMD) +sidebar_position: 3 +--- + +# Application dynamique (CIMD) + +L’application dynamique permet aux clients OAuth de se connecter à votre tenant sans pré-enregistrement. Au lieu d’un ID client délivré par Logto, le client utilise une URL HTTPS publique comme `client_id`. Cette URL sert un document JSON décrivant le client, appelé [document de métadonnées d’ID client (CIMD)](https://auth.wiki/client-id-metadata-document). Logto récupère ce document et considère le client comme une [application tierce](/integrate-logto/third-party-applications). + +L’application dynamique implémente le draft IETF [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html). + +## Quand utiliser l’application dynamique \{#when-to-use-dynamic-app} + +Le pré-enregistrement fonctionne lorsque vous connaissez vos partenaires. Il ne fonctionne pas lorsqu’un client quelconque peut se connecter, ce qui est courant dans l’écosystème [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents) : un utilisateur demande à son agent IA de se connecter à votre service, et l’agent n’a jamais communiqué avec votre tenant auparavant. + +Avec l’application dynamique, le client publie ses propres métadonnées à une URL qu’il possède, et cette URL est son identité. Rien n’a besoin d’être créé à l’avance dans votre tenant. + +| | Application tierce enregistrée | Application dynamique | +| -------------- | ------------------------------ | ----------------------------------------- | +| ID client | Délivré par Logto | Une URL HTTPS détenue par le client | +| Enregistrement | Requis | Non requis | +| Secret client | Pris en charge | Non pris en charge | +| Permissions | Par application | Partagées par tous les clients dynamiques | +| Types de flux | Dépend du type d’application | `authorization_code` et `refresh_token` | + +Les clients dynamiques sont des clients publics, ils utilisent donc toujours [PKCE](https://auth.wiki/pkce). Vous pouvez utiliser les deux modèles en même temps. Un partenaire de confiance peut toujours avoir une application enregistrée avec ses propres permissions. + +## Activer l’application dynamique \{#enable-dynamic-app} + +1. Allez dans Console > Applications et ouvrez l’onglet **Applications tierces**. +2. Cliquez sur **Créer une application** et sélectionnez la carte **Application dynamique**. Cela active une fonctionnalité au niveau du tenant au lieu de créer une application. +3. Confirmez dans la boîte de dialogue. Une fois activée, tout client OAuth avec une URL HTTPS publique valide comme ID client peut démarrer une requête d’autorisation pour votre tenant. +4. Ouvrez l’application dynamique depuis la liste des applications et allez dans l’onglet **Permissions** pour accorder des permissions. + +L’application dynamique n’a pas de nom modifiable, d’URI de redirection ou de credentials. Chaque client fournit les siens dans son document de métadonnées. + +:::note +L’application dynamique nécessite la [protection SSRF du fournisseur OIDC](/concepts/core-service/configuration#oidc-provider-ssrf-protection), car Logto récupère les documents de métadonnées depuis Internet. Les instances auto-hébergées qui la désactivent ne peuvent pas activer l’application dynamique. +::: + +### Accorder des permissions \{#grant-permissions} + +L’onglet **Permissions** définit les permissions maximales partagées par tous les clients dynamiques. Il fonctionne comme la [gestion des permissions](/integrate-logto/third-party-applications/permission-management) d’une application tierce enregistrée, avec des sections **Utilisateur** et **Organisation**. + +Demander une permission utilisateur non accordée entraîne une erreur, tandis que les permissions de ressource API et d’organisation non accordées sont ignorées. Les utilisateurs ne consentent également qu’aux permissions qu’ils possèdent via leurs [rôles](/authorization/role-based-access-control). + +Puisque chaque client dynamique partage cet ensemble, gardez-le minimal. + +## Publier un document de métadonnées d’ID client \{#publish-a-client-id-metadata-document} + +Si vous développez un client qui se connecte à Logto, hébergez un document de métadonnées et utilisez son URL comme votre `client_id`. L’URL doit utiliser le schéma `https` et ne contenir ni fragment, ni informations utilisateur, ni segments de chemin avec point. Logto envoie une requête `GET` à l’URL et attend un objet JSON. + +Par exemple, Claude Code utilise `https://claude.ai/oauth/claude-code-client-metadata`, qui sert : + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +Les noms de champs sont les mêmes que dans [OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591#section-2). À noter : + +- `client_id` doit être identique à l’URL qui sert le document. +- Les clients dynamiques sont des clients publics. Le document ne doit pas contenir de `client_secret`, et `token_endpoint_auth_method` ne doit pas être une méthode à secret partagé. Utilisez [PKCE](https://auth.wiki/pkce) à la place. +- Les URI de métadonnées comme `client_uri`, `logo_uri`, `tos_uri` et `policy_uri` doivent être des URLs absolues en `https`. Cela ne s’applique pas à `redirect_uris`, donc les clients natifs peuvent toujours utiliser des adresses loopback comme dans l’exemple ci-dessus. +- Les `redirect_uris` sont comparées comme des chaînes exactes, sauf que les adresses loopback peuvent être appariées avec n’importe quel port. Les [motifs génériques](/integrate-logto/application-data-structure#wildcard-patterns) sont également pris en charge. +- `scope`, `grant_types` et `response_types` sont décidés par Logto. Si le document les déclare, les valeurs sont ignorées. Les clients dynamiques ne peuvent utiliser que le flux authorization code et les jetons de rafraîchissement. + +Logto met en cache le document jusqu’à 24 heures, en suivant les en-têtes `Cache-Control` et `Expires` de votre réponse. Définissez-les selon la fréquence à laquelle vous prévoyez de mettre à jour le document. + +## Écran de consentement \{#consent-screen} + +Les clients dynamiques sont des applications tierces, donc l’[écran de consentement](/end-user-flows/consent-screen) est toujours affiché. + +L’écran de consentement affiche également un avis indiquant que le client n’est pas enregistré. Le nom et le logo du client proviennent du document de métadonnées, ils peuvent donc imiter n’importe quelle marque. L’hôte de l’URL d’ID client est également affiché, car c’est la seule partie que le client ne peut pas falsifier. + +## Gérer les autorisations \{#manage-authorizations} + +Les autorisations accordées aux clients dynamiques sont des [grants](/sessions/grants-management) tierces classiques. Les utilisateurs peuvent les consulter et les révoquer dans les paramètres du compte, et les administrateurs peuvent les gérer via la Management API. L’URL d’ID client sert à identifier le client. + +Désactiver l’application dynamique arrête les nouvelles requêtes d’autorisation, tandis que les grants existants sont conservés. Révoquer un grant oblige le client à obtenir à nouveau l’autorisation de l’utilisateur, mais les jetons d’accès précédemment délivrés peuvent rester valides jusqu’à leur expiration. + +## Limitations \{#limitations} + +- Seuls le flux authorization code avec PKCE et les jetons de rafraîchissement sont pris en charge. Les credentials client, device flow et l’échange de jetons ne sont pas disponibles. +- Les permissions et la personnalisation de marque ne peuvent pas être configurées par client. +- [Contrôle d’accès au niveau de l’application](/authorization/app-level-access-control) ne s’applique pas aux clients dynamiques, car ils n’ont pas d’enregistrement d’application. + +## Ressources associées \{#related-resources} + +Application tierce (OAuth / OIDC) + + Autoriser l’accès d’agents IA tiers à votre serveur MCP + diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index 94d13e7ff5e..79611355da3 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -2,47 +2,49 @@ sidebar_position: 2 --- -# Gérer les applications autorisées par l'utilisateur (autorisations) +# Gérer les applications autorisées par l'utilisateur (grants) -Les autorisations d'application représentent l'état d'autorisation de l'utilisateur pour des applications clientes spécifiques. +Les grants d'application représentent l'état d'autorisation de l'utilisateur pour des applications clientes spécifiques. -Utilisez la gestion des autorisations lorsque les utilisateurs ou les administrateurs doivent examiner les applications autorisées et révoquer l'accès à une application sans révoquer toute la session Logto. +Utilisez la gestion des grants lorsque les utilisateurs ou les administrateurs doivent examiner les applications autorisées et révoquer l'accès à une application sans révoquer toute la session Logto. -Lorsque les autorisations sont révoquées, les jetons d'accès opaques et les jetons de rafraîchissement précédemment émis pour ces autorisations sont invalidés. +Lorsque des grants sont révoqués, les jetons opaques d’accès (opaque access tokens) et les jetons de rafraîchissement (refresh tokens) précédemment émis pour ces grants sont invalidés. Les jetons d’accès JWT sont sans état, donc ceux déjà émis restent valides jusqu'à leur expiration. -## Choisissez le bon chemin \{#choose-the-right-path} +## Choisir la bonne voie \{#choose-the-right-path} -| Scénario | Chemin recommandé | -| ------------------------------------------------------------------------------------------------------------ | ----------------- | -| Permettre aux utilisateurs connectés de gérer leurs propres autorisations d'application | Account API | -| Permettre aux administrateurs ou aux équipes de support de gérer les autorisations pour un utilisateur cible | Management API | -| Permettre aux opérateurs de gérer les autorisations d'applications tierces dans l'interface utilisateur | Admin Console | +| Scénario | Voie recommandée | +| ------------------------------------------------------------------------------------------------- | ---------------- | +| Permettre aux utilisateurs connectés de gérer leurs propres autorisations d'applications | Account API | +| Permettre aux administrateurs ou équipes de support de gérer les grants pour un utilisateur cible | Management API | +| Permettre aux opérateurs de gérer les autorisations d'applications tierces dans l'interface | Admin Console | -## APIs de gestion directe des autorisations \{#direct-grant-management-apis} +## APIs de gestion directe des grants \{#direct-grant-management-apis} -### Account API (self-service) \{#account-api-self-service} +### Account API (en libre-service) \{#account-api-self-service} -Utilisez Account API dans les pages de paramètres de compte des utilisateurs finaux : +Utilisez Account API dans les pages de paramètres de compte utilisateur final : - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` -- Référence : [Gérer les applications autorisées par l'utilisateur (autorisations)](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) +- Référence : [Gérer les applications autorisées par l'utilisateur (grants)](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) ### Management API (outils d'administration) \{#management-api-admin-tools} -Utilisez Management API dans les outils d'administration et les flux de travail de support : +Utilisez Management API dans les outils d'administration et les workflows de support : - `GET /api/users/{userId}/grants` - `DELETE /api/users/{userId}/grants/{grantId}` -- Référence : [Gérer les applications autorisées par l'utilisateur (autorisations)](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) +- Référence : [Gérer les applications autorisées par l'utilisateur (grants)](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) -### Filtrer la liste des autorisations par type d'application \{#filter-grant-list-by-app-type} +### Filtrer la liste des grants par type d'application \{#filter-grant-list-by-app-type} -Les points de terminaison de liste des autorisations prennent en charge le paramètre de requête optionnel `appType` : +Les points de terminaison de la liste des grants prennent en charge le paramètre de requête optionnel `appType` : -- `appType=firstParty` : Lister uniquement les autorisations d'applications de première partie. -- `appType=thirdParty` : Lister uniquement les autorisations d'applications tierces. -- Omettre `appType` : Retourner toutes les autorisations actives. +- `appType=firstParty` : Lister uniquement les grants des applications internes (first-party). +- `appType=thirdParty` : Lister uniquement les grants des applications tierces (third-party). +- Omettre `appType` : Retourner tous les grants actifs. + +Les clients [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) sont des applications tierces, donc leurs grants sont retournés avec `appType=thirdParty`. L'URL de l'ID client est utilisée comme identifiant d'application. ## Gérer les autorisations d'applications tierces dans la Console \{#manage-third-party-app-authorizations-in-console} @@ -50,24 +52,24 @@ Dans Logto Console, utilisez la page de détails de l'utilisateur pour afficher - Référence : [Gérer les applications tierces autorisées par l'utilisateur](/user-management/manage-users#manage-user-authorized-third-party-apps) -## Révoquer les autorisations lors de la révocation d'une session \{#revoke-grants-when-revoking-a-session} +## Révoquer les grants lors de la révocation d'une session \{#revoke-grants-when-revoking-a-session} -Lors de la révocation d'une session via `DELETE /api/my-account/sessions/{sessionId}`, utilisez le paramètre de requête optionnel `revokeGrantsTarget` pour contrôler la portée de la révocation des autorisations : +Lors de la révocation d'une session via `DELETE /api/my-account/sessions/{sessionId}`, utilisez le paramètre de requête optionnel `revokeGrantsTarget` pour contrôler la portée de la révocation des grants : -- `all` : Révoquer les autorisations pour toutes les applications associées à la session. -- `firstParty` : Révoquer les autorisations pour les applications de première partie uniquement. +- `all` : Révoquer les grants pour toutes les applications associées à la session. +- `firstParty` : Révoquer les grants uniquement pour les applications internes (first-party). -Pour le comportement au niveau de la session et le contexte du point de terminaison, voir [Gérer les sessions utilisateur](/sessions/manage-user-sessions) et [Déconnexion](/end-user-flows/sign-out). +Pour le comportement au niveau de la session et le contexte des points de terminaison, voir [Gérer les sessions utilisateur](/sessions/manage-user-sessions) et [Déconnexion](/end-user-flows/sign-out). ## Ressources associées \{#related-resources} Sessions Gérer les sessions utilisateur - Paramètres de compte par Account API : Gérer les applications autorisées par l'utilisateur - (autorisations) + Paramètres du compte via Account API : Gérer les applications autorisées par l'utilisateur + (grants) - Paramètres de compte par Management API : Gérer les applications autorisées par l'utilisateur - (autorisations) + Paramètres du compte via Management API : Gérer les applications autorisées par l'utilisateur + (grants) diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index ffba6c03dfe..6d61c4aeb98 100644 --- a/i18n/fr/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/fr/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -5,40 +5,63 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- Pour permettre à l'agent IA tiers d'accéder à {props.serviceName ?? 'votre service'}, vous devez configurer une **application tierce** dans Logto. Cette application sera utilisée pour représenter l'agent IA et obtenir les identifiants nécessaires à l'authentification et à l'autorisation. :::info[Qu'est-ce qu'une application tierce ?] -Une **application tierce** est une application créée par des développeurs externes (et non par le propriétaire de la ressource) qui nécessite le consentement de l'utilisateur pour accéder à des ressources protégées. Contrairement aux applications propriétaires (vos propres applications), les applications tierces affichent un écran de consentement demandant aux utilisateurs d'approuver des permissions spécifiques avant d'accéder à leurs données. Cela garantit que les utilisateurs gardent le contrôle sur les données qu'ils partagent avec des services externes. +Une **application tierce** est une application créée par des développeurs externes (non propriétaire de la ressource) qui nécessite le consentement de l'utilisateur pour accéder à des ressources protégées. Contrairement aux applications propriétaires (vos propres applications), les applications tierces affichent un écran de consentement demandant aux utilisateurs d'approuver des permissions spécifiques avant d'accéder à leurs données. Cela garantit que les utilisateurs gardent le contrôle sur les données qu'ils partagent avec des services externes. Pour en savoir plus, consultez [Applications tierces](/integrate-logto/third-party-applications). ::: -### Autoriser les développeurs à créer des applications tierces dans Logto \{#allow-developers-to-create-third-party-apps-in-logto} +Il existe trois façons d'intégrer des agents IA : -Si vous construisez une place de marché ou souhaitez permettre aux développeurs de créer des applications tierces dans Logto, vous pouvez utiliser [Logto Management API](/integrate-logto/interact-with-management-api) pour créer des applications tierces de manière programmatique. Cela permet aux développeurs d'enregistrer leurs applications et d'obtenir les identifiants nécessaires à l'authentification. +- [Créer manuellement l'application dans la Console](#manually-create-a-third-party-app-in-logto), pour des tests ou quelques agents connus. +- [Construire un service d'enregistrement sur le Management API](#allow-developers-to-create-third-party-apps-in-logto), si vous souhaitez contrôler qui obtient des identifiants. +- [Activer l'application dynamique](#let-any-ai-agent-connect-without-pre-registration), si n'importe quel agent peut se connecter et que vous ne souhaitez pas d'étape d'enregistrement. -Vous devrez héberger votre propre service pour gérer le processus d'enregistrement des clients. Ce service interagira avec Logto Management API pour créer des applications tierces au nom des développeurs. +### Permettre aux développeurs de créer des applications tierces dans Logto \{#allow-developers-to-create-third-party-apps-in-logto} + +Si vous construisez une place de marché ou souhaitez permettre aux développeurs de créer des applications tierces dans Logto, vous pouvez exploiter le [Logto Management API](/integrate-logto/interact-with-management-api) pour créer des applications tierces de manière programmatique. Cela permet aux développeurs d'enregistrer leurs applications et d'obtenir les identifiants nécessaires à l'authentification. + +Vous devrez héberger votre propre service pour gérer le processus d'enregistrement des clients. Ce service interagira avec le Logto Management API pour créer des applications tierces au nom des développeurs. ```mermaid sequenceDiagram - actor Développeur - participant Serveur as Votre service d'enregistrement d'applications + actor Developer + participant Server as Votre service d'enregistrement d'applications participant Logto as Logto Management API - Développeur->>Serveur: Enregistrer l'application - Serveur->>Logto: Créer l'application - Logto->>Serveur: ID de l'application, secret, etc. - Serveur->>Développeur: ID de l'application, secret, etc. + Developer->>Server: Enregistrer l'application + Server->>Logto: Créer l'application + Logto->>Server: ID de l'application, secret, etc. + Server->>Developer: ID de l'application, secret, etc. +``` + +Alternativement, vous pouvez créer manuellement des applications tierces dans la Console Logto pour vous familiariser avec le processus. + +### Permettre à n'importe quel agent IA de se connecter sans pré-enregistrement \{#let-any-ai-agent-connect-without-pre-registration} + +Dans un écosystème MCP ouvert, vous ne connaissez généralement pas les agents à l'avance. [Application dynamique](/integrate-logto/third-party-applications/dynamic-apps) supprime l'étape d'enregistrement : l'agent utilise une URL HTTPS publique servant son propre document de métadonnées client comme `client_id`, et Logto le résout lorsque la requête d'autorisation arrive. + +```mermaid +sequenceDiagram + participant Agent as Agent IA (client MCP) + participant Logto + participant Metadata as URL du document de métadonnées de l'agent + Agent->>Logto: Requête d'autorisation avec l'URL du client ID + Logto->>Metadata: Récupérer le document de métadonnées du client ID + Metadata->>Logto: Nom du client, logo, URI de redirection, etc. + Logto->>Agent: Écran de consentement, puis code d'autorisation ``` -Vous pouvez également créer manuellement des applications tierces dans Logto Console pour vous familiariser avec le processus. +Vous contrôlez toujours ce que les agents peuvent demander via les permissions accordées à l'application dynamique, et chaque autorisation passe par l'écran de consentement utilisateur. ### Créer manuellement une application tierce dans Logto \{#manually-create-a-third-party-app-in-logto} -Vous pouvez créer manuellement une application tierce dans Logto Console à des fins de test ou d'intégrations ponctuelles. Cela est utile lorsque vous souhaitez tester rapidement l'intégration sans mettre en œuvre un flux complet d'enregistrement de client. +Vous pouvez créer manuellement une application tierce dans la Console Logto à des fins de test ou pour des intégrations ponctuelles. Ceci est utile lorsque vous souhaitez tester rapidement l'intégration sans mettre en œuvre un flux complet d'enregistrement de client. -1. Connectez-vous à votre Logto Console. +1. Connectez-vous à votre Console Logto. 2. Allez dans **Applications** → **Créer une application** → **Application tierce** -> **OIDC**. 3. Renseignez le nom de l'application et les autres champs requis, puis cliquez sur **Créer une application**. 4. Cliquez sur l'onglet **Permissions**, dans la section **Utilisateur**, cliquez sur "Ajouter". 5. Dans la boîte de dialogue qui s'ouvre -> **Données utilisateur** -> sélectionnez les permissions **`profile`**, **`email`**, puis cliquez sur **Enregistrer**. -6. Dans l'application tierce, configurez les portées (scopes) pour demander les permissions (portées) `openid profile email`. +6. Dans l'application tierce, configurez les portées (scopes) pour demander les permissions `openid profile email`. **Remarque** : `openid` est requis pour OIDC, et `profile` et `email` sont les permissions que vous avez ajoutées à l'étape précédente. diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx index afa1f502ddb..74004e14634 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx @@ -6,45 +6,45 @@ sidebar_position: 7 # アプリレベルのアクセス制御 -アプリレベルのアクセス制御を利用すると、特定のアプリケーションにサインインできるユーザーを制限できます。Logto テナント内のすべての登録ユーザーがすべてのアプリにアクセスできるのではなく、ユーザー、ユーザーロール、組織、または組織ロールに基づいて各アプリケーションごとに許可ルールを作成できます。 +アプリレベルのアクセス制御を利用すると、特定のアプリケーションにサインインできるユーザーを制限できます。Logto テナントに登録されているすべてのユーザーがすべてのアプリにアクセスできるのではなく、ユーザー、ユーザーロール、組織 (Organizations)、または組織ロールごとに各アプリケーションの許可ルールを作成できます。 アプリレベルのアクセス制御は、次のような場合に利用します： -- 社内アプリを従業員や管理者のみに公開したい場合。 -- [Protected App](/integrate-logto/protected-app) を特定のユーザーグループのみに制限したい場合。 -- 特定の顧客やパートナーだけが [サードパーティ OIDC / OAuth アプリケーション](/integrate-logto/third-party-applications) にアクセスできるようにしたい場合。 -- 新しいアプリケーションを全体公開する前にパイロットグループに展開したい場合。 +- 社内アプリを従業員や管理者のみに公開したい場合 +- [Protected App](/integrate-logto/protected-app) を特定のユーザーグループのみに制限したい場合 +- 特定の顧客やパートナーだけが [サードパーティ OIDC / OAuth アプリケーション](/integrate-logto/third-party-applications) にアクセスできるようにしたい場合 +- 新しいアプリケーションを全体公開する前にパイロットグループに展開したい場合 ## 仕組み \{#how-it-works} -アプリレベルのアクセス制御が無効な場合、Logto テナント内のすべての登録ユーザーがそのアプリケーションにサインインできます。 +アプリレベルのアクセス制御が無効な場合、Logto テナントに登録されているすべてのユーザーがそのアプリケーションにサインインできます。 -有効にすると、ユーザーは少なくとも 1 つの設定済みルールに一致した場合のみアプリケーションにアクセスできます。ユーザーがどのルールにも一致しない場合、Logto はサインイン試行を拒否し、アプリケーションがトークンを受け取る前にアクセス拒否ページを表示します。 +有効にすると、ユーザーは少なくとも 1 つの設定済みルールに一致した場合のみアプリケーションにアクセスできます。ユーザーがいずれのルールにも一致しない場合、Logto はサインイン試行を拒否し、アプリケーションがトークンを受け取る前にアクセス拒否ページを表示します。 アプリレベルのアクセス制御は、認可 (Authorization) フローおよびトークンの更新時に評価されます。つまり： - アクセス権のないユーザーは、アプリケーションのサインインを完了する前にブロックされます。 -- 既存のアプリ権限は、リフレッシュトークンを使用して新しいトークンをリクエストする際に再度チェックされます。 +- 既存のアプリグラントは、リフレッシュトークンを使用して新しいトークンをリクエストする際に再度チェックされます。 - ルールの更新は、ユーザーのグローバルな Logto セッションを変更することなく、今後の認可 (Authorization) およびトークン更新チェックに影響します。 :::note -アプリレベルのアクセス制御は [ロールベースのアクセス制御 (RBAC)](/authorization/role-based-access-control) とは別物です。RBAC はアクセス トークン内の権限（スコープ）を発行することで、認証 (Authentication) 後にユーザーが何をできるかを制御します。アプリレベルのアクセス制御は、ユーザーが特定のアプリケーションにそもそもアクセスできるかどうかを制御します。 +アプリレベルのアクセス制御は [ロールベースのアクセス制御 (RBAC)](/authorization/role-based-access-control) とは別物です。RBAC はアクセス トークン内の権限 (スコープ) を発行することで、認証 (Authentication) 後にユーザーが何をできるかを制御します。アプリレベルのアクセス制御は、ユーザーが特定のアプリケーションにそもそもアクセスできるかどうかを制御します。 ::: ## ルールの種類 \{#rule-types} 次の許可ルールを設定できます： -| ルールの種類 | 許可される内容 | -| ------------------ | -------------------------------------------------------------------------------------- | -| **ユーザー** | 特定のユーザーがアプリケーションにアクセスできます。 | -| **ユーザーロール** | 選択したユーザーロールに割り当てられたユーザーがアプリケーションにアクセスできます。 | -| **組織** | 選択した組織のすべての現在および将来のメンバーがアプリケーションにアクセスできます。 | -| **組織ロール** | 選択した組織内で選択した組織ロールを持つメンバーがアプリケーションにアクセスできます。 | +| ルールの種類 | 許可される内容 | +| ------------------------ | ------------------------------------------------------------------------------------------------------- | +| **ユーザー** | 特定のユーザーがアプリケーションにアクセスできます。 | +| **ユーザーロール** | 選択したユーザーロールに割り当てられたユーザーがアプリケーションにアクセスできます。 | +| **組織 (Organizations)** | 選択した組織 (Organizations) のすべての現在および将来のメンバーがアプリケーションにアクセスできます。 | +| **組織ロール** | 選択した組織 (Organizations) 内で選択した組織ロールを持つメンバーがアプリケーションにアクセスできます。 | ルールは加算式です。ユーザーは 1 つのルールに一致すればアプリケーションにアクセスできます。 -例えば、アプリケーションに「サポートチーム」ユーザーロールルールと「BigTree - 管理者」組織ロールルールの両方がある場合、ユーザーがサポートチームロールに割り当てられているか、BigTree 組織で管理者であればアプリケーションにアクセスできます。 +たとえば、アプリケーションに「サポートチーム」ユーザーロールルールと「BigTree - 管理者」組織ロールルールの両方がある場合、ユーザーがサポートチームロールに割り当てられているか、BigTree 組織の管理者であればアプリケーションにアクセスできます。 ## アプリレベルのアクセス制御を設定する \{#configure-app-level-access-control} @@ -55,14 +55,14 @@ sidebar_position: 7 5. ルールの種類を選択します： - **ユーザー** - **ユーザーロール** - - **組織** + - **組織 (Organizations)** - **組織ロール** -6. アプリケーションへのアクセスを許可したいユーザー、ロール、組織、または組織ロールを選択します。 -7. **アクセス制御を有効にする** をオンにします。 +6. アプリケーションへのアクセスを許可するユーザー、ロール、組織 (Organizations)、または組織ロールを選択します。 +7. **アクセス制御を有効化** をオンにします。 8. **変更を保存** をクリックします。 :::important -アクセス制御を有効にする前に、少なくとも 1 つの許可ルールを設定する必要があります。これにより、誰もアプリケーションにアクセスできない状態で誤ってアクセス制御を有効にすることを防ぎます。 +アクセス制御を有効にする前に、少なくとも 1 つの許可ルールを設定する必要があります。これにより、誰もアプリケーションにアクセスできない状態でアクセス制御を誤って有効化することを防ぎます。 ::: ## ルールの編集または削除 \{#edit-or-remove-rules} @@ -73,7 +73,7 @@ sidebar_position: 7 - ルールを削除するには、ルール行の削除ボタンをクリックし、操作を確認します。 - ルールを追加または削除した後、**変更を保存** をクリックして更新を適用します。 -アクセス制御が有効な場合、Logto は少なくとも 1 つのルールが設定されていることを要求します。すべてのルールを削除するには、まず **アクセス制御を有効にする** をオフにしてから、変更を保存してください。 +アクセス制御が有効な場合、Logto は少なくとも 1 つのルールが設定されていることを要求します。すべてのルールを削除するには、まず **アクセス制御を有効化** をオフにしてから変更を保存してください。 ## ルール変更がユーザーに与える影響 \{#how-rule-changes-affect-users} @@ -81,10 +81,10 @@ sidebar_position: 7 制限対象のアプリケーションについて： -- もはやどの許可ルールにも一致しなくなったユーザーは、次回アプリケーションの認可 (Authorization) フローを通過する際にブロックされます。 -- すでにアプリ関連の権限を持っている場合、アプリケーションがリフレッシュトークンを使って新しいトークンをリクエストする際に再度ルールがチェックされます。ユーザーがもはやアクセス権を持たない場合、Logto はトークンリクエストを拒否します。 +- いずれの許可ルールにも一致しなくなったユーザーは、次回そのアプリケーションの認可 (Authorization) フローを通過する際にブロックされます。 +- すでにアプリ関連のグラントを持っている場合、アプリケーションがリフレッシュトークンを使って新しいトークンをリクエストする際に再度ルールがチェックされます。ユーザーがアクセス権を失っていれば、Logto はトークンリクエストを拒否します。 -これにより、アクセス判断がアプリケーション単位で行われ、他のアプリケーションへの不要な影響を避けることができます。 +これにより、アクセス判断がアプリケーション単位で行われ、他のアプリケーションへの不要な影響を避けられます。 ## サードパーティアプリの権限との関係 \{#relationship-with-third-party-app-permissions} @@ -93,18 +93,22 @@ sidebar_position: 7 - **アプリレベルのアクセス制御** は、ユーザーがサードパーティアプリケーションにサインインできるかどうかを決定します。 - **権限管理** は、サードパーティアプリケーションが同意画面でリクエストできるユーザープロフィールスコープ、API リソーススコープ、組織スコープを決定します。 -両方が設定されている場合、ユーザーはサードパーティアプリケーションを認可 (Authorization) する前にアプリレベルのアクセス制御を通過する必要があります。 +両方が設定されている場合、ユーザーはまずアプリレベルのアクセス制御を通過しなければサードパーティアプリケーションを認可 (Authorization) できません。 + +:::note +アプリレベルのアクセス制御は登録済みアプリケーションのみに適用されます。[ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps) クライアントにはアプリケーションレコードがないため、この方法で制限できません。ダイナミックアプリへのアクセスは、付与した権限およびユーザーの同意によって制限されます。 +::: ## Protected App との関係 \{#relationship-with-protected-app} -[Protected App](/integrate-logto/protected-app) では、アプリレベルのアクセス制御によって、Logto の認証 (Authentication) レイヤーを通過して保護されたオリジンサーバーに到達できるユーザーが制限されます。 +[Protected App](/integrate-logto/protected-app) では、アプリレベルのアクセス制御によって Logto の認証 (Authentication) レイヤーを通過し、保護されたオリジンサーバーに到達できるユーザーを制限します。 -Protected App の認証 (Authentication) ルールは、どのルートが認証 (Authentication) を必要とするかを決定します。アプリレベルのアクセス制御は、認証 (Authentication) 済みの Logto ユーザーのうち、Protected App アプリケーションにアクセスできるユーザーを決定します。 +Protected App の認証 (Authentication) ルールは、どのルートに認証 (Authentication) が必要かを決定します。アプリレベルのアクセス制御は、認証 (Authentication) 済みの Logto ユーザーのうち、Protected App アプリケーションにアクセスできるユーザーを決定します。 ## ベストプラクティス \{#best-practices} - 可能な限りユーザーロールまたは組織ロールルールから始めましょう。個別ユーザーの長いリストよりも管理が簡単です。 -- 組織内の全員がアプリにアクセスすべき場合は、組織ルールを使用しましょう。 -- 組織内の特定メンバーだけがアプリにアクセスすべき場合は、組織ロールルールを使用しましょう。 -- ユーザーのロール変更、組織への参加・離脱時にはアクセスルールを見直しましょう。 +- 組織 (Organizations) 内の全員がアプリにアクセスすべき場合は、組織ルールを使いましょう。 +- 組織 (Organizations) の特定メンバーだけがアプリにアクセスすべき場合は、組織ロールルールを使いましょう。 +- ユーザーのロール変更、組織 (Organizations) への参加・離脱時にはアクセスルールを見直しましょう。 - RBAC の権限とアプリレベルのアクセス制御は頭の中で分けて考えましょう：アプリレベルのアクセス制御は「このユーザーはこのアプリにアクセスできるか？」、RBAC は「このユーザーは API や組織機能にアクセスした後に何ができるか？」に答えます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/ja/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index 5a91c43e4d8..004d83d592b 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -11,10 +11,10 @@ Logto は環境変数を次の順序で処理します： したがって、システム環境変数は `.env` の値を上書きします。 -### 変数 {#variables} +### 変数一覧 {#variables} :::caution -プロジェクトルートで `npm start` を使って Logto を実行する場合、`NODE_ENV` は常に `production` になります。 +プロジェクトルートで `npm start` で Logto を実行する場合、`NODE_ENV` は常に `production` になります。 ::: デフォルト値では、`protocol` は HTTPS 設定に応じて `http` または `https` になります。 @@ -26,7 +26,7 @@ Logto は環境変数を次の順序で処理します： | ADMIN_PORT | `3002` | `number` | Logto 管理コンソールがリッスンするローカルポート。 | | ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | `1` または `true` に設定すると管理コンソール用ポートを無効化します。`ADMIN_ENDPOINT` が未設定の場合、管理コンソールが完全に無効化されます。 | | DB_URL | N/A | `string` | Logto データベース用の [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6)。 | -| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL の `statement_timeout`（ミリ秒単位）。数値文字列（例：`5000`）で設定、または `DISABLE_TIMEOUT` で起動パラメータを省略（PgBouncer / RDS Proxy に推奨）。未設定または無効な場合、クライアントデフォルトは 60000 ms。 | +| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL の `statement_timeout`（ミリ秒単位）。数値文字列（例：`5000`）で設定、または `DISABLE_TIMEOUT` で起動パラメータを省略（PgBouncer / RDS Proxy 推奨）。未設定または無効の場合、クライアントのデフォルトは 60000 ms。 | | HTTPS_CERT_PATH | `undefined` | string | undefined | 詳細は [HTTPS 有効化](#enabling-https) を参照。 | | HTTPS_KEY_PATH | `undefined` | string | undefined | 同上。 | | TRUST_PROXY_HEADER | `false` | `boolean` | 同上。 | @@ -34,22 +34,24 @@ Logto は環境変数を次の順序で処理します： | ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | 本番用にカスタムドメインの URL を指定できます（例：`ADMIN_ENDPOINT=https://admin.domain.com`）。これにより管理コンソールのリダイレクト URI の値も影響を受けます。 | | CASE_SENSITIVE_USERNAME | `true` | `boolean` | ユーザー名の大文字小文字を区別するかどうかを指定します。この値を変更する際は注意してください。既存のデータベースデータは自動的に調整されないため、手動で管理する必要があります。 | | SECRET_VAULT_KEK | `undefined` | `string` | [Secret Vault](/secret-vault) でデータ暗号化キー (DEK) を暗号化するためのキー暗号化キー (KEK)。Secret Vault の正常動作に必須。base64 エンコード文字列である必要があります。AES-256（32 バイト）推奨。例：`crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | 段階的な OIDC 秘密鍵ローテーションの猶予期間（秒単位）。正の値に設定すると、新しい秘密鍵はまず `Next` として作成され、猶予期間後に有効になります。 | -| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | セルフホストのみ。信頼できる OIDC リライングパーティエンドポイントがプライベートネットワークアドレスに解決される必要がある場合のみ `true` に設定してください。[OIDC プロバイダー SSRF 保護](#oidc-provider-ssrf-protection) を参照。 | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | 段階的な OIDC 秘密鍵ローテーションの猶予期間（秒単位）。正の値を設定すると、新しい秘密鍵は最初に `Next` として作成され、猶予期間後に有効になります。 | +| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | セルフホストのみ。信頼できる OIDC リライングパーティーエンドポイントがプライベートネットワークアドレスに解決される必要がある場合のみ `true` に設定してください。[OIDC プロバイダー SSRF 保護](#oidc-provider-ssrf-protection) を参照。 | ### OIDC プロバイダー SSRF 保護 {#oidc-provider-ssrf-protection} -Logto はデフォルトで OIDC プロバイダーの外部リクエストに対してサーバーサイドリクエストフォージェリ (SSRF) から保護します。ループバックやプライベートネットワークアドレスなどの特殊用途アドレスへのリクエストはブロックされます。この保護は、バックチャネルログアウト URI、`jwks_uri`、`sector_identifier_uri` などのリライングパーティエンドポイントをカバーします。 +Logto はデフォルトで OIDC プロバイダーの外部リクエストに対してサーバーサイドリクエストフォージェリ (SSRF) から保護します。ループバックやプライベートネットワークアドレスなどの特殊用途アドレスへのリクエストはブロックされます。この保護は、バックチャネルログアウト URI、`jwks_uri`、`sector_identifier_uri` などのリライングパーティーエンドポイントや、 [ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps) のクライアント ID メタデータドキュメント取得にも適用されます。 -セルフホスト環境で、信頼できるリライングパーティエンドポイントにプライベートネットワーク経由でアクセスする必要がある場合は、`OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` を設定し、すべての Logto インスタンスを再起動してください。 +セルフホスト環境で、信頼できるリライングパーティーエンドポイントがプライベートネットワーク上にある場合は、`OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` を設定し、すべての Logto インスタンスを再起動してください。 :::caution -この設定は、すべての OIDC プロバイダー外部リクエストに対して SSRF 保護を無効化します。特定のエンドポイントだけでなく全体が対象です。すべてのリライングパーティエンドポイントが信頼でき、ネットワーク制御で内部サービスへのアクセスが防止されている場合のみ無効化してください。 +この設定は、すべての OIDC プロバイダー外部リクエストに対して SSRF 保護を無効化します。1 つのエンドポイントだけでなく全体に影響するため、すべてのリライングパーティーエンドポイントが信頼でき、かつネットワーク制御で機密内部サービスへのアクセスが防止されている場合のみ無効化してください。 + +[ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps) は、この保護が無効な間は有効化できません。なぜなら、クライアント自身が指定した URL からメタデータドキュメントを取得するためです。 ::: -### HTTPS 有効化 {#enabling-https} +### HTTPS の有効化 {#enabling-https} #### Node を利用する場合 {#using-node} @@ -69,12 +71,12 @@ Node はネイティブで HTTPS をサポートしています。`HTTPS_CERT_PA 環境変数が多すぎると管理が非効率かつ柔軟性に欠けるため、一般的な設定の多くはデータベーステーブル `logto_configs` に保存されています。 -このテーブルはシンプルなキー・バリュー型ストレージで、キーは次のように列挙可能です： +このテーブルはシンプルなキー・バリュー型ストレージであり、キーは次のように列挙可能です： -| Key | Type | 説明 | -| ---------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------- | -| oidc.cookieKeys | string[] | [署名クッキーキー](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#cookieskeys) の文字列配列。 | -| oidc.privateKeys | string[] | [OIDC JWT 署名](https://openid.net/specs/openid-connect-core-1_0.html#Signing) 用の秘密鍵内容の文字列配列。 | +| Key | Type | 説明 | +| ---------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------- | +| oidc.cookieKeys | string[] | [署名付きクッキーキー](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#cookieskeys) の文字列配列。 | +| oidc.privateKeys | string[] | [OIDC JWT 署名](https://openid.net/specs/openid-connect-core-1_0.html#Signing) 用の秘密鍵内容の文字列配列。 | ### サポートされている秘密鍵タイプ {#supported-private-key-types} diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index 853bb5eaac5..ff82956468c 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -6,34 +6,38 @@ sidebar_position: 6 ## 同意画面 (Consent screen) とは？ \{#what-is-consent-screen} -Google アカウントを使って Logto にサインアップする場面を想像してください。「Google でサインイン」ボタンをクリックすると、Google のサインインページにリダイレクトされます。Google の認証情報を入力した後、Logto が Google アカウント情報へアクセスする許可を求める画面が表示されます。これがユーザー同意画面 (consent screen) です。 +Google アカウントで Logto にサインアップする場面を想像してください。「Google でサインイン」ボタンをクリックすると、Google のサインインページにリダイレクトされます。Google の認証情報を入力した後、Logto が Google アカウント情報へのアクセス許可を求める画面が表示されます。これがユーザー同意画面 (consent screen) です。 -このページは、ユーザー **同意画面 (consent screen)** または **同意ページ (consent page)** と呼ばれます。これは標準的な [OIDC / OAuth 2.0 フロー](/integrate-logto/third-party-applications) であり、ユーザーが [サードパーティアプリケーション](/integrate-logto/third-party-applications) に自分のデータへのアクセス権限を付与できるようにします。その主な目的は、ユーザーに個人データの収集・処理・利用について通知し、これらの活動に対する明示的な同意を求めることです。 +このページは、ユーザー **同意画面 (consent screen)** または **同意ページ (consent page)** と呼ばれます。これは、ユーザーが [サードパーティアプリケーション](/integrate-logto/third-party-applications) に自分のデータへのアクセス権限を付与できる標準的な [OIDC / OAuth 2.0 フロー](/integrate-logto/third-party-applications) です。その主な目的は、ユーザーに個人データの収集、処理、利用について通知し、これらの活動に対する明確な同意を求めることです。 -同意画面では、通常、どの種類のデータが収集され、どのように利用され、第三者と共有されるかについての [情報](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information) がユーザーに提示されます。この情報は透明性のために重要であり、ユーザーがプライバシーやデータセキュリティについて十分な判断を下せるようにします。 +同意画面 (consent screen) では、通常、収集されるデータの種類、その利用方法、第三者への共有の有無などの [情報](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information) がユーザーに提示されます。この情報は透明性のために重要であり、ユーザーがプライバシーやデータセキュリティについて十分な判断を下せるようにします。 -同意ページは、欧州連合の一般データ保護規則 ([GDPR](https://gdpr-info.eu/art-4-gdpr/)) や米国カリフォルニア州消費者プライバシー法 ([CCPA](https://oag.ca.gov/privacy/ccpa)) などのプライバシー規制の文脈で特に重要です。これらの規制は、組織がユーザーの個人情報を処理する前に明確かつ積極的な同意を取得することを求めています。 +同意ページ (consent page) は、欧州連合の一般データ保護規則 ([GDPR](https://gdpr-info.eu/art-4-gdpr/)) や米国カリフォルニア州消費者プライバシー法 ([CCPA](https://oag.ca.gov/privacy/ccpa)) などのプライバシー規制の文脈で特に重要です。これらの規制は、組織がユーザーの個人情報を処理する前に明確かつ積極的な同意を取得することを求めています。 -## Logto でユーザーが同意画面 (Consent screen) を見るタイミング \{#when-does-user-see-the-consent-screen-in-logto} +## Logto でユーザーが同意画面 (consent screen) を見るタイミング \{#when-does-user-see-the-consent-screen-in-logto} -前述の通り、同意画面 (consent screen) は、ユーザーが Google、Facebook、Apple などのサードパーティアイデンティティプロバイダー (IdP) を使って Logto にサインインする際に表示されます。この構成では、Logto はサービスプロバイダー (SP) として機能し、IdP からユーザー情報へのアクセスを要求します。同意画面は、[SP](https://auth.wiki/service-provider) と [IdP](https://auth.wiki/identity-provider) が異なる組織である場合に一般的に表示され、データ共有のためにユーザーの認可 (Authorization) が必要となります。 +前述のとおり、同意画面 (consent screen) は、ユーザーが Google、Facebook、Apple などのサードパーティアイデンティティプロバイダー (IdP) を使って Logto にサインインする際に表示されます。この構成では、Logto はサービスプロバイダー (SP) として機能し、IdP からユーザー情報へのアクセスを要求します。同意画面 (consent screen) は、[SP](https://auth.wiki/service-provider) と [IdP](https://auth.wiki/identity-provider) が別組織である場合に一般的に表示され、データ共有を促進するためにユーザーの認可 (Authorization) が必要となります。 Consent screen Logto as SP -同様に、Logto が IdP として機能する場合、Logto と連携した [**OIDC / OAuth サードパーティアプリケーション**](/integrate-logto/third-party-applications) にユーザーがサインインする際にも同意画面が表示されます。この画面では、アプリケーションが要求しているデータについてユーザーに通知し、処理を進めるための許可を求めます。ユーザーは要求された権限を確認し、そのアプリケーションに認可 (Authorization) を与えるかどうかを決定できます。 +同様に、Logto が IdP として機能する場合、Logto と連携した [**OIDC / OAuth サードパーティアプリケーション**](/integrate-logto/third-party-applications) にユーザーがサインインする際にも同意画面 (consent screen) が表示されます。この画面では、アプリケーションが要求しているデータについてユーザーに通知し、処理を進めるための許可を求めます。ユーザーは要求された権限を確認し、アプリケーションへの認可 (Authorization) を与えるかどうかを決定できます。 Consent screen Logto as IdP -## 同意画面 (Consent screen) の設定方法 \{#how-to-configure-the-consent-screen} +### 未登録（ダイナミック）クライアント \{#unregistered-dynamic-clients} -Logto の同意フローでは、サードパーティアプリケーションからのログインを認可 (Authorization) できます。各 OIDC サードパーティアプリケーションごとにブランディングや権限リクエストをカスタマイズできます。 +[ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps) が有効な場合、クライアントは事前登録なしでテナントに接続できます。これらのクライアントに対しては、同意画面 (consent screen) に追加の注意書きとクライアント ID URL のホストが表示されます。クライアント名やロゴはクライアント自身のメタデータドキュメントから取得されるため、どのブランドでも模倣できますが、ホストは偽装できません。 + +## 同意画面 (consent screen) の設定方法 \{#how-to-configure-the-consent-screen} + +Logto の同意フロー (consent flow) では、サードパーティアプリケーションからのログインを認可 (Authorization) できます。各 OIDC サードパーティアプリケーションごとにブランディングや権限リクエストをカスタマイズできます。 [サードパーティアプリケーション](/integrate-logto/third-party-applications/) のセットアップや、Logto での [同意画面 (consent screen)](/integrate-logto/third-party-applications/consent-screen-branding/) の設定方法について詳しく学べます。 ## 関連リソース \{#related-resources} - サービスを同意画面付きの安全な OIDC IdP に変える方法 + サービスを同意画面 (consent screen) 付きの安全な OIDC IdP に変える方法 ユーザー同意画面 (consent screen) の紹介 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 04c84dc2ff3..c96aa611655 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,5 +1,5 @@ --- -description: OIDC 認証 (Authentication) 統合のための主要なアプリケーションパラメーター（リダイレクト URI、エンドポイント、リフレッシュ トークン、バックチャネル ログアウトなど）を参照できます。 +description: OIDC 認証 (Authentication) 統合のための主要なアプリケーションパラメーター（リダイレクト URI、エンドポイント、リフレッシュ トークン、バックチャネルログアウトなど）を参照できます。 sidebar_position: 7 --- @@ -7,42 +7,46 @@ sidebar_position: 7 ## はじめに \{#introduction} -Logto における _アプリケーション_ とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代理での操作を行う権限が付与された特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API へのリクエスト元を識別し、ユーザーがそれらのアプリケーションへアクセスする際の認証 (Authentication) および認可 (Authorization) プロセスを管理するために使用されます。 +Logto における _アプリケーション_ とは、Logto プラットフォームに登録され、ユーザー情報へのアクセスやユーザーの代理でアクションを実行する認可 (Authorization) を受けた特定のソフトウェアプログラムまたはサービスを指します。アプリケーションは、Logto API へのリクエスト元の識別や、ユーザーがそれらのアプリケーションへアクセスする際の認証 (Authentication)・認可 (Authorization) プロセスの管理に使用されます。 -Logto のサインイン体験におけるアプリケーションの利用により、ユーザーは一箇所から自分が認可 (Authorization) されたアプリケーションへ簡単にアクセス・管理でき、統一された安全な認証 (Authentication) プロセスが提供されます。これによりユーザー体験が効率化され、認可 (Authorization) された人物のみが機密情報へアクセスしたり、組織の代理で操作を行ったりできるようになります。 +Logto のサインイン体験におけるアプリケーションの利用により、ユーザーは一箇所から認可 (Authorization) されたアプリケーションへ簡単にアクセス・管理でき、一貫性と安全性の高い認証 (Authentication) プロセスが実現します。これによりユーザー体験が効率化され、認可 (Authorization) された人物のみが機密情報へアクセスしたり、組織の代理でアクションを実行できるようになります。 -また、アプリケーションは Logto の監査ログでも使用され、ユーザーのアクティビティを追跡し、潜在的なセキュリティ脅威や侵害を特定するのに役立ちます。特定の操作を特定のアプリケーションと関連付けることで、Logto はデータがどのようにアクセス・利用されているかについて詳細なインサイトを提供し、組織がセキュリティやコンプライアンス要件をより適切に管理できるようにします。 -アプリケーションを Logto と統合したい場合は、 [Logto との統合](/integrate-logto) を参照してください。 +また、アプリケーションは Logto の監査ログでも利用され、ユーザーアクティビティの追跡や潜在的なセキュリティ脅威・侵害の特定に役立ちます。特定のアクションを特定のアプリケーションと関連付けることで、Logto はデータのアクセス・利用状況を詳細に把握でき、組織のセキュリティやコンプライアンス要件の管理を支援します。 +アプリケーションを Logto と統合したい場合は、 [Logto との統合](/integrate-logto) をご覧ください。 ## プロパティ \{#properties} ### アプリケーション ID \{#application-id} -_アプリケーション ID_ は、Logto 内でアプリケーションを識別するための一意の自動生成キーであり、OAuth 2.0 では [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) として参照されます。 +_アプリケーション ID_ は Logto 内でアプリケーションを識別するための一意な自動生成キーであり、OAuth 2.0 では [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) として参照されます。 + +:::note +[ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps) クライアントは Logto に登録されません。これらのクライアント ID はクライアントが所有する公開 HTTPS URL であり、クライアントメタデータドキュメントを提供します。 +::: ### アプリケーションタイプ \{#application-types} -_アプリケーション_ は、次のいずれかのアプリケーションタイプとなります： +_アプリケーション_ は次のいずれかのタイプとなります： - **ネイティブアプリ**：ネイティブ環境で動作するアプリ。例：iOS アプリ、Android アプリ。 - - **デバイスフローアプリ**：入力制限のあるデバイスやヘッドレスアプリケーション（例：スマート TV、ゲームコンソール、CLI ツール、IoT デバイス）向けの特別なネイティブアプリタイプです。標準のリダイレクトベースのフローの代わりに [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) を使用します。詳細は [デバイスフロー クイックスタート](/quick-starts/device-flow) を参照してください。 -- **シングルページアプリ**：Web ブラウザ上で動作し、サーバーからの新しいデータでページ全体を再読み込みせずに更新するアプリ。例：React DOM アプリ、Vue アプリ。 + - **デバイスフローアプリ**：入力制限デバイスやヘッドレスアプリケーション（例：スマート TV、ゲーム機、CLI ツール、IoT デバイス）向けの特別なネイティブアプリです。標準のリダイレクトベースフローの代わりに [OAuth 2.0 デバイス認可 (Authorization) グラント](https://auth.wiki/device-flow) を使用します。詳細は [デバイスフロー クイックスタート](/quick-starts/device-flow) をご覧ください。 +- **シングルページアプリ**：Web ブラウザ上で動作し、サーバーから新しいデータを取得してページ全体を再読み込みせずに更新するアプリ。例：React DOM アプリ、Vue アプリ。 - **従来型 Web アプリ**：Web サーバーのみでページをレンダリング・更新するアプリ。例：JSP、PHP。 - **マシン間通信 (M2M) アプリ**：ユーザー操作なしでサービス間通信を直接行うマシン環境で動作するアプリケーション。 ### アプリケーションシークレット \{#application-secret} -_アプリケーションシークレット_ は、認証 (Authentication) システム内でアプリケーションを認証 (Authentication) するためのキーであり、特にプライベートクライアント（従来型 Web および M2M アプリ）におけるプライベートなセキュリティバリアとして機能します。 +_アプリケーションシークレット_ は認証 (Authentication) システムでアプリケーションを認証 (Authentication) するためのキーであり、特にプライベートクライアント（従来型 Web アプリや M2M アプリ）でプライベートなセキュリティバリアとして利用されます。 :::tip -シングルページアプリ (SPA) およびネイティブアプリにはアプリシークレットは提供されません。SPA およびネイティブアプリは「パブリッククライアント」であり、シークレットを保持できません（ブラウザコードやアプリバンドルは検査可能です）。アプリシークレットの代わりに、Logto は PKCE、厳格なリダイレクト URI / CORS 検証、短命なアクセス トークン、リフレッシュ トークンのローテーションで保護します。 +シングルページアプリ（SPA）やネイティブアプリはアプリシークレットを提供しません。SPA やネイティブアプリは「パブリッククライアント」であり、シークレットを保持できません（ブラウザコードやアプリバンドルは検査可能なため）。アプリシークレットの代わりに、Logto は PKCE、厳格なリダイレクト URI / CORS 検証、短命なアクセス トークン、リフレッシュ トークンのローテーションで保護します。 ::: ### アプリケーション名 \{#application-name} -_アプリケーション名_ は、人間が読めるアプリケーションの名称であり、管理コンソールに表示されます。 +_アプリケーション名_ はアプリケーションの人間が読める名称であり、管理コンソールに表示されます。 -_アプリケーション名_ は Logto でアプリケーションを管理する上で重要な要素であり、管理者がプラットフォーム内の個々のアプリケーションのアクティビティを簡単に識別・追跡できるようにします。 +_アプリケーション名_ は Logto でアプリケーションを管理する上で重要な要素であり、管理者が個々のアプリケーションのアクティビティを簡単に識別・追跡できるようにします。 :::note _アプリケーション名_ は管理コンソールにアクセスできるすべてのユーザーに表示されるため、慎重に選択することが重要です。アプリケーションの目的や機能を正確に反映し、分かりやすく認識しやすい名称にしてください。 @@ -50,61 +54,61 @@ _アプリケーション名_ は管理コンソールにアクセスできる ### 説明 \{#description} -アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的や機能、その他関連情報など、管理者に追加情報を提供することを意図しています。 +アプリケーションの簡単な説明が管理コンソールのアプリケーション詳細ページに表示されます。説明は、アプリケーションの目的や機能、その他関連情報など、管理者に追加情報を提供するためのものです。 ### リダイレクト URI \{#redirect-uris} _リダイレクト URI_ は、アプリケーションに事前設定された有効なリダイレクト URI のリストです。ユーザーが Logto にサインインしアプリケーションへアクセスしようとすると、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。 -許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto へ送信される認可 (Authorization) リクエストに含まれるリダイレクト URI を検証するために使用されます。認可 (Authorization) リクエストで指定されたリダイレクト URI がアプリケーション設定の許可リストのいずれかと一致する場合、認証 (Authentication) 成功後にその URI へリダイレクトされます。一致しない場合、ユーザーはリダイレクトされず、認証 (Authentication) プロセスは失敗します。 +許可された URI リストは、認証 (Authentication) プロセス中にアプリケーションから Logto へ送信される認可 (Authorization) リクエストに含まれるリダイレクト URI の検証に使用されます。認可 (Authorization) リクエストで指定されたリダイレクト URI がアプリケーション設定の許可リストに一致する場合、認証 (Authentication) 成功後にその URI へリダイレクトされます。一致しない場合、リダイレクトされず認証 (Authentication) プロセスは失敗します。 :::note -すべての有効なリダイレクト URI を Logto のアプリケーションの許可リストに追加することが重要です。これにより、認証 (Authentication) 後にユーザーが正常にアプリケーションへアクセスできるようになります。 +すべての有効なリダイレクト URI を Logto のアプリケーションの許可リストに追加しておくことが重要です。これにより、認証 (Authentication) 後にユーザーがアプリケーションへ正常にアクセスできるようになります。 ::: -詳細は [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) を参照してください。 +詳細は [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) をご覧ください。 - OIDC における認可コードフローでのリダイレクト URI の理解 + OIDC の認可コードフローにおけるリダイレクト URI の理解 #### ワイルドカードパターン \{#wildcard-patterns} -_対象: シングルページアプリ、従来型 Web アプリ_ +_対象：シングルページアプリ、従来型 Web アプリ_ -リダイレクト URI は、プレビュー環境などの動的環境向けにワイルドカードパターン（`*`）をサポートしています。ワイルドカードは HTTP / HTTPS URI のホスト名およびパス名部分で使用できます。 +リダイレクト URI は、プレビュー環境など動的な環境向けにワイルドカードパターン（`*`）をサポートしています。ワイルドカードは HTTP / HTTPS URI のホスト名およびパス名部分で使用できます。 **ルール：** - ワイルドカードはホスト名およびパス名のみ許可 -- スキーム、ポート、クエリパラメータ、ハッシュフラグメントではワイルドカードは許可されません -- ホスト名のワイルドカードは少なくとも 1 つのドットを含む必要があります（例：`https://*.example.com/callback`） +- スキーム、ポート、クエリパラメータ、ハッシュフラグメントでは使用不可 +- ホスト名のワイルドカードは少なくとも 1 つのドットを含む必要あり（例：`https://*.example.com/callback`） **例：** -- `https://*.example.com/callback` - 任意のサブドメインにマッチ -- `https://preview-*.example.com/callback` - プレビュー環境にマッチ -- `https://example.com/*/callback` - 任意のパスセグメントにマッチ +- `https://*.example.com/callback` - 任意のサブドメインに一致 +- `https://preview-*.example.com/callback` - プレビュー環境に一致 +- `https://example.com/*/callback` - 任意のパスセグメントに一致 :::caution -ワイルドカードリダイレクト URI は標準 OIDC ではなく、攻撃対象領域が広がる可能性があります。可能な限り正確なリダイレクト URI を優先して使用してください。 +ワイルドカードリダイレクト URI は標準 OIDC ではなく、攻撃対象領域が広がる可能性があります。利用は慎重に行い、可能な限り正確なリダイレクト URI を推奨します。 ::: ### サインアウト後リダイレクト URI \{#post-sign-out-redirect-uris} -_サインアウト後リダイレクト URI_ は、ユーザーが Logto からサインアウトした後にリダイレクトされるよう、アプリケーションに事前設定された有効な URI のリストです。 +_サインアウト後リダイレクト URI_ は、ユーザーが Logto からサインアウトした後にリダイレクトされるアプリケーション用に事前設定された有効な URI のリストです。 -Allowed _Post Sign-out Redirect URIs_ の利用は、OIDC の RP-Initiated（Relying Party Initiated）Logout 仕様の一部です。この仕様は、アプリケーションがユーザーのログアウトリクエストを開始し、サインアウト後にユーザーを事前設定されたエンドポイントへリダイレクトする標準化された方法を提供します。 +Allowed _Post Sign-out Redirect URIs_ の利用は、OIDC の RP-Initiated（Relying Party Initiated）Logout 仕様の一部です。この仕様は、アプリケーションがユーザーのログアウトリクエストを開始し、サインアウト後に事前設定されたエンドポイントへリダイレクトする標準化された方法を提供します。 -ユーザーが Logto からサインアウトすると、そのセッションは終了し、アプリケーション設定で指定された許可された URI のいずれかにリダイレクトされます。これにより、サインアウト後にユーザーが認可 (Authorization) された有効なエンドポイントのみに誘導され、未知または未検証のエンドポイントへのリダイレクトによる不正アクセスやセキュリティリスクを防ぎます。 +ユーザーが Logto からサインアウトすると、そのセッションは終了し、アプリケーション設定で指定された許可 URI のいずれかにリダイレクトされます。これにより、サインアウト後にユーザーが認可 (Authorization) された有効なエンドポイントのみに誘導され、未知または未検証のエンドポイントへのリダイレクトによる不正アクセスやセキュリティリスクを防ぎます。 -詳細は [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) を参照してください。 +詳細は [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) をご覧ください。 ### CORS 許可オリジン \{#cors-allowed-origins} _CORS（クロスオリジンリソースシェアリング）許可オリジン_ は、アプリケーションが Logto サービスへリクエストを送信できる許可されたオリジンのリストです。許可リストに含まれていないオリジンからは Logto サービスへのリクエストはできません。 -CORS 許可オリジンリストは、未認可ドメインからの Logto サービスへのアクセスを制限し、クロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐのに役立ちます。Logto でアプリケーションごとに許可オリジンを指定することで、認可 (Authorization) されたドメインのみがサービスへリクエストできるようにします。 +CORS 許可オリジンリストは、未認可ドメインからの Logto サービスへのアクセスを制限し、クロスサイトリクエストフォージェリ（CSRF）攻撃の防止にも役立ちます。Logto でアプリケーションごとに許可オリジンを指定することで、認可 (Authorization) されたドメインのみがサービスへリクエストできるようにします。 :::note 許可オリジンリストには、アプリケーションが提供されるオリジンを含めてください。これにより、アプリケーションからのリクエストは許可され、未認可オリジンからのリクエストはブロックされます。 @@ -116,17 +120,17 @@ CORS 許可オリジンリストは、未認可ドメインからの Logto サ ### 認可 (Authorization) エンドポイント \{#authorization-endpoint} -_認可 (Authorization) エンドポイント_ は OIDC 用語であり、ユーザーの認証 (Authentication) プロセスを開始するために使用される必須エンドポイントです。ユーザーが Logto プラットフォームに登録された保護されたリソースやアプリケーションへアクセスしようとすると、_認可 (Authorization) エンドポイント_ へリダイレクトされ、アイデンティティの認証 (Authentication) およびリソースへのアクセス権限の取得が行われます。 +_認可 (Authorization) エンドポイント_ は OIDC 用語であり、ユーザーの認証 (Authentication) プロセスを開始するために使用される必須エンドポイントです。ユーザーが Logto プラットフォームに登録された保護されたリソースやアプリケーションへアクセスしようとすると、_認可 (Authorization) エンドポイント_ へリダイレクトされ、アイデンティティの認証 (Authentication) とリソースへのアクセス認可 (Authorization) を取得します。 -詳細は [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) を参照してください。 +詳細は [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) をご覧ください。 ### トークンエンドポイント \{#token-endpoint} _トークンエンドポイント_ は OIDC 用語であり、OIDC クライアントが OIDC プロバイダーからアクセス トークン、ID トークン、リフレッシュ トークンを取得するための Web API エンドポイントです。 -OIDC クライアントがアクセス トークンや ID トークンを取得する必要がある場合、トークンエンドポイントへ認可 (Authorization) グラント（通常は認可コードまたはリフレッシュ トークン）を送信します。トークンエンドポイントは認可 (Authorization) グラントを検証し、有効な場合はクライアントにアクセス トークンや ID トークンを発行します。 +OIDC クライアントがアクセス トークンや ID トークンを取得する必要がある場合、認可 (Authorization) グラント（通常は認可コードまたはリフレッシュ トークン）とともにトークンエンドポイントへリクエストを送信します。トークンエンドポイントは認可 (Authorization) グラントを検証し、有効な場合はクライアントにアクセス トークンや ID トークンを発行します。 -詳細は [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) を参照してください。 +詳細は [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) をご覧ください。 ### Userinfo エンドポイント \{#userinfo-endpoint} @@ -134,76 +138,76 @@ OpenID Connect の [UserInfo Endpoint](https://openid.net/specs/openid-connect-c ### 常にリフレッシュ トークンを発行 \{#always-issue-refresh-token} -_対象: 従来型 Web、SPA_ +_対象：従来型 Web、SPA_ 有効にすると、認証 (Authentication) リクエストで `prompt=consent` やスコープに `offline_access` が指定されていなくても、Logto は常にリフレッシュ トークンを発行します。 -ただし、この運用は必要な場合以外は推奨されません（通常はリフレッシュ トークンが必須な一部のサードパーティ OAuth 連携で有用です）。OpenID Connect との互換性がなく、問題が発生する可能性があります。 +ただし、この運用は必要な場合（通常はリフレッシュ トークンを必要とする一部のサードパーティ OAuth 連携）を除き推奨されません。OpenID Connect との互換性がなく、問題が発生する可能性があります。 ### リフレッシュ トークンのローテーション \{#rotate-refresh-token} -_デフォルト: `true`_ +_デフォルト：`true`_ -有効にすると、クライアントがリフレッシュ トークンを使って新しいトークンをリクエストした際に、新しいリフレッシュ トークンが発行される場合があります。リフレッシュ トークンとそのアプリグラントが有効な場合、デフォルトのローテーションポリシーは次の通りです： +有効にすると、クライアントがリフレッシュ トークンを使って新しいトークンをリクエストする際に、新しいリフレッシュ トークンが発行される場合があります。リフレッシュ トークンとそのアプリグラントが有効な場合、デフォルトのローテーションポリシーは次の通りです： -- リフレッシュ トークンは、リフレッシュ トークンチェーンが 1 年間存在する前のみローテーション可能です。これは内部的なローテーション安全上限であり、リフレッシュ トークン自身の TTL やアプリグラント TTL が先に失効する場合もあります。上限に達すると、Logto はリフレッシュ トークンをローテーションせず、現在のリフレッシュ トークンの有効期限が最終となります。 +- リフレッシュ トークンは、リフレッシュ トークンチェーンが 1 年間存在するまでのみローテーション可能です。これは内部的なローテーション安全上限であり、リフレッシュ トークン自身の TTL やアプリグラント TTL が先に失効する場合もあります。上限に達すると、Logto はリフレッシュ トークンをローテーションせず、現在のリフレッシュ トークンの有効期限が最終となります。 - センダー制約のないパブリッククライアント（例：通常のネイティブアプリやシングルページアプリ）では、ローテーションが許可されている間はリフレッシュ トークンリクエストごとにリフレッシュ トークンをローテーションします。 -- その他のクライアントでは、有効期限が近づいた場合（元の TTL の 70％以上経過）にのみリフレッシュ トークンをローテーションします。 +- その他のクライアントでは、有効期限が近い場合（元の TTL の 70％以上経過）にのみリフレッシュ トークンをローテーションします。 :::note パブリッククライアントでは、セキュリティ上の理由からリフレッシュ トークンのローテーションを有効にしておくことを強く推奨します。 -センダー制約付きリフレッシュ トークンは、クライアントが保持する証明キーや証明書にバインドされます。通常の SPA では、ローテーションにより新しいリフレッシュ トークンが発行されますが、リフレッシュ トークンの有効期間は延長されません。新しいリフレッシュ トークンは前のリフレッシュ トークンの残り TTL を継承します。 +センダー制約付きリフレッシュ トークンは、クライアントが保持する証明鍵や証明書にバインドされます。通常の SPA では、ローテーションにより新しいリフレッシュ トークンが発行されますが、リフレッシュ トークンの有効期間は延長されません。新しいリフレッシュ トークンは前のリフレッシュ トークンの残り TTL を継承します。 ::: :::caution リフレッシュ トークンチェーンの有効期間 -リフレッシュ トークンはアプリグラントに紐づいています。Logto のデフォルトグラント TTL は **180 日** です。グラントが失効すると、リフレッシュ トークンリクエストは失敗し、リフレッシュ トークンは新しいトークンの取得に使用できなくなります。リフレッシュ トークンのローテーションが有効でも同様です。 +リフレッシュ トークンはアプリグラントに紐づきます。Logto のデフォルトグラント TTL は **180 日** です。グラントが失効すると、リフレッシュ トークンリクエストは失敗し、リフレッシュ トークンは新しいトークンの取得に使用できなくなります。たとえリフレッシュ トークンのローテーションが有効でも同様です。 つまり、リフレッシュ トークンによる認可 (Authorization) の実質的な最大有効期間は、グラント TTL、明示的な失効、またはリフレッシュ トークン自身の有効期限のいずれか早い方で制限されます。 ::: - リフレッシュ トークンのローテーションの理解 + リフレッシュ トークンローテーションの理解 -### リフレッシュ トークンの有効期間 (TTL) 日数 \{#refresh-token-time-to-live-ttl-in-days} +### リフレッシュ トークンの有効期間（TTL、日数） \{#refresh-token-time-to-live-ttl-in-days} -_対象: ネイティブアプリ、従来型 Web、SPA; デフォルト: 14 日; 最大: 180 日_ +_対象：ネイティブアプリ、従来型 Web、SPA；デフォルト：14 日；最大：180 日_ -リフレッシュ トークンが新しいアクセス トークンをリクエストできる有効期間です。有効期間を過ぎるとリフレッシュ トークンは無効になります。トークンリクエストによりリフレッシュ トークンの TTL はこの値まで延長されます。 +リフレッシュ トークンが失効し無効になるまで、新しいアクセス トークンをリクエストできる期間です。トークンリクエストによりリフレッシュ トークンの TTL がこの値まで延長されます。 通常は、より低い値が推奨されます。 :::note -SPA ではセキュリティ上の理由から TTL の延長はできません。SPA ではこの設定がリフレッシュ トークンの固定有効期間となり、Logto はトークンリクエストによる TTL 延長を行わず、リフレッシュ トークンのローテーションも SPA のリフレッシュ トークンの有効期限切れを防ぎません。 +SPA ではセキュリティ上の理由から TTL の延長はできません。SPA ではこの設定がリフレッシュ トークンの固定有効期間となり、トークンリクエストによる延長は行われません。リフレッシュ トークンのローテーションも SPA のリフレッシュ トークンの有効期限切れを防ぎません。 ::: :::caution リフレッシュ トークン TTL とグラント TTL -リフレッシュ トークン TTL は唯一の有効期限制限ではありません。リフレッシュ トークンはアプリグラントに紐づいており、Logto のデフォルトグラント TTL は **180 日** です。グラントが失効すると、リフレッシュ トークンが有効でもリクエストは失敗します。 +リフレッシュ トークン TTL だけが有効期限ではありません。リフレッシュ トークンはアプリグラントに紐づき、Logto のデフォルトグラント TTL は **180 日** です。グラントが失効すると、リフレッシュ トークンが有効でもリクエストは失敗します。 -トークンリクエストでリフレッシュ トークン TTL が延長されるクライアントでは、グラント TTL がリフレッシュ トークンチェーンの絶対最大有効期間となります。SPA では、リフレッシュ トークンの固定 TTL がグラントより先に失効する場合があります。 +トークンリクエストでリフレッシュ トークン TTL が延長されるクライアントでは、グラント TTL がリフレッシュ トークンチェーンの絶対最大有効期間となります。SPA ではリフレッシュ トークンの固定 TTL がグラントより先に失効する場合もあります。 ::: :::caution リフレッシュ トークンとセッションバインディング -認可 (Authorization) リクエストで `offline_access` スコープなしでリフレッシュ トークンが発行された場合、ユーザーセッションにバインドされます。セッションの固定 TTL は **14 日** です。セッションが失効すると、リフレッシュ トークンは自身の TTL 設定に関わらず無効となります。 +認可 (Authorization) リクエストで `offline_access` スコープを指定せずにリフレッシュ トークンが発行された場合、そのリフレッシュ トークンはユーザーセッションにバインドされます。セッションの固定 TTL は **14 日** です。セッションが失効すると、リフレッシュ トークンは自身の TTL 設定に関わらず無効となります。 -リフレッシュ トークン TTL 設定を最大限活用するには、認可 (Authorization) リクエストに `offline_access` スコープを含めてください。 +リフレッシュ トークン TTL 設定を十分に活用するには、認可 (Authorization) リクエストに `offline_access` スコープを含めてください。 ::: -### バックチャネル ログアウト URI \{#backchannel-logout-uri} +### バックチャネルログアウト URI \{#backchannel-logout-uri} -OpenID Connect のバックチャネル ログアウトエンドポイントです。詳細は [フェデレーテッドサインアウト：バックチャネル ログアウト](#) を参照してください。 +OpenID Connect のバックチャネルログアウトエンドポイントです。詳細は [フェデレーションサインアウト：バックチャネルログアウト](#) をご覧ください。 -### 最大許可グラント数 (`maxAllowedGrants`) \{#max-allowed-grants-maxallowedgrants} +### 最大許可グラント数（`maxAllowedGrants`） \{#max-allowed-grants-maxallowedgrants} -`maxAllowedGrants` は、`customClientMetadata` 配下のオプションのアプリレベルフィールドで、現在のアプリにおけるユーザーごとの同時アクティブグラント数の上限を制御します。 +`maxAllowedGrants` は `customClientMetadata` 配下のオプションのアプリレベルフィールドで、現在のアプリにおけるユーザーごとの同時アクティブグラント数の上限を制御します。 - **デフォルト**：`undefined`（制限なし） -- **設定時**：認可 (Authorization) 成功ごとに、Logto は現在のアプリでのユーザーの全アクティブグラント数（ブラウザやデバイスをまたいで）をチェックします。上限を超えた場合、Logto は最も古いグラントを失効させます。 +- **設定時**：認可 (Authorization) 成功ごとに、Logto は現在のアプリでのユーザーのアクティブグラント総数（ブラウザやデバイスをまたいで）を確認し、上限を超えた場合は最も古いグラントを失効させます。 この設定は、アプリごとに同時認証 (Authentication) デバイス数を制限したい場合に便利です。 -各エビクション時に `Grant.LimitExceeded` [Webhook イベント](/developers/webhooks/webhooks-events#exception-hook-events) が発生するため、ユーザーへの通知や上限到達頻度のトラッキングが可能です。 +各エビクション時には `Grant.LimitExceeded` [Webhook イベント](/developers/webhooks/webhooks-events#exception-hook-events) が発火するため、ユーザーへの通知や上限到達頻度のトラッキングが可能です。 :::note @@ -217,4 +221,4 @@ OpenID Connect のバックチャネル ログアウトエンドポイントで ### カスタムデータ \{#custom-data} -事前定義されたアプリケーションプロパティに含まれない追加のカスタムアプリケーション情報です。ユーザーは、ビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。 +事前定義されたアプリケーションプロパティに含まれない追加のカスタムアプリ情報です。ユーザーはビジネス固有の設定や構成など、特定のニーズに応じて独自のカスタムデータフィールドを定義できます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index f7e434bb688..53aa95d0987 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -1,39 +1,47 @@ --- -description: Logto を使って独自のアイデンティティプロバイダーを作成し、サードパーティアプリケーション向けにシングルサインオン (SSO) を有効化できます。OIDC / OAuth アプリケーションの統合も簡単です。 +description: Logto を使って独自のアイデンティティプロバイダー (IdP) を作成し、サードパーティアプリケーション向けにシングルサインオン (SSO) を有効化できます。OIDC / OAuth アプリケーションの統合も簡単です。 sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; # サードパーティアプリ (OAuth / OIDC) -Logto のサードパーティアプリケーション統合を利用すると、Logto を外部アプリケーションの [アイデンティティプロバイダー (IdP)](https://auth.wiki/identity-provider) として活用できます。 +Logto のサードパーティアプリケーション統合により、Logto を外部アプリケーションの [アイデンティティプロバイダー (IdP)](https://auth.wiki/identity-provider) として活用できます。 -アイデンティティプロバイダー (IdP) とは、ユーザーのアイデンティティを検証し、ログイン認証情報を管理するサービスです。ユーザーのアイデンティティを確認した後、IdP は認証トークンやアサーションを生成し、ユーザーが再度ログインすることなくさまざまなアプリケーションやサービスにアクセスできるようにします。 +アイデンティティプロバイダー (IdP) とは、ユーザーのアイデンティティを検証し、そのログイン認証情報を管理するサービスです。ユーザーのアイデンティティを確認した後、IdP は認証 (Authentication) トークンやアサーションを生成し、ユーザーが再度ログインすることなくさまざまなアプリケーションやサービスにアクセスできるようにします。 -[アプリケーションへの Logto 統合](/integrate-logto/integrate-logto-into-your-application) ガイドで作成したアプリケーションが自分で開発・完全に管理できるものだったのに対し、サードパーティアプリケーションは外部の開発者やビジネスパートナーによって開発された独立したサービスです。 +[アプリケーションへの Logto 統合](/integrate-logto/integrate-logto-into-your-application) ガイドで作成したアプリケーションが自社開発・完全管理下にあるのに対し、サードパーティアプリケーションは外部開発者やビジネスパートナーによって開発された独立したサービスです。 -この統合アプローチは、一般的なビジネスシナリオに最適です。Logto アカウントを使ってパートナーアプリケーションにアクセスできるようにしたり、エンタープライズユーザーが Google Workspace で Slack にサインインするような体験を提供できます。また、サードパーティアプリケーションが「Logto でサインイン」機能を追加できるオープンプラットフォームを構築することも可能です（「Google でサインイン」と同様）。 +この統合アプローチは、一般的なビジネスシナリオに最適です。Logto アカウントを使ってパートナーアプリケーションへアクセスできるようにしたり、エンタープライズユーザーが Google Workspace で Slack にサインインするような体験を提供できます。また、サードパーティアプリケーションが「Logto でサインイン」機能を追加できるオープンプラットフォームを構築することも可能です（「Google でサインイン」と同様）。 -Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコルに基づくアイデンティティサービスであり、[認証 (Authentication)](https://auth.wiki/authentication) と [認可 (Authorization)](https://auth.wiki/authorization) の両方の機能を提供します。これにより、OIDC サードパーティアプリの統合は従来のウェブアプリケーションと同じくらい簡単です。 +Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコルに基づくアイデンティティサービスであり、[認証 (Authentication)](https://auth.wiki/authentication) と [認可 (Authorization)](https://auth.wiki/authorization) の両方の機能を提供します。これにより、OIDC サードパーティアプリの統合は従来の Web アプリケーションと同じくらい簡単です。 -また、OIDC は [OAuth 2.0](https://auth.wiki/oauth-2.0) の上に認証レイヤーを追加して構築されているため、OAuth プロトコルを使ったサードパーティアプリの統合も可能です。 +また、OIDC は [OAuth 2.0](https://auth.wiki/oauth-2.0) の上に認証 (Authentication) レイヤーを追加して構築されているため、OAuth プロトコルを使ったサードパーティアプリの統合も可能です。 + +## サードパーティアプリのオンボーディング方法は 2 つ \{#two-ways-to-onboard-a-third-party-app} + +- **Logto でアプリを登録する**（本ガイド）：アプリケーションを作成し、その権限やリダイレクト URI を設定します。パートナーが明確な場合に利用します。 +- **[ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps)**：事前登録なしでクライアントが接続でき、自身のメタデータドキュメントの公開 HTTPS URL をクライアント ID として利用します。MCP クライアントや AI エージェントなど、どんなクライアントでも接続する可能性がある場合に利用します。 + +両方を同時に利用することも可能です。 ## Logto でサードパーティアプリケーションを作成する \{#create-a-third-party-application-in-logto} -1. コンソール > アプリケーション に移動します。 +1. コンソール ＞ アプリケーション にアクセスします。 2. 「アプリケーションを作成」ボタンをクリックし、「サードパーティアプリ」をアプリケーションタイプとして選択し、次のいずれかの統合プロトコルを選びます： - OIDC / OAuth 3. サードパーティアプリケーションのタイプに応じてアプリケーションタイプを選択します： - - **従来型ウェブ**：バックエンドでクライアントシークレットを安全に保存できるサーバーレンダリングアプリケーション（例：Node.js、PHP、Java）。 - - **シングルページアプリ (SPA)**：完全にブラウザ上で動作し、シークレットを安全に保存できないクライアントサイドレンダリングアプリケーション（例：React、Vue、Angular）。 + - **従来型 Web**：バックエンドでクライアントシークレットを安全に保管できるサーバーレンダリングアプリケーション（例：Node.js、PHP、Java）。 + - **シングルページアプリ (SPA)**：クライアントサイドでレンダリングされ、ブラウザ上で動作しシークレットを安全に保管できないアプリケーション（例：React、Vue、Angular）。 - **ネイティブ**：ユーザーデバイス上で動作するモバイルまたはデスクトップアプリケーション（例：iOS、Android、Electron）。 -4. アプリケーションの名前と説明を入力し、「作成」ボタンをクリックします。新しいサードパーティアプリケーションが作成されます。 +4. アプリケーション名と説明を入力し、「作成」ボタンをクリックします。新しいサードパーティアプリケーションが作成されます。 -作成したサードパーティアプリケーションはすべて、「アプリケーション」ページの「サードパーティアプリ」タブに一覧表示されます。この構成により、自分のアプリケーションと区別しやすくなり、すべてのアプリケーションを一元管理できます。 +作成したサードパーティアプリケーションはすべて、「アプリケーション」ページの「サードパーティアプリ」タブに一覧表示されます。この構成により、自社アプリケーションと区別しやすくなり、すべてのアプリケーションを一元管理できます。 サードパーティアプリケーションにサインインできるユーザーを制限したい場合は、アプリケーションの **ルール** タブで [アプリレベルのアクセス制御](/authorization/app-level-access-control) を設定してください。 @@ -41,9 +49,9 @@ Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコ ### アプリケーション設定情報の確認 \{#find-the-application-configurations} -アプリケーション詳細ページで、統合に必要な [**クライアント ID**](/integrate-logto/application-data-structure#application-id)、[**クライアントシークレット**](/integrate-logto/application-data-structure#application-secret)（従来型ウェブアプリのみ）、および OIDC エンドポイントを確認できます。 +アプリケーション詳細ページで、[**クライアント ID**](/integrate-logto/application-data-structure#application-id)、[**クライアントシークレット**](/integrate-logto/application-data-structure#application-secret)（従来型 Web アプリのみ）、および統合に必要な OIDC エンドポイントを確認できます。 -サードパーティサービスが OIDC ディスカバリーに対応している場合は、**ディスカバリーエンドポイント** を提供するだけで済みます。対応していない場合は、**エンドポイントの詳細を表示** をクリックして、[認可エンドポイント](/integrate-logto/application-data-structure#authorization-endpoint) や [トークンエンドポイント](/integrate-logto/application-data-structure#token-endpoint) などすべてのエンドポイントを確認してください。 +サードパーティサービスが OIDC ディスカバリーに対応している場合は、**ディスカバリーエンドポイント** を提供するだけで OK です。対応していない場合は、**エンドポイントの詳細を表示** をクリックして、[認可エンドポイント](/integrate-logto/application-data-structure#authorization-endpoint) や [トークンエンドポイント](/integrate-logto/application-data-structure#token-endpoint) などすべてのエンドポイントを確認してください。 ### サードパーティ IdP 対応サービスとの統合 \{#integrate-with-services-that-support-third-party-idp} @@ -51,61 +59,61 @@ Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコ 1. サービスの IdP または SSO 設定ページを開きます。 2. Logto から **クライアント ID**（必要に応じて **クライアントシークレット** も）をコピーし、サービスの設定に貼り付けます。 -3. サービスが OIDC 自動ディスカバリーに対応していれば **ディスカバリーエンドポイント** を、対応していなければ **認可エンドポイント** と **トークンエンドポイント** を手動でコピーします。 +3. サービスが OIDC 自動ディスカバリーに対応していれば **ディスカバリーエンドポイント** を、非対応の場合は **認可エンドポイント** と **トークンエンドポイント** を手動でコピーします。 4. サービスの設定ページから **リダイレクト URI** をコピーし、Logto アプリケーションの許可リダイレクト URI に追加します。 -5. サービスが許可していれば **スコープ** を設定します。Logto は OIDC プロバイダーなので、ユーザー認証が必要な場合は `openid` スコープを含めてください（ID トークンや UserInfo エンドポイントへのアクセスが可能になります）。OAuth リソースアクセスのみ必要な場合は `openid` スコープは任意です。 +5. サービスが許可していれば **スコープ** を設定します。Logto は OIDC プロバイダーなので、ユーザー認証 (Authentication) が必要な場合は `openid` スコープを含めてください（ID トークンや UserInfo エンドポイントへのアクセスが可能になります）。OAuth リソースアクセスのみ必要な場合は `openid` スコープは任意です。 設定が完了すると、サービス側で OAuth / OIDC フローが自動的に処理されます。 ### OAuth / OIDC プロトコルによる統合 \{#integrate-via-oauth-protocol} -サードパーティアプリケーションがプログラム的に Logto を IdP として統合する場合、標準の [認可コードフロー](https://auth.wiki/authorization-code-flow) を実装する必要があります。実装には、各プログラミング言語向けの OAuth 2.0 / OIDC クライアントライブラリの利用を推奨します。 +サードパーティアプリケーションがプログラム的に Logto を IdP として統合する場合、標準の [認可コードフロー](https://auth.wiki/authorization-code-flow) を実装する必要があります。実装には、プログラミング言語向けの OAuth 2.0 / OIDC クライアントライブラリの利用を推奨します。 - + -従来型ウェブアプリケーションは、クライアントシークレットをバックエンドサーバーで安全に保存できる **機密クライアント** です。実装の詳細は [認可コードフロー](https://auth.wiki/authorization-code-flow) を参照してください。 +従来型 Web アプリケーションは、クライアントシークレットをバックエンドサーバーで安全に保管できる **機密クライアント** です。実装の詳細は [認可コードフロー](https://auth.wiki/authorization-code-flow) を参照してください。 **主な手順：** -1. **認可の開始**：`client_id`、`redirect_uri`、`response_type=code`、`scope` を付与して Logto の認可エンドポイントにユーザーをリダイレクトします。 -2. **コールバックの処理**：リダイレクトから認可 `code` を受け取ります。 -3. **トークンの交換**：バックエンドから、code・`client_id`・`client_secret` をトークンエンドポイントに POST します。 +1. **認可開始**：`client_id`、`redirect_uri`、`response_type=code`、`scope` を指定して Logto の認可エンドポイントへリダイレクトします。 +2. **コールバック処理**：リダイレクトから認可 `code` を受け取ります。 +3. **トークン交換**：バックエンドからトークンエンドポイントへ code、`client_id`、`client_secret` を POST します。 -シングルページアプリやネイティブアプリは、シークレットを安全に保存できない **パブリッククライアント** です。これらのアプリケーションは、クライアントシークレットの代わりに [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) を使って安全な認可を行う必要があります。実装の詳細は [認可コードフロー](https://auth.wiki/authorization-code-flow) および [PKCE](https://auth.wiki/pkce) を参照してください。 +シングルページアプリやネイティブアプリは、シークレットを安全に保管できない **パブリッククライアント** です。クライアントシークレットの代わりに [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) を使って安全な認可を行います。実装の詳細は [認可コードフロー](https://auth.wiki/authorization-code-flow) および [PKCE](https://auth.wiki/pkce) を参照してください。 **主な手順：** -1. **PKCE パラメータの生成**：`code_verifier` を作成し、`code_challenge`（SHA-256）を導出します。 -2. **認可の開始**：`code_challenge` と `code_challenge_method=S256` を付与して認可エンドポイントにユーザーをリダイレクトします。 -3. **コールバックの処理**：リダイレクトから認可 `code` を受け取ります。 -4. **トークンの交換**：code と元の `code_verifier` をトークンエンドポイントに POST します。 +1. **PKCE パラメータ生成**：`code_verifier` を作成し、`code_challenge`（SHA-256）を導出します。 +2. **認可開始**：`code_challenge` と `code_challenge_method=S256` を指定して認可エンドポイントへリダイレクトします。 +3. **コールバック処理**：リダイレクトから認可 `code` を受け取ります。 +4. **トークン交換**：トークンエンドポイントへ code と元の `code_verifier` を POST します。 ### デバイスフローによる統合 \{#integrate-via-device-flow} -入力が制限されたデバイス（例：スマートテレビ、ゲーム機、CLI ツール）上で動作するネイティブサードパーティアプリケーションの場合、標準のリダイレクトベースの認可コードフローは現実的でない場合があります。その場合は、[OAuth 2.0 デバイス認可グラント](https://auth.wiki/device-flow) を利用できます。 +入力が制限されたデバイス（例：スマート TV、ゲーム機、CLI ツール）上で動作するネイティブサードパーティアプリケーションの場合、標準的なリダイレクトベースの認可コードフローは現実的でない場合があります。その場合は [OAuth 2.0 デバイス認可グラント](https://auth.wiki/device-flow) を利用できます。 -デバイスフローでは、デバイスがユーザーコードと検証用 URL を表示します。ユーザーは別のデバイス（スマートフォンやノートパソコンなど）でその URL にアクセスし、コードを入力して認証を完了します。デバイスは認可が完了するまで Logto のトークンエンドポイントをポーリングします。 +デバイスフローでは、デバイスがユーザーコードと検証用 URL を表示します。ユーザーは別のデバイス（スマートフォンやノート PC など）で URL にアクセスし、コードを入力して認証 (Authentication) を完了します。デバイスは Logto のトークンエンドポイントをポーリングし、認可が完了するのを待ちます。 :::note -デバイスフローを実装する前に、Logto コンソールでサードパーティアプリケーションに必要な [権限](/integrate-logto/third-party-applications/permission-management) を設定してください。有効化されていないスコープをリクエストした場合、サードパーティアプリはアクセスを拒否されます。 +デバイスフローを実装する前に、Logto コンソールでサードパーティアプリケーションに必要な [権限](/integrate-logto/third-party-applications/permission-management) を設定してください。有効化されていないスコープをリクエストしたサードパーティアプリはアクセスが拒否されます。 ::: -実装の詳細は [デバイスフロー クイックスタート](/quick-starts/device-flow) を参照してください。 +[デバイスフロー クイックスタート](/quick-starts/device-flow) で実装の詳細を確認できます。 ## OIDC サードパーティアプリケーションの同意画面 (Consent screen) \{#consent-screen-for-oidc-third-party-applications} -セキュリティ上の理由から、すべての OIDC サードパーティアプリケーションは Logto による認証 (Authentication) 後、ユーザー認可のために [同意画面](/end-user-flows/consent-screen) にリダイレクトされます。 +セキュリティ上の理由から、すべての OIDC サードパーティアプリケーションは Logto による認証 (Authentication) 後、[同意画面](/end-user-flows/consent-screen) へリダイレクトされ、ユーザーによる認可 (Authorization) が行われます。 -サードパーティがリクエストした [ユーザープロファイル権限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API リソーススコープ](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[組織権限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes)、および組織メンバーシップ情報はすべて同意画面に表示されます。 +サードパーティがリクエストした [ユーザープロファイル権限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API リソーススコープ](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[組織権限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes)、および組織メンバーシップ情報が同意画面に表示されます。 -これらのリクエストされた権限は、ユーザーが「認可」ボタンをクリックした後にのみサードパーティアプリケーションに付与されます。 +これらのリクエストされた権限は、ユーザーが「認可 (Authorization)」ボタンをクリックした後にのみサードパーティアプリケーションへ付与されます。
consent screen @@ -119,7 +127,7 @@ Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコ type: 'link', label: '権限管理', href: '/integrate-logto/third-party-applications/permission-management', - description: 'OIDC サードパーティアプリケーションの権限管理方法を学べます。', + description: 'OIDC サードパーティアプリケーションの権限管理方法を学びます。', customProps: { icon: , }, @@ -129,11 +137,21 @@ Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコ label: '同意画面のブランディング', href: '/integrate-logto/third-party-applications/consent-screen-branding', description: - '同意画面の外観をブランドイメージに合わせてカスタマイズし、一貫したユーザー体験を提供できます。', + '同意画面の外観をブランドイメージに合わせてカスタマイズし、一貫したユーザー体験を提供します。', customProps: { icon: , }, }, + { + type: 'link', + label: 'ダイナミックアプリ (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + 'クライアント ID メタデータドキュメントの URL をクライアント ID として利用し、OAuth クライアントが事前登録なしで接続できるようにします。', + customProps: { + icon: , + }, + }, ]} /> @@ -146,7 +164,7 @@ Logto は [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) プロトコ -Logto ではロールベースのアクセス制御 (RBAC) を使ってユーザー権限を管理しています。同意画面には、ユーザーにすでに割り当てられているスコープ（権限）のみが表示されます。ユーザーが持っていないスコープをサードパーティアプリがリクエストしても、それらは除外され、誤った同意を防ぎます。 +Logto ではロールベースのアクセス制御 (RBAC) を用いてユーザー権限を管理しています。同意画面には、ユーザーに既に割り当てられているスコープ（権限）のみが表示されます。サードパーティアプリがユーザーの持たないスコープをリクエストした場合、それらは除外され、無許可の同意を防ぎます。 管理方法： diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..401290ff4f3 --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,100 @@ +--- +description: クライアント ID メタデータドキュメントの URL を client ID として使用することで、OAuth クライアントが事前登録なしでテナントに接続できるようにします。 +sidebar_label: 動的アプリ (CIMD) +sidebar_position: 3 +--- + +# 動的アプリ (CIMD) + +動的アプリを利用すると、OAuth クライアントは事前登録なしでテナントに接続できます。Logto によって発行された client ID の代わりに、クライアントは自身の `client_id` として公開 HTTPS URL を使用します。この URL はクライアントを記述する JSON ドキュメント（[クライアント ID メタデータドキュメント (CIMD)](https://auth.wiki/client-id-metadata-document)）を提供します。Logto はこのドキュメントを取得し、クライアントを [サードパーティアプリケーション](/integrate-logto/third-party-applications) として扱います。 + +動的アプリは IETF ドラフト [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html) を実装しています。 + +## 動的アプリを使うタイミング \{#when-to-use-dynamic-app} + +事前登録はパートナーが分かっている場合に有効ですが、どのクライアントでも接続できる場合（[Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents) エコシステムでよくあります）には機能しません。例えば、ユーザーが自身の AI エージェントにサービスへの接続を依頼し、そのエージェントがこれまでテナントと通信したことがない場合です。 + +動的アプリでは、クライアントが所有する URL で自身のメタデータを公開し、その URL がアイデンティティとなります。テナント側で事前に何かを作成する必要はありません。 + +| | 登録済みサードパーティアプリ | 動的アプリ | +| ------------------------ | ---------------------------- | ------------------------------------------- | +| Client ID | Logto により発行 | クライアントが所有する HTTPS URL | +| 登録 | 必須 | 不要 | +| クライアントシークレット | サポートあり | サポートなし | +| 権限 | アプリごと | すべての動的クライアントで共有 | +| グラントタイプ | アプリタイプによる | `authorization_code` および `refresh_token` | + +動的クライアントは公開クライアントであるため、常に [PKCE](https://auth.wiki/pkce) を使用します。両方のモデルを同時に利用できます。信頼できるパートナーは、独自の権限を持つ登録済みアプリを引き続き持つことができます。 + +## 動的アプリを有効化する \{#enable-dynamic-app} + +1. コンソール > アプリケーション に移動し、**サードパーティアプリ** + タブを開きます。 +2. **アプリケーションの作成** をクリックし、**動的アプリ** カードを選択します。これはアプリケーションを作成するのではなく、テナントレベルの機能を有効化します。 +3. ダイアログで確認します。有効化されると、有効な公開 HTTPS クライアント ID URL を持つ任意の OAuth クライアントがテナントへの認可リクエストを開始できます。 +4. アプリケーションリストから動的アプリを開き、**権限** タブで権限を付与します。 + +動的アプリには編集可能な名前、リダイレクト URI、認証情報はありません。各クライアントが自身のメタデータドキュメントでそれらを提供します。 + +:::note +動的アプリは [OIDC プロバイダー SSRF 保護](/concepts/core-service/configuration#oidc-provider-ssrf-protection) が必要です。Logto がインターネットからメタデータドキュメントを取得するためです。これを無効化しているセルフホスト環境では動的アプリを有効化できません。 +::: + +### 権限を付与する \{#grant-permissions} + +**権限** タブでは、すべての動的クライアントで共有される最大権限を定義します。これは登録済みサードパーティアプリの [権限管理](/integrate-logto/third-party-applications/permission-management) と同様に動作し、**ユーザー** および **組織** セクションがあります。 + +付与されていないユーザー権限をリクエストするとエラーとなり、付与されていない API リソースや組織権限は無視されます。ユーザーは自身の [ロール](/authorization/role-based-access-control) を通じて持つ権限のみ同意します。 + +すべての動的クライアントがこのセットを共有するため、最小限に抑えてください。 + +## クライアント ID メタデータドキュメントを公開する \{#publish-a-client-id-metadata-document} + +Logto に接続するクライアントを構築する場合、メタデータドキュメントをホストし、その URL を `client_id` として使用します。URL は `https` スキームを使用し、フラグメント、ユーザー情報、ドットパスセグメントを含んではいけません。Logto はその URL に `GET` リクエストを送り、JSON オブジェクトを期待します。 + +例えば、Claude Code は `https://claude.ai/oauth/claude-code-client-metadata` を使用し、次の内容を提供します： + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +フィールド名は [OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591#section-2) と同じです。注意点： + +- `client_id` はドキュメントを提供する URL と完全に一致する必要があります。 +- 動的クライアントは公開クライアントです。ドキュメントに `client_secret` を含めてはいけません。また、`token_endpoint_auth_method` は共有シークレット方式であってはいけません。代わりに [PKCE](https://auth.wiki/pkce) を使用してください。 +- `client_uri`、`logo_uri`、`tos_uri`、`policy_uri` などのメタデータ URI は絶対 `https` URL でなければなりません。これは `redirect_uris` には適用されないため、上記例のようにネイティブクライアントはループバックアドレスも利用できます。 +- `redirect_uris` は完全一致でマッチしますが、ループバックアドレスの場合は任意のポートでマッチします。[ワイルドカードパターン](/integrate-logto/application-data-structure#wildcard-patterns) もサポートされています。 +- `scope`、`grant_types`、`response_types` は Logto によって決定されます。ドキュメントで宣言されていても値は無視されます。動的クライアントは認可コードフローとリフレッシュトークンのみ利用できます。 + +Logto はドキュメントを最大 24 時間キャッシュし、レスポンスの `Cache-Control` および `Expires` ヘッダーに従います。ドキュメントの更新頻度に応じて設定してください。 + +## 同意画面 (Consent screen) \{#consent-screen} + +動的クライアントはサードパーティアプリケーションであるため、[同意画面](/end-user-flows/consent-screen) が常に表示されます。 + +同意画面にはクライアントが未登録である旨の注意書きも表示されます。クライアント名やロゴはメタデータドキュメントから取得されるため、任意のブランドを模倣することが可能です。クライアント ID URL のホスト名も表示されます。これはクライアントが偽装できない唯一の部分です。 + +## 認可の管理 \{#manage-authorizations} + +動的クライアントに付与された認可は通常のサードパーティ [グラント](/sessions/grants-management) です。ユーザーはアカウント設定で確認・取り消しができ、管理者は Management API を通じて管理できます。クライアントの識別にはクライアント ID URL が使われます。 + +動的アプリを無効化すると新規認可リクエストは停止しますが、既存のグラントは保持されます。グラントを取り消すと、クライアントは再度ユーザー認可を取得する必要がありますが、既に発行されたアクセス トークンは有効期限まで利用可能です。 + +## 制限事項 \{#limitations} + +- PKCE を用いた認可コードフローとリフレッシュトークンのみサポートされます。クライアントクレデンシャル、デバイスフロー、トークンエクスチェンジは利用できません。 +- 権限やブランディングはクライアントごとに設定できません。 +- [アプリレベルのアクセス制御](/authorization/app-level-access-control) は動的クライアントには適用されません（アプリケーションレコードが存在しないため）。 + +## 関連リソース \{#related-resources} + +サードパーティアプリ (OAuth / OIDC) + + MCP サーバーへのサードパーティ AI エージェントアクセスの有効化 + diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index 84ea98454c3..48b60d3c30a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -2,70 +2,72 @@ sidebar_position: 2 --- -# ユーザーの認可されたアプリ (グラント) を管理する +# ユーザー認可済みアプリ（グラント）の管理 -アプリのグラントは、特定のクライアントアプリケーションに対するユーザーの認可状態を表します。 +アプリグラントは、特定のクライアントアプリケーションに対するユーザーの認可 (Authorization) 状態を表します。 -ユーザーや管理者が認可されたアプリを確認し、全体の Logto セッションを取り消すことなくアプリのアクセスを取り消す必要がある場合に、グラント管理を使用します。 +ユーザーや管理者が認可済みアプリを確認し、Logto セッション全体を無効化せずにアプリへのアクセスを取り消す必要がある場合に、グラント管理を利用します。 -グラントが取り消されると、それらのグラントに対して以前に発行された不透明トークン (Opaque token) とリフレッシュ トークン (Refresh token) は無効になります。 +グラントが取り消されると、それらのグラントに対して発行された不透明トークン (Opaque token) のアクセス トークン (Access token) およびリフレッシュ トークン (Refresh token) は無効化されます。JWT アクセス トークン (Access token) はステートレスなため、既に発行されたものは有効期限まで有効です。 -## 適切なパスを選択する \{#choose-the-right-path} +## 適切な方法を選択する \{#choose-the-right-path} -| シナリオ | 推奨パス | -| -------------------------------------------------------------- | -------------- | -| サインインしたユーザーが自分のアプリの認可を管理する | Account API | -| 管理者やサポートチームがターゲットユーザーのグラントを管理する | Management API | -| オペレーターが UI でサードパーティアプリの認可を管理する | Admin Console | +| シナリオ | 推奨される方法 | +| ------------------------------------------------------------------------- | -------------- | +| サインイン中のユーザー自身がアプリ認可 (Authorization) を管理する | Account API | +| 管理者やサポートチームが特定ユーザーのグラントを管理する | Management API | +| オペレーターが UI でサードパーティアプリの認可 (Authorization) を管理する | 管理コンソール | -## 直接グラント管理 API \{#direct-grant-management-apis} +## 直接的なグラント管理 API \{#direct-grant-management-apis} -### Account API (セルフサービス) \{#account-api-self-service} +### Account API（セルフサービス） \{#account-api-self-service} -エンドユーザーのアカウント設定ページで Account API を使用します： +エンドユーザーのアカウント設定ページで Account API を利用します： - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` -- 参照: [ユーザーの認可されたアプリ (グラント) を管理する](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) +- 参考: [Account API によるユーザー認可済みアプリ（グラント）の管理](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) -### Management API (管理ツール) \{#management-api-admin-tools} +### Management API（管理ツール） \{#management-api-admin-tools} -管理ツールやサポートワークフローで Management API を使用します： +管理ツールやサポート業務で Management API を利用します： - `GET /api/users/{userId}/grants` - `DELETE /api/users/{userId}/grants/{grantId}` -- 参照: [ユーザーの認可されたアプリ (グラント) を管理する](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) +- 参考: [Management API によるユーザー認可済みアプリ（グラント）の管理](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) -### アプリタイプでグラントリストをフィルタリングする \{#filter-grant-list-by-app-type} +### アプリ種別でグラント一覧をフィルタリング \{#filter-grant-list-by-app-type} -グラントリストのエンドポイントは、オプションのクエリパラメーター `appType` をサポートしています： +グラント一覧取得エンドポイントは、オプションのクエリパラメーター `appType` をサポートしています： -- `appType=firstParty`: ファーストパーティアプリのグラントのみをリストします。 -- `appType=thirdParty`: サードパーティアプリのグラントのみをリストします。 -- `appType` を省略: すべてのアクティブなグラントを返します。 +- `appType=firstParty`：ファーストパーティアプリのグラントのみを一覧表示。 +- `appType=thirdParty`：サードパーティアプリのグラントのみを一覧表示。 +- `appType` を省略：すべての有効なグラントを返します。 -## コンソールでサードパーティアプリの認可を管理する \{#manage-third-party-app-authorizations-in-console} +[ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps) クライアントはサードパーティアプリケーションであるため、そのグラントは `appType=thirdParty` で返されます。クライアント ID の URL がアプリケーション ID として使用されます。 -Logto コンソールでは、ユーザー詳細ページを使用して認可されたサードパーティアプリを表示および取り消すことができます。 +## コンソールでサードパーティアプリの認可 (Authorization) を管理 \{#manage-third-party-app-authorizations-in-console} -- 参照: [ユーザーの認可されたサードパーティアプリを管理する](/user-management/manage-users#manage-user-authorized-third-party-apps) +Logto コンソールでは、ユーザー詳細ページから認可済みサードパーティアプリの確認および取り消しが可能です。 -## セッションを取り消す際にグラントを取り消す \{#revoke-grants-when-revoking-a-session} +- 参考: [ユーザー認可済みサードパーティアプリの管理](/user-management/manage-users#manage-user-authorized-third-party-apps) -`DELETE /api/my-account/sessions/{sessionId}` を使用してセッションを取り消す際に、オプションのクエリパラメーター `revokeGrantsTarget` を使用してグラントの取り消し範囲を制御します： +## セッション取り消し時にグラントも取り消す \{#revoke-grants-when-revoking-a-session} -- `all`: セッションに関連付けられたすべてのアプリのグラントを取り消します。 -- `firstParty`: ファーストパーティアプリのグラントのみを取り消します。 +`DELETE /api/my-account/sessions/{sessionId}` でセッションを取り消す際、オプションのクエリパラメーター `revokeGrantsTarget` でグラントの取り消し範囲を制御できます： -セッションレベルの動作とエンドポイントのコンテキストについては、[ユーザーセッションを管理する](/sessions/manage-user-sessions) と [サインアウト](/end-user-flows/sign-out) を参照してください。 +- `all`：セッションに関連付けられたすべてのアプリのグラントを取り消す。 +- `firstParty`：ファーストパーティアプリのグラントのみを取り消す。 + +セッションレベルの挙動やエンドポイントの詳細は、[ユーザーセッションの管理](/sessions/manage-user-sessions) および [サインアウト](/end-user-flows/sign-out) を参照してください。 ## 関連リソース \{#related-resources} セッション -ユーザーセッションを管理する +ユーザーセッションの管理 - Account API によるアカウント設定: ユーザーの認可されたアプリ (グラント) を管理する + Account API によるアカウント設定：ユーザー認可済みアプリ（グラント）の管理 - Management API によるアカウント設定: ユーザーの認可されたアプリ (グラント) を管理する + Management API によるアカウント設定：ユーザー認可済みアプリ（グラント）の管理 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index 220217fed97..17e3516851a 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/ja/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -2,19 +2,25 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- ## Logto でサードパーティ AI エージェントを設定する \{#configure-third-party-ai-agent-in-logto} -サードパーティ AI エージェントが {props.serviceName ?? 'サービス'} にアクセスできるようにするには、Logto で **サードパーティアプリ** を設定する必要があります。このアプリは AI エージェントを表し、認証 (Authentication) と認可 (Authorization) に必要な認証情報を取得するために使用されます。 +サードパーティ AI エージェントが {props.serviceName ?? 'サービス'} にアクセスできるようにするには、Logto で **サードパーティアプリ** をセットアップする必要があります。このアプリは AI エージェントを表し、認証 (Authentication) と認可 (Authorization) に必要な認証情報を取得するために使用されます。 :::info[サードパーティアプリとは？] -**サードパーティアプリ** とは、外部開発者（リソース所有者ではない）が作成したアプリケーションで、保護されたリソースにアクセスするためにユーザーの同意が必要です。ファーストパーティアプリ（自社アプリケーション）とは異なり、サードパーティアプリはユーザーのデータにアクセスする前に、特定の権限を承認する同意画面が表示されます。これにより、ユーザーは外部サービスと共有するデータをコントロールできます。 +**サードパーティアプリ** とは、外部開発者（リソース所有者ではない）が作成し、保護されたリソースへアクセスするためにユーザーの同意が必要なアプリケーションです。ファーストパーティアプリ（自社アプリ）とは異なり、サードパーティアプリはユーザーのデータへアクセスする前に、特定の権限を承認する同意画面が表示されます。これにより、ユーザーは外部サービスと共有するデータをコントロールできます。 -詳細は [サードパーティアプリケーション](/integrate-logto/third-party-applications) を参照してください。 +詳しくは [サードパーティアプリケーション](/integrate-logto/third-party-applications) を参照してください。 ::: +AI エージェントをオンボードする方法は 3 つあります： + +- [コンソールで手動作成](#manually-create-a-third-party-app-in-logto)：テストや既知の少数のエージェント向け。 +- [Management API で登録サービスを構築](#allow-developers-to-create-third-party-apps-in-logto)：認証情報の発行をコントロールしたい場合。 +- [ダイナミックアプリを有効化](#let-any-ai-agent-connect-without-pre-registration)：どのエージェントも事前登録なしで接続できるようにしたい場合。 + ### 開発者が Logto でサードパーティアプリを作成できるようにする \{#allow-developers-to-create-third-party-apps-in-logto} -マーケットプレイスを構築したり、開発者が Logto でサードパーティアプリを作成できるようにしたい場合は、[Logto Management API](/integrate-logto/interact-with-management-api) を活用してプログラムでサードパーティアプリを作成できます。これにより、開発者は自分のアプリケーションを登録し、認証 (Authentication) に必要な認証情報を取得できます。 +マーケットプレイスを構築したり、開発者が Logto でサードパーティアプリを作成できるようにしたい場合は、[Logto Management API](/integrate-logto/interact-with-management-api) を活用してプログラム的にサードパーティアプリを作成できます。これにより、開発者は自分のアプリケーションを登録し、認証 (Authentication) に必要な認証情報を取得できます。 -クライアント登録プロセスを処理する独自のサービスをホストする必要があります。このサービスは Logto Management API と連携し、開発者に代わってサードパーティアプリを作成します。 +クライアント登録プロセスを処理する独自のサービスをホストする必要があります。このサービスは Logto Management API と連携し、開発者の代わりにサードパーティアプリを作成します。 ```mermaid sequenceDiagram @@ -29,19 +35,36 @@ sequenceDiagram または、Logto コンソールで手動でサードパーティアプリを作成し、プロセスに慣れることもできます。 -### Logto でサードパーティアプリを手動で作成する \{#manually-create-a-third-party-app-in-logto} +### 事前登録なしで任意の AI エージェントを接続可能にする \{#let-any-ai-agent-connect-without-pre-registration} + +オープンな MCP エコシステムでは、事前にエージェントを把握していないことが一般的です。[ダイナミックアプリ](/integrate-logto/third-party-applications/dynamic-apps) を利用すると、登録ステップが不要になります。エージェントは自身のクライアントメタデータドキュメントを公開する HTTPS URL を `client_id` として使用し、認可 (Authorization) リクエストが到着した際に Logto がそれを解決します。 + +```mermaid +sequenceDiagram + participant Agent as AI エージェント（MCP クライアント） + participant Logto + participant Metadata as エージェントのメタデータドキュメント URL + Agent->>Logto: クライアント ID URL で認可リクエスト + Logto->>Metadata: クライアント ID メタデータドキュメント取得 + Metadata->>Logto: クライアント名、ロゴ、リダイレクト URI 等 + Logto->>Agent: 同意画面、その後認可コード +``` + +ダイナミックアプリに付与された権限を通じて、エージェントがリクエストできる内容を引き続きコントロールできます。また、すべての認可 (Authorization) はユーザーの同意画面を経由します。 + +### Logto でサードパーティアプリを手動作成する \{#manually-create-a-third-party-app-in-logto} -テストやアドホックな統合のために、Logto コンソールでサードパーティアプリを手動で作成できます。これは、クライアント登録フローを実装せずに統合をすぐにテストしたい場合に便利です。 +テストやアドホックな連携のために、Logto コンソールでサードパーティアプリを手動で作成できます。これは、フルのクライアント登録フローを実装せずに素早く連携をテストしたい場合に便利です。 1. Logto コンソールにサインインします。 -2. **アプリケーション**→ **アプリケーションの作成** → +2. **アプリケーション**→ **アプリケーションを作成** → **サードパーティアプリ** -> **OIDC** を選択します。 -3. アプリ名やその他の必須項目を入力し、**アプリケーションの作成** をクリックします。 +3. アプリ名など必要事項を入力し、**アプリケーションを作成** をクリックします。 4. **権限** タブをクリックし、**ユーザー** セクションで「追加」をクリックします。 5. 開いたダイアログで -> **ユーザーデータ** -> **`profile`**、**`email`** 権限を選択し、**保存** をクリックします。 -6. サードパーティアプリで、`openid profile email` 権限（スコープ）をリクエストするようにスコープを設定します。 +6. サードパーティアプリ側で、`openid profile email` 権限（スコープ）をリクエストするようにスコープを設定します。 - **注意**：`openid` は OIDC で必須、`profile` と `email` は前のステップで追加した権限です。 + **注意**：`openid` は OIDC に必須であり、`profile` と `email` は前のステップで追加した権限です。 7. サードパーティアプリの **リダイレクト URI** を適切に設定します。Logto 側のリダイレクト URI も忘れずに更新してください。 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx index 33df5c524b2..b2572fcd1e7 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx @@ -10,25 +10,25 @@ sidebar_position: 7 앱 수준 접근 제어를 사용해야 하는 경우: -- 내부 앱을 직원 또는 관리자에게만 제공하고 싶을 때 +- 내부 앱을 직원이나 관리자에게만 제공하고 싶을 때 - [보호된 앱](/integrate-logto/protected-app)을 선택된 사용자 그룹으로 제한하고 싶을 때 -- 특정 고객 또는 파트너만 [서드파티 OIDC / OAuth 애플리케이션](/integrate-logto/third-party-applications)에 접근할 수 있도록 허용하고 싶을 때 -- 새로운 애플리케이션을 전체 공개 전에 파일럿 그룹에 먼저 배포하고 싶을 때 +- 특정 고객이나 파트너만 [서드파티 OIDC / OAuth 애플리케이션](/integrate-logto/third-party-applications)에 접근할 수 있도록 허용하고 싶을 때 +- 새로운 애플리케이션을 모두에게 공개하기 전에 파일럿 그룹에 먼저 배포하고 싶을 때 ## 작동 방식 \{#how-it-works} -앱 수준 접근 제어가 비활성화된 경우, Logto 테넌트에 등록된 모든 사용자가 해당 애플리케이션에 로그인할 수 있습니다. +앱 수준 접근 제어가 비활성화되어 있으면, Logto 테넌트에 등록된 모든 사용자가 해당 애플리케이션에 로그인할 수 있습니다. -활성화된 경우, 사용자는 최소 하나의 구성된 규칙과 일치해야만 애플리케이션에 접근할 수 있습니다. 사용자가 어떤 규칙과도 일치하지 않으면, Logto는 로그인 시도를 거부하고 애플리케이션이 토큰을 받기 전에 접근 거부 페이지를 표시합니다. +활성화되어 있으면, 사용자는 최소 하나의 구성된 규칙과 일치해야만 애플리케이션에 접근할 수 있습니다. 사용자가 어떤 규칙과도 일치하지 않으면, Logto는 로그인 시도를 거부하고 애플리케이션이 토큰을 받기 전에 접근 거부 페이지를 표시합니다. 앱 수준 접근 제어는 인가 (Authorization) 플로우 및 토큰 갱신 시점에 평가됩니다. 즉: - 접근 권한이 없는 사용자는 애플리케이션에 로그인 완료 전에 차단됩니다. -- 기존 앱 권한은 리프레시 토큰을 사용하여 새 토큰을 요청할 때 다시 확인됩니다. -- 규칙을 업데이트하면 사용자의 글로벌 Logto 세션을 변경하지 않고, 향후 인가 및 토큰 갱신 검사에 영향을 줍니다. +- 기존 앱 권한은 리프레시 토큰을 사용해 새 토큰을 요청할 때 다시 확인됩니다. +- 규칙을 업데이트하면 사용자의 글로벌 Logto 세션을 변경하지 않고 향후 인가 및 토큰 갱신 검사에 영향을 줍니다. :::note -앱 수준 접근 제어는 [역할 기반 접근 제어 (RBAC)](/authorization/role-based-access-control)와 별개입니다. RBAC는 인증 (Authentication) 이후 사용자가 무엇을 할 수 있는지 액세스 토큰의 권한(스코프)으로 제어합니다. 앱 수준 접근 제어는 사용자가 특정 애플리케이션에 접근할 수 있는지 자체를 제어합니다. +앱 수준 접근 제어는 [역할 기반 접근 제어 (RBAC)](/authorization/role-based-access-control)와 별개입니다. RBAC는 액세스 토큰의 권한(스코프)을 발급하여 인증 이후 사용자가 무엇을 할 수 있는지 제어합니다. 앱 수준 접근 제어는 사용자가 특정 애플리케이션에 접근할 수 있는지 자체를 제어합니다. ::: ## 규칙 유형 \{#rule-types} @@ -38,20 +38,20 @@ sidebar_position: 7 | 규칙 유형 | 허용 내용 | | --------------- | --------------------------------------------------------------------------------- | | **사용자** | 특정 사용자가 애플리케이션에 접근할 수 있습니다. | -| **사용자 역할** | 선택된 사용자 역할에 할당된 사용자가 애플리케이션에 접근할 수 있습니다. | -| **조직** | 선택된 조직의 현재 및 미래 모든 구성원이 애플리케이션에 접근할 수 있습니다. | -| **조직 역할** | 선택된 조직의 선택된 조직 역할을 가진 구성원이 애플리케이션에 접근할 수 있습니다. | +| **사용자 역할** | 선택한 사용자 역할이 할당된 사용자가 애플리케이션에 접근할 수 있습니다. | +| **조직** | 선택한 조직의 현재 및 미래 모든 구성원이 애플리케이션에 접근할 수 있습니다. | +| **조직 역할** | 선택한 조직의 선택한 조직 역할을 가진 구성원이 애플리케이션에 접근할 수 있습니다. | 규칙은 누적 적용됩니다. 사용자는 하나의 규칙만 일치해도 애플리케이션에 접근할 수 있습니다. -예를 들어, 한 애플리케이션에 "지원팀" 사용자 역할 규칙과 "BigTree - Admin" 조직 역할 규칙이 모두 있다면, 사용자가 지원팀 역할에 할당되어 있거나 BigTree 조직에서 Admin 역할을 가지고 있다면 애플리케이션에 접근할 수 있습니다. +예를 들어, 한 애플리케이션에 "지원팀" 사용자 역할 규칙과 "BigTree - Admin" 조직 역할 규칙이 모두 있다면, 사용자가 지원팀 역할을 할당받았거나 BigTree 조직의 Admin이라면 애플리케이션에 접근할 수 있습니다. ## 앱 수준 접근 제어 구성하기 \{#configure-app-level-access-control} 1. 콘솔 > 애플리케이션으로 이동하세요. -2. 접근을 제한할 애플리케이션을 엽니다. +2. 제한하려는 애플리케이션을 엽니다. 3. **규칙** 탭으로 이동합니다. -4. **사용자 지정 허용 규칙**에서 **규칙 추가**를 클릭합니다. +4. **사용자 지정 허용 규칙**에서 **규칙 추가**를 클릭하세요. 5. 규칙 유형을 선택하세요: - **사용자** - **사용자 역할** @@ -62,7 +62,7 @@ sidebar_position: 7 8. **변경 사항 저장**을 클릭하세요. :::important -접근 제어를 활성화하기 전에 최소 하나의 허용 규칙을 구성해야 합니다. 이는 실수로 아무도 애플리케이션에 접근할 수 없게 되는 것을 방지합니다. +접근 제어를 활성화하기 전에 최소 하나의 허용 규칙을 구성해야 합니다. 이는 접근 제어를 실수로 활성화하여 아무도 애플리케이션에 접근하지 못하는 상황을 방지합니다. ::: ## 규칙 수정 또는 제거하기 \{#edit-or-remove-rules} @@ -73,18 +73,18 @@ sidebar_position: 7 - 규칙을 제거하려면 해당 규칙 행의 삭제 버튼을 클릭하고 작업을 확인하세요. - 규칙을 추가하거나 제거한 후 **변경 사항 저장**을 클릭하여 업데이트를 적용하세요. -접근 제어가 활성화된 경우, Logto는 최소 하나의 규칙이 남아 있어야 합니다. 모든 규칙을 제거하려면 먼저 **접근 제어 활성화**를 끄고 변경 사항을 저장하세요. +접근 제어가 활성화되어 있으면, Logto는 최소 하나의 규칙이 남아 있어야 합니다. 모든 규칙을 제거하려면 먼저 **접근 제어 활성화**를 끄고 변경 사항을 저장하세요. ## 규칙 변경이 사용자에게 미치는 영향 \{#how-rule-changes-affect-users} -앱 수준 접근 제어는 사용자의 글로벌 Logto 세션을 종료하지 않습니다. 사용자는 여전히 Logto 및 다른 애플리케이션에 로그인된 상태일 수 있습니다. +앱 수준 접근 제어는 사용자의 글로벌 Logto 세션을 종료하지 않습니다. 사용자는 여전히 Logto 및 다른 애플리케이션에 로그인되어 있을 수 있습니다. 제한되는 애플리케이션의 경우: -- 더 이상 어떤 허용 규칙과도 일치하지 않는 사용자는 다음에 애플리케이션의 인가 (Authorization) 플로우를 진행할 때 차단됩니다. -- 사용자가 이미 앱 관련 권한을 가지고 있다면, 애플리케이션이 리프레시 토큰을 사용하여 새 토큰을 요청할 때 Logto가 규칙을 다시 확인합니다. 사용자가 더 이상 접근 권한이 없으면 Logto는 토큰 요청을 거부합니다. +- 더 이상 어떤 허용 규칙과도 일치하지 않는 사용자는 다음에 해당 애플리케이션의 인가 (Authorization) 플로우를 거칠 때 차단됩니다. +- 사용자가 이미 앱 관련 권한을 가지고 있다면, 애플리케이션이 리프레시 토큰을 사용해 새 토큰을 요청할 때 Logto가 규칙을 다시 확인합니다. 사용자가 더 이상 접근 권한이 없으면 Logto는 토큰 요청을 거부합니다. -이 방식은 접근 결정을 애플리케이션에만 연결하면서, 관련 없는 애플리케이션에는 불필요한 영향을 주지 않습니다. +이렇게 하면 접근 결정이 애플리케이션에만 연결되고, 관련 없는 애플리케이션에는 불필요한 중단이 발생하지 않습니다. ## 서드파티 앱 권한과의 관계 \{#relationship-with-third-party-app-permissions} @@ -95,16 +95,20 @@ sidebar_position: 7 둘 다 구성된 경우, 사용자는 서드파티 애플리케이션을 인가하기 전에 앱 수준 접근 제어를 통과해야 합니다. +:::note +앱 수준 접근 제어는 등록된 애플리케이션에만 적용됩니다. [동적 앱](/integrate-logto/third-party-applications/dynamic-apps) 클라이언트는 애플리케이션 레코드가 없으므로 이 방식으로 제한할 수 없습니다. 이들의 접근은 동적 앱에 부여한 권한과 사용자 동의에 의해 제한됩니다. +::: + ## 보호된 앱과의 관계 \{#relationship-with-protected-app} -[보호된 앱](/integrate-logto/protected-app)의 경우, 앱 수준 접근 제어는 Logto 인증 (Authentication) 레이어를 통과하여 보호된 오리진 서버에 도달할 수 있는 사용자를 제한합니다. +[보호된 앱](/integrate-logto/protected-app)의 경우, 앱 수준 접근 제어는 Logto 인증 (Authentication) 레이어를 통과하여 보호된 원본 서버에 도달할 수 있는 사용자를 제한합니다. -보호된 앱의 인증 (Authentication) 규칙은 어떤 경로가 인증 (Authentication)을 요구하는지 결정합니다. 앱 수준 접근 제어는 인증된 Logto 사용자 중에서 보호된 앱 애플리케이션에 접근할 수 있는 사용자를 결정합니다. +보호된 앱의 인증 규칙은 어떤 경로에 인증이 필요한지 결정합니다. 앱 수준 접근 제어는 인증된 Logto 사용자 중에서 보호된 앱 애플리케이션에 접근할 수 있는 사용자를 결정합니다. ## 모범 사례 \{#best-practices} - 가능하다면 사용자 역할 또는 조직 역할 규칙부터 시작하세요. 개별 사용자 목록보다 유지 관리가 쉽습니다. - 조직의 모든 구성원이 앱에 접근해야 한다면 조직 규칙을 사용하세요. - 조직 내 특정 구성원만 앱에 접근해야 한다면 조직 역할 규칙을 사용하세요. -- 사용자의 역할 변경, 조직 가입 또는 탈퇴 시 접근 규칙을 검토하세요. -- RBAC 권한과 앱 수준 접근 제어를 명확히 구분하세요: 앱 수준 접근 제어는 "이 사용자가 이 앱에 접근할 수 있는가?"에 답하고, RBAC는 "이 사용자가 API 또는 조직 기능에 접근한 후 무엇을 할 수 있는가?"에 답합니다. +- 사용자가 역할을 변경하거나 조직에 가입/탈퇴할 때 접근 규칙을 검토하세요. +- RBAC 권한과 앱 수준 접근 제어를 명확히 분리해서 생각하세요: 앱 수준 접근 제어는 "이 사용자가 이 앱에 접근할 수 있는가?"에 답하고, RBAC는 "이 사용자가 API 또는 조직 기능에 접근한 후 무엇을 할 수 있는가?"에 답합니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/ko/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index 482f0168cfd..9de3744e5d8 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/ko/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -19,43 +19,45 @@ Logto는 환경 변수를 다음 순서로 처리합니다: 기본값에서 `protocol`은 HTTPS 설정에 따라 `http` 또는 `https`가 됩니다. -| Key | Default Value | Type | Description | -| -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| NODE_ENV | `undefined` | 'production' | 'test' | undefined | Logto가 실행되는 환경 유형입니다. | -| PORT | `3001` | `number` | Logto가 수신 대기하는 로컬 포트입니다. | -| ADMIN_PORT | `3002` | `number` | Logto 관리 콘솔이 수신 대기하는 로컬 포트입니다. | -| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | 관리 콘솔 포트를 비활성화하려면 `1` 또는 `true`로 설정하세요. `ADMIN_ENDPOINT`가 설정되지 않은 경우, 관리 콘솔이 완전히 비활성화됩니다. | -| DB_URL | N/A | `string` | Logto 데이터베이스용 [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6)입니다. | -| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout`(밀리초 단위)입니다. 숫자 문자열(예: `5000`)로 설정하거나, `DISABLE_TIMEOUT`로 시작 파라미터를 생략할 수 있습니다(PgBouncer/RDS Proxy에 권장). 미설정 또는 잘못된 경우, 클라이언트 기본값은 60000ms입니다. | -| HTTPS_CERT_PATH | `undefined` | string | undefined | 자세한 내용은 [HTTPS 활성화](#enabling-https)를 참조하세요. | -| HTTPS_KEY_PATH | `undefined` | string | undefined | 위와 동일. | -| TRUST_PROXY_HEADER | `false` | `boolean` | 위와 동일. | -| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | 온라인 테스트 또는 프로덕션을 위해 커스텀 도메인으로 URL을 지정할 수 있습니다. 이 값은 [OIDC 발급자 식별자](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier)에도 영향을 줍니다. | -| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | 프로덕션을 위해 커스텀 도메인으로 URL을 지정할 수 있습니다(예: `ADMIN_ENDPOINT=https://admin.domain.com`). 이 값은 관리 콘솔 리디렉션 URI에도 영향을 줍니다. | -| CASE_SENSITIVE_USERNAME | `true` | `boolean` | 사용자 이름의 대소문자 구분 여부를 지정합니다. 이 값을 변경할 때는 주의하세요. 기존 데이터베이스 데이터는 자동으로 조정되지 않으므로 수동으로 관리해야 합니다. | -| SECRET_VAULT_KEK | `undefined` | `string` | [Secret Vault](/secret-vault)에서 데이터 암호화 키(DEK)를 암호화하는 데 사용되는 키 암호화 키(KEK)입니다. Secret Vault가 제대로 작동하려면 필수입니다. base64 인코딩된 문자열이어야 하며, AES-256(32바이트)을 권장합니다. 예시: `crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | 단계적 OIDC 개인 키 교체를 위한 유예 기간(초)입니다. 양수로 설정하면, 새 개인 키가 먼저 `Next`로 생성되고 유예 기간 후에만 유효해집니다. | -| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | 셀프 호스팅 전용. 신뢰할 수 있는 OIDC 릴라잉 파티 엔드포인트가 프라이빗 네트워크 주소를 해석해야 할 때만 `true`로 설정하세요. 자세한 내용은 [OIDC 공급자 SSRF 보호](#oidc-provider-ssrf-protection)를 참조하세요. | +| Key | Default Value | Type | Description | +| -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| NODE_ENV | `undefined` | 'production' | 'test' | undefined | Logto가 실행되는 환경 유형입니다. | +| PORT | `3001` | `number` | Logto가 수신 대기하는 로컬 포트입니다. | +| ADMIN_PORT | `3002` | `number` | Logto 관리 콘솔이 수신 대기하는 로컬 포트입니다. | +| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | 관리 콘솔 포트를 비활성화하려면 `1` 또는 `true`로 설정하세요. `ADMIN_ENDPOINT`가 설정되지 않은 경우, 관리 콘솔이 완전히 비활성화됩니다. | +| DB_URL | N/A | `string` | Logto 데이터베이스를 위한 [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6)입니다. | +| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout` (밀리초 단위). 숫자 문자열(예: `5000`)로 설정하거나, `DISABLE_TIMEOUT`으로 시작 매개변수를 생략할 수 있습니다(PgBouncer/RDS Proxy에 권장). 미설정 또는 잘못된 경우, 클라이언트 기본값은 60000ms입니다. | +| HTTPS_CERT_PATH | `undefined` | string | undefined | 자세한 내용은 [HTTPS 활성화](#enabling-https)를 참조하세요. | +| HTTPS_KEY_PATH | `undefined` | string | undefined | 위와 동일. | +| TRUST_PROXY_HEADER | `false` | `boolean` | 위와 동일. | +| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | 온라인 테스트 또는 프로덕션을 위해 커스텀 도메인으로 URL을 지정할 수 있습니다. 이는 [OIDC 발급자 식별자](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) 값에도 영향을 줍니다. | +| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | 프로덕션을 위해 커스텀 도메인으로 URL을 지정할 수 있습니다(예: `ADMIN_ENDPOINT=https://admin.domain.com`). 이는 관리 콘솔 리디렉션 URI 값에도 영향을 줍니다. | +| CASE_SENSITIVE_USERNAME | `true` | `boolean` | 사용자 이름의 대소문자 구분 여부를 지정합니다. 이 값을 변경할 때 주의하세요. 기존 데이터베이스 데이터는 자동으로 조정되지 않으므로 수동 관리가 필요합니다. | +| SECRET_VAULT_KEK | `undefined` | `string` | [Secret Vault](/secret-vault)에서 데이터 암호화 키(DEK)를 암호화하는 데 사용되는 키 암호화 키(KEK)입니다. Secret Vault가 제대로 작동하려면 필수입니다. base64로 인코딩된 문자열이어야 하며, AES-256(32바이트)을 권장합니다. 예시: `crypto.randomBytes(32).toString('base64')` | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | 단계적 OIDC 개인 키 교체를 위한 유예 기간(초)입니다. 양수로 설정하면 새 개인 키가 먼저 `Next`로 생성되고, 유예 기간 후에만 적용됩니다. | +| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | 셀프 호스팅 전용. 신뢰할 수 있는 OIDC 릴라잉 파티 엔드포인트가 프라이빗 네트워크 주소를 해석해야 할 때만 `true`로 설정하세요. 자세한 내용은 [OIDC 공급자 SSRF 보호](#oidc-provider-ssrf-protection)를 참조하세요. | ### OIDC 공급자 SSRF 보호 {#oidc-provider-ssrf-protection} -Logto는 기본적으로 OIDC 공급자의 아웃바운드 요청에 대해 서버 측 요청 위조(SSRF)로부터 보호합니다. 루프백 및 프라이빗 네트워크 주소 등 특수 용도 주소로의 요청은 차단됩니다. 이 보호는 릴라잉 파티 엔드포인트(예: 백채널 로그아웃 URI, `jwks_uri`, `sector_identifier_uri`)에 적용됩니다. +Logto는 기본적으로 OIDC 공급자의 아웃바운드 요청에 대해 서버 측 요청 위조(SSRF)로부터 보호합니다. 루프백 및 프라이빗 네트워크 주소 등 특수 용도 주소로의 요청은 차단됩니다. 이 보호는 백채널 로그아웃 URI, `jwks_uri`, `sector_identifier_uri` 등 릴라잉 파티 엔드포인트와, [동적 앱](/integrate-logto/third-party-applications/dynamic-apps)을 위한 클라이언트 ID 메타데이터 문서에도 적용됩니다. -셀프 호스팅 배포에서 신뢰할 수 있는 릴라잉 파티 엔드포인트가 프라이빗 네트워크에 있어야 하는 경우, `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true`로 설정하고 모든 Logto 인스턴스를 재시작하세요. +셀프 호스팅 배포에서 신뢰할 수 있는 릴라잉 파티 엔드포인트에 프라이빗 네트워크로 접근해야 하는 경우, `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true`로 설정하고 모든 Logto 인스턴스를 재시작하세요. :::caution 이 설정은 모든 OIDC 공급자 아웃바운드 요청에 대한 SSRF 보호를 비활성화합니다(특정 엔드포인트만이 아님). 구성된 모든 릴라잉 파티 엔드포인트가 신뢰할 수 있고, 네트워크 제어로 민감한 내부 서비스 접근이 차단되는 경우에만 비활성화하세요. +[동적 앱](/integrate-logto/third-party-applications/dynamic-apps)은 이 보호가 꺼져 있을 때 활성화할 수 없습니다. 클라이언트가 제공한 URL에서 메타데이터 문서를 가져오기 때문입니다. + ::: ### HTTPS 활성화 {#enabling-https} #### Node 사용 시 {#using-node} -Node는 HTTPS를 기본적으로 지원합니다. HTTPS를 활성화하려면 `HTTPS_CERT_PATH`와 `HTTPS_KEY_PATH` **둘 다** 제공해야 합니다. +Node는 HTTPS를 기본적으로 지원합니다. `HTTPS_CERT_PATH`와 `HTTPS_KEY_PATH` **둘 다** 제공하면 Node를 통해 HTTPS를 활성화할 수 있습니다. -`HTTPS_CERT_PATH`는 HTTPS 인증서 경로, `HTTPS_KEY_PATH`는 HTTPS 키 경로를 의미합니다. +`HTTPS_CERT_PATH`는 HTTPS 인증서의 경로를, `HTTPS_KEY_PATH`는 HTTPS 키의 경로를 의미합니다. #### HTTPS 프록시 사용 시 {#using-a-https-proxy} @@ -63,11 +65,11 @@ Node는 HTTPS를 기본적으로 지원합니다. HTTPS를 활성화하려면 `H 이 경우, 프록시 헤더 필드를 신뢰할지 여부를 나타내는 `TRUST_PROXY_HEADER`를 `true`로 설정하는 것이 좋습니다. Logto는 이 값을 [Koa 앱 설정](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings)에 전달합니다. -이 필드를 언제 구성해야 하는지에 대해서는 [TLS 오프로딩 프록시 신뢰](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies)를 참조하세요. +이 필드를 언제 설정해야 하는지에 대해서는 [TLS 오프로딩 프록시 신뢰](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies)를 참조하세요. -## 데이터베이스 설정 {#database-configs} +## 데이터베이스 구성 {#database-configs} -너무 많은 환경 변수를 관리하는 것은 비효율적이고 유연하지 않으므로, 대부분의 일반 설정은 데이터베이스 테이블 `logto_configs`에 저장됩니다. +너무 많은 환경 변수를 관리하는 것은 비효율적이고 유연하지 않으므로, 대부분의 일반 구성은 데이터베이스 테이블 `logto_configs`에 저장됩니다. 이 테이블은 간단한 키-값 저장소이며, 키는 다음과 같이 열거할 수 있습니다: diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index 9868e6b46f2..c8005d9e93e 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -6,24 +6,28 @@ sidebar_position: 6 ## 동의 화면이란 무엇인가요? \{#what-is-consent-screen} -Logto에 Google 계정으로 가입한다고 상상해 보세요. "Google로 로그인" 버튼을 클릭하면 Google의 로그인 페이지로 리디렉션됩니다. Google 자격 증명을 입력한 후, Logto가 Google 계정 정보에 접근할 수 있도록 허용할 것인지 묻는 메시지가 표시됩니다. 이것이 사용자 동의 화면입니다. +Logto에 Google 계정으로 가입한다고 상상해 보세요. "Google로 로그인" 버튼을 클릭하면 Google의 로그인 페이지로 리디렉션됩니다. Google 자격 증명을 입력한 후, Logto가 Google 계정 정보에 접근할 수 있도록 권한을 부여하라는 메시지가 표시됩니다. 이것이 사용자 동의 화면입니다. -이 페이지를 사용자 **동의 화면 (consent screen)** 또는 **동의 페이지 (consent page)**라고 부릅니다. 이는 사용자가 [타사 애플리케이션](/integrate-logto/third-party-applications)이 자신의 데이터를 대신 접근할 수 있도록 권한을 부여할 수 있게 하는 표준 [OIDC / OAuth 2.0 플로우](/integrate-logto/third-party-applications)입니다. 동의 화면의 주요 목적은 사용자의 개인정보 수집, 처리, 사용에 대해 알리고, 이러한 활동에 대해 명시적인 동의 또는 승인을 요청하는 것입니다. +이 페이지를 사용자 **동의 화면 (Consent screen)** 또는 **동의 페이지**라고 부릅니다. 이는 사용자가 [타사 애플리케이션](/integrate-logto/third-party-applications)이 자신의 데이터를 대신 접근할 수 있도록 권한을 부여할 수 있게 해주는 표준 [OIDC / OAuth 2.0 플로우](/integrate-logto/third-party-applications)입니다. 이 화면의 주요 목적은 사용자의 개인정보 수집, 처리, 사용에 대해 알리고, 이러한 활동에 대해 명시적인 동의 또는 승인을 요청하는 것입니다. -동의 화면에서는 일반적으로 수집될 데이터의 유형, 사용 방법, 제3자와의 공유 여부 등에 대한 [정보](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information)가 사용자에게 제공됩니다. 이 정보는 투명성을 보장하고, 사용자가 자신의 개인정보 및 데이터 보안에 대해 정보에 입각한 결정을 내릴 수 있도록 돕습니다. +동의 화면에서는 일반적으로 수집될 데이터의 유형, 사용 방법, 제3자와의 공유 여부 등에 대한 [정보](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information)가 사용자에게 제공됩니다. 이 정보는 투명성을 보장하며, 사용자가 자신의 개인정보 및 데이터 보안에 대해 정보에 입각한 결정을 내릴 수 있도록 도와줍니다. -동의 페이지는 유럽 연합의 일반 데이터 보호 규정([GDPR](https://gdpr-info.eu/art-4-gdpr/))이나 미국의 캘리포니아 소비자 개인정보 보호법([CCPA](https://oag.ca.gov/privacy/ccpa))과 같은 개인정보 보호 규정의 맥락에서 특히 중요합니다. 이러한 규정은 조직이 사용자의 개인정보를 처리하기 전에 명확하고 적극적인 동의를 얻도록 요구합니다. +동의 페이지는 유럽 연합의 일반 데이터 보호 규정 ([GDPR](https://gdpr-info.eu/art-4-gdpr/))이나 미국의 캘리포니아 소비자 개인정보 보호법 ([CCPA](https://oag.ca.gov/privacy/ccpa))과 같은 개인정보 보호 규정의 맥락에서 특히 중요합니다. 이러한 규정은 조직이 사용자의 개인정보를 처리하기 전에 명확하고 적극적인 동의를 얻도록 요구합니다. ## Logto에서 사용자가 동의 화면을 언제 보게 되나요? \{#when-does-user-see-the-consent-screen-in-logto} -앞서 언급했듯이, 동의 화면은 사용자가 Google, Facebook, Apple과 같은 타사 아이덴티티 제공자 (IdP)로 Logto에 로그인할 때 나타납니다. 이 설정에서 Logto는 서비스 제공자 (SP)로서 IdP로부터 사용자 정보 접근을 요청합니다. 동의 화면은 일반적으로 [SP](https://auth.wiki/service-provider)와 [IdP](https://auth.wiki/identity-provider)가 서로 다른 조직일 때 표시되며, 데이터 공유를 위해 사용자 인가가 필요합니다. +앞서 언급했듯이, 동의 화면은 사용자가 Google, Facebook, Apple과 같은 타사 아이덴티티 제공자 (IdP)를 통해 Logto에 로그인할 때 나타납니다. 이 설정에서 Logto는 서비스 제공자 (SP)로서 IdP로부터 사용자 정보 접근을 요청합니다. 동의 화면은 일반적으로 [SP](https://auth.wiki/service-provider)와 [IdP](https://auth.wiki/identity-provider)가 서로 다른 조직일 때 표시되며, 데이터 공유를 위해 사용자 인가가 필요합니다. Consent screen Logto as SP -마찬가지로, Logto가 IdP로 동작할 때, Logto와 통합된 [**OIDC / OAuth 타사 애플리케이션**](/integrate-logto/third-party-applications)에 사용자가 로그인하면 동의 화면이 표시됩니다. 이 화면은 애플리케이션이 요청하는 데이터에 대해 사용자에게 알리고, 진행을 위한 허가를 요청합니다. 사용자는 요청된 권한을 검토하고, 애플리케이션에 인가를 부여할지 결정할 수 있습니다. +마찬가지로, Logto가 IdP로 동작할 때, Logto와 통합된 [**OIDC / OAuth 타사 애플리케이션**](/integrate-logto/third-party-applications)에 사용자가 로그인하면 동의 화면이 표시됩니다. 이 화면은 애플리케이션이 요청하는 데이터에 대해 사용자에게 알리고, 진행을 위한 사용자의 허락을 구합니다. 사용자는 요청된 권한을 검토하고 애플리케이션에 인가를 부여할지 결정할 수 있습니다. Consent screen Logto as IdP +### 미등록(동적) 클라이언트 \{#unregistered-dynamic-clients} + +[동적 앱](/integrate-logto/third-party-applications/dynamic-apps)이 활성화된 경우, 클라이언트는 사전 등록 없이 테넌트에 연결할 수 있습니다. 이러한 클라이언트의 경우, 동의 화면에는 클라이언트 ID URL의 호스트와 함께 추가 안내가 표시됩니다. 클라이언트 이름과 로고는 클라이언트의 자체 메타데이터 문서에서 가져오기 때문에 어떤 브랜드도 모방할 수 있지만, 호스트는 위조할 수 없습니다. + ## 동의 화면을 어떻게 설정하나요? \{#how-to-configure-the-consent-screen} Logto 동의 플로우를 통해 타사 애플리케이션의 로그인을 인가할 수 있습니다. 각 OIDC 타사 애플리케이션별로 브랜딩 및 권한 요청을 맞춤 설정할 수 있습니다. @@ -33,7 +37,7 @@ Logto 동의 플로우를 통해 타사 애플리케이션의 로그인을 인 ## 관련 리소스 \{#related-resources} - 동의 화면이 포함된 안전한 OIDC IdP로 서비스를 전환하세요. + 귀하의 서비스를 동의 화면이 탑재된 안전한 OIDC IdP로 전환하세요. 사용자 동의 화면 소개. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index befd1c7023c..3fc87840241 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -7,12 +7,12 @@ sidebar_position: 7 ## 소개 \{#introduction} -Logto에서 *애플리케이션*은 Logto 플랫폼에 등록되어 사용자 정보를 액세스하거나 사용자를 대신해 작업을 수행할 수 있는 권한을 부여받은 특정 소프트웨어 프로그램 또는 서비스를 의미합니다. 애플리케이션은 Logto API에 대한 요청의 출처를 식별하고, 해당 애플리케이션에 접근하는 사용자의 인증 (Authentication) 및 인가 (Authorization) 과정을 관리하는 데 사용됩니다. +Logto에서 *애플리케이션*은 Logto 플랫폼에 등록되어 사용자 정보를 액세스하거나 사용자를 대신하여 작업을 수행할 수 있는 권한을 부여받은 특정 소프트웨어 프로그램 또는 서비스를 의미합니다. 애플리케이션은 Logto API에 대한 요청의 출처를 식별하고, 해당 애플리케이션에 접근하는 사용자의 인증 (Authentication) 및 인가 (Authorization) 프로세스를 관리하는 데 사용됩니다. -Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 하나의 위치에서 자신이 인가 (Authorization)된 애플리케이션을 쉽게 접근하고 관리할 수 있으며, 일관되고 안전한 인증 (Authentication) 과정을 제공합니다. 이는 사용자 경험을 간소화하고, 인가 (Authorization)된 사람만이 민감한 정보에 접근하거나 조직을 대신해 작업을 수행하도록 보장합니다. +Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 하나의 위치에서 자신이 인가 (Authorization)된 애플리케이션을 쉽게 접근하고 관리할 수 있으며, 일관되고 안전한 인증 (Authentication) 프로세스를 제공합니다. 이를 통해 사용자 경험을 간소화하고, 인가 (Authorization)된 사람만이 민감한 정보에 접근하거나 조직을 대신하여 작업을 수행하도록 보장할 수 있습니다. -애플리케이션은 Logto의 감사 로그에서도 사용되어 사용자 활동을 추적하고 잠재적인 보안 위협이나 침해를 식별합니다. 특정 작업을 특정 애플리케이션과 연관시킴으로써, Logto는 데이터가 어떻게 접근되고 사용되는지에 대한 상세한 인사이트를 제공하여 조직이 보안 및 컴플라이언스 요구사항을 더 잘 관리할 수 있도록 합니다. -애플리케이션을 Logto와 통합하려면 [Logto 통합하기](/integrate-logto)를 참고하세요. +애플리케이션은 Logto의 감사 로그에서도 사용되어 사용자 활동을 추적하고 잠재적인 보안 위협이나 침해를 식별하는 데 활용됩니다. 특정 작업을 특정 애플리케이션과 연관시킴으로써, Logto는 데이터가 어떻게 접근되고 사용되는지에 대한 상세한 인사이트를 제공하여 조직이 보안 및 컴플라이언스 요구사항을 더 잘 관리할 수 있도록 합니다. +애플리케이션을 Logto와 통합하고 싶다면 [Logto 통합하기](/integrate-logto)를 참고하세요. ## 속성 \{#properties} @@ -20,6 +20,10 @@ Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 *애플리케이션 ID*는 Logto에서 애플리케이션을 식별하기 위한 고유 자동 생성 키이며, OAuth 2.0에서는 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)로 참조됩니다. +:::note +[동적 앱](/integrate-logto/third-party-applications/dynamic-apps) 클라이언트는 Logto에 등록되지 않습니다. 이들의 client ID는 클라이언트가 소유한 공개 HTTPS URL로, 클라이언트 메타데이터 문서를 제공합니다. +::: + ### 애플리케이션 유형 \{#application-types} *애플리케이션*은 다음 중 하나의 애플리케이션 유형이 될 수 있습니다: @@ -35,7 +39,7 @@ Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 *애플리케이션 시크릿*은 인증 (Authentication) 시스템에서 애플리케이션을 인증하는 데 사용되는 키로, 특히 프라이빗 클라이언트(전통적인 웹 및 M2M 앱)에서 프라이빗 보안 장벽 역할을 합니다. :::tip -싱글 페이지 앱(SPA)과 네이티브 앱은 App secret을 제공하지 않습니다. SPA와 네이티브 앱은 "공개 클라이언트"로, 시크릿을 안전하게 보관할 수 없습니다(브라우저 코드나 앱 번들은 누구나 볼 수 있음). Logto는 앱 시크릿 대신 PKCE, 엄격한 리디렉션 URI/CORS 검증, 단명 액세스 토큰, 리프레시 토큰 회전을 통해 보호합니다. +싱글 페이지 앱(SPA)과 네이티브 앱은 앱 시크릿을 제공하지 않습니다. SPA와 네이티브 앱은 "공개 클라이언트"로, 시크릿을 안전하게 보관할 수 없습니다(브라우저 코드나 앱 번들은 검사 가능함). 앱 시크릿 대신 Logto는 PKCE, 엄격한 리디렉션 URI/CORS 검증, 단명 액세스 토큰, 리프레시 토큰 회전을 통해 보호합니다. ::: ### 애플리케이션 이름 \{#application-name} @@ -56,38 +60,38 @@ Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 *리디렉션 URI*는 애플리케이션에 대해 미리 구성된 유효한 리디렉션 URI 목록입니다. 사용자가 Logto에 로그인하고 애플리케이션에 접근하려고 할 때, 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다. -허용된 URI 목록은 인증 (Authentication) 과정에서 애플리케이션이 Logto에 보낸 인가 (Authorization) 요청에 포함된 리디렉션 URI를 검증하는 데 사용됩니다. 인가 (Authorization) 요청에 지정된 리디렉션 URI가 애플리케이션 설정의 허용된 URI 중 하나와 일치하면, 인증 (Authentication)에 성공한 후 해당 URI로 사용자가 리디렉션됩니다. 허용 목록에 없는 경우, 사용자는 리디렉션되지 않으며 인증 (Authentication) 과정이 실패합니다. +허용된 URI 목록은 인증 (Authentication) 과정에서 애플리케이션이 Logto에 보낸 인가 (Authorization) 요청에 포함된 리디렉션 URI를 검증하는 데 사용됩니다. 인가 (Authorization) 요청에 지정된 리디렉션 URI가 애플리케이션 설정의 허용된 URI 중 하나와 일치하면, 인증 (Authentication)에 성공한 후 해당 URI로 사용자가 리디렉션됩니다. 리디렉션 URI가 허용 목록에 없으면, 사용자는 리디렉션되지 않으며 인증 (Authentication) 과정이 실패합니다. :::note -모든 유효한 리디렉션 URI가 Logto의 허용 목록에 추가되어야, 인증 (Authentication) 후 사용자가 애플리케이션에 정상적으로 접근할 수 있습니다. +모든 유효한 리디렉션 URI가 Logto의 애플리케이션 허용 목록에 추가되어야, 인증 (Authentication) 후 사용자가 애플리케이션에 정상적으로 접근할 수 있습니다. ::: -[Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2)에서 자세한 정보를 확인할 수 있습니다. +자세한 내용은 [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2)를 참고하세요. - 인가 코드 플로우에서 OIDC 리디렉션 URI 이해하기 + OIDC에서 인가 코드 플로우의 리디렉션 URI 이해하기 #### 와일드카드 패턴 \{#wildcard-patterns} _적용 대상: 싱글 페이지 앱, 전통적인 웹 앱_ -리디렉션 URI는 프리뷰 배포 등 동적 환경을 위해 와일드카드 패턴(`*`)을 지원합니다. 와일드카드는 HTTP/HTTPS URI의 호스트명과 경로명에 사용할 수 있습니다. +리디렉션 URI는 프리뷰 배포 등 동적 환경을 위해 와일드카드 패턴(`*`)을 지원합니다. 와일드카드는 HTTP/HTTPS URI의 호스트명 및 경로명에 사용할 수 있습니다. **규칙:** - 와일드카드는 호스트명과 경로명에만 허용됩니다. - 스킴, 포트, 쿼리 파라미터, 해시 프래그먼트에는 와일드카드가 허용되지 않습니다. -- 호스트명 와일드카드는 반드시 점(`.`)을 하나 이상 포함해야 합니다(예: `https://*.example.com/callback`). +- 호스트명 와일드카드는 반드시 점(.)을 하나 이상 포함해야 합니다(예: `https://*.example.com/callback`). **예시:** -- `https://*.example.com/callback` - 모든 서브도메인에 매칭 -- `https://preview-*.example.com/callback` - 프리뷰 배포에 매칭 -- `https://example.com/*/callback` - 모든 경로 세그먼트에 매칭 +- `https://*.example.com/callback` - 모든 서브도메인에 일치 +- `https://preview-*.example.com/callback` - 프리뷰 배포에 일치 +- `https://example.com/*/callback` - 모든 경로 세그먼트에 일치 :::caution -와일드카드 리디렉션 URI는 표준 OIDC가 아니며 공격 표면을 넓힐 수 있습니다. 가능한 한 정확한 리디렉션 URI를 사용하는 것이 좋습니다. +와일드카드 리디렉션 URI는 표준 OIDC가 아니며 공격 표면을 넓힐 수 있습니다. 가능한 한 정확한 리디렉션 URI를 우선 사용하고, 신중하게 사용하세요. ::: ### 로그아웃 후 리디렉션 URI \{#post-sign-out-redirect-uris} @@ -98,16 +102,16 @@ _적용 대상: 싱글 페이지 앱, 전통적인 웹 앱_ 사용자가 Logto에서 로그아웃하면 세션이 종료되고, 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다. 이를 통해 사용자가 로그아웃 후 인가 (Authorization)된 유효한 엔드포인트로만 이동하도록 하여, 미확인 또는 검증되지 않은 엔드포인트로의 리디렉션과 관련된 무단 접근 및 보안 위험을 방지할 수 있습니다. -[RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout)에서 자세한 정보를 확인할 수 있습니다. +자세한 내용은 [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout)을 참고하세요. ### CORS 허용 오리진 \{#cors-allowed-origins} -*CORS (교차 출처 리소스 공유) 허용 오리진*은 애플리케이션이 Logto 서비스에 요청을 보낼 수 있도록 허용된 오리진 목록입니다. 허용 목록에 포함되지 않은 오리진은 Logto 서비스에 요청할 수 없습니다. +*CORS (교차 출처 리소스 공유) 허용 오리진*은 애플리케이션이 Logto 서비스에 요청을 보낼 수 있도록 허용된 오리진 목록입니다. 허용 목록에 포함되지 않은 오리진은 Logto 서비스에 요청을 보낼 수 없습니다. -CORS 허용 오리진 목록은 무단 도메인에서 Logto 서비스에 접근하는 것을 제한하고, 교차 사이트 요청 위조(CSRF) 공격을 방지하는 데 도움이 됩니다. Logto에서 애플리케이션의 허용 오리진을 지정함으로써, 인가 (Authorization)된 도메인만 서비스에 요청할 수 있도록 보장합니다. +CORS 허용 오리진 목록은 무단 도메인에서 Logto 서비스에 접근하는 것을 제한하고, 교차 사이트 요청 위조(CSRF) 공격을 방지하는 데 도움이 됩니다. Logto에서 애플리케이션의 허용 오리진을 지정함으로써, 인가 (Authorization)된 도메인만 서비스에 요청할 수 있도록 보장할 수 있습니다. :::note -허용 오리진 목록에는 애플리케이션이 서비스될 오리진이 포함되어야 합니다. 이를 통해 애플리케이션의 요청은 허용되고, 무단 오리진의 요청은 차단됩니다. +허용 오리진 목록에는 애플리케이션이 서비스되는 오리진이 포함되어야 합니다. 이를 통해 애플리케이션의 요청은 허용되고, 무단 오리진의 요청은 차단됩니다. ::: ### OpenID 제공자 구성 엔드포인트 \{#openid-provider-configuration-endpoint} @@ -116,9 +120,9 @@ CORS 허용 오리진 목록은 무단 도메인에서 Logto 서비스에 접근 ### 인가 엔드포인트 \{#authorization-endpoint} -*인가 엔드포인트*는 OIDC 용어로, 사용자의 인증 (Authentication) 과정을 시작하는 데 사용되는 필수 엔드포인트입니다. 사용자가 Logto 플랫폼에 등록된 보호된 리소스나 애플리케이션에 접근하려고 할 때, *인가 엔드포인트*로 리디렉션되어 자신의 아이덴티티를 인증 (Authentication)하고 요청된 리소스에 접근할 인가 (Authorization)를 받게 됩니다. +*인가 엔드포인트*는 OIDC 용어로, 사용자의 인증 (Authentication) 프로세스를 시작하는 데 사용되는 필수 엔드포인트입니다. 사용자가 Logto 플랫폼에 등록된 보호된 리소스나 애플리케이션에 접근하려고 할 때, *인가 엔드포인트*로 리디렉션되어 아이덴티티를 인증 (Authentication)하고 요청된 리소스에 접근할 수 있는 인가 (Authorization)를 받게 됩니다. -[Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint)에서 자세한 정보를 확인할 수 있습니다. +자세한 내용은 [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint)를 참고하세요. ### 토큰 엔드포인트 \{#token-endpoint} @@ -126,7 +130,7 @@ CORS 허용 오리진 목록은 무단 도메인에서 Logto 서비스에 접근 OIDC 클라이언트가 액세스 토큰이나 ID 토큰을 얻어야 할 때, 인가 (Authorization) 그랜트(일반적으로 인가 코드 또는 리프레시 토큰)와 함께 토큰 엔드포인트에 요청을 보냅니다. 토큰 엔드포인트는 인가 (Authorization) 그랜트를 검증하고, 유효하다면 클라이언트에 액세스 토큰 또는 ID 토큰을 발급합니다. -[Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint)에서 자세한 정보를 확인할 수 있습니다. +자세한 내용은 [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint)를 참고하세요. ### Userinfo 엔드포인트 \{#userinfo-endpoint} @@ -136,17 +140,17 @@ OpenID Connect [UserInfo Endpoint](https://openid.net/specs/openid-connect-core- _적용 대상: 전통적인 웹, SPA_ -이 옵션을 활성화하면, 인증 (Authentication) 요청에 `prompt=consent`가 포함되지 않거나, 스코프에 `offline_access`가 포함되지 않아도 Logto는 항상 리프레시 토큰을 발급합니다. +활성화하면, 인증 (Authentication) 요청에 `prompt=consent`가 포함되지 않거나, 스코프에 `offline_access`가 포함되지 않아도 Logto는 항상 리프레시 토큰을 발급합니다. -그러나 이 방식은 OpenID Connect와 호환되지 않으며, 일반적으로 권장되지 않습니다(일부 리프레시 토큰이 필요한 서드파티 OAuth 통합에서만 유용). 잠재적으로 문제를 일으킬 수 있습니다. +그러나 이 방식은 필요하지 않은 한 권장되지 않습니다(일반적으로 리프레시 토큰이 필요한 일부 서드파티 OAuth 통합에 유용함). OpenID Connect와 호환되지 않으며, 잠재적으로 문제를 일으킬 수 있습니다. ### 리프레시 토큰 회전 \{#rotate-refresh-token} _기본값: `true`_ -이 옵션을 활성화하면, 클라이언트가 리프레시 토큰을 사용해 새로운 토큰을 요청할 때 Logto가 새로운 리프레시 토큰을 발급할 수 있습니다. 리프레시 토큰과 해당 앱 그랜트가 여전히 유효하다면, 기본 회전 정책은 다음과 같습니다: +활성화하면, 클라이언트가 리프레시 토큰을 사용해 새로운 토큰을 요청할 때 Logto가 새로운 리프레시 토큰을 발급할 수 있습니다. 리프레시 토큰과 해당 앱 그랜트가 여전히 유효하다면, 기본 회전 정책은 다음과 같습니다: -- 리프레시 토큰 체인이 1년 동안 존재하기 전까지만 회전이 가능합니다. 이는 내부 회전 안전 한도이며, 리프레시 토큰 자체의 TTL 또는 앱 그랜트 TTL이 더 빨리 만료될 수 있습니다. 한도에 도달하면 Logto는 더 이상 리프레시 토큰을 회전하지 않으며, 현재 리프레시 토큰의 만료가 최종입니다. +- 리프레시 토큰은 리프레시 토큰 체인이 1년 동안 존재하기 전까지만 회전할 수 있습니다. 이는 내부 회전 안전 한도이며, 리프레시 토큰 자체의 TTL이나 앱 그랜트 TTL이 더 빨리 만료될 수 있습니다. 한도에 도달하면 Logto는 더 이상 리프레시 토큰을 회전하지 않으며, 현재 리프레시 토큰의 만료가 최종입니다. - 발신자 제한 리프레시 토큰을 사용하지 않는 공개 클라이언트(예: 일반 네이티브 애플리케이션 및 싱글 페이지 애플리케이션)의 경우, 회전이 허용되는 동안 매번 리프레시 토큰 요청 시 리프레시 토큰을 회전합니다. - 그 외 클라이언트의 경우, 리프레시 토큰의 만료가 임박했을 때(원래 TTL의 70% 이상 경과)만 리프레시 토큰을 회전합니다. @@ -157,16 +161,16 @@ _기본값: `true`_ ::: :::caution 리프레시 토큰 체인 수명 -리프레시 토큰은 앱 그랜트와 연관되어 있습니다. 기본 Logto 그랜트 TTL은 **180일**입니다. 그랜트가 만료되면, 리프레시 토큰 요청이 실패하며, 회전이 활성화되어 있어도 더 이상 새로운 토큰을 얻을 수 없습니다. +리프레시 토큰은 앱 그랜트와 연결되어 있습니다. 기본 Logto 그랜트 TTL은 **180일**입니다. 그랜트가 만료되면, 리프레시 토큰 요청이 실패하며, 회전이 활성화되어 있어도 더 이상 새로운 토큰을 얻을 수 없습니다. -즉, 리프레시 토큰 기반 인가 (Authorization)의 실질적인 최대 수명은 현재 그랜트 TTL, 명시적 해지, 또는 리프레시 토큰 자체의 만료 중 먼저 도달하는 값으로 제한됩니다. +즉, 리프레시 토큰 기반 인가 (Authorization)의 실질적인 최대 수명은 현재 그랜트 TTL, 명시적 해지, 또는 리프레시 토큰 자체의 만료 중 먼저 도달하는 것으로 제한됩니다. ::: 리프레시 토큰 회전 이해하기 -### 리프레시 토큰 TTL(유효 기간, 일 단위) \{#refresh-token-time-to-live-ttl-in-days} +### 리프레시 토큰 TTL(일 단위) \{#refresh-token-time-to-live-ttl-in-days} _적용 대상: 네이티브 앱, 전통적인 웹, SPA; 기본값: 14일; 최대: 180일_ @@ -175,17 +179,17 @@ _적용 대상: 네이티브 앱, 전통적인 웹, SPA; 기본값: 14일; 최 일반적으로 더 낮은 값이 선호됩니다. :::note -보안상의 이유로 싱글 페이지 애플리케이션(SPA)에서는 TTL 갱신이 불가능합니다. SPA의 경우, 이 설정은 최초 발급 시점부터 고정된 리프레시 토큰 수명을 제어합니다. Logto는 토큰 요청을 통해 TTL을 연장하지 않으며, 리프레시 토큰 회전도 SPA 리프레시 토큰의 만료를 방지하지 않습니다. +SPA(싱글 페이지 애플리케이션)에서는 보안상의 이유로 TTL 갱신이 불가능합니다. SPA의 경우, 이 설정은 최초 발급 시점부터 고정된 리프레시 토큰 수명을 제어합니다. Logto는 토큰 요청을 통해 TTL을 연장하지 않으며, 리프레시 토큰 회전도 SPA 리프레시 토큰 만료를 방지하지 않습니다. ::: :::caution 리프레시 토큰 TTL과 그랜트 TTL -리프레시 토큰 TTL만이 유일한 만료 한계가 아닙니다. 리프레시 토큰은 앱 그랜트와 연결되어 있으며, 기본 Logto 그랜트 TTL은 **180일**입니다. 그랜트가 만료되면, 리프레시 토큰이 여전히 유효하더라도 요청이 실패합니다. +리프레시 토큰 TTL만이 유일한 만료 제한이 아닙니다. 리프레시 토큰은 앱 그랜트와 연결되어 있으며, 기본 Logto 그랜트 TTL은 **180일**입니다. 그랜트가 만료되면, 리프레시 토큰이 여전히 유효하더라도 요청이 실패합니다. 토큰 요청이 리프레시 토큰 TTL을 갱신하는 클라이언트의 경우, 그랜트 TTL이 리프레시 토큰 체인의 절대 최대 수명 역할을 합니다. SPA의 경우, 리프레시 토큰의 고정 TTL이 그랜트보다 먼저 만료될 수 있습니다. ::: :::caution 리프레시 토큰과 세션 바인딩 -인가 (Authorization) 요청에 `offline_access` 스코프 없이 리프레시 토큰이 발급되면, 해당 토큰은 사용자 세션에 바인딩됩니다. 세션의 TTL은 **14일**로 고정되어 있습니다. 세션이 만료되면, 리프레시 토큰의 TTL 설정과 무관하게 토큰이 무효화됩니다. +인가 (Authorization) 요청에 `offline_access` 스코프 없이 리프레시 토큰이 발급된 경우, 해당 토큰은 사용자 세션에 바인딩됩니다. 세션의 TTL은 **14일**로 고정되어 있습니다. 세션이 만료되면, 리프레시 토큰의 TTL 설정과 무관하게 토큰이 무효화됩니다. 리프레시 토큰 TTL 설정이 완전히 적용되도록 하려면, 인가 (Authorization) 요청에 반드시 `offline_access` 스코프를 포함하세요. ::: @@ -199,7 +203,7 @@ OpenID Connect 백채널 로그아웃 엔드포인트입니다. 자세한 내용 `maxAllowedGrants`는 `customClientMetadata` 하위의 선택적 앱 레벨 필드로, 현재 앱에서 사용자별로 동시에 활성화될 수 있는 최대 그랜트 수를 제어합니다. - **기본값**: `undefined` (제한 없음) -- **설정 시**: 인가 (Authorization)에 성공할 때마다 Logto는 현재 앱에서 사용자의 전체 활성 그랜트 수(브라우저 및 디바이스 전체)를 확인합니다. 제한을 초과하면 Logto는 가장 오래된 그랜트를 해지합니다. +- **설정 시**: 인가 (Authorization)에 성공할 때마다 Logto는 현재 앱에서 해당 사용자의 전체 활성 그랜트 수(브라우저 및 디바이스 전체)를 확인합니다. 제한을 초과하면 Logto가 가장 오래된 그랜트를 해지합니다. 이 설정은 앱별로 동시 인증된 디바이스 수를 제한하고 싶을 때 유용합니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 8fdaff817ac..8b845c48bc6 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,6 +4,7 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; @@ -14,28 +15,35 @@ Logto의 타사 애플리케이션 통합 기능을 통해 Logto를 외부 애 아이덴티티 제공자 (IdP)는 사용자의 아이덴티티를 검증하고 로그인 자격 증명을 관리하는 서비스입니다. 사용자의 아이덴티티를 확인한 후, IdP는 인증 (Authentication) 토큰 또는 어설션을 생성하여 사용자가 다시 로그인할 필요 없이 다양한 애플리케이션이나 서비스에 접근할 수 있도록 합니다. -[Logto를 애플리케이션에 통합하기](/integrate-logto/integrate-logto-into-your-application) 가이드에서 생성한, 여러분이 직접 개발하고 완전히 제어하는 애플리케이션과 달리, 타사 애플리케이션은 외부 개발자나 비즈니스 파트너가 개발한 독립적인 서비스입니다. +[Logto 애플리케이션에 인증 (Authentication)을 추가하세요](/integrate-logto/integrate-logto-into-your-application) 가이드에서 생성한, 여러분이 직접 개발하고 완전히 제어하는 애플리케이션과 달리, 타사 애플리케이션은 외부 개발자나 비즈니스 파트너가 개발한 독립적인 서비스입니다. -이 통합 방식은 일반적인 비즈니스 시나리오에 적합합니다. 사용자가 Logto 계정으로 파트너 애플리케이션에 접근할 수 있도록 할 수 있으며, 이는 엔터프라이즈 사용자가 Google Workspace로 Slack에 로그인하는 방식과 유사합니다. 또한, 타사 애플리케이션이 "Logto로 로그인" 기능을 추가할 수 있는 오픈 플랫폼을 구축할 수도 있습니다. 이는 "Google로 로그인"과 비슷합니다. +이 통합 방식은 일반적인 비즈니스 시나리오에 적합합니다. 사용자가 Logto 계정으로 파트너 애플리케이션에 접근할 수 있도록 할 수 있으며, 이는 엔터프라이즈 사용자가 Google Workspace로 Slack에 로그인하는 것과 유사합니다. 또한, 타사 애플리케이션이 "Logto로 로그인" 기능을 추가할 수 있는 오픈 플랫폼을 구축할 수도 있습니다. 이는 "Google로 로그인"과 비슷합니다. -Logto는 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 프로토콜을 기반으로 한 아이덴티티 서비스로, [인증 (Authentication)](https://auth.wiki/authentication)과 [인가 (Authorization)](https://auth.wiki/authorization) 기능을 모두 제공합니다. 이로 인해 OIDC 타사 앱 통합은 기존 웹 애플리케이션만큼 간단하게 구현할 수 있습니다. +Logto는 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 프로토콜을 기반으로 구축된 아이덴티티 서비스로, [인증 (Authentication)](https://auth.wiki/authentication)과 [인가 (Authorization)](https://auth.wiki/authorization) 기능을 모두 제공합니다. 이로 인해 OIDC 타사 앱 통합은 기존 웹 애플리케이션과 마찬가지로 매우 간단합니다. OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 계층을 추가하여 구축되었기 때문에, OAuth 프로토콜을 사용하여 타사 앱을 통합할 수도 있습니다. +## 타사 앱 온보딩 방법 두 가지 \{#two-ways-to-onboard-a-third-party-app} + +- **Logto에 앱 등록** (이 가이드): 애플리케이션을 생성하고 권한 및 리디렉션 URI를 구성합니다. 파트너를 알고 있을 때 사용하세요. +- **[동적 앱](/integrate-logto/third-party-applications/dynamic-apps)**: 사전 등록 없이 클라이언트가 자체 메타데이터 문서의 공개 HTTPS URL을 클라이언트 ID로 사용하여 연결합니다. MCP 클라이언트, AI 에이전트 등 어떤 클라이언트든 연결될 수 있을 때 사용하세요. + +두 방법은 동시에 사용할 수 있습니다. + ## Logto에서 타사 애플리케이션 생성하기 \{#create-a-third-party-application-in-logto} 1. 콘솔 > 애플리케이션로 이동하세요. -2. "애플리케이션 생성" 버튼을 클릭하세요. 애플리케이션 유형으로 "타사 앱"을 선택하고, 다음 중 하나의 통합 프로토콜을 선택하세요: +2. "애플리케이션 생성" 버튼을 클릭합니다. 애플리케이션 유형으로 "타사 앱"을 선택하고 다음 통합 프로토콜 중 하나를 선택하세요: - OIDC / OAuth 3. 타사 애플리케이션의 유형에 따라 애플리케이션 유형을 선택하세요: - **전통적인 웹**: 백엔드에서 클라이언트 시크릿을 안전하게 저장할 수 있는 서버 렌더링 애플리케이션 (예: Node.js, PHP, Java). - - **싱글 페이지 앱 (SPA)**: 브라우저에서 완전히 실행되며 시크릿을 안전하게 저장할 수 없는 클라이언트 사이드 렌더링 애플리케이션 (예: React, Vue, Angular). + - **싱글 페이지 앱 (SPA)**: 브라우저에서 완전히 실행되며 시크릿을 안전하게 저장할 수 없는 클라이언트 렌더링 애플리케이션 (예: React, Vue, Angular). - **네이티브**: 사용자 기기에서 실행되는 모바일 또는 데스크톱 애플리케이션 (예: iOS, Android, Electron). 4. 애플리케이션의 이름과 설명을 입력한 후 "생성" 버튼을 클릭하세요. 새로운 타사 애플리케이션이 생성됩니다. -생성된 모든 타사 애플리케이션은 "타사 앱" 탭 아래의 애플리케이션 페이지에 정리되어 표시됩니다. 이 구조는 여러분의 자체 애플리케이션과 구분하여 한 곳에서 모든 애플리케이션을 쉽게 관리할 수 있도록 도와줍니다. +생성된 모든 타사 애플리케이션은 "타사 앱" 탭 아래의 애플리케이션 페이지에 정리되어 표시됩니다. 이를 통해 자체 애플리케이션과 구분하여 한 곳에서 모든 애플리케이션을 쉽게 관리할 수 있습니다. -타사 애플리케이션에 로그인할 수 있는 사용자를 제한하려면, 애플리케이션의 **규칙** 탭에서 [앱 수준 접근 제어](/authorization/app-level-access-control)를 설정하세요. +타사 애플리케이션에 로그인할 수 있는 사용자를 제한하려면, 애플리케이션의 **규칙** 탭에서 [앱 수준 접근 제어](/authorization/app-level-access-control)를 구성하세요. ## 통합 가이드 \{#integration-guide} @@ -50,16 +58,16 @@ OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 계층을 추가 외부 아이덴티티 제공자 구성을 기본적으로 지원하는 서비스나 제품(예: 엔터프라이즈 SaaS 플랫폼, 협업 도구)에 연결하는 경우, 설정은 간단합니다: 1. 서비스의 IdP 또는 SSO 구성 페이지를 엽니다. -2. Logto에서 **클라이언트 ID**(필요하다면 **클라이언트 시크릿**도)를 복사하여 서비스의 구성에 붙여넣습니다. -3. 서비스가 OIDC 자동 디스커버리를 지원한다면 **디스커버리 엔드포인트**를 제공하고, 그렇지 않다면 **인가 엔드포인트**와 **토큰 엔드포인트**를 수동으로 복사합니다. -4. 서비스의 구성 페이지에서 **리디렉션 URI**를 복사하여 Logto 애플리케이션의 허용된 리디렉션 URI에 추가합니다. -5. 서비스에서 허용한다면 **스코프**를 설정하세요. Logto는 OIDC 제공자이므로, 사용자를 인증 (Authentication)해야 한다면 `openid` 스코프를 반드시 포함하세요 (ID 토큰 및 UserInfo 엔드포인트 접근 허용). OAuth 리소스 접근만 필요하다면 `openid` 스코프는 선택 사항입니다. +2. Logto에서 **클라이언트 ID** (필요하다면 **클라이언트 시크릿**도)를 복사하여 서비스의 구성에 붙여넣습니다. +3. 서비스가 OIDC 자동 디스커버리를 지원한다면 **디스커버리 엔드포인트**를 제공하고, 그렇지 않다면 **인가 엔드포인트**와 **토큰 엔드포인트**를 수동으로 복사하세요. +4. 서비스의 구성 페이지에서 **리디렉션 URI**를 복사하여 Logto 애플리케이션의 허용된 리디렉션 URI에 추가하세요. +5. 서비스에서 허용한다면 **스코프**를 구성하세요. Logto는 OIDC 제공자이므로, 사용자를 인증 (Authentication)해야 한다면 `openid` 스코프를 반드시 포함하세요 (ID 토큰 및 UserInfo 엔드포인트 접근 허용). OAuth 리소스 접근만 필요하다면 `openid` 스코프는 선택 사항입니다. 설정이 완료되면 서비스가 OAuth / OIDC 플로우를 자동으로 처리합니다. ### OAuth / OIDC 프로토콜로 통합하기 \{#integrate-via-oauth-protocol} -타사 애플리케이션이 Logto를 IdP로 프로그래밍 방식으로 통합해야 하는 경우, 표준 [인가 코드 플로우](https://auth.wiki/authorization-code-flow)를 구현해야 합니다. 구현을 위해 사용하는 프로그래밍 언어에 맞는 OAuth 2.0 / OIDC 클라이언트 라이브러리 사용을 권장합니다. +타사 애플리케이션이 프로그래밍 방식으로 Logto를 IdP로 통합해야 하는 경우, 표준 [인가 코드 플로우](https://auth.wiki/authorization-code-flow)를 구현해야 합니다. 구현을 위해 사용하는 프로그래밍 언어에 맞는 OAuth 2.0 / OIDC 클라이언트 라이브러리 사용을 권장합니다. @@ -70,38 +78,38 @@ OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 계층을 추가 1. **인가 시작**: `client_id`, `redirect_uri`, `response_type=code`, `scope`와 함께 사용자를 Logto의 인가 엔드포인트로 리디렉션합니다. 2. **콜백 처리**: 리디렉션에서 인가 `code`를 받습니다. -3. **토큰 교환**: 백엔드에서 code, `client_id`, `client_secret`을 포함하여 토큰 엔드포인트에 POST 요청을 보냅니다. +3. **토큰 교환**: 백엔드에서 code, `client_id`, `client_secret`을 포함하여 토큰 엔드포인트로 POST 요청을 보냅니다. -싱글 페이지 앱과 네이티브 앱은 시크릿을 안전하게 저장할 수 없는 **공개 클라이언트**입니다. 이러한 애플리케이션은 클라이언트 시크릿 대신 [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce)를 사용하여 안전하게 인가를 진행해야 합니다. 전체 구현 방법은 [인가 코드 플로우](https://auth.wiki/authorization-code-flow) 및 [PKCE](https://auth.wiki/pkce)를 참고하세요. +싱글 페이지 앱과 네이티브 앱은 시크릿을 안전하게 저장할 수 없는 **공개 클라이언트**입니다. 이러한 애플리케이션은 [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce)를 사용하여 안전하게 인가를 받아야 합니다. 전체 구현 방법은 [인가 코드 플로우](https://auth.wiki/authorization-code-flow) 및 [PKCE](https://auth.wiki/pkce)를 참고하세요. **주요 단계:** -1. **PKCE 파라미터 생성**: `code_verifier`를 생성하고, `code_challenge`(SHA-256)를 도출합니다. -2. **인가 시작**: `code_challenge` 및 `code_challenge_method=S256`과 함께 인가 엔드포인트로 사용자를 리디렉션합니다. +1. **PKCE 파라미터 생성**: `code_verifier`를 생성하고 `code_challenge`(SHA-256)를 도출합니다. +2. **인가 시작**: `code_challenge`, `code_challenge_method=S256`과 함께 인가 엔드포인트로 사용자를 리디렉션합니다. 3. **콜백 처리**: 리디렉션에서 인가 `code`를 받습니다. -4. **토큰 교환**: code와 원래의 `code_verifier`를 포함하여 토큰 엔드포인트에 POST 요청을 보냅니다. +4. **토큰 교환**: code와 원래의 `code_verifier`를 포함하여 토큰 엔드포인트로 POST 요청을 보냅니다. ### 디바이스 플로우로 통합하기 \{#integrate-via-device-flow} -입력이 제한된 디바이스(예: 스마트 TV, 게임 콘솔, CLI 도구)에서 실행되는 네이티브 타사 애플리케이션의 경우, 표준 리디렉션 기반 인가 코드 플로우가 적합하지 않을 수 있습니다. 이럴 때는 [OAuth 2.0 디바이스 인가 그랜트](https://auth.wiki/device-flow)를 사용할 수 있습니다. +입력이 제한된 기기(예: 스마트 TV, 게임 콘솔, CLI 도구)에서 실행되는 네이티브 타사 애플리케이션의 경우, 표준 리디렉션 기반 인가 코드 플로우를 사용할 수 없습니다. 이럴 때는 [OAuth 2.0 디바이스 인가 그랜트](https://auth.wiki/device-flow)를 사용할 수 있습니다. -디바이스 플로우에서는 디바이스가 사용자 코드와 인증 URL을 표시합니다. 사용자는 별도의 기기(휴대폰, 노트북 등)에서 해당 URL에 접속하여 코드를 입력하고 인증을 완료합니다. 디바이스는 인가가 완료될 때까지 Logto의 토큰 엔드포인트를 폴링합니다. +디바이스 플로우에서는 기기가 사용자 코드와 인증 URL을 표시합니다. 사용자는 별도의 기기(휴대폰, 노트북 등)에서 해당 URL에 접속하여 코드를 입력하고 인증 (Authentication)을 완료합니다. 기기는 Logto의 토큰 엔드포인트를 폴링하여 인가가 완료될 때까지 대기합니다. :::note -디바이스 플로우를 구현하기 전에, Logto 콘솔에서 타사 애플리케이션에 필요한 [권한](/integrate-logto/third-party-applications/permission-management)을 반드시 설정하세요. 활성화되지 않은 스코프를 요청하는 타사 앱은 접근이 거부됩니다. +디바이스 플로우를 구현하기 전에, Logto 콘솔에서 타사 애플리케이션에 필요한 [권한](/integrate-logto/third-party-applications/permission-management)을 반드시 구성하세요. 활성화되지 않은 스코프를 요청하는 타사 앱은 접근이 거부됩니다. ::: 전체 구현 방법은 [디바이스 플로우 빠른 시작](/quick-starts/device-flow)을 참고하세요. ## OIDC 타사 애플리케이션의 동의 화면 \{#consent-screen-for-oidc-third-party-applications} -보안상의 이유로, 모든 OIDC 타사 애플리케이션은 Logto에서 인증 (Authentication)된 후 [동의 화면](/end-user-flows/consent-screen)으로 리디렉션되어 사용자 인가 (Authorization)를 받게 됩니다. +보안상의 이유로, 모든 OIDC 타사 애플리케이션은 Logto에서 인증 (Authentication) 후 [동의 화면](/end-user-flows/consent-screen)으로 리디렉션되어 사용자 인가 (Authorization)를 받게 됩니다. 타사에서 요청한 모든 [사용자 프로필 권한](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes), [API 리소스 스코프](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [조직 권한](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes), 그리고 조직 멤버십 정보가 동의 화면에 표시됩니다. @@ -119,7 +127,7 @@ OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 계층을 추가 type: 'link', label: '권한 관리', href: '/integrate-logto/third-party-applications/permission-management', - description: 'OIDC 타사 애플리케이션의 권한을 관리하는 방법을 알아보세요.', + description: 'OIDC 타사 애플리케이션의 권한 관리 방법을 알아보세요.', customProps: { icon: , }, @@ -134,6 +142,16 @@ OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 계층을 추가 icon: , }, }, + { + type: 'link', + label: '동적 앱 (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + '클라이언트 ID 메타데이터 문서 URL을 클라이언트 ID로 사용하여 사전 등록 없이 OAuth 클라이언트가 연결할 수 있도록 합니다.', + customProps: { + icon: , + }, + }, ]} /> @@ -146,13 +164,13 @@ OIDC가 [OAuth 2.0](https://auth.wiki/oauth-2.0) 위에 인증 계층을 추가 -Logto는 역할 기반 접근 제어 (RBAC)를 사용하여 사용자 권한을 관리합니다. 동의 화면에는 사용자의 역할을 통해 이미 할당된 스코프(권한)만 표시됩니다. 타사 앱이 사용자가 갖고 있지 않은 스코프를 요청하는 경우, 해당 스코프는 제외되어 무단 동의를 방지합니다. +Logto는 역할 기반 접근 제어 (RBAC)를 사용하여 사용자 권한을 관리합니다. 동의 화면에는 사용자가 이미 역할을 통해 할당받은 스코프(권한)만 표시됩니다. 사용자가 가지지 않은 스코프를 타사 앱이 요청하더라도, 해당 스코프는 제외되어 무단 동의를 방지합니다. 관리 방법: - 특정 스코프를 가진 [글로벌 역할](/authorization/role-based-access-control) 또는 [조직 역할](/authorization/organization-template)을 정의하세요. - 접근 필요에 따라 사용자에게 역할을 할당하세요. -- 사용자는 역할을 통해 자동으로 스코프를 상속받습니다. +- 사용자는 역할을 통해 자동으로 스코프를 상속받게 됩니다. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..23948efaef0 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,100 @@ +--- +description: OAuth 클라이언트가 클라이언트 ID 메타데이터 문서 URL을 client ID로 사용하여 사전 등록 없이 테넌트에 연결할 수 있도록 합니다. +sidebar_label: 동적 앱 (CIMD) +sidebar_position: 3 +--- + +# 동적 앱 (CIMD) + +동적 앱을 사용하면 OAuth 클라이언트가 사전 등록 없이 테넌트에 연결할 수 있습니다. Logto에서 발급한 client ID 대신, 클라이언트는 공개 HTTPS URL을 `client_id`로 사용합니다. 이 URL은 클라이언트를 설명하는 JSON 문서를 제공하며, 이를 [클라이언트 ID 메타데이터 문서 (CIMD)](https://auth.wiki/client-id-metadata-document)라고 합니다. Logto는 이 문서를 가져와 클라이언트를 [서드파티 애플리케이션](/integrate-logto/third-party-applications)으로 처리합니다. + +동적 앱은 IETF 초안 [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html)를 구현합니다. + +## 동적 앱을 사용할 때 \{#when-to-use-dynamic-app} + +사전 등록은 파트너를 알고 있을 때에만 작동합니다. [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents) 생태계처럼 어떤 클라이언트든 연결될 수 있는 경우에는 작동하지 않습니다. 예를 들어, 사용자가 자신의 AI 에이전트에게 서비스에 연결하라고 요청할 때, 그 에이전트는 이전에 테넌트와 대화한 적이 없을 수 있습니다. + +동적 앱을 사용하면, 클라이언트가 자신이 소유한 URL에 메타데이터를 게시하고, 그 URL이 곧 아이덴티티가 됩니다. 테넌트에 미리 생성해야 할 것은 아무것도 없습니다. + +| | 등록된 서드파티 앱 | 동적 앱 | +| ------------- | ------------------- | --------------------------------------- | +| Client ID | Logto에서 발급 | 클라이언트가 소유한 HTTPS URL | +| 등록 | 필요함 | 필요 없음 | +| Client secret | 지원 | 지원하지 않음 | +| 권한 | 애플리케이션별 | 모든 동적 클라이언트가 공유 | +| Grant types | 앱 유형에 따라 다름 | `authorization_code` 및 `refresh_token` | + +동적 클라이언트는 공개 클라이언트이므로 항상 [PKCE](https://auth.wiki/pkce)를 사용합니다. 두 모델을 동시에 사용할 수 있습니다. 신뢰하는 파트너는 여전히 자체 권한을 가진 등록된 앱을 가질 수 있습니다. + +## 동적 앱 활성화하기 \{#enable-dynamic-app} + +1. 콘솔 > 애플리케이션으로 이동하여 **서드파티 앱** 탭을 + 엽니다. +2. **애플리케이션 생성**을 클릭하고 **동적 앱** 카드를 선택합니다. 이는 애플리케이션을 생성하는 대신 테넌트 레벨 기능을 활성화합니다. +3. 대화 상자에서 확인합니다. 활성화되면, 유효한 공개 HTTPS client ID URL을 가진 모든 OAuth 클라이언트가 테넌트에 대한 인가 요청을 시작할 수 있습니다. +4. 애플리케이션 목록에서 동적 앱을 열고 **권한** 탭으로 이동하여 권한을 부여하세요. + +동적 앱은 편집 가능한 이름, 리디렉션 URI, 자격 증명이 없습니다. 각 클라이언트가 자신의 메타데이터 문서에 이를 제공합니다. + +:::note +동적 앱은 [OIDC 제공자 SSRF 보호](/concepts/core-service/configuration#oidc-provider-ssrf-protection)가 필요합니다. Logto가 인터넷에서 메타데이터 문서를 가져오기 때문입니다. 이를 비활성화한 셀프 호스팅 인스턴스는 동적 앱을 활성화할 수 없습니다. +::: + +### 권한 부여하기 \{#grant-permissions} + +**권한** 탭은 모든 동적 클라이언트가 공유하는 최대 권한을 정의합니다. 이는 등록된 서드파티 앱의 [권한 관리](/integrate-logto/third-party-applications/permission-management)와 유사하게 **사용자** 및 **조직** 섹션으로 구성됩니다. + +부여되지 않은 사용자 권한을 요청하면 오류가 발생하며, 부여되지 않은 API 리소스 및 조직 권한은 무시됩니다. 사용자는 자신의 [역할](/authorization/role-based-access-control)을 통해 가진 권한에만 동의합니다. + +모든 동적 클라이언트가 이 집합을 공유하므로, 최소한으로 유지하세요. + +## 클라이언트 ID 메타데이터 문서 게시하기 \{#publish-a-client-id-metadata-document} + +Logto에 연결하는 클라이언트를 구축하는 경우, 메타데이터 문서를 호스팅하고 해당 URL을 `client_id`로 사용하세요. URL은 반드시 `https` 스킴을 사용해야 하며, fragment, 사용자 정보, dot 경로 세그먼트를 포함할 수 없습니다. Logto는 해당 URL에 `GET` 요청을 보내고 JSON 객체를 기대합니다. + +예를 들어, Claude Code는 `https://claude.ai/oauth/claude-code-client-metadata`를 사용하며, 다음과 같이 제공합니다: + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +필드 이름은 [OAuth 2.0 동적 클라이언트 등록](https://datatracker.ietf.org/doc/html/rfc7591#section-2)과 동일합니다. 참고 사항: + +- `client_id`는 문서를 제공하는 URL과 동일해야 합니다. +- 동적 클라이언트는 공개 클라이언트입니다. 문서에 `client_secret`이 포함되어서는 안 되며, `token_endpoint_auth_method`는 공유 비밀 방식이 아니어야 합니다. 대신 [PKCE](https://auth.wiki/pkce)를 사용하세요. +- `client_uri`, `logo_uri`, `tos_uri`, `policy_uri`와 같은 메타데이터 URI는 절대 `https` URL이어야 합니다. 이는 `redirect_uris`에는 적용되지 않으므로, 네이티브 클라이언트는 위 예시처럼 루프백 주소를 사용할 수 있습니다. +- `redirect_uris`는 정확한 문자열로 일치하지만, 루프백 주소는 어떤 포트와도 일치할 수 있습니다. [와일드카드 패턴](/integrate-logto/application-data-structure#wildcard-patterns)도 지원됩니다. +- `scope`, `grant_types`, `response_types`는 Logto에서 결정합니다. 문서에 선언되어 있어도 값은 무시됩니다. 동적 클라이언트는 인가 코드 플로우와 리프레시 토큰만 사용할 수 있습니다. + +Logto는 응답의 `Cache-Control` 및 `Expires` 헤더를 따라 최대 24시간 동안 문서를 캐시합니다. 문서를 얼마나 자주 업데이트할지에 따라 헤더를 설정하세요. + +## 동의 화면(Consent screen) \{#consent-screen} + +동적 클라이언트는 서드파티 애플리케이션이므로, [동의 화면](/end-user-flows/consent-screen)이 항상 표시됩니다. + +동의 화면에는 클라이언트가 등록되지 않았다는 안내도 표시됩니다. 클라이언트 이름과 로고는 메타데이터 문서에서 가져오기 때문에, 어떤 브랜드도 모방할 수 있습니다. 클라이언트 ID URL의 호스트도 함께 표시되며, 이는 클라이언트가 위조할 수 없는 유일한 부분입니다. + +## 인가 관리하기 \{#manage-authorizations} + +동적 클라이언트에 부여된 인가는 일반 서드파티 [grant](/sessions/grants-management)입니다. 사용자는 계정 설정에서 이를 검토하고 철회할 수 있으며, 관리자는 Management API를 통해 관리할 수 있습니다. 클라이언트 식별에는 client ID URL이 사용됩니다. + +동적 앱을 비활성화하면 새로운 인가 요청이 중단되지만, 기존 grant는 유지됩니다. grant를 철회하면 클라이언트는 다시 사용자 인가를 받아야 하며, 이전에 발급된 액세스 토큰은 만료될 때까지 유효할 수 있습니다. + +## 제한 사항 \{#limitations} + +- PKCE가 적용된 인가 코드 플로우와 리프레시 토큰만 지원됩니다. 클라이언트 자격 증명, 디바이스 플로우, 토큰 교환은 지원되지 않습니다. +- 권한 및 브랜딩은 클라이언트별로 설정할 수 없습니다. +- [앱 레벨 접근 제어](/authorization/app-level-access-control)는 동적 클라이언트에 적용되지 않습니다. 애플리케이션 레코드가 없기 때문입니다. + +## 관련 리소스 \{#related-resources} + +서드파티 앱 (OAuth / OIDC) + + MCP 서버에서 서드파티 AI 에이전트 접근 허용하기 + diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index 1651f7a5a3e..74470d36d49 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -2,23 +2,23 @@ sidebar_position: 2 --- -# 사용자 승인 앱 (권한) 관리 +# 사용자 인가 앱(그랜트) 관리 -앱 권한은 특정 클라이언트 애플리케이션에 대한 사용자 인가 상태를 나타냅니다. +앱 그랜트는 특정 클라이언트 애플리케이션에 대한 사용자 인가 상태를 나타냅니다. -사용자나 관리자가 승인된 앱을 검토하고 전체 Logto 세션을 취소하지 않고 앱 접근을 취소해야 할 때 권한 관리를 사용하세요. +사용자 또는 관리자가 인가된 앱을 검토하고 전체 Logto 세션을 해제하지 않고 앱 접근을 해제해야 할 때 그랜트 관리를 사용하세요. -권한이 취소되면, 해당 권한에 대해 이전에 발급된 불투명 액세스 토큰과 리프레시 토큰이 무효화됩니다. +그랜트가 해제되면, 해당 그랜트에 대해 이전에 발급된 불투명 토큰 (Opaque token) 액세스 토큰 및 리프레시 토큰은 무효화됩니다. JWT 액세스 토큰은 상태를 저장하지 않으므로, 이전에 발급된 토큰은 만료될 때까지 유효합니다. ## 올바른 경로 선택하기 \{#choose-the-right-path} -| 시나리오 | 권장 경로 | -| ------------------------------------------------------- | -------------- | -| 로그인한 사용자가 자신의 앱 인가를 관리하도록 허용 | Account API | -| 관리자나 지원 팀이 특정 사용자의 권한을 관리하도록 허용 | Management API | -| 운영자가 UI에서 타사 앱 인가를 관리하도록 허용 | Admin Console | +| 시나리오 | 권장 경로 | +| ----------------------------------------------------------- | -------------- | +| 로그인한 사용자가 자신의 앱 인가를 직접 관리하도록 허용 | Account API | +| 관리자 또는 지원팀이 특정 사용자의 그랜트를 관리하도록 허용 | Management API | +| 운영자가 UI에서 서드파티 앱 인가를 관리하도록 허용 | Admin Console | -## 직접 권한 관리 API \{#direct-grant-management-apis} +## 직접 그랜트 관리 API \{#direct-grant-management-apis} ### Account API (셀프 서비스) \{#account-api-self-service} @@ -26,46 +26,48 @@ sidebar_position: 2 - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` -- 참고: [사용자 승인 앱 (권한) 관리](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) +- 참고: [사용자 인가 앱(그랜트) 관리](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) -### Management API (관리 도구) \{#management-api-admin-tools} +### Management API (관리자 도구) \{#management-api-admin-tools} -관리 도구 및 지원 워크플로우에서 Management API를 사용하세요: +관리자 도구 및 지원 워크플로우에서 Management API를 사용하세요: - `GET /api/users/{userId}/grants` - `DELETE /api/users/{userId}/grants/{grantId}` -- 참고: [사용자 승인 앱 (권한) 관리](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) +- 참고: [사용자 인가 앱(그랜트) 관리](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) -### 앱 유형별 권한 목록 필터링 \{#filter-grant-list-by-app-type} +### 앱 유형별 그랜트 목록 필터링 \{#filter-grant-list-by-app-type} -권한 목록 엔드포인트는 선택적 쿼리 매개변수 `appType`을 지원합니다: +그랜트 목록 엔드포인트는 선택적 쿼리 파라미터 `appType`을 지원합니다: -- `appType=firstParty`: 퍼스트 파티 앱 권한만 나열합니다. -- `appType=thirdParty`: 타사 앱 권한만 나열합니다. -- `appType`을 생략: 모든 활성 권한을 반환합니다. +- `appType=firstParty`: 퍼스트파티 앱 그랜트만 나열합니다. +- `appType=thirdParty`: 서드파티 앱 그랜트만 나열합니다. +- `appType`을 생략: 모든 활성 그랜트를 반환합니다. -## 콘솔에서 타사 앱 인가 관리 \{#manage-third-party-app-authorizations-in-console} +[다이나믹 앱](/integrate-logto/third-party-applications/dynamic-apps) 클라이언트는 서드파티 애플리케이션이므로, 해당 그랜트는 `appType=thirdParty`로 반환됩니다. 클라이언트 ID URL이 애플리케이션 ID로 사용됩니다. -Logto Console에서 사용자 세부 정보 페이지를 사용하여 승인된 타사 앱을 보고 취소할 수 있습니다. +## Console에서 서드파티 앱 인가 관리하기 \{#manage-third-party-app-authorizations-in-console} -- 참고: [사용자 승인 타사 앱 관리](/user-management/manage-users#manage-user-authorized-third-party-apps) +Logto Console에서는 사용자 상세 페이지에서 인가된 서드파티 앱을 확인하고 해제할 수 있습니다. -## 세션 취소 시 권한 취소 \{#revoke-grants-when-revoking-a-session} +- 참고: [사용자 인가 서드파티 앱 관리](/user-management/manage-users#manage-user-authorized-third-party-apps) -`DELETE /api/my-account/sessions/{sessionId}`를 통해 세션을 취소할 때, 선택적 쿼리 매개변수 `revokeGrantsTarget`을 사용하여 권한 취소 범위를 제어하세요: +## 세션 해제 시 그랜트 해제하기 \{#revoke-grants-when-revoking-a-session} -- `all`: 세션과 관련된 모든 앱에 대한 권한을 취소합니다. -- `firstParty`: 퍼스트 파티 앱에 대한 권한만 취소합니다. +`DELETE /api/my-account/sessions/{sessionId}`로 세션을 해제할 때, 선택적 쿼리 파라미터 `revokeGrantsTarget`을 사용하여 그랜트 해제 범위를 제어할 수 있습니다: -세션 수준의 동작 및 엔드포인트 컨텍스트에 대해서는 [사용자 세션 관리](/sessions/manage-user-sessions) 및 [로그아웃](/end-user-flows/sign-out)을 참조하세요. +- `all`: 세션과 연관된 모든 앱의 그랜트를 해제합니다. +- `firstParty`: 퍼스트파티 앱의 그랜트만 해제합니다. + +세션 수준 동작 및 엔드포인트 맥락에 대해서는 [사용자 세션 관리](/sessions/manage-user-sessions) 및 [로그아웃](/end-user-flows/sign-out)을 참고하세요. ## 관련 리소스 \{#related-resources} 세션 사용자 세션 관리 - Account API에 의한 계정 설정: 사용자 승인 앱 (권한) 관리 + Account API로 계정 설정: 사용자 인가 앱(그랜트) 관리 - Management API에 의한 계정 설정: 사용자 승인 앱 (권한) 관리 + Management API로 계정 설정: 사용자 인가 앱(그랜트) 관리 diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index c71f72d5a14..f0c5694c40a 100644 --- a/i18n/ko/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/ko/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -2,48 +2,71 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- ## Logto에서 서드파티 AI 에이전트 구성하기 \{#configure-third-party-ai-agent-in-logto} -서드파티 AI 에이전트가 {props.serviceName ?? '귀하의 서비스'}에 접근할 수 있도록 하려면, Logto에서 **서드파티 앱**을 설정해야 합니다. 이 앱은 AI 에이전트를 대표하며, 인증 (Authentication) 및 인가 (Authorization)에 필요한 자격 증명을 얻는 데 사용됩니다. +서드파티 AI 에이전트가 {props.serviceName ?? '귀하의 서비스'}에 접근할 수 있도록 하려면, Logto에서 **서드파티 앱**을 설정해야 합니다. 이 앱은 AI 에이전트를 대표하며, 인증 (Authentication) 및 인가 (Authorization)에 필요한 자격 증명을 획득하는 데 사용됩니다. :::info[서드파티 앱이란?] -**서드파티 앱**은 외부 개발자(리소스 소유자가 아님)가 생성한 애플리케이션으로, 보호된 리소스에 접근하기 위해 사용자 동의가 필요합니다. 퍼스트파티 앱(자체 애플리케이션)과 달리, 서드파티 앱은 사용자의 데이터에 접근하기 전에 특정 권한을 승인하도록 요청하는 동의 화면을 표시합니다. 이를 통해 사용자는 외부 서비스와 어떤 데이터를 공유할지 직접 제어할 수 있습니다. +**서드파티 앱**은 외부 개발자(리소스 소유자가 아님)가 만든 애플리케이션으로, 보호된 리소스에 접근하기 위해 사용자 동의가 필요합니다. 퍼스트파티 앱(자신의 애플리케이션)과 달리, 서드파티 앱은 사용자의 데이터에 접근하기 전에 특정 권한을 승인하도록 요청하는 동의 화면을 표시합니다. 이를 통해 사용자는 외부 서비스와 어떤 데이터를 공유할지 제어할 수 있습니다. 자세한 내용은 [서드파티 애플리케이션](/integrate-logto/third-party-applications)을 참고하세요. ::: +AI 에이전트를 온보딩하는 방법은 세 가지가 있습니다: + +- [콘솔에서 수동으로 앱 생성](#manually-create-a-third-party-app-in-logto): 테스트 또는 몇몇 알려진 에이전트에 적합합니다. +- [Management API로 등록 서비스 구축](#allow-developers-to-create-third-party-apps-in-logto): 자격 증명 발급 대상을 직접 제어하고 싶을 때 사용합니다. +- [동적 앱 활성화](#let-any-ai-agent-connect-without-pre-registration): 사전 등록 없이 어떤 에이전트든 연결할 수 있도록 할 때 사용합니다. + ### 개발자가 Logto에서 서드파티 앱을 생성할 수 있도록 허용하기 \{#allow-developers-to-create-third-party-apps-in-logto} -마켓플레이스를 구축하거나 개발자가 Logto에서 서드파티 앱을 생성할 수 있도록 하려면, [Logto Management API](/integrate-logto/interact-with-management-api)를 활용하여 프로그래밍 방식으로 서드파티 앱을 생성할 수 있습니다. 이를 통해 개발자는 자신의 애플리케이션을 등록하고 인증 (Authentication)에 필요한 자격 증명을 얻을 수 있습니다. +마켓플레이스를 구축하거나 개발자가 Logto에서 서드파티 앱을 생성할 수 있도록 하려면, [Logto Management API](/integrate-logto/interact-with-management-api)를 활용하여 프로그래밍 방식으로 서드파티 앱을 생성할 수 있습니다. 이를 통해 개발자는 자신의 애플리케이션을 등록하고 인증 (Authentication)에 필요한 자격 증명을 획득할 수 있습니다. 클라이언트 등록 프로세스를 처리할 자체 서비스를 호스팅해야 합니다. 이 서비스는 Logto Management API와 상호작용하여 개발자를 대신해 서드파티 앱을 생성합니다. ```mermaid sequenceDiagram - actor 개발자 - participant Server as 앱 등록 서비스 + actor Developer + participant Server as 귀하의 앱 등록 서비스 participant Logto as Logto Management API - 개발자->>Server: 앱 등록 + Developer->>Server: 앱 등록 Server->>Logto: 앱 생성 Logto->>Server: 앱 ID, 시크릿 등 - Server->>개발자: 앱 ID, 시크릿 등 + Server->>Developer: 앱 ID, 시크릿 등 +``` + +또는, Logto 콘솔에서 수동으로 서드파티 앱을 생성하여 프로세스를 익힐 수도 있습니다. + +### 사전 등록 없이 어떤 AI 에이전트든 연결 허용하기 \{#let-any-ai-agent-connect-without-pre-registration} + +오픈 MCP 생태계에서는 사전에 에이전트를 알 수 없는 경우가 많습니다. [동적 앱](/integrate-logto/third-party-applications/dynamic-apps)은 등록 단계를 제거합니다: 에이전트는 자신의 클라이언트 메타데이터 문서를 제공하는 공개 HTTPS URL을 `client_id`로 사용하고, Logto는 인가 (Authorization) 요청이 도착하면 이를 확인합니다. + +```mermaid +sequenceDiagram + participant Agent as AI 에이전트 (MCP 클라이언트) + participant Logto + participant Metadata as 에이전트의 메타데이터 문서 URL + Agent->>Logto: 클라이언트 ID URL로 인가 요청 + Logto->>Metadata: 클라이언트 ID 메타데이터 문서 가져오기 + Metadata->>Logto: 클라이언트 이름, 로고, 리디렉션 URI 등 + Logto->>Agent: 동의 화면, 이후 인가 코드 ``` -또는, Logto 콘솔에서 직접 서드파티 앱을 수동으로 생성하여 프로세스를 익힐 수도 있습니다. +여전히 동적 앱에 부여된 권한을 통해 에이전트가 요청할 수 있는 범위를 제어할 수 있으며, 모든 인가 (Authorization)는 사용자 동의 화면을 거칩니다. ### Logto에서 서드파티 앱을 수동으로 생성하기 \{#manually-create-a-third-party-app-in-logto} -테스트 목적이나 임시 통합을 위해 Logto 콘솔에서 서드파티 앱을 수동으로 생성할 수 있습니다. 전체 클라이언트 등록 플로우를 구현하지 않고도 통합을 빠르게 테스트하고 싶을 때 유용합니다. +테스트 목적이나 임시 통합을 위해 Logto 콘솔에서 서드파티 앱을 수동으로 생성할 수 있습니다. 전체 클라이언트 등록 플로우를 구현하지 않고 빠르게 통합을 테스트하고 싶을 때 유용합니다. 1. Logto 콘솔에 로그인하세요. 2. **애플리케이션** → **애플리케이션 생성** → **서드파티 - 앱** -> **OIDC**로 이동하세요. + 앱** -> **OIDC**를 선택하세요. 3. 앱 이름 및 기타 필수 항목을 입력한 후 **애플리케이션 생성**을 클릭하세요. 4. **권한** 탭을 클릭하고, **사용자** 섹션에서 "추가"를 클릭하세요. 5. 열린 대화상자에서 -> **사용자 데이터** -> **`profile`**, **`email`** 권한을 선택한 후 **저장**을 클릭하세요. -6. 서드파티 앱에서 `openid profile email` 권한(스코프)을 요청하도록 스코프를 구성하세요. +6. 서드파티 앱에서 `openid profile email` 권한(스코프)을 요청하도록 스코프를 설정하세요. - **참고**: `openid`는 OIDC에 필수이며, `profile`과 `email`은 이전 단계에서 추가한 권한입니다. + **참고**: OIDC를 위해서는 `openid`가 필수이며, `profile`과 `email`은 이전 단계에서 추가한 권한입니다. -7. 서드파티 애플리케이션의 **리디렉션 URI**를 적절히 구성하세요. Logto에서도 리디렉션 URI를 반드시 업데이트해야 합니다. +7. 서드파티 애플리케이션의 **리디렉션 URI**를 적절히 설정하세요. Logto에서도 리디렉션 URI를 반드시 업데이트해야 합니다. Console > Aplicativos. 2. Abra o aplicativo que deseja restringir. @@ -62,7 +62,7 @@ Por exemplo, se um aplicativo tiver tanto uma regra de papel de usuário "Equipe 8. Clique em **Salvar alterações**. :::important -Você deve configurar pelo menos uma regra de permissão antes de habilitar o controle de acesso. Isso evita habilitar acidentalmente o controle de acesso sem nenhum usuário autorizado a acessar o aplicativo. +Você deve configurar pelo menos uma regra de permissão antes de habilitar o controle de acesso. Isso evita ativar acidentalmente o controle de acesso sem nenhum usuário autorizado a acessar o aplicativo. ::: ## Editar ou remover regras \{#edit-or-remove-rules} @@ -70,10 +70,10 @@ Você deve configurar pelo menos uma regra de permissão antes de habilitar o co Você pode atualizar a lista de permissões na guia **Regras** do aplicativo. - Para adicionar mais regras, clique em **Adicionar outra** abaixo da tabela de regras. -- Para remover uma regra, clique no botão de exclusão na linha da regra e confirme a ação. +- Para remover uma regra, clique no botão de excluir na linha da regra e confirme a ação. - Após adicionar ou remover regras, clique em **Salvar alterações** para aplicar a atualização. -Se o controle de acesso estiver ativado, o Logto exige que pelo menos uma regra permaneça configurada. Para remover todas as regras, desative primeiro **Habilitar controle de acesso** e depois salve as alterações. +Se o controle de acesso estiver ativado, o Logto exige que pelo menos uma regra permaneça configurada. Para remover todas as regras, desative **Habilitar controle de acesso** primeiro e depois salve as alterações. ## Como as alterações nas regras afetam os usuários \{#how-rule-changes-affect-users} @@ -82,7 +82,7 @@ O controle de acesso ao nível do aplicativo não encerra a sessão global do us Para o aplicativo que está sendo restringido: - Um usuário que não corresponder mais a nenhuma regra de permissão será bloqueado na próxima vez que passar pelo fluxo de autorização do aplicativo. -- Se o usuário já tiver permissões relacionadas ao aplicativo, o Logto verifica as regras novamente quando o aplicativo usa um token de atualização para solicitar novos tokens. Se o usuário não tiver mais acesso, o Logto nega a solicitação de token. +- Se o usuário já tiver permissões relacionadas ao app, o Logto verifica as regras novamente quando o aplicativo usa um token de atualização para solicitar novos tokens. Se o usuário não tiver mais acesso, o Logto nega a solicitação de token. Isso mantém as decisões de acesso vinculadas ao aplicativo, evitando interrupções desnecessárias em aplicativos não relacionados. @@ -90,21 +90,25 @@ Isso mantém as decisões de acesso vinculadas ao aplicativo, evitando interrup Para [aplicativos de terceiros](/integrate-logto/third-party-applications), o controle de acesso ao nível do aplicativo e o gerenciamento de permissões resolvem problemas diferentes: -- **Controle de acesso ao nível do aplicativo** determina se um usuário tem permissão para fazer login no aplicativo de terceiros. +- **Controle de acesso ao nível do aplicativo** determina se um usuário pode fazer login no aplicativo de terceiros. - **Gerenciamento de permissões** determina quais escopos de perfil de usuário, escopos de recursos de API e escopos de organização o aplicativo de terceiros pode solicitar na tela de consentimento. Se ambos estiverem configurados, o usuário deve passar pelo controle de acesso ao nível do aplicativo antes de autorizar o aplicativo de terceiros. +:::note +O controle de acesso ao nível do aplicativo se aplica apenas a aplicativos registrados. Clientes [aplicativos dinâmicos](/integrate-logto/third-party-applications/dynamic-apps) não possuem registro de aplicativo, portanto não podem ser restringidos dessa forma. O acesso deles é limitado pelas permissões que você concede ao aplicativo dinâmico e pelo consentimento do usuário. +::: + ## Relação com Aplicativo Protegido \{#relationship-with-protected-app} Para [Aplicativo Protegido](/integrate-logto/protected-app), o controle de acesso ao nível do aplicativo restringe quem pode passar pela camada de autenticação do Logto e alcançar o servidor de origem protegido. -As regras de autenticação do Aplicativo Protegido ainda determinam quais rotas exigem autenticação. O controle de acesso ao nível do aplicativo determina quais usuários autenticados do Logto têm permissão para acessar o aplicativo Aplicativo Protegido. +As regras de autenticação do Aplicativo Protegido ainda determinam quais rotas exigem autenticação. O controle de acesso ao nível do aplicativo determina quais usuários autenticados do Logto podem acessar o aplicativo Aplicativo Protegido. -## Melhores práticas \{#best-practices} +## Boas práticas \{#best-practices} -- Comece com regras de papel de usuário ou papel de organização sempre que possível. Elas são mais fáceis de manter do que listas longas de usuários individuais. +- Comece com regras de papel de usuário ou papel de organização sempre que possível. Elas são mais fáceis de manter do que longas listas de usuários individuais. - Use regras de organização quando todos em uma organização devem acessar o app. - Use regras de papel de organização quando apenas membros específicos de uma organização devem acessar o app. -- Revise as regras de acesso quando usuários mudarem de papel, entrarem em organizações ou saírem de organizações. +- Revise as regras de acesso quando usuários mudarem de papel, entrarem ou saírem de organizações. - Mantenha as permissões RBAC e o controle de acesso ao nível do aplicativo separados em seu modelo mental: o controle de acesso ao nível do aplicativo responde "Este usuário pode acessar este app?", enquanto o RBAC responde "O que este usuário pode fazer após acessar APIs ou recursos da organização?" diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index afcf3ed37fc..12401b3ff4f 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -22,8 +22,8 @@ Nos valores padrão, `protocol` será `http` ou `https` de acordo com sua config | Key | Valor padrão | Tipo | Descrição | | -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | NODE_ENV | `undefined` | 'production' | 'test' | undefined | Qual tipo de ambiente em que o Logto está rodando. | -| PORT | `3001` | `number` | A porta local que o Logto escuta. | -| ADMIN_PORT | `3002` | `number` | A porta local que o Logto Admin Console escuta. | +| PORT | `3001` | `number` | A porta local na qual o Logto escuta. | +| ADMIN_PORT | `3002` | `number` | A porta local na qual o Logto Admin Console escuta. | | ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Defina como `1` ou `true` para desabilitar a porta do Admin Console. Com `ADMIN_ENDPOINT` não definido, irá desabilitar completamente o Admin Console. | | DB_URL | N/A | `string` | O [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6) para o banco de dados do Logto. | | DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) `statement_timeout` do PostgreSQL em milissegundos. Use uma string numérica (ex: `5000`) para definir, ou `DISABLE_TIMEOUT` para omitir o parâmetro de inicialização (recomendado para PgBouncer/RDS Proxy). Se não definido ou inválido, o padrão do cliente é 60000 ms. | @@ -34,18 +34,20 @@ Nos valores padrão, `protocol` será `http` ou `https` de acordo com sua config | ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | Você pode especificar uma URL com seu domínio personalizado para produção (Ex: `ADMIN_ENDPOINT=https://admin.dominio.com`). Isso também afetará o valor dos URIs de redirecionamento do Admin Console. | | CASE_SENSITIVE_USERNAME | `true` | `boolean` | Especifica se o nome de usuário diferencia maiúsculas de minúsculas. Tenha cautela ao modificar este valor; alterações não ajustarão automaticamente os dados existentes no banco de dados, exigindo gerenciamento manual. | | SECRET_VAULT_KEK | `undefined` | `string` | A Key Encryption Key (KEK) usada para criptografar as Data Encryption Keys (DEK) no [Secret Vault](/secret-vault). Necessária para o funcionamento adequado do Secret Vault. Deve ser uma string codificada em base64. Recomenda-se AES-256 (32 bytes). Exemplo: `crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | Período de carência em segundos para rotação de chave privada OIDC em estágio. Quando definido para um valor positivo, a nova chave privada é criada como `Next` primeiro e só se torna efetiva após o período de carência. | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | Período de carência em segundos para rotação de chave privada OIDC em estágio. Quando definido como um valor positivo, a nova chave privada é criada como `Next` primeiro e só se torna efetiva após o período de carência. | | OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | Apenas para auto-hospedado. Defina como `true` apenas quando endpoints confiáveis de relying-party OIDC precisarem resolver para endereços de rede privada. Veja [Proteção SSRF do provedor OIDC](#oidc-provider-ssrf-protection). | ### Proteção SSRF do provedor OIDC {#oidc-provider-ssrf-protection} -O Logto protege as requisições de saída do provedor OIDC contra server-side request forgery (SSRF) por padrão. Requisições para endereços de uso especial, incluindo loopback e endereços de rede privada, são bloqueadas. Essa proteção cobre endpoints de relying-party como URIs de logout back-channel, `jwks_uri` e `sector_identifier_uri`. +O Logto protege as requisições de saída do provedor OIDC contra server-side request forgery (SSRF) por padrão. Requisições para endereços de uso especial, incluindo loopback e endereços de rede privada, são bloqueadas. Essa proteção cobre endpoints de relying-party como URIs de logout back-channel, `jwks_uri` e `sector_identifier_uri`, assim como os documentos de metadados de client ID buscados para [aplicativo dinâmico](/integrate-logto/third-party-applications/dynamic-apps). -Se sua implantação auto-hospedada precisar intencionalmente acessar um endpoint confiável de relying-party em uma rede privada, defina `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` e reinicie todas as instâncias do Logto. +Se sua implantação auto-hospedada precisar intencionalmente acessar um endpoint confiável de relying-party em uma rede privada, defina `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` e reinicie cada instância do Logto. :::caution -Esta configuração desabilita a proteção SSRF para todas as requisições de saída do provedor OIDC, não apenas para um endpoint. Só desative se todos os endpoints de relying-party configurados forem confiáveis e seus controles de rede impedirem acesso a serviços internos sensíveis. +Esta configuração desativa a proteção SSRF para todas as requisições de saída do provedor OIDC, não apenas para um endpoint. Só desative se todos os endpoints de relying-party configurados forem confiáveis e seus controles de rede impedirem o acesso a serviços internos sensíveis. + +[Aplicativo dinâmico](/integrate-logto/third-party-applications/dynamic-apps) não pode ser habilitado enquanto essa proteção estiver desativada, pois busca documentos de metadados de URLs fornecidos pelos próprios clientes. ::: @@ -63,7 +65,7 @@ Outra prática comum é ter um proxy HTTPS na frente do Node (Ex: Nginx). Nesse caso, provavelmente você vai querer definir `TRUST_PROXY_HEADER` como `true`, o que indica se os campos de cabeçalho do proxy devem ser confiáveis. O Logto irá passar o valor para as [configurações do app Koa](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings). -Veja [Confiando em proxies de descarregamento TLS](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies) para saber quando configurar este campo. +Veja [Confiando em proxies de TLS offloading](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies) para saber quando configurar este campo. ## Configurações do banco de dados {#database-configs} diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index e419b818b5a..9526bb8a642 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -24,9 +24,13 @@ Da mesma forma, no Logto, quando o Logto funciona como IdP, a tela de consentime Consent screen Logto as IdP +### Clientes não registrados (dinâmicos) \{#unregistered-dynamic-clients} + +Se o [aplicativo dinâmico](/integrate-logto/third-party-applications/dynamic-apps) estiver habilitado, clientes podem se conectar ao seu tenant sem pré-registro. Para esses clientes, a tela de consentimento exibe um aviso adicional, juntamente com o host da URL do client ID. O nome e o logotipo do cliente vêm do próprio documento de metadados do cliente, então eles podem imitar qualquer marca, enquanto o host não pode ser falsificado. + ## Como configurar a tela de consentimento? \{#how-to-configure-the-consent-screen} -O fluxo de consentimento do Logto permite autorizar logins de aplicativos de terceiros. Você pode personalizar a marca e as solicitações de permissão para cada aplicativo de terceiros OIDC. +O fluxo de consentimento do Logto permite autorizar logins de aplicativos de terceiros. Você pode personalizar a marca e os pedidos de permissão para cada aplicativo de terceiros OIDC. Saiba mais sobre como configurar o [aplicativo de terceiros](/integrate-logto/third-party-applications/) e configurar a [tela de consentimento](/integrate-logto/third-party-applications/consent-screen-branding/) no Logto. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index f617737b37f..e913545fd10 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -7,7 +7,7 @@ sidebar_position: 7 ## Introdução \{#introduction} -No Logto, um _aplicativo_ refere-se a um programa de software ou serviço específico que está registrado na plataforma Logto e recebeu autorização para acessar informações do usuário ou realizar ações em nome de um usuário. Os aplicativos são usados para identificar a origem das solicitações feitas à API do Logto, bem como para gerenciar o processo de autenticação e autorização para usuários que acessam esses aplicativos. +No Logto, um _aplicativo_ refere-se a um programa de software ou serviço específico que está registrado na plataforma Logto e recebeu autorização para acessar informações do usuário ou realizar ações em nome de um usuário. Aplicativos são usados para identificar a origem das solicitações feitas à API do Logto, bem como para gerenciar o processo de autenticação e autorização para usuários que acessam esses aplicativos. O uso de aplicativos na experiência de login do Logto permite que os usuários acessem e gerenciem facilmente seus aplicativos autorizados a partir de um único local, com um processo de autenticação consistente e seguro. Isso ajuda a simplificar a experiência do usuário e garante que apenas pessoas autorizadas estejam acessando informações sensíveis ou realizando ações em nome da organização. @@ -20,27 +20,31 @@ Se você deseja integrar seu aplicativo ao Logto, veja [Integrar Logto](/integra _O ID do aplicativo_ é uma chave única gerada automaticamente para identificar seu aplicativo no Logto, e é referenciado como [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) no OAuth 2.0. +:::note +Clientes [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) não são registrados no Logto. O client ID deles é uma URL HTTPS pública de propriedade do cliente, que serve o documento de metadados do cliente. +::: + ### Tipos de aplicativo \{#application-types} Um _aplicativo_ pode ser um dos seguintes tipos de aplicativo: -- **Aplicativo nativo** é um aplicativo que roda em um ambiente nativo. Ex.: aplicativo iOS, aplicativo Android. - - **Aplicativo de fluxo de dispositivo** é um tipo especial de aplicativo nativo para dispositivos com entrada limitada ou aplicativos sem interface (ex.: smart TVs, consoles de jogos, ferramentas CLI, dispositivos IoT). Ele utiliza o [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) em vez do fluxo padrão baseado em redirecionamento. Veja [Início rápido do fluxo de dispositivo](/quick-starts/device-flow) para detalhes. -- **Aplicativo de página única (SPA)** é um aplicativo que roda em um navegador web, atualizando a página com novos dados do servidor sem carregar páginas inteiras. Ex.: aplicativo React DOM, aplicativo Vue. -- **Aplicativo web tradicional** é um aplicativo que renderiza e atualiza páginas apenas pelo servidor web. Ex.: JSP, PHP. +- **Aplicativo nativo** é um app que roda em um ambiente nativo. Ex.: app iOS, app Android. + - **Aplicativo de device flow** é um tipo especial de aplicativo nativo para dispositivos com entrada limitada ou aplicativos sem interface (ex.: smart TVs, consoles de jogos, ferramentas CLI, dispositivos IoT). Ele usa o [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) em vez do fluxo padrão baseado em redirecionamento. Veja [Device flow quick start](/quick-starts/device-flow) para detalhes. +- **Aplicativo de página única (Single page app)** é um app que roda em um navegador web, que atualiza a página com novos dados do servidor sem recarregar páginas inteiras. Ex.: app React DOM, app Vue. +- **Aplicativo web tradicional** é um app que renderiza e atualiza páginas apenas pelo servidor web. Ex.: JSP, PHP. - **Aplicativo máquina para máquina (M2M)** é um aplicativo que roda em um ambiente de máquina para comunicação direta entre serviços, sem interação do usuário. ### Segredo do aplicativo \{#application-secret} -_O segredo do aplicativo_ é uma chave usada para autenticar o aplicativo no sistema de autenticação, especificamente para clientes privados (aplicativos Web Tradicional e M2M) como uma barreira de segurança privada. +_O segredo do aplicativo_ é uma chave usada para autenticar o aplicativo no sistema de autenticação, especificamente para clientes privados (aplicativos Web tradicionais e M2M) como uma barreira de segurança privada. :::tip -Aplicativos de Página Única (SPAs) e aplicativos Nativos não fornecem segredo do aplicativo. SPAs e aplicativos Nativos são "clientes públicos" e não podem manter segredos (o código do navegador ou os pacotes do aplicativo podem ser inspecionados). Em vez de um segredo do aplicativo, o Logto os protege com PKCE, validação rigorosa de URI de redirecionamento / CORS, tokens de acesso de curta duração e rotação de token de atualização. +Single Page Apps (SPAs) e aplicativos nativos não fornecem segredo do app. SPAs e aplicativos nativos são "clientes públicos" e não podem manter segredos (o código do navegador ou os pacotes do app podem ser inspecionados). Em vez de um segredo do app, o Logto os protege com PKCE, validação rigorosa de URI de redirecionamento / CORS, tokens de acesso de curta duração e rotação de token de atualização. ::: ### Nome do aplicativo \{#application-name} -_O nome do aplicativo_ é um nome legível por humanos do aplicativo e será exibido no console de administração. +_Nome do aplicativo_ é o nome legível por humanos do aplicativo e será exibido no console de administração. O _nome do aplicativo_ é um componente importante para o gerenciamento de aplicativos no Logto, pois permite que os administradores identifiquem e acompanhem facilmente a atividade de aplicativos individuais dentro da plataforma. @@ -50,13 +54,13 @@ O _nome do aplicativo_ é um componente importante para o gerenciamento de aplic ### Descrição \{#description} -Uma breve descrição do aplicativo será exibida na página de detalhes do aplicativo no console de administração. A descrição tem como objetivo fornecer aos administradores informações adicionais sobre o aplicativo, como seu propósito, funcionalidade e quaisquer outros detalhes relevantes. +Uma breve descrição do aplicativo será exibida na página de detalhes do aplicativo no console de administração. A descrição tem como objetivo fornecer aos administradores informações adicionais sobre o aplicativo, como seu propósito, funcionalidade e outros detalhes relevantes. ### URIs de redirecionamento \{#redirect-uris} -_URIs de redirecionamento_ são uma lista de URIs de redirecionamento válidas que foram pré-configuradas para um aplicativo. Quando um usuário faz login no Logto e tenta acessar o aplicativo, ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo. +_URIs de redirecionamento_ são uma lista de URIs de redirecionamento válidos que foram pré-configurados para um aplicativo. Quando um usuário faz login no Logto e tenta acessar o aplicativo, ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo. -A lista de URIs permitidas é usada para validar o URI de redirecionamento incluído na solicitação de autorização enviada pelo aplicativo ao Logto durante o processo de autenticação. Se o URI de redirecionamento especificado na solicitação de autorização corresponder a um dos URIs permitidos nas configurações do aplicativo, o usuário será redirecionado para esse URI após a autenticação bem-sucedida. Se o URI de redirecionamento não estiver na lista permitida, o usuário não será redirecionado e o processo de autenticação falhará. +A lista de URIs permitidos é usada para validar o URI de redirecionamento incluído na solicitação de autorização enviada pelo aplicativo ao Logto durante o processo de autenticação. Se o URI de redirecionamento especificado na solicitação de autorização corresponder a um dos URIs permitidos nas configurações do aplicativo, o usuário será redirecionado para esse URI após a autenticação bem-sucedida. Se o URI de redirecionamento não estiver na lista permitida, o usuário não será redirecionado e o processo de autenticação falhará. :::note É importante garantir que todos os URIs de redirecionamento válidos sejam adicionados à lista permitida para um aplicativo no Logto, para garantir que os usuários possam acessar o aplicativo com sucesso após a autenticação. @@ -65,14 +69,14 @@ A lista de URIs permitidas é usada para validar o URI de redirecionamento inclu Você pode conferir o [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) para mais informações. - Compreendendo URIs de redirecionamento em OIDC com Authorization Code Flow + Entendendo URIs de redirecionamento em OIDC com Authorization Code Flow #### Padrões curinga \{#wildcard-patterns} -_Disponibilidade: Aplicativo de página única, Aplicativo web tradicional_ +_Disponibilidade: Single page app, Aplicativo web tradicional_ -URIs de redirecionamento suportam padrões curinga (`*`) para ambientes dinâmicos, como implantações de preview. Curingas podem ser usados nos componentes de hostname e pathname de URIs HTTP / HTTPS. +URIs de redirecionamento suportam padrões curinga (`*`) para ambientes dinâmicos, como implantações de preview. Curingas podem ser usados nos componentes de hostname e pathname de URIs HTTP/HTTPS. **Regras:** @@ -90,21 +94,21 @@ URIs de redirecionamento suportam padrões curinga (`*`) para ambientes dinâmic URIs de redirecionamento curinga não são padrão OIDC e podem aumentar a superfície de ataque. Use com cuidado e prefira URIs de redirecionamento exatos sempre que possível. ::: -### URIs de redirecionamento pós-logout \{#post-sign-out-redirect-uris} +### URIs de redirecionamento pós logout \{#post-sign-out-redirect-uris} -_URIs de redirecionamento pós-logout_ são uma lista de URIs válidas que foram pré-configuradas para um aplicativo redirecionar o usuário após ele sair do Logto. +_URIs de redirecionamento pós logout_ são uma lista de URIs válidos que foram pré-configurados para um aplicativo redirecionar o usuário após ele sair do Logto. -O uso de _URIs de redirecionamento pós-logout_ permitidas para logout faz parte da especificação de Logout Iniciado pela RP (Relying Party Initiated) no OIDC. Essa especificação fornece um método padronizado para aplicativos iniciarem uma solicitação de logout para um usuário, que inclui redirecionar o usuário para um endpoint pré-configurado após ele sair. +O uso de _URIs de redirecionamento pós logout_ permitidos para logout faz parte da especificação de logout iniciado pela RP (Relying Party Initiated) no OIDC. Essa especificação fornece um método padronizado para aplicativos iniciarem uma solicitação de logout para um usuário, que inclui redirecionar o usuário para um endpoint pré-configurado após ele sair. -Quando um usuário sai do Logto, sua sessão é encerrada e ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo. Isso garante que o usuário seja direcionado apenas para endpoints autorizados e válidos após sair, ajudando a evitar acessos não autorizados e riscos de segurança associados ao redirecionamento de usuários para endpoints desconhecidos ou não verificados. +Quando um usuário faz logout do Logto, sua sessão é encerrada e ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo. Isso garante que o usuário seja direcionado apenas para endpoints autorizados e válidos após sair, ajudando a evitar acessos não autorizados e riscos de segurança associados ao redirecionamento de usuários para endpoints desconhecidos ou não verificados. Você pode conferir o [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) para mais informações. -### Origens permitidas para CORS \{#cors-allowed-origins} +### Origens permitidas CORS \{#cors-allowed-origins} -_As origens permitidas para CORS (Cross-origin resource sharing)_ são uma lista de origens permitidas a partir das quais um aplicativo pode fazer solicitações ao serviço Logto. Qualquer origem que não esteja incluída na lista permitida não poderá fazer solicitações ao serviço Logto. +_As origens permitidas de CORS (Cross-origin resource sharing)_ são uma lista de origens permitidas a partir das quais um aplicativo pode fazer solicitações ao serviço Logto. Qualquer origem que não esteja incluída na lista permitida não poderá fazer solicitações ao serviço Logto. -A lista de origens permitidas para CORS é usada para restringir o acesso ao serviço Logto a partir de domínios não autorizados e para ajudar a prevenir ataques de falsificação de solicitação entre sites (CSRF). Ao especificar as origens permitidas para um aplicativo no Logto, o serviço pode garantir que apenas domínios autorizados possam fazer solicitações ao serviço. +A lista de origens permitidas CORS é usada para restringir o acesso ao serviço Logto a partir de domínios não autorizados e para ajudar a prevenir ataques de falsificação de solicitação entre sites (CSRF). Ao especificar as origens permitidas para um aplicativo no Logto, o serviço pode garantir que apenas domínios autorizados possam fazer solicitações ao serviço. :::note A lista de origens permitidas deve conter a origem onde o aplicativo será servido. Isso garante que as solicitações do aplicativo sejam permitidas, enquanto solicitações de origens não autorizadas sejam bloqueadas. @@ -116,7 +120,7 @@ O endpoint para [OpenID Connect Discovery](https://openid.net/specs/openid-conne ### Endpoint de autorização \{#authorization-endpoint} -_Endpoint de autorização_ é um termo OIDC, e é um endpoint obrigatório usado para iniciar o processo de autenticação de um usuário. Quando um usuário tenta acessar um recurso protegido ou aplicativo registrado na plataforma Logto, ele será redirecionado para o _Endpoint de autorização_ para autenticar sua identidade e obter autorização para acessar o recurso solicitado. +_Endpoint de autorização_ é um termo OIDC, e é um endpoint obrigatório usado para iniciar o processo de autenticação de um usuário. Quando um usuário tenta acessar um recurso protegido ou aplicativo registrado na plataforma Logto, ele será redirecionado para o _endpoint de autorização_ para autenticar sua identidade e obter autorização para acessar o recurso solicitado. Você pode conferir o [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) para mais informações. @@ -124,19 +128,19 @@ Você pode conferir o [Authorization Endpoint](https://openid.net/specs/openid-c _Endpoint de token_ é um termo OIDC, é um endpoint de API web usado por um cliente OIDC para obter um token de acesso, um token de ID ou um token de atualização de um provedor OIDC. -Quando um cliente OIDC precisa obter um token de acesso ou token de ID, ele envia uma solicitação ao Endpoint de Token com uma concessão de autorização, que normalmente é um código de autorização ou um token de atualização. O Endpoint de Token então valida a concessão de autorização e emite um token de acesso ou token de ID para o cliente se a concessão for válida. +Quando um cliente OIDC precisa obter um token de acesso ou token de ID, ele envia uma solicitação ao endpoint de token com uma concessão de autorização, que normalmente é um código de autorização ou um token de atualização. O endpoint de token então valida a concessão de autorização e emite um token de acesso ou token de ID para o cliente se a concessão for válida. Você pode conferir o [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) para mais informações. -### Endpoint Userinfo \{#userinfo-endpoint} +### Endpoint userinfo \{#userinfo-endpoint} -O [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) do OpenID Connect. +O endpoint [UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) do OpenID Connect. ### Sempre emitir token de atualização \{#always-issue-refresh-token} _Disponibilidade: Web tradicional, SPA_ -Quando ativado, o Logto sempre emitirá tokens de atualização, independentemente de `prompt=consent` estar presente na solicitação de autenticação ou `offline_access` estar presente nos escopos. +Quando ativado, o Logto sempre emitirá tokens de atualização, independentemente de `prompt=consent` estar presente na solicitação de autenticação, ou `offline_access` estar presente nos escopos. No entanto, essa prática é desencorajada, a menos que seja necessário (geralmente é útil para algumas integrações OAuth de terceiros que exigem token de atualização), pois não é compatível com OpenID Connect e pode causar problemas. @@ -146,8 +150,8 @@ _Padrão: `true`_ Quando ativado, o Logto pode emitir um novo token de atualização quando um cliente usa um token de atualização para solicitar novos tokens. Se o token de atualização e sua concessão de aplicativo ainda forem válidos, a política padrão de rotação é: -- Tokens de atualização podem ser rotacionados apenas antes que a cadeia de tokens de atualização exista por um ano. Este é um limite interno de segurança de rotação; o próprio TTL do token de atualização ou o TTL da concessão do aplicativo podem expirar antes. Após atingir o limite, o Logto não rotaciona mais o token de atualização, e a expiração do token de atualização atual é final. -- Para clientes públicos que não usam tokens de atualização vinculados ao remetente (por exemplo, aplicativos Nativos regulares e aplicativos de página única), o Logto rotaciona o token de atualização em cada solicitação de token de atualização enquanto a rotação é permitida. +- Tokens de atualização podem ser rotacionados apenas antes que a cadeia de tokens de atualização exista por um ano. Este é um limite interno de segurança de rotação; o próprio TTL do token de atualização ou o TTL da concessão do app podem expirar antes. Após atingir o limite, o Logto não rotaciona mais o token de atualização, e a expiração do token de atualização atual é final. +- Para clientes públicos que não usam tokens de atualização vinculados ao remetente (por exemplo, aplicativos nativos regulares e single page apps), o Logto rotaciona o token de atualização em cada solicitação de token de atualização enquanto a rotação for permitida. - Para outros clientes, o Logto rotaciona o token de atualização apenas quando ele está próximo da expiração (>=70% do seu Tempo de Vida (TTL) original já passou). :::note @@ -156,32 +160,32 @@ Para clientes públicos, é altamente recomendado manter a rotação de token de Tokens de atualização vinculados ao remetente são associados a uma chave de prova ou certificado mantido pelo cliente. Para SPAs regulares, a rotação emite um novo token de atualização, mas não estende o tempo de vida do token de atualização. O novo token de atualização herda o TTL restante do token de atualização anterior. ::: -:::caution Tempo de vida da cadeia de token de atualização +:::caution Tempo de vida da cadeia de tokens de atualização Tokens de atualização estão associados a uma concessão de aplicativo. O TTL padrão da concessão Logto é **180 dias**. Quando a concessão expira, as solicitações de token de atualização falham e o token de atualização não pode mais ser usado para obter novos tokens, mesmo que a rotação de token de atualização esteja ativada. Isso significa que o tempo de vida máximo prático de uma autorização baseada em token de atualização está atualmente limitado pelo TTL da concessão, revogação explícita ou expiração do próprio token de atualização, o que ocorrer primeiro. ::: - Compreendendo a rotação de token de atualização + Entendendo a rotação de token de atualização ### Tempo de vida (TTL) do token de atualização em dias \{#refresh-token-time-to-live-ttl-in-days} _Disponibilidade: Aplicativo nativo, Web tradicional, SPA; Padrão: 14 dias; Máximo: 180 dias_ -A duração pela qual um token de atualização pode ser usado para solicitar novos tokens de acesso antes de expirar e se tornar inválido. As solicitações de token estenderão o TTL do token de atualização para esse valor. +A duração pela qual um token de atualização pode ser usado para solicitar novos tokens de acesso antes de expirar e se tornar inválido. Solicitações de token estenderão o TTL do token de atualização para esse valor. Normalmente, um valor menor é preferido. :::note -A atualização do TTL não está disponível em aplicativos de página única (SPAs) por motivos de segurança. Para SPAs, essa configuração controla o tempo de vida fixo do token de atualização a partir do momento da emissão original. O Logto não estenderá o TTL por meio de solicitações de token, e a rotação de token de atualização não impede que tokens de atualização de SPA expirem. +A atualização do TTL não está disponível em single-page applications (SPAs) por motivos de segurança. Para SPAs, essa configuração controla o tempo de vida fixo do token de atualização a partir do momento da emissão original. O Logto não estenderá o TTL por meio de solicitações de token, e a rotação de token de atualização não impede que tokens de atualização de SPA expirem. ::: :::caution TTL do token de atualização e TTL da concessão -O TTL do token de atualização não é o único limite de expiração. Tokens de atualização estão vinculados a uma concessão de aplicativo, e o TTL padrão da concessão Logto é **180 dias**. Quando a concessão expira, as solicitações de token de atualização falham mesmo que o token de atualização ainda esteja válido. +O TTL do token de atualização não é o único limite de expiração. Tokens de atualização estão vinculados a uma concessão de aplicativo, e o TTL padrão da concessão Logto é **180 dias**. Quando a concessão expira, as solicitações de token de atualização falham mesmo que o token de atualização ainda seja válido. -Para clientes onde as solicitações de token renovam o TTL do token de atualização, o TTL da concessão atua como o tempo de vida máximo absoluto para a cadeia de token de atualização. Para SPAs, o TTL fixo do token de atualização pode expirar antes da concessão. +Para clientes onde as solicitações de token renovam o TTL do token de atualização, o TTL da concessão atua como o tempo de vida máximo absoluto para a cadeia de tokens de atualização. Para SPAs, o TTL fixo do token de atualização pode expirar antes da concessão. ::: :::caution Token de atualização e vinculação de sessão @@ -192,16 +196,16 @@ Para garantir que a configuração de TTL do token de atualização tenha efeito ### URI de logout backchannel \{#backchannel-logout-uri} -O endpoint de logout backchannel do OpenID Connect. Veja [Logout federado: Logout back-channel](#) para mais informações. +O endpoint de logout backchannel do OpenID Connect. Veja [Logout federado: Back-channel logout](#) para mais informações. ### Máximo de concessões permitidas (`maxAllowedGrants`) \{#max-allowed-grants-maxallowedgrants} -`maxAllowedGrants` é um campo opcional em nível de aplicativo em `customClientMetadata` que controla o número máximo de concessões ativas simultâneas por usuário para o aplicativo atual. +`maxAllowedGrants` é um campo opcional no nível do app em `customClientMetadata` que controla o número máximo de concessões ativas simultâneas por usuário para o app atual. - **Padrão**: `undefined` (sem limite) -- **Quando configurado**: A cada autorização bem-sucedida, o Logto verifica o total de concessões ativas para o usuário no aplicativo atual (em navegadores e dispositivos). Se o limite for excedido, o Logto revoga as concessões mais antigas. +- **Quando configurado**: A cada autorização bem-sucedida, o Logto verifica o total de concessões ativas para o usuário no app atual (em navegadores e dispositivos). Se o limite for excedido, o Logto revoga as concessões mais antigas. -Essa configuração é útil quando você deseja limitar dispositivos autenticados simultâneos por aplicativo. +Essa configuração é útil quando você deseja limitar dispositivos autenticados simultâneos por app. Cada remoção aciona o evento de webhook `Grant.LimitExceeded` [webhook event](/developers/webhooks/webhooks-events#exception-hook-events), para que você possa notificar o usuário ou acompanhar com que frequência o limite é atingido. diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index ded5bce2811..3a46280dc8c 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,6 +4,7 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; @@ -12,15 +13,22 @@ import Tabs from '@theme/Tabs'; A integração de aplicativos de terceiros do Logto permite que você utilize o Logto como um [Provedor de Identidade (IdP)](https://auth.wiki/identity-provider) para aplicativos externos. -Um Provedor de Identidade (IdP) é um serviço que verifica identidades de usuários e gerencia suas credenciais de login. Após confirmar a identidade de um usuário, o IdP gera tokens de autenticação ou declarações e permite que o usuário acesse vários aplicativos ou serviços sem precisar fazer login novamente. +Um Provedor de Identidade (IdP) é um serviço que verifica identidades de usuários e gerencia suas credenciais de login. Após confirmar a identidade de um usuário, o IdP gera tokens de autenticação ou afirmações e permite que o usuário acesse vários aplicativos ou serviços sem precisar fazer login novamente. -Diferente dos aplicativos que você criou no guia [Integre Logto ao seu aplicativo](/integrate-logto/integrate-logto-into-your-application), que são desenvolvidos e totalmente controlados por você, os aplicativos de terceiros são serviços independentes desenvolvidos por desenvolvedores externos ou parceiros de negócios. +Diferente dos aplicativos que você criou no guia [Integre Logto ao seu aplicativo](/integrate-logto/integrate-logto-into-your-application), que são desenvolvidos e totalmente controlados por você, aplicativos de terceiros são serviços independentes desenvolvidos por desenvolvedores externos ou parceiros de negócios. -Essa abordagem de integração é ideal para cenários de negócios comuns. Você pode permitir que usuários acessem aplicativos parceiros usando suas contas Logto, assim como usuários corporativos fazem login no Slack com Google Workspace. Você também pode construir uma plataforma aberta onde aplicativos de terceiros podem adicionar a funcionalidade "Entrar com Logto", semelhante ao "Entrar com Google". +Essa abordagem de integração é ideal para cenários de negócios comuns. Você pode permitir que usuários acessem aplicativos de parceiros usando suas contas Logto, assim como usuários corporativos fazem login no Slack com Google Workspace. Você também pode construir uma plataforma aberta onde aplicativos de terceiros podem adicionar a funcionalidade "Entrar com Logto", semelhante ao "Entrar com Google". -O Logto é um serviço de identidade construído sobre o protocolo [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), fornecendo capacidades de [autenticação (Authentication)](https://auth.wiki/authentication) e [autorização (Authorization)](https://auth.wiki/authorization). Isso torna a integração de um aplicativo de terceiros OIDC tão simples quanto um aplicativo web tradicional. +O Logto é um serviço de identidade construído sobre o protocolo [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), fornecendo capacidades de [autenticação (Authentication)](https://auth.wiki/authentication) e [autorização (Authorization)](https://auth.wiki/authorization). Isso torna a integração de um aplicativo de terceiros OIDC tão simples quanto uma aplicação web tradicional. -Além disso, como o OIDC é construído sobre o [OAuth 2.0](https://auth.wiki/oauth-2.0) adicionando uma camada de autenticação, você também pode integrar aplicativos de terceiros usando o protocolo OAuth. +Como o OIDC é construído sobre o [OAuth 2.0](https://auth.wiki/oauth-2.0), adicionando uma camada de autenticação, você também pode integrar aplicativos de terceiros usando o protocolo OAuth. + +## Duas formas de integrar um aplicativo de terceiros \{#two-ways-to-onboard-a-third-party-app} + +- **Registrar o aplicativo no Logto** (este guia): você cria o aplicativo e configura suas permissões e URIs de redirecionamento. Use quando você conhece seus parceiros. +- **[Aplicativo dinâmico](/integrate-logto/third-party-applications/dynamic-apps)**: clientes conectam-se sem pré-registro, usando uma URL pública HTTPS que serve seu próprio documento de metadados como client ID. Use quando qualquer cliente pode se conectar, como clientes MCP e agentes de IA. + +Ambos podem ser usados ao mesmo tempo. ## Criar um aplicativo de terceiros no Logto \{#create-a-third-party-application-in-logto} @@ -28,9 +36,9 @@ Além disso, como o OIDC é construído sobre o [OAuth 2.0](https://auth.wiki/oa 2. Clique no botão "Criar aplicativo". Selecione "Aplicativo de terceiros" como o tipo de aplicativo e escolha um dos seguintes protocolos de integração: - OIDC / OAuth 3. Selecione um tipo de aplicativo com base no tipo do aplicativo de terceiros: - - **Web tradicional**: Aplicativos renderizados no servidor (por exemplo, Node.js, PHP, Java) que podem armazenar um segredo do cliente com segurança no backend. - - **Single Page App (SPA)**: Aplicativos renderizados no lado do cliente (por exemplo, React, Vue, Angular) que rodam inteiramente no navegador e não podem armazenar segredos com segurança. - - **Nativo**: Aplicativos móveis ou desktop (por exemplo, iOS, Android, Electron) que rodam em dispositivos dos usuários. + - **Web tradicional**: Aplicações renderizadas no servidor (ex.: Node.js, PHP, Java) que podem armazenar um client secret com segurança no backend. + - **Single Page App (SPA)**: Aplicações renderizadas no lado do cliente (ex.: React, Vue, Angular) que rodam inteiramente no navegador e não podem armazenar segredos com segurança. + - **Nativo**: Aplicativos móveis ou desktop (ex.: iOS, Android, Electron) que rodam em dispositivos dos usuários. 4. Insira um nome e uma descrição para seu aplicativo e clique no botão "Criar". Um novo aplicativo de terceiros será criado. Todos os aplicativos de terceiros criados serão catalogados na página de Aplicativos sob a guia "Aplicativos de terceiros". Essa organização ajuda você a distingui-los dos seus próprios aplicativos, facilitando o gerenciamento de todos os seus aplicativos em um só lugar. @@ -39,71 +47,71 @@ Para restringir quais usuários podem fazer login em um aplicativo de terceiros, ## Guia de integração \{#integration-guide} -### Encontrar as configurações do aplicativo \{#find-the-application-configurations} +### Encontre as configurações do aplicativo \{#find-the-application-configurations} -Na página de detalhes do aplicativo, você pode encontrar o [**Client ID**](/integrate-logto/application-data-structure#application-id), [**Client secret**](/integrate-logto/application-data-structure#application-secret) (apenas para aplicativos web tradicionais) e os endpoints OIDC necessários para integração. +Na página de detalhes do aplicativo, você pode encontrar o [**Client ID**](/integrate-logto/application-data-structure#application-id), [**Client secret**](/integrate-logto/application-data-structure#application-secret) (apenas para apps web tradicionais) e os endpoints OIDC necessários para integração. -Se o serviço de terceiros suportar descoberta OIDC, basta fornecer o **Discovery endpoint**. Caso contrário, clique em **Mostrar detalhes dos endpoints** para visualizar todos os endpoints, incluindo o [endpoint de autorização](/integrate-logto/application-data-structure#authorization-endpoint) e o [endpoint de token](/integrate-logto/application-data-structure#token-endpoint). +Se o serviço de terceiros suportar descoberta OIDC, basta fornecer o **Discovery endpoint**. Caso contrário, clique em **Mostrar detalhes dos endpoints** para visualizar todos os endpoints, incluindo o [authorization endpoint](/integrate-logto/application-data-structure#authorization-endpoint) e o [token endpoint](/integrate-logto/application-data-structure#token-endpoint). -### Integrar com serviços que suportam IdP de terceiros \{#integrate-with-services-that-support-third-party-idp} +### Integre com serviços que suportam IdP de terceiros \{#integrate-with-services-that-support-third-party-idp} -Se você estiver conectando um serviço ou produto que suporta nativamente a configuração de provedor de identidade externo (por exemplo, plataformas SaaS corporativas, ferramentas de colaboração), a configuração é simples: +Se você estiver conectando um serviço ou produto que suporta nativamente configuração de provedor de identidade externo (ex.: plataformas SaaS corporativas, ferramentas de colaboração), a configuração é simples: 1. Abra a página de configuração de IdP ou SSO do serviço. 2. Copie o **Client ID** (e **Client secret** se necessário) do Logto e cole na configuração do serviço. 3. Forneça o **Discovery endpoint** se o serviço suportar auto-descoberta OIDC, ou copie manualmente o **Authorization endpoint** e o **Token endpoint**. 4. Copie o **Redirect URI** da página de configuração do serviço e adicione-o aos URIs de redirecionamento permitidos do seu aplicativo Logto. -5. Configure os **scopes** se o serviço permitir. Como o Logto é um provedor OIDC, inclua o escopo `openid` se você precisar autenticar usuários (concede acesso a um Token de ID (ID token) e ao endpoint UserInfo). O escopo `openid` é opcional se você precisar apenas de acesso a recursos OAuth. +5. Configure os **scopes** se o serviço permitir. Como o Logto é um provedor OIDC, inclua o escopo `openid` se você precisar autenticar usuários (concede acesso a um Token de ID (ID token) e ao endpoint UserInfo). O escopo `openid` é opcional se você só precisar de acesso a recursos OAuth. O serviço irá lidar automaticamente com o fluxo OAuth / OIDC após a configuração. -### Integrar via protocolo OAuth / OIDC \{#integrate-via-oauth-protocol} +### Integre via protocolo OAuth / OIDC \{#integrate-via-oauth-protocol} -Se um aplicativo de terceiros precisar se integrar ao Logto como IdP programaticamente, ele deve implementar o padrão [Authorization Code Flow](https://auth.wiki/authorization-code-flow). Recomendamos usar uma biblioteca cliente OAuth 2.0 / OIDC para sua linguagem de programação para facilitar a implementação. +Se um aplicativo de terceiros precisar integrar-se ao Logto como IdP programaticamente, ele deve implementar o padrão [Authorization Code Flow](https://auth.wiki/authorization-code-flow). Recomendamos usar uma biblioteca cliente OAuth 2.0 / OIDC para sua linguagem de programação para facilitar a implementação. -Aplicativos web tradicionais são **clientes confidenciais** que podem armazenar um segredo do cliente com segurança no servidor backend. Veja [Authorization Code Flow](https://auth.wiki/authorization-code-flow) para detalhes completos de implementação. +Aplicativos web tradicionais são **clientes confidenciais** que podem armazenar um client secret com segurança no servidor backend. Veja [Authorization Code Flow](https://auth.wiki/authorization-code-flow) para detalhes completos de implementação. **Etapas principais:** -1. **Iniciar autorização**: Redirecione o usuário para o endpoint de autorização do Logto com `client_id`, `redirect_uri`, `response_type=code` e `scope`. +1. **Iniciar autorização**: Redirecione o usuário para o authorization endpoint do Logto com `client_id`, `redirect_uri`, `response_type=code` e `scope`. 2. **Tratar callback**: Receba o `code` de autorização do redirecionamento. -3. **Trocar tokens**: Do seu backend, faça um POST para o endpoint de token com o código, `client_id` e `client_secret`. +3. **Trocar tokens**: Do seu backend, faça um POST para o token endpoint com o código, `client_id` e `client_secret`. -Single page apps e aplicativos nativos são **clientes públicos** que não podem armazenar segredos com segurança. Em vez de usar um segredo do cliente, esses aplicativos devem usar [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) para autorização segura. Veja [Authorization Code Flow](https://auth.wiki/authorization-code-flow) e [PKCE](https://auth.wiki/pkce) para detalhes completos de implementação. +Single page apps e apps nativos são **clientes públicos** que não podem armazenar segredos com segurança. Em vez de usar um client secret, esses aplicativos devem usar [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) para autorização segura. Veja [Authorization Code Flow](https://auth.wiki/authorization-code-flow) e [PKCE](https://auth.wiki/pkce) para detalhes completos de implementação. **Etapas principais:** 1. **Gerar parâmetros PKCE**: Crie um `code_verifier` e derive o `code_challenge` (SHA-256). -2. **Iniciar autorização**: Redirecione o usuário para o endpoint de autorização com `code_challenge` e `code_challenge_method=S256`. +2. **Iniciar autorização**: Redirecione o usuário para o authorization endpoint com `code_challenge` e `code_challenge_method=S256`. 3. **Tratar callback**: Receba o `code` de autorização do redirecionamento. -4. **Trocar tokens**: Faça um POST para o endpoint de token com o código e o `code_verifier` original. +4. **Trocar tokens**: Faça um POST para o token endpoint com o código e o `code_verifier` original. -### Integrar via device flow \{#integrate-via-device-flow} +### Integre via device flow \{#integrate-via-device-flow} -Para aplicativos nativos de terceiros executados em dispositivos com entrada limitada (por exemplo, smart TVs, consoles de jogos, ferramentas CLI), o fluxo padrão de autorização baseado em redirecionamento pode não ser viável. Nesses casos, o aplicativo pode usar o [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow). +Para aplicativos nativos de terceiros executados em dispositivos com entrada limitada (ex.: smart TVs, consoles de jogos, ferramentas CLI), o fluxo padrão de autorização baseado em redirecionamento pode não ser viável. Nesses casos, o aplicativo pode usar o [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow). -Com o device flow, o dispositivo exibe um código de usuário e uma URL de verificação. O usuário acessa a URL em um dispositivo separado (celular, laptop), insere o código e conclui a autenticação lá. O dispositivo faz polling no endpoint de token do Logto até que a autorização seja concluída. +Com o device flow, o dispositivo exibe um código de usuário e uma URL de verificação. O usuário acessa a URL em outro dispositivo (celular, laptop), insere o código e conclui a autenticação lá. O dispositivo faz polling no token endpoint do Logto até a autorização ser concluída. :::note -Antes de implementar o device flow, certifique-se de configurar as [permissões](/integrate-logto/third-party-applications/permission-management) necessárias para seu aplicativo de terceiros no Console do Logto. Aplicativos de terceiros que solicitarem scopes não habilitados terão o acesso negado. +Antes de implementar o device flow, certifique-se de configurar as [permissões](/integrate-logto/third-party-applications/permission-management) necessárias para seu aplicativo de terceiros no Console do Logto. Aplicativos de terceiros que solicitarem scopes não habilitados terão acesso negado. ::: Veja o [Guia rápido do device flow](/quick-starts/device-flow) para detalhes completos de implementação. -## Tela de consentimento para aplicativos de terceiros OIDC \{#consent-screen-for-oidc-third-party-applications} +## Tela de consentimento para aplicativos OIDC de terceiros \{#consent-screen-for-oidc-third-party-applications} -Por motivos de segurança, todos os aplicativos de terceiros OIDC serão redirecionados para uma [tela de consentimento](/end-user-flows/consent-screen) para autorização do usuário após serem autenticados pelo Logto. +Por motivos de segurança, todos os aplicativos OIDC de terceiros serão redirecionados para uma [tela de consentimento](/end-user-flows/consent-screen) para autorização do usuário após serem autenticados pelo Logto. -Todas as [permissões de perfil de usuário](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) solicitadas pelo aplicativo de terceiros, [escopos de recursos de API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [permissões de organização](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) e informações de associação à organização serão exibidas na tela de consentimento. +Todas as [permissões de perfil de usuário](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) solicitadas pelo terceiro, [escopos de recursos de API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [permissões de organização](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) e informações de associação à organização serão exibidas na tela de consentimento. Essas permissões solicitadas só serão concedidas aos aplicativos de terceiros após o usuário clicar no botão "Autorizar". @@ -119,7 +127,7 @@ Essas permissões solicitadas só serão concedidas aos aplicativos de terceiros type: 'link', label: 'Gerenciamento de permissões', href: '/integrate-logto/third-party-applications/permission-management', - description: 'Saiba como gerenciar permissões para seu aplicativo de terceiros OIDC.', + description: 'Saiba como gerenciar permissões para seu aplicativo OIDC de terceiros.', customProps: { icon: , }, @@ -134,6 +142,16 @@ Essas permissões solicitadas só serão concedidas aos aplicativos de terceiros icon: , }, }, + { + type: 'link', + label: 'Aplicativo dinâmico (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + 'Permita que clientes OAuth conectem-se sem pré-registro, usando uma URL de documento de metadados como client ID.', + customProps: { + icon: , + }, + }, ]} /> @@ -146,7 +164,7 @@ Essas permissões solicitadas só serão concedidas aos aplicativos de terceiros -O Logto usa Controle de Acesso Baseado em Papel (RBAC) para gerenciar permissões de usuários. Na tela de consentimento, apenas os escopos (permissões) já atribuídos ao usuário — por meio de seus papéis — serão exibidos. Se um aplicativo de terceiros solicitar escopos que o usuário não possui, eles serão excluídos para evitar consentimento não autorizado. +O Logto usa Controle de Acesso Baseado em Papel (RBAC) para gerenciar permissões de usuários. Na tela de consentimento, apenas escopos (permissões) já atribuídos ao usuário — por meio de seus papéis — serão exibidos. Se um aplicativo de terceiros solicitar escopos que o usuário não possui, eles serão excluídos para evitar consentimento não autorizado. Para gerenciar isso: @@ -163,5 +181,5 @@ Para gerenciar isso: - Usando o Logto como um provedor de identidade de terceiros (IdP) + Usando o Logto como provedor de identidade de terceiros (IdP) diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..d19614c27f3 --- /dev/null +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,99 @@ +--- +description: Permita que clientes OAuth se conectem ao seu tenant sem pré-registro usando uma URL de documento de metadados de client ID como seu client ID. +sidebar_label: Aplicativo dinâmico (CIMD) +sidebar_position: 3 +--- + +# Aplicativo dinâmico (CIMD) + +O aplicativo dinâmico permite que clientes OAuth se conectem ao seu tenant sem pré-registro. Em vez de um client ID emitido pelo Logto, o cliente usa uma URL pública HTTPS como seu `client_id`. Essa URL serve um documento JSON descrevendo o cliente, chamado de [documento de metadados de client ID (CIMD)](https://auth.wiki/client-id-metadata-document). O Logto busca o documento e trata o cliente como um [aplicativo de terceiros](/integrate-logto/third-party-applications). + +O aplicativo dinâmico implementa o rascunho IETF [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html). + +## Quando usar aplicativo dinâmico \{#when-to-use-dynamic-app} + +O pré-registro funciona quando você conhece seus parceiros. Ele não funciona quando qualquer cliente pode se conectar, o que é comum no ecossistema do [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents): um usuário pede para seu agente de IA se conectar ao seu serviço, e o agente nunca falou com seu tenant antes. + +Com o aplicativo dinâmico, o cliente publica seus próprios metadados em uma URL que possui, e essa URL é sua identidade. Nada precisa ser criado previamente em seu tenant. + +| | Aplicativo de terceiros registrado | Aplicativo dinâmico | +| ------------- | ---------------------------------- | ---------------------------------------------- | +| Client ID | Emitido pelo Logto | Uma URL HTTPS de propriedade do cliente | +| Registro | Obrigatório | Não obrigatório | +| Client secret | Suportado | Não suportado | +| Permissões | Por aplicativo | Compartilhadas por todos os clientes dinâmicos | +| Grant types | Depende do tipo de aplicativo | `authorization_code` e `refresh_token` | + +Clientes dinâmicos são clientes públicos, então sempre usam [PKCE](https://auth.wiki/pkce). Você pode usar ambos os modelos ao mesmo tempo. Um parceiro de confiança ainda pode ter um aplicativo registrado com suas próprias permissões. + +## Ativar aplicativo dinâmico \{#enable-dynamic-app} + +1. Vá para Console > Aplicativos e abra a aba **Aplicativos de terceiros**. +2. Clique em **Criar aplicativo** e selecione o cartão **Aplicativo dinâmico**. Isso ativa um recurso em nível de tenant em vez de criar um aplicativo. +3. Confirme no diálogo. Uma vez ativado, qualquer cliente OAuth com uma URL pública HTTPS válida como client ID pode iniciar uma solicitação de autorização para seu tenant. +4. Abra o aplicativo dinâmico na lista de aplicativos e vá para a aba **Permissões** para conceder permissões. + +O aplicativo dinâmico não possui nome editável, URIs de redirecionamento ou credenciais. Cada cliente fornece as suas no documento de metadados. + +:::note +O aplicativo dinâmico requer a [proteção SSRF do provedor OIDC](/concepts/core-service/configuration#oidc-provider-ssrf-protection), já que o Logto busca documentos de metadados da internet. Instâncias self-hosted que a desativam não podem ativar o aplicativo dinâmico. +::: + +### Conceder permissões \{#grant-permissions} + +A aba **Permissões** define as permissões máximas compartilhadas por todos os clientes dinâmicos. Ela funciona como o [gerenciamento de permissões](/integrate-logto/third-party-applications/permission-management) de um aplicativo de terceiros registrado, com seções de **Usuário** e **Organização**. + +Solicitar uma permissão de usuário que não foi concedida resulta em erro, enquanto permissões de recurso de API e de organização que não foram concedidas são ignoradas. Os usuários também consentem apenas com permissões que possuem através de seus [papéis](/authorization/role-based-access-control). + +Como todo cliente dinâmico compartilha esse conjunto, mantenha-o mínimo. + +## Publicar um documento de metadados de client ID \{#publish-a-client-id-metadata-document} + +Se você está construindo um cliente que se conecta ao Logto, hospede um documento de metadados e use sua URL como seu `client_id`. A URL deve usar o esquema `https` e não conter fragmento, informações de usuário ou segmentos de caminho com ponto. O Logto envia uma requisição `GET` para a URL e espera um objeto JSON. + +Por exemplo, o Claude Code usa `https://claude.ai/oauth/claude-code-client-metadata`, que serve: + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +Os nomes dos campos são os mesmos do [OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591#section-2). Observe que: + +- `client_id` deve ser idêntico à URL que serve o documento. +- Clientes dinâmicos são clientes públicos. O documento não deve conter `client_secret`, e `token_endpoint_auth_method` não pode ser um método de segredo compartilhado. Use [PKCE](https://auth.wiki/pkce) em vez disso. +- URIs de metadados como `client_uri`, `logo_uri`, `tos_uri` e `policy_uri` devem ser URLs absolutas `https`. Isso não se aplica a `redirect_uris`, então clientes nativos ainda podem usar endereços loopback como no exemplo acima. +- `redirect_uris` são correspondidos como strings exatas, exceto que endereços loopback podem ser correspondidos com qualquer porta. [Padrões curinga](/integrate-logto/application-data-structure#wildcard-patterns) também são suportados. +- `scope`, `grant_types` e `response_types` são decididos pelo Logto. Se o documento os declarar, os valores são ignorados. Clientes dinâmicos só podem usar o fluxo de código de autorização e tokens de atualização. + +O Logto armazena em cache o documento por até 24 horas, seguindo os cabeçalhos `Cache-Control` e `Expires` da sua resposta. Defina-os de acordo com a frequência com que espera atualizar o documento. + +## Tela de consentimento \{#consent-screen} + +Clientes dinâmicos são aplicativos de terceiros, então a [tela de consentimento](/end-user-flows/consent-screen) é sempre exibida. + +A tela de consentimento também mostra um aviso de que o cliente não está registrado. O nome e o logo do cliente vêm do documento de metadados, então eles podem imitar qualquer marca. O host da URL do client ID também é exibido, pois é a única parte que o cliente não pode falsificar. + +## Gerenciar autorizações \{#manage-authorizations} + +Autorizações concedidas a clientes dinâmicos são [concessões](/sessions/grants-management) regulares de terceiros. Os usuários podem revisá-las e revogá-las nas configurações da conta, e administradores podem gerenciá-las pela Management API. A URL do client ID é usada para identificar o cliente. + +Desativar o aplicativo dinâmico impede novas solicitações de autorização, enquanto concessões existentes são mantidas. Revogar uma concessão exige que o cliente obtenha autorização do usuário novamente, mas tokens de acesso emitidos anteriormente podem permanecer válidos até expirarem. + +## Limitações \{#limitations} + +- Apenas o fluxo de código de autorização com PKCE e tokens de atualização são suportados. Credenciais de cliente, device flow e troca de tokens não estão disponíveis. +- Permissões e personalização de marca não podem ser configuradas por cliente. +- [Controle de acesso em nível de aplicativo](/authorization/app-level-access-control) não se aplica a clientes dinâmicos, pois eles não possuem registro de aplicativo. + +## Recursos relacionados \{#related-resources} + +Aplicativo de terceiros (OAuth / OIDC) + + Permitir acesso de agente de IA de terceiros ao seu servidor MCP + diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index b5aa6e7b93b..22750b76aa5 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -6,15 +6,15 @@ sidebar_position: 2 As concessões de aplicativos representam o estado de autorização do usuário para aplicativos clientes específicos. -Use o gerenciamento de concessões quando usuários ou administradores precisarem revisar aplicativos autorizados e revogar o acesso ao aplicativo sem revogar toda a sessão do Logto. +Use o gerenciamento de concessões quando usuários ou administradores precisarem revisar aplicativos autorizados e revogar o acesso de aplicativos sem revogar toda a sessão do Logto. -Quando as concessões são revogadas, os tokens de acesso opacos e tokens de atualização emitidos anteriormente para essas concessões são invalidados. +Quando as concessões são revogadas, os tokens opacos de acesso (opaque access tokens) e tokens de atualização (refresh tokens) emitidos anteriormente para essas concessões são invalidados. Os tokens de acesso JWT são sem estado, então os emitidos anteriormente permanecem válidos até expirarem. ## Escolha o caminho certo \{#choose-the-right-path} | Cenário | Caminho recomendado | | -------------------------------------------------------------------------------------------- | ------------------- | -| Permitir que usuários conectados gerenciem suas próprias autorizações de aplicativos | Account API | +| Permitir que usuários autenticados gerenciem suas próprias autorizações de aplicativos | Account API | | Permitir que administradores ou equipes de suporte gerenciem concessões para um usuário alvo | Management API | | Permitir que operadores gerenciem autorizações de aplicativos de terceiros na interface | Admin Console | @@ -44,6 +44,8 @@ Os endpoints de listagem de concessões suportam o parâmetro de consulta opcion - `appType=thirdParty`: Listar apenas concessões de aplicativos de terceiros. - Omitir `appType`: Retornar todas as concessões ativas. +Clientes [aplicativos dinâmicos (Dynamic app)](/integrate-logto/third-party-applications/dynamic-apps) são aplicativos de terceiros, então suas concessões são retornadas com `appType=thirdParty`. A URL do client ID é usada como o ID do aplicativo. + ## Gerenciar autorizações de aplicativos de terceiros no Console \{#manage-third-party-app-authorizations-in-console} No Logto Console, use a página de detalhes do usuário para visualizar e revogar aplicativos de terceiros autorizados. @@ -52,21 +54,21 @@ No Logto Console, use a página de detalhes do usuário para visualizar e revoga ## Revogar concessões ao revogar uma sessão \{#revoke-grants-when-revoking-a-session} -Ao revogar uma sessão via `DELETE /api/my-account/sessions/{sessionId}`, use o parâmetro de consulta opcional `revokeGrantsTarget` para controlar o escopo de revogação de concessões: +Ao revogar uma sessão via `DELETE /api/my-account/sessions/{sessionId}`, use o parâmetro de consulta opcional `revokeGrantsTarget` para controlar o escopo da revogação das concessões: - `all`: Revogar concessões para todos os aplicativos associados à sessão. - `firstParty`: Revogar concessões apenas para aplicativos de primeira parte. -Para comportamento em nível de sessão e contexto de endpoint, veja [Gerenciar sessões de usuário](/sessions/manage-user-sessions) e [Sair](/end-user-flows/sign-out). +Para comportamento em nível de sessão e contexto do endpoint, veja [Gerenciar sessões de usuário](/sessions/manage-user-sessions) e [Sign-out](/end-user-flows/sign-out). ## Recursos relacionados \{#related-resources} Sessões Gerenciar sessões de usuário - Configurações de conta pelo Account API: Gerenciar aplicativos autorizados do usuário (concessões) + Configurações de conta por Account API: Gerenciar aplicativos autorizados do usuário (concessões) - Configurações de conta pelo Management API: Gerenciar aplicativos autorizados do usuário + Configurações de conta por Management API: Gerenciar aplicativos autorizados do usuário (concessões) diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/pt-BR/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index 5cc266b8ffd..4d28dd02230 100644 --- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -5,11 +5,17 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- Para permitir que o agente de IA de terceiros acesse {props.serviceName ?? 'seu serviço'}, você precisa configurar um **aplicativo de terceiros** no Logto. Este aplicativo será usado para representar o agente de IA e obter as credenciais necessárias para autenticação e autorização. :::info[O que é um aplicativo de terceiros?] -Um **aplicativo de terceiros** é um aplicativo criado por desenvolvedores externos (não o proprietário do recurso) que precisa do consentimento do usuário para acessar recursos protegidos. Diferente dos aplicativos de primeira parte (seus próprios aplicativos), aplicativos de terceiros exibirão uma tela de consentimento solicitando que os usuários aprovem permissões específicas antes de acessar seus dados. Isso garante que os usuários tenham controle sobre quais dados compartilham com serviços externos. +Um **aplicativo de terceiros** é um aplicativo criado por desenvolvedores externos (não o proprietário do recurso) que precisa do consentimento do usuário para acessar recursos protegidos. Diferente dos aplicativos de primeira parte (seus próprios aplicativos), aplicativos de terceiros exibem uma tela de consentimento pedindo aos usuários que aprovem permissões específicas antes de acessar seus dados. Isso garante que os usuários tenham controle sobre quais dados compartilham com serviços externos. Para saber mais, veja [Aplicativos de terceiros](/integrate-logto/third-party-applications). ::: +Existem três maneiras de integrar agentes de IA: + +- [Criar manualmente o aplicativo no Console](#manually-create-a-third-party-app-in-logto), para testes ou alguns agentes conhecidos. +- [Construir um serviço de registro usando a Management API](#allow-developers-to-create-third-party-apps-in-logto), se você quiser controlar quem recebe as credenciais. +- [Habilitar aplicativo dinâmico](#let-any-ai-agent-connect-without-pre-registration), se qualquer agente puder se conectar e você não quiser uma etapa de registro. + ### Permitir que desenvolvedores criem aplicativos de terceiros no Logto \{#allow-developers-to-create-third-party-apps-in-logto} Se você está construindo um marketplace ou deseja permitir que desenvolvedores criem aplicativos de terceiros no Logto, pode utilizar a [Logto Management API](/integrate-logto/interact-with-management-api) para criar aplicativos de terceiros programaticamente. Isso permite que desenvolvedores registrem seus aplicativos e obtenham as credenciais necessárias para autenticação. @@ -27,7 +33,24 @@ sequenceDiagram Server->>Developer: ID do app, segredo, etc. ``` -Alternativamente, você pode criar aplicativos de terceiros manualmente no Logto Console para se familiarizar com o processo. +Alternativamente, você pode criar manualmente aplicativos de terceiros no Logto Console para se familiarizar com o processo. + +### Permitir que qualquer agente de IA se conecte sem pré-registro \{#let-any-ai-agent-connect-without-pre-registration} + +Em um ecossistema MCP aberto, geralmente você não conhece os agentes com antecedência. [Aplicativo dinâmico](/integrate-logto/third-party-applications/dynamic-apps) remove a etapa de registro: o agente usa uma URL pública HTTPS que serve seu próprio documento de metadados de cliente como seu `client_id`, e o Logto resolve isso quando a solicitação de autorização chega. + +```mermaid +sequenceDiagram + participant Agent as Agente de IA (cliente MCP) + participant Logto + participant Metadata as URL do documento de metadados do agente + Agent->>Logto: Solicitação de autorização com a URL do client ID + Logto->>Metadata: Buscar o documento de metadados do client ID + Metadata->>Logto: Nome do cliente, logo, URIs de redirecionamento, etc. + Logto->>Agent: Tela de consentimento, depois código de autorização +``` + +Você ainda controla o que os agentes podem solicitar através das permissões concedidas ao aplicativo dinâmico, e toda autorização passa pela tela de consentimento do usuário. ### Criar manualmente um aplicativo de terceiros no Logto \{#manually-create-a-third-party-app-in-logto} @@ -36,7 +59,7 @@ Você pode criar manualmente um aplicativo de terceiros no Logto Console para fi 1. Faça login no seu Logto Console. 2. Vá em **Aplicativos** → **Criar aplicativo** → **Aplicativo de terceiros** -> **OIDC**. 3. Preencha o nome do aplicativo e outros campos obrigatórios, depois clique em **Criar aplicativo**. -4. Clique na aba **Permissões**, na seção **Usuário**, clique em "Adicionar". +4. Clique na guia **Permissões**, na seção **Usuário**, clique em "Adicionar". 5. Na janela aberta -> **Dados do usuário** -> selecione as permissões **`profile`**, **`email`**, depois clique em **Salvar**. 6. No aplicativo de terceiros, configure os escopos para solicitar as permissões (escopos) `openid profile email`. diff --git a/i18n/th/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx b/i18n/th/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx index 16f82d42faf..14f13c594c8 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx @@ -1,31 +1,31 @@ --- -description: จำกัดว่าผู้ใช้คนใดสามารถลงชื่อเข้าใช้แอปพลิเคชันเฉพาะโดยใช้ผู้ใช้, บทบาท, องค์กร หรือบทบาทในองค์กร +description: จำกัดว่าผู้ใช้คนใดสามารถลงชื่อเข้าใช้แอปพลิเคชันเฉพาะโดยใช้ผู้ใช้, บทบาท, องค์กร หรือบทบาทองค์กร sidebar_label: การควบคุมการเข้าถึงระดับแอป sidebar_position: 7 --- # การควบคุมการเข้าถึงระดับแอป (App-level access control) -การควบคุมการเข้าถึงระดับแอปช่วยให้คุณจำกัดว่าใครสามารถลงชื่อเข้าใช้แอปพลิเคชันเฉพาะได้ แทนที่จะอนุญาตให้ผู้ใช้ที่ลงทะเบียนทุกคนใน Logto tenant ของคุณเข้าถึงทุกแอป คุณสามารถสร้างกฎอนุญาตสำหรับแต่ละแอปพลิเคชันโดยอิงจากผู้ใช้, บทบาทผู้ใช้, องค์กร หรือบทบาทในองค์กร +การควบคุมการเข้าถึงระดับแอปช่วยให้คุณจำกัดว่าใครสามารถลงชื่อเข้าใช้แอปพลิเคชันเฉพาะได้ แทนที่จะอนุญาตให้ผู้ใช้ที่ลงทะเบียนทุกคนใน Logto tenant ของคุณเข้าถึงทุกแอป คุณสามารถสร้างกฎอนุญาตสำหรับแต่ละแอปพลิเคชันโดยอิงจากผู้ใช้, บทบาทผู้ใช้, องค์กร หรือบทบาทองค์กร ใช้การควบคุมการเข้าถึงระดับแอปเมื่อคุณต้องการ: -- ทำให้แอปภายในใช้งานได้เฉพาะพนักงานหรือผู้ดูแลระบบเท่านั้น +- ทำให้แอปภายในใช้งานได้เฉพาะกับพนักงานหรือผู้ดูแลระบบเท่านั้น - จำกัด [Protected App](/integrate-logto/protected-app) ให้กับกลุ่มผู้ใช้ที่เลือกไว้ -- อนุญาตเฉพาะลูกค้าหรือพันธมิตรบางรายให้เข้าถึง [แอป OIDC / OAuth ของบุคคลที่สาม](/integrate-logto/third-party-applications) -- เปิดตัวแอปใหม่ให้กับกลุ่มนำร่องก่อนเปิดให้ทุกคน +- อนุญาตเฉพาะลูกค้าหรือพาร์ทเนอร์บางรายให้เข้าถึง [แอป OIDC / OAuth ของบุคคลที่สาม](/integrate-logto/third-party-applications) +- เปิดตัวแอปใหม่กับกลุ่มนำร่องก่อนเปิดให้ทุกคนใช้งาน ## วิธีการทำงาน \{#how-it-works} เมื่อปิดการควบคุมการเข้าถึงระดับแอป ผู้ใช้ที่ลงทะเบียนทุกคนใน Logto tenant ของคุณสามารถลงชื่อเข้าใช้แอปพลิเคชันได้ -เมื่อเปิดใช้งาน ผู้ใช้จะสามารถเข้าถึงแอปพลิเคชันได้ก็ต่อเมื่อเขาตรงกับอย่างน้อยหนึ่งกฎที่กำหนดไว้ หากผู้ใช้ไม่ตรงกับกฎใดเลย Logto จะปฏิเสธความพยายามในการลงชื่อเข้าใช้และแสดงหน้าปฏิเสธการเข้าถึงก่อนที่แอปพลิเคชันจะได้รับโทเค็น +เมื่อเปิดใช้งาน ผู้ใช้จะสามารถเข้าถึงแอปพลิเคชันได้ก็ต่อเมื่อเขาตรงกับกฎที่กำหนดไว้อย่างน้อยหนึ่งข้อ หากผู้ใช้ไม่ตรงกับกฎใดเลย Logto จะปฏิเสธความพยายามในการลงชื่อเข้าใช้และแสดงหน้าถูกปฏิเสธการเข้าถึงก่อนที่แอปพลิเคชันจะได้รับโทเค็น -การควบคุมการเข้าถึงระดับแอปจะถูกประเมินระหว่างกระบวนการ authorization และการต่ออายุโทเค็น ซึ่งหมายความว่า: +การควบคุมการเข้าถึงระดับแอปจะถูกประเมินระหว่างกระบวนการอนุญาต (authorization flow) และการต่ออายุโทเค็น (token renewal) ซึ่งหมายความว่า: -- ผู้ใช้ที่ไม่มีสิทธิ์จะถูกบล็อกก่อนที่จะลงชื่อเข้าใช้แอปพลิเคชันได้สำเร็จ -- การอนุญาตแอปที่มีอยู่จะถูกตรวจสอบอีกครั้งเมื่อใช้โทเค็นรีเฟรชเพื่อขอโทเค็นใหม่ -- การอัปเดตกฎจะมีผลกับการตรวจสอบ authorization และการต่ออายุโทเค็นในอนาคต โดยไม่เปลี่ยนแปลงเซสชัน Logto ระดับโกลบอลของผู้ใช้ +- ผู้ใช้ที่ไม่มีสิทธิ์เข้าถูกบล็อกก่อนที่จะลงชื่อเข้าใช้แอปพลิเคชันได้สำเร็จ +- การให้สิทธิ์แอปที่มีอยู่จะถูกตรวจสอบอีกครั้งเมื่อใช้โทเค็นรีเฟรชเพื่อขอโทเค็นใหม่ +- การอัปเดตกฎจะมีผลกับการตรวจสอบการอนุญาตและการต่ออายุโทเค็นในอนาคต โดยไม่เปลี่ยนแปลงเซสชัน Logto ระดับโกลบอลของผู้ใช้ :::note การควบคุมการเข้าถึงระดับแอปแยกออกจาก [การควบคุมการเข้าถึงตามบทบาท (RBAC)](/authorization/role-based-access-control) RBAC ควบคุมสิ่งที่ผู้ใช้สามารถทำได้หลังการยืนยันตัวตนโดยการออกสิทธิ์ (ขอบเขต; scopes) ในโทเค็นการเข้าถึง การควบคุมการเข้าถึงระดับแอปควบคุมว่าผู้ใช้จะสามารถเข้าถึงแอปพลิเคชันนั้นได้หรือไม่ @@ -35,21 +35,21 @@ sidebar_position: 7 คุณสามารถกำหนดกฎอนุญาตต่อไปนี้ได้: -| ประเภทกฎ | สิ่งที่อนุญาต | -| -------------------------------------- | --------------------------------------------------------------------------- | -| **ผู้ใช้ (Users)** | ผู้ใช้เฉพาะสามารถเข้าถึงแอปพลิเคชันได้ | -| **บทบาทผู้ใช้ (User roles)** | ผู้ใช้ที่ได้รับมอบหมายบทบาทผู้ใช้ที่เลือกสามารถเข้าถึงแอปพลิเคชันได้ | -| **องค์กร (Organizations)** | สมาชิกปัจจุบันและอนาคตทั้งหมดขององค์กรที่เลือกสามารถเข้าถึงแอปพลิเคชันได้ | -| **บทบาทในองค์กร (Organization roles)** | สมาชิกที่มีบทบาทในองค์กรที่เลือกในองค์กรที่เลือกสามารถเข้าถึงแอปพลิเคชันได้ | +| ประเภทกฎ | สิ่งที่อนุญาต | +| ------------------------------------ | ------------------------------------------------------------------------------- | +| **ผู้ใช้ (Users)** | ผู้ใช้เฉพาะรายสามารถเข้าถึงแอปพลิเคชันได้ | +| **บทบาทผู้ใช้ (User roles)** | ผู้ใช้ที่ได้รับมอบหมายบทบาทผู้ใช้ที่เลือกไว้สามารถเข้าถึงแอปพลิเคชันได้ | +| **องค์กร (Organizations)** | สมาชิกปัจจุบันและอนาคตทั้งหมดขององค์กรที่เลือกไว้สามารถเข้าถึงแอปพลิเคชันได้ | +| **บทบาทองค์กร (Organization roles)** | สมาชิกที่มีบทบาทองค์กรที่เลือกไว้ในองค์กรที่เลือกไว้สามารถเข้าถึงแอปพลิเคชันได้ | -กฎเป็นแบบเพิ่มรวม (additive) ผู้ใช้เพียงแค่ตรงกับกฎใดกฎหนึ่งก็สามารถเข้าถึงแอปพลิเคชันได้ +กฎเป็นแบบบวก (additive) ผู้ใช้เพียงแค่ตรงกับกฎข้อใดข้อหนึ่งก็สามารถเข้าถึงแอปพลิเคชันได้ -ตัวอย่างเช่น หากแอปพลิเคชันมีทั้งกฎบทบาทผู้ใช้ “Support team” และกฎบทบาทในองค์กร “BigTree - Admin” ผู้ใช้จะเข้าถึงแอปได้หากได้รับมอบหมายบทบาท Support team หรือเป็น Admin ในองค์กร BigTree +ตัวอย่างเช่น หากแอปพลิเคชันมีทั้งกฎบทบาทผู้ใช้ “Support team” และกฎบทบาทองค์กร “BigTree - Admin” ผู้ใช้จะสามารถเข้าถึงแอปได้หากได้รับมอบหมายบทบาท Support team หรือเป็น Admin ในองค์กร BigTree ## ตั้งค่าการควบคุมการเข้าถึงระดับแอป \{#configure-app-level-access-control} 1. ไปที่ Console > Applications -2. เปิดแอปพลิเคชันที่คุณต้องการจำกัด +2. เปิดแอปพลิเคชันที่คุณต้องการจำกัดการเข้าถึง 3. ไปที่แท็บ **Rules** 4. ใน **Custom allow rules** คลิก **Add rules** 5. เลือกประเภทกฎ: @@ -57,7 +57,7 @@ sidebar_position: 7 - **User roles** - **Organizations** - **Organization roles** -6. เลือกผู้ใช้, บทบาท, องค์กร หรือบทบาทในองค์กรที่ควรได้รับอนุญาตให้เข้าถึงแอปพลิเคชัน +6. เลือกผู้ใช้, บทบาท, องค์กร หรือบทบาทองค์กรที่ควรได้รับอนุญาตให้เข้าถึงแอปพลิเคชัน 7. เปิดใช้งาน **Enable access control** 8. คลิก **Save changes** @@ -69,22 +69,22 @@ sidebar_position: 7 คุณสามารถอัปเดตรายการอนุญาตได้จากแท็บ **Rules** ของแอปพลิเคชัน -- หากต้องการเพิ่มกฎ คลิก **Add another** ใต้ตารางกฎ -- หากต้องการลบกฎ คลิกปุ่มลบบนแถวกฎและยืนยันการดำเนินการ +- เพื่อเพิ่มกฎเพิ่มเติม คลิก **Add another** ใต้ตารางกฎ +- เพื่อลบกฎ คลิกปุ่มลบในแถวของกฎนั้นและยืนยันการดำเนินการ - หลังจากเพิ่มหรือลบกฎ คลิก **Save changes** เพื่อบันทึกการอัปเดต หากเปิดใช้งานการควบคุมการเข้าถึง Logto ต้องการให้มีกฎอย่างน้อยหนึ่งข้อคงอยู่ หากต้องการลบกฎทั้งหมด ให้ปิด **Enable access control** ก่อน แล้วจึงบันทึกการเปลี่ยนแปลง ## ผลกระทบของการเปลี่ยนกฎต่อผู้ใช้ \{#how-rule-changes-affect-users} -การควบคุมการเข้าถึงระดับแอปจะไม่ยุติเซสชัน Logto ระดับโกลบอลของผู้ใช้ ผู้ใช้ยังคงลงชื่อเข้าใช้ Logto และแอปพลิเคชันอื่น ๆ ได้ +การควบคุมการเข้าถึงระดับแอปจะไม่ยุติเซสชัน Logto ระดับโกลบอลของผู้ใช้ ผู้ใช้อาจยังคงลงชื่อเข้าใช้ Logto และแอปพลิเคชันอื่น ๆ ได้ สำหรับแอปพลิเคชันที่ถูกจำกัด: -- ผู้ใช้ที่ไม่ตรงกับกฎอนุญาตใด ๆ อีกต่อไปจะถูกบล็อกเมื่อเข้าสู่กระบวนการ authorization ของแอปครั้งถัดไป -- หากผู้ใช้มีการอนุญาตที่เกี่ยวข้องกับแอปอยู่แล้ว Logto จะตรวจสอบกฎอีกครั้งเมื่อแอปใช้โทเค็นรีเฟรชเพื่อขอโทเค็นใหม่ หากผู้ใช้ไม่มีสิทธิ์อีกต่อไป Logto จะปฏิเสธคำขอโทเค็น +- ผู้ใช้ที่ไม่ตรงกับกฎอนุญาตใด ๆ อีกต่อไปจะถูกบล็อกเมื่อเข้าสู่กระบวนการอนุญาตของแอปพลิเคชันในครั้งถัดไป +- หากผู้ใช้มีการให้สิทธิ์ที่เกี่ยวข้องกับแอปอยู่แล้ว Logto จะตรวจสอบกฎอีกครั้งเมื่อแอปใช้โทเค็นรีเฟรชเพื่อขอโทเค็นใหม่ หากผู้ใช้ไม่มีสิทธิ์เข้าถึงอีกต่อไป Logto จะปฏิเสธคำขอโทเค็น -สิ่งนี้ช่วยให้การตัดสินใจการเข้าถึงผูกกับแอปพลิเคชันโดยไม่รบกวนแอปอื่นที่ไม่เกี่ยวข้องโดยไม่จำเป็น +สิ่งนี้ทำให้การตัดสินใจเข้าถึงผูกกับแต่ละแอปพลิเคชันโดยไม่รบกวนแอปอื่นที่ไม่เกี่ยวข้องโดยไม่จำเป็น ## ความสัมพันธ์กับสิทธิ์ของแอปบุคคลที่สาม \{#relationship-with-third-party-app-permissions} @@ -95,16 +95,20 @@ sidebar_position: 7 หากกำหนดทั้งสองอย่าง ผู้ใช้ต้องผ่านการควบคุมการเข้าถึงระดับแอปก่อนจึงจะสามารถอนุญาตแอปบุคคลที่สามได้ +:::note +การควบคุมการเข้าถึงระดับแอปใช้ได้กับแอปพลิเคชันที่ลงทะเบียนเท่านั้น [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) ไม่มีระเบียนแอปพลิเคชัน จึงไม่สามารถจำกัดด้วยวิธีนี้ได้ การเข้าถึงของพวกเขาถูกจำกัดด้วยสิทธิ์ที่คุณให้กับ dynamic app และโดยความยินยอมของผู้ใช้ +::: + ## ความสัมพันธ์กับ Protected App \{#relationship-with-protected-app} -สำหรับ [Protected App](/integrate-logto/protected-app) การควบคุมการเข้าถึงระดับแอปจะจำกัดว่าใครสามารถผ่านชั้นการยืนยันตัวตนของ Logto และเข้าถึง origin server ที่ได้รับการปกป้องได้ +สำหรับ [Protected App](/integrate-logto/protected-app) การควบคุมการเข้าถึงระดับแอปจะจำกัดว่าใครสามารถผ่านชั้นการยืนยันตัวตนของ Logto และเข้าถึงต้นทางที่ได้รับการปกป้องได้ -กฎการยืนยันตัวตนของ Protected App ยังคงกำหนดว่า route ใดต้องการการยืนยันตัวตน การควบคุมการเข้าถึงระดับแอปจะกำหนดว่าผู้ใช้ Logto ที่ได้รับการยืนยันตัวตนคนใดได้รับอนุญาตให้เข้าถึงแอป Protected App +กฎการยืนยันตัวตนของ Protected App ยังคงกำหนดว่า route ใดต้องการการยืนยันตัวตน การควบคุมการเข้าถึงระดับแอปจะกำหนดว่าผู้ใช้ Logto ที่ได้รับการยืนยันตัวตนคนใดได้รับอนุญาตให้เข้าถึง Protected App ## แนวทางปฏิบัติที่ดีที่สุด \{#best-practices} -- เริ่มต้นด้วยกฎบทบาทผู้ใช้หรือบทบาทในองค์กรเมื่อเป็นไปได้ เพราะดูแลรักษาง่ายกว่ารายชื่อผู้ใช้ยาว ๆ +- เริ่มต้นด้วยกฎบทบาทผู้ใช้หรือบทบาทองค์กรเมื่อเป็นไปได้ เพราะดูแลรักษาง่ายกว่ารายชื่อผู้ใช้ยาว ๆ - ใช้กฎองค์กรเมื่อทุกคนในองค์กรควรเข้าถึงแอป -- ใช้กฎบทบาทในองค์กรเมื่อเฉพาะสมาชิกบางคนขององค์กรควรเข้าถึงแอป +- ใช้กฎบทบาทองค์กรเมื่อเฉพาะสมาชิกบางคนในองค์กรควรเข้าถึงแอป - ทบทวนกฎการเข้าถึงเมื่อผู้ใช้เปลี่ยนบทบาท, เข้าร่วมองค์กร หรือออกจากองค์กร -- แยกสิทธิ์ RBAC และการควบคุมการเข้าถึงระดับแอปในโมเดลความคิดของคุณ: การควบคุมการเข้าถึงระดับแอปตอบคำถาม “ผู้ใช้คนนี้เข้าถึงแอปนี้ได้หรือไม่?” ขณะที่ RBAC ตอบว่า “ผู้ใช้คนนี้สามารถทำอะไรได้บ้างหลังเข้าถึง API หรือฟีเจอร์ขององค์กร?” +- แยก RBAC และการควบคุมการเข้าถึงระดับแอปในโมเดลความคิดของคุณ: การควบคุมการเข้าถึงระดับแอปตอบว่า “ผู้ใช้คนนี้เข้าถึงแอปนี้ได้หรือไม่?” ขณะที่ RBAC ตอบว่า “ผู้ใช้คนนี้ทำอะไรได้บ้างหลังเข้าถึง API หรือฟีเจอร์ขององค์กร?” diff --git a/i18n/th/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/th/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index 078de728499..90fbff216b8 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/th/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -7,45 +7,47 @@ Logto จัดการตัวแปรสภาพแวดล้อมตามลำดับดังนี้: - ตัวแปรสภาพแวดล้อมของระบบ -- ไฟล์ `.env` ใน root ของโปรเจกต์ ซึ่งเป็นไปตามรูปแบบ [dotenv](https://github.com/motdotla/dotenv#readme) +- ไฟล์ `.env` ที่อยู่ใน root ของโปรเจกต์ ซึ่งเป็นไปตามรูปแบบ [dotenv](https://github.com/motdotla/dotenv#readme) ดังนั้น ตัวแปรสภาพแวดล้อมของระบบจะมีสิทธิ์แทนที่ค่าที่อยู่ใน `.env` ### ตัวแปร {#variables} :::caution -หากคุณรัน Logto ผ่าน `npm start` ใน root ของโปรเจกต์ `NODE_ENV` จะเป็น `production` เสมอ +หากคุณรัน Logto ผ่าน `npm start` ที่ root ของโปรเจกต์ `NODE_ENV` จะเป็น `production` เสมอ ::: ในค่าเริ่มต้น `protocol` จะเป็น `http` หรือ `https` ตามการตั้งค่า HTTPS ของคุณ -| Key | ค่าเริ่มต้น | ประเภท | คำอธิบาย | -| -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| NODE_ENV | `undefined` | 'production' | 'test' | undefined | ประเภทของสภาพแวดล้อมที่ Logto ทำงานอยู่ | -| PORT | `3001` | `number` | พอร์ตภายในเครื่องที่ Logto รับฟัง | -| ADMIN_PORT | `3002` | `number` | พอร์ตภายในเครื่องที่ Logto Admin Console รับฟัง | -| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | ตั้งค่าเป็น `1` หรือ `true` เพื่อปิดพอร์ตสำหรับ Admin Console หาก `ADMIN_ENDPOINT` ไม่ถูกตั้งค่า จะปิด Admin Console ทั้งหมด | -| DB_URL | N/A | `string` | [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6) สำหรับฐานข้อมูล Logto | -| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout` หน่วยเป็นมิลลิวินาที ใช้สตริงตัวเลข (เช่น `5000`) เพื่อกำหนด หรือ `DISABLE_TIMEOUT` เพื่อข้ามพารามิเตอร์นี้ (แนะนำสำหรับ PgBouncer/RDS Proxy) หากไม่ตั้งค่าหรือไม่ถูกต้อง ค่าเริ่มต้นฝั่ง client คือ 60000 ms | -| HTTPS_CERT_PATH | `undefined` | string | undefined | ดูรายละเอียดที่ [การเปิดใช้งาน HTTPS](#enabling-https) | -| HTTPS_KEY_PATH | `undefined` | string | undefined | เช่นเดียวกัน | -| TRUST_PROXY_HEADER | `false` | `boolean` | เช่นเดียวกัน | -| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | คุณสามารถระบุ URL ที่มีโดเมนของคุณเองสำหรับการทดสอบออนไลน์หรือ production ได้ ค่านี้จะมีผลต่อ [OIDC issuer identifier](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) ด้วย | -| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | คุณสามารถระบุ URL ที่มีโดเมนของคุณเองสำหรับ production (เช่น `ADMIN_ENDPOINT=https://admin.domain.com`) ค่านี้จะมีผลต่อค่า Admin Console Redirect URIs ด้วย | -| CASE_SENSITIVE_USERNAME | `true` | `boolean` | ระบุว่าชื่อผู้ใช้ต้องตรงตามตัวพิมพ์เล็ก/ใหญ่หรือไม่ โปรดระวังเมื่อเปลี่ยนค่านี้; การเปลี่ยนแปลงจะไม่ปรับข้อมูลในฐานข้อมูลที่มีอยู่โดยอัตโนมัติ ต้องจัดการเอง | -| SECRET_VAULT_KEK | `undefined` | `string` | Key Encryption Key (KEK) ที่ใช้เข้ารหัส Data Encryption Keys (DEK) ใน [Secret Vault](/secret-vault) จำเป็นสำหรับการทำงานของ Secret Vault ต้องเป็นสตริง base64-encoded แนะนำให้ใช้ AES-256 (32 bytes) ตัวอย่าง: `crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | ระยะเวลาผ่อนผัน (วินาที) สำหรับการหมุนคีย์ส่วนตัว OIDC แบบ staged เมื่อกำหนดค่ามากกว่า 0 คีย์ใหม่จะถูกสร้างเป็น `Next` ก่อนและจะมีผลหลังจากหมดระยะเวลาผ่อนผัน | -| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | สำหรับ self-hosted เท่านั้น ตั้งค่าเป็น `true` เฉพาะเมื่อ endpoint ของ OIDC relying-party ที่เชื่อถือได้ต้องชี้ไปยัง private network ดู [การป้องกัน SSRF ของ OIDC provider](#oidc-provider-ssrf-protection) | +| Key | ค่าเริ่มต้น | ประเภท | คำอธิบาย | +| -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| NODE_ENV | `undefined` | 'production' | 'test' | undefined | ประเภทของสภาพแวดล้อมที่ Logto ทำงานอยู่ | +| PORT | `3001` | `number` | พอร์ตภายในเครื่องที่ Logto รับฟัง | +| ADMIN_PORT | `3002` | `number` | พอร์ตภายในเครื่องที่ Logto Admin Console รับฟัง | +| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | ตั้งค่าเป็น `1` หรือ `true` เพื่อปิดพอร์ตสำหรับ Admin Console หาก `ADMIN_ENDPOINT` ไม่ถูกตั้งค่า จะปิด Admin Console ทั้งหมด | +| DB_URL | N/A | `string` | [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6) สำหรับฐานข้อมูล Logto | +| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout` หน่วยเป็นมิลลิวินาที ใช้ string ตัวเลข (เช่น `5000`) เพื่อกำหนด หรือ `DISABLE_TIMEOUT` เพื่อข้ามพารามิเตอร์นี้ (แนะนำสำหรับ PgBouncer/RDS Proxy) หากไม่ตั้งค่าหรือไม่ถูกต้อง ค่าเริ่มต้นฝั่ง client คือ 60000 ms | +| HTTPS_CERT_PATH | `undefined` | string | undefined | ดูรายละเอียดที่ [การเปิดใช้งาน HTTPS](#enabling-https) | +| HTTPS_KEY_PATH | `undefined` | string | undefined | เช่นเดียวกัน | +| TRUST_PROXY_HEADER | `false` | `boolean` | เช่นเดียวกัน | +| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | คุณสามารถระบุ URL ด้วยโดเมนของคุณเองสำหรับการทดสอบออนไลน์หรือ production ค่านี้จะมีผลต่อ [OIDC issuer identifier](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) ด้วย | +| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | คุณสามารถระบุ URL ด้วยโดเมนของคุณเองสำหรับ production (เช่น `ADMIN_ENDPOINT=https://admin.domain.com`) ค่านี้จะมีผลต่อค่า Admin Console Redirect URIs ด้วย | +| CASE_SENSITIVE_USERNAME | `true` | `boolean` | ระบุว่า username ต้องแยกตัวพิมพ์เล็ก-ใหญ่หรือไม่ โปรดระวังเมื่อเปลี่ยนค่า เพราะข้อมูลในฐานข้อมูลเดิมจะไม่ถูกปรับอัตโนมัติ ต้องจัดการเอง | +| SECRET_VAULT_KEK | `undefined` | `string` | Key Encryption Key (KEK) ที่ใช้เข้ารหัส Data Encryption Keys (DEK) ใน [Secret Vault](/secret-vault) จำเป็นสำหรับการทำงานของ Secret Vault ต้องเป็น string ที่เข้ารหัส base64 แนะนำให้ใช้ AES-256 (32 bytes) ตัวอย่าง: `crypto.randomBytes(32).toString('base64')` | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | ระยะเวลาผ่อนผัน (วินาที) สำหรับการหมุน private key ของ OIDC แบบ staged เมื่อกำหนดค่ามากกว่า 0 จะสร้าง private key ใหม่เป็น `Next` ก่อน และจะมีผลหลังจากหมดระยะเวลาผ่อนผัน | +| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | สำหรับ self-hosted เท่านั้น ตั้งค่าเป็น `true` เฉพาะเมื่อ endpoint ของ OIDC relying-party ที่เชื่อถือได้ต้องชี้ไปยัง private network ดู [การป้องกัน SSRF ของ OIDC provider](#oidc-provider-ssrf-protection) | ### การป้องกัน SSRF ของ OIDC provider {#oidc-provider-ssrf-protection} -โดยค่าเริ่มต้น Logto ป้องกันคำขอออกจาก OIDC provider ต่อภายนอกไม่ให้เกิด server-side request forgery (SSRF) โดยจะบล็อกคำขอไปยังที่อยู่พิเศษ เช่น loopback และ private network การป้องกันนี้ครอบคลุม endpoint ของ relying-party เช่น back-channel logout URIs, `jwks_uri` และ `sector_identifier_uri` +Logto ป้องกันคำขอออกจาก OIDC provider ต่อภายนอกจาก server-side request forgery (SSRF) โดยค่าเริ่มต้น โดยจะบล็อกคำขอไปยังที่อยู่พิเศษ เช่น loopback และ private network การป้องกันนี้ครอบคลุม endpoint ของ relying-party เช่น back-channel logout URIs, `jwks_uri`, และ `sector_identifier_uri` รวมถึงเอกสาร metadata client ID ที่ดึงมาเพื่อ [dynamic app](/integrate-logto/third-party-applications/dynamic-apps) หากการติดตั้งแบบ self-hosted ของคุณจำเป็นต้องเข้าถึง endpoint ของ relying-party ที่เชื่อถือได้ใน private network ให้ตั้งค่า `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` และรีสตาร์ท Logto ทุก instance :::caution -การตั้งค่านี้จะปิดการป้องกัน SSRF สำหรับคำขอออกทั้งหมดของ OIDC provider ไม่ใช่แค่ endpoint เดียว ควรปิดเฉพาะเมื่อ endpoint ทั้งหมดที่ตั้งค่าไว้เชื่อถือได้และระบบเครือข่ายของคุณป้องกันการเข้าถึงบริการภายในที่สำคัญ +การตั้งค่านี้จะปิดการป้องกัน SSRF สำหรับคำขอออกทั้งหมดของ OIDC provider ไม่ใช่แค่ endpoint เดียว ควรปิดเฉพาะเมื่อ endpoint ทั้งหมดที่ตั้งค่าไว้เชื่อถือได้ และเครือข่ายของคุณควบคุมการเข้าถึงบริการภายในที่สำคัญได้ + +[Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) จะไม่สามารถเปิดใช้งานได้ขณะปิดการป้องกันนี้ เพราะต้องดึง metadata จาก URL ที่ client กำหนดเอง ::: @@ -59,11 +61,11 @@ Node รองรับ HTTPS โดยตรง ให้ระบุ **ทั #### ใช้งานกับ HTTPS proxy {#using-a-https-proxy} -อีกแนวทางที่นิยมคือการมี HTTPS proxy อยู่หน้า Node (เช่น Nginx) +อีกแนวทางที่นิยมคือมี HTTPS proxy อยู่หน้า Node (เช่น Nginx) ในกรณีนี้ คุณอาจต้องตั้งค่า `TRUST_PROXY_HEADER` เป็น `true` เพื่อระบุว่าควรเชื่อ header จาก proxy หรือไม่ Logto จะส่งค่าดังกล่าวไปยัง [Koa app settings](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings) -ดู [Trusting TLS offloading proxies](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies) สำหรับกรณีที่ควรตั้งค่าฟิลด์นี้ +ดู [Trusting TLS offloading proxies](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies) เพื่อดูว่าเมื่อใดควรตั้งค่านี้ ## การตั้งค่าฐานข้อมูล {#database-configs} @@ -71,12 +73,12 @@ Node รองรับ HTTPS โดยตรง ให้ระบุ **ทั ตารางนี้เป็น key-value storage แบบง่าย ๆ โดย key ที่ใช้ได้มีดังนี้: -| Key | ประเภท | คำอธิบาย | -| ---------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -| oidc.cookieKeys | string[] | อาร์เรย์ของสตริงสำหรับ [signing cookie keys](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#cookieskeys) | -| oidc.privateKeys | string[] | อาร์เรย์ของสตริงเนื้อหาคีย์ส่วนตัวสำหรับ [OIDC JWT signing](https://openid.net/specs/openid-connect-core-1_0.html#Signing) | +| Key | ประเภท | คำอธิบาย | +| ---------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------- | +| oidc.cookieKeys | string[] | อาร์เรย์ string ของ [signing cookie keys](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#cookieskeys) | +| oidc.privateKeys | string[] | อาร์เรย์ string ของเนื้อหา private key สำหรับ [OIDC JWT signing](https://openid.net/specs/openid-connect-core-1_0.html#Signing) | -### ประเภทคีย์ส่วนตัวที่รองรับ {#supported-private-key-types} +### ประเภท private key ที่รองรับ {#supported-private-key-types} - EC (P-256, secp256k1, P-384, และ P-521 curves) - RSA diff --git a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index ea8944e6f13..02badaf5bd4 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -6,27 +6,31 @@ sidebar_position: 6 ## หน้าขอความยินยอมคืออะไร? \{#what-is-consent-screen} -ลองจินตนาการว่าคุณกำลังสมัครใช้งาน Logto โดยใช้บัญชี Google ของคุณ เมื่อคุณคลิกปุ่ม "Sign in with Google" คุณจะถูกเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ของ Google หลังจากที่คุณกรอกข้อมูลบัญชี Google แล้ว คุณจะถูกขอให้อนุญาตให้ Logto เข้าถึงข้อมูลบัญชี Google ของคุณ นี่คือหน้าขอความยินยอมของผู้ใช้ +ลองจินตนาการว่าคุณกำลังสมัครใช้งาน Logto ด้วยบัญชี Google ของคุณ เมื่อคุณคลิกปุ่ม "Sign in with Google" คุณจะถูกเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ของ Google หลังจากที่คุณกรอกข้อมูลบัญชี Google แล้ว คุณจะถูกขอให้อนุญาตให้ Logto เข้าถึงข้อมูลบัญชี Google ของคุณ นี่คือหน้าขอความยินยอมของผู้ใช้ -หน้านี้เราเรียกว่า **หน้าขอความยินยอม (consent screen)** หรือ **หน้าความยินยอม (consent page)** เป็นขั้นตอนมาตรฐานของ [OIDC / OAuth 2.0 flow](/integrate-logto/third-party-applications) ที่เปิดโอกาสให้ผู้ใช้อนุญาต [แอปพลิเคชันของบุคคลที่สาม](/integrate-logto/third-party-applications) ให้เข้าถึงข้อมูลของตนแทนตนเอง จุดประสงค์หลักคือเพื่อแจ้งให้ผู้ใช้ทราบเกี่ยวกับการเก็บรวบรวม ประมวลผล และการใช้ข้อมูลส่วนบุคคลของพวกเขา และขอความยินยอมอย่างชัดเจนสำหรับกิจกรรมเหล่านี้ +หน้านี้เราเรียกว่า **หน้าขอความยินยอม (consent screen)** หรือ **หน้าความยินยอม (consent page)** ซึ่งเป็นขั้นตอนมาตรฐานของ [OIDC / OAuth 2.0 flow](/integrate-logto/third-party-applications) ที่เปิดโอกาสให้ผู้ใช้อนุญาต [แอปพลิเคชันของบุคคลที่สาม](/integrate-logto/third-party-applications) ให้เข้าถึงข้อมูลของตนเองแทนตน จุดประสงค์หลักคือเพื่อแจ้งให้ผู้ใช้ทราบเกี่ยวกับการเก็บรวบรวม ประมวลผล และการใช้ข้อมูลส่วนบุคคลของพวกเขา และขอความยินยอมอย่างชัดเจนสำหรับกิจกรรมเหล่านี้ -ในหน้าขอความยินยอม ผู้ใช้จะได้รับ [ข้อมูล](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information) เกี่ยวกับประเภทของข้อมูลที่จะถูกเก็บรวบรวม วิธีการใช้งาน และการแบ่งปันกับบุคคลที่สามหรือไม่ ข้อมูลนี้มีความสำคัญต่อความโปร่งใส ช่วยให้ผู้ใช้ตัดสินใจเกี่ยวกับความเป็นส่วนตัวและความปลอดภัยของข้อมูลได้อย่างมีข้อมูล +บนหน้าขอความยินยอม ผู้ใช้จะได้รับ [ข้อมูล](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information) เกี่ยวกับประเภทของข้อมูลที่จะถูกเก็บรวบรวม วิธีการใช้งาน และการแบ่งปันกับบุคคลที่สามหรือไม่ ข้อมูลนี้มีความสำคัญต่อความโปร่งใส ช่วยให้ผู้ใช้ตัดสินใจเกี่ยวกับความเป็นส่วนตัวและความปลอดภัยของข้อมูลได้อย่างมีข้อมูล -หน้าความยินยอมมีความสำคัญอย่างยิ่งในบริบทของกฎหมายความเป็นส่วนตัว เช่น กฎระเบียบการคุ้มครองข้อมูลทั่วไป ([GDPR](https://gdpr-info.eu/art-4-gdpr/)) ในสหภาพยุโรป หรือกฎหมายความเป็นส่วนตัวของผู้บริโภคแคลิฟอร์เนีย ([CCPA](https://oag.ca.gov/privacy/ccpa)) ในสหรัฐอเมริกา ซึ่งกำหนดให้องค์กรต้องได้รับความยินยอมที่ชัดเจนและยืนยันได้จากผู้ใช้ก่อนดำเนินการกับข้อมูลส่วนบุคคลของพวกเขา +หน้าความยินยอมมีความสำคัญอย่างยิ่งในบริบทของกฎหมายคุ้มครองข้อมูลส่วนบุคคล เช่น กฎระเบียบคุ้มครองข้อมูลทั่วไป ([GDPR](https://gdpr-info.eu/art-4-gdpr/)) ในสหภาพยุโรป หรือกฎหมายคุ้มครองความเป็นส่วนตัวของผู้บริโภคแคลิฟอร์เนีย ([CCPA](https://oag.ca.gov/privacy/ccpa)) ในสหรัฐอเมริกา ซึ่งกำหนดให้องค์กรต้องได้รับความยินยอมที่ชัดเจนและยืนยันได้จากผู้ใช้ก่อนดำเนินการกับข้อมูลส่วนบุคคล ## ผู้ใช้จะเห็นหน้าขอความยินยอมใน Logto เมื่อใด? \{#when-does-user-see-the-consent-screen-in-logto} -ดังที่กล่าวไปก่อนหน้านี้ หน้าขอความยินยอมจะปรากฏขึ้นเมื่อผู้ใช้ลงชื่อเข้าใช้ Logto โดยใช้ผู้ให้บริการข้อมูลระบุตัวตน (IdP) ของบุคคลที่สาม เช่น Google, Facebook หรือ Apple ในกรณีนี้ Logto ทำหน้าที่เป็นผู้ให้บริการบริการ (SP) ที่ร้องขอเข้าถึงข้อมูลผู้ใช้จาก IdP โดยทั่วไปหน้าขอความยินยอมจะแสดงเมื่อ [SP](https://auth.wiki/service-provider) และ [IdP](https://auth.wiki/identity-provider) เป็นองค์กรคนละแห่งกัน ซึ่งต้องได้รับการอนุญาตจากผู้ใช้เพื่ออำนวยความสะดวกในการแบ่งปันข้อมูล +ดังที่กล่าวไปก่อนหน้านี้ หน้าขอความยินยอมจะปรากฏเมื่อผู้ใช้ลงชื่อเข้าใช้ Logto ด้วยผู้ให้บริการข้อมูลระบุตัวตน (IdP) ของบุคคลที่สาม เช่น Google, Facebook หรือ Apple ในกรณีนี้ Logto ทำหน้าที่เป็นผู้ให้บริการบริการ (SP) ขอเข้าถึงข้อมูลผู้ใช้จาก IdP โดยทั่วไปหน้าขอความยินยอมจะปรากฏเมื่อ [SP](https://auth.wiki/service-provider) และ [IdP](https://auth.wiki/identity-provider) เป็นคนละองค์กรกัน ซึ่งต้องได้รับการอนุญาตจากผู้ใช้เพื่อให้สามารถแบ่งปันข้อมูลได้ Consent screen Logto as SP -ในทำนองเดียวกัน ใน Logto เมื่อ Logto ทำหน้าที่เป็น IdP หน้าขอความยินยอมจะแสดงเมื่อผู้ใช้ลงชื่อเข้าใช้ [**แอปพลิเคชัน OIDC / OAuth ของบุคคลที่สาม**](/integrate-logto/third-party-applications) ที่เชื่อมต่อกับ Logto หน้านี้จะแจ้งให้ผู้ใช้ทราบเกี่ยวกับข้อมูลที่แอปพลิเคชันร้องขอและขออนุญาตจากผู้ใช้ในการดำเนินการต่อ ผู้ใช้สามารถตรวจสอบสิทธิ์ที่ร้องขอและตัดสินใจว่าจะอนุญาตให้แอปพลิเคชันหรือไม่ +ในทำนองเดียวกัน ใน Logto เมื่อ Logto ทำหน้าที่เป็น IdP หน้าขอความยินยอมจะปรากฏเมื่อผู้ใช้ลงชื่อเข้าใช้ [**OIDC / OAuth third-party application**](/integrate-logto/third-party-applications) ที่เชื่อมต่อกับ Logto หน้านี้จะแจ้งให้ผู้ใช้ทราบเกี่ยวกับข้อมูลที่แอปพลิเคชันร้องขอและขออนุญาตจากผู้ใช้ ผู้ใช้สามารถตรวจสอบสิทธิ์ที่ร้องขอและตัดสินใจว่าจะอนุญาตให้แอปพลิเคชันเข้าถึงหรือไม่ Consent screen Logto as IdP -## วิธีตั้งค่าหน้าขอความยินยอม \{#how-to-configure-the-consent-screen} +### ไคลเอนต์ที่ไม่ได้ลงทะเบียน (ไดนามิก) \{#unregistered-dynamic-clients} -กระบวนการขอความยินยอมของ Logto ช่วยให้คุณอนุญาตการเข้าสู่ระบบจากแอปพลิเคชันของบุคคลที่สาม คุณสามารถปรับแต่งแบรนด์และคำขอสิทธิ์สำหรับแต่ละแอปพลิเคชัน OIDC ของบุคคลที่สามได้ +หากเปิดใช้งาน [dynamic app](/integrate-logto/third-party-applications/dynamic-apps) ไคลเอนต์สามารถเชื่อมต่อกับ tenant ของคุณได้โดยไม่ต้องลงทะเบียนล่วงหน้า สำหรับไคลเอนต์เหล่านี้ หน้าขอความยินยอมจะแสดงประกาศเพิ่มเติม พร้อมกับ host ของ client ID URL ชื่อและโลโก้ของไคลเอนต์จะมาจาก metadata document ของไคลเอนต์เอง ดังนั้นพวกเขาสามารถเลียนแบบแบรนด์ใดก็ได้ แต่ host ไม่สามารถปลอมแปลงได้ + +## จะตั้งค่าหน้าขอความยินยอมได้อย่างไร? \{#how-to-configure-the-consent-screen} + +ขั้นตอนขอความยินยอมของ Logto ช่วยให้คุณอนุญาตการเข้าสู่ระบบจากแอปพลิเคชันของบุคคลที่สาม คุณสามารถปรับแต่งแบรนด์และคำขอสิทธิ์สำหรับแต่ละแอปพลิเคชัน OIDC ของบุคคลที่สามได้ เรียนรู้เพิ่มเติมเกี่ยวกับการตั้งค่า [แอปพลิเคชันของบุคคลที่สาม](/integrate-logto/third-party-applications/) และการตั้งค่า [หน้าขอความยินยอม](/integrate-logto/third-party-applications/consent-screen-branding/) ใน Logto diff --git a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index fc2eaf64f24..819dcb46641 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -1,5 +1,5 @@ --- -description: ดูข้อมูลคีย์พารามิเตอร์ของแอปพลิเคชันสำหรับการผสานรวมการยืนยันตัวตน (Authentication) OIDC รวมถึง redirect URIs, endpoints, โทเค็นรีเฟรช (Refresh tokens), การออกจากระบบแบบ backchannel ฯลฯ +description: ดูข้อมูลพารามิเตอร์สำคัญของแอปพลิเคชันสำหรับการผสานรวมการยืนยันตัวตน (OIDC) รวมถึง redirect URIs, endpoints, โทเค็นรีเฟรช, backchannel logout ฯลฯ sidebar_position: 7 --- @@ -7,11 +7,11 @@ sidebar_position: 7 ## บทนำ \{#introduction} -ใน Logto _แอปพลิเคชัน_ หมายถึงโปรแกรมซอฟต์แวร์หรือบริการเฉพาะที่ลงทะเบียนกับแพลตฟอร์ม Logto และได้รับการอนุญาต (Authorization) ให้เข้าถึงข้อมูลผู้ใช้หรือดำเนินการในนามของผู้ใช้ แอปพลิเคชันถูกใช้เพื่อระบุแหล่งที่มาของคำขอที่ส่งไปยัง Logto API รวมถึงจัดการกระบวนการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) สำหรับผู้ใช้ที่เข้าถึงแอปพลิเคชันเหล่านั้น +ใน Logto _แอปพลิเคชัน_ หมายถึงโปรแกรมซอฟต์แวร์หรือบริการเฉพาะที่ลงทะเบียนกับแพลตฟอร์ม Logto และได้รับการอนุญาตให้เข้าถึงข้อมูลผู้ใช้หรือดำเนินการในนามของผู้ใช้ แอปพลิเคชันถูกใช้เพื่อระบุแหล่งที่มาของคำขอที่ส่งไปยัง Logto API รวมถึงจัดการกระบวนการการยืนยันตัวตน (การยืนยันตัวตน (Authentication)) และการอนุญาต (การอนุญาต (Authorization)) สำหรับผู้ใช้ที่เข้าถึงแอปพลิเคชันเหล่านั้น -การใช้แอปพลิเคชันในประสบการณ์การลงชื่อเข้าใช้ของ Logto ช่วยให้ผู้ใช้เข้าถึงและจัดการแอปพลิเคชันที่ได้รับอนุญาตได้อย่างง่ายดายจากที่เดียว ด้วยกระบวนการยืนยันตัวตนที่สม่ำเสมอและปลอดภัย ช่วยให้ประสบการณ์ผู้ใช้ราบรื่นและมั่นใจได้ว่ามีเพียงบุคคลที่ได้รับอนุญาตเท่านั้นที่เข้าถึงข้อมูลสำคัญหรือดำเนินการในนามขององค์กร +การใช้แอปพลิเคชันในประสบการณ์การลงชื่อเข้าใช้ของ Logto ช่วยให้ผู้ใช้สามารถเข้าถึงและจัดการแอปพลิเคชันที่ได้รับอนุญาตของตนได้อย่างง่ายดายจากที่เดียว ด้วยกระบวนการยืนยันตัวตนที่สม่ำเสมอและปลอดภัย สิ่งนี้ช่วยให้ประสบการณ์ผู้ใช้ราบรื่นและมั่นใจได้ว่ามีเพียงบุคคลที่ได้รับอนุญาตเท่านั้นที่สามารถเข้าถึงข้อมูลสำคัญหรือดำเนินการในนามขององค์กร -แอปพลิเคชันยังถูกใช้ในบันทึกการตรวจสอบ (audit logs) ของ Logto เพื่อติดตามกิจกรรมของผู้ใช้และระบุภัยคุกคามหรือการละเมิดความปลอดภัยที่อาจเกิดขึ้น โดยการเชื่อมโยงการกระทำเฉพาะกับแอปพลิเคชัน Logto สามารถให้ข้อมูลเชิงลึกอย่างละเอียดเกี่ยวกับวิธีการเข้าถึงและใช้งานข้อมูล ช่วยให้องค์กรจัดการข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดได้ดียิ่งขึ้น +แอปพลิเคชันยังถูกใช้ในบันทึกการตรวจสอบ (audit logs) ของ Logto เพื่อบันทึกกิจกรรมของผู้ใช้และระบุภัยคุกคามหรือการละเมิดความปลอดภัยที่อาจเกิดขึ้น โดยการเชื่อมโยงการกระทำเฉพาะกับแอปพลิเคชัน Logto สามารถให้ข้อมูลเชิงลึกอย่างละเอียดเกี่ยวกับวิธีการเข้าถึงและใช้งานข้อมูล ช่วยให้องค์กรจัดการข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดได้ดียิ่งขึ้น หากคุณต้องการผสานรวมแอปพลิเคชันของคุณกับ Logto ดูที่ [Integrate Logto](/integrate-logto) ## คุณสมบัติ \{#properties} @@ -20,46 +20,50 @@ sidebar_position: 7 _Application ID_ คือคีย์ที่สร้างขึ้นโดยอัตโนมัติและไม่ซ้ำกันเพื่อระบุแอปพลิเคชันของคุณใน Logto และถูกอ้างถึงว่าเป็น [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/) ใน OAuth 2.0 +:::note +[Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) client จะไม่ได้ลงทะเบียนใน Logto โดย client ID ของพวกเขาคือ URL HTTPS สาธารณะที่เป็นของ client ซึ่งใช้สำหรับให้บริการ client metadata document +::: + ### ประเภทของแอปพลิเคชัน \{#application-types} -_แอปพลิเคชัน_ สามารถเป็นประเภทใดประเภทหนึ่งต่อไปนี้: +_แอปพลิเคชัน_ สามารถเป็นหนึ่งในประเภทต่อไปนี้: -- **Native app** คือแอปที่ทำงานในสภาพแวดล้อมเนทีฟ เช่น iOS app, Android app - - **Device flow app** คือ native app ประเภทพิเศษสำหรับอุปกรณ์ที่จำกัดการป้อนข้อมูลหรือแอปพลิเคชันแบบไม่มีหัว (headless) (เช่น สมาร์ททีวี, เกมคอนโซล, CLI tools, IoT devices) ใช้ [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) แทน flow แบบ redirect มาตรฐาน ดู [Device flow quick start](/quick-starts/device-flow) สำหรับรายละเอียด +- **Native app** คือแอปที่ทำงานในสภาพแวดล้อม native เช่น iOS app, Android app + - **Device flow app** คือ native app ประเภทพิเศษสำหรับอุปกรณ์ที่มีข้อจำกัดในการป้อนข้อมูลหรือแอปพลิเคชันแบบไม่มีหัว (headless) (เช่น สมาร์ททีวี, เครื่องเล่นเกม, CLI tools, อุปกรณ์ IoT) โดยใช้ [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) แทน flow แบบ redirect มาตรฐาน ดู [Device flow quick start](/quick-starts/device-flow) สำหรับรายละเอียด - **Single page app** คือแอปที่ทำงานในเว็บเบราว์เซอร์ ซึ่งอัปเดตหน้าเว็บด้วยข้อมูลใหม่จากเซิร์ฟเวอร์โดยไม่ต้องโหลดหน้าใหม่ทั้งหมด เช่น React DOM app, Vue app -- **Traditional web app** คือแอปที่เรนเดอร์และอัปเดตหน้าเว็บโดยเว็บเซิร์ฟเวอร์เท่านั้น เช่น JSP, PHP -- **Machine-to-machine (M2M) app** คือแอปพลิเคชันที่ทำงานในสภาพแวดล้อมของเครื่องเพื่อสื่อสารระหว่างบริการโดยตรงโดยไม่ต้องมีการโต้ตอบกับผู้ใช้ +- **Traditional web app** คือแอปที่เรนเดอร์และอัปเดตหน้าเว็บโดยเซิร์ฟเวอร์เพียงอย่างเดียว เช่น JSP, PHP +- **Machine-to-machine (M2M) app** คือแอปพลิเคชันที่ทำงานในสภาพแวดล้อมของเครื่องสำหรับการสื่อสารระหว่างบริการโดยตรงโดยไม่ต้องมีการโต้ตอบกับผู้ใช้ ### Application secret \{#application-secret} -_Application secret_ คือคีย์ที่ใช้ยืนยันตัวตนของแอปพลิเคชันในระบบการยืนยันตัวตน โดยเฉพาะสำหรับ private clients (Traditional Web และ M2M apps) เพื่อเป็นกำแพงความปลอดภัยส่วนตัว +_Application secret_ คือคีย์ที่ใช้ในการยืนยันตัวตนของแอปพลิเคชันในระบบการยืนยันตัวตน โดยเฉพาะสำหรับ private client (Traditional Web และ M2M apps) เพื่อเป็นกำแพงความปลอดภัยส่วนตัว :::tip -Single Page Apps (SPAs) และ Native apps จะไม่มี App secret เนื่องจาก SPAs และ Native apps เป็น "public clients" และไม่สามารถเก็บความลับได้ (โค้ดเบราว์เซอร์หรือ app bundle สามารถถูกตรวจสอบได้) แทนที่จะใช้ app secret, Logto ปกป้องด้วย PKCE, การตรวจสอบ redirect URI/CORS อย่างเข้มงวด, access token อายุสั้น และการหมุนเวียน refresh-token +Single Page Apps (SPAs) และ Native apps จะไม่มี App secret เนื่องจาก SPAs และ Native apps เป็น "public clients" และไม่สามารถเก็บความลับได้ (โค้ดเบราว์เซอร์หรือ app bundle สามารถถูกตรวจสอบได้) แทนที่จะใช้ app secret, Logto ปกป้องพวกเขาด้วย PKCE, การตรวจสอบ redirect URI/CORS อย่างเข้มงวด, โทเค็นการเข้าถึงอายุสั้น และการหมุนเวียนโทเค็นรีเฟรช ::: -### Application name \{#application-name} +### ชื่อแอปพลิเคชัน \{#application-name} -_Application name_ คือชื่อที่มนุษย์อ่านเข้าใจได้ของแอปพลิเคชันและจะแสดงใน admin console +_ชื่อแอปพลิเคชัน_ คือชื่อที่มนุษย์อ่านเข้าใจได้ของแอปพลิเคชันและจะแสดงใน admin console -_Application name_ เป็นองค์ประกอบสำคัญในการจัดการแอปพลิเคชันใน Logto เพราะช่วยให้ผู้ดูแลระบบระบุและติดตามกิจกรรมของแต่ละแอปพลิเคชันในแพลตฟอร์มได้อย่างง่ายดาย +_ชื่อแอปพลิเคชัน_ เป็นองค์ประกอบสำคัญในการจัดการแอปพลิเคชันใน Logto เพราะช่วยให้ผู้ดูแลระบบสามารถระบุและติดตามกิจกรรมของแต่ละแอปพลิเคชันในแพลตฟอร์มได้อย่างง่ายดาย :::note -ควรเลือก _Application name_ อย่างระมัดระวัง เพราะจะแสดงให้ผู้ใช้ทุกคนที่เข้าถึง admin console เห็น ควรสะท้อนวัตถุประสงค์และฟังก์ชันของแอปพลิเคชันอย่างถูกต้อง และเข้าใจง่าย +ควรเลือก _ชื่อแอปพลิเคชัน_ อย่างระมัดระวัง เนื่องจากจะแสดงให้ผู้ใช้ทุกคนที่เข้าถึง admin console เห็น ควรสะท้อนวัตถุประสงค์และหน้าที่ของแอปพลิเคชันอย่างถูกต้อง และเข้าใจง่าย ::: -### คำอธิบาย (Description) \{#description} +### คำอธิบาย \{#description} -คำอธิบายสั้น ๆ ของแอปพลิเคชันจะแสดงในหน้าแสดงรายละเอียดแอปพลิเคชันใน admin console คำอธิบายนี้มีไว้เพื่อให้ข้อมูลเพิ่มเติมแก่ผู้ดูแลระบบ เช่น วัตถุประสงค์ ฟังก์ชันการทำงาน และรายละเอียดอื่น ๆ ที่เกี่ยวข้อง +คำอธิบายสั้น ๆ ของแอปพลิเคชันจะแสดงในหน้ารายละเอียดแอปพลิเคชันของ admin console คำอธิบายนี้มีไว้เพื่อให้ข้อมูลเพิ่มเติมแก่ผู้ดูแลระบบเกี่ยวกับแอปพลิเคชัน เช่น วัตถุประสงค์ ฟังก์ชันการทำงาน และรายละเอียดอื่น ๆ ที่เกี่ยวข้อง ### Redirect URIs \{#redirect-uris} -_Redirect URIs_ คือรายการของ redirect URIs ที่ถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชัน เมื่อผู้ใช้ลงชื่อเข้าใช้ Logto และพยายามเข้าถึงแอปพลิเคชัน จะถูกเปลี่ยนเส้นทางไปยัง URI ที่อนุญาตซึ่งระบุไว้ในการตั้งค่าแอปพลิเคชัน +_Redirect URIs_ คือรายการของ redirect URIs ที่ถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชัน เมื่อผู้ใช้ลงชื่อเข้าใช้ Logto และพยายามเข้าถึงแอปพลิเคชัน พวกเขาจะถูกเปลี่ยนเส้นทางไปยังหนึ่งใน URIs ที่อนุญาตซึ่งระบุไว้ในการตั้งค่าแอปพลิเคชัน -รายการ URI ที่อนุญาตนี้ใช้เพื่อตรวจสอบ redirect URI ที่รวมอยู่ในคำขอการอนุญาต (Authorization request) ที่แอปพลิเคชันส่งไปยัง Logto ระหว่างกระบวนการยืนยันตัวตน หาก redirect URI ที่ระบุในคำขอการอนุญาตตรงกับ URI ที่อนุญาตในแอปพลิเคชัน ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง URI นั้นหลังจากยืนยันตัวตนสำเร็จ หาก redirect URI ไม่อยู่ในรายการที่อนุญาต ผู้ใช้จะไม่ได้รับการเปลี่ยนเส้นทางและกระบวนการยืนยันตัวตนจะล้มเหลว +รายการ URIs ที่อนุญาตนี้ใช้สำหรับตรวจสอบ redirect URI ที่รวมอยู่ในคำขอการอนุญาตที่แอปพลิเคชันส่งไปยัง Logto ระหว่างกระบวนการยืนยันตัวตน หาก redirect URI ที่ระบุในคำขอการอนุญาตตรงกับหนึ่งใน URIs ที่อนุญาตในแอปพลิเคชัน ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง URI นั้นหลังจากยืนยันตัวตนสำเร็จ หาก redirect URI ไม่อยู่ในรายการที่อนุญาต ผู้ใช้จะไม่ถูกเปลี่ยนเส้นทางและกระบวนการยืนยันตัวตนจะล้มเหลว :::note -ควรตรวจสอบให้แน่ใจว่าได้เพิ่ม redirect URIs ที่ถูกต้องทั้งหมดลงในรายการที่อนุญาตของแอปพลิเคชันใน Logto เพื่อให้ผู้ใช้สามารถเข้าถึงแอปพลิเคชันได้สำเร็จหลังจากยืนยันตัวตน +สิ่งสำคัญคือต้องแน่ใจว่า redirect URIs ที่ถูกต้องทั้งหมดถูกเพิ่มในรายการที่อนุญาตสำหรับแอปพลิเคชันใน Logto เพื่อให้ผู้ใช้สามารถเข้าถึงแอปพลิเคชันได้สำเร็จหลังจากยืนยันตัวตน ::: คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) @@ -70,14 +74,14 @@ _Redirect URIs_ คือรายการของ redirect URIs ที่ถ #### รูปแบบ Wildcard \{#wildcard-patterns} -_ใช้งานได้กับ: Single page app, Traditional web app_ +_รองรับ: Single page app, Traditional web app_ -Redirect URIs รองรับรูปแบบ wildcard (`*`) สำหรับสภาพแวดล้อมแบบไดนามิก เช่น การ deploy แบบ preview สามารถใช้ wildcard ในส่วน hostname และ pathname ของ HTTP/HTTPS URIs +Redirect URIs รองรับรูปแบบ wildcard (`*`) สำหรับสภาพแวดล้อมแบบไดนามิก เช่น การ deploy แบบ preview โดยสามารถใช้ wildcard ในส่วน hostname และ pathname ของ HTTP/HTTPS URIs **กฎ:** -- อนุญาต wildcard เฉพาะใน hostname และ pathname เท่านั้น -- ไม่อนุญาต wildcard ใน scheme, port, query parameters หรือ hash fragments +- อนุญาตให้ใช้ wildcard เฉพาะใน hostname และ pathname เท่านั้น +- ไม่อนุญาตให้ใช้ wildcard ใน scheme, port, query parameters หรือ hash fragments - wildcard ใน hostname ต้องมีอย่างน้อยหนึ่งจุด (เช่น `https://*.example.com/callback`) **ตัวอย่าง:** @@ -92,19 +96,19 @@ Wildcard redirect URIs ไม่ใช่มาตรฐาน OIDC และอ ### Post sign-out redirect URIs \{#post-sign-out-redirect-uris} -_Post sign-out redirect URIs_ คือรายการ URI ที่อนุญาตล่วงหน้าสำหรับแอปพลิเคชันเพื่อเปลี่ยนเส้นทางผู้ใช้หลังจากออกจากระบบ Logto +_Post sign-out redirect URIs_ คือรายการ URIs ที่ถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชันเพื่อเปลี่ยนเส้นทางผู้ใช้หลังจากที่พวกเขาออกจากระบบ Logto -การใช้ Allowed _Post Sign-out Redirect URIs_ สำหรับ Logout เป็นส่วนหนึ่งของข้อกำหนด RP-Initiated (Relying Party Initiated) Logout ใน OIDC ข้อกำหนดนี้ให้วิธีมาตรฐานสำหรับแอปพลิเคชันในการเริ่มคำขอออกจากระบบสำหรับผู้ใช้ ซึ่งรวมถึงการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่กำหนดไว้ล่วงหน้าหลังจากออกจากระบบ +การใช้ Allowed _Post Sign-out Redirect URIs_ สำหรับ Logout เป็นส่วนหนึ่งของข้อกำหนด RP-Initiated (Relying Party Initiated) Logout ใน OIDC ข้อกำหนดนี้ให้วิธีมาตรฐานสำหรับแอปพลิเคชันในการเริ่มต้นคำขอออกจากระบบสำหรับผู้ใช้ ซึ่งรวมถึงการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่กำหนดไว้ล่วงหน้าหลังจากออกจากระบบ -เมื่อผู้ใช้ออกจากระบบ Logto เซสชันของเขาจะสิ้นสุดและถูกเปลี่ยนเส้นทางไปยัง URI ที่อนุญาตในแอปพลิเคชัน เพื่อให้แน่ใจว่าผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง endpoint ที่ได้รับอนุญาตและถูกต้องเท่านั้นหลังจากออกจากระบบ ช่วยป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตและความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับการเปลี่ยนเส้นทางไปยัง endpoint ที่ไม่รู้จักหรือไม่ได้รับการตรวจสอบ +เมื่อผู้ใช้ออกจากระบบ Logto เซสชันของพวกเขาจะถูกยุติและพวกเขาจะถูกเปลี่ยนเส้นทางไปยังหนึ่งใน URIs ที่อนุญาตที่ระบุไว้ในการตั้งค่าแอปพลิเคชัน เพื่อให้แน่ใจว่าผู้ใช้จะถูกนำทางไปยัง endpoint ที่ได้รับอนุญาตและถูกต้องเท่านั้นหลังจากออกจากระบบ ช่วยป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตและความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่ไม่รู้จักหรือไม่ได้รับการตรวจสอบ -ดูข้อมูลเพิ่มเติมได้ที่ [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) +คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) ### CORS allowed origins \{#cors-allowed-origins} -_CORS (Cross-origin resource sharing) allowed origins_ คือรายการ origin ที่อนุญาตให้แอปพลิเคชันสามารถส่งคำขอไปยังบริการ Logto ได้ Origin ที่ไม่ได้อยู่ในรายการนี้จะไม่สามารถส่งคำขอไปยังบริการ Logto ได้ +_CORS (Cross-origin resource sharing) allowed origins_ คือรายการ origin ที่อนุญาตให้แอปพลิเคชันสามารถส่งคำขอไปยังบริการ Logto ได้ Origin ที่ไม่ได้อยู่ในรายการที่อนุญาตจะไม่สามารถส่งคำขอไปยังบริการ Logto ได้ -รายการ CORS allowed origins ใช้เพื่อจำกัดการเข้าถึงบริการ Logto จากโดเมนที่ไม่ได้รับอนุญาต และช่วยป้องกันการโจมตีแบบ cross-site request forgery (CSRF) โดยการระบุ origin ที่อนุญาตสำหรับแอปพลิเคชันใน Logto บริการจะมั่นใจได้ว่ามีเพียงโดเมนที่ได้รับอนุญาตเท่านั้นที่สามารถส่งคำขอได้ +รายการ CORS allowed origins ใช้เพื่อจำกัดการเข้าถึงบริการ Logto จากโดเมนที่ไม่ได้รับอนุญาต และช่วยป้องกันการโจมตีแบบ cross-site request forgery (CSRF) โดยการระบุ origin ที่อนุญาตสำหรับแอปพลิเคชันใน Logto บริการจะมั่นใจได้ว่าเฉพาะโดเมนที่ได้รับอนุญาตเท่านั้นที่สามารถส่งคำขอไปยังบริการได้ :::note รายการ allowed origins ควรมี origin ที่แอปพลิเคชันจะถูกให้บริการ เพื่อให้แน่ใจว่าคำขอจากแอปพลิเคชันจะได้รับอนุญาต ในขณะที่คำขอจาก origin ที่ไม่ได้รับอนุญาตจะถูกบล็อก @@ -116,17 +120,17 @@ Endpoint สำหรับ [OpenID Connect Discovery](https://openid.net/specs/ ### Authorization endpoint \{#authorization-endpoint} -_Authorization Endpoint_ เป็นคำศัพท์ของ OIDC และเป็น endpoint ที่จำเป็นสำหรับเริ่มกระบวนการยืนยันตัวตน (Authentication) ของผู้ใช้ เมื่อผู้ใช้พยายามเข้าถึงทรัพยากรหรือแอปพลิเคชันที่ได้รับการลงทะเบียนกับ Logto จะถูกเปลี่ยนเส้นทางไปยัง _Authorization Endpoint_ เพื่อยืนยันตัวตนและขออนุญาตเข้าถึงทรัพยากรที่ร้องขอ +_Authorization Endpoint_ เป็นคำศัพท์ของ OIDC และเป็น endpoint ที่จำเป็นสำหรับเริ่มต้นกระบวนการยืนยันตัวตนของผู้ใช้ เมื่อผู้ใช้พยายามเข้าถึงทรัพยากรหรือแอปพลิเคชันที่ได้รับการลงทะเบียนกับแพลตฟอร์ม Logto พวกเขาจะถูกเปลี่ยนเส้นทางไปยัง _Authorization Endpoint_ เพื่อยืนยันตัวตนและขออนุญาตเข้าถึงทรัพยากรที่ร้องขอ -ดูข้อมูลเพิ่มเติมได้ที่ [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) +คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) ### Token endpoint \{#token-endpoint} _Token Endpoint_ เป็นคำศัพท์ของ OIDC เป็น endpoint ของ API ที่ใช้โดย OIDC client เพื่อขอรับโทเค็นการเข้าถึง (Access token), โทเค็น ID (ID token) หรือโทเค็นรีเฟรช (Refresh token) จาก OIDC provider -เมื่อ OIDC client ต้องการขอรับ access token หรือ ID token จะส่งคำขอไปยัง Token Endpoint พร้อม authorization grant ซึ่งโดยทั่วไปคือ authorization code หรือ refresh token จากนั้น Token Endpoint จะตรวจสอบ authorization grant และออก access token หรือ ID token ให้ client หาก grant ถูกต้อง +เมื่อ OIDC client ต้องการขอรับโทเค็นการเข้าถึงหรือ ID token จะส่งคำขอไปยัง Token Endpoint พร้อม authorization grant ซึ่งโดยปกติจะเป็น authorization code หรือ refresh token จากนั้น Token Endpoint จะตรวจสอบ authorization grant และออกโทเค็นการเข้าถึงหรือ ID token ให้ client หาก grant ถูกต้อง -ดูข้อมูลเพิ่มเติมได้ที่ [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) +คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) ### Userinfo endpoint \{#userinfo-endpoint} @@ -134,60 +138,60 @@ OpenID Connect [UserInfo Endpoint](https://openid.net/specs/openid-connect-core- ### Always issue refresh token \{#always-issue-refresh-token} -_ใช้งานได้กับ: Traditional web, SPA_ +_รองรับ: Traditional web, SPA_ -เมื่อเปิดใช้งาน Logto จะออกโทเค็นรีเฟรช (Refresh tokens) เสมอ ไม่ว่าจะมี `prompt=consent` ในคำขอการยืนยันตัวตนหรือไม่ หรือมี `offline_access` ในขอบเขต (Scopes) หรือไม่ก็ตาม +เมื่อเปิดใช้งาน Logto จะออกโทเค็นรีเฟรช (Refresh token) เสมอ ไม่ว่าจะมี `prompt=consent` ในคำขอการยืนยันตัวตนหรือไม่ หรือมี `offline_access` ในขอบเขต (scopes) หรือไม่ก็ตาม -อย่างไรก็ตาม ไม่แนะนำให้ใช้วิธีนี้เว้นแต่จำเป็น (โดยปกติใช้กับการผสานรวม OAuth ของบุคคลที่สามที่ต้องการ refresh token) เพราะไม่สอดคล้องกับ OpenID Connect และอาจทำให้เกิดปัญหาได้ +อย่างไรก็ตาม ไม่แนะนำให้ใช้แนวทางนี้เว้นแต่จำเป็น (โดยปกติจะใช้กับการผสานรวม OAuth ของบุคคลที่สามบางรายที่ต้องการ refresh token) เนื่องจากไม่สอดคล้องกับ OpenID Connect และอาจทำให้เกิดปัญหาได้ ### Rotate refresh token \{#rotate-refresh-token} _ค่าเริ่มต้น: `true`_ -เมื่อเปิดใช้งาน Logto อาจออก refresh token ใหม่เมื่อ client ใช้ refresh token เพื่อขอโทเค็นใหม่ หาก refresh token และ app grant ยังใช้ได้ นโยบายการหมุนเวียนเริ่มต้นคือ: +เมื่อเปิดใช้งาน Logto อาจออกโทเค็นรีเฟรชใหม่เมื่อ client ใช้ refresh token เพื่อขอโทเค็นใหม่ หาก refresh token และ app grant ของมันยังคงถูกต้อง นโยบายการหมุนเวียนเริ่มต้นคือ: -- Refresh tokens สามารถหมุนเวียนได้เฉพาะก่อนที่โซ่ refresh token จะมีอายุครบหนึ่งปี นี่คือขีดจำกัดความปลอดภัยภายใน; TTL ของ refresh token หรือ TTL ของ app grant อาจหมดอายุก่อน เมื่อถึงขีดจำกัด Logto จะไม่หมุนเวียน refresh token อีกต่อไป และ refresh token ปัจจุบันจะหมดอายุเป็นครั้งสุดท้าย -- สำหรับ public clients ที่ไม่ใช้ sender-constrained refresh tokens (เช่น Native applications ทั่วไปและ single page applications) Logto จะหมุนเวียน refresh token ทุกครั้งที่มีการร้องขอ refresh token ในขณะที่อนุญาตให้หมุนเวียน -- สำหรับ client อื่น ๆ Logto จะหมุนเวียน refresh token เฉพาะเมื่อใกล้หมดอายุ (>=70% ของ TTL เดิมผ่านไปแล้ว) +- โทเค็นรีเฟรชสามารถหมุนเวียนได้เฉพาะก่อนที่ chain ของ refresh token จะมีอายุครบหนึ่งปี นี่คือขีดจำกัดความปลอดภัยภายใน; TTL ของ refresh token หรือ TTL ของ app grant อาจหมดอายุก่อนถึงขีดจำกัดนี้ หลังจากถึงขีดจำกัด Logto จะไม่หมุนเวียน refresh token อีกต่อไป และ refresh token ปัจจุบันจะหมดอายุเป็นครั้งสุดท้าย +- สำหรับ public client ที่ไม่ได้ใช้ sender-constrained refresh token (เช่น Native app ปกติและ single page app) Logto จะหมุนเวียน refresh token ทุกครั้งที่มีการร้องขอ refresh token ในขณะที่ยังอนุญาตให้หมุนเวียน +- สำหรับ client อื่น ๆ Logto จะหมุนเวียน refresh token เฉพาะเมื่อใกล้หมดอายุ (>=70% ของ TTL เดิมได้ผ่านไปแล้ว) :::note -สำหรับ public clients แนะนำอย่างยิ่งให้เปิดใช้งาน refresh token rotation เพื่อความปลอดภัย +สำหรับ public client ขอแนะนำอย่างยิ่งให้เปิดใช้งานการหมุนเวียน refresh token เพื่อเหตุผลด้านความปลอดภัย -Sender-constrained refresh tokens จะผูกกับ proof key หรือ certificate ที่ client ถืออยู่ สำหรับ SPA ทั่วไป การหมุนเวียนจะออก refresh token ใหม่แต่จะไม่ขยายอายุ refresh token ใหม่ refresh token ใหม่นี้จะสืบทอด TTL ที่เหลือของ refresh token ก่อนหน้า +Sender-constrained refresh token จะผูกกับ proof key หรือ certificate ที่ client ถืออยู่ สำหรับ SPA ปกติ การหมุนเวียนจะออก refresh token ใหม่แต่จะไม่ขยายอายุ refresh token ใหม่ refresh token ใหม่นี้จะสืบทอด TTL ที่เหลือของ refresh token ก่อนหน้า ::: -:::caution อายุโซ่ refresh token -Refresh tokens จะเชื่อมโยงกับ app grant โดย TTL ของ grant ใน Logto เริ่มต้นคือ **180 วัน** เมื่อ grant หมดอายุ คำขอ refresh token จะล้มเหลวและไม่สามารถใช้ refresh token เพื่อขอโทเค็นใหม่ได้อีก แม้จะเปิดใช้งาน refresh token rotation ก็ตาม +:::caution อายุของ refresh token chain +Refresh token จะเชื่อมโยงกับ app grant โดย TTL ของ grant ใน Logto เริ่มต้นคือ **180 วัน** เมื่อ grant หมดอายุ คำขอ refresh token จะล้มเหลวและไม่สามารถใช้ refresh token เพื่อขอโทเค็นใหม่ได้อีก แม้ว่าจะเปิดใช้งานการหมุนเวียน refresh token ก็ตาม -นั่นหมายความว่า อายุสูงสุดของการอนุญาตที่รองรับ refresh token จะถูกจำกัดโดย TTL ของ grant, การเพิกถอนโดยตรง หรือ TTL ของ refresh token แล้วแต่กรณีใดจะเกิดก่อน +นั่นหมายความว่า อายุสูงสุดในทางปฏิบัติของการอนุญาตที่รองรับ refresh token จะถูกจำกัดด้วย TTL ของ grant, การเพิกถอนโดยตรง หรือการหมดอายุของ refresh token แล้วแต่กรณีใดจะเกิดขึ้นก่อน ::: - ทำความเข้าใจ refresh token rotation + ทำความเข้าใจการหมุนเวียน refresh token ### Refresh token time-to-live (TTL) เป็นวัน \{#refresh-token-time-to-live-ttl-in-days} -_ใช้งานได้กับ: Native app, Traditional web, SPA; ค่าเริ่มต้น: 14 วัน; สูงสุด: 180 วัน_ +_รองรับ: Native app, Traditional web, SPA; ค่าเริ่มต้น: 14 วัน; สูงสุด: 180 วัน_ -ระยะเวลาที่ refresh token สามารถใช้ขอโทเค็นการเข้าถึงใหม่ก่อนจะหมดอายุและใช้ไม่ได้อีก คำขอโทเค็นจะขยาย TTL ของ refresh token เป็นค่านี้ +ระยะเวลาที่ refresh token สามารถใช้ขอโทเค็นการเข้าถึงใหม่ได้ก่อนที่จะหมดอายุและกลายเป็นโมฆะ คำขอโทเค็นจะขยาย TTL ของ refresh token เป็นค่านี้ โดยทั่วไป ค่าที่ต่ำกว่าจะดีกว่า :::note -การต่ออายุ TTL ของ refresh token จะไม่สามารถใช้ได้ใน single-page applications (SPAs) ด้วยเหตุผลด้านความปลอดภัย สำหรับ SPA การตั้งค่านี้จะควบคุมอายุ refresh token แบบคงที่นับจากเวลาที่ออกครั้งแรก Logto จะไม่ขยาย TTL ผ่านคำขอโทเค็น และการหมุนเวียน refresh token จะไม่ป้องกัน refresh token ของ SPA จากการหมดอายุ +การต่ออายุ TTL ของ refresh token ไม่สามารถใช้ได้ใน single-page applications (SPAs) ด้วยเหตุผลด้านความปลอดภัย สำหรับ SPA การตั้งค่านี้จะควบคุมอายุ refresh token แบบคงที่นับจากเวลาที่ออกครั้งแรก Logto จะไม่ขยาย TTL ผ่านคำขอโทเค็น และการหมุนเวียน refresh token จะไม่ป้องกัน refresh token ของ SPA จากการหมดอายุ ::: -:::caution TTL ของ refresh token และ TTL ของ grant -TTL ของ refresh token ไม่ใช่ขีดจำกัดการหมดอายุเพียงอย่างเดียว Refresh tokens จะผูกกับ app grant และ TTL ของ grant ใน Logto เริ่มต้นคือ **180 วัน** เมื่อ grant หมดอายุ คำขอ refresh token จะล้มเหลวแม้ว่า refresh token จะยังไม่หมดอายุก็ตาม +:::caution Refresh token TTL และ grant TTL +Refresh token TTL ไม่ใช่ขีดจำกัดการหมดอายุเพียงอย่างเดียว Refresh token จะผูกกับ app grant และ TTL ของ grant ใน Logto เริ่มต้นคือ **180 วัน** เมื่อ grant หมดอายุ คำขอ refresh token จะล้มเหลวแม้ว่า refresh token จะยังไม่หมดอายุก็ตาม -สำหรับ client ที่คำขอโทเค็นจะต่ออายุ TTL ของ refresh token, TTL ของ grant จะเป็นอายุสูงสุดของโซ่ refresh token สำหรับ SPA, TTL แบบคงที่ของ refresh token อาจหมดอายุก่อน grant +สำหรับ client ที่คำขอโทเค็นจะต่ออายุ refresh token TTL, grant TTL จะเป็นอายุสูงสุดของ refresh token chain สำหรับ SPA, refresh token อาจหมดอายุก่อน grant ::: -:::caution Refresh token และการผูกกับ session -เมื่อ refresh token ถูกออกโดย **ไม่มี** ขอบเขต `offline_access` ในคำขอการอนุญาต มันจะถูกผูกกับ session ของผู้ใช้ โดย session มี TTL คงที่ **14 วัน** เมื่อ session หมดอายุ refresh token จะใช้ไม่ได้ไม่ว่า TTL ของมันจะตั้งไว้เท่าใดก็ตาม +:::caution Refresh token และ session binding +เมื่อ refresh token ถูกออกโดย **ไม่มี** ขอบเขต `offline_access` ในคำขอการอนุญาต มันจะถูกผูกกับ session ของผู้ใช้ โดย session มี TTL คงที่ **14 วัน** หลังจาก session หมดอายุ refresh token จะกลายเป็นโมฆะโดยไม่คำนึงถึงการตั้งค่า TTL ของมันเอง -เพื่อให้ TTL ของ refresh token มีผลเต็มที่ ให้แน่ใจว่าได้ใส่ขอบเขต `offline_access` ในคำขอการอนุญาตของคุณ +เพื่อให้แน่ใจว่า refresh token TTL มีผลเต็มที่ ให้แน่ใจว่าคุณรวมขอบเขต `offline_access` ในคำขอการอนุญาตของคุณ ::: ### Backchannel logout URI \{#backchannel-logout-uri} @@ -201,7 +205,7 @@ Endpoint backchannel logout ของ OpenID Connect ดู [Federated sign-out: - **ค่าเริ่มต้น**: `undefined` (ไม่จำกัด) - **เมื่อกำหนดค่า**: ทุกครั้งที่อนุญาตสำเร็จ Logto จะตรวจสอบจำนวน grant ที่ใช้งานทั้งหมดของผู้ใช้ในแอปปัจจุบัน (ข้ามเบราว์เซอร์และอุปกรณ์) หากเกินขีดจำกัด Logto จะเพิกถอน grant ที่เก่าที่สุด -การตั้งค่านี้มีประโยชน์เมื่อคุณต้องการจำกัดจำนวนอุปกรณ์ที่ยืนยันตัวตนพร้อมกันต่อแอป +การตั้งค่านี้มีประโยชน์เมื่อคุณต้องการจำกัดจำนวนอุปกรณ์ที่รับรองความถูกต้องพร้อมกันต่อแอป ทุกครั้งที่มีการขับไล่ (eviction) จะทริกเกอร์เหตุการณ์ webhook `Grant.LimitExceeded` [webhook event](/developers/webhooks/webhooks-events#exception-hook-events) เพื่อให้คุณแจ้งผู้ใช้หรือบันทึกความถี่ที่ถึงขีดจำกัด @@ -215,6 +219,6 @@ Endpoint backchannel logout ของ OpenID Connect ดู [Federated sign-out: ::: -### ข้อมูลกำหนดเอง (Custom data) \{#custom-data} +### ข้อมูลกำหนดเอง \{#custom-data} -ข้อมูลเพิ่มเติมของแอปพลิเคชันที่ไม่ได้อยู่ในคุณสมบัติที่กำหนดไว้ล่วงหน้า ผู้ใช้สามารถกำหนดฟิลด์ข้อมูลกำหนดเองตามความต้องการเฉพาะ เช่น การตั้งค่าทางธุรกิจหรือการกำหนดค่าพิเศษอื่น ๆ +ข้อมูลแอปพลิเคชันเพิ่มเติมที่ไม่ได้อยู่ในคุณสมบัติที่กำหนดไว้ล่วงหน้า ผู้ใช้สามารถกำหนดฟิลด์ข้อมูลกำหนดเองตามความต้องการเฉพาะ เช่น การตั้งค่าทางธุรกิจหรือการกำหนดค่าต่าง ๆ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 1a100e6a4fb..de4bdf20f3a 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,6 +4,7 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; @@ -14,36 +15,43 @@ import Tabs from '@theme/Tabs'; ผู้ให้บริการข้อมูลระบุตัวตน (IdP) คือบริการที่ตรวจสอบตัวตนของผู้ใช้และจัดการข้อมูลรับรองการเข้าสู่ระบบของพวกเขา หลังจากยืนยันตัวตนของผู้ใช้แล้ว IdP จะสร้างโทเค็นการยืนยันตัวตนหรือ assertion และอนุญาตให้ผู้ใช้เข้าถึงแอปพลิเคชันหรือบริการต่าง ๆ ได้โดยไม่ต้องเข้าสู่ระบบซ้ำอีก -แตกต่างจากแอปพลิเคชันที่คุณสร้างในคู่มือ [ผสานรวม Logto เข้ากับแอปพลิเคชันของคุณ](/integrate-logto/integrate-logto-into-your-application) ซึ่งคุณพัฒนาและควบคุมได้อย่างสมบูรณ์ แอปพลิเคชันบุคคลที่สามเป็นบริการอิสระที่พัฒนาโดยนักพัฒนาภายนอกหรือพันธมิตรทางธุรกิจ +แตกต่างจากแอปพลิเคชันที่คุณสร้างในคู่มือ [ผสานรวม Logto เข้ากับแอปของคุณ](/integrate-logto/integrate-logto-into-your-application) ซึ่งคุณเป็นผู้พัฒนาและควบคุมโดยสมบูรณ์ แอปพลิเคชันบุคคลที่สามเป็นบริการอิสระที่พัฒนาโดยนักพัฒนาภายนอกหรือพันธมิตรทางธุรกิจ -แนวทางการผสานรวมนี้เหมาะกับสถานการณ์ทางธุรกิจทั่วไป คุณสามารถเปิดให้ผู้ใช้เข้าถึงแอปพลิเคชันของพันธมิตรโดยใช้บัญชี Logto ของตน เช่นเดียวกับที่ผู้ใช้ในองค์กรลงชื่อเข้าใช้ Slack ด้วย Google Workspace หรือคุณสามารถสร้างแพลตฟอร์มเปิดที่แอปพลิเคชันบุคคลที่สามสามารถเพิ่มฟีเจอร์ “ลงชื่อเข้าใช้ด้วย Logto” ได้ คล้ายกับ “ลงชื่อเข้าใช้ด้วย Google” +แนวทางการผสานรวมนี้เหมาะกับสถานการณ์ทางธุรกิจทั่วไป คุณสามารถเปิดให้ผู้ใช้เข้าถึงแอปของพันธมิตรโดยใช้บัญชี Logto ของตนเอง เช่นเดียวกับที่ผู้ใช้ระดับองค์กรลงชื่อเข้าใช้ Slack ด้วย Google Workspace หรือคุณสามารถสร้างแพลตฟอร์มเปิดที่แอปบุคคลที่สามสามารถเพิ่มฟีเจอร์ “Sign in with Logto” ได้ คล้ายกับ “Sign in with Google” -Logto เป็นบริการข้อมูลระบุตัวตนที่สร้างขึ้นบนโปรโตคอล [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) โดยให้ทั้ง [การยืนยันตัวตน (Authentication)](https://auth.wiki/authentication) และ [การอนุญาต (Authorization)](https://auth.wiki/authorization) ซึ่งทำให้การผสานรวมแอป OIDC บุคคลที่สามง่ายเหมือนกับแอปเว็บทั่วไป +Logto เป็นบริการข้อมูลระบุตัวตนที่สร้างขึ้นบนโปรโตคอล [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) โดยให้ทั้ง [การยืนยันตัวตน (Authentication)](https://auth.wiki/authentication) และ [การอนุญาต (Authorization)](https://auth.wiki/authorization) การผสานรวมแอป OIDC บุคคลที่สามจึงง่ายเหมือนกับแอปเว็บทั่วไป เนื่องจาก OIDC สร้างขึ้นบน [OAuth 2.0](https://auth.wiki/oauth-2.0) โดยเพิ่มชั้นการยืนยันตัวตน คุณจึงสามารถผสานรวมแอปบุคคลที่สามด้วยโปรโตคอล OAuth ได้เช่นกัน +## สองวิธีในการเชื่อมต่อแอปบุคคลที่สาม \{#two-ways-to-onboard-a-third-party-app} + +- **ลงทะเบียนแอปใน Logto** (คู่มือนี้): คุณสร้างแอปพลิเคชันและกำหนดสิทธิ์กับ redirect URI ใช้เมื่อคุณรู้จักพันธมิตรของคุณ +- **[Dynamic app](/integrate-logto/third-party-applications/dynamic-apps)**: ไคลเอนต์เชื่อมต่อได้โดยไม่ต้องลงทะเบียนล่วงหน้า โดยใช้ URL HTTPS สาธารณะที่ให้ metadata document ของตนเองเป็น client ID ใช้เมื่อไคลเอนต์ใด ๆ อาจเชื่อมต่อ เช่น MCP clients และ AI agents + +ทั้งสองวิธีสามารถใช้ร่วมกันได้ + ## สร้างแอปพลิเคชันบุคคลที่สามใน Logto \{#create-a-third-party-application-in-logto} 1. ไปที่ Console > Applications -2. คลิกปุ่ม "Create application" เลือก "Third-party app" เป็นประเภทแอปพลิเคชัน และเลือกหนึ่งในโปรโตคอลการผสานรวมต่อไปนี้: +2. คลิกปุ่ม "Create application" เลือก "Third-party app" เป็นประเภทแอปพลิเคชัน และเลือกโปรโตคอลการผสานรวมต่อไปนี้: - OIDC / OAuth 3. เลือกประเภทแอปพลิเคชันตามประเภทของแอปบุคคลที่สาม: - - **Traditional Web**: แอปพลิเคชันที่เรนเดอร์ฝั่งเซิร์ฟเวอร์ (เช่น Node.js, PHP, Java) ที่สามารถเก็บ client secret ไว้ที่ backend ได้อย่างปลอดภัย - - **Single Page App (SPA)**: แอปพลิเคชันที่เรนเดอร์ฝั่ง client (เช่น React, Vue, Angular) ที่ทำงานในเบราว์เซอร์และไม่สามารถเก็บ secret ได้อย่างปลอดภัย - - **Native**: แอปพลิเคชันมือถือหรือเดสก์ท็อป (เช่น iOS, Android, Electron) ที่ทำงานบนอุปกรณ์ของผู้ใช้ -4. กรอกชื่อและคำอธิบายสำหรับแอปของคุณแล้วคลิก "Create" จะมีการสร้างแอปพลิเคชันบุคคลที่สามใหม่ + - **Traditional Web**: แอปที่เรนเดอร์ฝั่งเซิร์ฟเวอร์ (เช่น Node.js, PHP, Java) ที่สามารถเก็บ client secret ไว้ที่ backend ได้อย่างปลอดภัย + - **Single Page App (SPA)**: แอปที่เรนเดอร์ฝั่ง client (เช่น React, Vue, Angular) ที่ทำงานในเบราว์เซอร์และไม่สามารถเก็บ secret ได้อย่างปลอดภัย + - **Native**: แอปมือถือหรือเดสก์ท็อป (เช่น iOS, Android, Electron) ที่ทำงานบนอุปกรณ์ของผู้ใช้ +4. กรอกชื่อและคำอธิบายสำหรับแอปของคุณ แล้วคลิกปุ่ม "Create" จะมีการสร้างแอปพลิเคชันบุคคลที่สามใหม่ -แอปพลิเคชันบุคคลที่สามที่สร้างขึ้นทั้งหมดจะถูกจัดหมวดหมู่ในหน้า Applications ใต้แท็บ "Third-party apps" การจัดเรียงนี้ช่วยให้คุณแยกแยะออกจากแอปของคุณเองและจัดการแอปทั้งหมดได้ง่ายขึ้นในที่เดียว +แอปพลิเคชันบุคคลที่สามที่สร้างขึ้นทั้งหมดจะถูกจัดหมวดหมู่ในหน้า Applications ภายใต้แท็บ "Third-party apps" การจัดเรียงนี้ช่วยให้คุณแยกแยะออกจากแอปของคุณเองและจัดการแอปทั้งหมดได้ง่ายขึ้นในที่เดียว -หากต้องการจำกัดว่าผู้ใช้ใดสามารถลงชื่อเข้าใช้แอปพลิเคชันบุคคลที่สาม ให้กำหนดค่า [การควบคุมการเข้าถึงระดับแอป](/authorization/app-level-access-control) ในแท็บ **Rules** ของแอปพลิเคชันนั้น +หากต้องการจำกัดว่าผู้ใช้ใดสามารถลงชื่อเข้าใช้แอปบุคคลที่สาม ให้กำหนดค่า [การควบคุมการเข้าถึงระดับแอป](/authorization/app-level-access-control) ในแท็บ **Rules** ของแอปพลิเคชัน ## คู่มือการผสานรวม \{#integration-guide} ### ค้นหาค่าคอนฟิกของแอปพลิเคชัน \{#find-the-application-configurations} -ในหน้ารายละเอียดแอปพลิเคชัน คุณจะพบ [**Client ID**](/integrate-logto/application-data-structure#application-id), [**Client secret**](/integrate-logto/application-data-structure#application-secret) (สำหรับ traditional web apps เท่านั้น) และ endpoint OIDC ที่จำเป็นสำหรับการผสานรวม +ในหน้ารายละเอียดแอปพลิเคชัน คุณจะพบ [**Client ID**](/integrate-logto/application-data-structure#application-id), [**Client secret**](/integrate-logto/application-data-structure#application-secret) (สำหรับแอปเว็บแบบดั้งเดิมเท่านั้น) และ endpoint OIDC ที่จำเป็นสำหรับการผสานรวม -หากบริการบุคคลที่สามรองรับ OIDC discovery เพียงแค่ระบุ **Discovery endpoint** หากไม่รองรับ ให้คลิก **Show endpoint details** เพื่อดู endpoint ทั้งหมด รวมถึง [authorization endpoint](/integrate-logto/application-data-structure#authorization-endpoint) และ [token endpoint](/integrate-logto/application-data-structure#token-endpoint) +หากบริการบุคคลที่สามรองรับ OIDC discovery เพียงแค่ให้ **Discovery endpoint** หากไม่รองรับ ให้คลิก **Show endpoint details** เพื่อดู endpoint ทั้งหมด รวมถึง [authorization endpoint](/integrate-logto/application-data-structure#authorization-endpoint) และ [token endpoint](/integrate-logto/application-data-structure#token-endpoint) ### ผสานรวมกับบริการที่รองรับ IdP บุคคลที่สาม \{#integrate-with-services-that-support-third-party-idp} @@ -51,25 +59,25 @@ Logto เป็นบริการข้อมูลระบุตัวต 1. เปิดหน้าตั้งค่า IdP หรือ SSO ของบริการนั้น 2. คัดลอก **Client ID** (และ **Client secret** หากจำเป็น) จาก Logto ไปวางในหน้าตั้งค่าของบริการ -3. ระบุ **Discovery endpoint** หากบริการรองรับ OIDC auto-discovery หรือคัดลอก **Authorization endpoint** และ **Token endpoint** ด้วยตนเอง +3. ให้ **Discovery endpoint** หากบริการรองรับ OIDC auto-discovery หรือคัดลอก **Authorization endpoint** และ **Token endpoint** ด้วยตนเอง 4. คัดลอก **Redirect URI** จากหน้าตั้งค่าของบริการและเพิ่มเข้าไปใน allowed redirect URIs ของแอป Logto ของคุณ -5. กำหนดค่า **scopes** หากบริการนั้นอนุญาต เนื่องจาก Logto เป็น OIDC provider ให้เพิ่ม scope `openid` หากคุณต้องการยืนยันตัวตนผู้ใช้ (เพื่อรับ ID token และเข้าถึง UserInfo endpoint) scope `openid` เป็นตัวเลือกหากคุณต้องการเพียงการเข้าถึงทรัพยากร OAuth +5. กำหนดค่า **scopes** หากบริการรองรับ เนื่องจาก Logto เป็น OIDC provider ให้เพิ่ม scope `openid` หากต้องการยืนยันตัวตนผู้ใช้ (จะได้รับ ID token และ endpoint UserInfo) scope `openid` เป็นตัวเลือกหากต้องการเข้าถึงทรัพยากร OAuth เท่านั้น บริการจะจัดการ flow ของ OAuth / OIDC ให้อัตโนมัติเมื่อกำหนดค่าเสร็จ ### ผสานรวมผ่านโปรโตคอล OAuth / OIDC \{#integrate-via-oauth-protocol} -หากแอปพลิเคชันบุคคลที่สามต้องการผสานรวมกับ Logto เป็น IdP แบบโปรแกรม ควรใช้ [Authorization Code Flow](https://auth.wiki/authorization-code-flow) มาตรฐาน เราแนะนำให้ใช้ไลบรารี client OAuth 2.0 / OIDC สำหรับภาษาที่คุณใช้เพื่อจัดการการทำงานนี้ +หากแอปพลิเคชันบุคคลที่สามต้องการผสานรวมกับ Logto เป็น IdP แบบโปรแกรม ควรใช้ [Authorization Code Flow](https://auth.wiki/authorization-code-flow) มาตรฐาน เราแนะนำให้ใช้ไลบรารี OAuth 2.0 / OIDC สำหรับภาษาโปรแกรมของคุณเพื่อจัดการการใช้งาน -แอปพลิเคชันเว็บแบบดั้งเดิมเป็น **confidential clients** ที่สามารถเก็บ client secret ไว้ที่ backend server ได้อย่างปลอดภัย ดูรายละเอียดการใช้งานเต็มที่ได้ที่ [Authorization Code Flow](https://auth.wiki/authorization-code-flow) +แอปเว็บแบบดั้งเดิมเป็น **confidential clients** ที่สามารถเก็บ client secret ไว้ที่ backend ได้อย่างปลอดภัย ดูรายละเอียดการใช้งานเต็มที่ได้ที่ [Authorization Code Flow](https://auth.wiki/authorization-code-flow) **ขั้นตอนสำคัญ:** 1. **เริ่มต้นการอนุญาต**: เปลี่ยนเส้นทางผู้ใช้ไปยัง authorization endpoint ของ Logto พร้อม `client_id`, `redirect_uri`, `response_type=code` และ `scope` -2. **จัดการ callback**: รับ authorization `code` จากการ redirect +2. **จัดการ callback**: รับ authorization `code` จาก redirect 3. **แลกเปลี่ยนโทเค็น**: จาก backend ของคุณ POST ไปยัง token endpoint พร้อม code, `client_id` และ `client_secret` @@ -81,7 +89,7 @@ Single page app และ Native app เป็น **public clients** ที่ 1. **สร้างพารามิเตอร์ PKCE**: สร้าง `code_verifier` และแปลงเป็น `code_challenge` (SHA-256) 2. **เริ่มต้นการอนุญาต**: เปลี่ยนเส้นทางผู้ใช้ไปยัง authorization endpoint พร้อม `code_challenge` และ `code_challenge_method=S256` -3. **จัดการ callback**: รับ authorization `code` จากการ redirect +3. **จัดการ callback**: รับ authorization `code` จาก redirect 4. **แลกเปลี่ยนโทเค็น**: POST ไปยัง token endpoint พร้อม code และ `code_verifier` เดิม @@ -89,29 +97,29 @@ Single page app และ Native app เป็น **public clients** ที่ ### ผสานรวมผ่าน device flow \{#integrate-via-device-flow} -สำหรับแอปพลิเคชันบุคคลที่สามแบบ native ที่ทำงานบนอุปกรณ์ที่มีข้อจำกัดด้านการป้อนข้อมูล (เช่น สมาร์ททีวี, เกมคอนโซล, CLI tools) การใช้ authorization code flow แบบ redirect อาจไม่เหมาะสม ในกรณีนี้ แอปสามารถใช้ [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) แทนได้ +สำหรับแอปพลิเคชันบุคคลที่สามแบบ native ที่ทำงานบนอุปกรณ์ที่จำกัดการป้อนข้อมูล (เช่น สมาร์ททีวี, เกมคอนโซล, CLI tools) การใช้ authorization code flow แบบ redirect อาจไม่เหมาะสม ในกรณีนี้ แอปสามารถใช้ [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) แทนได้ -ด้วย device flow อุปกรณ์จะแสดง user code และ URL สำหรับยืนยันตัวตน ผู้ใช้จะไปที่ URL ดังกล่าวบนอุปกรณ์อื่น (เช่น โทรศัพท์, แล็ปท็อป) กรอกรหัส และดำเนินการยืนยันตัวตนให้เสร็จ อุปกรณ์จะ poll token endpoint ของ Logto จนกว่าการอนุญาตจะเสร็จสมบูรณ์ +ด้วย device flow อุปกรณ์จะแสดง user code และ verification URL ผู้ใช้จะไปที่ URL ดังกล่าวบนอุปกรณ์อื่น (เช่น โทรศัพท์, แล็ปท็อป) กรอก code และดำเนินการยืนยันตัวตนที่นั่น อุปกรณ์จะ poll token endpoint ของ Logto จนกว่าการอนุญาตจะเสร็จสมบูรณ์ :::note -ก่อนใช้งาน device flow โปรดกำหนดค่า [สิทธิ์ (permissions)](/integrate-logto/third-party-applications/permission-management) ที่จำเป็นสำหรับแอปบุคคลที่สามของคุณใน Logto Console แอปบุคคลที่สามที่ร้องขอ scopes ที่ไม่ได้เปิดใช้งานจะถูกปฏิเสธการเข้าถึง +ก่อนใช้งาน device flow อย่าลืมกำหนด [สิทธิ์](/integrate-logto/third-party-applications/permission-management) ที่จำเป็นสำหรับแอปบุคคลที่สามของคุณใน Logto Console แอปบุคคลที่สามที่ร้องขอ scope ที่ไม่ได้เปิดใช้งานจะถูกปฏิเสธการเข้าถึง ::: ดู [Device flow quick start](/quick-starts/device-flow) สำหรับรายละเอียดการใช้งาน -## หน้าขอความยินยอมสำหรับแอป OIDC บุคคลที่สาม \{#consent-screen-for-oidc-third-party-applications} +## หน้าขอความยินยอม (Consent screen) สำหรับแอป OIDC บุคคลที่สาม \{#consent-screen-for-oidc-third-party-applications} -เพื่อความปลอดภัย แอปพลิเคชัน OIDC บุคคลที่สามทั้งหมดจะถูกเปลี่ยนเส้นทางไปยัง [หน้าขอความยินยอม (consent screen)](/end-user-flows/consent-screen) เพื่อขอการอนุญาตจากผู้ใช้หลังจากได้รับการยืนยันตัวตนโดย Logto แล้ว +เพื่อความปลอดภัย แอป OIDC บุคคลที่สามทั้งหมดจะถูกเปลี่ยนเส้นทางไปยัง [หน้าขอความยินยอม (consent screen)](/end-user-flows/consent-screen) เพื่อขอการอนุญาตจากผู้ใช้หลังจากได้รับการยืนยันตัวตนโดย Logto แล้ว [สิทธิ์โปรไฟล์ผู้ใช้](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes) ที่แอปบุคคลที่สามร้องขอ, [ขอบเขตทรัพยากร API](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [สิทธิ์องค์กร](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) และข้อมูลสมาชิกองค์กรทั้งหมดจะแสดงบนหน้าขอความยินยอม -สิทธิ์ที่ร้องขอเหล่านี้จะถูกอนุญาตให้แอปบุคคลที่สามก็ต่อเมื่อผู้ใช้คลิกปุ่ม "Authorize" เท่านั้น +สิทธิ์ที่ร้องขอเหล่านี้จะถูกอนุมัติให้แอปบุคคลที่สามก็ต่อเมื่อผู้ใช้คลิกปุ่ม "Authorize" เท่านั้น
consent screen
-## การดำเนินการเพิ่มเติม \{#further-actions} +## การดำเนินการถัดไป \{#further-actions} , }, }, + { + type: 'link', + label: 'Dynamic app (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + 'อนุญาตให้ OAuth clients เชื่อมต่อได้โดยไม่ต้องลงทะเบียนล่วงหน้า โดยใช้ URL metadata document เป็น client ID', + customProps: { + icon: , + }, + }, ]} /> @@ -142,24 +160,24 @@ Single page app และ Native app เป็น **public clients** ที่
-### เราจะมั่นใจได้อย่างไรว่าผู้ใช้สามารถอนุญาตเฉพาะสิทธิ์ที่ตนเองมีบนหน้าขอความยินยอม? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} +### เราจะมั่นใจได้อย่างไรว่าผู้ใช้สามารถอนุมัติสิทธิ์เฉพาะที่ตนเองมีบนหน้าขอความยินยอม? \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} -Logto ใช้การควบคุมการเข้าถึงตามบทบาท (RBAC) เพื่อจัดการสิทธิ์ของผู้ใช้ บนหน้าขอความยินยอมจะแสดงเฉพาะขอบเขต (สิทธิ์) ที่ผู้ใช้ได้รับผ่านบทบาทของตนเท่านั้น หากแอปบุคคลที่สามร้องขอขอบเขตที่ผู้ใช้ไม่มี จะไม่แสดงเพื่อป้องกันการอนุญาตที่ไม่ได้รับอนุญาต +Logto ใช้การควบคุมการเข้าถึงตามบทบาท (RBAC) เพื่อจัดการสิทธิ์ของผู้ใช้ บนหน้าขอความยินยอมจะแสดงเฉพาะ scope (สิทธิ์) ที่ผู้ใช้ได้รับผ่านบทบาทของตนแล้วเท่านั้น หากแอปบุคคลที่สามร้องขอ scope ที่ผู้ใช้ไม่มี จะไม่แสดงเพื่อป้องกันการอนุญาตที่ไม่ได้รับอนุญาต แนวทางการจัดการ: -- กำหนด [บทบาทระดับโกลบอล](/authorization/role-based-access-control) หรือ [บทบาทองค์กร](/authorization/organization-template) พร้อมขอบเขตที่ต้องการ -- กำหนดบทบาทให้ผู้ใช้ตามความต้องการในการเข้าถึง -- ผู้ใช้จะได้รับขอบเขตจากบทบาทโดยอัตโนมัติ +- กำหนด [บทบาทระดับโกลบอล](/authorization/role-based-access-control) หรือ [บทบาทองค์กร](/authorization/organization-template) พร้อม scope เฉพาะ +- กำหนดบทบาทให้ผู้ใช้ตามความต้องการเข้าถึง +- ผู้ใช้จะได้รับ scope จากบทบาทของตนโดยอัตโนมัติ
## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} - กรณีศึกษา: ผสานรวม Apache Answer เพื่อสร้างชุมชนสำหรับผู้ใช้ของคุณ + กรณีศึกษา: ผสานรวม Apache Answer เพื่อสร้างคอมมูนิตี้สำหรับผู้ใช้ของคุณ diff --git a/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..a253f543937 --- /dev/null +++ b/i18n/th/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,99 @@ +--- +description: อนุญาตให้ OAuth client เชื่อมต่อกับ tenant ของคุณโดยไม่ต้องลงทะเบียนล่วงหน้า ด้วยการใช้ URL เอกสาร metadata ของ client ID เป็น client ID ของพวกเขา +sidebar_label: แอปไดนามิก (CIMD) +sidebar_position: 3 +--- + +# แอปไดนามิก (CIMD) + +แอปไดนามิกช่วยให้ OAuth client เชื่อมต่อกับ tenant ของคุณได้โดยไม่ต้องลงทะเบียนล่วงหน้า แทนที่จะใช้ client ID ที่ออกโดย Logto, client จะใช้ URL สาธารณะแบบ HTTPS เป็น `client_id` URL นี้จะให้บริการเอกสาร JSON ที่อธิบาย client ซึ่งเรียกว่า [client ID metadata document (CIMD)](https://auth.wiki/client-id-metadata-document) Logto จะดึงเอกสารนี้และปฏิบัติต่อ client เหมือนเป็น [แอปพลิเคชันบุคคลที่สาม](/integrate-logto/third-party-applications) + +แอปไดนามิกนี้อิงตาม IETF draft [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html) + +## เมื่อใดควรใช้แอปไดนามิก \{#when-to-use-dynamic-app} + +การลงทะเบียนล่วงหน้าจะใช้ได้เมื่อคุณรู้จักพาร์ทเนอร์ของคุณ แต่จะใช้ไม่ได้เมื่อ client ใด ๆ อาจเชื่อมต่อเข้ามา ซึ่งเป็นเรื่องปกติในระบบนิเวศ [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents): ผู้ใช้ขอให้ AI agent ของตนเชื่อมต่อกับบริการของคุณ และ agent นั้นไม่เคยติดต่อกับ tenant ของคุณมาก่อน + +ด้วยแอปไดนามิก client จะเผยแพร่ metadata ของตนเองที่ URL ที่ตนเป็นเจ้าของ และ URL นั้นคืออัตลักษณ์ของมัน โดยไม่ต้องสร้างอะไรใน tenant ของคุณล่วงหน้า + +| | แอปบุคคลที่สามที่ลงทะเบียนไว้ | แอปไดนามิก | +| ------------- | ----------------------------- | ---------------------------------------- | +| Client ID | ออกโดย Logto | URL แบบ HTTPS ที่ client เป็นเจ้าของ | +| การลงทะเบียน | จำเป็นต้องลงทะเบียน | ไม่จำเป็นต้องลงทะเบียน | +| Client secret | รองรับ | ไม่รองรับ | +| สิทธิ์ | ต่อแอปพลิเคชัน | ใช้ร่วมกันโดย client ไดนามิกทั้งหมด | +| Grant types | ขึ้นกับประเภทแอป | `authorization_code` และ `refresh_token` | + +client ไดนามิกถือเป็น public client ดังนั้นจึงใช้ [PKCE](https://auth.wiki/pkce) เสมอ คุณสามารถใช้ทั้งสองโมเดลนี้พร้อมกันได้ พาร์ทเนอร์ที่คุณไว้ใจยังคงมีแอปที่ลงทะเบียนพร้อมสิทธิ์ของตนเองได้ + +## เปิดใช้งานแอปไดนามิก \{#enable-dynamic-app} + +1. ไปที่ Console > Applications และเปิดแท็บ **Third-party apps** +2. คลิก **Create application** และเลือกการ์ด **Dynamic app** ซึ่งจะเปิดใช้ฟีเจอร์ระดับ tenant แทนที่จะสร้างแอปพลิเคชัน +3. ยืนยันใน dialog เมื่อเปิดใช้งานแล้ว OAuth client ใด ๆ ที่มี client ID URL แบบ HTTPS สาธารณะที่ถูกต้องสามารถเริ่มคำขอการอนุญาตสำหรับ tenant ของคุณได้ +4. เปิดแอปไดนามิกจากรายการแอปพลิเคชันและไปที่แท็บ **Permissions** เพื่อกำหนดสิทธิ์ + +แอปไดนามิกไม่มีชื่อ, redirect URI หรือข้อมูลรับรองที่แก้ไขได้ แต่ละ client จะระบุข้อมูลเหล่านี้ใน metadata document ของตนเอง + +:::note +แอปไดนามิกต้องการ [การป้องกัน SSRF ของ OIDC provider](/concepts/core-service/configuration#oidc-provider-ssrf-protection) เนื่องจาก Logto จะดึง metadata document จากอินเทอร์เน็ต อินสแตนซ์ที่โฮสต์เองและปิดฟีเจอร์นี้จะไม่สามารถเปิดใช้แอปไดนามิกได้ +::: + +### กำหนดสิทธิ์ \{#grant-permissions} + +แท็บ **Permissions** จะกำหนดสิทธิ์สูงสุดที่ใช้ร่วมกันโดย client ไดนามิกทั้งหมด การทำงานเหมือนกับ [การจัดการสิทธิ์](/integrate-logto/third-party-applications/permission-management) ของแอปบุคคลที่สามที่ลงทะเบียน โดยมีส่วน **User** และ **Organization** + +หากร้องขอ user permission ที่ไม่ได้รับอนุญาตจะเกิดข้อผิดพลาด ขณะที่สิทธิ์ของทรัพยากร API และองค์กรที่ไม่ได้รับอนุญาตจะถูกละเลย ผู้ใช้จะยินยอมเฉพาะสิทธิ์ที่ตนมีผ่าน [บทบาท (Roles)](/authorization/role-based-access-control) ของตน + +เนื่องจาก client ไดนามิกทุกตัวใช้ชุดนี้ร่วมกัน ควรตั้งค่าให้น้อยที่สุด + +## เผยแพร่ client ID metadata document \{#publish-a-client-id-metadata-document} + +หากคุณกำลังสร้าง client ที่เชื่อมต่อกับ Logto ให้โฮสต์ metadata document และใช้ URL ของมันเป็น `client_id` URL ต้องใช้ scheme `https` และต้องไม่มี fragment, user info หรือ dot path segment Logto จะส่งคำขอ `GET` ไปยัง URL นี้และคาดหวังว่าจะได้ JSON object + +ตัวอย่างเช่น Claude Code ใช้ `https://claude.ai/oauth/claude-code-client-metadata` ซึ่งให้บริการ: + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +ชื่อฟิลด์เหมือนกับใน [OAuth 2.0 Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591#section-2) หมายเหตุว่า: + +- `client_id` ต้องเหมือนกับ URL ที่ให้บริการเอกสารนี้ +- client ไดนามิกถือเป็น public client เอกสารต้องไม่มี `client_secret` และ `token_endpoint_auth_method` ต้องไม่เป็น shared-secret method ให้ใช้ [PKCE](https://auth.wiki/pkce) แทน +- URI metadata เช่น `client_uri`, `logo_uri`, `tos_uri` และ `policy_uri` ต้องเป็น URL แบบสัมบูรณ์ที่ใช้ `https` เสมอ ข้อนี้ไม่ใช้กับ `redirect_uris` ดังนั้น native client ยังสามารถใช้ loopback address ได้เหมือนตัวอย่างข้างต้น +- `redirect_uris` จะถูกจับคู่แบบ exact string ยกเว้น loopback address ที่สามารถจับคู่กับพอร์ตใดก็ได้ [Wildcard patterns](/integrate-logto/application-data-structure#wildcard-patterns) ก็รองรับเช่นกัน +- `scope`, `grant_types` และ `response_types` จะถูกกำหนดโดย Logto หากเอกสารระบุไว้ ค่าจะถูกละเลย client ไดนามิกสามารถใช้ได้เฉพาะ authorization code flow และ refresh token เท่านั้น + +Logto จะ cache เอกสารนี้ได้นานสูงสุด 24 ชั่วโมง โดยอิงตาม header `Cache-Control` และ `Expires` ของ response ของคุณ กำหนดค่าเหล่านี้ตามความถี่ที่คุณคาดว่าจะอัปเดตเอกสาร + +## หน้าขอความยินยอม (Consent screen) \{#consent-screen} + +client ไดนามิกถือเป็นแอปพลิเคชันบุคคลที่สาม ดังนั้น [หน้าขอความยินยอม](/end-user-flows/consent-screen) จะแสดงเสมอ + +หน้าขอความยินยอมจะแสดงข้อความแจ้งว่า client นี้ยังไม่ได้ลงทะเบียน ชื่อและโลโก้ของ client มาจาก metadata document ดังนั้นจึงสามารถเลียนแบบแบรนด์ใดก็ได้ โฮสต์ของ client ID URL จะแสดงด้วย เพราะเป็นส่วนเดียวที่ client ไม่สามารถปลอมแปลงได้ + +## จัดการการอนุญาต (Manage authorizations) \{#manage-authorizations} + +การอนุญาตที่ให้กับ client ไดนามิกถือเป็น [grant](/sessions/grants-management) ของแอปบุคคลที่สามตามปกติ ผู้ใช้สามารถตรวจสอบและเพิกถอนสิทธิ์เหล่านี้ในหน้าตั้งค่าบัญชี และผู้ดูแลระบบสามารถจัดการผ่าน Management API โดยใช้ client ID URL เป็นตัวระบุ client + +การปิดใช้งานแอปไดนามิกจะหยุดคำขอการอนุญาตใหม่ แต่ grant ที่มีอยู่จะยังคงอยู่ การเพิกถอน grant จะทำให้ client ต้องขออนุญาตจากผู้ใช้อีกครั้ง แต่ access token ที่ออกไปแล้วอาจยังใช้ได้จนกว่าจะหมดอายุ + +## ข้อจำกัด \{#limitations} + +- รองรับเฉพาะ authorization code flow ที่ใช้ PKCE และ refresh token เท่านั้น ไม่รองรับ client credentials, device flow และ token exchange +- ไม่สามารถกำหนดสิทธิ์และแบรนด์แยกตาม client ได้ +- [การควบคุมการเข้าถึงระดับแอป](/authorization/app-level-access-control) ไม่ใช้กับ client ไดนามิก เพราะไม่มี record ของแอปพลิเคชัน + +## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} + +แอปบุคคลที่สาม (OAuth / OIDC) + + เปิดให้ AI agent บุคคลที่สามเข้าถึง MCP server ของคุณ + diff --git a/i18n/th/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/th/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index 7076a7c84fe..1f9654094b0 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -2,31 +2,31 @@ sidebar_position: 2 --- -# จัดการแอปที่ได้รับอนุญาตของผู้ใช้ (grants) +# จัดการแอปที่ผู้ใช้ได้รับอนุญาต (grants) -Grant ของแอปแสดงถึงสถานะการอนุญาตของผู้ใช้สำหรับแอปพลิเคชันลูกค้าเฉพาะ +Grant ของแอปแสดงถึงสถานะการอนุญาตของผู้ใช้สำหรับแอปพลิเคชันไคลเอนต์แต่ละตัว -ใช้การจัดการ grants เมื่อผู้ใช้หรือผู้ดูแลระบบต้องการตรวจสอบแอปที่ได้รับอนุญาตและเพิกถอนการเข้าถึงแอปโดยไม่ต้องเพิกถอนเซสชัน Logto ทั้งหมด +ใช้การจัดการ grant เมื่อผู้ใช้หรือผู้ดูแลระบบต้องการตรวจสอบแอปที่ได้รับอนุญาตและเพิกถอนการเข้าถึงแอปโดยไม่ต้องเพิกถอนเซสชัน Logto ทั้งหมด -เมื่อ grants ถูกเพิกถอน โทเค็นการเข้าถึงทึบ (opaque access tokens) และโทเค็นรีเฟรช (refresh tokens) ที่ออกให้ก่อนหน้านี้สำหรับ grants เหล่านั้นจะถูกทำให้ไม่ถูกต้อง +เมื่อมีการเพิกถอน grant โทเค็นทึบ (Opaque token) การเข้าถึง (Access token) และโทเค็นรีเฟรช (Refresh token) ที่ออกให้ก่อนหน้านี้สำหรับ grant เหล่านั้นจะถูกทำให้ใช้ไม่ได้ โทเค็นการเข้าถึง (Access token) แบบ JWT เป็นแบบไร้สถานะ (stateless) ดังนั้นโทเค็นที่ออกไปก่อนหน้านี้จะยังคงใช้ได้จนกว่าจะหมดอายุ -## เลือกเส้นทางที่ถูกต้อง \{#choose-the-right-path} +## เลือกเส้นทางที่เหมาะสม \{#choose-the-right-path} -| สถานการณ์ | เส้นทางที่แนะนำ | -| --------------------------------------------------------------- | --------------- | -| ให้ผู้ใช้ที่ลงชื่อเข้าใช้จัดการการอนุญาตแอปของตนเอง | Account API | -| ให้ผู้ดูแลระบบหรือทีมสนับสนุนจัดการ grants สำหรับผู้ใช้เป้าหมาย | Management API | -| ให้ผู้ปฏิบัติงานจัดการการอนุญาตแอปของบุคคลที่สามใน UI | Admin Console | +| สถานการณ์ | เส้นทางที่แนะนำ | +| -------------------------------------------------------------- | --------------- | +| ให้ผู้ใช้ที่ลงชื่อเข้าแล้วจัดการการอนุญาตแอปของตนเอง | Account API | +| ให้ผู้ดูแลระบบหรือทีมสนับสนุนจัดการ grant สำหรับผู้ใช้เป้าหมาย | Management API | +| ให้ผู้ปฏิบัติงานจัดการการอนุญาตแอปของบุคคลที่สามใน UI | Admin Console | -## API การจัดการ grant โดยตรง \{#direct-grant-management-apis} +## API สำหรับจัดการ grant โดยตรง \{#direct-grant-management-apis} ### Account API (บริการตนเอง) \{#account-api-self-service} -ใช้ Account API ในหน้าการตั้งค่าบัญชีผู้ใช้ปลายทาง: +ใช้ Account API ในหน้าการตั้งค่าบัญชีของผู้ใช้ปลายทาง: - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` -- อ้างอิง: [จัดการแอปที่ได้รับอนุญาตของผู้ใช้ (grants)](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) +- อ้างอิง: [จัดการแอปที่ผู้ใช้ได้รับอนุญาต (grants)](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) ### Management API (เครื่องมือผู้ดูแลระบบ) \{#management-api-admin-tools} @@ -34,38 +34,40 @@ Grant ของแอปแสดงถึงสถานะการอนุ - `GET /api/users/{userId}/grants` - `DELETE /api/users/{userId}/grants/{grantId}` -- อ้างอิง: [จัดการแอปที่ได้รับอนุญาตของผู้ใช้ (grants)](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) +- อ้างอิง: [จัดการแอปที่ผู้ใช้ได้รับอนุญาต (grants)](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) ### กรองรายการ grant ตามประเภทแอป \{#filter-grant-list-by-app-type} -จุดสิ้นสุดการแสดงรายการ grant รองรับพารามิเตอร์การค้นหา `appType` ที่เป็นทางเลือก: +จุดปลาย (endpoint) สำหรับแสดงรายการ grant รองรับพารามิเตอร์ query `appType` แบบเลือกได้: -- `appType=firstParty`: แสดงรายการ grant ของแอป first-party เท่านั้น -- `appType=thirdParty`: แสดงรายการ grant ของแอป third-party เท่านั้น -- ละเว้น `appType`: แสดงรายการ grant ที่ใช้งานอยู่ทั้งหมด +- `appType=firstParty`: แสดงเฉพาะ grant ของแอป first-party +- `appType=thirdParty`: แสดงเฉพาะ grant ของแอป third-party +- ไม่ระบุ `appType`: คืน grant ที่ใช้งานอยู่ทั้งหมด + +ไคลเอนต์ [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) ถือเป็นแอป third-party ดังนั้น grant ของพวกเขาจะถูกคืนค่าด้วย `appType=thirdParty` โดยใช้ URL client ID เป็นรหัสแอปพลิเคชัน ## จัดการการอนุญาตแอป third-party ใน Console \{#manage-third-party-app-authorizations-in-console} ใน Logto Console ใช้หน้ารายละเอียดผู้ใช้เพื่อดูและเพิกถอนแอป third-party ที่ได้รับอนุญาต -- อ้างอิง: [จัดการแอป third-party ที่ได้รับอนุญาตของผู้ใช้](/user-management/manage-users#manage-user-authorized-third-party-apps) +- อ้างอิง: [จัดการแอป third-party ที่ผู้ใช้ได้รับอนุญาต](/user-management/manage-users#manage-user-authorized-third-party-apps) -## เพิกถอน grants เมื่อเพิกถอนเซสชัน \{#revoke-grants-when-revoking-a-session} +## เพิกถอน grant เมื่อเพิกถอนเซสชัน \{#revoke-grants-when-revoking-a-session} -เมื่อเพิกถอนเซสชันผ่าน `DELETE /api/my-account/sessions/{sessionId}` ใช้พารามิเตอร์การค้นหา `revokeGrantsTarget` ที่เป็นทางเลือกเพื่อควบคุมขอบเขตการเพิกถอน grant: +เมื่อเพิกถอนเซสชันผ่าน `DELETE /api/my-account/sessions/{sessionId}` ให้ใช้พารามิเตอร์ query `revokeGrantsTarget` เพื่อควบคุมขอบเขตการเพิกถอน grant: -- `all`: เพิกถอน grants สำหรับแอปทั้งหมดที่เกี่ยวข้องกับเซสชัน -- `firstParty`: เพิกถอน grants สำหรับแอป first-party เท่านั้น +- `all`: เพิกถอน grant สำหรับทุกแอปที่เกี่ยวข้องกับเซสชัน +- `firstParty`: เพิกถอน grant เฉพาะสำหรับแอป first-party -สำหรับพฤติกรรมระดับเซสชันและบริบทของจุดสิ้นสุด ดู [จัดการเซสชันของผู้ใช้](/sessions/manage-user-sessions) และ [ลงชื่อออก](/end-user-flows/sign-out) +สำหรับพฤติกรรมในระดับเซสชันและบริบทของ endpoint ดู [จัดการเซสชันผู้ใช้](/sessions/manage-user-sessions) และ [การออกจากระบบ](/end-user-flows/sign-out) ## แหล่งข้อมูลที่เกี่ยวข้อง \{#related-resources} -Sessions -จัดการเซสชันของผู้ใช้ +เซสชัน +จัดการเซสชันผู้ใช้ - การตั้งค่าบัญชีโดย Account API: จัดการแอปที่ได้รับอนุญาตของผู้ใช้ (grants) + การตั้งค่าบัญชีโดย Account API: จัดการแอปที่ผู้ใช้ได้รับอนุญาต (grants) - การตั้งค่าบัญชีโดย Management API: จัดการแอปที่ได้รับอนุญาตของผู้ใช้ (grants) + การตั้งค่าบัญชีโดย Management API: จัดการแอปที่ผู้ใช้ได้รับอนุญาต (grants) diff --git a/i18n/th/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/th/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index cd91c2bad0e..08b98cb095a 100644 --- a/i18n/th/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/th/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -1,20 +1,26 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick-starts-reference.md'; -## กำหนดค่าเอเจนต์ AI ของบุคคลที่สามใน Logto \{#configure-third-party-ai-agent-in-logto} +## ตั้งค่าตัวแทน AI ของบุคคลที่สามใน Logto \{#configure-third-party-ai-agent-in-logto} -เพื่อให้เอเจนต์ AI ของบุคคลที่สามสามารถเข้าถึง {props.serviceName ?? 'บริการของคุณ'} ได้ คุณจำเป็นต้องตั้งค่า **แอปของบุคคลที่สาม** ใน Logto แอปนี้จะใช้แทนเอเจนต์ AI และรับข้อมูลประจำตัวที่จำเป็นสำหรับการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) +เพื่อให้ตัวแทน AI ของบุคคลที่สามสามารถเข้าถึง {props.serviceName ?? 'บริการของคุณ'} ได้ คุณต้องตั้งค่า **แอปของบุคคลที่สาม** ใน Logto แอปนี้จะใช้แทนตัวแทน AI และรับข้อมูลประจำตัวที่จำเป็นสำหรับการยืนยันตัวตน (การยืนยันตัวตน (Authentication)) และการอนุญาต (การอนุญาต (Authorization)) :::info[แอปของบุคคลที่สามคืออะไร?] -**แอปของบุคคลที่สาม** คือแอปพลิเคชันที่สร้างโดยนักพัฒนาภายนอก (ไม่ใช่เจ้าของทรัพยากร) ซึ่งต้องได้รับความยินยอมจากผู้ใช้เพื่อเข้าถึงทรัพยากรที่ได้รับการปกป้อง แตกต่างจากแอปของเจ้าของ (first-party apps; แอปของคุณเอง) แอปของบุคคลที่สามจะแสดงหน้าขอความยินยอม (consent screen) เพื่อขออนุมัติสิทธิ์เฉพาะก่อนเข้าถึงข้อมูลของผู้ใช้ เพื่อให้แน่ใจว่าผู้ใช้สามารถควบคุมข้อมูลที่จะแชร์กับบริการภายนอกได้ +**แอปของบุคคลที่สาม** คือแอปพลิเคชันที่สร้างโดยนักพัฒนาภายนอก (ไม่ใช่เจ้าของทรัพยากร) ซึ่งต้องได้รับความยินยอมจากผู้ใช้เพื่อเข้าถึงทรัพยากรที่ได้รับการป้องกัน แตกต่างจากแอปของเจ้าของ (first-party apps; แอปของคุณเอง) แอปของบุคคลที่สามจะแสดงหน้าขอความยินยอม (consent screen) เพื่อขออนุมัติสิทธิ์เฉพาะก่อนเข้าถึงข้อมูลของผู้ใช้ เพื่อให้แน่ใจว่าผู้ใช้ควบคุมข้อมูลที่จะแชร์กับบริการภายนอกได้ ดูเพิ่มเติมที่ [แอปพลิเคชันของบุคคลที่สาม](/integrate-logto/third-party-applications) ::: +มี 3 วิธีในการเชื่อมต่อ AI agent: + +- [สร้างแอปใน Console ด้วยตนเอง](#manually-create-a-third-party-app-in-logto) เหมาะสำหรับการทดสอบหรือกรณีที่มี agent ไม่กี่ตัวที่รู้จัก +- [สร้างบริการลงทะเบียนผ่าน Management API](#allow-developers-to-create-third-party-apps-in-logto) หากคุณต้องการควบคุมว่าใครจะได้รับข้อมูลประจำตัว +- [เปิดใช้งาน dynamic app](#let-any-ai-agent-connect-without-pre-registration) หากต้องการให้ agent ใด ๆ เชื่อมต่อได้โดยไม่ต้องลงทะเบียนล่วงหน้า + ### อนุญาตให้นักพัฒนาสร้างแอปของบุคคลที่สามใน Logto \{#allow-developers-to-create-third-party-apps-in-logto} -หากคุณกำลังสร้าง marketplace หรืออยากให้นักพัฒนาสามารถสร้างแอปของบุคคลที่สามใน Logto ได้ คุณสามารถใช้ [Logto Management API](/integrate-logto/interact-with-management-api) เพื่อสร้างแอปของบุคคลที่สามแบบโปรแกรมมิ่ง วิธีนี้จะช่วยให้นักพัฒนาสามารถลงทะเบียนแอปพลิเคชันของตนเองและรับข้อมูลประจำตัวที่จำเป็นสำหรับการยืนยันตัวตน +หากคุณกำลังสร้าง marketplace หรืออยากให้นักพัฒนาสามารถสร้างแอปของบุคคลที่สามใน Logto ได้ คุณสามารถใช้ [Logto Management API](/integrate-logto/interact-with-management-api) เพื่อสร้างแอปของบุคคลที่สามแบบโปรแกรมมิ่ง วิธีนี้ให้นักพัฒนาลงทะเบียนแอปของตนเองและรับข้อมูลประจำตัวที่จำเป็นสำหรับการยืนยันตัวตน (การยืนยันตัวตน (Authentication)) -คุณจะต้องโฮสต์บริการของคุณเองเพื่อจัดการกระบวนการลงทะเบียนไคลเอนต์ บริการนี้จะติดต่อกับ Logto Management API เพื่อสร้างแอปของบุคคลที่สามแทนนักพัฒนา +คุณต้องโฮสต์บริการของคุณเองเพื่อจัดการกระบวนการลงทะเบียน client บริการนี้จะติดต่อกับ Logto Management API เพื่อสร้างแอปของบุคคลที่สามแทนนักพัฒนา ```mermaid sequenceDiagram @@ -27,26 +33,43 @@ sequenceDiagram Server->>Developer: App ID, secret, ฯลฯ ``` -หรือคุณสามารถสร้างแอปของบุคคลที่สามใน Logto Console ด้วยตนเองเพื่อทำความคุ้นเคยกับกระบวนการนี้ +หรือ คุณสามารถสร้างแอปของบุคคลที่สามใน Logto Console ด้วยตนเองเพื่อทำความคุ้นเคยกับกระบวนการนี้ + +### อนุญาตให้ AI agent ใด ๆ เชื่อมต่อได้โดยไม่ต้องลงทะเบียนล่วงหน้า \{#let-any-ai-agent-connect-without-pre-registration} + +ในระบบนิเวศ MCP แบบเปิด คุณมักจะไม่รู้จัก agent ล่วงหน้า [Dynamic app](/integrate-logto/third-party-applications/dynamic-apps) จะตัดขั้นตอนการลงทะเบียนออก: agent ใช้ URL HTTPS สาธารณะซึ่งให้บริการ client metadata document ของตนเองเป็น `client_id` และ Logto จะดึงข้อมูลนี้เมื่อมีคำขอการอนุญาต (authorization request) เข้ามา + +```mermaid +sequenceDiagram + participant Agent as AI agent (MCP client) + participant Logto + participant Metadata as URL เอกสาร metadata ของ Agent + Agent->>Logto: คำขอการอนุญาตพร้อม client ID URL + Logto->>Metadata: ดึงเอกสาร metadata ของ client ID + Metadata->>Logto: ชื่อแอป, โลโก้, redirect URIs, ฯลฯ + Logto->>Agent: หน้าขอความยินยอม, จากนั้น authorization code +``` + +คุณยังคงควบคุมสิ่งที่ agent สามารถร้องขอได้ผ่านสิทธิ์ที่กำหนดให้กับ dynamic app และทุกการอนุญาตจะผ่านหน้าขอความยินยอมของผู้ใช้เสมอ ### สร้างแอปของบุคคลที่สามใน Logto ด้วยตนเอง \{#manually-create-a-third-party-app-in-logto} -คุณสามารถสร้างแอปของบุคคลที่สามใน Logto Console ด้วยตนเองเพื่อทดสอบหรือเชื่อมต่อแบบเฉพาะกิจ วิธีนี้เหมาะสำหรับการทดสอบการเชื่อมต่ออย่างรวดเร็วโดยไม่ต้องพัฒนากระบวนการลงทะเบียนไคลเอนต์แบบสมบูรณ์ +คุณสามารถสร้างแอปของบุคคลที่สามใน Logto Console ด้วยตนเองเพื่อทดสอบหรือเชื่อมต่อแบบ ad-hoc วิธีนี้เหมาะสำหรับการทดสอบการเชื่อมต่ออย่างรวดเร็วโดยไม่ต้องพัฒนา flow การลงทะเบียน client แบบเต็มรูปแบบ 1. ลงชื่อเข้าใช้ Logto Console ของคุณ -2. ไปที่ **แอปพลิเคชัน** → **สร้างแอปพลิเคชัน** → **แอปของบุคคลที่สาม** -> **OIDC** -3. กรอกชื่อแอปและข้อมูลที่จำเป็นอื่น ๆ จากนั้นคลิก **สร้างแอปพลิเคชัน** -4. คลิกแท็บ **สิทธิ์ (Permissions)** ในส่วน **ผู้ใช้ (User)** คลิก "เพิ่ม" -5. ในกล่องโต้ตอบที่เปิดขึ้น -> **ข้อมูลผู้ใช้ (User data)** -> เลือกสิทธิ์ **`profile`**, **`email`** แล้วคลิก **บันทึก (Save)** -6. ในแอปของบุคคลที่สาม ให้กำหนดค่า scopes เพื่อขอสิทธิ์ `openid profile email` (scopes) +2. ไปที่ **Applications** → **Create application** → **Third-party app** -> **OIDC** +3. กรอกชื่อแอปและข้อมูลที่จำเป็นอื่น ๆ จากนั้นคลิก **Create application** +4. คลิกแท็บ **Permissions** ในส่วน **User** คลิก "Add" +5. ใน dialog ที่เปิดขึ้น -> **User data** -> เลือกสิทธิ์ **`profile`**, **`email`** จากนั้นคลิก **Save** +6. ในแอปของบุคคลที่สาม ให้กำหนด scopes เพื่อร้องขอสิทธิ์ `openid profile email` (scopes) **หมายเหตุ**: `openid` จำเป็นสำหรับ OIDC และ `profile` กับ `email` คือสิทธิ์ที่คุณเพิ่มในขั้นตอนก่อนหน้า -7. กำหนดค่า **redirect URI** ของแอปของบุคคลที่สามของคุณให้ถูกต้อง และอย่าลืมอัปเดต redirect URI ใน Logto ด้วย +7. กำหนด **redirect URI** ของแอปของบุคคลที่สามของคุณให้ถูกต้อง และอย่าลืมอัปเดต redirect URI ใน Logto ด้วย สิทธิ์ของแอปของบุคคลที่สาม diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx index 1f03d2222d7..bf681fb1806 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/authorization/app-level-access-control.mdx @@ -6,14 +6,14 @@ sidebar_position: 7 # 应用级访问控制 -应用级访问控制让你可以限制谁可以登录到特定应用程序。你无需让 Logto 租户中的每个注册用户都能访问每个应用，而是可以为每个应用基于用户、用户角色、组织或组织角色创建允许规则。 +应用级访问控制让你可以限制谁可以登录到特定应用程序。你无需让 Logto 租户中的每个注册用户都能访问每个应用，而是可以基于用户、用户角色、组织或组织角色为每个应用创建允许规则。 当你希望： - 仅让员工或管理员访问内部应用时。 - 将[受保护应用](/integrate-logto/protected-app)限制给特定用户组时。 - 只允许特定客户或合作伙伴访问[第三方 OIDC / OAuth 应用](/integrate-logto/third-party-applications)时。 -- 在向所有人开放前，先向试点组推出新应用时。 +- 在向所有人开放前，先向试点组发布新应用时。 可以使用应用级访问控制。 @@ -21,7 +21,7 @@ sidebar_position: 7 当应用级访问控制被禁用时，你的 Logto 租户中的所有注册用户都可以登录该应用程序。 -当它被启用时，只有匹配至少一个已配置规则的用户才能访问该应用。如果用户未匹配任何规则，Logto 会拒绝登录尝试，并在应用收到令牌前显示访问被拒绝页面。 +启用后，只有匹配至少一个已配置规则的用户才能访问该应用。如果用户未匹配任何规则，Logto 会拒绝登录尝试，并在应用收到令牌前显示访问被拒绝页面。 应用级访问控制会在授权 (Authorization) 流程和令牌续期时进行评估。这意味着： @@ -46,7 +46,7 @@ sidebar_position: 7 规则是叠加的。用户只需匹配其中一条规则即可访问应用。 -例如，如果一个应用同时有“支持团队”用户角色规则和“BigTree - Admin”组织角色规则，那么只要用户被分配了支持团队角色，或在 BigTree 组织中是 Admin，就可以访问该应用。 +例如，如果一个应用同时有“支持团队”用户角色规则和“BigTree - Admin”组织角色规则，那么只要用户被分配了支持团队角色，或在 BigTree 组织中是 Admin，都可以访问该应用。 ## 配置应用级访问控制 \{#configure-app-level-access-control} @@ -64,7 +64,7 @@ sidebar_position: 7 8. 点击 **保存更改**。 :::important -你必须在启用访问控制前至少配置一条允许规则。这可以防止意外启用访问控制却没有任何用户可以访问应用。 +在启用访问控制前，必须至少配置一条允许规则。这可以防止意外启用访问控制却没有任何用户能访问应用。 ::: ## 编辑或移除规则 \{#edit-or-remove-rules} @@ -77,16 +77,16 @@ sidebar_position: 7 如果已启用访问控制，Logto 要求至少保留一条规则。若要移除所有规则，请先关闭 **启用访问控制**，然后保存更改。 -## 规则变更对用户的影响 \{#how-rule-changes-affect-users} +## 规则变更如何影响用户 \{#how-rule-changes-affect-users} 应用级访问控制不会终止用户的全局 Logto 会话。用户可能仍然登录着 Logto 及其他应用。 对于被限制的应用： -- 不再匹配任何允许规则的用户，在下次经过该应用授权 (Authorization) 流程时会被拦截。 -- 如果用户已有与应用相关的授权 (Authorization)，当应用使用刷新令牌请求新令牌时，Logto 会再次检查规则。如果用户已无访问权限，Logto 会拒绝令牌请求。 +- 不再匹配任何允许规则的用户，在下次经过该应用的授权 (Authorization) 流程时会被拦截。 +- 如果用户已有与应用相关的授权，Logto 会在应用使用刷新令牌请求新令牌时再次检查规则。如果用户已无访问权限，Logto 会拒绝令牌请求。 -这样可以让访问决策与应用绑定，同时避免对无关应用造成不必要的干扰。 +这样可以让访问决策仅影响该应用，同时避免对无关应用造成不必要的干扰。 ## 与第三方应用权限的关系 \{#relationship-with-third-party-app-permissions} @@ -97,6 +97,10 @@ sidebar_position: 7 如果两者都已配置，用户必须先通过应用级访问控制，才能授权第三方应用。 +:::note +应用级访问控制仅适用于已注册的应用。[动态应用](/integrate-logto/third-party-applications/dynamic-apps)客户端没有应用记录，因此无法通过此方式限制。它们的访问受你授予动态应用的权限和用户同意限制。 +::: + ## 与受保护应用的关系 \{#relationship-with-protected-app} 对于[受保护应用](/integrate-logto/protected-app)，应用级访问控制限制谁可以通过 Logto 认证 (Authentication) 层并访问受保护的源服务器。 @@ -105,8 +109,8 @@ sidebar_position: 7 ## 最佳实践 \{#best-practices} -- 尽量从用户角色或组织角色规则开始。它们比维护长用户列表更容易管理。 +- 优先使用用户角色或组织角色规则，它们比维护长用户列表更易管理。 - 当组织内所有成员都应访问应用时，使用组织规则。 - 当只有组织内特定成员应访问应用时，使用组织角色规则。 - 当用户变更角色、加入或离开组织时，及时检查访问规则。 -- 在你的思维模型中，将 RBAC 权限 (Permissions) 和应用级访问控制分开：应用级访问控制回答“这个用户能否访问这个应用？”，而 RBAC 回答“这个用户访问 API 或组织功能后能做什么？” +- 在思维模型中将 RBAC 权限和应用级访问控制分开：应用级访问控制回答“该用户能否访问该应用？”，而 RBAC 回答“该用户访问 API 或组织功能后能做什么？” diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md index 691b2ace8c4..c3f93c28fa3 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/concepts/core-service/configuration.md @@ -7,14 +7,14 @@ Logto 按照以下顺序处理环境变量： - 系统环境变量 -- 项目根目录下的 `.env` 文件，符合 [dotenv](https://github.com/motdotla/dotenv#readme) 格式 +- 项目根目录下的 `.env` 文件，遵循 [dotenv](https://github.com/motdotla/dotenv#readme) 格式 因此，系统环境变量会覆盖 `.env` 文件中的值。 ### 变量 {#variables} :::caution -如果你在项目根目录通过 `npm start` 运行 Logto，`NODE_ENV` 总是 `production`。 +如果你在项目根目录通过 `npm start` 运行 Logto，`NODE_ENV` 将始终为 `production`。 ::: 在默认值中，`protocol` 会根据你的 HTTPS 配置为 `http` 或 `https`。 @@ -26,26 +26,28 @@ Logto 按照以下顺序处理环境变量： | ADMIN_PORT | `3002` | `number` | Logto 管理控制台监听的本地端口。 | | ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | 设置为 `1` 或 `true` 可禁用管理控制台端口。如果未设置 `ADMIN_ENDPOINT`，将完全禁用管理控制台。 | | DB_URL | N/A | `string` | Logto 数据库的 [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6)。 | -| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout`，单位为毫秒。使用数字字符串（如 `5000`）设置，或使用 `DISABLE_TIMEOUT` 省略启动参数（推荐用于 PgBouncer/RDS Proxy）。如果未设置或无效，客户端默认值为 60000 毫秒。 | +| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | (v1.36.0+) PostgreSQL `statement_timeout`，单位为毫秒。使用数字字符串（如 `5000`）设置，或使用 `DISABLE_TIMEOUT` 省略启动参数（推荐用于 PgBouncer/RDS Proxy）。如果未设置或无效，客户端默认值为 60000 ms。 | | HTTPS_CERT_PATH | `undefined` | string | undefined | 详见 [启用 HTTPS](#enabling-https)。 | | HTTPS_KEY_PATH | `undefined` | string | undefined | 同上。 | | TRUST_PROXY_HEADER | `false` | `boolean` | 同上。 | -| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | 你可以为在线测试或生产环境指定自定义域名的 URL。这也会影响 [OIDC 发行者 (Issuer) 标识符](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) 的值。 | +| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | 你可以为线上测试或生产环境指定自定义域名的 URL。这也会影响 [OIDC 发行者 (Issuer) 标识符](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) 的值。 | | ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | 你可以为生产环境指定自定义域名的 URL（例如 `ADMIN_ENDPOINT=https://admin.domain.com`）。这也会影响管理控制台重定向 URI 的值。 | -| CASE_SENSITIVE_USERNAME | `true` | `boolean` | 指定用户名是否区分大小写。修改此值时请谨慎；更改不会自动调整现有数据库数据，需要手动管理。 | +| CASE_SENSITIVE_USERNAME | `true` | `boolean` | 指定用户名是否区分大小写。修改该值时请谨慎；更改不会自动调整现有数据库数据，需要手动管理。 | | SECRET_VAULT_KEK | `undefined` | `string` | 用于加密 [Secret Vault](/secret-vault) 中数据加密密钥 (DEK) 的密钥加密密钥 (KEK)。Secret Vault 正常工作所必需。必须为 base64 编码字符串。推荐使用 AES-256（32 字节）。示例：`crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | 分阶段 OIDC 私钥轮换的宽限期（秒）。设置为正值时，新私钥会先以 `Next` 状态创建，并在宽限期后才生效。 | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | OIDC 私钥轮换的宽限期（秒）。设置为正值时，新私钥会先以 `Next` 状态创建，并在宽限期后才生效。 | | OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | 仅限自托管。仅当受信任的 OIDC 依赖方端点必须解析为私有网络地址时，设置为 `true`。详见 [OIDC 提供方 SSRF 保护](#oidc-provider-ssrf-protection)。 | ### OIDC 提供方 SSRF 保护 {#oidc-provider-ssrf-protection} -Logto 默认保护 OIDC 提供方的出站请求，防止服务器端请求伪造 (SSRF)。对特殊用途地址（包括回环和私有网络地址）的请求会被阻止。此保护涵盖依赖方端点，如后端注销 URI、`jwks_uri` 和 `sector_identifier_uri`。 +Logto 默认保护 OIDC 提供方的出站请求，防止服务器端请求伪造 (SSRF)。对特殊用途地址（包括回环和私有网络地址）的请求会被阻止。此保护涵盖依赖方端点，如后端注销 URI、`jwks_uri` 和 `sector_identifier_uri`，以及为 [动态应用](/integrate-logto/third-party-applications/dynamic-apps) 获取的客户端 ID 元数据文档。 如果你的自托管部署确实需要访问私有网络上的受信任依赖方端点，请设置 `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true` 并重启所有 Logto 实例。 :::caution -此设置会禁用所有 OIDC 提供方出站请求的 SSRF 保护，而不仅仅是某一个端点。仅当所有配置的依赖方端点都可信，且你的网络控制能防止访问敏感内部服务时才应禁用。 +此设置会禁用所有 OIDC 提供方出站请求的 SSRF 保护，而不仅仅是某一个端点。仅当所有配置的依赖方端点都受信任，并且你的网络控制能防止访问敏感内部服务时才应禁用。 + +[动态应用](/integrate-logto/third-party-applications/dynamic-apps) 在关闭此保护时无法启用，因为它会从客户端自行提供的 URL 获取元数据文档。 ::: @@ -61,13 +63,13 @@ Node 原生支持 HTTPS。提供 **BOTH** `HTTPS_CERT_PATH` 和 `HTTPS_KEY_PATH` 另一种常见做法是在 Node 前面放置一个 HTTPS 代理（如 Nginx）。 -在这种情况下，你可能需要将 `TRUST_PROXY_HEADER` 设置为 `true`，表示信任代理头字段。Logto 会将该值传递给 [Koa 应用设置](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings)。 +在这种情况下，你可能需要将 `TRUST_PROXY_HEADER` 设置为 `true`，表示是否信任代理头字段。Logto 会将该值传递给 [Koa 应用设置](https://github.com/koajs/koa/blob/master/docs/api/index.md#settings)。 -关于何时配置此字段，请参见 [信任 TLS 卸载代理](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies)。 +关于何时配置该字段，请参见 [信任 TLS 卸载代理](https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#trusting-tls-offloading-proxies)。 ## 数据库配置 {#database-configs} -管理过多的环境变量既低效又不灵活，因此我们的大部分通用配置都存储在数据库表 `logto_configs` 中。 +管理过多的环境变量既低效又不灵活，因此我们的大多数通用配置都存储在数据库表 `logto_configs` 中。 该表是一个简单的键值存储，key 可枚举如下： diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index 7e3b108eeff..009306d6047 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -6,35 +6,39 @@ sidebar_position: 6 ## 什么是用户授权页面 (Consent screen)? \{#what-is-consent-screen} -想象一下，你正在使用 Google 账号注册 Logto。当你点击“使用 Google 登录”按钮时，你会被重定向到 Google 的登录页面。在你输入 Google 凭据后，系统会提示你授权 Logto 访问你的 Google 账号信息。这就是用户授权页面 (consent screen)。 +想象一下，你正在使用你的 Google 账户注册 Logto。当你点击“使用 Google 登录”按钮时，你会被重定向到 Google 的登录页面。在你输入 Google 凭据后，系统会提示你授权 Logto 访问你的 Google 账户信息。这就是用户授权页面 (Consent screen)。 -这个页面我们称之为用户**授权页面 (consent screen)** 或**授权页 (consent page)**。它是标准的 [OIDC / OAuth 2.0 流程](/integrate-logto/third-party-applications)，允许用户授权 [第三方应用程序](/integrate-logto/third-party-applications) 代表他们访问其数据。其主要目的是告知用户其个人数据的收集、处理和使用方式，并征求用户对这些活动的明确同意。 +这个页面我们称之为用户**授权页面 (Consent screen)** 或**授权页 (Consent page)**。它是一个标准的 [OIDC / OAuth 2.0 流程](/integrate-logto/third-party-applications)，允许用户授权 [第三方应用程序](/integrate-logto/third-party-applications) 代表他们访问他们的数据。其主要目的是告知用户其个人数据的收集、处理和使用情况，并征求用户对这些活动的明确同意或授权。 -在授权页面 (consent screen) 上，用户通常会看到有关将被收集的数据类型、用途以及是否会与第三方共享的[信息](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information)。这些信息对于透明度至关重要，使用户能够对其隐私和数据安全做出明智的决定。 +在授权页面 (Consent screen) 上，通常会向用户展示有关将要收集的数据类型、数据用途以及是否会与第三方共享的[信息](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information)。这些信息对于透明度至关重要，使用户能够就其隐私和数据安全做出明智的决定。 -在欧盟的通用数据保护条例（[GDPR](https://gdpr-info.eu/art-4-gdpr/)）或美国加利福尼亚消费者隐私法案（[CCPA](https://oag.ca.gov/privacy/ccpa)）等隐私法规背景下，授权页面 (consent screen) 尤为重要，这些法规要求组织在处理用户个人信息前获得用户明确且积极的同意。 +在欧盟的通用数据保护条例 ([GDPR](https://gdpr-info.eu/art-4-gdpr/)) 或美国的加州消费者隐私法案 ([CCPA](https://oag.ca.gov/privacy/ccpa)) 等隐私法规背景下，授权页面 (Consent screen) 尤为重要，这些法规要求组织在处理用户个人信息之前获得用户明确且积极的同意。 -## 用户在 Logto 中何时会看到授权页面 (consent screen)? \{#when-does-user-see-the-consent-screen-in-logto} +## 用户在 Logto 中何时会看到授权页面 (Consent screen)? \{#when-does-user-see-the-consent-screen-in-logto} -如前所述，当用户使用 Google、Facebook 或 Apple 等第三方身份提供商 (IdP) 登录 Logto 时，会出现授权页面 (consent screen)。在这种场景下，Logto 作为服务提供商 (SP)，向 IdP 请求用户信息的访问权限。当 [SP](https://auth.wiki/service-provider) 和 [IdP](https://auth.wiki/identity-provider) 属于不同组织时，通常会展示授权页面 (consent screen)，以便用户授权数据共享。 +如前所述，当用户使用第三方身份提供商 (IdP)（如 Google、Facebook 或 Apple）登录 Logto 时，会出现授权页面 (Consent screen)。在这种设置下，Logto 作为服务提供商 (SP)，请求从 IdP 访问用户信息。通常当 [SP](https://auth.wiki/service-provider) 和 [IdP](https://auth.wiki/identity-provider) 属于不同组织时，需要用户授权以便数据共享，因此会展示授权页面 (Consent screen)。 Consent screen Logto as SP -同样地，在 Logto 中，当 Logto 作为 IdP 时，用户在登录集成了 Logto 的 [**OIDC / OAuth 第三方应用程序**](/integrate-logto/third-party-applications) 时会看到授权页面 (consent screen)。该页面会告知用户应用请求的数据，并征求用户的授权。用户可以查看所请求的权限，并决定是否授权该应用程序。 +同样，在 Logto 中，当 Logto 作为 IdP 时，用户在登录集成了 Logto 的 [**OIDC / OAuth 第三方应用程序**](/integrate-logto/third-party-applications) 时，也会看到授权页面 (Consent screen)。该页面会告知用户应用程序请求的数据，并征求用户的许可。用户可以查看所请求的权限，并决定是否授权 (Authorization) 应用程序。 Consent screen Logto as IdP -## 如何配置授权页面 (consent screen)? \{#how-to-configure-the-consent-screen} +### 未注册（动态）客户端 \{#unregistered-dynamic-clients} -Logto 的授权流程 (consent flow) 允许你授权第三方应用程序的登录。你可以为每个 OIDC 第三方应用程序自定义品牌和权限请求。 +如果启用了 [动态应用](/integrate-logto/third-party-applications/dynamic-apps)，客户端可以在无需预注册的情况下连接到你的租户。对于这些客户端，授权页面 (Consent screen) 会显示额外的提示，以及客户端 ID URL 的主机名。客户端名称和 logo 来自客户端自己的元数据文档，因此他们可以模仿任何品牌，但主机名无法伪造。 -了解更多关于设置 [第三方应用程序](/integrate-logto/third-party-applications/) 以及在 Logto 中配置 [授权页面 (consent screen)](/integrate-logto/third-party-applications/consent-screen-branding/) 的信息。 +## 如何配置授权页面 (Consent screen)? \{#how-to-configure-the-consent-screen} + +Logto 的授权流程允许你授权第三方应用程序的登录。你可以为每个 OIDC 第三方应用程序自定义品牌和权限请求。 + +了解更多关于在 Logto 中设置 [第三方应用程序](/integrate-logto/third-party-applications/) 和配置 [授权页面 (Consent screen)](/integrate-logto/third-party-applications/consent-screen-branding/) 的信息。 ## 相关资源 \{#related-resources} - 将你的服务升级为带有授权页面 (consent screen) 的安全 OIDC IdP。 + 将你的服务变成带有授权页面 (Consent screen) 的安全 OIDC IdP。 -用户授权页面 (consent screen) 介绍。 +用户授权页面 (Consent screen) 介绍。 OIDC Prompt 101：开发者简单指南 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index b340d317903..0d01cf85d44 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -7,11 +7,11 @@ sidebar_position: 7 ## 简介 \{#introduction} -在 Logto 中，_应用_ 指的是在 Logto 平台上注册并被授权访问用户信息或代表用户执行操作的特定软件程序或服务。应用用于识别向 Logto API 发起请求的来源，并管理用户访问这些应用时的认证 (Authentication) 和授权 (Authorization) 流程。 +在 Logto 中，_应用_ 指的是在 Logto 平台上注册并被授权访问用户信息或代表用户执行操作的特定软件程序或服务。应用用于标识向 Logto API 发起请求的来源，并管理用户访问这些应用时的认证 (Authentication) 和授权 (Authorization) 流程。 -在 Logto 的登录体验中使用应用，可以让用户在一个位置轻松访问和管理他们已授权的应用，并享受一致且安全的认证 (Authentication) 流程。这有助于简化用户体验，并确保只有被授权的人员才能访问敏感信息或代表组织执行操作。 +在 Logto 的登录体验中使用应用，可以让用户从一个位置轻松访问和管理他们已授权的应用，并拥有一致且安全的认证 (Authentication) 流程。这有助于简化用户体验，并确保只有被授权的个人才能访问敏感信息或代表组织执行操作。 -应用还用于 Logto 的审计日志中，用于追踪用户活动并识别潜在的安全威胁或漏洞。通过将特定操作与某个应用关联，Logto 能够提供关于数据如何被访问和使用的详细洞察，帮助组织更好地管理其安全和合规需求。 +应用还用于 Logto 的审计日志中，用于追踪用户活动并识别任何潜在的安全威胁或漏洞。通过将特定操作与某个应用关联，Logto 能够提供有关数据如何被访问和使用的详细洞察，帮助组织更好地管理其安全和合规要求。 如果你想将你的应用集成到 Logto，请参阅 [集成 Logto](/integrate-logto)。 ## 属性 \{#properties} @@ -20,12 +20,16 @@ sidebar_position: 7 _应用 ID_ 是用于在 Logto 中唯一标识你的应用的自动生成密钥，在 OAuth 2.0 中被称为 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)。 +:::note +[动态应用](/integrate-logto/third-party-applications/dynamic-apps) 客户端不会在 Logto 中注册。它们的 client ID 是客户端拥有的公共 HTTPS URL，用于提供客户端元数据文档。 +::: + ### 应用类型 \{#application-types} _应用_ 可以是以下应用类型之一： - **原生应用**：运行在原生环境中的应用。例如 iOS 应用、Android 应用。 - - **设备流应用**：一种特殊类型的原生应用，适用于输入受限设备或无头应用（如智能电视、游戏主机、CLI 工具、IoT 设备）。它使用 [OAuth 2.0 设备授权许可](https://auth.wiki/device-flow) 替代标准的基于重定向的流程。详见 [设备流快速入门](/quick-starts/device-flow)。 + - **设备流应用**：是一种针对输入受限设备或无头应用（如智能电视、游戏主机、CLI 工具、IoT 设备）的特殊原生应用类型。它使用 [OAuth 2.0 设备授权许可](https://auth.wiki/device-flow) 替代标准的基于重定向的流程。详情见 [设备流快速开始](/quick-starts/device-flow)。 - **单页应用**：运行在 Web 浏览器中的应用，通过从服务器获取新数据来更新页面，而无需加载整个新页面。例如 React DOM 应用、Vue 应用。 - **传统 Web 应用**：仅由 Web 服务器渲染和更新页面的应用。例如 JSP、PHP。 - **机器对机器 (M2M) 应用**：在机器环境中运行、用于直接服务间通信且无需用户交互的应用。 @@ -35,7 +39,7 @@ _应用_ 可以是以下应用类型之一： _应用密钥_ 是用于在认证 (Authentication) 系统中认证应用的密钥，专为私有客户端（传统 Web 和 M2M 应用）作为私有安全屏障。 :::tip -单页应用（SPA）和原生应用不提供应用密钥。SPA 和原生应用属于“公开客户端”，无法保密密钥（浏览器代码或应用包可被检查）。Logto 通过 PKCE、严格的重定向 URI / CORS 校验、短生命周期访问令牌 (Access token) 和刷新令牌 (Refresh token) 轮换来保护它们，而不是使用应用密钥。 +单页应用 (SPA) 和原生应用不提供应用密钥。SPA 和原生应用属于“公共客户端”，无法保密（浏览器代码或应用包可被检查）。Logto 通过 PKCE、严格的重定向 URI / CORS 校验、短生命周期访问令牌 (Access token) 和刷新令牌 (Refresh token) 轮换来保护它们，而不是应用密钥。 ::: ### 应用名称 \{#application-name} @@ -45,24 +49,24 @@ _应用名称_ 是应用的人类可读名称，将显示在管理控制台中 _应用名称_ 是 Logto 应用管理的重要组成部分，它让管理员能够轻松识别和追踪平台内各个应用的活动。 :::note -需要注意的是，_应用名称_ 应谨慎选择，因为它会对所有有权访问管理控制台的用户可见。名称应准确反映应用的用途和功能，同时易于理解和识别。 +需要注意的是，_应用名称_ 应谨慎选择，因为它会对所有有权访问管理控制台的用户可见。它应准确反映应用的用途和功能，同时易于理解和识别。 ::: ### 描述 \{#description} -应用的简要描述将显示在管理控制台的应用详情页。描述旨在为管理员提供有关应用的更多信息，如用途、功能及其他相关细节。 +应用的简要描述将显示在管理控制台的应用详情页。描述旨在为管理员提供有关应用的附加信息，如其用途、功能及其他相关细节。 ### 重定向 URI \{#redirect-uris} _重定向 URI_ 是为应用预先配置的一组有效重定向 URI。当用户登录 Logto 并尝试访问应用时，他们会被重定向到应用设置中指定的允许 URI 之一。 -允许的 URI 列表用于校验应用在认证 (Authentication) 流程中向 Logto 发送的授权请求中包含的重定向 URI。如果授权请求中指定的重定向 URI 与应用设置中的允许 URI 匹配，则用户在认证 (Authentication) 成功后会被重定向到该 URI。如果重定向 URI 不在允许列表中，用户将不会被重定向，认证 (Authentication) 流程也会失败。 +允许的 URI 列表用于校验应用在认证 (Authentication) 流程中向 Logto 发送的授权请求中包含的重定向 URI。如果授权请求中指定的重定向 URI 与应用设置中的某个允许 URI 匹配，用户在认证 (Authentication) 成功后会被重定向到该 URI。如果重定向 URI 不在允许列表中，用户将不会被重定向，认证 (Authentication) 流程也会失败。 :::note -务必确保所有有效的重定向 URI 都已添加到 Logto 应用的允许列表中，以确保用户在认证 (Authentication) 后能够成功访问应用。 +务必确保所有有效的重定向 URI 都被添加到 Logto 应用的允许列表中，以确保用户在认证 (Authentication) 后能够成功访问应用。 ::: -你可以参考 [重定向端点](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) 了解更多信息。 +你可以查看 [重定向端点](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) 了解更多信息。 理解 OIDC 授权码流程中的重定向 URI @@ -82,23 +86,23 @@ _适用范围：单页应用、传统 Web 应用_ **示例：** -- `https://*.example.com/callback` —— 匹配任意子域名 -- `https://preview-*.example.com/callback` —— 匹配预览部署 -- `https://example.com/*/callback` —— 匹配任意路径段 +- `https://*.example.com/callback` - 匹配任意子域名 +- `https://preview-*.example.com/callback` - 匹配预览部署 +- `https://example.com/*/callback` - 匹配任意路径段 :::caution -通配符重定向 URI 并非标准 OIDC，且可能增加攻击面。请谨慎使用，并尽量优先使用精确的重定向 URI。 +通配符重定向 URI 并非标准 OIDC，且可能增加攻击面。请谨慎使用，并尽可能优先使用精确的重定向 URI。 ::: -### 登出后重定向 URI \{#post-sign-out-redirect-uris} +### 注销后重定向 URI \{#post-sign-out-redirect-uris} -_登出后重定向 URI_ 是为应用预先配置的一组有效 URI，用于用户从 Logto 登出后重定向。 +_注销后重定向 URI_ 是为应用预先配置的一组有效 URI，用于用户从 Logto 注销后重定向。 -允许的 _登出后重定向 URI_ 用于 OIDC 的 RP 发起（Relying Party Initiated）注销规范。该规范为应用发起用户注销请求提供了标准方法，包括在用户登出后重定向到预配置端点。 +允许的 _注销后重定向 URI_ 用于 OIDC 中的 RP 发起（Relying Party Initiated）注销规范。该规范为应用发起用户注销请求提供了标准方法，包括在用户注销后重定向到预先配置的端点。 -当用户从 Logto 登出时，其会话被终止，并被重定向到应用设置中指定的允许 URI 之一。这确保用户仅被引导到授权且有效的端点，防止因重定向到未知或未验证端点而导致的未授权访问和安全风险。 +当用户从 Logto 注销时，其会话被终止，并被重定向到应用设置中指定的某个允许 URI。这确保用户仅被引导到授权且有效的端点，防止因重定向到未知或未验证端点而导致的未授权访问和安全风险。 -你可以参考 [RP 发起注销](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) 了解更多信息。 +你可以查看 [RP 发起注销](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) 了解更多信息。 ### CORS 允许来源 \{#cors-allowed-origins} @@ -107,18 +111,18 @@ _CORS（跨域资源共享）允许来源_ 是允许应用向 Logto 服务发起 CORS 允许来源列表用于限制来自未授权域名对 Logto 服务的访问，并有助于防止跨站请求伪造（CSRF）攻击。通过在 Logto 中为应用指定允许来源，服务可以确保只有被授权的域名能够向服务发起请求。 :::note -允许来源列表应包含应用实际部署的来源。这确保应用的请求被允许，而来自未授权来源的请求会被阻止。 +允许来源列表应包含应用实际部署的来源。这确保来自应用的请求被允许，而来自未授权来源的请求会被拦截。 ::: ### OpenID 提供方配置端点 \{#openid-provider-configuration-endpoint} -[OpenID Connect 发现](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest)的端点。 +[OpenID Connect 发现](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) 的端点。 ### 授权端点 \{#authorization-endpoint} _授权端点_ 是 OIDC 术语，是用于启动用户认证 (Authentication) 流程的必需端点。当用户尝试访问已在 Logto 平台注册的受保护资源或应用时，他们会被重定向到 _授权端点_ 以认证其身份并获得访问所请求资源的授权 (Authorization)。 -你可以参考 [授权端点](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 了解更多信息。 +你可以查看 [授权端点](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 了解更多信息。 ### 令牌端点 \{#token-endpoint} @@ -126,17 +130,17 @@ _令牌端点_ 是 OIDC 术语，是 OIDC 客户端用于从 OIDC 提供方获 当 OIDC 客户端需要获取访问令牌 (Access token) 或 ID 令牌 (ID token) 时，会携带授权许可（通常是授权码或刷新令牌 (Refresh token)）向令牌端点发起请求。令牌端点验证授权许可后，如果有效，则向客户端颁发访问令牌 (Access token) 或 ID 令牌 (ID token)。 -你可以参考 [令牌端点](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) 了解更多信息。 +你可以查看 [令牌端点](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) 了解更多信息。 ### Userinfo 端点 \{#userinfo-endpoint} OpenID Connect [UserInfo 端点](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)。 -### 总是颁发刷新令牌 (Refresh token) \{#always-issue-refresh-token} +### 始终颁发刷新令牌 (Refresh token) \{#always-issue-refresh-token} _适用范围：传统 Web、SPA_ -启用后，无论认证 (Authentication) 请求中是否包含 `prompt=consent`，或权限 (Scope) 中是否包含 `offline_access`，Logto 都会始终颁发刷新令牌 (Refresh token)。 +启用后，Logto 将始终颁发刷新令牌 (Refresh token)，无论认证 (Authentication) 请求中是否包含 `prompt=consent`，或权限 (Scope) 中是否包含 `offline_access`。 但除非必要（通常用于某些需要刷新令牌 (Refresh token) 的第三方 OAuth 集成），否则不建议这样做，因为这与 OpenID Connect 不兼容，且可能带来潜在问题。 @@ -144,22 +148,22 @@ _适用范围：传统 Web、SPA_ _默认值：`true`_ -启用后，当客户端使用刷新令牌 (Refresh token) 请求新令牌时，Logto 可能会颁发新的刷新令牌 (Refresh token)。如果刷新令牌 (Refresh token) 及其应用授权 (grant) 仍然有效，默认轮换策略如下： +启用后，当客户端使用刷新令牌 (Refresh token) 请求新令牌时，Logto 可能会颁发新的刷新令牌 (Refresh token)。如果刷新令牌 (Refresh token) 及其应用授权 (app grant) 仍然有效，默认轮换策略如下： -- 刷新令牌 (Refresh token) 仅可在刷新令牌链存在不超过一年时轮换。这是内部轮换安全上限；刷新令牌自身的 TTL 或应用授权 (grant) TTL 可能更早过期。达到上限后，Logto 不再轮换刷新令牌，当前刷新令牌的过期时间为最终时间。 -- 对于未使用发送方约束刷新令牌的公开客户端（如常规原生应用和单页应用），Logto 在每次刷新令牌请求时轮换刷新令牌，只要轮换被允许。 -- 对于其他客户端，Logto 仅在刷新令牌接近过期时（原始 TTL 已过去 >=70%）轮换刷新令牌。 +- 刷新令牌 (Refresh token) 仅可在刷新令牌链存在不超过一年时轮换。这是内部轮换安全上限；刷新令牌自身的 TTL 或应用授权 (app grant) TTL 可能更早过期。达到上限后，Logto 不再轮换刷新令牌，当前刷新令牌的过期时间为最终时间。 +- 对于未使用发送方约束刷新令牌的公共客户端（如常规原生应用和单页应用），Logto 在每次刷新令牌请求时轮换刷新令牌，只要允许轮换。 +- 对于其他客户端，Logto 仅在刷新令牌接近过期时轮换（原始 TTL 已过去 >=70%）。 :::note -对于公开客户端，强烈建议出于安全考虑保持刷新令牌轮换开启。 +对于公共客户端，强烈建议出于安全考虑保持刷新令牌 (Refresh token) 轮换开启。 发送方约束刷新令牌绑定到客户端持有的证明密钥或证书。对于常规 SPA，轮换会颁发新刷新令牌，但不会延长刷新令牌的生命周期。新刷新令牌继承前一个刷新令牌的剩余 TTL。 ::: :::caution 刷新令牌链生命周期 -刷新令牌 (Refresh token) 与应用授权 (grant) 相关联。Logto 默认授权 (grant) TTL 为 **180 天**。当授权过期时，刷新令牌请求会失败，刷新令牌也无法再用于获取新令牌，即使刷新令牌轮换已启用。 +刷新令牌 (Refresh token) 与应用授权 (app grant) 相关联。Logto 默认授权 (grant) TTL 为 **180 天**。当授权过期时，刷新令牌请求会失败，即使刷新令牌轮换已启用，刷新令牌也无法再用于获取新令牌。 -这意味着基于刷新令牌的授权 (Authorization) 的实际最长生命周期目前受限于授权 (grant) TTL、显式吊销或刷新令牌自身的过期时间，以先到者为准。 +这意味着基于刷新令牌的授权 (Authorization) 的实际最长生命周期目前受限于授权 TTL、显式吊销或刷新令牌自身的过期时间，以先到者为准。 ::: @@ -170,22 +174,22 @@ _默认值：`true`_ _适用范围：原生应用、传统 Web、SPA；默认值：14 天；最大值：180 天_ -刷新令牌 (Refresh token) 可用于请求新访问令牌 (Access token) 的有效期，过期后即失效。令牌请求会将刷新令牌的 TTL 延长至该值。 +刷新令牌 (Refresh token) 可用于请求新访问令牌 (Access token) 的时长，超过后即失效。每次令牌请求会将刷新令牌的 TTL 延长至该值。 通常建议设置较低的值。 :::note -出于安全原因，单页应用（SPA）不支持 TTL 刷新。对于 SPA，此设置控制刷新令牌的固定生命周期，从最初颁发时开始。Logto 不会通过令牌请求延长 TTL，刷新令牌轮换也不会阻止 SPA 刷新令牌过期。 +出于安全原因，单页应用 (SPA) 不支持 TTL 刷新。对于 SPA，此设置控制刷新令牌从首次颁发起的固定生命周期。Logto 不会通过令牌请求延长 TTL，刷新令牌轮换也无法阻止 SPA 刷新令牌过期。 ::: :::caution 刷新令牌 TTL 与授权 (grant) TTL -刷新令牌 TTL 并不是唯一的过期限制。刷新令牌与应用授权 (grant) 绑定，Logto 默认授权 (grant) TTL 为 **180 天**。当授权过期时，即使刷新令牌本身仍然有效，刷新令牌请求也会失败。 +刷新令牌 TTL 并非唯一的过期限制。刷新令牌与应用授权 (app grant) 绑定，Logto 默认授权 TTL 为 **180 天**。当授权过期时，即使刷新令牌本身仍然有效，刷新令牌请求也会失败。 -对于令牌请求会刷新刷新令牌 TTL 的客户端，授权 (grant) TTL 是刷新令牌链的绝对最长生命周期。对于 SPA，刷新令牌的固定 TTL 可能会在授权 (grant) 到期前过期。 +对于令牌请求可刷新刷新令牌 TTL 的客户端，授权 TTL 是刷新令牌链的绝对最长生命周期。对于 SPA，刷新令牌的固定 TTL 可能会在授权过期前先到期。 ::: :::caution 刷新令牌与会话绑定 -当刷新令牌在授权请求中**未包含** `offline_access` 权限 (Scope) 时，它将绑定到用户会话。会话的固定 TTL 为 **14 天**。会话过期后，无论刷新令牌自身 TTL 设置如何，刷新令牌都会失效。 +当在授权请求中**未**包含 `offline_access` 权限 (Scope) 时，刷新令牌将绑定到用户会话。会话的固定 TTL 为 **14 天**。会话过期后，刷新令牌无论自身 TTL 设置如何都将失效。 如需刷新令牌 TTL 设置完全生效，请确保在授权请求中包含 `offline_access` 权限 (Scope)。 ::: @@ -194,16 +198,16 @@ _适用范围：原生应用、传统 Web、SPA；默认值：14 天；最大值 OpenID Connect 后端注销端点。详见 [联合登出：后端注销](#)。 -### 最大允许授权数（`maxAllowedGrants`）\{#max-allowed-grants-maxallowedgrants} +### 最大允许授权数 (`maxAllowedGrants`) \{#max-allowed-grants-maxallowedgrants} -`maxAllowedGrants` 是 `customClientMetadata` 下的可选应用级字段，用于控制当前应用每个用户允许的最大并发活跃授权数。 +`maxAllowedGrants` 是 `customClientMetadata` 下的可选应用级字段，用于控制当前应用每个用户最多可同时拥有的活跃授权数。 - **默认值**：`undefined`（无限制） -- **配置后**：每次授权成功，Logto 会检查当前应用下该用户的所有活跃授权（跨浏览器和设备）。如果超出限制，Logto 会吊销最早的授权。 +- **配置后**：每次授权 (Authorization) 成功，Logto 会检查当前应用下该用户的所有活跃授权（跨浏览器和设备）。如超出限制，Logto 会吊销最早的授权。 -当你希望限制每个应用的并发认证 (Authentication) 设备数量时，此设置非常有用。 +当你希望限制每个应用的并发认证 (Authentication) 设备数时，此设置非常有用。 -每次驱逐都会触发 `Grant.LimitExceeded` [Webhook 事件](/developers/webhooks/webhooks-events#exception-hook-events)，你可以据此通知用户或追踪限制被触发的频率。 +每次驱逐都会触发 `Grant.LimitExceeded` [Webhook 事件](/developers/webhooks/webhooks-events#exception-hook-events)，你可以据此通知用户或统计限制被触发的频率。 :::note diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 25e7a47be91..9db9ead7247 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,58 +4,66 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; # 第三方应用（OAuth / OIDC） -Logto 的第三方应用集成让你能够将 Logto 作为[身份提供商 (IdP)](https://auth.wiki/identity-provider)为外部应用提供服务。 +Logto 的第三方应用集成让你可以将 Logto 作为外部应用的 [身份提供商 (IdP)](https://auth.wiki/identity-provider)。 身份提供商 (IdP) 是一种验证用户身份并管理其登录凭据的服务。在确认用户身份后，IdP 会生成认证 (Authentication) 令牌或断言，并允许用户访问各种应用或服务，无需再次登录。 -与[集成 Logto 到你的应用](/integrate-logto/integrate-logto-into-your-application)指南中你自己开发和完全控制的应用不同，第三方应用是由外部开发者或业务合作伙伴开发的独立服务。 +与 [将 Logto 集成到你的应用](/integrate-logto/integrate-logto-into-your-application) 指南中你自己开发和完全控制的应用不同，第三方应用是由外部开发者或业务合作伙伴开发的独立服务。 -这种集成方式非常适合常见的业务场景。你可以让用户使用他们的 Logto 账户访问合作伙伴应用，就像企业用户用 Google Workspace 登录 Slack 一样。你也可以打造一个开放平台，让第三方应用可以添加“使用 Logto 登录”功能，类似于“使用 Google 登录”。 +这种集成方式非常适合常见的业务场景。你可以让用户使用他们的 Logto 账户访问合作伙伴应用，就像企业用户用 Google Workspace 登录 Slack 一样。你还可以构建一个开放平台，让第三方应用添加“使用 Logto 登录”功能，类似于“使用 Google 登录”。 -Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议构建的身份服务，提供[认证 (Authentication)](https://auth.wiki/authentication)和[授权 (Authorization)](https://auth.wiki/authorization)能力。这让集成 OIDC 第三方应用变得和传统 Web 应用一样简单。 +Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议构建的身份服务，提供 [认证 (Authentication)](https://auth.wiki/authentication) 和 [授权 (Authorization)](https://auth.wiki/authorization) 能力。这使得集成 OIDC 第三方应用就像传统 Web 应用一样简单直接。 由于 OIDC 是在 [OAuth 2.0](https://auth.wiki/oauth-2.0) 基础上增加了认证 (Authentication) 层，因此你也可以通过 OAuth 协议集成第三方应用。 +## 引入第三方应用的两种方式 \{#two-ways-to-onboard-a-third-party-app} + +- **在 Logto 中注册应用**（本指南）：你创建应用并配置其权限和重定向 URI。适用于你了解你的合作伙伴的场景。 +- **[动态应用](/integrate-logto/third-party-applications/dynamic-apps)**：客户端无需预注册，通过一个公开的 HTTPS URL（作为 client ID）提供自己的元数据文档。适用于任何客户端都可能接入的场景，如 MCP 客户端和 AI agent。 + +两种方式可以同时使用。 + ## 在 Logto 中创建第三方应用 \{#create-a-third-party-application-in-logto} -1. 前往 控制台 > 应用。 -2. 点击“创建应用”按钮。选择“第三方应用”作为应用类型，并选择以下集成协议之一： +1. 进入 控制台 > 应用。 +2. 点击“创建应用”按钮，选择“第三方应用”作为应用类型，并选择以下集成协议之一： - OIDC / OAuth 3. 根据第三方应用的类型选择应用类型： - - **传统 Web**：后端可安全存储客户端密钥的服务端渲染应用（如 Node.js、PHP、Java）。 + - **传统 Web**：后端可安全存储 client secret 的服务端渲染应用（如 Node.js、PHP、Java）。 - **单页应用 (SPA)**：完全在浏览器端运行、无法安全存储密钥的客户端渲染应用（如 React、Vue、Angular）。 - **原生应用**：运行在用户设备上的移动或桌面应用（如 iOS、Android、Electron）。 4. 输入你的应用名称和描述，点击“创建”按钮。一个新的第三方应用就会被创建。 -所有创建的第三方应用会在“应用”页面的“第三方应用”标签下进行分类。这种安排有助于你将它们与你自己的应用区分开，方便你在一个地方统一管理所有应用。 +所有已创建的第三方应用会在应用页面的“第三方应用”标签下进行分类。这种安排有助于你将它们与你自己的应用区分开，便于统一管理。 -如需限制哪些用户可以登录第三方应用，请在应用的 **规则** 标签页配置[应用级访问控制](/authorization/app-level-access-control)。 +如需限制哪些用户可以登录第三方应用，请在应用的 **规则** 标签页配置 [应用级访问控制](/authorization/app-level-access-control)。 ## 集成指南 \{#integration-guide} ### 查找应用配置信息 \{#find-the-application-configurations} -在应用详情页，你可以找到集成所需的 [**Client ID**](/integrate-logto/application-data-structure#application-id)、[**Client secret**](/integrate-logto/application-data-structure#application-secret)（仅限传统 Web 应用）和 OIDC 端点。 +在应用详情页，你可以找到集成所需的 [**Client ID**](/integrate-logto/application-data-structure#application-id)、[**Client secret**](/integrate-logto/application-data-structure#application-secret)（仅适用于传统 Web 应用）和 OIDC 端点。 -如果第三方服务支持 OIDC 发现，只需提供 **发现端点**。否则，点击 **显示端点详情** 查看所有端点，包括[授权端点](/integrate-logto/application-data-structure#authorization-endpoint)和[令牌端点](/integrate-logto/application-data-structure#token-endpoint)。 +如果第三方服务支持 OIDC 发现，只需提供 **发现端点**。否则，点击 **显示端点详情** 查看所有端点，包括 [授权端点](/integrate-logto/application-data-structure#authorization-endpoint) 和 [令牌端点](/integrate-logto/application-data-structure#token-endpoint)。 ### 集成支持第三方 IdP 的服务 \{#integrate-with-services-that-support-third-party-idp} -如果你要连接的服务或产品原生支持外部身份提供商配置（如企业 SaaS 平台、协作工具），设置流程非常简单： +如果你要连接的服务或产品原生支持外部身份提供商配置（如企业 SaaS 平台、协作工具），配置过程非常简单： 1. 打开该服务的 IdP 或 SSO 配置页面。 -2. 从 Logto 复制 **Client ID**（如需则复制 **Client secret**），粘贴到服务的配置中。 +2. 从 Logto 复制 **Client ID**（如需则还有 **Client secret**），粘贴到服务的配置中。 3. 如果服务支持 OIDC 自动发现，提供 **发现端点**，否则手动复制 **授权端点** 和 **令牌端点**。 -4. 从服务的配置页面复制 **重定向 URI**，并将其添加到 Logto 应用的允许重定向 URI 列表中。 -5. 如服务允许，配置 **scopes**。由于 Logto 是 OIDC 提供商，如果需要认证 (Authentication) 用户，请包含 `openid` scope（可获取 ID 令牌和 UserInfo 端点）。如果只需 OAuth 资源访问，`openid` scope 可选。 +4. 从服务配置页面复制 **重定向 URI**，并将其添加到 Logto 应用的允许重定向 URI 列表中。 +5. 如服务允许，配置 **scopes**。由于 Logto 是 OIDC 提供商，如需认证 (Authentication) 用户请包含 `openid` scope（可获取 ID 令牌和 UserInfo 端点）。如只需 OAuth 资源访问，`openid` scope 可选。 -服务配置完成后会自动处理 OAuth / OIDC 流程。 +配置完成后，服务会自动处理 OAuth / OIDC 流程。 ### 通过 OAuth / OIDC 协议集成 \{#integrate-via-oauth-protocol} @@ -64,48 +72,48 @@ Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议 -传统 Web 应用属于**机密客户端**，可以在后端安全存储客户端密钥。完整实现细节见 [授权码流程](https://auth.wiki/authorization-code-flow)。 +传统 Web 应用属于**机密客户端**，可以在后端安全存储 client secret。完整实现细节见 [授权码流程](https://auth.wiki/authorization-code-flow)。 **关键步骤：** -1. **发起授权请求**：将用户重定向到 Logto 的授权端点，携带 `client_id`、`redirect_uri`、`response_type=code` 和 `scope`。 +1. **发起授权**：将用户重定向到 Logto 的授权端点，携带 `client_id`、`redirect_uri`、`response_type=code` 和 `scope`。 2. **处理回调**：从重定向中接收授权 `code`。 -3. **交换令牌**：在你的后端，通过 POST 请求将 code、`client_id` 和 `client_secret` 发送到令牌端点。 +3. **交换令牌**：在后端向令牌端点 POST code、`client_id` 和 `client_secret`。 -单页应用和原生应用属于**公开客户端**，无法安全存储密钥。这类应用必须使用 [PKCE（Proof Key for Code Exchange）](https://auth.wiki/pkce) 进行安全授权。完整实现细节见 [授权码流程](https://auth.wiki/authorization-code-flow) 和 [PKCE](https://auth.wiki/pkce)。 +单页应用和原生应用属于**公开客户端**，无法安全存储密钥。这类应用必须使用 [PKCE（Proof Key for Code Exchange）](https://auth.wiki/pkce) 实现安全授权。完整实现细节见 [授权码流程](https://auth.wiki/authorization-code-flow) 和 [PKCE](https://auth.wiki/pkce)。 **关键步骤：** 1. **生成 PKCE 参数**：创建 `code_verifier` 并派生 `code_challenge`（SHA-256）。 -2. **发起授权请求**：将用户重定向到授权端点，携带 `code_challenge` 和 `code_challenge_method=S256`。 +2. **发起授权**：将用户重定向到授权端点，携带 `code_challenge` 和 `code_challenge_method=S256`。 3. **处理回调**：从重定向中接收授权 `code`。 -4. **交换令牌**：通过 POST 请求将 code 和原始 `code_verifier` 发送到令牌端点。 +4. **交换令牌**：向令牌端点 POST code 和原始 `code_verifier`。 ### 通过设备流集成 \{#integrate-via-device-flow} -对于运行在输入受限设备（如智能电视、游戏主机、CLI 工具）上的原生第三方应用，标准的基于重定向的授权码流程可能不可行。在这种情况下，应用可以使用 [OAuth 2.0 设备授权 (Device Authorization Grant)](https://auth.wiki/device-flow)。 +对于运行在输入受限设备（如智能电视、游戏主机、CLI 工具）上的原生第三方应用，标准的基于重定向的授权码流程可能不可行。在这种情况下，应用可以使用 [OAuth 2.0 设备授权许可](https://auth.wiki/device-flow)。 -使用设备流时，设备会显示一个用户代码和一个验证网址。用户在另一台设备（手机、电脑）上访问该网址，输入代码并完成认证 (Authentication)。设备会轮询 Logto 的令牌端点，直到授权完成。 +设备流下，设备会显示一个用户码和一个验证 URL。用户在另一台设备（手机、电脑）上访问该 URL，输入用户码并完成认证 (Authentication)。设备会轮询 Logto 的令牌端点，直到授权完成。 :::note -在实现设备流之前，请确保已在 Logto 控制台为你的第三方应用配置所需的[权限](/integrate-logto/third-party-applications/permission-management)。第三方应用请求未启用的 scopes 将被拒绝访问。 +在实现设备流之前，请确保已在 Logto 控制台为你的第三方应用配置所需的 [权限](/integrate-logto/third-party-applications/permission-management)。第三方应用请求未启用的 scopes 会被拒绝访问。 ::: 完整实现细节见 [设备流快速入门](/quick-starts/device-flow)。 ## OIDC 第三方应用的用户授权页面 (Consent screen) \{#consent-screen-for-oidc-third-party-applications} -出于安全考虑，所有 OIDC 第三方应用在被 Logto 认证 (Authentication) 后都会被重定向到[用户授权页面 (Consent screen)](/end-user-flows/consent-screen)进行用户授权 (Authorization)。 +出于安全考虑，所有 OIDC 第三方应用在被 Logto 认证 (Authentication) 后都会被重定向到 [用户授权页面 (Consent screen)](/end-user-flows/consent-screen) 进行用户授权 (Authorization)。 -所有第三方请求的[用户资料权限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API 资源权限](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[组织权限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes)以及组织成员信息都会在用户授权页面 (Consent screen) 上展示。 +所有第三方请求的 [用户资料权限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API 资源权限](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[组织权限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) 以及组织成员信息都会在用户授权页面展示。 -只有当用户点击“授权 (Authorize)”按钮后，这些请求的权限才会被授予第三方应用。 +这些请求的权限只有在用户点击“授权 (Authorize)”按钮后才会授予第三方应用。
consent screen @@ -126,14 +134,23 @@ Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议 }, { type: 'link', - label: '用户授权页面品牌定制', + label: '用户授权页面品牌化', href: '/integrate-logto/third-party-applications/consent-screen-branding', - description: - '个性化用户授权页面 (Consent screen) 外观，使其与你的品牌形象一致，提供统一的用户体验。', + description: '自定义用户授权页面外观，使其与你的品牌形象一致，提供一致的用户体验。', customProps: { icon: , }, }, + { + type: 'link', + label: '动态应用（CIMD）', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + '允许 OAuth 客户端无需预注册即可连接，使用客户端 ID 元数据文档 URL 作为 client ID。', + customProps: { + icon: , + }, + }, ]} /> @@ -142,15 +159,15 @@ Logto 是基于 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 协议
-### 如何确保用户只能在用户授权页面 (Consent screen) 授予他们实际拥有的权限？ \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} +### 如何确保用户在用户授权页面 (Consent screen) 上只能授权自己实际拥有的权限？ \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} Logto 使用基于角色的访问控制 (RBAC) 管理用户权限。在用户授权页面 (Consent screen) 上，只会显示用户已通过其角色分配的 scopes（权限）。如果第三方应用请求了用户没有的 scopes，这些 scopes 会被排除，以防止未经授权的授权 (Authorization)。 -管理方法如下： +管理方式如下： -- 定义带有特定 scopes 的[全局角色](/authorization/role-based-access-control)或[组织角色](/authorization/organization-template)。 +- 定义带有特定 scopes 的 [全局角色](/authorization/role-based-access-control) 或 [组织角色](/authorization/organization-template)。 - 根据访问需求为用户分配角色。 - 用户会自动继承其角色的 scopes。 diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..014bec20f18 --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,99 @@ +--- +description: 允许 OAuth 客户端通过使用 client ID 元数据文档 URL 作为其 client ID，无需预注册即可连接到你的租户。 +sidebar_label: 动态应用 (CIMD) +sidebar_position: 3 +--- + +# 动态应用 (CIMD) + +动态应用允许 OAuth 客户端无需预注册即可连接到你的租户。客户端不再使用 Logto 分配的 client ID，而是使用一个公开的 HTTPS URL 作为其 `client_id`。该 URL 提供一个描述客户端的 JSON 文档，称为 [client ID 元数据文档 (CIMD)](https://auth.wiki/client-id-metadata-document)。Logto 会获取该文档，并将该客户端视为[第三方应用](/integrate-logto/third-party-applications)。 + +动态应用实现了 IETF 草案 [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html)。 + +## 何时使用动态应用 \{#when-to-use-dynamic-app} + +当你了解你的合作伙伴时，预注册是可行的。但当任何客户端都可能连接时，预注册就不适用了，这在 [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents) 生态系统中很常见：用户让他们的 AI 代理连接到你的服务，而该代理之前从未与你的租户通信过。 + +通过动态应用，客户端在其拥有的 URL 上发布自己的元数据，该 URL 就是其身份。你的租户中无需提前创建任何内容。 + +| | 已注册第三方应用 | 动态应用 | +| ------------- | ---------------- | --------------------------------------- | +| Client ID | 由 Logto 分配 | 客户端拥有的 HTTPS URL | +| 注册 | 必须 | 不需要 | +| Client secret | 支持 | 不支持 | +| 权限 | 每个应用单独配置 | 所有动态客户端共享 | +| 授权类型 | 取决于应用类型 | `authorization_code` 和 `refresh_token` | + +动态客户端属于公开客户端，因此始终使用 [PKCE](https://auth.wiki/pkce)。你可以同时使用这两种模式。你信任的合作伙伴仍然可以拥有带有专属权限的注册应用。 + +## 启用动态应用 \{#enable-dynamic-app} + +1. 前往 控制台 > 应用程序 并打开 **第三方应用** 标签页。 +2. 点击 **创建应用程序** 并选择 **动态应用** 卡片。此操作会启用租户级功能，而不是创建一个应用程序。 +3. 在对话框中确认。启用后，任何拥有有效公开 HTTPS client ID URL 的 OAuth 客户端都可以为你的租户发起授权请求。 +4. 在应用程序列表中打开动态应用，进入 **权限** 标签页进行权限授予。 + +动态应用没有可编辑的名称、重定向 URI 或凭据。每个客户端会在其元数据文档中提供这些信息。 + +:::note +动态应用需要启用 [OIDC 提供方 SSRF 防护](/concepts/core-service/configuration#oidc-provider-ssrf-protection)，因为 Logto 会从互联网获取元数据文档。禁用该防护的自托管实例无法启用动态应用。 +::: + +### 授予权限 \{#grant-permissions} + +**权限** 标签页定义了所有动态客户端共享的最大权限。其工作方式类似于[注册第三方应用的权限管理](/integrate-logto/third-party-applications/permission-management)，分为 **用户** 和 **组织 (Organization)** 两部分。 + +请求未被授予的用户权限会导致错误，而未被授予的 API 资源和组织权限会被忽略。用户也只会同意他们通过其[角色](/authorization/role-based-access-control)拥有的权限。 + +由于所有动态客户端共享这组权限，请保持其最小化。 + +## 发布 client ID 元数据文档 \{#publish-a-client-id-metadata-document} + +如果你正在构建连接到 Logto 的客户端，请托管一个元数据文档，并将其 URL 用作你的 `client_id`。该 URL 必须使用 `https` 协议，且不能包含片段、用户信息或点路径段。Logto 会向该 URL 发送 `GET` 请求，并期望返回一个 JSON 对象。 + +例如，Claude Code 使用 `https://claude.ai/oauth/claude-code-client-metadata`，其内容如下： + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +字段名称与 [OAuth 2.0 动态客户端注册](https://datatracker.ietf.org/doc/html/rfc7591#section-2) 中相同。注意： + +- `client_id` 必须与提供该文档的 URL 完全一致。 +- 动态客户端属于公开客户端。文档中不得包含 `client_secret`，且 `token_endpoint_auth_method` 不能为共享密钥方式。请改用 [PKCE](https://auth.wiki/pkce)。 +- 元数据 URI，如 `client_uri`、`logo_uri`、`tos_uri` 和 `policy_uri` 必须为绝对的 `https` URL。这一要求不适用于 `redirect_uris`，因此本地客户端仍可使用如上例所示的回环地址。 +- `redirect_uris` 需精确匹配字符串，但回环地址可匹配任意端口。[通配符模式](/integrate-logto/application-data-structure#wildcard-patterns) 也受支持。 +- `scope`、`grant_types` 和 `response_types` 由 Logto 决定。如果文档声明了这些字段，其值会被忽略。动态客户端只能使用授权码流程和刷新令牌。 + +Logto 最多会缓存该文档 24 小时，遵循你的响应中的 `Cache-Control` 和 `Expires` 头。请根据你期望的文档更新频率设置这些头。 + +## 用户授权页面 (Consent screen) \{#consent-screen} + +动态客户端属于第三方应用，因此始终会显示[用户授权页面](/end-user-flows/consent-screen)。 + +用户授权页面还会显示一条提示，说明该客户端未注册。客户端名称和 logo 来自元数据文档，因此它们可以模仿任何品牌。client ID URL 的主机名也会显示，因为这是客户端无法伪造的唯一部分。 + +## 管理授权 (Authorizations) \{#manage-authorizations} + +授予动态客户端的授权 (Authorizations) 属于常规第三方[授权 (grants)](/sessions/grants-management)。用户可以在账户设置中查看和撤销它们，管理员可以通过 Management API 进行管理。客户端通过 client ID URL 进行识别。 + +禁用动态应用会阻止新的授权请求，但现有授权 (grants) 会被保留。撤销授权 (grant) 后，客户端需要重新获得用户授权，但之前签发的访问令牌 (access tokens) 可能会在过期前继续有效。 + +## 限制 \{#limitations} + +- 仅支持带 PKCE 的授权码流程和刷新令牌。不支持客户端凭据、设备流程和令牌交换。 +- 无法为每个客户端单独配置权限和品牌。 +- [应用级访问控制](/authorization/app-level-access-control) 不适用于动态客户端，因为它们没有应用记录。 + +## 相关资源 \{#related-resources} + +第三方应用 (OAuth / OIDC) + + 启用第三方 AI 代理访问你的 MCP 服务器 + diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index 2643f8725a5..d9d51401920 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -2,70 +2,72 @@ sidebar_position: 2 --- -# 管理用户授权的应用程序（授权） +# 管理用户授权应用（授权记录） -应用程序授权表示用户对特定客户端应用程序的授权状态。 +应用授权（grants）代表用户对特定客户端应用的授权状态。 -当用户或管理员需要查看已授权的应用程序并撤销应用程序访问而不撤销整个 Logto 会话时，可以使用授权管理。 +当用户或管理员需要查看已授权的应用并撤销应用访问权限（而不影响整个 Logto 会话）时，可以使用授权管理。 -当授权被撤销时，之前为这些授权颁发的不透明访问令牌和刷新令牌将失效。 +当授权被撤销时，之前颁发的该授权的不透明访问令牌（opaque access tokens）和刷新令牌（refresh tokens）将失效。JWT 访问令牌（access tokens）是无状态的，因此已颁发的令牌会一直有效，直到过期为止。 ## 选择正确的路径 \{#choose-the-right-path} -| 场景 | 推荐路径 | -| -------------------------------------- | -------------- | -| 让已登录用户管理自己的应用程序授权 | Account API | -| 让管理员或支持团队为目标用户管理授权 | Management API | -| 让操作员在 UI 中管理第三方应用程序授权 | Admin Console | +| 场景 | 推荐路径 | +| ------------------------------------ | -------------- | +| 让已登录用户自行管理其应用授权 | Account API | +| 让管理员或支持团队为目标用户管理授权 | Management API | +| 让运维人员在界面中管理第三方应用授权 | 管理控制台 | ## 直接授权管理 API \{#direct-grant-management-apis} ### Account API（自助服务）\{#account-api-self-service} -在终端用户账户设置页面中使用 Account API： +在终端用户账户设置页面使用 Account API： - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` -- 参考：[管理用户授权的应用程序（授权）](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) +- 参考：[通过 Account API 管理用户授权应用（授权记录）](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) ### Management API（管理工具）\{#management-api-admin-tools} -在管理工具和支持工作流中使用 Management API： +在管理工具和支持流程中使用 Management API： - `GET /api/users/{userId}/grants` - `DELETE /api/users/{userId}/grants/{grantId}` -- 参考：[管理用户授权的应用程序（授权）](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) +- 参考：[通过 Management API 管理用户授权应用（授权记录）](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) -### 按应用程序类型筛选授权列表 \{#filter-grant-list-by-app-type} +### 按应用类型筛选授权列表 \{#filter-grant-list-by-app-type} -授权列表端点支持可选查询参数 `appType`： +授权列表接口支持可选查询参数 `appType`： -- `appType=firstParty`：仅列出第一方应用程序授权。 -- `appType=thirdParty`：仅列出第三方应用程序授权。 -- 省略 `appType`：返回所有活动授权。 +- `appType=firstParty`：仅列出第一方应用授权。 +- `appType=thirdParty`：仅列出第三方应用授权。 +- 省略 `appType`：返回所有活跃授权。 -## 在控制台中管理第三方应用程序授权 \{#manage-third-party-app-authorizations-in-console} +[动态应用](/integrate-logto/third-party-applications/dynamic-apps) 客户端属于第三方应用，因此它们的授权会以 `appType=thirdParty` 返回。客户端 ID URL 用作应用 ID。 -在 Logto 控制台中，使用用户详细信息页面查看和撤销已授权的第三方应用程序。 +## 在控制台管理第三方应用授权 \{#manage-third-party-app-authorizations-in-console} -- 参考：[管理用户授权的第三方应用程序](/user-management/manage-users#manage-user-authorized-third-party-apps) +在 Logto 控制台中，可以通过用户详情页查看和撤销已授权的第三方应用。 -## 撤销会话时撤销授权 \{#revoke-grants-when-revoking-a-session} +- 参考：[管理用户授权的第三方应用](/user-management/manage-users#manage-user-authorized-third-party-apps) -通过 `DELETE /api/my-account/sessions/{sessionId}` 撤销会话时，使用可选查询参数 `revokeGrantsTarget` 控制授权撤销范围： +## 撤销会话时同步撤销授权 \{#revoke-grants-when-revoking-a-session} -- `all`：撤销与会话关联的所有应用程序的授权。 -- `firstParty`：仅撤销第一方应用程序的授权。 +通过 `DELETE /api/my-account/sessions/{sessionId}` 撤销会话时，可以使用可选查询参数 `revokeGrantsTarget` 控制授权撤销范围： -有关会话级别行为和端点上下文，请参阅 [管理用户会话](/sessions/manage-user-sessions) 和 [注销](/end-user-flows/sign-out)。 +- `all`：撤销与该会话关联的所有应用授权。 +- `firstParty`：仅撤销第一方应用授权。 + +关于会话级行为和接口上下文，参见 [管理用户会话](/sessions/manage-user-sessions) 和 [登出](/end-user-flows/sign-out)。 ## 相关资源 \{#related-resources} -Sessions +会话 管理用户会话 - 通过 Account API 进行账户设置：管理用户授权的应用程序（授权） + 通过 Account API 账户设置：管理用户授权应用（授权记录） - 通过 Management API 进行账户设置：管理用户授权的应用程序（授权） + 通过 Management API 账户设置：管理用户授权应用（授权记录） diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index bbe6e64af81..83717b4e37e 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -7,12 +7,18 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- :::info[什么是第三方应用？] **第三方应用**是由外部开发者（非资源所有者）创建的应用程序，需要用户同意才能访问受保护资源。与第一方应用（你自己的应用程序）不同，第三方应用会显示用户授权页面 (Consent screen)，在访问用户数据前请求用户批准特定权限。这确保了用户可以控制与外部服务共享哪些数据。 -了解更多，请参阅 [第三方应用程序](/integrate-logto/third-party-applications)。 +了解更多，请参阅 [第三方应用](/integrate-logto/third-party-applications)。 ::: +接入 AI 代理有三种方式： + +- [在控制台手动创建应用](#manually-create-a-third-party-app-in-logto)，适用于测试或少量已知代理。 +- [基于 Management API 构建注册服务](#allow-developers-to-create-third-party-apps-in-logto)，如果你希望控制谁能获取凭证。 +- [启用动态应用](#let-any-ai-agent-connect-without-pre-registration)，如果任何代理都可能接入且你不希望有注册步骤。 + ### 允许开发者在 Logto 中创建第三方应用 \{#allow-developers-to-create-third-party-apps-in-logto} -如果你正在构建一个市场，或希望允许开发者在 Logto 中创建第三方应用，可以利用 [Logto Management API](/integrate-logto/interact-with-management-api) 以编程方式创建第三方应用。这样开发者就可以注册他们的应用，并获取认证 (Authentication) 所需的凭证。 +如果你正在构建一个市场或希望允许开发者在 Logto 中创建第三方应用，可以利用 [Logto Management API](/integrate-logto/interact-with-management-api) 以编程方式创建第三方应用。这样开发者可以注册他们的应用并获取认证 (Authentication) 所需的凭证。 你需要托管自己的服务来处理客户端注册流程。该服务将与 Logto Management API 交互，代表开发者创建第三方应用。 @@ -29,20 +35,37 @@ sequenceDiagram 另外，你也可以在 Logto 控制台手动创建第三方应用，以熟悉整个流程。 +### 允许任何 AI 代理无需预注册即可接入 \{#let-any-ai-agent-connect-without-pre-registration} + +在开放的 MCP 生态系统中，你通常无法提前知道所有代理。[动态应用](/integrate-logto/third-party-applications/dynamic-apps) 移除了注册步骤：代理使用一个公开的 HTTPS URL（提供其自身客户端元数据文档）作为其 `client_id`，Logto 在收到授权 (Authorization) 请求时解析它。 + +```mermaid +sequenceDiagram + participant Agent as AI 代理（MCP 客户端） + participant Logto + participant Metadata as 代理的元数据文档 URL + Agent->>Logto: 携带 client ID URL 的授权 (Authorization) 请求 + Logto->>Metadata: 获取 client ID 元数据文档 + Metadata->>Logto: 客户端名称、logo、重定向 URI 等 + Logto->>Agent: 用户授权页面 (Consent screen)，然后返回授权码 +``` + +你仍然可以通过授予动态应用的权限来控制代理可请求的内容，并且每次授权 (Authorization) 都会经过用户授权页面 (Consent screen)。 + ### 在 Logto 中手动创建第三方应用 \{#manually-create-a-third-party-app-in-logto} -你可以在 Logto 控制台手动创建第三方应用，用于测试或临时集成。当你想快速测试集成而无需实现完整的客户端注册流程时，这非常有用。 +你可以在 Logto 控制台手动创建第三方应用，用于测试或临时集成。当你想快速测试集成而无需实现完整的客户端注册流程时，这种方式非常有用。 -1. 登录到你的 Logto 控制台。 -2. 进入 **应用程序** → **创建应用程序** → **第三方应用** -> **OIDC**。 -3. 填写应用名称及其他必填项，然后点击 **创建应用程序**。 +1. 登录你的 Logto 控制台。 +2. 进入 **应用程序** → **创建应用** → **第三方应用** -> **OIDC**。 +3. 填写应用名称及其他必填项，然后点击 **创建应用**。 4. 点击 **权限** 标签页，在 **用户** 部分点击“添加”。 5. 在弹出的对话框中 -> **用户数据** -> 选择 **`profile`**、**`email`** 权限，然后点击 **保存**。 6. 在第三方应用中，配置 scopes 以请求 `openid profile email` 权限（scopes）。 **注意**：`openid` 是 OIDC 必需的，`profile` 和 `email` 是你在上一步添加的权限。 -7. 相应地配置你的第三方应用的 **重定向 URI**。记得在 Logto 中也更新重定向 URI。 +7. 按需配置你的第三方应用的 **重定向 URI**。记得在 Logto 中同步更新重定向 URI。 'production' | 'test' | undefined | Logto 執行的環境類型。 | -| PORT | `3001` | `number` | Logto 監聽的本地埠號。 | -| ADMIN_PORT | `3002` | `number` | Logto 管理主控台監聽的本地埠號。 | -| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | 設為 `1` 或 `true` 可停用管理主控台的埠號。若未設定 `ADMIN_ENDPOINT`，將完全停用管理主控台。 | -| DB_URL | N/A | `string` | Logto 資料庫的 [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6)。 | -| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | （v1.36.0+）PostgreSQL `statement_timeout`，單位為毫秒。請使用數字字串（如 `5000`）設定，或設為 `DISABLE_TIMEOUT` 以略過啟動參數（建議用於 PgBouncer / RDS Proxy）。若未設定或無效，預設為 60000 ms。 | -| HTTPS_CERT_PATH | `undefined` | string | undefined | 詳情請見 [啟用 HTTPS](#enabling-https)。 | -| HTTPS_KEY_PATH | `undefined` | string | undefined | 同上。 | -| TRUST_PROXY_HEADER | `false` | `boolean` | 同上。 | -| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | 你可以指定自訂網域的 URL 以供線上測試或正式環境使用。這也會影響 [OIDC 簽發者識別碼 (Issuer Identifier)](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) 的值。 | -| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | 你可以為正式環境指定自訂網域的 URL（例如：`ADMIN_ENDPOINT=https://admin.domain.com`）。這也會影響管理主控台重新導向 URI 的值。 | -| CASE_SENSITIVE_USERNAME | `true` | `boolean` | 指定使用者名稱是否區分大小寫。修改此值時請小心，變更不會自動調整現有資料庫資料，需手動管理。 | -| SECRET_VAULT_KEK | `undefined` | `string` | 用於加密 [Secret Vault](/secret-vault) 中資料加密金鑰（DEK）的金鑰加密金鑰（KEK）。Secret Vault 正常運作必須設定。必須為 base64 編碼字串。建議使用 AES-256（32 bytes）。範例：`crypto.randomBytes(32).toString('base64')` | -| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | OIDC 私鑰輪替的緩衝期（秒）。設為正值時，新私鑰會先以 `Next` 狀態建立，並於緩衝期後才生效。 | -| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | 僅限自架設。僅當信任的 OIDC 依賴方端點必須解析為私有網路位址時設為 `true`。詳見 [OIDC provider SSRF 保護](#oidc-provider-ssrf-protection)。 | - -### OIDC provider SSRF 保護 {#oidc-provider-ssrf-protection} - -Logto 預設會保護 OIDC provider 的對外請求，防止伺服器端請求偽造（SSRF, Server-Side Request Forgery）。對特殊用途位址（如 loopback 與私有網路位址）的請求將被阻擋。此保護涵蓋依賴方端點，例如 back-channel logout URI、`jwks_uri` 與 `sector_identifier_uri`。 - -若你的自架設部署確實需要存取私有網路上的信任依賴方端點，請將 `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true`，並重啟所有 Logto 執行個體。 +| Key | Default Value | Type | Description | +| -------------------------------------- | ------------------------------------ | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| NODE_ENV | `undefined` | 'production' | 'test' | undefined | Logto 執行時所處的環境類型。 | +| PORT | `3001` | `number` | Logto 監聽的本地埠號。 | +| ADMIN_PORT | `3002` | `number` | Logto 管理主控台監聽的本地埠號。 | +| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | 設為 `1` 或 `true` 可停用管理主控台的埠號。若未設定 `ADMIN_ENDPOINT`，將完全停用管理主控台。 | +| DB_URL | N/A | `string` | Logto 資料庫的 [Postgres DSN](https://www.postgresql.org/docs/14/libpq-connect.html#id-1.7.3.8.3.6)。 | +| DATABASE_STATEMENT_TIMEOUT | N/A | `string` | （v1.36.0+）PostgreSQL `statement_timeout`，單位為毫秒。請使用數字字串（如 `5000`）設定，或設為 `DISABLE_TIMEOUT` 以略過啟動參數（建議用於 PgBouncer / RDS Proxy）。若未設定或無效，預設為 60000 ms。 | +| HTTPS_CERT_PATH | `undefined` | string | undefined | 詳情請參閱 [啟用 HTTPS](#enabling-https)。 | +| HTTPS_KEY_PATH | `undefined` | string | undefined | 同上。 | +| TRUST_PROXY_HEADER | `false` | `boolean` | 同上。 | +| ENDPOINT | `'protocol://localhost:$PORT'` | `string` | 你可以指定自訂網域的 URL 以供線上測試或正式環境使用。這也會影響 [OIDC 簽發者識別碼 (Issuer Identifier)](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) 的值。 | +| ADMIN_ENDPOINT | `'protocol://localhost:$ADMIN_PORT'` | `string` | 你可以為正式環境指定自訂網域的 URL（例如：`ADMIN_ENDPOINT=https://admin.domain.com`）。這也會影響管理主控台重新導向 URI 的值。 | +| CASE_SENSITIVE_USERNAME | `true` | `boolean` | 指定使用者名稱是否區分大小寫。修改此值時請謹慎，變更不會自動調整現有資料庫資料，需手動管理。 | +| SECRET_VAULT_KEK | `undefined` | `string` | 用於加密 [Secret Vault](/secret-vault) 中資料加密金鑰（DEK, Data Encryption Key）的金鑰加密金鑰（KEK, Key Encryption Key）。Secret Vault 正常運作必須設定此值。必須為 base64 編碼字串。建議使用 AES-256（32 bytes）。範例：`crypto.randomBytes(32).toString('base64')` | +| PRIVATE_KEY_ROTATION_GRACE_PERIOD | `0` | `number` | OIDC 私鑰輪替的緩衝期（秒）。設為正值時，新私鑰會先以 `Next` 狀態建立，並於緩衝期後才生效。 | +| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | `false` | `boolean` | 僅限自架設。僅當需要讓受信任的 OIDC 依賴方端點解析到私有網路位址時設為 `true`。詳見 [OIDC 提供者 SSRF 保護](#oidc-provider-ssrf-protection)。 | + +### OIDC 提供者 SSRF 保護 {#oidc-provider-ssrf-protection} + +Logto 預設保護 OIDC 提供者的對外請求，防止伺服器端請求偽造（SSRF, Server-Side Request Forgery）。對特殊用途位址（如 loopback 與私有網路位址）的請求將被阻擋。此保護涵蓋依賴方端點，例如 back-channel logout URI、`jwks_uri`、`sector_identifier_uri`，以及為 [動態應用程式](/integrate-logto/third-party-applications/dynamic-apps) 取得的 client ID metadata 文件。 + +若你的自架設部署確實需要存取私有網路上的受信任依賴方端點，請將 `OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true`，並重啟所有 Logto 執行個體。 :::caution -此設定會停用所有 OIDC provider 對外請求的 SSRF 保護，而不僅僅是單一端點。僅在所有設定的依賴方端點皆可信，且你的網路控管能防止存取敏感內部服務時才停用。 +此設定會停用所有 OIDC 提供者對外請求的 SSRF 保護，而非僅針對單一端點。僅在所有設定的依賴方端點皆可信，且你的網路控管能防止存取敏感內部服務時才應停用。 + +[動態應用程式](/integrate-logto/third-party-applications/dynamic-apps) 在此保護關閉時無法啟用，因其會從客戶端自行提供的 URL 取得 metadata 文件。 ::: @@ -53,9 +55,9 @@ Logto 預設會保護 OIDC provider 的對外請求，防止伺服器端請求 #### 使用 Node {#using-node} -Node 原生支援 HTTPS。請同時提供 `HTTPS_CERT_PATH` 與 `HTTPS_KEY_PATH`，即可透過 Node 啟用 HTTPS。 +Node 原生支援 HTTPS。提供 **BOTH（兩者）** `HTTPS_CERT_PATH` 與 `HTTPS_KEY_PATH` 即可透過 Node 啟用 HTTPS。 -`HTTPS_CERT_PATH` 指向你的 HTTPS 憑證路徑，`HTTPS_KEY_PATH` 則指向你的 HTTPS 金鑰路徑。 +`HTTPS_CERT_PATH` 指向你的 HTTPS 憑證路徑，`HTTPS_KEY_PATH` 指向你的 HTTPS 金鑰路徑。 #### 使用 HTTPS 代理 {#using-a-https-proxy} @@ -67,9 +69,9 @@ Node 原生支援 HTTPS。請同時提供 `HTTPS_CERT_PATH` 與 `HTTPS_KEY_PATH` ## 資料庫設定 {#database-configs} -管理過多環境變數既沒效率又不靈活，因此大多數一般設定都儲存在資料表 `logto_configs` 中。 +管理過多環境變數既沒效率又不靈活，因此我們將大多數一般設定存放於資料庫表格 `logto_configs`。 -該表為簡單的鍵值儲存，key 可列舉如下： +該表格為簡單的鍵值儲存，key 可列舉如下： | Key | Type | Description | | ---------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------- | @@ -78,6 +80,6 @@ Node 原生支援 HTTPS。請同時提供 `HTTPS_CERT_PATH` 與 `HTTPS_KEY_PATH` ### 支援的私鑰類型 {#supported-private-key-types} -- EC（P-256、secp256k1、P-384 與 P-521 曲線） +- EC（P-256、secp256k1、P-384、P-521 曲線） - RSA - OKP（Ed25519、Ed448、X25519、X448 子類型） diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx index 0ba39a61776..7db98bea027 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/end-user-flows/consent-screen.mdx @@ -6,34 +6,38 @@ sidebar_position: 6 ## 什麼是使用者授權頁面？ \{#what-is-consent-screen} -想像你正在使用 Google 帳號註冊 Logto。當你點擊「使用 Google 登入」按鈕時，會被導向 Google 的登入頁面。輸入 Google 憑證後，系統會要求你授權 Logto 存取你的 Google 帳號資訊。這就是所謂的使用者授權頁面。 +想像你正在使用 Google 帳號註冊 Logto。當你點擊「使用 Google 登入」按鈕時，會被導向 Google 的登入頁面。輸入 Google 憑證後，系統會提示你授權 Logto 存取你的 Google 帳號資訊。這就是所謂的使用者授權頁面（consent screen）。 -這個頁面我們稱為使用者 **授權頁面 (consent screen)** 或 **授權同意頁 (consent page)**。它是標準的 [OIDC / OAuth 2.0 流程](/integrate-logto/third-party-applications)，允許使用者授權 [第三方應用程式](/integrate-logto/third-party-applications) 代表他們存取資料。其主要目的是告知使用者其個人資料的蒐集、處理與使用方式，並徵求使用者對這些行為的明確同意。 +這個頁面就是我們所說的使用者 **授權頁面 (consent screen)** 或 **授權頁 (consent page)**。它是標準的 [OIDC / OAuth 2.0 流程](/integrate-logto/third-party-applications)，讓使用者能授權 [第三方應用程式 (third-party applications)](/integrate-logto/third-party-applications) 代表他們存取資料。其主要目的是告知使用者其個人資料的收集、處理與使用方式，並徵求他們對這些行為的明確同意。 -在授權頁面上，通常會向使用者展示[相關資訊](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information)，例如將蒐集哪些資料、如何使用，以及是否會與第三方分享。這些資訊對於資訊透明至關重要，讓使用者能夠做出明智的隱私與資料安全決策。 +在授權頁面上，通常會向使用者展示 [資訊](/integrate-logto/third-party-applications/consent-screen-branding#customize-the-branding-information)，說明將收集哪些資料、如何使用，以及是否會與第三方分享。這些資訊對於透明度至關重要，讓使用者能對自己的隱私與資料安全做出明智決定。 -授權頁面在隱私法規（如歐盟的通用資料保護規範 [GDPR](https://gdpr-info.eu/art-4-gdpr/) 或美國加州消費者隱私法 [CCPA](https://oag.ca.gov/privacy/ccpa)）的背景下尤其重要，這些法規要求組織在處理個人資訊前，必須取得使用者明確且積極的同意。 +授權頁面在隱私法規（如歐盟的通用資料保護規則 [GDPR](https://gdpr-info.eu/art-4-gdpr/) 或美國加州消費者隱私法 [CCPA](https://oag.ca.gov/privacy/ccpa)）下尤其重要，這些法規要求組織在處理使用者個人資訊前，必須取得明確且積極的同意。 ## 使用者在 Logto 什麼時候會看到授權頁面？ \{#when-does-user-see-the-consent-screen-in-logto} -如前所述，當使用者透過 Google、Facebook 或 Apple 等第三方身分提供者 (IdP, Identity provider) 登入 Logto 時，會出現授權頁面。在這種情境下，Logto 作為服務提供者 (SP, Service provider)，向 IdP 請求存取使用者資訊。當 [SP](https://auth.wiki/service-provider) 與 [IdP](https://auth.wiki/identity-provider) 屬於不同組織時，通常會顯示授權頁面，要求使用者授權以促進資料分享。 +如前所述，當使用者透過 Google、Facebook 或 Apple 等第三方身分提供者 (IdP, Identity provider) 登入 Logto 時，會出現授權頁面。在這種情境下，Logto 作為服務提供者 (SP, Service provider)，向 IdP 請求存取使用者資訊。當 [SP](https://auth.wiki/service-provider) 與 [IdP](https://auth.wiki/identity-provider) 屬於不同組織時，通常會顯示授權頁面，要求使用者授權以促進資料共享。 Consent screen Logto as SP -同樣地，在 Logto 作為 IdP 時，當使用者登入與 Logto 整合的 [**OIDC / OAuth 第三方應用程式**](/integrate-logto/third-party-applications) 時，也會顯示授權頁面。此頁面會告知使用者應用程式請求哪些資料，並徵求其授權。使用者可以檢視所請求的權限，並決定是否授權該應用程式。 +同樣地，在 Logto 作為 IdP 時，當使用者登入與 Logto 整合的 [**OIDC / OAuth 第三方應用程式**](/integrate-logto/third-party-applications) 時，也會顯示授權頁面。此頁面會告知使用者應用程式請求哪些資料，並徵求他們的同意。使用者可以檢視所請求的權限，並決定是否授權該應用程式。 Consent screen Logto as IdP +### 未註冊（動態）用戶端 \{#unregistered-dynamic-clients} + +若啟用 [動態應用程式 (dynamic app)](/integrate-logto/third-party-applications/dynamic-apps)，用戶端可在未預先註冊的情況下連接你的租戶。對於這類用戶端，授權頁面會額外顯示一則提示，以及 client ID URL 的主機名稱。用戶端名稱與標誌來自用戶端自己的 metadata 文件，因此他們可以模仿任何品牌，但主機名稱無法偽造。 + ## 如何設定授權頁面？ \{#how-to-configure-the-consent-screen} -Logto 的授權流程允許你授權第三方應用程式的登入。你可以針對每個 OIDC 第三方應用程式自訂品牌與權限請求內容。 +Logto 的授權流程允許你授權第三方應用程式的登入。你可以針對每個 OIDC 第三方應用程式自訂品牌與權限請求。 -進一步瞭解如何設定 [第三方應用程式](/integrate-logto/third-party-applications/) 以及在 Logto 中配置 [授權頁面](/integrate-logto/third-party-applications/consent-screen-branding/)。 +進一步瞭解如何設定 [第三方應用程式](/integrate-logto/third-party-applications/) 及在 Logto 中設定 [授權頁面](/integrate-logto/third-party-applications/consent-screen-branding/)。 ## 相關資源 \{#related-resources} - 讓你的服務成為具備授權頁面的安全 OIDC 身分提供者 (IdP)。 + 將你的服務升級為具備授權頁面的安全 OIDC 身分提供者 (IdP)。 使用者授權頁面簡介。 diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx index 4747d2b7f0c..127a3d734df 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/application-data-structure.mdx @@ -7,26 +7,30 @@ sidebar_position: 7 ## 簡介 \{#introduction} -在 Logto 中，_應用程式_ 指的是已註冊於 Logto 平台，並獲授權可存取使用者資訊或代表使用者執行操作的特定軟體程式或服務。應用程式用於識別向 Logto API 發出的請求來源，並管理使用者存取這些應用程式時的驗證 (Authentication) 與授權 (Authorization) 流程。 +在 Logto 中，_應用程式_ 指的是註冊於 Logto 平台、並獲授權可存取使用者資訊或代表使用者執行操作的特定軟體程式或服務。應用程式用於識別向 Logto API 發出的請求來源，同時管理使用者存取這些應用程式時的驗證 (Authentication) 與授權 (Authorization) 流程。 -在 Logto 的登入體驗 (Sign-in experience) 中使用應用程式，讓使用者能從單一位置輕鬆存取與管理其已授權的應用程式，並享有一致且安全的驗證流程。這有助於簡化使用者體驗，並確保只有獲授權的人員能存取敏感資訊或代表組織執行操作。 +在 Logto 的登入體驗 (Sign-in experience) 中使用應用程式，讓使用者能從單一位置輕鬆存取並管理其已授權的應用程式，並享有一致且安全的驗證流程。這有助於簡化使用者體驗，並確保只有經授權的人員能存取敏感資訊或代表組織執行操作。 -應用程式也用於 Logto 的稽核日誌 (Audit logs) 中，以追蹤使用者活動並識別潛在的安全威脅或漏洞。透過將特定操作與特定應用程式關聯，Logto 能提供資料存取與使用的詳細洞察，協助組織更好地管理安全與合規需求。 -如果你想將應用程式與 Logto 整合，請參閱 [整合 Logto](/integrate-logto)。 +應用程式也會用於 Logto 的稽核日誌 (Audit logs) 中，以追蹤使用者活動並識別潛在的安全威脅或漏洞。透過將特定操作與特定應用程式關聯，Logto 能提供資料存取與使用的詳細洞察，協助組織更好地管理安全性與合規需求。 +如果你想將應用程式整合至 Logto，請參閱 [整合 Logto](/integrate-logto)。 ## 屬性 \{#properties} ### 應用程式 ID \{#application-id} -_應用程式 ID_ 是用於在 Logto 中唯一識別你應用程式的自動產生金鑰，在 OAuth 2.0 中稱為 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)。 +_應用程式 ID_ 是用於識別你在 Logto 中應用程式的唯一自動產生金鑰，在 OAuth 2.0 中稱為 [client id](https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/)。 + +:::note +[動態應用程式](/integrate-logto/third-party-applications/dynamic-apps)客戶端不會註冊於 Logto。它們的 client ID 是由客戶端擁有的公開 HTTPS URL，該 URL 提供 client metadata 文件。 +::: ### 應用程式類型 \{#application-types} _應用程式_ 可為下列其中一種類型： - **原生應用程式 (Native app)**：運行於原生環境的應用程式。例如 iOS app、Android app。 - - **裝置流程應用程式 (Device flow app)**：專為輸入受限裝置或無頭應用（如智慧電視、遊戲主機、CLI 工具、IoT 裝置）設計的特殊原生應用程式。它使用 [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) 取代標準的重導流程。詳情請參閱 [Device flow 快速入門](/quick-starts/device-flow)。 -- **單頁應用程式 (Single page app)**：運行於網頁瀏覽器，並能在不重新載入整個頁面的情況下從伺服器取得新資料並更新頁面的應用程式。例如 React DOM app、Vue app。 + - **裝置流程應用程式 (Device flow app)**：一種特殊的原生應用程式，適用於輸入受限裝置或無頭應用（如智慧電視、遊戲主機、CLI 工具、IoT 裝置）。它使用 [OAuth 2.0 Device Authorization Grant](https://auth.wiki/device-flow) 取代標準的重導導向流程。詳情請參閱 [Device flow 快速入門](/quick-starts/device-flow)。 +- **單頁應用程式 (Single page app)**：運行於網頁瀏覽器中，能在不重新載入整個頁面的情況下從伺服器取得新資料並更新頁面。例如 React DOM app、Vue app。 - **傳統網頁應用程式 (Traditional web app)**：僅由網頁伺服器渲染與更新頁面的應用程式。例如 JSP、PHP。 - **機器對機器 (M2M) 應用程式**：運行於機器環境、用於直接服務對服務通訊且無需使用者互動的應用程式。 @@ -45,7 +49,7 @@ _應用程式名稱_ 是應用程式的人類可讀名稱，會顯示於管理 _應用程式名稱_ 是 Logto 應用程式管理的重要組成部分，讓管理員能輕鬆識別並追蹤平台內各應用程式的活動。 :::note -請注意，_應用程式名稱_ 應謹慎選擇，因為所有有權存取管理主控台的使用者都能看到。名稱應準確反映應用程式的用途與功能，並易於理解與辨識。 +請注意，_應用程式名稱_ 應謹慎命名，因為所有有權存取管理主控台的使用者都能看到。名稱應準確反映應用程式的用途與功能，並易於理解與辨識。 ::: ### 描述 \{#description} @@ -54,12 +58,12 @@ _應用程式名稱_ 是 Logto 應用程式管理的重要組成部分，讓管 ### 重導 URI \{#redirect-uris} -_重導 URI_ 是已預先設定於應用程式的有效重導 URI 清單。當使用者登入 Logto 並嘗試存取應用程式時，會被重導至應用程式設定中允許的 URI 之一。 +_重導 URI_ 是預先為應用程式設定的一組有效重導 URI。當使用者登入 Logto 並嘗試存取應用程式時，會被重導至應用程式設定中允許的 URI 之一。 -允許的 URI 清單用於驗證應用程式於驗證 (Authentication) 流程中發送給 Logto 的授權請求所包含的重導 URI。若授權請求中的重導 URI 與應用程式設定中的允許 URI 相符，則使用者驗證成功後會被重導至該 URI。若重導 URI 不在允許清單中，則不會重導且驗證流程會失敗。 +允許的 URI 清單用於驗證應用程式在驗證 (Authentication) 流程中發送給 Logto 的授權請求所包含的重導 URI。若授權請求中的重導 URI 與應用程式設定中的允許 URI 之一相符，則使用者驗證成功後會被重導至該 URI。若重導 URI 不在允許清單中，則不會重導且驗證流程會失敗。 :::note -請確保所有有效的重導 URI 都已加入 Logto 應用程式的允許清單，以確保使用者驗證後能順利存取應用程式。 +請務必將所有有效的重導 URI 加入 Logto 應用程式的允許清單，以確保使用者驗證後能順利存取應用程式。 ::: 你可以參考 [Redirection endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2) 以獲得更多資訊。 @@ -84,19 +88,19 @@ _適用於：單頁應用程式、傳統網頁應用程式_ - `https://*.example.com/callback` - 匹配任何子網域 - `https://preview-*.example.com/callback` - 匹配預覽部署 -- `https://example.com/*/callback` - 匹配任意路徑片段 +- `https://example.com/*/callback` - 匹配任一路徑片段 :::caution -萬用字元重導 URI 並非標準 OIDC，且可能增加攻擊面。請謹慎使用，並盡可能偏好精確的重導 URI。 +萬用字元重導 URI 並非標準 OIDC，且可能增加攻擊面。請謹慎使用，並盡可能優先使用精確的重導 URI。 ::: ### 登出後重導 URI \{#post-sign-out-redirect-uris} -_登出後重導 URI_ 是已預先設定於應用程式的有效 URI 清單，用於使用者自 Logto 登出後的重導。 +_登出後重導 URI_ 是預先為應用程式設定的一組有效 URI，供使用者自 Logto 登出後重導。 -允許的 _登出後重導 URI_ 用於 OIDC 的 RP-Initiated（Relying Party Initiated）Logout 規範。此規範為應用程式提供標準化的使用者登出請求方法，包含在使用者登出後重導至預先設定的端點。 +允許的 _登出後重導 URI_ 用於 Logout，屬於 OIDC RP-Initiated（Relying Party Initiated）Logout 規範的一部分。該規範為應用程式發起使用者登出請求提供標準化方法，包含在登出後將使用者重導至預先設定的端點。 -當使用者自 Logto 登出時，其工作階段會終止，並被重導至應用程式設定中允許的 URI 之一。這確保使用者僅被導向授權且有效的端點，避免將使用者重導至未知或未驗證端點所帶來的未授權存取與安全風險。 +當使用者自 Logto 登出時，其工作階段（Session）會被終止，並被重導至應用程式設定中允許的 URI 之一。這確保使用者僅被導向授權且有效的端點，避免將使用者重導至未知或未驗證端點所帶來的未授權存取與安全風險。 你可以參考 [RP-initiated logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout) 以獲得更多資訊。 @@ -104,10 +108,10 @@ _登出後重導 URI_ 是已預先設定於應用程式的有效 URI 清單， _CORS（跨來源資源共用）允許來源_ 是允許應用程式向 Logto 服務發送請求的來源清單。不在允許清單中的來源將無法向 Logto 服務發送請求。 -CORS 允許來源清單用於限制未授權網域存取 Logto 服務，並協助防止跨站請求偽造（CSRF）攻擊。透過在 Logto 指定應用程式的允許來源，服務可確保僅授權網域能發送請求。 +CORS 允許來源清單用於限制未授權網域存取 Logto 服務，並協助防範跨站請求偽造（CSRF）攻擊。透過在 Logto 中為應用程式指定允許來源，服務可確保僅授權網域能發送請求。 :::note -允許來源清單應包含應用程式實際服務的來源。這可確保應用程式的請求被允許，而未授權來源的請求會被阻擋。 +允許來源清單應包含應用程式實際服務的來源。這可確保來自應用程式的請求被允許，而未授權來源的請求會被阻擋。 ::: ### OpenID 提供者設定端點 \{#openid-provider-configuration-endpoint} @@ -116,7 +120,7 @@ CORS 允許來源清單用於限制未授權網域存取 Logto 服務，並協 ### 授權端點 \{#authorization-endpoint} -_授權端點 (Authorization Endpoint)_ 是 OIDC 術語，是用於啟動使用者驗證流程的必要端點。當使用者嘗試存取已註冊於 Logto 平台的受保護資源或應用程式時，會被重導至 _授權端點_ 以驗證身分並取得存取所請求資源的授權。 +_授權端點 (Authorization Endpoint)_ 是 OIDC 術語，是用於啟動使用者驗證 (Authentication) 流程的必要端點。當使用者嘗試存取已註冊於 Logto 平台的受保護資源或應用程式時，會被重導至 _授權端點_ 以驗證身分並獲得存取所請求資源的授權 (Authorization)。 你可以參考 [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) 以獲得更多資訊。 @@ -124,7 +128,7 @@ _授權端點 (Authorization Endpoint)_ 是 OIDC 術語，是用於啟動使用 _權杖端點 (Token Endpoint)_ 是 OIDC 術語，是 OIDC 客戶端用來向 OIDC 提供者取得存取權杖 (Access token)、ID 權杖 (ID token) 或重新整理權杖 (Refresh token) 的 Web API 端點。 -當 OIDC 客戶端需要取得存取權杖或 ID 權杖時，會攜帶授權憑證（通常為授權碼或重新整理權杖）向權杖端點發送請求。權杖端點驗證授權憑證後，若有效則發放存取權杖或 ID 權杖給客戶端。 +當 OIDC 客戶端需要取得存取權杖或 ID 權杖時，會帶著授權憑證（通常是授權碼或重新整理權杖）向權杖端點發送請求。權杖端點驗證授權憑證後，若有效則發放存取權杖或 ID 權杖給客戶端。 你可以參考 [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) 以獲得更多資訊。 @@ -132,78 +136,76 @@ _權杖端點 (Token Endpoint)_ 是 OIDC 術語，是 OIDC 客戶端用來向 OI OpenID Connect [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)。 -### 總是發放重新整理權杖 (Refresh token) \{#always-issue-refresh-token} +### 永遠發放重新整理權杖 (Always issue refresh token) \{#always-issue-refresh-token} _適用於：傳統網頁、SPA_ -啟用後，Logto 會總是發放重新整理權杖 (Refresh token)，無論驗證請求中是否帶有 `prompt=consent` 或權限範圍 (Scope) 中是否帶有 `offline_access`。 +啟用後，Logto 會永遠發放重新整理權杖 (Refresh token)，無論驗證請求中是否帶有 `prompt=consent` 或權限範圍 (Scope) 中是否帶有 `offline_access`。 但除非必要（通常僅用於某些需要重新整理權杖的第三方 OAuth 整合），否則不建議這麼做，因為這不符合 OpenID Connect 標準，且可能導致問題。 -### 重新整理權杖 (Refresh token) 輪替 \{#rotate-refresh-token} +### 重新整理權杖輪替 (Rotate refresh token) \{#rotate-refresh-token} _預設值：`true`_ 啟用後，當客戶端使用重新整理權杖請求新權杖時，Logto 可能會發放新的重新整理權杖。若重新整理權杖及其 app grant 仍有效，預設輪替政策如下： - 僅在重新整理權杖鏈存在未滿一年時可輪替。這是內部輪替安全上限；重新整理權杖本身的 TTL 或 app grant TTL 可能更早到期。達到上限後，Logto 不再輪替重新整理權杖，現有權杖的到期日即為最終期限。 -- 對於未使用 sender-constrained 重新整理權杖的公開客戶端（如一般原生應用程式與單頁應用程式），Logto 在每次重新整理權杖請求時都會輪替權杖（只要允許輪替）。 +- 對於未使用 sender-constrained 重新整理權杖的公開客戶端（如一般原生應用程式與單頁應用程式），Logto 只要允許輪替，就會在每次重新整理權杖請求時輪替。 - 其他客戶端則僅在權杖接近到期時（原始 TTL 已過 70% 以上）才輪替。 :::note -對於公開客戶端，強烈建議為安全考量保持重新整理權杖輪替功能啟用。 +對於公開客戶端，強烈建議為安全考量保持重新整理權杖輪替啟用。 -Sender-constrained 重新整理權杖會綁定至客戶端持有的 proof key 或憑證。對於一般 SPA，輪替會發放新權杖但不會延長權杖壽命，新權杖會繼承前一個權杖剩餘的 TTL。 +Sender-constrained 重新整理權杖會綁定至客戶端持有的 proof key 或憑證。對於一般 SPA，輪替會發放新權杖但不會延長權杖存活期。新權杖會繼承前一個權杖剩餘的 TTL。 ::: -:::caution 重新整理權杖鏈存活時間 -重新整理權杖與 app grant 綁定。Logto 預設 grant TTL 為 **180 天**。grant 到期後，重新整理權杖請求會失敗，即使輪替功能啟用也無法再取得新權杖。 +:::caution 重新整理權杖鏈存活期 +重新整理權杖會與 app grant 綁定。Logto 預設 grant TTL 為 **180 天**。grant 到期後，重新整理權杖請求會失敗，即使輪替功能仍啟用，該權杖也無法再取得新權杖。 -這表示實際上以重新整理權杖支撐的授權最大存活時間受限於 grant TTL、明確撤銷或重新整理權杖本身的到期日，以最早發生者為準。 +這表示以重新整理權杖支援的授權 (Authorization) 實際最長存活期受限於 grant TTL、明確撤銷或重新整理權杖本身的到期日，以先到者為準。 ::: - - 了解重新整理權杖 (Refresh token) 輪替 - +了解重新整理權杖輪替 -### 重新整理權杖 (Refresh token) 存活時間（TTL，天）\{#refresh-token-time-to-live-ttl-in-days} +### 重新整理權杖存活期（TTL，天）\{#refresh-token-time-to-live-ttl-in-days} _適用於：原生應用程式、傳統網頁、SPA；預設：14 天；最大：180 天_ -重新整理權杖可用於請求新存取權杖的有效期間，超過後即失效。每次權杖請求會將重新整理權杖的 TTL 延長至此值。 +重新整理權杖可用於請求新存取權杖的存活天數，超過後即失效。每次權杖請求會將重新整理權杖的 TTL 延長至此值。 -通常建議設為較低值。 +通常建議設較低的值。 :::note -出於安全考量，單頁應用程式（SPA）不支援 TTL 延長。對 SPA 而言，此設定僅控制從發放時起的固定權杖壽命。Logto 不會透過權杖請求延長 TTL，輪替也無法防止 SPA 權杖過期。 +出於安全考量，單頁應用程式（SPA）不支援 TTL 延長。對 SPA 而言，此設定僅控制從最初發放時起的固定權杖存活期。Logto 不會透過權杖請求延長 TTL，輪替也無法防止 SPA 的重新整理權杖過期。 ::: :::caution 重新整理權杖 TTL 與 grant TTL -重新整理權杖 TTL 並非唯一的到期限制。重新整理權杖與 app grant 綁定，Logto 預設 grant TTL 為 **180 天**。grant 到期後，即使重新整理權杖本身仍有效，請求也會失敗。 +重新整理權杖 TTL 並非唯一的到期限制。重新整理權杖會綁定至 app grant，Logto 預設 grant TTL 為 **180 天**。grant 到期後，即使重新整理權杖本身仍有效，請求也會失敗。 -對於會延長權杖 TTL 的客戶端，grant TTL 是權杖鏈的絕對最大存活時間。對 SPA 而言，權杖的固定 TTL 可能會早於 grant 到期。 +對於會延長重新整理權杖 TTL 的客戶端，grant TTL 是權杖鏈的絕對最長存活期。對 SPA 而言，重新整理權杖的固定 TTL 可能早於 grant 到期前失效。 ::: -:::caution 重新整理權杖與工作階段綁定 -若在授權請求中**未**帶有 `offline_access` 權限範圍 (Scope)，則發放的重新整理權杖會綁定至使用者工作階段。該工作階段的 TTL 固定為 **14 天**。工作階段到期後，無論權杖本身 TTL 設定為何，權杖都會失效。 +:::caution 重新整理權杖與 Session 綁定 +若在授權請求中**未帶上** `offline_access` 權限範圍 (Scope)，則發放的重新整理權杖會綁定至使用者 Session。Session 固定 TTL 為 **14 天**。Session 到期後，無論權杖本身 TTL 設定為何，重新整理權杖都會失效。 -若要確保重新整理權杖 TTL 設定能完全生效，請務必在授權請求中包含 `offline_access` 權限範圍 (Scope)。 +若要讓重新整理權杖 TTL 設定完全生效，請確保在授權請求中包含 `offline_access` 權限範圍 (Scope)。 ::: ### 後台登出 URI \{#backchannel-logout-uri} -OpenID Connect 的後台登出端點。詳情請參閱 [聯邦登出：後台登出](#)。 +OpenID Connect 後台登出端點。詳情請參閱 [聯邦登出：後台登出](#)。 -### 最大允許授權數 (`maxAllowedGrants`) \{#max-allowed-grants-maxallowedgrants} +### 最大允許 grant 數（`maxAllowedGrants`）\{#max-allowed-grants-maxallowedgrants} -`maxAllowedGrants` 是 `customClientMetadata` 下的可選應用程式層級欄位，用於控制當前應用程式每位使用者可同時存在的最大有效授權數。 +`maxAllowedGrants` 是 `customClientMetadata` 下的可選應用程式層級欄位，用於控制單一使用者於當前應用程式的最大同時有效 grant 數量。 - **預設值**：`undefined`（無限制） -- **若有設定**：每次授權成功時，Logto 會檢查該使用者於當前應用程式（跨瀏覽器與裝置）的有效授權總數。若超過上限，Logto 會撤銷最舊的授權。 +- **若有設定**：每次授權成功時，Logto 會檢查該使用者於當前應用程式的所有有效 grant（跨瀏覽器與裝置）。若超過上限，Logto 會撤銷最舊的 grant。 此設定適用於你想限制每個應用程式同時登入裝置數量的情境。 -每次淘汰都會觸發 `Grant.LimitExceeded` [Webhook 事件](/developers/webhooks/webhooks-events#exception-hook-events)，你可以通知使用者或追蹤超限頻率。 +每次淘汰都會觸發 `Grant.LimitExceeded` [Webhook 事件](/developers/webhooks/webhooks-events#exception-hook-events)，你可通知使用者或追蹤超限頻率。 :::note diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx index 577f1e60f2b..936ddde437b 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/README.mdx @@ -4,6 +4,7 @@ sidebar_position: 4 --- import AuthorizationIcon from '@site/src/assets/authorization.svg'; +import CloudConnectionIcon from '@site/src/assets/cloud-connection.svg'; import CustomizationIcon from '@site/src/assets/customization.svg'; import TabItem from '@theme/TabItem'; import Tabs from '@theme/Tabs'; @@ -16,19 +17,26 @@ Logto 的第三方應用程式整合功能，讓你能將 Logto 作為外部應 與你在 [將 Logto 整合到你的應用程式](/integrate-logto/integrate-logto-into-your-application) 指南中建立、由你完全控制的應用程式不同，第三方應用程式是由外部開發者或商業夥伴開發的獨立服務。 -這種整合方式非常適合常見的商業場景。你可以讓使用者用 Logto 帳號存取合作夥伴的應用程式，就像企業用戶用 Google Workspace 登入 Slack 一樣。你也可以打造開放平台，讓第三方應用程式新增「使用 Logto 登入」功能，類似「使用 Google 登入」。 +這種整合方式非常適合常見的商業場景。你可以讓使用者用 Logto 帳號登入合作夥伴的應用程式，就像企業用戶用 Google Workspace 登入 Slack 一樣。你也可以打造一個開放平台，讓第三方應用程式新增「使用 Logto 登入」功能，類似「使用 Google 登入」。 -Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 協議的身分服務，提供 [驗證 (Authentication)](https://auth.wiki/authentication) 與 [授權 (Authorization)](https://auth.wiki/authorization) 能力。這讓整合 OIDC 第三方應用程式就像傳統 Web 應用程式一樣簡單。 +Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 協議的身分服務，提供 [驗證 (Authentication)](https://auth.wiki/authentication) 與 [授權 (Authorization)](https://auth.wiki/authorization) 能力。這讓 OIDC 第三方應用程式的整合就像傳統 Web 應用程式一樣簡單。 由於 OIDC 建立於 [OAuth 2.0](https://auth.wiki/oauth-2.0) 之上，並新增了驗證層，因此你也可以使用 OAuth 協議整合第三方應用程式。 -## 在 Logto 中建立第三方應用程式 \{#create-a-third-party-application-in-logto} +## 導入第三方應用程式的兩種方式 \{#two-ways-to-onboard-a-third-party-app} + +- **在 Logto 註冊應用程式**（本指南）：你建立應用程式並設定其權限與重導 URI。適用於你已知合作夥伴的情境。 +- **[動態應用程式](/integrate-logto/third-party-applications/dynamic-apps)**：客戶端無需預先註冊，直接使用公開 HTTPS URL 作為 client ID，該 URL 提供自己的 metadata 文件。適用於任何客戶端都可能連線的情境，例如 MCP 客戶端與 AI agent。 + +兩種方式可同時使用。 + +## 在 Logto 建立第三方應用程式 \{#create-a-third-party-application-in-logto} 1. 前往 控制台 > 應用程式。 2. 點擊「建立應用程式」按鈕，選擇「第三方應用程式」作為應用程式類型，並選擇以下其中一種整合協議： - OIDC / OAuth -3. 根據第三方應用程式的類型選擇應用程式型態： - - **傳統 Web**：伺服器端渲染的應用程式（如 Node.js、PHP、Java），可在後端安全儲存 client secret。 +3. 根據第三方應用程式的型態選擇應用程式類型： + - **傳統 Web**：伺服器端渲染的應用程式（如 Node.js、PHP、Java），可安全儲存 client secret。 - **單頁應用程式 (SPA)**：前端渲染的應用程式（如 React、Vue、Angular），完全在瀏覽器執行，無法安全儲存密鑰。 - **原生應用程式 (Native)**：行動或桌面應用程式（如 iOS、Android、Electron），在使用者裝置上執行。 4. 輸入應用程式名稱與描述，點擊「建立」按鈕，即可建立新的第三方應用程式。 @@ -41,57 +49,57 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) ### 查找應用程式設定資訊 \{#find-the-application-configurations} -在應用程式詳細頁面，你可以找到 [**Client ID**](/integrate-logto/application-data-structure#application-id)、[**Client secret**](/integrate-logto/application-data-structure#application-secret)（僅限傳統 Web 應用程式），以及整合所需的 OIDC 端點。 +在應用程式詳細頁面，你可以找到整合所需的 [**Client ID**](/integrate-logto/application-data-structure#application-id)、[**Client secret**](/integrate-logto/application-data-structure#application-secret)（僅限傳統 Web 應用程式）以及 OIDC 端點。 -如果第三方服務支援 OIDC 探索，只需提供 **Discovery endpoint**。否則，點擊 **顯示端點詳細資訊** 以檢視所有端點，包括 [授權端點](/integrate-logto/application-data-structure#authorization-endpoint) 和 [權杖端點](/integrate-logto/application-data-structure#token-endpoint)。 +若第三方服務支援 OIDC discovery，只需提供 **Discovery endpoint**。否則，點擊 **顯示端點詳情** 可查看所有端點，包括 [授權端點](/integrate-logto/application-data-structure#authorization-endpoint) 與 [權杖端點](/integrate-logto/application-data-structure#token-endpoint)。 -### 與支援第三方 IdP 的服務整合 \{#integrate-with-services-that-support-third-party-idp} +### 整合支援第三方 IdP 的服務 \{#integrate-with-services-that-support-third-party-idp} -若你要連接原生支援外部身分提供者設定的服務或產品（如企業級 SaaS 平台、協作工具），設定流程如下： +若你要連接的服務或產品原生支援外部身分提供者設定（如企業級 SaaS 平台、協作工具），設定流程如下： -1. 開啟該服務的 IdP 或 SSO 設定頁面。 -2. 從 Logto 複製 **Client ID**（如需，還有 **Client secret**），貼到服務的設定中。 -3. 若服務支援 OIDC 自動探索，提供 **Discovery endpoint**；否則手動複製 **授權端點** 與 **權杖端點**。 -4. 從服務設定頁複製 **Redirect URI**，並將其加入 Logto 應用程式允許的 redirect URI 清單。 -5. 若服務允許，設定 **scopes**。Logto 作為 OIDC 提供者，若需驗證使用者，請包含 `openid` 權限範圍（可取得 ID 權杖與 UserInfo 端點）。若僅需 OAuth 資源存取，`openid` 權限範圍為選填。 +1. 開啟服務的 IdP 或 SSO 設定頁面。 +2. 從 Logto 複製 **Client ID**（如需則包含 **Client secret**），貼到服務的設定中。 +3. 若服務支援 OIDC 自動發現，提供 **Discovery endpoint**；否則手動複製 **授權端點** 與 **權杖端點**。 +4. 從服務設定頁複製 **Redirect URI**，並加入 Logto 應用程式允許的 redirect URI 清單。 +5. 若服務允許，設定 **scopes**。Logto 為 OIDC 提供者，若需驗證使用者請包含 `openid` 權限範圍（可取得 ID 權杖與 UserInfo 端點）。若僅需 OAuth 資源存取，`openid` 權限範圍為選填。 -服務設定完成後，會自動處理 OAuth / OIDC 流程。 +服務設定完成後，將自動處理 OAuth / OIDC 流程。 ### 透過 OAuth / OIDC 協議整合 \{#integrate-via-oauth-protocol} -若第三方應用程式需以程式方式將 Logto 作為 IdP 整合，應實作標準的 [授權碼流程 (Authorization Code Flow)](https://auth.wiki/authorization-code-flow)。建議使用你所用程式語言的 OAuth 2.0 / OIDC 客戶端函式庫來處理實作。 +若第三方應用程式需以程式方式將 Logto 作為 IdP 整合，應實作標準的 [授權碼流程 (Authorization Code Flow)](https://auth.wiki/authorization-code-flow)。建議使用你所用程式語言的 OAuth 2.0 / OIDC client library 來實作。 -傳統 Web 應用程式屬於 **機密用戶端 (confidential clients)**，可在後端安全儲存 client secret。完整實作細節請參考 [授權碼流程 (Authorization Code Flow)](https://auth.wiki/authorization-code-flow)。 +傳統 Web 應用程式屬於 **機密客戶端 (confidential clients)**，可安全儲存 client secret。完整實作細節請參考 [授權碼流程 (Authorization Code Flow)](https://auth.wiki/authorization-code-flow)。 **主要步驟：** 1. **啟動授權**：將使用者導向 Logto 的授權端點，帶上 `client_id`、`redirect_uri`、`response_type=code` 與 `scope`。 -2. **處理回呼**：從 redirect 接收授權 `code`。 -3. **交換權杖**：從後端向權杖端點發送 POST 請求，帶上 code、`client_id` 與 `client_secret`。 +2. **處理回調**：從 redirect 接收授權 `code`。 +3. **交換權杖**：從後端以 POST 請求帶上 code、`client_id` 與 `client_secret` 到權杖端點。 -單頁應用程式與原生應用程式屬於 **公開用戶端 (public clients)**，無法安全儲存密鑰。這類應用程式必須使用 [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) 進行安全授權。完整實作細節請參考 [授權碼流程 (Authorization Code Flow)](https://auth.wiki/authorization-code-flow) 與 [PKCE](https://auth.wiki/pkce)。 +單頁應用程式與原生應用程式屬於 **公開客戶端 (public clients)**，無法安全儲存密鑰。這類應用程式必須使用 [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) 來確保授權安全。完整實作細節請參考 [授權碼流程 (Authorization Code Flow)](https://auth.wiki/authorization-code-flow) 與 [PKCE](https://auth.wiki/pkce)。 **主要步驟：** 1. **產生 PKCE 參數**：建立 `code_verifier` 並推導出 `code_challenge`（SHA-256）。 2. **啟動授權**：將使用者導向授權端點，帶上 `code_challenge` 與 `code_challenge_method=S256`。 -3. **處理回呼**：從 redirect 接收授權 `code`。 -4. **交換權杖**：向權杖端點發送 POST 請求，帶上 code 與原始 `code_verifier`。 +3. **處理回調**：從 redirect 接收授權 `code`。 +4. **交換權杖**：以 POST 請求帶上 code 與原始 `code_verifier` 到權杖端點。 ### 透過裝置流程整合 \{#integrate-via-device-flow} -對於運行於輸入受限裝置（如智慧電視、遊戲主機、CLI 工具）的原生第三方應用程式，標準的 redirect 授權碼流程可能不可行。此時可改用 [OAuth 2.0 裝置授權流程 (Device Authorization Grant)](https://auth.wiki/device-flow)。 +對於運行於輸入受限裝置（如智慧電視、遊戲主機、CLI 工具）的原生第三方應用程式，標準的重導向授權碼流程可能不適用。此時可改用 [OAuth 2.0 裝置授權流程 (Device Authorization Grant)](https://auth.wiki/device-flow)。 -裝置流程會在裝置上顯示一組用戶代碼與驗證網址。使用者在另一台裝置（手機、筆電）上造訪該網址，輸入代碼並完成驗證。裝置則持續輪詢 Logto 的權杖端點，直到授權完成。 +裝置流程會在裝置上顯示一組使用者代碼與驗證網址。使用者在另一台裝置（手機、筆電）上造訪該網址，輸入代碼並完成驗證。裝置則持續輪詢 Logto 的權杖端點，直到授權完成。 :::note 在實作裝置流程前，請先於 Logto 控制台為你的第三方應用程式設定所需的 [權限](/integrate-logto/third-party-applications/permission-management)。第三方應用程式若請求未啟用的權限範圍將被拒絕存取。 @@ -103,7 +111,7 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 出於安全考量，所有 OIDC 第三方應用程式在經 Logto 驗證後，將被導向 [使用者授權頁面 (Consent screen)](/end-user-flows/consent-screen) 進行授權。 -所有第三方請求的 [使用者資料權限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API 資源權限範圍](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[組織權限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) 及組織成員資訊，皆會顯示於授權頁面。 +所有第三方請求的 [使用者資料權限](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes)、[API 資源權限範圍](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes)、[組織權限](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes) 及組織成員資訊都會顯示於授權頁面。 這些請求的權限僅在使用者點擊「授權」按鈕後才會授予第三方應用程式。 @@ -117,7 +125,7 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) items={[ { type: 'link', - label: '權限管理 (Permission management)', + label: '權限管理', href: '/integrate-logto/third-party-applications/permission-management', description: '瞭解如何管理你的 OIDC 第三方應用程式的權限。', customProps: { @@ -126,13 +134,23 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) }, { type: 'link', - label: '授權頁面品牌設定 (Consent screen branding)', + label: '授權頁面品牌設定', href: '/integrate-logto/third-party-applications/consent-screen-branding', - description: '自訂授權頁面外觀，讓其符合你的品牌識別，並提供一致的使用者體驗。', + description: '自訂授權頁面外觀，讓其符合你的品牌識別，並提供一致的使用體驗 (Experience)。', customProps: { icon: , }, }, + { + type: 'link', + label: '動態應用程式 (CIMD)', + href: '/integrate-logto/third-party-applications/dynamic-apps', + description: + '允許 OAuth 客戶端無需預先註冊即可連線，直接以 client ID metadata 文件 URL 作為 client ID。', + customProps: { + icon: , + }, + }, ]} /> @@ -141,24 +159,24 @@ Logto 是一個基於 [OpenID Connect (OIDC)](https://auth.wiki/openid-connect)
-### 我們如何確保使用者只能在授權頁面授予他們實際擁有的權限？ \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} +### 我們如何確保使用者只能在授權頁面授予自己實際擁有的權限？ \{#how-do-we-ensure-users-can-only-grant-permissions-they-actually-have-on-the-consent-screen} -Logto 透過基於角色的存取控制 (RBAC, Role-Based Access Control) 管理使用者權限。在授權頁面上，僅會顯示已經透過角色分配給使用者的權限範圍（scopes）。若第三方應用程式請求使用者未擁有的權限範圍，這些權限將不會顯示，以防止未經授權的授權行為。 +Logto 透過基於角色的存取控制 (RBAC, Role-Based Access Control) 管理使用者權限。在授權頁面上，僅會顯示已透過角色分配給使用者的權限範圍（scopes）。若第三方應用程式請求使用者未擁有的權限範圍，這些權限將不會顯示，以防止未授權的授權行為。 管理方式如下： - 定義具有特定權限範圍的 [全域角色](/authorization/role-based-access-control) 或 [組織角色](/authorization/organization-template)。 - 根據存取需求將角色分配給使用者。 -- 使用者會自動繼承其角色的權限範圍。 +- 使用者將自動繼承其角色的權限範圍。
## 相關資源 \{#related-resources} - 使用案例：整合 Apache Answer，為你的用戶打造社群 + 使用案例：整合 Apache Answer 為你的用戶打造社群 使用 Logto 作為第三方身分提供者 (IdP) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx new file mode 100644 index 00000000000..f358922e3fa --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/integrate-logto/third-party-applications/dynamic-apps.mdx @@ -0,0 +1,99 @@ +--- +description: 允許 OAuth 用戶端透過使用 client ID metadata document URL 作為其 client ID，無需預先註冊即可連接到你的租戶。 +sidebar_label: 動態應用程式 (CIMD) +sidebar_position: 3 +--- + +# 動態應用程式 (CIMD) + +動態應用程式允許 OAuth 用戶端無需預先註冊即可連接到你的租戶。用戶端不再使用 Logto 發行的 client ID，而是以公開的 HTTPS URL 作為其 `client_id`。該 URL 提供一份描述用戶端的 JSON 文件，稱為 [client ID metadata document (CIMD)](https://auth.wiki/client-id-metadata-document)。Logto 會擷取此文件，並將該用戶端視為 [第三方應用程式](/integrate-logto/third-party-applications)。 + +動態應用程式實作了 IETF 草案 [OAuth Client ID Metadata Document](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html)。 + +## 什麼時候該使用動態應用程式 \{#when-to-use-dynamic-app} + +預先註冊適用於你已知合作夥伴的情境。當任何用戶端都可能連接時（這在 [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents) 生態系中很常見）：例如，使用者要求其 AI agent 連接你的服務，而該 agent 之前從未與你的租戶互動。 + +透過動態應用程式，用戶端在其擁有的 URL 上公開自己的 metadata，該 URL 即為其身分。你的租戶無需事先建立任何內容。 + +| | 已註冊第三方應用程式 | 動態應用程式 | +| ------------- | -------------------- | --------------------------------------- | +| Client ID | 由 Logto 發行 | 用戶端擁有的 HTTPS URL | +| 註冊 | 必須 | 不需要 | +| Client secret | 支援 | 不支援 | +| 權限 | 每個應用程式獨立 | 所有動態用戶端共用 | +| Grant types | 依應用程式類型而定 | `authorization_code` 與 `refresh_token` | + +動態用戶端屬於公開用戶端，因此一律使用 [PKCE](https://auth.wiki/pkce)。你可以同時使用這兩種模式。你信任的合作夥伴仍可擁有專屬權限的註冊應用程式。 + +## 啟用動態應用程式 \{#enable-dynamic-app} + +1. 前往 主控台 > 應用程式，並切換到 **第三方應用程式** 分頁。 +2. 點擊 **建立應用程式** 並選擇 **動態應用程式** 卡片。這會啟用租戶層級功能，而非建立一個應用程式。 +3. 在對話框中確認。啟用後，任何擁有有效公開 HTTPS client ID URL 的 OAuth 用戶端都可以開始對你的租戶發起授權請求。 +4. 從應用程式清單中開啟動態應用程式，並前往 **權限** 分頁以授予權限。 + +動態應用程式沒有可編輯的名稱、redirect URI 或憑證。每個用戶端會在其 metadata document 中提供這些資訊。 + +:::note +動態應用程式需要 [OIDC provider SSRF 保護](/concepts/core-service/configuration#oidc-provider-ssrf-protection)，因為 Logto 會從網際網路擷取 metadata document。若自架部署停用此功能，則無法啟用動態應用程式。 +::: + +### 授予權限 \{#grant-permissions} + +**權限** 分頁定義所有動態用戶端共用的最大權限。其運作方式與已註冊第三方應用程式的 [權限管理](/integrate-logto/third-party-applications/permission-management) 相同，分為 **使用者 (User)** 與 **組織 (Organization)** 區塊。 + +請求未被授予的使用者權限會導致錯誤，未被授予的 API 資源與組織權限則會被忽略。使用者僅會同意其透過 [角色 (Roles)](/authorization/role-based-access-control) 擁有的權限。 + +由於所有動態用戶端共用這組權限，請盡量保持精簡。 + +## 發佈 client ID metadata document \{#publish-a-client-id-metadata-document} + +如果你正在開發連接 Logto 的用戶端，請託管一份 metadata document，並將其 URL 作為你的 `client_id`。該 URL 必須使用 `https` 協定，且不得包含 fragment、user info 或點路徑段。Logto 會對該 URL 發送 `GET` 請求，並期望收到 JSON 物件。 + +例如，Claude Code 使用 `https://claude.ai/oauth/claude-code-client-metadata`，其內容如下： + +```json +{ + "client_id": "https://claude.ai/oauth/claude-code-client-metadata", + "client_name": "Claude Code", + "client_uri": "https://claude.ai", + "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"], + "token_endpoint_auth_method": "none" +} +``` + +欄位名稱與 [OAuth 2.0 動態用戶端註冊](https://datatracker.ietf.org/doc/html/rfc7591#section-2) 相同。注意： + +- `client_id` 必須與提供該文件的 URL 完全一致。 +- 動態用戶端屬於公開用戶端。文件中不得包含 `client_secret`，且 `token_endpoint_auth_method` 不得為共用密鑰方法。請改用 [PKCE](https://auth.wiki/pkce)。 +- `client_uri`、`logo_uri`、`tos_uri`、`policy_uri` 等 metadata URI 必須為絕對 `https` URL。這不適用於 `redirect_uris`，因此原生用戶端仍可使用如上例的 loopback 位址。 +- `redirect_uris` 需完全比對字串，唯獨 loopback 位址可比對任意 port。[萬用字元模式](/integrate-logto/application-data-structure#wildcard-patterns) 亦支援。 +- `scope`、`grant_types` 與 `response_types` 由 Logto 決定。若文件宣告這些欄位，將被忽略。動態用戶端僅能使用授權碼流程與重新整理權杖。 + +Logto 最多會根據你的回應 `Cache-Control` 與 `Expires` 標頭快取該文件 24 小時。請根據你預期的更新頻率設定這些標頭。 + +## 使用者授權頁面 (Consent screen) \{#consent-screen} + +動態用戶端屬於第三方應用程式，因此 [使用者授權頁面 (Consent screen)](/end-user-flows/consent-screen) 一定會顯示。 + +授權頁面同時會顯示該用戶端尚未註冊的提示。用戶端名稱與 logo 來自 metadata document，因此可模仿任何品牌。client ID URL 的主機名稱也會顯示，因為這是用戶端唯一無法偽造的部分。 + +## 管理授權 (Manage authorizations) \{#manage-authorizations} + +授予動態用戶端的授權屬於一般第三方 [授權 (grants)](/sessions/grants-management)。使用者可在帳號設定中檢視與撤銷，管理員則可透過 Management API 管理。client ID URL 用於識別用戶端。 + +停用動態應用程式會阻止新的授權請求，但現有授權會保留。撤銷授權後，用戶端需再次獲得使用者授權，但先前發出的存取權杖 (Access tokens) 可能會在到期前繼續有效。 + +## 限制 \{#limitations} + +- 僅支援授權碼流程（含 PKCE）與重新整理權杖。不支援 client credentials、裝置流程與權杖交換。 +- 權限與品牌無法針對單一用戶端設定。 +- [應用程式層級存取控制](/authorization/app-level-access-control) 不適用於動態用戶端，因為它們沒有應用程式紀錄。 + +## 相關資源 \{#related-resources} + +第三方應用程式（OAuth / OIDC） + + 啟用第三方 AI agent 存取你的 MCP 伺服器 + diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx index 7319c533364..e58c935365e 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/sessions/grants-management.mdx @@ -2,70 +2,72 @@ sidebar_position: 2 --- -# 管理使用者授權的應用程式（授權） +# 管理使用者授權應用程式（授權記錄，grants） -應用程式授權代表使用者對特定客戶端應用程式的授權狀態。 +應用程式授權記錄（app grants）代表使用者對特定用戶端應用程式的授權狀態。 -當使用者或管理員需要檢視授權的應用程式並撤銷應用程式存取權，而不撤銷整個 Logto 會話時，可以使用授權管理。 +當使用者或管理員需要檢視已授權的應用程式並撤銷應用程式存取權（而不影響整個 Logto 工作階段）時，請使用授權記錄管理功能。 -當授權被撤銷時，先前發出的不透明存取權杖和重新整理權杖將失效。 +當授權記錄被撤銷時，先前發出的不透明權杖 (Opaque tokens) 和重新整理權杖 (Refresh tokens) 會失效。JWT 存取權杖 (Access tokens) 為無狀態，因此先前發出的權杖會在過期前持續有效。 -## 選擇正確的路徑 \{#choose-the-right-path} +## 選擇正確的管理方式 \{#choose-the-right-path} -| 情境 | 推薦路徑 | -| -------------------------------------- | -------------- | -| 讓已登入的使用者管理自己的應用程式授權 | Account API | -| 讓管理員或支援團隊管理目標使用者的授權 | Management API | -| 讓操作員在 UI 中管理第三方應用程式授權 | Admin Console | +| 情境 | 建議路徑 | +| ------------------------------------------ | -------------------------- | +| 讓已登入使用者自行管理其應用程式授權 | Account API | +| 讓管理員或客服團隊為目標使用者管理授權記錄 | Management API | +| 讓營運人員於 UI 管理第三方應用程式授權 | 管理主控台 (Admin Console) | -## 直接授權管理 API \{#direct-grant-management-apis} +## 直接授權記錄管理 API \{#direct-grant-management-apis} ### Account API（自助服務）\{#account-api-self-service} -在終端使用者帳戶設定頁面中使用 Account API： +於終端使用者帳戶設定頁面使用 Account API： - `GET /api/my-account/grants` - `DELETE /api/my-account/grants/{grantId}` -- 參考：[管理使用者授權的應用程式（授權）](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) +- 參考：[透過 Account API 管理使用者授權應用程式（授權記錄）](/end-user-flows/account-settings/by-account-api#manage-user-authorized-apps-grants) ### Management API（管理工具）\{#management-api-admin-tools} -在管理工具和支援工作流程中使用 Management API： +於管理工具與客服流程中使用 Management API： - `GET /api/users/{userId}/grants` - `DELETE /api/users/{userId}/grants/{grantId}` -- 參考：[管理使用者授權的應用程式（授權）](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) +- 參考：[透過 Management API 管理使用者授權應用程式（授權記錄）](/end-user-flows/account-settings/by-management-api#manage-user-authorized-apps-grants) -### 按應用程式類型篩選授權列表 \{#filter-grant-list-by-app-type} +### 依應用程式類型篩選授權記錄清單 \{#filter-grant-list-by-app-type} -授權列表端點支援可選的查詢參數 `appType`： +授權記錄查詢端點支援可選查詢參數 `appType`： -- `appType=firstParty`：僅列出第一方應用程式授權。 -- `appType=thirdParty`：僅列出第三方應用程式授權。 -- 省略 `appType`：返回所有活動授權。 +- `appType=firstParty`：僅列出第一方應用程式授權記錄。 +- `appType=thirdParty`：僅列出第三方應用程式授權記錄。 +- 省略 `appType`：回傳所有有效授權記錄。 -## 在 Console 中管理第三方應用程式授權 \{#manage-third-party-app-authorizations-in-console} +[動態應用程式 (Dynamic app)](/integrate-logto/third-party-applications/dynamic-apps) 用戶端屬於第三方應用程式，因此其授權記錄會以 `appType=thirdParty` 回傳。用戶端 ID URL 作為應用程式 ID 使用。 -在 Logto Console 中，使用使用者詳細資料頁面查看和撤銷授權的第三方應用程式。 +## 於主控台管理第三方應用程式授權 \{#manage-third-party-app-authorizations-in-console} + +在 Logto 主控台 (Console) 的使用者詳情頁面，可檢視並撤銷已授權的第三方應用程式。 - 參考：[管理使用者授權的第三方應用程式](/user-management/manage-users#manage-user-authorized-third-party-apps) -## 撤銷會話時撤銷授權 \{#revoke-grants-when-revoking-a-session} +## 撤銷工作階段時一併撤銷授權記錄 \{#revoke-grants-when-revoking-a-session} -透過 `DELETE /api/my-account/sessions/{sessionId}` 撤銷會話時，使用可選的查詢參數 `revokeGrantsTarget` 控制授權撤銷範圍： +透過 `DELETE /api/my-account/sessions/{sessionId}` 撤銷工作階段時，可使用可選查詢參數 `revokeGrantsTarget` 控制授權記錄撤銷範圍： -- `all`：撤銷與會話相關的所有應用程式的授權。 -- `firstParty`：僅撤銷第一方應用程式的授權。 +- `all`：撤銷與該工作階段關聯的所有應用程式授權記錄。 +- `firstParty`：僅撤銷第一方應用程式的授權記錄。 -有關會話層級行為和端點上下文，請參閱 [管理使用者會話](/sessions/manage-user-sessions) 和 [登出](/end-user-flows/sign-out)。 +關於工作階段層級行為與端點說明，請參閱 [管理使用者工作階段](/sessions/manage-user-sessions) 與 [登出 (Sign-out)](/end-user-flows/sign-out)。 ## 相關資源 \{#related-resources} -Sessions -管理使用者會話 +工作階段 (Sessions) +管理使用者工作階段 - 透過 Account API 的帳戶設定：管理使用者授權的應用程式（授權） + 透過 Account API 管理使用者授權應用程式（授權記錄） - 透過 Management API 的帳戶設定：管理使用者授權的應用程式（授權） + 透過 Management API 管理使用者授權應用程式（授權記錄） diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx index 25fefbe9e27..0b00b8f7e83 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/use-cases/ai/fragments/_configure-third-party-ai-agent.mdx @@ -2,51 +2,74 @@ import QuickStartsReference from '../../../quick-starts/third-party/oidc/_quick- ## 在 Logto 設定第三方 AI agent \{#configure-third-party-ai-agent-in-logto} -若要讓第三方 AI agent 存取你的 {props.serviceName ?? '服務'}，你需要在 Logto 中建立一個**第三方應用程式 (third-party app)**。這個應用程式將代表 AI agent，並取得驗證 (Authentication) 與授權 (Authorization) 所需的憑證。 +若要讓第三方 AI agent 存取你的 {props.serviceName ?? '服務'}，你需要在 Logto 中建立一個**第三方應用程式（third-party app）**。這個應用程式將代表 AI agent，並取得驗證 (Authentication) 與授權 (Authorization) 所需的憑證。 :::info[什麼是第三方應用程式？] -**第三方應用程式 (third-party app)** 是由外部開發者（非資源擁有者）建立的應用程式，需要使用者同意才能存取受保護資源。與第一方應用程式（你自己的應用程式）不同，第三方應用程式會顯示使用者授權頁面 (Consent screen)，要求使用者在存取其資料前批准特定權限。這確保使用者能掌控與外部服務分享哪些資料。 +**第三方應用程式（third-party app）** 是由外部開發者（非資源擁有者）建立的應用程式，需經使用者同意才能存取受保護資源。與第一方應用程式（你自己的應用程式）不同，第三方應用程式會顯示使用者授權頁面（consent screen），要求使用者在存取資料前同意特定權限。這確保使用者能掌控與外部服務分享哪些資料。 想了解更多，請參閱 [第三方應用程式](/integrate-logto/third-party-applications)。 ::: +有三種方式可將 AI agent 導入系統： + +- [在 Console 手動建立應用程式](#manually-create-a-third-party-app-in-logto)，適合測試或少數已知 agent。 +- [基於 Management API 建立註冊服務](#allow-developers-to-create-third-party-apps-in-logto)，若你想控管誰能取得憑證。 +- [啟用動態應用程式（dynamic app）](#let-any-ai-agent-connect-without-pre-registration)，若任何 agent 都可能連線且你不想有註冊步驟。 + ### 允許開發者在 Logto 建立第三方應用程式 \{#allow-developers-to-create-third-party-apps-in-logto} -如果你正在打造市集或希望開發者能在 Logto 建立第三方應用程式，可以利用 [Logto Management API](/integrate-logto/interact-with-management-api) 以程式方式建立第三方應用程式。這讓開發者能註冊他們的應用程式並取得驗證所需的憑證。 +如果你正在打造市集或想讓開發者能在 Logto 建立第三方應用程式，可以利用 [Logto Management API](/integrate-logto/interact-with-management-api) 以程式方式建立第三方應用程式。這讓開發者能註冊他們的應用程式並取得驗證 (Authentication) 所需的憑證。 -你需要自行架設服務來處理 client 註冊流程。該服務會與 Logto Management API 互動，代表開發者建立第三方應用程式。 +你需要自行架設服務來處理 client 註冊流程。此服務會與 Logto Management API 互動，代表開發者建立第三方應用程式。 ```mermaid sequenceDiagram - actor Developer + actor Developer as 開發者 (Developer) participant Server as 你的應用程式註冊服務 (Your app registration service) participant Logto as Logto Management API Developer->>Server: 註冊應用程式 (Register app) Server->>Logto: 建立應用程式 (Create app) - Logto->>Server: App ID、密鑰等 (App ID, secret, etc.) - Server->>Developer: App ID、密鑰等 (App ID, secret, etc.) + Logto->>Server: 應用程式 ID、密鑰等 (App ID, secret, etc.) + Server->>Developer: 應用程式 ID、密鑰等 (App ID, secret, etc.) ``` 你也可以在 Logto Console 手動建立第三方應用程式，以熟悉整個流程。 +### 允許任何 AI agent 免預先註冊直接連線 \{#let-any-ai-agent-connect-without-pre-registration} + +在開放的 MCP 生態系中，你通常無法事先知道所有 agent。[動態應用程式（dynamic app）](/integrate-logto/third-party-applications/dynamic-apps) 省略了註冊步驟：agent 直接以公開 HTTPS URL（其自身 client metadata 文件）作為 `client_id`，Logto 在收到授權請求時自動解析。 + +```mermaid +sequenceDiagram + participant Agent as AI agent（MCP client） + participant Logto + participant Metadata as Agent 的 metadata 文件 URL + Agent->>Logto: 帶有 client ID URL 的授權請求 (Authorization request with the client ID URL) + Logto->>Metadata: 取得 client ID metadata 文件 (Fetch the client ID metadata document) + Metadata->>Logto: 應用名稱、logo、redirect URI 等 (Client name, logo, redirect URIs, etc.) + Logto->>Agent: 使用者授權頁面，然後授權碼 (Consent screen, then authorization code) +``` + +你仍可透過授予動態應用程式的權限來控管 agent 可請求的內容，且每次授權都會經過使用者授權頁面（consent screen）。 + ### 在 Logto 手動建立第三方應用程式 \{#manually-create-a-third-party-app-in-logto} -你可以在 Logto Console 手動建立第三方應用程式，作為測試或臨時整合之用。這在你想快速測試整合、尚未實作完整 client 註冊流程時特別有用。 +你可以在 Logto Console 手動建立第三方應用程式，適合測試或臨時整合。這對於想快速測試整合而不需實作完整 client 註冊流程時特別有用。 1. 登入你的 Logto Console。 -2. 前往 **應用程式 (Applications)** → **建立應用程式 (Create application)** → **第三方應用程式 (Third-party app)** -> **OIDC**。 -3. 輸入應用程式名稱及其他必要欄位，然後點擊 **建立應用程式 (Create application)**。 -4. 點選 **權限 (Permissions)** 分頁，在 **使用者 (User)** 區塊點擊「新增 (Add)」。 -5. 在開啟的對話框 -> **使用者資料 (User data)** -> 勾選 **`profile`**、**`email`** 權限，然後點擊 **儲存 (Save)**。 +2. 前往 **應用程式（Applications）** → **建立應用程式（Create application）** → **第三方應用程式（Third-party app）** -> **OIDC**。 +3. 輸入應用程式名稱及其他必要欄位，然後點擊 **建立應用程式（Create application）**。 +4. 點選 **權限（Permissions）** 分頁，在 **使用者（User）** 區塊點擊「新增（Add）」。 +5. 在開啟的對話框中 -> **使用者資料（User data）** -> 勾選 **`profile`**、**`email`** 權限，然後點擊 **儲存（Save）**。 6. 在第三方應用程式中，設定 scopes 以請求 `openid profile email` 權限（scopes）。 **注意**：`openid` 為 OIDC 必填，`profile` 與 `email` 則是你在前一步新增的權限。 -7. 依需求設定你的第三方應用程式的 **redirect URI**，並記得在 Logto 中同步更新 redirect URI。 +7. 依需求設定你的第三方應用程式的 **redirect URI**，並記得在 Logto 內同步更新 redirect URI。 第三方應用程式權限 (Third-party app permissions)