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 auszuführen. Anwendungen werden verwendet, um die Quelle von Anfragen an die Logto API zu identifizieren sowie den Authentifizierungs- und Autorisierungsprozess für Benutzer, die auf diese Anwendungen zugreifen, zu verwalten.
Die Verwendung von Anwendungen in 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 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.
Eigenschaften
Anwendungs-ID
Die Anwendungs-ID ist ein eindeutiger, automatisch generierter Schlüssel zur Identifizierung deiner Anwendung in Logto und wird in OAuth 2.0 als client id 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.
- 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
Der Anwendungsschlüssel ist ein Schlüssel, der zur Authentifizierung der Anwendung im Authentifizierungssystem verwendet wird, speziell für private Clients (traditionelle Web- und M2M-Apps) als private Sicherheitsbarriere.
Single Page Apps (SPAs) und Native Apps stellen keinen App-Schlüssel bereit. SPAs und Native Apps sind "öffentliche Clients" und können keine Geheimnisse bewahren (Browser-Code oder App-Bundles sind einsehbar). Statt eines App-Schlüssels schützt Logto sie mit PKCE, strikter Redirect-URI/CORS-Validierung, kurzlebigen Zugangstokens und Auffrischungstoken-Rotation.
Anwendungsname
Der Anwendungsname ist ein menschenlesbarer Name der Anwendung und wird in der Admin-Konsole angezeigt.
Der Anwendungsname ist ein wichtiger Bestandteil der Anwendungsverwaltung in Logto, da Administratoren damit einzelne Anwendungen innerhalb der Plattform leicht identifizieren und deren Aktivitäten verfolgen können.
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 liefern, wie z. B. ihren Zweck, ihre Funktionalität und andere 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 einer Anwendung in Logto hinzugefügt werden, damit Benutzer nach der Authentifizierung erfolgreich auf die Anwendung zugreifen können.
Weitere Informationen findest du im Redirection Endpoint.
Redirect-URIs in OIDC mit Authorization Code Flow verstehen
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 unter 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 CORS-erlaubten Ursprünge wird verwendet, um den Zugriff auf den Logto-Dienst von nicht autorisierten Domains einzuschränken und Cross-Site-Request-Forgery (CSRF)-Angriffe zu verhindern. Durch die Angabe der erlaubten Ursprünge für eine Anwendung in Logto kann der Dienst sicherstellen, dass nur autorisierte Domains Anfragen an den Dienst stellen können.
Die Liste der erlaubten Ursprünge sollte den Ursprung enthalten, unter dem die Anwendung bereitgestellt wird. So wird sichergestellt, dass Anfragen von der Anwendung erlaubt sind, während Anfragen von nicht autorisierten Ursprüngen blockiert werden.
OpenID-Provider-Konfigurationsendpunkt
Der Endpunkt für OpenID Connect Discovery.
Autorisierungsendpunkt
Der Autorisierungsendpunkt ist ein OIDC-Begriff und ein erforderlicher Endpunkt, der verwendet wird, um den Authentifizierungsprozess für einen Benutzer zu starten. Wenn ein Benutzer versucht, auf eine geschützte Ressource oder Anwendung zuzugreifen, die bei der Logto-Plattform registriert ist, wird er zum Autorisierungsendpunkt weitergeleitet, um seine Identität zu authentifizieren und die Autorisierung für den Zugriff auf die angeforderte Ressource zu erhalten.
Weitere Informationen findest du unter Authorization Endpoint.
Token-Endpunkt
Der Token-Endpunkt ist ein OIDC-Begriff. Es handelt sich um einen Web-API-Endpunkt, der von einem OIDC-Client verwendet wird, um ein Zugangstoken, ein ID-Token oder ein Auffrischungstoken vom OIDC-Provider zu erhalten.
Wenn ein OIDC-Client ein Zugangstoken oder ID-Token benötigt, sendet er eine Anfrage an den Token-Endpunkt mit einem Autorisierungsnachweis, der typischerweise ein Autorisierungscode oder ein Auffrischungstoken ist. Der Token-Endpunkt validiert dann den Autorisierungsnachweis und stellt dem Client ein Zugangstoken oder ID-Token aus, wenn der Nachweis gültig ist.
Weitere Informationen findest du unter 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 folgenden Bedingungen aus:
- Wenn das Auffrischungstoken rotiert wurde (seine TTL durch die Ausstellung eines neuen Tokens verlängert wurde) und dies seit einem Jahr geschieht; ODER
- Wenn das Auffrischungstoken kurz vor dem Ablauf steht (>=70 % seiner ursprünglichen Lebensdauer (TTL) sind vergangen); ODER
- Wenn der Client ein öffentlicher Client ist, z. B. Native Anwendung oder Single Page Application (SPA).
Für öffentliche Clients wird bei aktivierter Funktion immer ein neues Auffrischungstoken ausgestellt, wenn der Client mit dem Auffrischungstoken ein neues Zugangstoken anfordert. Obwohl du die Funktion für diese öffentlichen Clients deaktivieren kannst, wird dringend empfohlen, sie aus Sicherheitsgründen aktiviert zu lassen.
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.
Backchannel-Logout-URI
Der OpenID Connect Backchannel-Logout-Endpunkt. Siehe Federated sign-out: 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, wie z. B. geschäftsspezifische Einstellungen und Konfigurationen.