Uwierzytelnianie i autoryzacja

Niezawodna pętla AuthN/AuthZ jest jednym punktem prawdy o tym, kim jesteś (uwierzytelnianie) i co można zrobić (autoryzacja). Na platformie z wieloma markami, regionami, integracjami i wysokimi wymaganiami regulacyjnymi, ten kontur powinien być modułowy, obserwowany i zarządzany przez polityków, a nie „rozpraszanie danych o usługach”.

1) Podstawowe terminy i role

Identyfikacja (ID): identyfikacja (użytkownik, usługodawca, usługodawca).
Uwierzytelnianie (AuthN): dowód tożsamości (hasło, MFA, certyfikat).
Autoryzacja (AuthZ) -Policy i oparty na kontekście może/nie może zdecydować.
PDP/PEP: Point Decision/Policy Enforcement Point.
IdP: dostawca tożsamości (OIDC).
Temat/Zasoby/Działanie/Kontekst: kto/co/co robi/na jakich warunkach.

2) Ogólna architektura pętli

[ 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)

Zasady: centralizacja żetonu i tworzenia polityki, stosowanie lokalne; „minimalne przywileje” i wyraźne delegacje.

3) Uwierzytelnianie użytkownika (OIDC/OAuth 2. 1)

• Kod autoryzacji + PKCE (zawsze dla SPA/Mobile).
• SSO: zewnętrzne wsparcie IdP (SAML/OIDC) dla b2b/operatorów.
• MSZ: TOTP/WebAuthn/SMS (zalecane przez WebAuthn i TOTP; SMS - fallback).
• Krok w górę oparty na ryzyku: w przypadku działań wrażliwych (wycofanie środków, zmiana szczegółów) wymagane jest MFA/pe-Auth.

• Odświeżenie rejestru Token Rotation + RT z wykrywanym ponownym użyciem.
• Nonce/State + PKCE, ścisły CORS/CSRF dla strumieni przeglądarki.
• Żetony dostępu krótkotrwałego (5-15 мий) + ciche odświeżenie/RT.
• Wiązanie urządzenia (żetony związane DPoP/mtls) do operacji krytycznych.

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) Uwierzytelnianie usługi (mTLS, SPIFFE, JWT)

mTLS między usługami + SPIFFE/SPIRE dla stabilnych identyfikatorów obciążenia roboczego.
Usługa JWT o krótkim okresie (≤ 5 minut), podpisana przez HSM/KMS; audyt emisji.
Widownia: JWT nadaje się tylko do określonej usługi/domeny.
Strefy zaufania: usługi z innego regionu/najemcy - oddzielne PXT i polityki.

5) Modele autoryzacji: RBAC, ABAC, ReBAC

RBAC (role → uprawnienia): proste i przejrzyste (odpowiednie dla paneli administratora, operatorów).

ABAC (atrybuty tematyczne/zasobowe/kontekstowe): elastyczne dla "najemcy =... Region I =... I kyc_tier≥2"

ReBAC (relacje): Przydatne dla złożonych pakietów akcji („kto jest właścicielem marki/folderu/kampanii”).

Zalecenie: hybrydowe - podstawowe warunki RBAC + kontekst ABAC + relacje punktowe ReBAC.

6) Polityka i egzekwowanie (PDP/PEP)

PEP na Bramie i w usługach: pobiera kontekst (JWT, bilety, IP/ASN, czas, region, warstwa KYC), składa wniosek do 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" }
}

i zwraca 'PERMIT/DENY' + wyjaśnienie.

Pamięć podręczna PEP (TTL 30-120 c) zmniejsza opóźnienie; niepełnosprawność poprzez wydarzenia związane z rolą/zmianą polityki.

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) Zakresy i uchwały

• Zasób: akcja - 'portfel: read', 'portfel: transfer', 'bets: place', 'kyc: status'. odczytać ".
• Dla administratorów - 'admin:' w domenie samodzielnej.
• Dla dostawców - dostawca: raport. czytaj „,” dostawca: wydarzenia. push '.

Zasada minimalnych przywilejów: przypisujemy tylko niezbędne zakresy; „eskalacja” (tymczasowe przedłużenie praw) - biletem i z TTL.

8) Wieloosobowy najemca i regiony (miejsce zamieszkania)

Żetony zawierają „najemcę”, „regionu”, „licencji”; PDP sprawdza korespondencję z zasobem.
Role/polityki - obszary nazw na najemcę („rola: brand _ eu/support”).
rozdzielenie kluczy podpisu i list odwołań według regionów; transregionalne wnioski - tylko poprzez zaufane bramy.

9) Zarządzanie sesjami i urządzeniami

Sklep sesyjny po stronie serwera (powiązanie urządzenia/przeglądarki, rotacja identyfikatora).
Czas bezczynności/bezwzględny (np. 30 min/24 h); działania wrażliwe - re-Auth/MFA.
Lista aktywnych urządzeń, „wyjście ze wszystkich”.
Anomalie: jednoczesne wejścia z różnych regionów, częste zanurzenia MFA - sygnały ryzyka.

10) Delegacja i zgoda (zgoda)

W imieniu (OBO): usługa działa w imieniu użytkownika (token pełnomocnika z odrębnym aktem "sub "/").
Zgoda: wyraźny ekran dostępu partnerów do danych, logarytm zgody z odzyskaniem.
Tymczasowe uprawnienia dostępu: prawa do N godzin/dni automatycznie wygasają.

11) Klucze, podpisy i rotacja

JWKS z „dzieckiem”, automatyczna rotacja, przechowywanie kluczy prywatnych w KMS/HSM.
Algorytmy: ES256/EdDSA dla JWT; TLS 1. 2 +/mTLS.
Okres dwóch kluczy: Zaakceptuj obie 'dzieci', zanim uaktualnienie klienta zostanie zakończone.
RT i Token Introspection przypomina o krytycznych incydentach.

12) Bezpieczeństwo aplikacji klienta

SPA: Authorizate Code + PKCE, no 'implicit', стровий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, bezpieczne przechowywanie RT, ochrona korzenia/jailbreak.
Pulpit: przeglądarka systemowa do logowania (bez wbudowanych widoków), PKCE.

13) Wygodne umowy SDK

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) Obserwowalność i audyt

• '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”
• Anomalie wejść (nowe urządzenie, geo-prędkość), podejrzane zakresy.

• 'who/what/when/where/why', 'decision', 'policy _ version', 'token _ kid', 'client _ id'.
• Eksport do celów zgodności (regulator/sprzedawca-audyt).

15) Ochrona obwodu i klienta

Brama PEP: limit stawki, kontrola bot/podpis, ochrona CSRF, ścisły CORS, HSTS.
Ruch wewnętrzny: mTLS + usługi JWT + ograniczone sieci.
Webhooks/zewnętrzne kolbaki: podpisy nadwozia (HMAC/JWS), okna czasowe, anty-replay.

16) Typowe błędy

Długotrwałe żetony dostępu → przecieki.
Domyślny przepływ OAuth w SPA.
Brak rotacji klucza i okresu podwójnego klucza.
Hardcore role zamiast polityki (niemożliwe jest audyt/wyjaśnienie decyzji).
Mieszanie najemców/regionów w jednym 'role' lub 'key'.
Brak MSZ na działania wrażliwe.
Rozwiązania AuthZ pamięci podręcznej bez zmiany niepełnosprawności.

17) Playbooks (książki startowe)

1. Kluczowy kompromis JWT pod podpisem

Natychmiastowe cofnięcie „dziecko”, publikacja nowego JWKS, przymusowe RT/sesje niepełnosprawności, raport z audytu.

2. Luzem 'invalid _ token'

Sprawdź niewłaściwe zegar/żywotność, znaczenie JWKS, awarie pamięci podręcznej.

3. Anomalie wejściowe

Włączyć zwiększony wynik ryzyka, wymagać zwiększenia, powiadomić użytkownika, tymczasowo ograniczyć płatności.

4. IdP nie powiodło się

Przejdź do pamięci podręcznej sesji/urządzenia ról, ograniczyć nowe logowania, wstrzymać aktywne sesje na TTL.

18) Lista kontrolna przedsprzedaży

• OIDC/OAuth 2. 1 z PKCE, short AT, rotacja RT, wiązanie urządzenia dla operacji krytycznych.
• Pomoc makrofinansowa (WebAuthn/TOTP) i zwiększenie wydajności/zmiana szczegółów/zwiększenie roli.
• Obsługa: mTLS + SPIFFE, krótkotrwałe usługi JWT.
• Polityka AuthZ (RBAC + ABAC/ReBAC) w scentralizowanym PDP; PEP na bramie i w usługach.
• Rozwiązania dla osób niepełnosprawnych Cache; niezmienna ścieżka audytu.
• Multi-najemca/regiony: key/policy/log isolation, license accounting.
• JWKS/klucze w KMS/HSM, rotacja podwójnego klucza, monitorowanie 'kid'.
• CSRF/CORS/HSTS/Rate-limit/bot filtry na obwodzie.
• Odtwarzacze incydentów, cofnij/obracaj/blokuj uruchamianie przycisków.
• Zestaw testowy: jednostka (zasady), umowa (SDK/przepływy), chaos (IdP, JWKS), e2e (step-up, OBO, cofnij).

19) Szablony mini konfiguracji

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."]

Wnioski

Pętla uwierzytelniania i autoryzacji nie jest biblioteką, ale możliwością platformy: krótkotrwałe żetony i klucze zarządzane, scentralizowane zasady i ich lokalna aplikacja, multifactor i step-up, ścisła izolacja najemców/regionów, audyt i telemetria. Konstrukcja ta sprawia, że zmiany są bezpieczne, wyjaśnialne dla regulatora i przejrzyste dla produktu - a skalowanie przez rynek i polecenie staje się rutynową operacją, a nie wyczynem.