OAuth2/OpenID Connect im Kernel

OIDC auf der OAuth2 ist der Standardweg, um zu beweisen, wer der Benutzer/Kunde ist, und um einen kurzlebigen API-Zugriff zu gewähren. Im Kern der Plattform wird es zu einer zentralen Fähigkeit: Single Sign-On für Kunden, Betreiber und Dienste; Mindestprivilegien; messbares Risiko; Einhaltung der regionalen und lizenzrechtlichen Bestimmungen.

1) Ziele und Grundsätze

Trennung „deploy vs enable“: Wir rollen den Code separat aus, aktivieren den Zugriff mit Flags/Richtlinien.
Kurzlebige Token + sicheres Update: Reduzieren Sie Schäden bei Lecks.
Multi-Tenant/Region: Alle Artefakte werden mit 'tenant/region/licence' beworfen.
Richtlinien über Token: Lösungen werden von PDP (RBAC/ABAC), PEP auf Gateway/Diensten gemacht.
Kanalschutz: TLS1. 2 +, möglichst mTLS/DPoP, strenge CORS/CSRF.
Beobachtbarkeit und Auditierung: Sichtbarkeit durch den Fluss, durch den Kunden, durch die Region.

2) Ströme und wann sie anzuwenden sind

Authorization Code + PKCE (SPA/Mobile/Web) - Standard für Benutzeranmeldungen.
Geräteautorisierung (Konsolen/TV/CLI) - wenn kein Browser vorhanden ist.
Client Credentials (Machine-to-Machine) - Service-Integrationen ohne Benutzer.
Token Exchange (RFC 8693, OBO) - Der Dienst handelt im Namen des Benutzers.
CIBA/Back-Channel (optional) - Push-Authentifizierung ohne Umleitung.

• PAR (Pushed Authorization Requests) - Autorisierungsparameter werden über einen sicheren Serverkanal übertragen.
• JAR (JWT Secured Authorization) - Anforderungsparameter sind signiert/verschlüsselt.
• JARM ist eine sichere Autorisierungsantwort (JWT), die gegen Spoofing resistent ist.
• RAR (Rich Authorization Requests) - Umfangreiche Anfragen nach Zugriffsrechten (detaillierte Berechtigungen).

3) Token und Stempel

• ID Token (OIDC) - wer sich angemeldet hat (nur Client/Front anzeigen).
• Access Token (AT) - Recht auf Handlung (kurzes Leben).
• Refresh Token (RT) - Aktualisiert AT; wird nur in einer vertrauenswürdigen Umgebung gespeichert.

• AT: 5-15 Min. (Web/Mobile), 2-5 Min. (Service-to-Service).
• RT: 7–30 дней (web/mobile) с rotation + reuse detection.
• ID: ≤ 5 min.

json
{
"iss":"https://auth. core",
"sub":"user_42",
"aud":["wallet","catalog"],
"exp":1730388600,"iat":1730388000,
"tenant":"brand_eu","region":"EE","licence":"EE-A1",
"scp":["wallet:read","bets:place"],     // scopes
"sid ": "sess _ abcd, ""amr": [" pwd,"" webauthn"] ,//login methods
"act":{"sub":"svc. catalog" }//if OBO
}

Signieren: ES256/EdDSA, öffentliche Schlüssel - bei JWKS mit 'kid' und Rotation.

4) Sitzungsumrisse und Logout

Server-side session для web (cookie `SameSite=Lax/Strict`, `HttpOnly`, `Secure`).
Back-Channel Logout + Front-Channel Logout (OIDC) - synchrone Terminierung aller Clients.
Step-Up MFA: bei sensiblen Aktionen - erneute Überprüfung ('acr' steigt).
Revocation & Introspection: Sofortige Deaktivierung von RT/AT für den Vorfall.

5) Sicherheit der Kunden

Web/SPAs: Autorisierungscode + PKCE, kein Implizit; strenge CORS/Content-Security-Policy.
Mobile: System-Browser (AppAuth), Integritätsprüfung (App Attestation/DeviceCheck), sicherer RT-Speicher.
Desktop/CLI/TV: Device Flow; Speichern Sie RT in OS-Secret-Speichern.
DPoP oder mTLS-gebundene Token, um den AT an das Gerät/die Verbindung zu binden.

6) Service-zu-Service

mTLS + kurz Service JWT (aud-scoped), gibt STS mit KMS/HSM aus.
Workload-Identitäten: SPIFFE/SPIRE.
Politik "von schmal zu breit": konkretes Publikum und Scopes statt ".

7) Scope-Register und Zustimmung (consent)

Benennung: 'Ressource: Aktion' - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.

Konfigurieren Sie die Sichtbarkeit und Empfindlichkeit von Scopes.
Consent Bildschirm wird von RAR/Scopes gesammelt; Speichern Sie eine Zustimmungshistorie und erlauben Sie einen Widerruf.

json
{
"type":"wallet. transfer",
"actions":["create"],
"locations":["https://api. core/wallet"],
"datatypes":["payment"],
"resources":[{"wallet_id":"w_123","currency":"EUR","amount_max":1000}]
}

8) Integration mit Berechtigung (PDP/PEP)

PEP auf API Gateway validiert AT/DPoP/mTLS, bereichert den Kontext (IP/ASN/region/tenant), stellt eine Anfrage an PDP.
PDP (OPA/cedar) wendet RBAC/ABAC/ReBAC-Richtlinien an und gibt 'ALLOW/DENY' mit Erklärung und TTL zurück.
Entscheidungscache bei PEP (TTL 30-120 s) mit Behinderung durch Ereignisse (Rollen-/Regelwechsel).

9) Multi-Tenant und Regionen

Alle Token und Sessions sind mit 'tenant/region/licence' gekennzeichnet; PDP validiert die Einhaltung der Ressource.
Getrennte JWKS/Schlüssel und Abruflisten nach Region; cross-region - über vertrauenswürdige Gateways.
Einschränkungen der Datenresidenz: Die Introspektion/Revokation erfolgt in der Herkunftsregion.

10) Protokollverstärkungen

PAR + JAR + JARM - Schützen Sie Autorisierungsparameter und -antworten.
Nonce/State/PKCE - für alle öffentlichen Kunden.
Pushed Device Authorization (bei hohem Risiko).
JWT Access Tokens mit minimaler Branding + opaque Option für externe Integrationen durch Introspektion.
FAPI-ähnliche Praktiken: strenge Signaturalgorithmen, Anforderungen an die TLS/redirect_uri/PKCE.

11) Fehler und Rückgaberichtlinien

json
{ "error":"invalid_grant", "error_description":"refresh token reused", "error_code":"RT_REUSE" }

Критичные коды: `invalid_request`, `invalid_client`, `invalid_grant`, `invalid_scope`, `unauthorized_client`, `access_denied`, `temporarily_unavailable`.
Rate-Limit für empfindliche Endpunkte ('/token', '/introspect', '/revoke'), exponentieller Backoff.

12) Beobachtbarkeit und Audit

• `auth_code_success_rate`, `pkce_missing_rate`, `mfa_challenge/fail_rate`,
• `token_issuance_p95_ms`, `jwks_skew_ms`, `invalid_token_rate`, `rt_reuse_detected`,
• по API: `authz_p95_ms`, `deny_rate{reason}`, `dpop_mismatch_rate`, `mtls_fail_rate`.

Логи/трейсы: `client_id`, `grant_type`, `kid`, `acr/amr`, `tenant/region`, `decision`, `policy_version`, `aud`, `scp`, `sid`, `trace_id`.
Audit (unveränderlich): Ausgabe von Token, Eskalation von Rechten, Widerruf von Einwilligungen, Schlüsselrotation.

13) Schlüsselverwaltung und Rotation

JWT-Signatur: KMS/HSM, JWKS-Publikation mit 'kid'.
Dual-Key-Periode: IdP signiert neu, Prüfer akzeptieren alt + neu vor dem Wechsel.
Regelmäßige Rotation und Notfall-Revoke; Überwachung des Verbrauchs von "kid'.

14) Playbooks (Runbooks)

1. Kompromittierung des Signaturschlüssels

Sofort revoke' kid', veröffentlichen Sie eine neue, höhere Behinderung RT/Sitzungen, Audit-Bericht.

2. Masse' invalid _ token '/Wachstum 401

Überprüfen Sie die Synchronisierung der Uhr, abgelaufenes AT, gebrochener JWKS-Cache; den Tolerance' clock _ skew 'vorübergehend erhöhen.

3. Wiederverwendung von RT

Sperren Sie die Sitzung ('sid'), benachrichtigen Sie den Benutzer, fordern Sie ein Step-up für eine neue Anmeldung, Untersuchung.

4. Der Fall des IdP

Aktivieren Sie den Modus „Read-Only-Autorisierung“: Halten Sie die aktuellen ATs auf TTL, beschränken Sie neue Logins, verteilen Sie den Introspektionscache.

5. Angriff auf '/token '

Verstärken Sie Rate-Limit/Bot-Filter, aktivieren Sie mTLS/DPoP für empfindliche Kunden, nehmen Sie „kalte“ RTs in ein separates Segment.

15) Testen

Contract: OIDC discovery, JWKS, OpenID provider config.
Sicherheit: PKCE/nonce/state sind erforderlich; negative-sets (Substitutionen 'redirect _ uri', reuse RT).
Interoperabilität: Kunden (Web/Mobile/CLI), verschiedene Zeitzonen/Locales.
Chaos: PAR/JARM-Ausfall, JWKS-Verzögerungen, rotiertes' Kind'„on the fly“.
E2E: step-up MFA, OBO (token exchange), logout (front/back-channel), revoke/rotate.

16) Beispiele für Konfigurationen

yaml issuer: https://auth. core jwks:
rotation_days: 30 alg: ES256 tokens:
access_ttl: 10m refresh_ttl: 14d id_ttl: 5m policies:
require_pkce: true require_par: true require_jarm: true dpop_enabled: true mfa_step_up:
actions: ["wallet:transfer","payout:initiate"]
tenancy:
include_claims: ["tenant","region","licence"]
jwks_per_region: true

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

17) Checkliste vor dem Verkauf

• PKCE/nonce/state enthalten; PAR/JAR/JARM sind aktiv.
• AT/RT/ID TTL angegeben; RT Rotation + Reuse Detection aktiviert.
• DPoP oder mTLS-Bindung für sensible Kunden/Betriebe.
• JWKS c `kid`; automatische Rotation und Überwachung des Schlüsselverbrauchs.
• Consent/RAR und Scope-Register; Step-up MFA für sensibles Handeln.
• PDP/PEP integriert, Lösungscache mit Behinderung.
• Token enthalten 'tenant/region/licence'; Die Residency wird eingehalten.
• Beobachtbarkeit: Metriken, Protokolle, Trace; alert auf 'invalid _ token', 'rt _ reuse', 'jwks _ skew'.
• Playbooks auf revoke/rotate/lockdown; Notfalllogout-Taste.
• Eine Reihe E2E/chaos/interop Tests wurde an den Ständen bestanden.

Schlussfolgerung

Durch die Integration von OAuth2/OIDC als Plattformfähigkeit erhalten Sie vorhersehbare Autorisierungsströme, verwaltete Token, einheitliche Zugriffsrichtlinien und messbare Risiken. Kurze ATs, geschützt durch RT, Schlüsselrotation, PAR/JARM/DPoP, Zustimmung und Step-up sind Praktiken, die Sicherheit standardmäßig und Evolution für Teams und Partner schnell und schmerzlos machen.