Erişim Kontrolü, OIDC ve Oturum Yönetimi

Kimlik doğrulama kullanıcının veya servisin kim olduğunu, erişim kontrolü ise hangi kaynağa hangi koşullarda erişebileceğini belirler. OAuth2/OIDC token'ı bu kararın girdisidir; authorization kararı her zaman resource-owning backend'de uygulanmalıdır.

Hızlı Karar

İhtiyaç	Yaklaşım	Dikkat
Basit rol matrisi	RBAC	Rol patlamasını izle
Kaynak/tenant/cihaz bağlamı	ABAC veya policy engine	Policy test edilebilir olmalı
Kullanıcı giriş federasyonu	OIDC	ID token'ı API access token yerine kullanma
Kurumsal SSO	SAML veya OIDC federation	Metadata ve sertifika rotation
Stateless API	Kısa ömürlü access token	Revocation ve refresh akışı
Stateful browser session	Secure cookie + distributed session	CSRF ve session fixation

Üretim Kontrol Listesi

• Problem: Kimlik, yetki, resource ownership ve tenant sınırı ayrı ayrı tanımlı mı?
• Çözüm: Token claim, scope, policy, session storage, revocation ve audit akışı net mi?
• Trade-off: Merkezi policy tutarlılık sağlar; auth servisi kritik dependency olur.
• Hata durumu: Expired/revoked token, privilege escalation, session theft ve confused deputy ele alınmalı.
• Ölçüm: Authorization deny, token refresh, session anomaly, policy latency ve SSO failure izlenmeli.
• Güvenlik/maliyet: Least privilege, kısa token lifetime, secret rotation ve policy cache invalidation uygulanmalı.

OIDC ve OAuth2 Rolleri

OIDC, OAuth2 üzerine kimlik katmanı ekler. Authorization code + PKCE kullanıcı girişinde, client credentials servisler arası erişimde kullanılabilir. ID token istemciye kimlik bilgisi taşır; API'nin korunan kaynağı için access token ve audience/scope doğrulanmalıdır.

JWT doğrulamasında issuer, audience, signature algorithm, expiry, not-before, key ID ve clock skew kontrol edilir. Refresh token rotation, reuse detection ve revoke işlemi ayrıca tasarlanır; yalnızca JWT imzası logout veya acil revoke sorununu çözmez.

RBAC ve ABAC

RBAC, role -> permission ilişkisiyle basit ve denetlenebilirdir. Hierarchical role'lar kolaylık sağlar fakat büyük organizasyonlarda role explosion yaratabilir.

ABAC, subject, resource, action, tenant, cihaz, konum veya zaman gibi attribute'larla karar verir:

allow if subject.tenant == resource.tenant
       and action in subject.permissions
       and resource.classification <= subject.clearance

Policy evaluation fail-closed olmalı. Policy version, decision reason, cache lifetime ve object-level authorization testleri kaydedilmelidir. Gateway'deki coarse check, servisteki resource ownership kontrolünün yerine geçmez.

Session Yönetimi

Stateful session kullanılıyorsa session ID yalnızca rastgele opaque değer olmalı; cookie Secure, HttpOnly, uygun SameSite, dar Domain/Path ve idle/absolute timeout ile korunmalıdır. Login sonrası session ID rotate edilerek session fixation önlenir.

Birden fazla instance'ta session Redis veya database gibi ortak store'da tutulabilir. Sticky session operasyonu basitleştirmez; failover, expiration, revocation, serialization ve store outage davranışı yine tasarlanmalıdır. Logout, password change ve riskli cihaz değişiminde tüm ilgili session/refresh token'lar revoke edilmelidir.

SSO ve Identity Federation

SAML assertion veya OIDC identity provider'dan gelen kimlik, local user/account mapping ve tenant policy ile eşleştirilir. Email gibi değişebilir bir alanı kalıcı kimlik olarak kullanma; provider subject ve verified claim'leri tercih et.

SSO'da redirect URI allowlist, state, nonce, PKCE, certificate/signing-key rotation, clock skew ve account linking kuralları test edilmelidir. Provider outage sırasında mevcut session'ın ne kadar süre yaşatılacağı açık bir risk kararıdır.

Zero-Trust Servis Erişimi

Zero-trust, private network'te bulunan servise otomatik güvenmemeyi gerektirir:

• Her workload için doğrulanabilir service identity ve kısa ömürlü credential.
• Her istekte authentication, authorization, audience ve policy enforcement.
• mTLS, network policy ve least-privilege service account.
• İnsan erişiminde just-in-time yetki, audit ve düzenli access review.

Service mesh policy'leri savunma katmanıdır; business authorization yine uygulama ve veri sahibi serviste kalır. Policy bypass, default allow ve ortak admin credential'ları kırmızı bayraktır.

Denetim ve Olay İncelemesi

Auth event'leri actor, subject, resource, action, decision, policy version, request/trace ID ve timestamp içermelidir. Token veya password loglanmaz. Deny oranındaki ani artış, session coğrafya değişimi ve başarısız SSO akışı alarm sinyali olabilir.

OAuth2, JWT ve API key uygulama ayrıntıları için Authentication vs Authorization; request güvenliği için API Güvenliği ve servis kimliği için TLS/mTLS sayfalarına bakılabilir.