OAuth2 akışları

Önceki dersler tek bir uygulamanın kendi kullanıcısını tanımasını anlattı. OAuth2 farklı bir soruyu çözer: bir uygulama, kullanıcının başka bir sistemdeki verisine, kullanıcının parolasını hiç görmeden nasıl erişir? Cevap, kullanıcının kimlik sağlayıcıda oturum açması ve uygulamaya sınırlı bir erişim jetonu verilmesidir. Bu ders rolleri, iki kritik ucu ve akışları — authorization code + PKCE'yi merkeze koyarak — anlatıyor; sonunda da en sık yapılan kavram hatasını düzeltiyor: OAuth2 yetkilendirmedir, kimlik doğrulama değildir.

01Ne öğreneceksin

02Hangi problemi çözüyor?

OAuth2 öncesi dünyada bir uygulamanın senin adına başka bir sistemden veri çekmesinin tek yolu vardı: o sistemdeki parolanı ona vermek. Bu yaklaşımın dört ayrı sorunu vardır ve dördü de OAuth2'nin tasarım gerekçesidir.

• Sınırsız erişim: parolayı alan uygulama her şeyi yapabilir; yalnızca takvimini okumak isteyen uygulama e-postanı da silebilir.
• Geri alınamaz: erişimi kesmenin tek yolu parolayı değiştirmektir — ve bu, parolayı verdiğin tüm uygulamaları düşürür.
• Çoğaltma: parola artık üçüncü tarafın veritabanındadır; oradaki bir sızıntı seni de vurur.
• MFA ile uyumsuz: ikinci faktör varsa üçüncü taraf zaten giriş yapamaz.

OAuth2'nin çözümü delegasyondur: kullanıcı kimlik sağlayıcıda kendi oturumunu açar, uygulamaya yalnızca sınırlı kapsamda ve süreli bir erişim jetonu verilir. Parola hiçbir zaman uygulamaya gitmez ve kullanıcı izni tek tek geri alabilir. Kurumsal ve kamu ortamlarında aynı mekanizma tek oturum açma (SSO) için kullanılır: onlarca iç uygulama kendi parola yönetimini yapmaz, merkezi bir kimlik sağlayıcıya yaslanır — bu, 1. dersteki "saldırı yüzeyini küçült" ilkesinin kurumsal ölçekteki uygulamasıdır.

03Roller ve iki uç

Yetkilendirme sunucusunun iki ucu vardır ve ikisinin doğası tamamen farklıdır — bu ayrım akışları anlamanın anahtarıdır:

• /authorize — tarayıcıda ziyaret edilir. Kullanıcı buraya yönlendirilir, giriş yapar, izin ekranını görür. Ön kanal (front channel): adres çubuğundan geçer, yani URL'deki her şey kullanıcı ve tarayıcı geçmişi tarafından görülebilir.
• /token — sunucudan sunucuya çağrılır. Kod jetona burada dönüştürülür. Arka kanal (back channel): TLS ile korunur ve tarayıcıya hiç uğramaz.

Bir de istemci türü ayrımı vardır. Gizli istemci (confidential) bir sır saklayabilir: sunucuda çalışan bir uygulama, arka uç. Açık istemci (public) saklayamaz: tarayıcıda çalışan SPA ve mobil uygulama — ikisinin de kodu kullanıcının cihazındadır, "gömülü sır" diye bir şey yoktur (1. dersteki güvenlik teatrali başlığı). Bu ayrım, hangi akışın kullanılacağını doğrudan belirler.

04Authorization code + PKCE

Bugünün varsayılan akışıdır ve her istemci türü için önerilir — SPA, mobil ve sunucu uygulaması dâhil. Temel fikir şudur: tarayıcıdan geçen ön kanalda jeton değil, tek kullanımlık kısa ömürlü bir kod taşınır; kod jetona arka kanalda çevrilir.

1) İstemci hazırlık (tarayıcıda):
   code_verifier  = rastgele 43-128 karakter        (gizli tutulur, bellekte kalır)
   code_challenge = base64url( SHA-256(code_verifier) )
   state          = rastgele değer                   (CSRF savunması; oturuma bağlanır)

2) Kullanıcı /authorize'a YÖNLENDİRİLİR  (ön kanal — tarayıcı)
   GET /authorize?response_type=code
       &client_id=basvuru-portali
       &redirect_uri=https://portal.ornek.gov.tr/geri-donus
       &scope=basvuru.oku basvuru.yaz
       &state=xyz123
       &code_challenge=E9Melhoa...&code_challenge_method=S256

3) Kullanıcı kimlik sağlayıcıda giriş yapar + izin ekranını onaylar
   (parola İSTEMCİYE HİÇ GİTMEZ)

4) Geri yönlendirme (ön kanal):
   https://portal.ornek.gov.tr/geri-donus?code=SplxlOB...&state=xyz123
   ↑ İstemci ÖNCE state'i doğrular; eşleşmiyorsa akış durdurulur

5) Kod → jeton (ARKA KANAL — sunucudan sunucuya, TLS)
   POST /token
     grant_type=authorization_code&code=SplxlOB...
     &redirect_uri=https://portal.ornek.gov.tr/geri-donus
     &client_id=basvuru-portali&code_verifier=<1. adımdaki gizli değer>

6) Yanıt:  { access_token, token_type: "Bearer", expires_in: 900, refresh_token, scope }

PKCE tam olarak neyi çözüyor? Sorun şudur: kod ön kanaldan, yani tarayıcının adres çubuğundan geçer. Mobil ve masaüstü dünyasında bu yönlendirmeyi başka bir uygulama yakalayabilir (kötü niyetli bir uygulama aynı URL şemasına kaydolmuş olabilir); web tarafında kod sunucu loglarına ya da Referer başlığına düşebilir. PKCE (Proof Key for Code Exchange) kodu tek başına işe yaramaz hâle getirir: kodu jetona çevirmek için, kodu talep eden tarafın elindeki code_verifier de gereklidir ve o değer hiçbir zaman ön kanaldan geçmemiştir. Kodu çalan saldırgan code_verifier'ı bilemez.

PKCE önce mobil için tasarlandı, sonra SPA'lar için zorunlu hâle geldi, bugün ise gizli istemcilerde bile önerilir — çünkü kod ele geçirme saldırısı istemci sırrından bağımsız bir yüzeydir.

state ile PKCE karıştırılmamalıdır ve bu ayrım sınavda ayırt edicidir: state CSRF savunmasıdır — saldırganın kendi yetkilendirme kodunu kurbanın tarayıcısına enjekte etmesini engeller (oturum karıştırma). code_verifier ise kod ele geçirme savunmasıdır. İkisi farklı saldırılara bakar, ikisi de kullanılır.

05Diğer akışlar ve ölen akışlar

Implicit neden öldü? Bu akışta jeton doğrudan ön kanaldan, URL fragment'ı içinde dönüyordu. Sonuç: erişim jetonu tarayıcı geçmişine, sunucu loglarına ve genişletmelere maruz kalıyor; ayrıca yenileme jetonu verilemediği için kısa ömürlülük çözümü de yoktu. PKCE'li kod akışı, SPA'lar için hem daha güvenli hem daha yeteneklidir; implicit'in tek gerekçesi olan "SPA arka kanal çağrısı yapamaz" varsayımı CORS ile geçersiz kaldı.

ROPC neden öldü? Bu akışta kullanıcı parolasını doğrudan uygulamaya yazıyordu ve uygulama onu yetkilendirme sunucusuna iletiyordu — yani OAuth2'nin var oluş sebebini ortadan kaldırıyordu. MFA, federasyon ve kimlik sağlayıcı politikalarıyla da uyumsuzdur. Eski sistem göçlerinde nadiren ve geçici olarak görülür; yeni tasarımda gerekçesi yoktur.

Client credentials'ın kritik farkı: ortada kullanıcı yoktur. Jeton "uygulama X" demektir, "kullanıcı 42" demez. Bu jetonu alan bir servis kullanıcı adına iş yapıyormuş gibi davranırsa tüm kullanıcı verisine erişebilen bir süper kimlik üretmiş olursun. Kural: makine jetonunun kapsamı dar tutulur ve kullanıcı bağlamı gerektiren işlemler için kullanılmaz.

06Yönlendirme adresi, kapsam ve izin

redirect_uri tam eşleşme ile doğrulanır. Yetkilendirme sunucusu, istemci kaydında önceden tanımlanmış adreslerden birine birebir uymayan hiçbir adrese yönlendirme yapmamalıdır. Joker karakter, önek eşleşmesi ya da "alt yol serbest" kuralı, açık yönlendirme zafiyeti üretir: saldırgan redirect_uri=https://portal.ornek.gov.tr/geri-donus/../../disari?hedef=kotu.example benzeri bir adresle kodu kendi sunucusuna aktarabilir. Aynı sebeple uygulamanın içinde de "geri dönüş adresi" parametreleri beyaz listeyle sınırlanır.

Kapsam (scope), jetonun ne yapabileceğini sınırlar: basvuru.oku, belge.yaz. İki ilke geçerlidir. Birincisi en az yetki: uygulama yalnızca ihtiyaç duyduğu kapsamları ister; "her ihtimale karşı" geniş kapsam istemek, kullanıcının izin ekranında gördüğü listeyi büyütür ve jeton çalındığında zararı artırır. Artımlı izin deseni buna cevaptır: başlangıçta minimum kapsam istenir, kullanıcı ilgili özelliği kullanmaya kalktığında ek kapsam istenir.

İkincisi ve daha önemlisi: kapsam yetkilendirmenin yerini tutmaz. Kapsam, istemcinin ne isteyebileceğini söyler; kullanıcının ne yapmaya hakkı olduğunu söylemez. basvuru.oku kapsamlı bir jetonla gelen istek, kaynak sunucuda hâlâ şu soruyu geçmelidir: bu kullanıcı bu başvurunun sahibi mi? 3. dersteki IDOR bölümü burada aynen geçerlidir — kapsam kontrolü onun yerine geçmez, üstüne eklenir. Bu, "her servis kendi kararını verir" (12-12) kuralının OAuth2 tarafındaki karşılığıdır.

İzin ekranı (consent) kullanıcının delegasyonu onayladığı yerdir. Kurumsal SSO'da genellikle yönetici tarafından önceden onaylanır. Kullanıcıya gösterilen metnin anlaşılır olması bir güvenlik özelliğidir: teknik kapsam adları listelenirse kullanıcı ne onayladığını bilmez — 1. dersteki psikolojik kabul edilebilirlik ilkesi.

07Kaynak sunucu jetonu nasıl doğrular?

İki yöntem vardır ve seçim, 5. dersteki iptal tartışmasının aynısıdır:

Yerel doğrulamada açık anahtar JWKS ucundan alınır — kimlik sağlayıcının yayınladığı, açık anahtarları içeren bir JSON belgesi. Üç üretim ayrıntısı vardır ve üçü de sahada sorun çıkarır:

• Önbellekleme şart. Her istekte JWKS çekmek, kimlik sağlayıcıyı kendi trafiğinle boğar. Uygulama anahtarları önbellekler.
• Ama sonsuza kadar değil. Anahtar döndürüldüğünde (yeni kid) uygulama bilmediği bir kid görürse JWKS'i bir kez yeniden çekmelidir. Bu tazeleme yoksa, sağlayıcı anahtar döndürdüğü an tüm doğrulamalar patlar.
• Tazeleme oran sınırlı olmalıdır. Aksi hâlde geçersiz jeton yağmuru, her istekte bir JWKS çağrısı tetikler ve kendi kendine hizmet engelleme üretir — 12-12'deki uçuşta tekilleştirme ve önbellek çığı deseni burada aynen uygulanır.

Ve 5. dersin en sık atlanan kontrolü OAuth2 bağlamında daha da kritiktir: aud doğrulanmalıdır. Aynı kimlik sağlayıcıdan jeton alan başka bir API'nin jetonu, senin API'nde çalışmamalıdır. Aksi hâlde o API'ye jeton alabilen herkes seninkine de girer. Kapsam kontrolüyle birlikte bu ikisi, kaynak sunucunun asgari kontrol listesidir.

08En sık kavram hatası: OAuth2 kimlik doğrulama değildir

Cümle şudur: OAuth2 bir yetkilendirme (delegasyon) protokolüdür; kullanıcı kimliğini bildirmek için tasarlanmamıştır. Erişim jetonu, kaynak sunucuya "bu istemcinin şu kapsamda erişim hakkı var" der. İstemciye kullanıcının kim olduğunu söylemez ve istemci için hiçbir garanti içermez.

Bunu yanlış anlayan klasik desen şöyledir: uygulama bir erişim jetonu alır, onunla bir "profil" ucunu çağırır, dönen kullanıcı kimliğine bakıp "demek ki bu kullanıcı giriş yaptı" der. Zafiyet burada: erişim jetonu bir taşıyıcı (bearer) kimlik bilgisidir — nereden geldiğinin bir kanıtı yoktur. Kötü niyetli bir uygulama, kendi kullanıcısından aldığı geçerli bir erişim jetonunu alıp senin uygulamana sunabilir; senin uygulaman profili çeker, kimliği görür ve o kullanıcı olarak oturum açar. Buna jeton değiştirme (token substitution) saldırısı denir.

Eksik olan şey, istemciye hitaben verilmiş, imzalı, hedef kitlesi belirtilmiş bir kimlik belgesidir. OAuth2'nin üstüne inşa edilen OpenID Connect tam olarak bunu ekler: id_token — aud alanı senin client_id'ne eşit olan, nonce ile isteğe bağlanan bir JWT. Bir sonraki ders (guv-oidc) bunu ve kimlik sağlayıcı kavramını işleyecek. Şimdilik akılda kalması gereken tek cümle: "Google ile giriş yap" OAuth2 değil, OIDC'dir; erişim jetonuyla kullanıcı doğrulanmaz.

09Mini alıştırma — akışı kâğıtta kur, PKCE'yi hesapla

10Kendini sına

OAuth2 hangi problemi çözer; dört rol ve iki uç nedir? Gizli ve açık istemci ayrımı neyi belirler?

Parola paylaşımının dört sorununu çözer: sınırsız erişim, geri alınamazlık, parolanın üçüncü tarafa çoğaltılması ve MFA ile uyumsuzluk. Yerine delegasyon koyar: kullanıcı kimlik sağlayıcıda oturum açar, uygulamaya sınırlı kapsamda ve süreli bir erişim jetonu verilir; parola istemciye hiç gitmez ve izin tek tek geri alınabilir. Roller: kaynak sahibi (kullanıcı), istemci (uygulama), yetkilendirme sunucusu (jetonu veren), kaynak sunucusu (jetonu doğrulayıp veriyi veren API). İki uç: /authorize tarayıcıda ziyaret edilir — ön kanal, adres çubuğundan geçer ve içeriği görülebilir; /token sunucudan sunucuya çağrılır — arka kanal, TLS ile korunur ve tarayıcıya uğramaz. İstemci türü: gizli istemci sır saklayabilir (sunucu uygulaması), açık istemci saklayamaz (SPA ve mobil — kod kullanıcının cihazındadır, "gömülü sır" güvenlik teatralidir). Bu ayrım hangi akışın kullanılacağını belirler.

Authorization code akışının adımlarını anlat. PKCE hangi saldırıyı, state hangi saldırıyı kapatır?

Adımlar: istemci code_verifier üretir ve SHA-256'sını code_challenge olarak hazırlar, bir de state üretip oturumuna bağlar ▸ kullanıcı /authorize'a yönlendirilir (response_type=code, client_id, redirect_uri, scope, state, code_challenge) ▸ kullanıcı kimlik sağlayıcıda giriş yapar ve izin verir — parola istemciye gitmez ▸ redirect_uri'ye code ve state ile dönülür ▸ istemci önce state'i doğrular ▸ arka kanaldan /token'a code + code_verifier gönderip erişim (ve yenileme) jetonunu alır. Ön kanalda jeton değil kod taşınması akışın temel fikridir. PKCE kod ele geçirme saldırısını kapatır: kodu çalan saldırgan ön kanaldan hiç geçmemiş olan code_verifier'ı bilemez, kodu jetona çeviremez. state ise CSRF / oturum karıştırma saldırısını kapatır: saldırganın kendi yetkilendirme kodunu kurbanın tarayıcısına enjekte etmesini engeller. Farklı saldırılara bakarlar; ikisi de kullanılır ve PKCE bugün gizli istemcilerde de önerilir.

Implicit ve ROPC neden terk edildi? client_credentials'ın kritik farkı nedir? redirect_uri nasıl doğrulanır?

Implicit: jeton doğrudan ön kanaldan, URL fragment'ı içinde dönüyordu — erişim jetonu tarayıcı geçmişine, loglara ve genişletmelere maruz kalıyor, üstelik yenileme jetonu verilemediği için kısa ömürlülük çözümü de yoktu. Tek gerekçesi olan "SPA arka kanal çağrısı yapamaz" varsayımı CORS ile geçersiz kaldı; PKCE'li kod akışı hem daha güvenli hem daha yeteneklidir. ROPC: kullanıcı parolasını doğrudan uygulamaya yazıyordu — protokolün var oluş sebebini ortadan kaldırır, MFA ve federasyonla uyumsuzdur. client_credentials: ortada kullanıcı yoktur; jeton "uygulama X" der, "kullanıcı 42" demez. Bu jetonla kullanıcı adına iş yapmak, tüm kullanıcı verisine erişebilen bir süper kimlik üretir; kapsamı dar tutulur ve kullanıcı bağlamı gerektiren işlemlerde kullanılmaz. redirect_uri istemci kaydındaki adreslerle tam eşleşme ile doğrulanır; joker karakter, önek eşleşmesi ya da "alt yol serbest" kuralı açık yönlendirme zafiyeti üretir ve saldırgan kodu kendi sunucusuna aktarabilir.

"Kapsam yetki değildir" ne demek? JWKS ile doğrulamanın üç üretim ayrıntısı nedir? OAuth2 neden kimlik doğrulama değildir?

Kapsam istemcinin ne isteyebileceğini söyler, kullanıcının ne yapmaya hakkı olduğunu söylemez. basvuru.oku kapsamlı geçerli bir jetonla gelen istek, kaynak sunucuda hâlâ "bu kullanıcı bu başvurunun sahibi mi?" sorusunu geçmelidir — kapsam kontrolü IDOR kontrolünün yerine geçmez, üstüne eklenir. JWKS ayrıntıları: (1) açık anahtarlar önbelleklenir, yoksa kimlik sağlayıcı kendi trafiğinle boğulur; (2) bilinmeyen bir kid görüldüğünde JWKS bir kez tazelenir, yoksa sağlayıcı anahtar döndürdüğü an tüm doğrulamalar patlar; (3) tazeleme oran sınırlı olmalıdır, aksi hâlde geçersiz jeton yağmuru her istekte bir JWKS çağrısı tetikler ve kendi kendine hizmet engelleme üretir — 12-12'deki uçuşta tekilleştirme deseni burada uygulanır. Ayrıca aud mutlaka doğrulanır. Kimlik doğrulama değildir: erişim jetonu kaynak sunucuya hitap eder ve bir taşıyıcı kimlik bilgisidir — nereden geldiğinin kanıtı yoktur. Erişim jetonuyla profil çekip "demek bu kullanıcı giriş yaptı" demek, jeton değiştirme saldırısına açıktır: başka bir uygulama kendi kullanıcısından aldığı geçerli jetonu sana sunar. Eksik olan şey, aud'u senin client_id'n olan ve nonce ile isteğe bağlanan imzalı bir kimlik belgesidir — bunu OpenID Connect'in id_token'ı sağlar.

11Sınav köşesi