Authentifizierung und Autorisierung

Die zuverlässige AuthN/AuthZ-Schleife ist ein einziger Punkt der Wahrheit darüber, wer Sie sind (Authentifizierung) und was Sie dürfen (Autorisierung). In einer Plattform mit vielen Marken, Regionen, Integrationen und hohen regulatorischen Anforderungen sollte diese Kontur modular sein, von Richtlinien überwacht und verwaltet werden und nicht als „Streuung von If-Ichs über Dienste“.

1) Grundlegende Begriffe und Rollen

Identifikation (ID): Identifizierung (User, Service, Provider).
Authentifizierung (AuthN): Identitätsnachweis (Passwort, MFA, Zertifikat).
Autorisierung (AuthZ): Entscheidung „kann/kann nicht“ basierend auf Richtlinien und Kontext.
PDP/PEP: Policy Decision Point (entscheidet )/Policy Enforcement Point (wendet an).
IdP: Identity Provider (OIDC).
Thema/Ressource/Aktion/Kontext: wer/zu was/was tut/unter welchen Bedingungen.

2) Allgemeine Konturarchitektur

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

Prinzipien: Zentralisierung der Generierung von Token und Richtlinien, lokale Anwendung; „Mindestprivilegien“ und explizite Delegationen.

3) Benutzerauthentifizierung (OIDC/OAuth 2. 1)

• Autorisierungscode + PKCE (immer für SPA/Mobile).
• SSO: Unterstützung externer IdPs (SAML/OIDC) für b2b/Operatoren.
• MFA: TOTP/WebAuthn/SMS (empfohlen von WebAuthn und TOTP; SMS — fallback).
• Risikobasiertes Step-Up: bei sensiblen Aktionen (Auszahlungen, Änderung von Details) MFA/pe-Auth verlangen.

• Refresh Token Rotation + RT-Registry mit Wiederverwendungsdetail.
• Nonce/State + PKCE, strenge CORS/CSRF für Browser-Streams.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Gerätebindung (DPoP/mtls-bound tokens) für kritische Operationen.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) Service-Service-Authentifizierung (mTLS, SPIFFE, JWT)

mTLS zwischen den Diensten + SPIFFE/SPIRE für stabile Workload-IDs.
Service JWT mit kurzer Laufzeit (≤5 min), signiert von HSM/KMS; Prüfung der Ausstellung.
Audience-scoped: JWT ist nur für einen bestimmten Dienst/eine bestimmte Domain geeignet.
Vertrauenszonen: Dienste aus einer anderen Region/Tenant - einzelne PKIs und Richtlinien.

5) Autorisierungsmodelle: RBAC, ABAC, ReBAC

RBAC (Rollen → Auflösung): einfach und transparent (geeignet für Admin-Panels, Operatoren).
ABAC (Subjekt/Ressource/Kontext Attribute): flexibel für Regeln "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (Relations): nützlich für komplexe Bestände („wer besitzt die Marke/den Ordner/die Kampagne“).

Empfehlung: hybrid - basic RBAC + context ABAC-conditions + point ReBAC-relations.

6) Richtlinien und deren Umsetzung (PDP/PEP)

PEP auf dem Gateway und in den Diensten: ruft den Kontext ab (JWT, Mandate, IP/ASN, Zeit, Region, KYC-Schicht), bildet eine Anfrage an den PDP.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

und gibt 'ALLOW/DENY' + Erklärung zurück.

Der Entscheidungscache in PEP (TTL 30-120 c) reduziert die Latenz; Behinderung durch Ereignisse „Rollenwechsel/Richtlinien“.

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) Scopes und Genehmigungen

• Ressource: Aktion - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.
• Für Admins ist 'admin:' in einer isolierten Domäne.
• Für Anbieter - 'provider: report. read`, `provider:events. push`.

Prinzip der Mindestprivilegien: Wir weisen nur die notwendigen Skopi zu; „Eskalationen“ (temporäre Erweiterungen) - per Ticket und mit TTL.

8) Multi-Tenant und Regionen (residency)

Token enthalten 'tenant', 'region', 'licence'; PDP überprüft die Übereinstimmung mit der Ressource.
Rollen/Richtlinien - Namespaces per tenant ('role: brand _ eu/support').
Unterteilung von Signaturschlüsseln und Sperrlisten nach Regionen; cross-regionale Anfragen - nur über Trusted Gateways.

9) Verwalten von Sitzungen und Geräten

Server-Side Session Store für Web (Bindung an Gerät/Browser, ID-Rotation).
Idle/Absolute Timeout (z.B. 30 min/24 h); sensibles Handeln - re-Auth/MFA.
Auflistung der aktiven Geräte, „out of all“.
Anomalien: gleichzeitige Eingaben aus verschiedenen Regionen, häufige MFA-Ausfälle - Risikosignale.

10) Delegation und Zustimmung (consent)

On-behalf-of (OBO): Der Dienst handelt im Namen des Benutzers (Proxy-Token mit separatem 'sub '/' act').
Zustimmung: expliziter Bildschirm für den Zugriff des Partners auf die Daten, Protokoll der Zustimmung zum Widerruf.
Temporäre Zugriffsmandate: Rechte für N Stunden/Tage, verfallen automatisch.

11) Schlüssel, Unterschriften und Rotation

JWKS mit 'kid', automatische Rotation, private Schlüsselspeicherung im KMS/HSM.
Algorithmen: ES256/EdDSA für JWT; TLS 1. 2+/mTLS.
Dual-Key-Periode: Akzeptieren Sie beide „Kinder“, bis das Client-Update abgeschlossen ist.
Rückruf von RT und Token Introspection für kritische Vorfälle.

12) Sicherheit von Client-Anwendungen

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobil: App Attestation/Device Check, sicherer RT-Speicher, Root/Jailbreak-Schutz.
Desktop: System-Browser für Login (keine embedded Web-Views), PKCE.

13) Benutzerfreundliche SDK-Verträge

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

14) Beobachtbarkeit und Auditierung

• `authn_success_rate`/`mfa_challenge_rate`/`mfa_fail_rate`
• `authz_p95_ms`, `authz_denied_rate{reason}`
• `invalid_token_rate`, `jwks_skew_ms`, `rt_reuse_detected`
• Anomalien der Eingänge (neues Gerät, Geo-Velocity), verdächtige Scopes.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Export für Compliance (Regulator/Vendor-Audit).

15) Perimeter- und Kundenschutz

Gateway PEP: rate-limit, bot/signature checks, CSRF-protection, strict CORS, HSTS.
Interner Datenverkehr: mTLS + Service JWT + begrenzte Netzwerke.
Webhooks/externe Collbacks: Körpersignaturen (HMAC/JWS), Zeitfenster, Anti-Replays.

16) Typische Fehler

Langlebige Access-Token → Lecks.
Implizite OAuth-Strömung im SPA.
Keine Rotation der Schlüssel und Dual-Key-Periode.
Beißende Rollen statt Richtlinien (es ist unmöglich, Entscheidungen zu prüfen/zu erklären).
Mischen von Tenanten/Regionen in einer 'Rolle' oder 'Schlüssel'.
Kein Step-up-MFA bei sensiblen Aktionen.
AuthZ-Entscheidungscache ohne Behinderung bei Rollenänderungen.

17) Playbooks (Runbooks)

1. Kompromittierung des JWT-Signaturschlüssels

Sofortige revoke' kid', Veröffentlichung eines neuen JWKS, erzwungene Behinderung von RT/Sitzungen, Bericht an das Audit.

2. Masse' invalid _ token '

Überprüfen Sie die Synchronisation der Uhr/Lebensdauer, JWKS-Relevanz, Cache-Abstürze.

3. Anomalien der Eingänge

Aktivieren Sie ein erhöhtes Risiko-Scoring, fordern Sie ein Step-up, benachrichtigen Sie den Benutzer, begrenzen Sie die Auszahlungen vorübergehend.

4. IdP fehlgeschlagen

Wechseln Sie zum Sitzungscache/Rollengerät, beschränken Sie neue Logins, halten Sie aktuelle Sitzungen auf TTL.

18) Checkliste vor dem Verkauf

• OIDC/OAuth 2. 1 mit PKCE, kurze AT, RT Rotation, Gerätebindung für kritische Operationen.
• MFA (WebAuthn/TOTP) und Step-up für Leads/Requirements Change/Rolle-Eskalationen.
• Service-to-Service: mTLS + SPIFFE, kurzlebige Service-JWTs.
• AuthZ-Richtlinien (RBAC + ABAC/ReBAC) in einem zentralisierten PDP; PEP am Gateway und in den Services.
• Lösungs-Cache mit Behinderung; audit trail ist unveränderlich.
• Multi-Tenant/Regionen: Isolierung von Schlüsseln/Richtlinien/Protokollen, Lizenzbuchhaltung.
• JWKS/Schlüssel in KMS/HSM, Dual-Key Rotation, Überwachung 'kid'.
• CSRF/CORS/HSTS/Rate-Limit/Bot-Filter am Perimeter.
• Incident playbooks, run buttons revoke/rotate/lockdown.
• Test Set: unit (policies), contract (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Mini-Konfigurationsvorlagen

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

Schlussfolgerung

Die Authentifizierungs- und Autorisierungsschleife ist keine Bibliothek, sondern eine Plattformfähigkeit: kurzlebige Token und verwaltete Schlüssel, zentralisierte Richtlinien und ihre lokale Anwendung, Multifaktor und Step-up, strikte Isolierung von Tenanten/Regionen, Audit und Telemetrie. Dieses Design macht Änderungen sicher, für die Regulierungsbehörde erklärbar und für das Produkt transparent - und die Skalierung über Märkte und Teams hinweg wird eher zu einer Routineoperation als zu einem Kunststück.