Kimlik doğrulama ve yetkilendirme

Güvenilir AuthN/AuthZ döngüsü, kim olduğunuz (kimlik doğrulama) ve ne yapmanıza izin verildiği (yetkilendirme) hakkında tek bir doğruluk noktasıdır. Birçok marka, bölge, entegrasyon ve yüksek düzenleyici gerekliliklere sahip bir platformda, bu kontur "eğer-s'nin servislerle dağılması'değil, politikacılar tarafından modüler, gözlemlenmeli ve yönetilmelidir.

1) Temel terimler ve roller

Kimlik (ID): Kimlik (kullanıcı, servis, sağlayıcı).
Authentication (AuthN): Kimlik kanıtı (parola, MFA, sertifika).
Authorization (AuthZ) - Politik ve bağlam tabanlı karar veremez/veremez.
PDP/PEP: Politika Karar Noktası/Politika Uygulama Noktası.

IdP: Identity Provider (Kimlik Sağlayıcı) (OIDC)

Konu/Kaynak/Eylem/Bağlam: kim/ne/ne yapar/hangi koşullar altında.

2) Genel döngü mimarisi

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

İlkeler: belirteç ve politika üretiminin merkezileştirilmesi, yerel uygulama; "asgari ayrıcalıklar've açık delegasyonlar.

3) Kullanıcı kimlik doğrulaması (OIDC/OAuth 2. 1)

• Yetkilendirme Kodu + PKCE (her zaman SPA/Mobil için).
• SSO: B2b/operatörler için harici IdP desteği (SAML/OIDC).
• MFA: TOTP/WebAuthn/SMS (WebAuthn ve TOTP önerilir; SMS - geri dönüş).
• Risk Bazlı Step-Up: Hassas eylemler için (fonların çekilmesi, detayların değiştirilmesi) MFA/pe-Auth gerektirir.

• Token Rotation + RT kayıt defterini yeniden kullanım detektörlü olarak yenileyin.
• Nonce/State + PKCE, tarayıcı akışları için sıkı CORS/CSRF.
• Kısa ömürlü erişim belirteçleri (5-15 мин) + sessiz yenileme/RT.
• Kritik işlemler için cihaz bağlama (DPoP/mtls bağlı belirteçler).

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) Servis-servis kimlik doğrulaması (mTLS, SPIFFE, JWT)

Hizmetler arasında mTLS + istikrarlı iş yükü tanımlayıcıları için SPIFFE/SPIRE.
HSM/KMS tarafından imzalanan kısa süreli (≤5 dakika) hizmet JWT; İhraç denetimi.
İzleyici kapsamı: JWT yalnızca belirli bir hizmet/etki alanı için uygundur.
Güven bölgeleri: başka bir bölgeden/kiracıdan gelen hizmetler - ayrı PKI'ler ve politikalar.

5) Yetkilendirme modelleri: RBAC, ABAC, ReBAC

RBAC (roller - izinler): basit ve şeffaf (yönetici panelleri, operatörler için uygun).

ABAC (konu/kaynak/bağlam nitelikleri): "tenant =... VE bölge =... Ve kyc_tier≥2"

ReBAC (ilişkiler): Karmaşık holdingler için yararlıdır ('bir marka/klasör/kampanyanın sahibi ").

Öneri: hibrit - temel RBAC + bağlam ABAC koşulları + nokta ReBAC ilişkileri.

6) Politikalar ve Uygulama (PDP/PEP)

Ağ Geçidinde ve hizmetlerde PEP: bağlamı alır (JWT, biletler, IP/ASN, zaman, bölge, KYC katmanı), PDP'ye bir istek oluşturur.

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" }
}

ve 'ALLOW/DENY' + açıklamasını döndürür.

PEP'in çözüm önbelleği (TTL 30-120 c) gecikmeyi azaltır; "Rol/politika değişikliği" olayları ile engellilik.

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) Kapsamlar ve çözünürlükler

• Kaynak: eylem - 'cüzdan: oku', 'cüzdan: Transfer', 'bahisler: Yer', 'kyc: durum. Oku '.
• Yöneticiler için - bağımsız bir etki alanında 'admin:'.
• Sağlayıcılar için - 'sağlayıcı: rapor. oku ',' sağlayıcı: olaylar. It '.

Minimum ayrıcalıklar ilkesi: Sadece gerekli kapsamları atıyoruz; "eskalasyon" (hakların geçici olarak uzatılması) - biletle ve TTL ile.

8) Çok kiracılı ve bölgeler (ikamet)

Belirteçler 'kiracı', 'bölge', 'lisans' içerir; PDP, kaynakla olan yazışmaları kontrol eder.
Roller/politikalar - kiracı başına ad alanları ('role: brand _ eu/support').
İmza anahtarlarının ve iptal listelerinin bölgelere göre ayrılması; Bölgeler arası talepler - yalnızca güvenilir ağ geçitleri aracılığıyla.

9) Oturum ve cihaz yönetimi

Web için sunucu tarafı oturum deposu (cihaz/tarayıcı bağlama, tanımlayıcı rotasyonu).
Boşta/Mutlak Zaman Aşımı (örn. 30 dakika/24 saat); Hassas eylemler - re-Auth/MFA.
Etkin cihazların listesi, "exit from all".
Anomaliler: Farklı bölgelerden eşzamanlı girişler, sık sık MFA düşüşleri - risk sinyalleri.

10) Delegasyon ve rıza (rıza)

(OBO) adına: Hizmet, kullanıcı adına hareket eder (ayrı bir 'alt'/' hareket' içeren bir proxy belirteci).
Rıza: Verilere ortak erişim için açık ekran, geri çağırma ile onay günlüğü.
Geçici erişim yetkileri: N saat/gün hakları otomatik olarak sona erer.

11) Anahtarlar, imzalar ve döndürme

'Çocuk'ile JWKS, otomatik rotasyon, KMS/HSM'de özel anahtarların depolanması.
Algoritmalar: JWT için ES256/EdDSA; TLS 1. 2 +/mTLS.
Çift anahtarlı dönem: İstemci yükseltmesi tamamlanmadan önce her iki'kid'i de kabul edin.
RT ve Token Introspection kritik olayları hatırlıyor.

12) İstemci uygulama güvenliği

SPA: Yetkilendirme Kodu + PKCE, hayır 'örtülü', строгий CORS/İçerik-Güvenlik-Politikası.
Mobil: Uygulama Onayı/Cihaz Kontrolü, güvenli RT depolama, kök/jailbreak koruması.
Masaüstü: oturum açmak için sistem tarayıcısı (gömülü web görünümü yok), PKCE.

13) Uygun SDK sözleşmeleri

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) Gözlemlenebilirlik ve denetim

• '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'
• Girdilerin anomalileri (yeni cihaz, jeo-hız), şüpheli kapsamlar.

• 'Kim/ne/ne/nerede/neden', 'karar', 'politika _ sürümü', 'token _ kid', 'müşteri _ id'.
• Uyumluluk için dışa aktarma (düzenleyici/satıcı-denetim).

15) Çevre ve müşteri koruması

Gateway PEP: hız limiti, bot/imza kontrolleri, CSRF koruması, sıkı CORS, HSTS.
Dahili trafik: mTLS + hizmet JWT + sınırlı ağlar.
Webhooks/harici collbacks: vücut imzaları (HMAC/JWS), zaman pencereleri, anti-replay.

16) Tipik hatalar

Uzun ömürlü erişim belirteçleri - sızıntılar.
SPA'da örtük OAuth akışı.
Anahtar dönüşü ve Çift Anahtar dönemi yok.
Politikalar yerine sert roller (kararları denetlemek/açıklamak mümkün değildir).
Kiracıları/bölgeleri bir 'rol' veya 'anahtar' içinde karıştırmak.
Hassas eylemlerde MFA'yı yükseltmek yok.
AuthZ çözümleri rol değiştirme engeli olmayan önbellek.

17) Playbook'lar (runbook'lar)

1. JWT imza anahtar uzlaşma

Derhal'çocuk 'iptal, yeni JWKS yayın, zorla RT/oturumları sakatlık, denetim raporu.

2. Toplu 'geçersiz _ token'

Saatin yanlış hizalanmasını/ömrünü, JWKS alaka düzeyini, önbellek çökmelerini kontrol edin.

3. Giriş anomalileri

Artan risk puanlamasını etkinleştirin, adım atılmasını isteyin, kullanıcıyı bilgilendirin, ödemeleri geçici olarak sınırlayın.

4. IdP başarısız oldu

Oturum önbelleğine/rol aygıtına geçin, yeni girişleri sınırlayın, etkin oturumları TTL olarak tutun.

18) Satış öncesi kontrol listesi

• OIDC/OAuth 2. PKCE ile 1, kısa AT, RT rotasyonu, kritik işlemler için cihaz bağlama.
• MFA (WebAuthn/TOTP) ve çıkış/detay değişimi/rol yükselmeleri için adım.
• Hizmetten hizmete: mTLS + SPIFFE, kısa ömürlü hizmet JWT'leri.
• Merkezi PDP'de AuthZ politikaları (RBAC + ABAC/ReBAC); Geçit ve hizmetlerde PEP.
• Engellilik Çözümleri Önbelleği; denetim izi değiştirilemez.
• Çok kiracılı/bölgeler: anahtar/politika/günlük izolasyonu, lisans muhasebesi.
• KMS/HSM'de JWKS/anahtarlar, çift anahtarlı döndürme, izleme 'kimlik'.
• Çevre üzerinde CSRF/CORS/HSTS/Rate-limit/bot filtreleri.
• Olay oyun kitapları, iptal/döndürme/kilitleme çalıştırma düğmeleri.
• Test paketi: birim (politikalar), sözleşme (SDK/akışlar), kaos (IdP, JWKS), e2e (adım atma, OBO, iptal etme).

19) Mini yapılandırma şablonları

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

Sonuç

Kimlik doğrulama ve yetkilendirme döngüsü bir kütüphane değil, bir platform yeteneğidir: Kısa ömürlü belirteçler ve yönetilen anahtarlar, merkezi politikalar ve bunların yerel uygulamaları, çok faktörlü ve adım adım, kiracıların/bölgelerin sıkı izolasyonu, denetim ve telemetri. Bu tasarım, değişiklikleri güvenli, regülatöre açıklanabilir ve ürüne şeffaf hale getirir - ve piyasa ve komuta göre ölçeklendirme, bir başarı değil, rutin bir işlem haline gelir.