Zum Hauptinhalt springen

Organisation (Nicht-API) Berechtigungen schützen

Verwende die Organisation-Vorlage, um organisationsweite Rollen und Berechtigungen in Logto zu verwalten und durchzusetzen. So steuerst du den Zugriff auf In-App-Funktionen und Workflows im Kontext einer Organisation.

Was sind Organisation (Nicht-API) Berechtigungen?​

Organisationsberechtigungen (Nicht-API) steuern, was Benutzer im Kontext einer Organisation tun können, werden aber nicht auf API-Ebene durchgesetzt. Stattdessen regeln sie den Zugriff auf App-Funktionen, UI-Elemente, Workflows oder Geschäftsaktionen und nicht auf Backend-APIs.

Anwendungsfälle sind unter anderem

  • Mitglieder innerhalb einer Organisation einladen oder verwalten
  • Organisationsrollen zuweisen oder ändern
  • Abrechnung, Einstellungen oder administrative Funktionen für eine Organisation verwalten
  • Zugriff auf Dashboards, Analysen oder interne Tools, die keine API-Endpunkte haben

Logto ermöglicht es dir, diese Organisationsberechtigungen mit OAuth 2.1 und rollenbasierter Zugangskontrolle (RBAC) abzusichern und unterstützt dabei Multi-Tenant-SaaS-Architekturen.

Diese Berechtigungen werden über Organisationsrollen verwaltet, die in der Organisation-Vorlage definiert sind. Jede Organisation verwendet die gleiche Vorlage, was ein konsistentes Berechtigungsmodell über alle Organisationen hinweg sicherstellt.

So funktioniert es in Logto​

  • Organisationsebene RBAC: Rollen und Berechtigungen werden in der Organisation-Vorlage definiert. Wenn ein Benutzer einer Organisation beitritt, werden ihm eine oder mehrere Rollen zugewiesen, die bestimmte Berechtigungen gewähren.
  • Nicht-API-Durchsetzung: Berechtigungen werden in der UI deiner App, im Workflow oder in der Backend-Logik geprüft und durchgesetzt, nicht zwingend durch ein API-Gateway.
  • Trennung vom API-Schutz: Organisation (Nicht-API) Berechtigungen sind von API-Ressourcenberechtigungen getrennt. Du kannst beide für fortgeschrittene Szenarien kombinieren.
Organisation Berechtigungen RBAC

Überblick zur Implementierung​

  1. Definiere Organisationsberechtigungen in Logto unter der Organisation-Vorlage.
  2. Erstelle Organisationsrollen, die die notwendigen Berechtigungen für deine organisationsspezifischen Aktionen bündeln.
  3. Weise Rollen Benutzern oder Clients innerhalb jeder Organisation zu.
  4. Erhalte ein Organisationstoken (JWT) für die aktuelle Organisation entweder über das Auffrischungstoken oder den Client-Credentials-Flow.
  5. Validiere Zugangstokens in der UI oder im Backend deiner App, um Organisationsberechtigungen durchzusetzen.

Autorisierungsablauf: Authentifizierung und Absicherung von Organisationsberechtigungen​

Der folgende Ablauf zeigt, wie ein Client (Web, Mobile oder Backend) Organisationstokens für die Durchsetzung von Nicht-API-Berechtigungen erhält und verwendet.

Beachte, dass der Ablauf keine vollständigen Details zu den erforderlichen Parametern oder Headern enthält, sondern sich auf die wichtigsten Schritte konzentriert. Lies weiter, um zu sehen, wie der Ablauf in der Praxis funktioniert.

Benutzer-Authentifizierung = Browser/App. M2M = Backend-Service oder Skript mit Client-Credentials + Organisationskontext.

Implementierungsschritte​

Organisationsberechtigungen registrieren​

  1. Gehe zu Konsole → Organisation-Vorlage → Organisationsberechtigungen.
  2. Definiere die benötigten Organisationsberechtigungen (z. B. invite:member, manage:billing, view:analytics).

Für vollständige Konfigurationsschritte siehe Organisationsberechtigungen definieren.

Organisationsrollen einrichten​

  1. Gehe zu Konsole → Organisation-Vorlage → Organisationsrollen.
  2. Erstelle Rollen, die die zuvor definierten Organisationsberechtigungen bündeln (z. B. admin, member, billing).
  3. Weise diese Rollen Benutzern oder Clients innerhalb jeder Organisation zu.

Für vollständige Konfigurationsschritte siehe Organisationsrollen verwenden.

Organisationstokens (Nicht-API) erhalten​

Dein Client/App sollte ein Organisationstoken (Nicht-API) erhalten, um auf Organisationsberechtigungen zuzugreifen. Logto stellt Organisationstokens als JSON Web Tokens (JWTs) aus. Du kannst diese entweder über den Auffrischungstoken-Flow oder den Client-Credentials-Flow erhalten.

Auffrischungstoken-Flow​

Fast alle offiziellen Logto SDKs unterstützen das Abrufen von Organisationstokens über den Auffrischungstoken-Flow direkt. Eine Standard-OAuth 2.0 / OIDC-Client-Bibliothek kann ebenfalls verwendet werden, um diesen Flow zu implementieren.

Beim Initialisieren des Logto SDK füge urn:logto:scope:organizations und die gewünschten Organisationsberechtigungen (Berechtigungen) zum scopes-Parameter hinzu.

Einige Logto SDKs haben einen vordefinierten Scope für Organisationen, wie UserScope.Organizations in JavaScript SDKs.

hinweis:

Überprüfe den organizations-Anspruch im ID-Token, um eine Liste der Organisations-IDs zu erhalten, denen der Benutzer angehört. Dieser Anspruch listet alle Organisationen auf, bei denen der Benutzer Mitglied ist, was es einfach macht, Organisationen in deiner App aufzulisten oder zu wechseln.

Verwende getOrganizationToken oder eine ähnliche Methode (wie getAccessToken mit einer Organisations-ID), um ein Organisationstoken für eine bestimmte Organisation anzufordern.

Für Details zu jedem SDK siehe Quick starts.

Client-Credentials-Flow​

Für Maschine-zu-Maschine (M2M)-Szenarien kannst du den Client-Credentials-Flow verwenden, um ein Zugangstoken für Organisationsberechtigungen zu erhalten. Durch eine POST-Anfrage an Logtos /oidc/token-Endpunkt mit Organisationsparametern kannst du ein Organisationstoken mit deiner Client-ID und deinem Secret anfordern.

Hier sind die wichtigsten Parameter, die in der Anfrage enthalten sein sollten:

  • organization_id: Die ID der Organisation, für die du das Token möchtest.
  • scope: Die Organisationsberechtigungen, die du anfordern möchtest (z. B. invite:member, manage:billing).

Hier ist ein nicht-normatives Beispiel für die Token-Anfrage mit dem Client-Credentials-Grant-Typ:

POST /oidc/token HTTP/1.1
Host: your.logto.endpoint
Content-Type: application/x-www-form-urlencoded
Authorization: Basic base64(client_id:client_secret)

grant_type=client_credentials
&organization_id=your-organization-id
&scope=invite:member manage:billing

Organisationstokens validieren​

Von Logto ausgestellte Organisationstokens (JWTs) enthalten Ansprüche, die deine App/UI/Backend zur Durchsetzung des organisationsweiten Zugriffs verwenden kann.

Wenn deine App ein Organisationstoken erhält, solltest du:

  • Die Token-Signatur überprüfen (mit Logtos JWKs).
  • Prüfen, dass das Token nicht abgelaufen ist (exp-Anspruch).
  • Sicherstellen, dass der iss (Aussteller) mit deinem Logto-Endpunkt übereinstimmt.
  • Sicherstellen, dass der aud (Zielgruppe) mit dem formatierten Organisationsbezeichner übereinstimmt (z. B. urn:logto:organization:{organization_id}).
  • Den scope-Anspruch (durch Leerzeichen getrennt) auf erforderliche Berechtigungen prüfen.

Für Schritt-für-Schritt- und sprachspezifische Anleitungen siehe Wie man Zugangstokens validiert.

Best Practices und Sicherheitstipps​

  • Verlasse dich niemals ausschließlich auf die UI-Durchsetzung: Prüfe Berechtigungen für kritische Aktionen immer auch im Backend.
  • Verwende Zielgruppenbeschränkungen: Prüfe immer den aud-Anspruch, um sicherzustellen, dass das Token für die beabsichtigte Organisation ist.
  • Halte Berechtigungen geschäftsgetrieben: Verwende klare Namen, die echten Aktionen entsprechen; gewähre nur das, was für jede Organisationsrolle benötigt wird.
  • Trenne API- und Nicht-API-Berechtigungen, wo möglich (beide können aber in einer Rolle enthalten sein).
  • Überprüfe die Organisation-Vorlage regelmäßig, während sich dein Produkt weiterentwickelt.

FAQs​

Kann ich Organisations- und Nicht-Organisationsberechtigungen in einer Rolle mischen?​

Nein, Organisationsberechtigungen (einschließlich organisationsbezogener API-Berechtigungen) werden durch die Organisation-Vorlage definiert und können nicht mit globalen API-Berechtigungen gemischt werden. Du kannst jedoch Rollen erstellen, die sowohl Organisationsberechtigungen als auch organisationsbezogene API-Berechtigungen enthalten.

Wo sollte ich Nicht-API-Berechtigungen durchsetzen?​

Prüfe Nicht-API-Berechtigungen sowohl in der UI (für Feature-Gating) als auch in deiner serverseitigen Logik für sensible Aktionen.

Weiterführende Literatur​

Wie man Zugangstokens validiert Token-Ansprüche anpassen

Anwendungsfall: Multi-Tenant-SaaS-Anwendung bauen