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, das Benutzererlebnis 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. 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 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, bei der Seiten ausschließlich vom Webserver gerendert und aktualisiert werden. 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). Anstelle 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 Verwaltung von Anwendungen 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 geben, wie z. B. deren Zweck, 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 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 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 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 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 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 einem Autorisierungs-Grant, der typischerweise ein Autorisierungscode oder ein Auffrischungstoken ist. Der Token-Endpunkt validiert dann den Autorisierungs-Grant und stellt dem Client ein Zugangstoken oder ID-Token aus, wenn der Grant 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 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.
Auffrischungstoken rotieren
Standard: true
Wenn aktiviert, kann Logto ein neues Auffrischungstoken ausstellen, wenn ein Client ein Auffrischungstoken verwendet, um neue Tokens anzufordern. Wenn das Auffrischungstoken und sein App-Grant noch gültig sind, gilt die folgende Standard-Rotationsrichtlinie:
- 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 öffentliche Clients wird dringend empfohlen, die Auffrischungstoken-Rotation aus Sicherheitsgründen aktiviert zu lassen.
Sender-constrained Auffrischungstokens sind an einen vom Client gehaltenen Proof Key oder ein Zertifikat gebunden. Für reguläre SPAs gibt die Rotation ein neues Auffrischungstoken aus, verlängert jedoch nicht die Lebensdauer des Auffrischungstokens. Das neue Auffrischungstoken übernimmt die verbleibende TTL des vorherigen Auffrischungstokens.
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.
Auffrischungstoken-Rotation verstehen
Auffrischungstoken Time-to-Live (TTL) in Tagen
Verfügbarkeit: Native App, Traditionelle Web, SPA; Standard: 14 Tage; Maximum: 180 Tage
Die Dauer, für die ein Auffrischungstoken verwendet werden kann, um neue Zugangstokens anzufordern, bevor es abläuft und ungültig wird. Token-Anfragen verlängern die TTL des Auffrischungstokens auf diesen Wert.
Typischerweise wird ein niedrigerer Wert bevorzugt.
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.
Die Auffrischungstoken-TTL ist nicht die einzige Ablaufgrenze. 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.
Wenn ein Auffrischungstoken ohne die offline_access-Berechtigung 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 die offline_access-Berechtigung in deiner Autorisierungsanfrage enthalten ist.
Backchannel-Logout-URI
Der OpenID Connect Backchannel-Logout-Endpunkt. Siehe Federated sign-out: Back-channel logout für weitere Informationen.
Maximal erlaubte Grants (maxAllowedGrants)
maxAllowedGrants ist ein optionales App-Feld unter customClientMetadata, das die maximale Anzahl gleichzeitiger aktiver Grants pro Benutzer für die aktuelle App steuert.
- Standard:
undefined(kein Limit) - Wenn konfiguriert: Bei jeder erfolgreichen Autorisierung prüft Logto die Gesamtzahl der aktiven 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.
Dieses Feld wird nicht unterstützt für:
- Maschine-zu-Maschine-Apps
- Geschützte Apps
- SAML-Apps
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.