OAuth 2.0 ve OpenID Connect: Kimlik Doğrulama Rehberi

Bir uygulamada "Google ile giriş yap" butonuna tıkladığınızda arka planda iki ayrı standart devreye girer. Bunlar OAuth 2.0 ve OpenID Connect'tir. İkisi günlük konuşmada sık sık birbirinin yerine kullanılıyor ama aslında farklı sorulara cevap veriyorlar; biri yetkilendirmeyi, diğeri kimlik doğrulamayı çözüyor. Bu yazıda ikisinin ne iş gördüğünü, nasıl birlikte çalıştığını ve pratikte nelere dikkat etmeniz gerektiğini ele alıyorum.

Kimlik Doğrulama ile Yetkilendirme Farkı

Bu iki kavram sık sık birbirine karıştırılıyor ama sordukları soru tamamen farklı. Kimlik doğrulama (authentication) "sen kimsin" sorusuna cevap arıyor; kullanıcının iddia ettiği kişi olup olmadığını doğruluyor. Yetkilendirme (authorization) ise "neye erişebilirsin" sorusuna cevap veriyor; kimliği doğrulanmış bir kullanıcının hangi kaynaklara erişim hakkı olduğunu belirliyor.

Bu ayrım pratikte şöyle çalışıyor. Bir kullanıcı e-posta ve şifresiyle giriş yaptığında önce kimliği doğrulanıyor. Ardından o kullanıcının belirli bir dosyayı görüntüleyip görüntüleyemeyeceği ve hangi API uç noktalarına istek atabileceği, yetkilendirme katmanında karara bağlanıyor. OAuth 2.0 ikinci soruyu çözmek için tasarlandı, OpenID Connect ise birinciyi.

Bu iki kavramı ayrı tutmamak, gerçek projelerde sık görülen bir tasarım hatasına yol açıyor. Ekipler bazen sadece OAuth 2.0 kullanıp kullanıcının "kim" olduğu bilgisini access token içine sıkıştırmaya çalışıyor. Oysa access token, tanımı gereği bir yetki belgesidir; kimlik bilgisini standart biçimde taşımak için tasarlanmamıştır. Bu ihtiyacı OpenID Connect'in ID token'ı karşılıyor. Bu karışıklık, özellikle "sadece OAuth kullanıyoruz, OIDC'ye gerek yok" diyen ekiplerde ortaya çıkıyor. Kimlik bilgisi gerekmeyen, salt API erişimi senaryolarında bu yaklaşım doğru olabilir. Ama kullanıcı girişi söz konusuysa OIDC'yi atlamak, kendi yarı-standart kimlik çözümünü baştan kurmak anlamına geliyor.

OAuth 2.0 ve OpenID Connect'in resmi teknik dokümantasyonuna OAuth.net ve OpenID Foundation sayfalarından ulaşabilirsiniz. RFC 6749 ve OpenID Connect Core spesifikasyonları, protokolün tüm detaylarını içeriyor.

OAuth 2.0 Nasıl Çalışır

OAuth 2.0'ın temel fikri basit. Bir uygulama, kullanıcının şifresini hiç görmeden, kullanıcı adına sınırlı bir erişim token'ı alıyor. Bu işleyiş dört rol üzerinden yürüyor: kaynak sahibi (genellikle kullanıcı), istemci (erişim isteyen uygulama), kaynak sunucusu (verinin bulunduğu API) ve yetkilendirme sunucusu (token'ları veren servis).

En yaygın ve güvenli akış, yetkilendirme kodu akışıdır (authorization code flow). Bu akışta uygulama önce kullanıcıyı yetkilendirme sunucusuna yönlendiriyor. Kullanıcı izin verdikten sonra kısa ömürlü bir kod alıyor ve bu kodu arka planda erişim token'ı ile değiştiriyor:

GET /authorize?
  response_type=code&
  client_id=abc123&
  redirect_uri=https://uygulama.com/callback&
  scope=profile email&
  state=xyz789

Kullanıcı izin verdikten sonra tarayıcı, redirect_uri adresine bir kod ile yönlendiriliyor. Uygulama bu kodu sunucu tarafında, doğrudan token uç noktasına göndererek gerçek erişim token'ına çeviriyor:

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=SPLXlOBeZQQYbYS6WxSbIA&
redirect_uri=https://uygulama.com/callback&
client_id=abc123&
client_secret=gizli_deger

Bu iki aşamalı yapının amacı; erişim token'ının tarayıcı geçmişinde veya URL'de açıkta kalmamasını sağlamak. Kod tek kullanımlık ve genellikle bir dakika içinde geçerliliğini yitiriyor.

Diğer akış türleri de farklı senaryolar için tanımlanmış. Mobil ve tek sayfa uygulamalar için PKCE eklenmiş yetkilendirme kodu akışı, sunucudan sunucuya iletişim için ise client credentials akışı kullanılıyor. Kullanıcı etkileşimi olmayan, iki sistemin doğrudan birbiriyle konuştuğu senaryolarda client credentials akışı tercih ediliyor; çünkü orada bir "kaynak sahibi" kullanıcı yok, sadece iki servis var. Eskiden mobil uygulamalarda kullanılan implicit akış, token'ı doğrudan URL parçasında döndürüyordu. Bu yöntem, token'ın tarayıcı geçmişinde ve yönlendirme zincirinde açığa çıkmasına yol açtığı için artık önerilmiyor. Bugün neredeyse tüm istemci türleri için PKCE'li yetkilendirme kodu akışı tercih ediliyor.

İzinler ve Token Yönetimi

Scope (izin) parametresi, uygulamanın hangi kaynaklara erişim istediğini tanımlıyor. Bir uygulama yalnızca "profile" izni istiyorsa kullanıcının e-postasına veya takvim verisine erişemiyor. Bu, en az ayrıcalık ilkesinin OAuth 2.0'daki karşılığı. İyi bir güvenlik pratiği, uygulamanın gerçekten ihtiyaç duyduğu izinlerden fazlasını hiç talep etmemesi.

Token türleri arasındaki fark da kritik:

Access token'ın kısa ömürlü olması bilinçli bir tasarım kararı. Bir token ele geçirilse bile saldırganın kullanım penceresi dar kalıyor. Refresh token'lar ise güvenli biçimde saklanmalı; çünkü uzun ömürlü olmaları, ele geçirildikleri durumda daha büyük risk taşıdıkları anlamına geliyor.

Refresh token rotasyonu, bu riski daha da azaltan bir teknik. Her yenileme isteğinde eski refresh token geçersiz kılınıyor ve yerine yenisi veriliyor. Bir saldırgan çalınmış bir refresh token'ı kullanmaya çalıştığında, gerçek kullanıcının bir sonraki yenileme isteği başarısız oluyor. Bu tutarsızlık, sistem tarafında şüpheli aktivite olarak işaretlenebilir.

OpenID Connect Kimlik Katmanı Ekliyor

OpenID Connect (OIDC), OAuth 2.0'ın üzerine inşa edilmiş bir kimlik doğrulama katmanı. OAuth 2.0 tek başına "bu uygulamaya şu kaynaklara erişim izni verildi" diyor ama kullanıcının kim olduğu hakkında standart bir bilgi taşımıyor. OIDC bu boşluğu ID token ile dolduruyor. Bu token, JWT (JSON Web Token) formatında kullanıcı kimliğini taşıyan imzalı bir veri paketi.

Bir ID token'ın içeriği kabaca şöyle görünür:

{
  "sub": "110169484474386276334",
  "email": "[email protected]",
  "email_verified": true,
  "name": "Ali Veli",
  "iss": "https://accounts.google.com",
  "aud": "abc123",
  "exp": 1735689600
}

sub alanı kullanıcının benzersiz kimliğini gösteriyor, iss token'ı hangi servisin verdiğini, exp ise geçerlilik süresini belirtiyor. Uygulama bu token'ı aldığında imzasını doğrulayarak sahte bir token olmadığından emin olmalı. Bu doğrulama adımı atlanırsa kimlik doğrulama katmanı tamamen anlamsız hâle geliyor.

aud alanı da göz ardı edilmemeli. Bu alan, token'ın hangi istemci için üretildiğini belirtiyor ve bir uygulamanın başka bir uygulama için üretilmiş token'ı kabul etmemesi gerekiyor. Bu kontrol atlanırsa, bir servise ait geçerli bir token, farklı bir servise karşı yeniden kullanılabilir hâle gelebilir. Buna token yeniden kullanımı (token replay) saldırısı deniyor.

OIDC'nin en yaygın kullanım alanı tek oturum açma (SSO). Bir kullanıcı bir kez giriş yaptığında, aynı kimlik sağlayıcıyı kullanan diğer uygulamalara tekrar şifre girmeden geçebilir. Kurumsal ortamlarda bu, hem kullanıcı deneyimini hem de parola yönetimi yükünü doğrudan etkiliyor.

Discovery uç noktası (/.well-known/openid-configuration), OIDC'nin geliştirici deneyimini kolaylaştıran pratik bir özellik. Bu adrese yapılan bir istek, yetkilendirme sunucusunun tüm uç nokta adreslerini, desteklenen imzalama algoritmalarını ve diğer yapılandırma bilgilerini tek bir JSON belgesinde döndürüyor. Bu sayede istemci kütüphaneleri, sunucu adresini elle girmeden kendi kendini yapılandırabilir.

Güvenlik Açısından Dikkat Edilmesi Gerekenler

OAuth 2.0 ve OIDC güçlü standartlar ama yanlış uygulandıklarında ciddi açıklar doğurabilir. Tüm iletişim mutlaka HTTPS üzerinden gitmeli. Şifrelenmemiş bir kanalda token yakalamak, saldırganın o kullanıcı adına istek atmasına yetiyor. redirect_uri değerinin yetkilendirme sunucusunda önceden kayıtlı, tam eşleşen bir adres olması da zorunlu. Gevşek eşleştirme kuralları, açık yönlendirme saldırılarını mümkün kılıyor.

state parametresi, CSRF saldırılarına karşı korunmanın standart yolu. İstek gönderilirken rastgele bir değer üretilip saklanmalı. Geri dönen yanıtta bu değerin aynı olduğu kontrol edilmeli:

const state = crypto.randomUUID();
sessionStorage.setItem('oauth_state', state);
// yönlendirme URL'ine state=... eklenir

// callback'te:
if (params.get('state') !== sessionStorage.getItem('oauth_state')) {
  throw new Error('State uyuşmuyor, istek reddedildi');
}

Kendi OAuth istemci kodunuzu sıfırdan yazmak yerine, dilinizin veya çatınızın olgun ve güncel bir kütüphanesini kullanmak neredeyse her zaman daha güvenli. Bu kütüphaneler PKCE (Proof Key for Code Exchange) gibi ek koruma katmanlarını, token doğrulama mantığını ve bilinen açıkları zaten kapatmış durumda.

PKCE, özellikle mobil ve tek sayfa uygulamalarda client secret'ı güvenli saklayamama sorununu çözüyor. İstemci, isteği başlatmadan önce rastgele bir "code verifier" üretiyor ve bunun hash'lenmiş halini (code_challenge) yetkilendirme isteğine ekliyor. Token isteğinde ise orijinal verifier'ı gönderiyor. Sunucu, ayrı bir gizli anahtara ihtiyaç duymadan, iki değeri karşılaştırarak isteğin gerçekten aynı istemciden geldiğini doğruluyor.

API Güvenliğinde Pratik Kullanım

Modern uygulamalar giderek daha fazla üçüncü taraf API'ye bağlanıyor. OAuth 2.0, bu erişimi standart bir şekilde yönetmenin fiili yöntemi hâline geldi. Bir API'yi OAuth 2.0 ile korumak, yalnızca geçerli token taşıyan isteklerin kaynaklara ulaşmasını garanti ediyor. Token'daki scope bilgisi de hangi uç noktalara erişim verildiğini belirliyor.

Sunucu tarafı bir API isteği tipik olarak şöyle görünür:

curl -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6..." \
     https://api.ornek.com/v1/kullanici/profil

API sunucusu, gelen Bearer token'ını doğrulamalı. İmzasını kontrol etmeli, süresinin dolmadığından emin olmalı ve gerekiyorsa scope kontrolü yapmalı. Bu doğrulama adımlarından herhangi biri atlanırsa, geçersiz veya süresi dolmuş bir token'la bile kaynaklara erişilebilir.

Bu doğrulama işini her istekte elle yapmak yerine, çoğu çatı bunu bir ara katman (middleware) olarak sunuyor. Express, Django veya Spring gibi çatılarda hazır OAuth/OIDC ara katmanları kullanmak, doğrulama mantığının her uç noktada ayrı ayrı ve tutarsız biçimde yazılmasını engelliyor.

Kimlik federasyonu da bu standartların pratik faydalarından biri. Bir kurum, kendi kullanıcı veritabanını yönetmek yerine Google, Microsoft veya kendi kurumsal kimlik sağlayıcısına güvenerek kullanıcıları doğrulatabilir. Bu yaklaşım hem geliştirme yükünü azaltıyor hem de şifre yönetimi sorumluluğunu uzman bir sağlayıcıya devrediyor. Aynı zamanda güvenlik yükünü de dağıtıyor. Parola sızıntısı, çok faktörlü doğrulama ve şüpheli giriş tespiti gibi zor problemleri kendi sisteminizde çözmek yerine, bunları zaten çözmüş bir sağlayıcıya devretmiş oluyorsunuz.

OAuth 2.0'ı yetkilendirme için, OpenID Connect'i kimlik doğrulama için ayrı düşünmek, hangi token'ı ne zaman kullanacağınızı netleştiriyor. Kendi güvenlik kodunuzu yazmak yerine test edilmiş kütüphanelere güvenmek ve state, PKCE gibi koruma mekanizmalarını atlamamak, bu iki standardı güvenli biçimde uygulamanın temelini oluşturuyor.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.