Pushed Authorization Requests Nedir? OAuth PAR İçin 10 Kritik Kontrol

Pushed Authorization Requests nedir: Hızlı Bakış

Pushed Authorization Requests Nedir? OAuth PAR İçin 10 Kritik Kontrol

1. PAR Endpointini Ayrı Güvenlik Sınırı Olarak Tasarlayın

PAR endpoint yüksek değerli authorization verisi alır.

Rate limit, client authentication, schema doğrulama ve detaylı hata yönetimi gerekir.

2. request_uri Değerini Kısa Ömürlü Tutun

PAR yanıtındaki request_uri uzun süre geçerli bir yetki bileti gibi davranmamalıdır.

Kısa geçerlilik süresi ve tek kullanımlık davranış saldırı penceresini küçültür.

3. Authorization Parametrelerini request_uri Sonrası Değiştirmeyin

Tarayıcı aşamasında yeni scope, redirect_uri veya farklı parametre eklemek bütünlük modelini bozar.

Sunucu işlenecek parametre setini PAR kaydıyla sabitlemelidir.

4. Client Authentication Politikası Belirleyin

Özellikle confidential client ve yüksek güvenlik profillerinde PAR isteği güçlü kimlik doğrulamayla gönderilmelidir.

private_key_jwt veya mTLS gibi yöntemler tehdit modeline göre kullanılabilir.

5. Redirect URI Doğrulamasını Sürdürün

PAR, redirect URI güvenliğini ortadan kaldırmaz.

Sunucu kayıtlı redirect URI ile gelen değeri sıkı biçimde doğrulamalıdır.

6. JAR ile Birlikte Kullanımı Değerlendirin

PAR taşıma kanalını güçlendirirken JAR parametre bütünlüğü ve istemci kaynağı için imzalı Request Object sağlayabilir.

Yüksek riskli akışlarda iki mekanizma birbirini tamamlar.

7. Hassas Parametreleri Loglardan Koruyun

PAR endpoint doğrudan authorization içeriğini gördüğü için loglama hassasiyetini artırır.

Claims, kişisel veri ve özel yetki parametreleri maskelenmelidir.

8. Request Object ve Normal Parametre Çakışmalarını Reddedin

Aynı semantiği farklı kanallardan taşıyan çelişkili parametreler belirsizlik yaratır.

Sunucu deterministik ve standarda uygun precedence uygulamalıdır.

9. Rate Limit ve Abuse Detection Ekleyin

PAR endpoint kullanıcı tarayıcısından bağımsız çağrılabildiği için otomatik kötüye kullanım hedefi olabilir.

İstemci bazlı kota, anomali tespiti ve başarısız deneme metrikleri kullanın.

10. Uçtan Uca Negatif Test Yapın

Süresi dolmuş request_uri, başka client tarafından kullanılan URI, parametre manipülasyonu ve replay test edilmelidir.

Authorization endpoint bu durumlarda kullanıcıya akışı devam ettirmeden güvenli hata vermelidir.

Pushed Authorization Requests nedir: Uygulama Mimarisi

İstemci authorization request parametrelerini doğrudan PAR endpointine gönderir. Authorization Server doğrulama sonrası request_uri ve expires_in benzeri bilgi döndürür. İstemci kullanıcıyı authorization endpointine yönlendirirken uzun parametre seti yerine request_uri referansını kullanır.

Ü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.

Pushed Authorization Requests nedir: Tehdit Modeli Nasıl Kurulmalı?

Pushed Authorization Requests 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 Pushed Authorization Requests nedir mimarisinin tehdit modeli, üretim mimarisi değiştikçe yeniden gözden geçirilmelidir.

Pushed Authorization Requests 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.

Pushed Authorization Requests nedir: Operasyon, Loglama ve Olay Müdahalesi

Üretimde iyi tasarlanmış bir Pushed Authorization Requests 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.

Pushed Authorization Requests 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. Pushed Authorization Requests nedir için doğru mimari, tehdidi anlamlı ölçüde azaltırken ekibin yönetebileceği kadar sade kalan mimaridir.

Pushed Authorization Requests nedir: Sık Yapılan Hatalar

• request_uri değerini uzun ömürlü yapmak
• PAR sonrası tarayıcıda scope veya redirect_uri değiştirmek
• Client authenticationı gevşek bırakmak
• PAR içeriğini tam olarak loglamak
• JAR/PAR parametre çakışmalarını belirsiz bırakmak
• request_uri replay testlerini yapmamak

Pushed Authorization Requests nedir: Sık Sorulan Sorular

PAR nedir?

Authorization request verisini tarayıcıdan önce doğrudan Authorization Server’a gönderen OAuth uzantısıdır.

Hangi RFC’de tanımlıdır?

RFC 9126.

request_uri ne işe yarar?

Sunucuda saklanan authorization request verisine kısa ömürlü bir referans sağlar.

PAR ve JAR aynı mı?

Hayır. PAR taşıma yöntemini, JAR ise request parametrelerinin JWT ile korunmasını tanımlar.

FAPI ile ilişkisi nedir?

Yüksek güvenlikli FAPI profillerinde PAR önemli bir yapı taşıdır.

İlgili İçerikler

OAuth 2.0 Güvenliği

JWT Güvenliği

OpenID Connect Güvenliği

DPoP

FAPI 2.0

Resmî ve Güvenilir Kaynaklar

IETF — RFC 9126 PAR

OpenID Foundation — FAPI 2.0 Security Profile

Sonuç: Pushed Authorization Requests nedir

Pushed Authorization Requests 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.

PAR özellikle karmaşık ve yüksek değerli authorization isteklerini kullanıcı aracısı yüzeyinden uzaklaştırarak daha kontrollü bir giriş noktası oluşturur. 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.