OAuth 2.0

OAuth 2.0, yetkilendirme devretme için standart protokoldür; üçüncü taraf uygulamaların başka bir hizmette kontrolünüzdeki kaynaklara şifrenizi vermeden erişmesini sağlar. "Google ile Giriş Yap", "GitHub Hesabınızı Bağlayın", "Zapier'in Gmail'inize Erişmesine İzin Verin" gibi özellikler hepsinde OAuth kullanır.

Dört rol: kaynak sahibi (kullanıcı), istemci (üçüncü taraf uygulama), yetkilendirme sunucusu (OAuth veren hizmet, örn. accounts.google.com), kaynak sunucusu (istemcinin çağırmak istediği API, örn. gmail.googleapis.com).

En yaygın akış (PKCE ile yetkilendirme kodu):

1. İstemci, kullanıcıyı yetkilendirme sunucusuna yönlendirir.
2. Kullanıcı giriş yapar ve talep edilen kapsamları onaylar.
3. Yetkilendirme sunucusu, tek kullanımlık bir yetkilendirme koduyla geri yönlendirir.
4. İstemci, kodu (ve PKCE doğrulayıcıyı) erişim jetonuyla değiştirir.
5. İstemci, erişim jetonuyla kaynak sunucusunu çağırır.

OAuth 2.0 yalnızca yetkilendirme içerir. OpenID Connect (OIDC), üstüne eklenen kimlik doğrulama katmanıdır; kimin giriş yaptığını değil yalnızca "yetkili bir kullanıcı" olduğunu bilen istemciye kullanıcıyı tanıtan talepleri içeren bir kimlik jetonu (JWT) ekler. Modern "X ile Giriş Yap" akışlarının büyük çoğunluğu saf OAuth değil, OIDC kullanır.

PKCE neden artık genel istemciler için zorunludur: orijinal OAuth 2.0 yetkilendirme-kodu akışı, istemcinin bir sırrı saklayabildiğini varsayıyordu. Mobil uygulamalar ve tek sayfalık uygulamalar bunu yapamaz; herkes uygulamayı tersine mühendislik yaparak gömülü sırrı çıkarabilir. PKCE (Proof Key for Code Exchange, RFC 7636), statik istemci sırrını akış başına rastgele bir doğrulayıcıyla değiştirir; bu doğrulayıcı SHA-256 ile karma haline getirilir: istemci başlangıçta karmayı gönderir, kodu değiştirirken orijinal metni paylaşır ve böylece akışı başlatan istemcinin aynı olduğunu kanıtlar. PKCE, artık tüm genel istemciler için zorunludur (OAuth 2.1, RFC 9700 BCP) ve derinlemesine savunma amacıyla gizli istemciler için de önerilmektedir.

Bilmeniz gereken dört akış ve kaçınmanız gereken iki akış: neredeyse her şey için (web, mobil, SPA) Yetkilendirme Kodu + PKCE kullanın. Kullanıcının olmadığı makineden makineye API çağrıları için İstemci Kimlik Bilgileri kullanın. Örtük akış (erişim jetonlarını doğrudan URL parçalarında döndürür) ve Kaynak Sahibi Parola Kimlik Bilgileri akışı (istemci parolayı doğrudan toplar) OAuth 2.1'de kullanımdan kaldırılmıştır; her ikisi de modern saldırılara karşı yeterince koruma sağlamaz. Yeni bir OAuth entegrasyonu, bir sağlayıcı bunları sunsa bile reddetmelidir. İlgili: SHA-256. Kaynak: RFC 6749 — OAuth 2.0, RFC 7636 — PKCE.

Çözümlü örnek

SaaS uygulamanızdaki "Slack'e Bağlan" düğmesi şu URL'ye yönlendirme tetikler: https://slack.com/oauth/v2/authorize?client_id=...&scope=chat:write,channels:read&redirect_uri=https://app.example.com/oauth/callback&state=xyz&code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256. Kullanıcı onaylar; Slack https://app.example.com/oauth/callback?code=ONE_TIME_CODE&state=xyz adresine yönlendirir. Arka ucunuz https://slack.com/api/oauth.v2.access adresine kodu, orijinal PKCE doğrulayıcıyı ve istemci kimliğini içeren bir POST isteği gönderir. Slack {"access_token": "xoxb-...", "scope": "chat:write,channels:read", "team": {"id": "T123"}} döndürür. Erişim jetonunu sunucu tarafında saklarsınız (asla tarayıcı yerel depolamasında değil) ve sonraki Slack API çağrılarında Authorization: Bearer xoxb-... olarak kullanırsınız. Tüm işlem birkaç yüz milisaniye sürer; kullanıcı tek bir onay ekranı görür ve uygulamanıza hiçbir zaman Slack şifresi yazmaz.

Ne zaman ve neden önem taşır

OAuth yanlış yapılandırmaları, modern web güvenliğinde en çok istismar edilen kategorilerden biridir. Yaygın hata modları: state parametresini doğrulamamak (callback'te CSRF'ye kapı açar), redirect_uri kaydında joker karaktere izin vermek (açık yönlendirme yoluyla jeton hırsızlığına yol açar), erişim jetonlarını tarayıcının erişebildiği bir depolama alanında tutmak (XSS ile sızdırılabilir) ve yenileme jetonlarını rotasyon olmadan uzun ömürlü bearer jeton gibi kullanmak. OAuth 2.0 Güvenlik En İyi Güncel Uygulaması (RFC 9700, 2025'te yayımlandı) modern varsayımları kodifiye eder: her yerde PKCE, tam eşleşen yönlendirme URI'ları, yüksek değerli API'ler için gönderici kısıtlı jetonlar (DPoP veya mTLS) ve yeniden kullanım tespitli yenileme jetonu rotasyonu. Bu kurallara uymak, OAuth kalem testi bulgularının büyük bölümünü geçersiz kılar. Kaynak: RFC 9700 — OAuth 2.0 Güvenlik En İyi Güncel Uygulaması.