Özellikle public client senaryolarında authorization code interception riskini azaltmak için tasarlanmış olsa da modern OAuth güvenlik yaklaşımında daha geniş kullanım alanına sahiptir. Bu rehber, PKCE nedir konusunu standart tanımı, tehdit modeli, uygulanabilir kontroller, sık hatalar ve mimari kararlarla birlikte ele alır.
Rank Math açısından odak ifade başlık, giriş, alt başlıklar, sonuç ve görsel ALT alanında doğal biçimde kullanılmıştır. Teknik doğruluk için birincil kaynak olarak IETF RFC’leri ve OpenID Foundation dokümanları esas alınmıştır.
PKCE nedir: Hızlı Bakış
| Kontrol Alanı | Temel Amaç |
|---|---|
| code_verifier | İstemcide üretilen yüksek entropili sır |
| code_challenge | Verifier üzerinden türetilen değer |
| S256 | Önerilen challenge yöntemi |
| Token isteği | Verifier ile kodun kanıtlanması |
| Amaç | Ele geçirilen authorization code replay riskini azaltmak |
PKCE Nedir? OAuth Authorization Code İçin 10 Güçlü Güvenlik Kontrolü
1. Her Yetkilendirme İsteğinde Yeni Verifier Üretin
Code verifier oturumdan oturuma yeniden kullanılmamalıdır.
Tek kullanımlık ve yüksek entropili değer, saldırganın önceki akıştan yararlanmasını zorlaştırır.
2. S256 Kullanımını Zorunlu Tutun
PKCE code challenge için S256 yöntemi güvenli varsayılan olmalıdır.
Plain yöntemiyle geniş uyumluluk uğruna güvenlik seviyesini düşürmekten kaçının.
3. Verifier’ı Tarayıcıya veya Loglara Sızdırmayın
Verifier akışın istemci tarafındaki gizli kanıtıdır.
URL, analytics, hata logu veya üçüncü taraf script üzerinden sızması PKCE korumasını zayıflatır.
4. Authorization Code ile Verifier Bağını Tek Kullanımlı Yapın
Authorization Server code oluştururken challenge değerini o code ile ilişkilendirmelidir.
Code kullanıldıktan sonra tekrar token alınmasına izin verilmemelidir.
5. Redirect URI Kontrolünü PKCE’ye Bırakmayın
PKCE yanlış redirect URI kaydı veya açık yönlendirme problemlerini çözmez.
Redirect URI exact matching ve istemci kaydı ayrı zorunlu güvenlik katmanıdır.
6. State ve OIDC Nonce Kontrollerini Koruyun
PKCE farklı tehditleri azaltır; CSRF ve OIDC replay bağlamını tek başına çözmez.
state ve gerektiğinde nonce gibi bağlam doğrulamaları akış tasarımında korunmalıdır.
7. Public Client’larda Client Secret’a Güvenmeyin
Mobil ve SPA gibi public client uygulamalarında gömülü secret gerçek bir sır değildir.
PKCE bu istemcilerde Authorization Code Flow güvenliğinin temel parçalarından biri olmalıdır.
8. Confidential Client’larda da PKCE’yi Kullanın
Client authentication yapılması PKCE ihtiyacını tamamen ortadan kaldırmaz.
Katmanlı güvenlik yaklaşımı code injection ve interception senaryolarına karşı ek bağ sağlar.
9. Verifier Entropisini Doğru Seçin
Tahmin edilebilir, kısa veya kullanıcıdan türetilmiş verifier değerleri kullanılmamalıdır.
Kriptografik güvenli rastgele üretici tercih edilmelidir.
10. Negatif Akışları Test Edin
Yanlış verifier, farklı challenge, tekrar kullanılan code ve eksik PKCE parametreleri test edilmelidir.
Sunucunun bu durumları token vermeden reddettiği otomatik testlerle doğrulanmalıdır.
PKCE nedir: Uygulama Mimarisi
İstemci önce rastgele bir code_verifier üretir, S256 ile code_challenge türetir ve authorization request içinde challenge gönderir. Authorization Server code ile challenge değerini bağlar. Token isteğinde istemci code_verifier gönderir; sunucu aynı dönüşümü yapıp eşleşme varsa token üretir.
Üretim ortamında yalnızca protokolün desteklenmesi yeterli değildir. Authorization Server, istemci, Resource Server, anahtar veya sertifika yaşam döngüsü, loglama, hata davranışı ve geri dönüş senaryoları birlikte test edilmelidir. Güvenlik kontrolü yalnızca başarılı istekte değil; geçersiz imza, yanlış audience, süresi dolmuş değer, tekrar kullanılan artefakt ve beklenmeyen istemci davranışında da doğru şekilde reddetmelidir.
PKCE nedir: Tehdit Modeli Nasıl Kurulmalı?
PKCE nedir için ilk adım, protokol özelliğini açmaktan önce hangi saldırıyı azaltmak istediğinizi açıkça tanımlamaktır. Authorization Code ele geçirme, token replay, request parametresi manipülasyonu, istemci taklidi, phishing, cihaz kodu kötüye kullanımı veya servisler arası yetki genişlemesi gibi risklerin her biri farklı kontrol gerektirir. Aynı güvenlik özelliğini her probleme çözüm gibi uygulamak hem gereksiz karmaşıklık yaratır hem de gerçek açığın gözden kaçmasına neden olabilir.
Tehdit modeli hazırlanırken istemci türünü, tarayıcı veya cihaz yeteneklerini, Authorization Server ile Resource Server arasındaki güven sınırlarını, reverse proxy ve API gateway katmanlarını, anahtarların nerede üretildiğini ve hangi bileşenlerin hassas artefaktlara erişebildiğini belgeleyin. Özellikle OAuth akışlarında bir parametrenin güvenli kanaldan gelmesi, o parametrenin otomatik olarak yetkili olduğu anlamına gelmez; issuer, audience, redirect URI, client kimliği, scope ve bağlam kontrolleri birlikte düşünülmelidir.
Risk değerlendirmesini yalnız tasarım aşamasında bırakmayın. Yeni mobil uygulama, yeni API, farklı bir identity provider, service mesh geçişi veya reverse proxy değişikliği güven sınırlarını değiştirebilir. Bu nedenle PKCE nedir mimarisinin tehdit modeli, üretim mimarisi değiştikçe yeniden gözden geçirilmelidir.
PKCE nedir: Test Kontrol Listesi
- Standartta zorunlu olan parametreleri ve doğrulama adımlarını otomatik test edin.
- Negatif testlerde bozuk imza, yanlış issuer/audience, tekrar kullanımı ve süresi dolmuş değerleri deneyin.
- Authorization Server metadata ve istemci kayıtlarının üretim yapılandırmasıyla uyumunu doğrulayın.
- Secret, private key ve sertifikaları uygulama koduna gömmeyin; güvenli anahtar yönetimi kullanın.
- Loglarda token, authorization code, verifier, private key veya hassas kişisel verileri düz metin tutmayın.
- Rate limit ve anomali izleme ile protokol uç noktalarını kötüye kullanıma karşı gözlemleyin.
- Hata mesajlarının saldırgana gereksiz ayrıntı sızdırmadığını kontrol edin.
- Standart güncellemelerini ve güvenlik BCP değişikliklerini periyodik takip edin.
Test otomasyonu yalnız “happy path” senaryosuna odaklanmamalıdır. Aynı isteği ikinci kez kullanmak, farklı client_id ile tekrar göndermek, başka audience hedeflemek, yanlış anahtar veya sertifika kullanmak, süresi dolmuş artefakt sunmak ve parametreleri beklenmeyen kombinasyonlarla göndermek gibi saldırgan davranışları da CI/CD güvenlik testlerine ekleyin. Böylece uygulama ekibi protokol kütüphanesini güncellediğinde güvenlik davranışının gerilemediğini hızlıca görebilir.
PKCE nedir: Operasyon, Loglama ve Olay Müdahalesi
Üretimde iyi tasarlanmış bir PKCE nedir uygulaması, reddedilen isteğin nedenini operasyon ekibine gösterebilmeli fakat saldırgana veya log sistemine gereksiz sır sızdırmamalıdır. Hata kategorilerini; imza/anahtar doğrulama, istemci eşleşmesi, issuer-audience, süre, replay, scope ve biçim hatası gibi ayrı metriklerle izlemek sorun çözme süresini ciddi biçimde azaltır.
Loglara ham access token, refresh token, authorization code, device code, private key, client secret veya kişisel veri yazmak yerine korelasyon kimliği, anonimleştirilmiş client kimliği, endpoint, hata sınıfı ve zaman damgası gibi operasyonel verileri tercih edin. Güvenlik olayında aynı artefaktın birden fazla IP, cihaz veya sertifika bağlamından kullanılması gibi anormallikleri ilişkilendirebilmek için merkezi gözlemlenebilirlik önemlidir.
Anahtar ya da sertifika sızıntısı, yanlış client kaydı veya yanlış yapılandırma tespit edildiğinde ne yapılacağı önceden belirlenmelidir. İptal, rotasyon, token geçersizleştirme, istemciyi devre dışı bırakma ve olay sonrası doğrulama adımlarını runbook hâline getirmek, güvenlik özelliğinin yalnızca tasarım belgesinde kalmasını engeller.
PKCE nedir: Uygulama Öncesi Karar Kontrolü
Bu mekanizmayı seçmeden önce mevcut OAuth kütüphanenizin ilgili standardı tam ve doğru desteklediğini, istemci tipinizin gerekli kriptografik işlemleri güvenli biçimde yapabildiğini ve Resource Server tarafında gereken doğrulama bağlamının kaybolmadığını kontrol edin. Standart desteği eksikse protokolü elle üretmek yerine olgun, güncel ve test edilmiş kütüphaneler kullanmak daha güvenlidir.
Son olarak performans, kullanılabilirlik ve operasyon maliyetini de hesaba katın. Ek imza doğrulaması, sertifika yönetimi, yeni endpoint veya kısa ömürlü artefaktlar güvenlik kazancı sağlarken dağıtım ve gözlem karmaşıklığını artırabilir. PKCE nedir için doğru mimari, tehdidi anlamlı ölçüde azaltırken ekibin yönetebileceği kadar sade kalan mimaridir.
PKCE nedir: Sık Yapılan Hatalar
- Aynı verifierı birden fazla akışta kullanmak
- plain challenge yöntemini varsayılan bırakmak
- Verifierı URL veya telemetry loguna yazmak
- Redirect URI kontrolünü atlamak
- PKCE varken state/nonce gereksiz sanmak
- Mobil uygulamaya gömülü client secretı gerçek sır kabul etmek
PKCE nedir: Sık Sorulan Sorular
PKCE nedir?
Authorization Code akışında kodu başlatan istemci ile kodu tokena çeviren istemciyi code verifier üzerinden bağlayan OAuth uzantısıdır.
PKCE hangi RFC’de tanımlıdır?
RFC 7636.
S256 nedir?
Code verifier üzerinden SHA-256 tabanlı code challenge üretme yöntemidir.
PKCE client secret yerine geçer mi?
Hayır. Client authentication ile farklı güvenlik amaçlarına hizmet eder.
SPA ve mobil uygulamalarda kullanılır mı?
Evet, özellikle public client senaryolarında temel güvenlik kontrolüdür.
İlgili İçerikler
Resmî ve Güvenilir Kaynaklar
IETF — RFC 9700 OAuth Security BCP
Sonuç: PKCE nedir
PKCE nedir doğru uygulandığında OAuth tabanlı mimarilerde belirli bir saldırı yüzeyini küçültür; ancak tek başına bütün güvenlik problemlerini çözmez. En güçlü sonuç, PKCE, güçlü client authentication, sender-constrained token, sıkı redirect URI kontrolü, kısa ömürlü artefaktlar, anahtar yönetimi ve kapsamlı gözlemlenebilirlik ile birlikte kullanıldığında elde edilir.
PKCE küçük görünen iki parametreyle authorization code akışının önemli bir saldırı yüzeyini daraltır. Bu nedenle tasarım kararını yalnızca “özellik açık mı?” sorusuyla değil, tehdit modelinizde hangi riski azalttığı ve yanlış yapılandırıldığında hangi yeni riski oluşturabileceği üzerinden değerlendirin.
