Anwendungsdatenstruktur
Einführung
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 Logto-Audit-Logs verwendet, um Benutzeraktivitäten zu verfolgen und potenzielle Sicherheitsbedrohungen oder -verletzungen zu erkennen. 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.
Eigenschaften
Anwendungs-ID
Anwendungs-ID ist ein eindeutiger, automatisch generierter Schlüssel zur Identifizierung deiner Anwendung in Logto und wird als client id in OAuth 2.0 bezeichnet.
Anwendungstypen
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- 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 anstelle des Standard-Redirect-basierten Flows. Siehe Device Flow Schnellstart 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 direkte Service-zu-Service-Kommunikation ohne Benutzerinteraktion läuft.
Anwendungsschlüssel
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.
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). Anstelle eines App-Schlüssels schützt Logto sie mit PKCE, strikter Redirect-URI/CORS-Validierung, kurzlebigen Zugangstokens und Auffrischungstoken-Rotation.
Anwendungsname
Anwendungsname ist ein menschenlesbarer Name der Anwendung und wird in der Admin-Konsole angezeigt.
Der Anwendungsname ist ein wichtiger Bestandteil der Verwaltung von Anwendungen in Logto, da er Administratoren ermöglicht, einzelne Anwendungen innerhalb der Plattform einfach zu identifizieren und deren Aktivitäten nachzuverfolgen.
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.
Beschreibung
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 weitere relevante Details.
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.
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.
Redirect-URIs im OIDC mit Authorization Code Flow verstehen
Wildcard-Muster
Verfügbarkeit: Single Page App, Traditionelle Web-App
Redirect-URIs unterstützen Wildcard-Muster (*) für dynamische Umgebungen wie Preview-Deployments. Wildcards können in den Hostnamen- und Pfadkomponenten von HTTP/HTTPS-URIs verwendet werden.
Regeln:
- Wildcards sind nur im Hostnamen und Pfadnamen erlaubt
- Wildcards sind nicht im Schema, Port, in Query-Parametern oder Hash-Fragmente erlaubt
- Hostname-Wildcards müssen mindestens einen Punkt enthalten (z. B.
https://*.example.com/callback)
Beispiele:
https://*.example.com/callback– passt auf jede Subdomainhttps://preview-*.example.com/callback– passt auf Preview-Deploymentshttps://example.com/*/callback– passt auf jedes Pfadsegment
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 sind eine Liste gültiger URIs, die für eine Anwendung vorkonfiguriert wurden, um den Benutzer nach dem Abmelden von Logto weiterzuleiten.
Die Verwendung von erlaubten Post-Sign-out-Redirect-URIs für Logout ist Teil der RP-Initiated (Relying Party Initiated) Logout-Spezifikation in OIDC. Diese Spezifikation bietet eine standardisierte Methode für Anwendungen, eine Logout-Anfrage für einen Benutzer zu initiieren, einschließlich der Weiterleitung des Benutzers zu einem vorkonfigurierten Endpunkt nach dem Abmelden.
Wenn sich ein Benutzer von Logto abmeldet, wird seine Sitzung beendet und er wird zu einer der in den Anwendungseinstellungen angegebenen erlaubten URIs 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.
CORS erlaubte Ursprünge
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 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 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
Der Endpunkt für OpenID Connect Discovery.
Autorisierungsendpunkt
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.
Weitere Informationen findest du beim Authorization Endpoint.
Token-Endpunkt
Token-Endpunkt ist ein OIDC-Begriff. Es handelt sich um einen Web-API-Endpunkt, der von einem OIDC-Client verwendet wird, um ein Zugangstoken, ein ID-Token oder ein Auffrischungstoken von einem OIDC-Provider zu erhalten.
Wenn ein OIDC-Client ein Zugangstoken oder ID-Token benötigt, sendet er eine Anfrage an den Token-Endpunkt mit einer Autorisierungsgewährung, die typischerweise ein Autorisierungscode oder ein Auffrischungstoken ist. Der Token-Endpunkt validiert dann die Autorisierungsgewährung und stellt dem Client ein Zugangstoken oder ID-Token aus, wenn die Gewährung gültig ist.
Weitere Informationen findest du beim Token Endpoint.
Userinfo-Endpunkt
Der OpenID Connect UserInfo Endpoint.
Immer Auffrischungstoken ausstellen
Verfügbarkeit: Traditionelle Web, SPA
Wenn aktiviert, stellt Logto immer Auffrischungstokens aus, unabhängig davon, ob prompt=consent in der Authentifizierungsanfrage vorhanden ist oder offline_access in den Berechtigungen enthalten ist.
Diese Praxis wird jedoch nicht empfohlen, es sei denn, sie ist notwendig (in der Regel nützlich für einige OAuth-Integrationen von Drittanbietern, die ein Auffrischungstoken erfordern), da sie nicht mit OpenID Connect kompatibel ist und potenziell Probleme verursachen kann.
Auffrischungstoken rotieren
Standard: true
Wenn aktiviert, stellt Logto ein neues Auffrischungstoken für Token-Anfragen unter den folgenden Bedingungen aus:
- Wenn das Auffrischungstoken rotiert wurde (seine TTL durch die Ausgabe eines neuen Tokens verlängert wurde) für ein Jahr; ODER
- Wenn das Auffrischungstoken kurz vor dem Ablauf steht (>=70% seiner ursprünglichen Lebensdauer (TTL) vergangen); ODER
- Wenn der Client ein öffentlicher Client ist, z. B. Native Anwendung oder Single Page Application (SPA).
Für öffentliche Clients wird bei aktivierter Funktion immer ein neues Auffrischungstoken ausgestellt, wenn der Client ein neues Zugangstoken mit dem Auffrischungstoken anfordert. Obwohl du die Funktion für diese öffentlichen Clients deaktivieren kannst, wird dringend empfohlen, sie aus Sicherheitsgründen aktiviert zu lassen.
Auffrischungstoken-Rotation verstehen
Auffrischungstoken Lebensdauer (TTL) in Tagen
Verfügbarkeit: Nicht SPA; Standard: 14 Tage
Die Dauer, für die ein Auffrischungstoken verwendet werden kann, um neue Zugangstokens anzufordern, bevor es abläuft und ungültig wird. Token-Anfragen verlängern die TTL des Auffrischungstokens auf diesen Wert.
In der Regel wird ein niedrigerer Wert bevorzugt.
Hinweis: Die Verlängerung der TTL ist in SPA (Single Page App) aus Sicherheitsgründen nicht verfügbar. Das bedeutet, dass Logto die TTL nicht durch Token-Anfragen verlängert. Um die Benutzererfahrung zu verbessern, kannst du die Funktion "Auffrischungstoken rotieren" aktivieren, sodass Logto bei Bedarf ein neues Auffrischungstoken ausstellt.
Wenn ein Auffrischungstoken ohne die Berechtigung offline_access in der Autorisierungsanfrage ausgestellt wird, wird 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 die Berechtigung offline_access in deiner Autorisierungsanfrage einschließt.
Backchannel-Logout-URI
Der OpenID Connect Backchannel-Logout-Endpunkt. Siehe Föderiertes Abmelden: Back-Channel-Logout für weitere Informationen.
Benutzerdefinierte Daten
Zusätzliche benutzerdefinierte Anwendungsinformationen, die nicht in den vordefinierten Anwendungseigenschaften aufgeführt sind. Benutzer können eigene benutzerdefinierte Datenfelder entsprechend ihren spezifischen Anforderungen definieren, z. B. geschäftsspezifische Einstellungen und Konfigurationen.