Modern frameworklerin kimlik doğrulama ve yetkilendirmeyi nasıl uyguladığı hakkında bilgi edinin: oturumlar, tokenler, OAuth/OIDC, middleware, roller, politikalar ve önemli güvenlik tuzakları.
Kimlik doğrulama “sen kimsin?” sorusunu yanıtlar. Yetkilendirme “ne yapmana izin veriliyor?” sorusunu yanıtlar. Modern frameworkler bunları ilişkili ama ayrı kaygılar olarak ele alır; bu ayrım, bir uygulama büyüdükçe güvenliğin tutarlı kalmasının ana nedenlerinden biridir.
Kimlik doğrulama, bir kullanıcının (veya servisin) iddia ettiği kişi olduğunu kanıtlamaya yöneliktir. Frameworkler genellikle tek bir yöntemi sert kodlamaz; bunun yerine parola girişi, sosyal giriş, SSO, API anahtarları ve servis kimlik bilgileri gibi yaygın seçenekler için genişletme noktaları sunarlar.
Kimlik doğrulamanın çıktısı bir kimliktir: bir kullanıcı kimliği, hesap durumu ve bazen temel öznitelikler (ör. e-posta doğrulandı mı). Önemli: kimlik doğrulama bir işlemin izinli olup olmadığını belirlememelidir—sadece isteği kimin yaptığını belirler.
Yetkilendirme, belirlenmiş kimliği ve istek bağlamını (rota, kaynak sahibi, tenant, kapsamlar, ortam vb.) kullanarak bir eylemin izinli olup olmayacağını karar verir. Roller, izinler, politikalar ve kaynak bazlı kurallar burada yaşar.
Frameworkler yetkilendirme kurallarını kimlik doğrulamadan ayırır, böylece:
Çoğu framework isteğin yaşam döngüsünde merkezi noktalardan kuralları uygular:
İsimler farklı olsa da yapı taşları tanıdıktır: bir kimlik deposu (kullanıcılar ve kimlik bilgileri), istekler arasında kimliği taşıyan bir oturum veya token, ve kimlik doğrulama + yetkilendirmeyi tutarlı şekilde zorlayan middleware/koruyucular.
Bu makaledeki örnekler kavramsaldır, böylece tercih ettiğiniz frameworke haritalayabilirsiniz.
Bir framework birini “oturum açmış” olarak işaretlemeden önce iki şeye ihtiyaç duyar: kimlik verilerini arayacağı bir yer (kimlik deposu) ve kodda o kimliği tutarlı şekilde temsil etme yöntemi (kullanıcı modeli). Modern frameworklerde birçok “kimlik doğrulama özelliği” aslında bu iki parçanın etrafındaki soyutlamalardır.
Frameworkler genelde birden fazla arka ucu destekler, ya yerleşik ya da eklentiler aracılığıyla:
Ana fark gerçek bilginin kaynağıdır. Veritabanı kullanıcılarında uygulamanız kimlik bilgilerine ve profil verilerine sahiptir. Bir IdP veya dizin ile uygulamanız genellikle harici kimlikle ilişkilendirilmiş bir “yerel gölge kullanıcı” saklar.
Frameworkler varsayılan bir kullanıcı modeli oluştursa bile, çoğu ekip birkaç alanı standartlaştırır:
is_verified, is_active, is_locked, deleted_atBu bayraklar önemlidir çünkü kimlik doğrulama sadece “parola doğru mu?” değil—aynı zamanda “bu hesap şu an oturum açmasına izin veriliyor mu?” sorusudur.
Pratik bir kimlik deposu kayıt, e-posta/telefon doğrulama, parola sıfırlama, hassas değişikliklerden sonra oturum geçersiz kılma ve devre dışı bırakma veya soft-delete gibi ortak yaşam döngüsü olaylarını destekler. Frameworkler genellikle tokenler, zaman damgaları, hook'lar gibi yapı taşları sağlar, ancak yine de kuralları siz tanımlarsınız: son kullanma pencereleri, oran sınırlamaları ve bir hesap devre dışı bırakıldığında mevcut oturumlara ne olacağı gibi.
Çoğu modern framework user providerlar, adaptörler veya repository'ler gibi genişletme noktaları sunar. Bu bileşenler “bu oturum açma tanımlayıcısı verildiğinde kullanıcıyı getir” ve “bu kullanıcı ID'si verildiğinde mevcut kullanıcıyı yükle” mantığını seçtiğiniz depoya çevirir—ister SQL sorgusu, ister bir IdP çağrısı, ister kurumsal dizin sorgusu olsun.
Oturum tabanlı kimlik doğrulama, birçok web framework'ünün hâlâ varsayılan olarak kullandığı “klasik” yaklaşımdır—özellikle sunucu tarafından render edilen uygulamalarda. Fikir basit: sunucu kim olduğunuzu hatırlar, tarayıcı bu hafızaya küçük bir işaretçi tutar.
Başarılı bir girişten sonra framework sunucu tarafında bir oturum kaydı oluşturur (genelde rasgele bir session ID ile kullanıcı arasında eşleme). Tarayıcı bu session ID'yi içeren bir çerez alır. Her istekte tarayıcı çerezi otomatik olarak geri gönderir ve sunucu kim oturum açmış kullanıcıyı bulmak için bunu kullanır.
Çerez sadece bir tanımlayıcı olduğundan (kendi içinde kullanıcı verisi taşımadığı için), hassas bilgiler sunucuda kalır.
Modern frameworkler oturum çerezlerini çalınmayı veya kötüye kullanılmayı zorlaştırmak için güvenli varsayılanlar koymaya çalışır:
Bunlar genelde “session cookie settings” veya “security headers” altında yapılandırılır.
Frameworkler genellikle oturum deposu seçmenize izin verir:
Genel olarak trade-off hız vs kalıcılık vs operasyonel karmaşıklıktır.
Çıkış (logout) iki anlama gelebilir:
Frameworkler genellikle “her yerde çıkış” için kullanıcıya bir “oturum versiyonu” tutarak, kullanıcı başına birden fazla session ID saklayıp bunları iptal ederek uygular. Anında geçersiz kılma gerekiyorsa, oturum tabanlı kimlik doğrulama genellikle tokenlere göre daha basittir çünkü sunucu bir oturumu hemen unutabilir.
Token tabanlı kimlik doğrulama, sunucu tarafı oturum aramasını bir string ile değiştirme fikrine dayanır. Frameworkler genelde tokenleri API ağırlıklı sunucular, mobil uygulamalar, ayrı backend ile konuşan SPA'ler veya servislerin tarayıcı oturumuna ihtiyaç duymadan birbirlerini çağırdığı durumlar için önerir.
Token, oturum açmadan sonra (veya bir OAuth akışından sonra) verilen bir erişim yetkisidir. İstemci bunu sonraki isteklere gönderir, böylece sunucu çağıranı kimlik doğrulayıp sonra eylemi yetkilendirebilir. Çoğu framework bunu birinci sınıf desen olarak ele alır: bir “token ver” uç noktası, tokeni doğrulayan kimlik doğrulama middleware'i ve kimlik belirlendikten sonra çalışan koruyucular/politikalar.
Opak tokenler istemci için anlamı olmayan rastgele dizelerdir (ör. tX9...). Sunucu bunları bir veritabanı veya önbellek girdisiyle doğrular. Bu, iptal etmeyi kolaylaştırır ve token içeriğini gizli tutar.
JWT'ler (JSON Web Token) yapılandırılmış ve imzalıdır. Bir JWT tipik olarak sub, iss, aud, iat, exp gibi claimler ve bazen roller/kapsamlar içerir. Önemli: JWT'ler varsayılan olarak şifrelenmez—tokeni elinde tutan herhangi biri claimleri okuyabilir, imza doğrulama olmadan sahte oluşturamaz.
Framework rehberliği genelde iki daha güvenli varsayılda birleşir:
Authorization: Bearer <token> başlığıyla gönderin. Bu, otomatik gönderilen çerezlerin yol açtığı CSRF risklerini azaltır, ama JavaScript'in tokeni okuyup eklemesini gerektirdiği için XSS savunmalarını güçlendirir.HttpOnly, Secure ve SameSite yapabiliyorsanız kullanın ve CSRF'yi uygun şekilde ele almaya hazır olun (genellikle ayrı CSRF tokenleriyle eşleştirilir).Erişim tokenleri kısa ömürlü tutulur. Sürekli yeniden oturum açma zorunluluğunu önlemek için birçok framework yenileme tokenleri destekler: yalnızca yeni erişim tokenleri üretmek için kullanılan uzun ömürlü bir kimlik.
Yapı genellikle şöyledir:
POST /auth/login → erişim tokeni (ve yenileme tokeni) dönerPOST /auth/refresh → yenileme tokenini döndürür ve yeni erişim tokeni verirPOST /auth/logout → yenileme tokenlerini sunucu tarafında geçersiz kılarHer istekte yeni bir yenileme tokeni vermek (rotation), bir yenileme tokeni ele geçirilirse zararı sınırlar; birçok framework token tanımlayıcılarını saklama, yeniden kullanım tespiti ve hızlı iptal için hook'lar sağlar.
OAuth 2.0 ve OpenID Connect (OIDC) sıkça birlikte anılır, ama frameworkler bunları farklı olarak ele alır çünkü farklı problemleri çözerler.
OAuth 2.0'ı delege edilmiş erişim gerektiğinde kullanın: uygulamanız bir API'yi kullanıcının adına çağırmak istiyorsa.
OpenID Connect'i kimlik/login gerektiğinde kullanın: uygulamanız kullanıcının kim olduğunu bilmek ve ID token ile kimlik claimleri almak istiyorsa. Pratikte “X ile giriş” genelde OIDC'nin OAuth 2.0 üzerine konmuş halidir.
Çoğu modern framework ve kimlik kütüphanesi iki akışa odaklanır:
Framework entegrasyonları genellikle bir callback rotası ve yardımcı middleware sağlar, ama yine de temel yapılandırmaları doğru yapmak sizin sorumluluğunuzdur:
Frameworkler genellikle sağlayıcı verisini yerel kullanıcı modeline normalleştirir. Tasarım kararı, yetkilendirmeyi gerçekten neyin yöneteceğidir:
Yaygın bir desen: kararlı tanımlayıcıları (sub gibi) yerel bir kullanıcıya eşleyin, sonra sağlayıcı rollerini/gruplarını/claimlerini uygulamanızın kontrol ettiği yerel roller veya politikalara çevirin.
Parolalar hâlâ birçok uygulamada varsayılan giriş yöntemidir, bu yüzden frameworkler genellikle daha güvenli depolama desenleri ve ortak korumalarla gelir. Temel kural değişmedi: parolayı (veya basit bir hash'ini) asla veritabanınızda saklamamalısınız.
Modern frameworkler genellikle bcrypt, Argon2 veya scrypt gibi amaça yönelik parola hashleyicilerini varsayılan olarak sunar. Bu algoritmalar kasıtlı olarak yavaştır ve salt içerir; bu, önceden hesaplanmış tablo saldırılarını önlemeye yardımcı olur ve büyük ölçekli kırmayı pahalı hale getirir.
SHA-256 gibi düz kriptografik hash'ler parolalar için güvensizdir çünkü hızlı olacak şekilde tasarlanmıştır. Bir veritabanı sızarsa, hızlı hash'ler saldırganların milyarlarca parolayı hızla denemesine izin verir. Parola hashleyiciler iş faktörleri (cost) içerir, böylece donanım geliştikçe güvenliği ayarlayabilirsiniz.
Frameworkler genellikle mantıklı kuralları her uç noktaya sert kodlamak yerine ara katman/eklenti şeklinde uygulamanıza olanak veren hook'lar sağlar:
Çoğu ekosistem MFA'yı parola doğrulamasından sonra ikinci adım olarak eklemeyi destekler:
Parola sıfırlama yaygın bir saldırı yolu olduğundan, frameworkler genellikle şu desenleri teşvik eder:
İyi bir kural: meşru kullanıcılar için kurtarmayı kolaylaştırın, ama saldırganların otomasyonunu maliyetli hale getirin.
Çoğu modern framework güvenliği istek hattının bir parçası olarak ele alır: kontrolör/handler'dan önce (ve bazen sonra) çalışan bir dizi adım. İsimler değişse de—middleware, filtreler, koruyucular, interceptorler—fikir aynıdır: her adım isteği okuyabilir, bağlam ekleyebilir veya işleme dur diyebilir.
Tipik akış şu şekildedir:
/account/settings).Frameworkler güvenlik kontrollerini iş mantığından dışarda tutmanızı teşvik eder, böylece kontrolörler “ne yapmalı”ya odaklanır, “kimi izin verilmeli”ye değil.
Kimlik doğrulama, çerezlerden, session ID'lerden, API anahtarlarından veya bearer tokenlerden kullanıcı bağlamını çıkarma adımıdır. Başarılı olursa isteğe özgü bir kimlik oluşturur—genelde user, principal veya context.auth gibi bir nesne olarak erişilebilir.
Bu iliştirme önemlidir çünkü sonraki adımlar (ve uygulama kodu) başlıkları yeniden ayrıştırmamalı veya tokenleri yeniden doğrulamamalıdır. Zaten doldurulmuş kullanıcı nesnesini okumalıdır, bu nesne genelde şunları içerir:
Yetkilendirme genelde şunlar olarak uygulanır:
İkinci tür, yetkilendirme kancalarının neden kontrolörler ve servislerin yakınında olduğunu açıklıyor: doğru karar vermek için rota parametrelerine veya veritabanından yüklenen nesnelere ihtiyaçları olabilir.
Frameworkler iki yaygın hata modunu ayırır:
İyi tasarlanmış sistemler 403 yanıtlarında hangi kuralın başarısız olduğunu ifşa etmez; erişimi reddeder ama detay vermez.
Yetkilendirme daha dar bir soruyu yanıtlar: “Bu oturum açmış kullanıcı şu anda bu belirli şeyi yapabilir mi?” Modern frameworkler genelde birkaç modeli destekler ve birçok ekip bunları birleştirir.
RBAC kullanıcıları bir veya daha fazla role atar (admin, support, member) ve özellikleri bu rollere göre engeller.
Uygulaması kolaydır ve frameworkler genelde requireRole('admin') gibi yardımcılar sunar. Rol hiyerarşileri (“admin => manager => member”) çoğaltmayı azaltabilir, ama bir üst rolde yapılan küçük bir değişiklik uygulama genelinde gizli ayrıcalıklar verebilir.
RBAC geniş, sabit ayrımlar için en iyi çalışır.
İzin bazlı yetkilendirme bir eylemi bir kaynağa karşı kontrol eder, genelde şöyle ifade edilir:
read, create, update, delete, inviteinvoice, project, user, bazen bir ID veya sahiplik bilgisi ileBu model RBAC'den daha kesinlik sağlar. Örneğin, “projeleri güncelleyebilir” ile “sadece kendine ait projeleri güncelleyebilir” farklıdır; ikincisi hem izin hem de veri koşulu kontrolü gerektirir.
Frameworkler genelde kontrolörlerde, resolver'larda, worker'larda veya şablonlarda çağrılmak üzere merkezi bir “can?” fonksiyonu (veya servisi) uygular.
Politikalar yetkilendirme mantığını yeniden kullanılabilir değerlendiricilere paketler: “Bir kullanıcı bir yorumu silerse eğer onu yazdıysa ya da moderatörse” gibi. Politikalar bağlam kabul eder (kullanıcı, kaynak, istek) ve şu durumlar için idealdir:
Frameworkler politikaları routing ve middleware ile entegre ettiğinde, kuralları uç noktalar arasında tutarlı şekilde uygulayabilirsiniz.
Annotasyonlar (ör. @RequireRole('admin')) niyeti handler'a yakın tutar, ama kurallar karmaşıklaşınca parçalanabilir.
Kod tabanlı kontroller (yetkilendiriciye açıkça yapılan çağrılar) daha uzundur ama test etmesi ve refaktörlemesi genelde daha kolaydır. Ortak bir uzlaşma: kaba kapı filtreleri için annotasyonlar, ayrıntılı mantık için politikalar kullanmak.
Modern frameworkler sadece kullanıcı girişine yardımcı olmaz—aynı zamanda kimlik etrafında ortaya çıkan en yaygın “web bağlantı” saldırılarına karşı savunmalarla gelir.
Uygulamanız oturum çerezleri kullanıyorsa, tarayıcı istekler sırasında bunları otomatik olarak iliştirir—bazen başka bir site tarafından tetiklenmiş isteklerde bile. Framework CSRF koruması genelde durum-değiştiren isteklerle birlikte gönderilmesi gereken per-oturum (veya per-istek) bir CSRF tokeni ekler.
Yaygın desenler:
CSRF tokenlerini SameSite çerezleri (genelde varsayılan olarak Lax) ile eşleştirip, oturum çerezinizin HttpOnly ve Secure olmasını sağlamalısınız.
CORS bir kimlik mekanizması değildir; tarayıcı izin sistemi üzerinedir. Frameworkler genelde güvenilen kökenlerin API'nizi çağırmasına izin vermek için middleware/konfigürasyon sağlar.
Kaçınılması gereken yanlış yapılandırmalar:
Access-Control-Allow-Origin: * ile birlikte Access-Control-Allow-Credentials: true kullanmak (tarayıcı bunu reddeder ve kafa karışıklığını gösterir).Origin başlığını yansıtmak yerine katı bir izin listesi kullanmamak.Authorization) veya metotları izin listesine eklemeyi unutmak; bu durum curl ile çalışan ama tarayıcıda başarısız olan istemcilere yol açar.Çoğu framework güvenli varsayılanlar ayarlayabilir veya şu başlıkları eklemeyi kolaylaştırır:
X-Frame-Options veya Content-Security-Policy: frame-ancestors.Content-Security-Policy.Referrer-Policy ve X-Content-Type-Options: nosniff.Doğrulama verinin biçimsel olarak doğru olmasını sağlar; yetkilendirme kullanıcının bunu yapmaya yetkili olup olmadığını sağlar. Geçerli bir istek yine de yasaklanabilir—frameworkler her iki katmanı da erken uyguladığınızda en iyi çalışır: önce girdileri doğrulayın, sonra erişimi ilgili kaynağa göre zorlayın.
“Doğru” kimlik deseni, kodunuzun nerede çalıştığına ve isteklerin arka uca nasıl ulaştığına bağlıdır. Frameworkler birden fazla seçeneği destekleyebilir, ama bir uygulama türünde doğal gelen varsayılanlar başka bir türde garip veya riskli olabilir.
SSR frameworkleri genelde çerez tabanlı oturumlarla iyi eşleşir. Tarayıcı çerezi otomatik olarak gönderir, sunucu oturumu bulur ve sayfalar kullanıcı bağlamıyla render edilebilir.
Pratik bir kural: oturum çerezlerini HttpOnly, Secure ve uygun bir SameSite ile tutun ve özel veri render eden her istekte sunucu tarafı yetkilendirme kontrollerine güvenin.
SPAlar genellikle JavaScript'ten API çağrısı yaptığı için token seçimleri daha görünür olur. Birçok ekip kısa ömürlü erişim tokenleri üreten OAuth/OIDC akışını tercih eder.
Uzun ömürlü tokenleri localStorage'da saklamaktan kaçının; bu XSS patlama alanını artırır. Yaygın bir alternatif backend-for-frontend (BFF) desenidir: SPA kendi sunucunuza bir oturum çerezi ile konuşur ve sunucu yukarı akış API'ler için tokenleri değiş tokuş/ saklar.
Mobil uygulamalar tarayıcı çerez kurallarına güvenemez. Genelde PKCE ile OAuth/OIDC kullanır ve yenileme tokenlerini platformun güvenli depolama alanında (Keychain/Keystore) saklarlar.
“Kayıp cihaz” kurtarması planlayın: yenileme tokenlerini iptal edin, kimlik bilgilerini döndürün ve MFA etkinse yeniden kimlik doğrulamayı pürüzsüz yapın.
Birden çok servisle, merkezi kimlik ile servis düzeyi uygulama arasında seçim yaparsınız:
Servisler arası kimlik doğrulama için frameworkler genelde mTLS (güçlü kanal kimliği) veya OAuth client credentials (servis hesapları) ile entegrasyon sunar. Anahtar nokta hem çağıranı kimlik doğrulamak hem de ne yapabileceğini yetkilendirmektir.
Yönetici “kullanıcı taklidi” özellikleri güçlü ama tehlikelidir. Açık taklit oturumlarını tercih edin, yöneticiler için yeniden kimlik doğrulama/MFA isteyin ve her zaman denetim kayıtları yazın (kim kimi taklit etti, ne zaman ve hangi eylemler yapıldı).
Güvenlik özellikleri kod değiştiğinde çalışmaya devam etmelidir. Modern frameworkler kimlik doğrulama ve yetkilendirmeyi test etmeyi kolaylaştırır, ama gerçek kullanıcı davranışını ve gerçek saldırgan davranışını yansıtan testlere ihtiyacınız var.
Ne test ettiğinizi ayırarak başlayın:
Çoğu framework test yardımcılarıyla gelir, böylece her seferinde oturum veya token elle oluşturmaya gerek kalmaz. Yaygın desenler:
Pratik bir kural: her “mutlu yol” testine bir de “reddedilmeli” testi ekleyin ki yetkilendirme kontrolünün gerçekten çalıştığını doğrulayın.
Koda hızlı iterasyon yaparken, geri alma destekli hızlı prototipleme araçları yardımcı olabilir. Örneğin, Koder.ai (bir vibe-coding platformu) React frontend ve Go + PostgreSQL backend oluşturup anlık görüntüler ve geri alma ile middleware/koruyucu ve politika denemelerinde değişiklikleri denetlemenizi sağlar—oturum vs token yaklaşımlarını denerken değişiklikleri denetlenebilir tutmak için kullanışlıdır.
Bir şey ters gittiğinde hızlı ve emin cevaplar almak istersiniz.
Aşağıdaki olayları loglayın/denetleyin:
Hafif metrikler de ekleyin: 401/403 oranları, başarısız oturum açma patlamaları ve alışılmadık token yenileme desenleri.
Yetki hatalarını test edilebilir davranışlar olarak ele alın: eğer gerileyebiliyorsa, bir teste değerdir.
Kimlik doğrulama, kimlik kanıtlar (isteği yapan kim?). Yetkilendirme ise erişimi belirler (o kim ne yapabilir?) ve rota, kaynak sahipliği, tenant, kapsamlar gibi bağlamı kullanır.
Frameworkler bunları ayırır, böylece oturum açma yöntemlerini değiştirmek zorunda kalmadan izin mantığını koruyabilirsiniz.
Çoğu framework doğrulamayı istek hattında uygular; tipik olarak:
user/principal eklemek için Middleware/filtreler/interceptorlerBir kimlik deposu, kullanıcılar ve kimlik bilgileri için gerçek kaynak (veya harici kimliklere bağlar). Bir kullanıcı modeli ise bu kimliği kod içinde nasıl temsil ettiğinizdir.
Frameworkler pratikte şu soruyu yanıtlamak için ikisine ihtiyaç duyar: “bu tanımlayıcı/token verildiğinde, şu anki kullanıcı kim?”
Yaygın kaynaklar şunlardır:
IdP veya dizin kullanıldığında, birçok uygulama OIDC sub gibi kararlı harici kimlikleri yerel rollere ve verilere eşlemek için bir “gölge kullanıcı” saklar.
Oturumlar kimliği sunucu tarafında saklar ve çerez bir işaretçi (session ID) olarak kullanılır; SSR için uygundur ve iptal etmeyi kolaylaştırır.
Tokenler (JWT/opaque) her istekte gönderilir (çoğunlukla Authorization: Bearer ... yoluyla) ve API'ler, SPA'lar, mobil uygulamalar ve hizmetler arası senaryolar için daha uygundur.
Frameworkler genellikle oturum çerezlerini şu şekilde sertleştirir:
HttpOnly (XSS ile çerez hırsızlığını azaltır)Secure (sadece HTTPS üzerinden gönderilir)SameSite (çerezlerin çapraz site gönderimini sınırlar; CSRF ve üçüncü taraf kimlik akışlarını etkiler)Doğru değerleri ( vs ) uygulamanızın ihtiyaçlarına göre seçmeniz gerekir.
Opaque tokenler rastgele dizelerdir ve sunucu sorgulamasıyla doğrulanır (iptali kolay, içeriği gizli).
JWT'ler imzalı ve kendini içeren tokenlerdir; sub, exp, roller/kapsamlar gibi okunabilir claimler taşırlar. Dağıtılmış sistemlerde kullanışlıdırlar, ama iptal etmek zordur—kısa ömürler ve sunucu tarafı kontroller gerekir.
Erişim tokenlerini kısa ömürlü tutun ve yeni erişim tokenleri üretmek için yalnızca yenileme tokenleri kullanın.
Yaygın uç noktalar:
POST /auth/login → erişim + yenilemePOST /auth/refresh → yenileme tokenini döndürür ve erişimi yenilerPOST /auth/logout → yenileme tokenlerini geçersiz kılarDönüşümlü yenileme (rotation) ve yeniden kullanım tespiti, bir yenileme tokeni ele geçirilirse zararı sınırlar.
OAuth 2.0, vekaletli erişim içindir: uygulamanız bir API'yi kullanıcının adına çağırmak istiyorsa.
OpenID Connect (OIDC) kimlik içindir: uygulamanız kullanıcının kim olduğunu bilmek istiyorsa ve ID token ile kimlik claimleri almak istiyorsa. Genelde “X ile giriş” OIDC üzerinde OAuth 2.0'dır.
Roller geniş kapı bekçileri için kullanışlıdır (admin, member gibi). İzinler/politikalar ise kaynak düzeyinde daha ince kurallar sağlar (ör. sadece kendi belgesini düzenleyebilme).
Yaygın desen:
LaxNone