Podłącz OAuth2/OpenID w jądrze

OIDC over OAuth2 jest standardowym sposobem, aby dowieść, kim jest użytkownik/klient i dać krótkotrwały dostęp API. W centrum platformy staje się ona centralną zdolnością: jednorazowym uruchomieniem dla klientów, operatorów i usług; uprawnienia minimalne; mierzalne ryzyko; zgodność z przepisami regionalnymi i dotyczącymi licencjonowania.

1) Cele i zasady

Separacja „deploy vs enable”: rozwinąć kod oddzielnie, włączyć dostęp z flagami/zasadami.
Krótkotrwałe żetony + bezpieczna aktualizacja: zmniejszyć uszkodzenia z przecieków.
Najemca/region: wszystkie artefakty są oznaczone jako „najemca/region/licencja”.
Zasady na górze żetonów: rozwiązania są tworzone przez PDP (RBAC/ABAC), PEP na bramę/usługi.
Ochrona linków: TLS1. 2 +, mTLS/DPoP, jeśli to możliwe, ścisłe CORS/CSRF.
Obserwacja i audyt: widoczność przez strumień, przez klienta, przez region.

2) Przepływy i czas ich stosowania

Kod autoryzacji + PKCE (SPA/Mobile/Web) - domyślnie dla login użytkownika.
Autoryzacja urządzenia (konsole/TV/CLI) - gdy nie ma przeglądarki.
Uwierzytelnienia klienta (maszyna-maszyna) - integracja usług bez użytkownika.
Token Exchange (RFC 8693, OBO) - usługa działa w imieniu użytkownika.
CIBA/Back-channel (opcjonalnie) - push uwierzytelnianie bez przekierowania.

• PAR (Pushed Authorization Requests) - parametry autoryzacji są przesyłane przez bezpieczny kanał serwera.
• JWT Secured Authorization - Parametry żądań są podpisywane/szyfrowane.
• JARM - chroniona odpowiedź autoryzacyjna (JWT), odporna na spoofing.
• RAR (Rich Authorization Requests) - bogate żądania praw dostępu (szczegółowe uprawnienia).

3) Żetony i znaczki

• ID Token (OIDC) - kto wszedł (pokaż tylko klientowi/frontowi).
• Dostęp Token (AT) - prawo do działania (krótkie życie).
• Odśwież token (RT) - aktualizacje AT; jest przechowywany tylko w zaufanym środowisku.

• AT: 5-15 min (web/mobile), 2-5 min (service-to-service).
• RT: 7-30 дней (web/mobile)
• 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
}

Podpisanie: ES256/EdDSA, klucze publiczne - w JWKS z 'dzieciakiem' i rotacją.

4) Zarys sesji i wylogowanie

Sesja po stronie serwera (pliki cookie: ' Site = Lax/Strict', 'Only', 'Secure').
Back-Channel Logout + Front-Channel Logout (OIDC) - synchroniczne zakończenie wszystkich klientów.
MSZ Step-Up: z wrażliwymi działaniami - powtarzanie kontroli (wzrost „acr”).
Odwołanie i wprowadzenie: natychmiastowe wyłączenie RT/AT przez incydent.

5) Bezpieczeństwo klienta

Web/SPA: Kod autoryzacji + PKCE, nie jest dorozumiany; ścisła polityka CORS/Content-Security-Policy.
Telefon komórkowy: przeglądarka systemowa (AppAuth), kontrola integralności (App Attestation/ Check), bezpieczne przechowywanie RT.
Desktop/CLI/TV: Przepływ urządzenia; przechowywać RT w tajnych sklepach z systemem operacyjnym.
Żetony związane DPoP lub mTLS, aby powiązać AT z urządzeniem/połączeniem.

6) Usługi do obsługi

mTLS + short Service JWT (aud-scoped), wydania STS z KMS/HSM.
Tożsamość obciążeń roboczych: SPIFFE/SPIRE.

Wąska i szeroka polityka: zamiast tego konkretna publiczność i zakresy "

7) Zakres rejestracji i zgoda

Nazwa: 'resource: action' - 'portfel: read', 'portfel: transfer', 'bets: place', 'kyc: status'. odczytać ".

Skonfiguruj widoczność i czułość zakresów.
Ekran zgody jest montowany z RAR/Scopes; zachować historię zgody i zezwolić na opinie.

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

8) Integracja autoryzacji (PDP/PEP)

PEP w API Gateway zatwierdza AT/DPoP/mTLS, wzbogaca kontekst (IP/ASN/region/najemca), składa wniosek do PDP.
PDP (OPA/cedr) stosuje zasady RBAC/ABAC/ReBAC i zwraca "PERMIT/DENY 'z wyjaśnieniem i TTL.
Pamięć podręczna roztworu w PEP (TTL 30-120 s) z niepełnosprawnością według zdarzeń (zmiana roli/reguły).

9) Wieloosobowy najemca i regiony

Wszystkie żetony i sesje są oznaczone jako „najemca/region/licencja”; PDP zatwierdza zgodność zasobów.
Oddzielne JWKS/klucze i listy wycofania według regionu; cross-region - przez zaufane bramy.
Ograniczenia pobytu danych: Introspekcja/cofnięcie danych odbywa się w regionie pochodzenia.

10) Wzmacnianie protokołu

PAR + JAR + JARM - Chroń parametry autoryzacji i odpowiedzi.
Nonce/State/PKCE - dla wszystkich klientów publicznych.
Autoryzacja urządzenia pchanego (na wysokie ryzyko).
Żetony JWT z minimalnymi znaczkami + nieprzezroczystą opcją dla integracji zewnętrznych poprzez introspekcję.
Praktyki podobne do FAPI: ścisłe algorytmy podpisu, wymagania TLS/redirect_uri/PKCE.

11) Błędy i polityka powrotów

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'.
Limit szybkości dla wrażliwych punktów końcowych ('/token ', '/introspect', '/cofnij'), wykładnicze backoff.

12) Obserwowalność i audyt

• „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', 'deeny _ 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'.
Audyt (niezmienny): emisja żetonów, eskalacja praw, cofnięcie zgody, rotacja klucza.

13) Zarządzanie kluczem i rotacja

Podpis JWT: KMS/HSM, publikacja JWKS z „dzieckiem”.
Okres podwójny: IdP podpisuje nowe, recenzenci akceptują stare + nowe przed przełączeniem.
Regularny obrót i odwołanie awaryjne; monitorowanie konsumpcji „dzieci”.

14) Playbooks (książki startowe)

1. Kompromis klucza podpisu

Natychmiast odwołać „dziecko”, wydać nowy, siłowo-niepełnosprawny RT/sesje, raport z audytu.

2. Masa „nieprawidłowy _ token ”/wzrost 401

Sprawdź błędne ustawienie zegara, wygasł AT, złamany pamięć podręczna JWKS; tymczasowo zwiększyć tolerancję „zegar _ skew”.

3. Ponowne wykorzystanie RT

Zablokować sesję ('sid'), powiadomić użytkownika, poprosić o krok do nowego logowania, zbadać.

4. Spadek IdP

Włącz tryb autoryzacji tylko do odczytu: utrzymuj aktywne ATs do TTL, ograniczaj nowe logowania, skaluj pamięć podręczną introspekcji.

5. Atak na '/token '

Wzmocnienie limitu prędkości/filtrów bot, włączenie mTLS/DPoP dla wrażliwych klientów, przeniesienie zimnych RT do oddzielnego segmentu.

15) Badanie

Kontrakt: odkrycie OIDC, JWKS, dostawca OpenID config.
Bezpieczeństwo: PKCE/nonce/state są wymagane; zestawy ujemne (zamienniki „przekierowanie _ uri”, ponowne użycie RT).
Interoperacyjność: klienci (web/mobile/CLI), różne strefy czasowe/lokalizacje.
Chaos: awaria PAR/JARM, opóźnienie JWKS, obrócone „dziecko” na muchę.
E2E: step-up MFA, OBO (wymiana tokenów), logowanie (front/back-channel), cofnąć/obrócić.

16) Przykłady konfiguracji

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) Lista kontrolna przedsprzedaży

• PKCE/nonce/state enabled; PAR/JAR/JARM są aktywne.
• Zestaw AT/RT/TTL ID; Włączona rotacja RT + wykrywanie ponownego użycia.
• DPoP lub mTLS-binding dla wrażliwych klientów/operacji.
• JWKS c „dziecko”; automatyczne monitorowanie rotacji i zużycia klucza.
• Zgoda/RAR i rejestr zakresu; zwiększenie pomocy makrofinansowej w zakresie działań wrażliwych.
• Zintegrowane PDP/PEP, pamięć podręczna rozwiązań niepełnosprawności.
• Tokeny zawierają „najemcę/region/licencję”; Obserwuje się miejsce zamieszkania.
• Obserwowalność: mierniki, kłody, śledzenie; wpisy do 'invalid _ token', 'rt _ reuse', 'jwks _ skew'.
• Playbooks on cofnąć/rotate/lockdown; przycisk awaryjnego wylogowania.
• Zestaw E2E/chaos/interop testów został przekazany na stoiskach.

Wnioski

Osadzając OAuth2/OIDC jako możliwość platformy, otrzymujesz przewidywalne przepływy autoryzacji, żetony zarządzane, jednolite zasady dostępu i wymierne ryzyko. Krótkie ATs chronione przez RT, rotacja klucza, PAR/JARM/DPoP, zgoda i krok-up to praktyki, które sprawiają, że bezpieczeństwo jest domyślne, a ewolucja szybka i bezbolesna dla zespołów i partnerów.