Kernkonzepte

Diese Seite definiert die Kernkonzepte in Auris. Jeder Begriff wird im Kontext seiner Verwendung in Auris erklärt — nicht als allgemeine Branchendefinition. Wenn du neu im Bereich Identity and Access Management bist, erleichtert das Lesen dieser Seite vor den Anleitungen das Verständnis der restlichen Dokumentation.

Tenant

Eine isolierte Umgebung in Auris. Jede Konfiguration, jeder Benutzer, jede Anwendung, Rolle und Richtlinie gehört zu einem Tenant. Tenants können keine Daten teilen — ein Benutzerkonto in Tenant A kann sich nicht bei einer in Tenant B registrierten Anwendung authentifizieren.

Intern entspricht jeder Tenant einem Keycloak-Realm. Keycloak erzwingt Realm-Isolation auf Ebene des Identitätsspeichers.

In API-Anfragen wird der aktive Tenant über den x-tenant-Header identifiziert. SDKs setzen diesen automatisch basierend auf der domain, die du bei der Initialisierung konfigurierst.

Single-Tenant-Bereitstellungen verwenden einen einzigen Tenant (üblicherweise 'default'). Multi-Tenant-SaaS-Produkte erstellen einen Tenant pro Kundenorganisation — dies unterscheidet sich von Auris’ eigenem Organization-Konzept, das eine B2B-Gruppierung innerhalb eines einzigen Auris-Tenants darstellt.

Anwendung

Ein bei Auris registrierter Client. Jede Software, die Auris-Authentifizierung verwendet, muss als Anwendung registriert werden. Eine Anwendung hat:

• Eine eindeutige Client-ID (öffentliche Kennung, sicher für Browser-Code)
• Ein optionales Client-Secret (privat, nur für serverseitige M2M-Clients)
• Eine Liste erlaubter Weiterleitungs-URIs (exakt durchgesetzt — keine Wildcards)
• Einen Anwendungstyp, der bestimmt, welche OAuth 2.0-Flows verfügbar sind

Anwendungstypen:

Anwendungen können mit benutzerdefinierten JWT-Claims konfiguriert werden — zusätzliche Daten, die in für diese Anwendung ausgestellte Access Tokens eingebettet werden, ohne einen zusätzlichen API-Aufruf zu benötigen.

Benutzer

Eine von Auris innerhalb eines Tenants verwaltete Identität. Benutzer haben:

• Eine eindeutige ID (sub-Claim in JWTs)
• Eine E-Mail-Adresse (primäre Kennung)
• Optionalen Benutzernamen, Vor- und Nachname sowie Telefonnummer
• Eine oder mehrere Rollen (über Rollenzuweisungen)
• Optionale Berechtigungsüberschreibungen (ALLOW oder DENY für bestimmte Berechtigungen, unabhängig von Rollen)
• Eine oder mehrere Authentifizierungsmethoden (Passwort, Social-Konten, Passkeys usw.)
• Optionale 2FA-Konfigurationen (TOTP, SMS, WebAuthn)

Benutzer werden in Keycloak (für die Authentifizierung) gespeichert und in der Auris Prisma-Datenbank gespiegelt (für RBAC-Metadaten, Einstellungen und erweiterte Profildaten).

Rolle

Eine benannte Sammlung von Berechtigungen. Benutzern werden Rollen zugewiesen; Rollen definieren, was diese Benutzer tun dürfen. Rollen sind auf einen Tenant beschränkt.

Ein Benutzer kann mehrere Rollen haben. Bei einer Berechtigungsprüfung werden alle Rollen ausgewertet — wenn eine Rolle ALLOW gewährt und keine DENY, wird die Berechtigung gewährt.

Rollen können hierarchisch sein (über INHERIT-Berechtigungswerte). Eine Basis-user-Rolle könnte Lesezugriff auf die meisten Ressourcen gewähren, während eine admin-Rolle darüber hinaus Schreibzugriff hinzufügt.

Rollen können auch anwendungsbezogen sein — derselbe Benutzer kann in verschiedenen bei Auris registrierten Anwendungen unterschiedliche Rollen (und damit unterschiedliche Berechtigungen) haben.

Berechtigung

Eine Fähigkeit, dargestellt als aktion:ressource-Zeichenkette. Beispiele:

• manage:users — vollständiger CRUD-Zugriff auf Benutzer
• view:invoices — Lesezugriff auf Rechnungen
• approve:expenses — Fähigkeit, Spesenberichte zu genehmigen
• create:tickets — Fähigkeit, Support-Tickets zu erstellen
• export:payments — Fähigkeit, Zahlungsdaten zu exportieren

Berechtigungen haben dreistufige Werte:

DENY gewinnt immer über ALLOW. Wenn ein Benutzer Rolle A mit ALLOW auf eine Berechtigung und Rolle B mit DENY auf dieselbe Berechtigung hat, wird der Zugriff verweigert.

Access Token

Ein kurzlebiges JWT (JSON Web Token), das die Identität des Benutzers beweist und seine Berechtigungen enthält. Access Tokens sind:

• Mit RS256 (RSA + SHA-256) mit dem privaten Schlüssel von Auris signiert
• Von jedem Dienst mit Zugriff auf den öffentlichen JWKS-Endpunkt von Auris verifizierbar
• Im Authorization: Bearer <token>-HTTP-Header an geschützte APIs gesendet
• Kurzlebig (Standard: 15 Minuten — pro Tenant konfigurierbar)

Refresh Token

Ein langlebiges opakes Token, das zum Abrufen neuer Access Tokens nach deren Ablauf verwendet wird. Refresh Tokens sind:

• Opak — zufällige Zeichenketten, keine JWTs
• Langlebig (Standard: 7 Tage — pro Tenant konfigurierbar)
• Einmalig — bei jeder Verwendung wird ein neues ausgegeben und das alte invalidiert (Rotation)
• Sicher gespeichert — SDKs speichern Refresh Tokens in httpOnly-Cookies oder verschlüsseltem Storage

ID Token

Ein OpenID Connect (OIDC)-Token mit den Profilinformationen des authentifizierten Benutzers. ID Tokens sind:

• JWTs, signiert mit RS256 wie Access Tokens
• Zusammen mit dem Access Token beim Authorization-Code-Austausch ausgestellt
• Für die Client-Anwendung gedacht, um Benutzerinformationen anzuzeigen (Name, E-Mail, Avatar)
• Nicht an APIs gesendet — APIs sollten den Access Token verwenden, nicht den ID Token

PKCE

Proof Key for Code Exchange (RFC 7636). Eine Sicherheitserweiterung des OAuth 2.0 Authorization Code-Flows, die Autorisierungscode-Abfangangriffe verhindert.

Ablauf:

1. Vor der Weiterleitung zum Login generiert der Client einen zufälligen code_verifier und berechnet code_challenge = base64url(SHA256(code_verifier)).
2. Die code_challenge wird mit der Autorisierungsanfrage gesendet.
3. Nach der Authentifizierung leitet Auris mit dem Autorisierungscode zurück.
4. Beim Eintauschen des Codes gegen Tokens sendet der Client den ursprünglichen code_verifier.
5. Auris berechnet die Challenge neu und verifiziert die Übereinstimmung.

Auris erzwingt S256 (SHA-256-Hashing) — plain PKCE wird nicht akzeptiert. Alle Auris-SDKs übernehmen PKCE automatisch.

RBAC

Role-Based Access Control (Rollenbasierte Zugriffskontrolle). Das Berechtigungsmodell, bei dem:

• Benutzern Rollen zugewiesen werden
• Rollen Berechtigungen haben
• Berechtigungen den Zugriff auf Aktionen und Ressourcen steuern

In Auris ist RBAC als Schicht 2 des dreistufigen Autorisierungsmodells implementiert.

FGA

Fine-Grained Authorization (Feingranulare Autorisierung). Ein Zanzibar-ähnliches beziehungsbasiertes Zugriffssteuerungssystem für Berechtigungen auf Objektebene. FGA beantwortet die Frage: „Kann dieser spezifische Benutzer auf dieses spezifische Objekt zugreifen?”

FGA verwendet drei Kernkonzepte:

• Autorisierungsmodell — ein Schema, das Objekttypen und Beziehungen definiert
• Beziehungs-Tuples — in der Datenbank gespeicherte Fakten
• Check — eine rekursive Abfrage, die bestimmt, ob ein Subjekt eine Beziehung zu einem Objekt hat

FGA ist als Schicht 3 implementiert und ersetzt die Ory Keto-Integration, wenn aktiviert (FGA_ENGINE_ENABLED=true).

SSO

Single Sign-On (Einmaliges Anmelden). Ein Mechanismus, der es Benutzern ermöglicht, sich einmalig bei einem Identitätsanbieter zu authentifizieren und automatisch auf mehrere Anwendungen zuzugreifen.

Auris unterstützt zwei SSO-Protokolle:

• SAML 2.0 — XML-basiertes Protokoll, weit verbreitet bei Enterprise-IdPs (Okta, Azure AD, ADFS)
• OIDC (OpenID Connect) — modernes JSON-basiertes Protokoll. Verwendet von Google Workspace, Microsoft Entra ID und anderen.

SCIM

System for Cross-domain Identity Management (RFC 7643/7644). Ein Standardprotokoll für automatisierte Benutzerbereitstellung und -deaktivierung.

Mit aktiviertem SCIM:

• Wenn HR einen neuen Mitarbeiter in Okta oder Azure AD anlegt, wird der Benutzer automatisch in Auris bereitgestellt.
• Wenn ein Mitarbeiter das Unternehmen verlässt, wird sein Auris-Konto automatisch deaktiviert.

M2M

Machine-to-Machine. Server-zu-Server-Authentifizierung ohne menschliche Benutzer. M2M-Authentifizierung verwendet den OAuth 2.0 Client Credentials Grant.

MFA

Multi-Factor Authentication (Multi-Faktor-Authentifizierung). Auris unterstützt drei MFA-Methoden:

Adaptives MFA eskaliert automatisch zu zusätzlichen Faktoren bei erkannten Risikosignalen.

Actions

Benutzerdefinierte JavaScript-Funktionen, die während Authentifizierungs-Flows in einer Sandbox-Umgebung ausgeführt werden. Actions ermöglichen die Erweiterung von Auris’ Verhalten ohne Forking der Plattform.

Organisation

Eine B2B-Entität innerhalb eines Tenants. Organisationen werden verwendet, wenn du ein Produkt an andere Unternehmen verkaufst — jeder deiner Kunden wird als Organisation modelliert.

Jede Organisation hat:

• Eine Liste von Mitgliedern mit Rollen (OWNER, ADMIN, MEMBER, VIEWER)
• Eine optionale Enterprise SSO-Verbindung (SAML oder OIDC)
• Einladungsworkflows — E-Mail-Einladungen an neue Mitglieder senden
• Domänenbasierte SSO-Erkennung — automatische Weiterleitung zum IdP

Benutzerdefinierte Domain

Eine Funktion, mit der du die gehosteten Auris-Login-Seiten von deiner eigenen Domain aus bereitstellen kannst (z. B. auth.ihrunternehmen.com). Auris übernimmt die SSL-Zertifikatsbereitstellung automatisch.

Webhook

Ein HTTP-Callback, den Auris an deinen Server sendet, wenn bestimmte Ereignisse eintreten. Webhooks sind mit HMAC-SHA256 signiert. Über 180 Ereignistypen werden unterstützt.

OIDC Discovery

Der Standardmechanismus für OIDC-Clients, um die Konfiguration eines Identitätsanbieters zu entdecken. Auris veröffentlicht sein OIDC-Discovery-Dokument unter:

GET /.well-known/openid-configuration