OAuth ve OIDC akışları

"Google Google ile giriş yap" düğmesine bastığınızda arka planda iki standart birlikte çalışır: OAuth 2.0 ve onun üzerine kurulan OpenID Connect (OIDC). Bu derste ikisinin ne işe yaradığını, bugün hangi akışın kullanılması gerektiğini ve token'ların nerede durması gerektiğini göreceksiniz.

OAuth Ne Çözer

OAuth'tan önce bir uygulama Gmail kişilerinize erişmek isterse sizden Gmail parolanızı isterdi. OAuth bu sorunu çözmek için çıktı: kullanıcı parolasını paylaşmadan, bir uygulamaya sınırlı ve geri alınabilir bir erişim izni verir.¹

Akışta dört rol vardır:²

Authorization Code Akışı

Bugün tarayıcıdan başlayan her OAuth girişi için önerilen akış budur:²³

1. Uygulama kullanıcıyı authorization server'ın giriş sayfasına yönlendirir.

2. Kullanıcı orada giriş yapar ve istenen izinleri (scope) onaylar.

3. Authorization server kullanıcıyı redirect_uri adresine kısa ömürlü bir authorization code ile geri gönderir.

4. Uygulama bu kodu authorization server'a gönderip karşılığında access token alır.

5. Uygulama access token ile API'ye istek atar.

İlk yönlendirme bir URL'dir:

https://auth.example.com/authorize
  ?response_type=code
  &client_id=shop-web
  &redirect_uri=https://shop.example.com/callback
  &scope=openid profile email
  &state=af0ifjsldkj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

Geri dönüş de bir URL'dir:

https://shop.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj

Kod tek başına işe yaramaz; token'a çevrilmesi gerekir. state değeri, dönen yanıtın sizin başlattığınız akışa ait olduğunu kontrol etmek içindir (CSRF koruması).³

PKCE

PKCE (Proof Key for Code Exchange, "piksi" diye okunur), authorization code'u ele geçiren birinin onu token'a çevirmesini engeller.⁴

1. Uygulama rastgele bir code_verifier üretir ve saklar.

2. Bunun SHA-256 hash'ini code_challenge olarak ilk yönlendirmeye ekler.

3. Kodu token'a çevirirken orijinal code_verifier'ı gönderir. Authorization server hash'leri karşılaştırır.

Kodu yolda yakalayan saldırganın elinde code_verifier yoktur, bu yüzden kodu kullanamaz.⁵ Web Crypto API ile üretimi birkaç satırdır:

function base64url(bytes: Uint8Array) {
  return btoa(String.fromCharCode(...bytes))
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/, "");
}

export function createCodeVerifier() {
  return base64url(crypto.getRandomValues(new Uint8Array(32)));
}

export async function createCodeChallenge(codeVerifier: string) {
  const data = new TextEncoder().encode(codeVerifier);
  const digest = await crypto.subtle.digest("SHA-256", data);
  return base64url(new Uint8Array(digest));
}

createCodeChallenge("dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk") çağrısı, RFC 7636'daki örnekle aynı sonucu verdi: E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM.⁵ Gerçek projede bunu kendiniz yazmazsınız; auth kütüphanesi yapar. Yine de bir kütüphanenin PKCE kullandığından emin olun.

Artık Kullanılmayan Akışlar

OAuth 2.0 güvenlik önerilerini toplayan RFC 9700 (Ocak 2025) bazı eski akışları açıkça bırakır:³

RFC 9700 ayrıca redirect_uri'nin tam eşleşmeyle kontrol edilmesini ve access token'ın belirli bir API'ye (audience) bağlanmasını ister.³ Bu değişiklikleri tek belgede toplayan OAuth 2.1 hâlâ taslak aşamasında.⁶

OpenID Connect

OIDC, OAuth'un üzerine ince bir kimlik katmanı ekler. Akış aynıdır; farkı, scope içinde openid istenmesi ve yanıtta access token'ın yanında bir ID token gelmesidir.⁷⁸

ID token bir JWT'dir (JWT'yi Oturum, cookie ve JWT dersinde gördük). İçinde kimin, ne zaman ve hangi uygulama için giriş yaptığı yazar:⁸

{
  "iss": "https://auth.example.com",
  "sub": "248289761001",
  "aud": "shop-web",
  "exp": 1792323192,
  "iat": 1792319592,
  "nonce": "n-0S6_WzA2Mj",
  "email": "ayse@example.com"
}

Kullanıcıyı veritabanınızda e-postayla değil, iss + sub ikilisiyle eşleştirin.⁸

Access Token ve ID Token

İki token sık karıştırılır. oauth.net'teki kural kısa: ID token API'ye gönderilmez, access token'ı da istemci okumaz.⁹

Token Nerede Durmalı

Ağustos 2026'da yayımlanan RFC 10017, tarayıcı uygulamaları için üç mimari tarif eder ve bunları güvenlik sırasına koyar.¹⁰ Belgenin yazarları arasında Aaron Parecki ve Philippe De Ryck de var.

Gerekçe basit: sayfada çalışan kötü niyetli bir script, uygulamanın kendi kodu ile aynı yetkilere sahiptir. Token tarayıcıdaysa onu çalabilir ya da yenisini alabilir.¹⁰ Next.js Next.js gibi sunucusu olan bir framework'te BFF zaten doğal yapıdır. Auth.js ya da Better Auth gibi kütüphaneler OAuth akışını sunucuda yürütür ve tarayıcıya yalnızca oturum cookie'si verir.

Kendin Dene

• Giriş yaparken DevTools > Network sekmesini açık tutun ve "Google ile giriş" yapan bir sitede authorize isteğini bulun. response_type, scope ve state parametrelerine bakın; PKCE kullanan sitelerde code_challenge da görürsünüz.

• Yukarıdaki createCodeChallenge fonksiyonunu tarayıcı konsolunda çalıştırıp RFC 7636'daki örnek değeri elde edin.

• Kendi kimlik sağlayıcınızın /.well-known/openid-configuration adresini açın; authorization_endpoint, token_endpoint ve desteklenen code_challenge_methods_supported alanlarını bulun.

Detaylı Öğrenmek İçin

• Video: David Neal, "An Illustrated Guide to OAuth and OpenID Connect" (16 dk); akışın çizimlerle anlatımı.²

• Konuşma: Aaron Parecki, "Why Do We Really Need OAuth?" (OWASP NZ 2022); OAuth'un çözdüğü sorun ve bugünkü akışlar.¹

• Resmi doküman: RFC 10017, OAuth 2.0 for Browser-Based Applications; BFF ve tarayıcıdaki saldırı senaryoları.¹⁰

• Resmi doküman: RFC 9700, OAuth 2.0 Security Best Current Practice.³