Amaç, tarayıcı üzerinden geçen kritik parametrelerin bütünlüğünü ve istemci kaynağını daha güçlü biçimde korumaktır. Bu rehber, JAR 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.
JAR nedir: Hızlı Bakış
| Kontrol Alanı | Temel Amaç |
|---|---|
| Request Object | Authorization parametrelerini taşıyan JWT |
| JWS | Bütünlük ve istemci kaynak doğrulaması |
| JWE | İsteğe bağlı gizlilik |
| request | JWT’yi doğrudan taşıma |
| request_uri | Request Object’i referansla taşıma |
JAR Nedir? OAuth Request Object İçin 10 Kritik Güvenlik Kontrolü
1. Request Object İçeriğini Tek Kaynak Yapın
Authorization işleme sırasında aynı parametrenin JWT içinde ve dışarıda çelişkili değerler taşımasına izin vermeyin.
Sunucu standarda uygun bir precedence veya reddetme politikası uygulamalıdır.
2. İmza Algoritmalarını Allowlist ile Sınırlandırın
İstemciden gelen alg alanını koşulsuz kabul etmek algoritma karışıklığı riskini artırır.
Kayıtlı client metadata ile uyumlu güçlü algoritmalar seçilmelidir.
3. Issuer ve Audience Claimlerini Doğrulayın
Request Object doğru istemciden ve doğru Authorization Server hedefi için gelmelidir.
iss/aud doğrulaması çapraz istemci ve yanlış sunucu bağlamını önler.
4. exp ve nbf ile Kısa Geçerlilik Kullanın
İmzalı Request Object sonsuza kadar tekrar kullanılabilir olmamalıdır.
Kısa süre ve gerektiğinde jti replay kontrolü uygulayın.
5. Redirect URI ve Scope’u Yine Sunucu Politikasıyla Doğrulayın
İmza, istemcinin istediği her değeri otomatik olarak güvenilir veya yetkili yapmaz.
Request Object içindeki redirect_uri ve scope kayıtlı izinlerle karşılaştırılmalıdır.
6. request_uri Kaynağını Güvenilir Tutun
Request Object referansla alınıyorsa sunucunun keyfi URL fetch yapması SSRF riski doğurabilir.
Ön kayıt, HTTPS ve kontrollü fetch politikası kullanılmalıdır.
7. PAR ile Birlikte Kullanımı Değerlendirin
JAR parametre bütünlüğünü, PAR ise doğrudan backchannel gönderimini sağlar.
Yüksek güvenlik profillerinde imzalı Request Object’i PAR endpoint üzerinden göndermek güçlü birleşimdir.
8. Anahtar Rotasyonunu Planlayın
Client signing key değiştiğinde Authorization Server yeni public keyi güvenilir biçimde alabilmelidir.
Eski anahtarların geçiş süresi ve iptal koşulu tanımlanmalıdır.
9. Hassas Authorization Verisini Gereksiz Açmayın
JWS bütünlük sağlar ancak payload varsayılan olarak okunabilir olabilir.
Gizlilik gerektiren claimler için JWE veya PAR gibi ek mekanizmalar değerlendirilmelidir.
10. Replay ve Manipülasyon Testlerini Otomatikleştirin
Aynı jti ile tekrar, süresi dolmuş Request Object, yanlış audience ve bozuk imza senaryolarını test edin.
Sunucu hiçbir durumda manipüle edilmiş parametrelerle akışı sürdürmemelidir.
JAR nedir: Uygulama Mimarisi
İstemci authorization request parametrelerini JWT claimleri olarak Request Object içine koyar ve imzalar. Bu JWT doğrudan request parametresiyle veya kontrollü request_uri referansıyla Authorization Server’a iletilir. Sunucu imza ve claim doğrulamasından sonra normal authorization sürecine devam eder.
Ü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.
JAR nedir: Tehdit Modeli Nasıl Kurulmalı?
JAR 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 JAR nedir mimarisinin tehdit modeli, üretim mimarisi değiştikçe yeniden gözden geçirilmelidir.
JAR 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.
JAR nedir: Operasyon, Loglama ve Olay Müdahalesi
Üretimde iyi tasarlanmış bir JAR 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.
JAR 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. JAR nedir için doğru mimari, tehdidi anlamlı ölçüde azaltırken ekibin yönetebileceği kadar sade kalan mimaridir.
JAR nedir: Sık Yapılan Hatalar
- Request Object imzasını doğrulamamak
- JWT içi ve dışı parametre çakışmalarını kabul etmek
- request_uri için keyfi URL fetch etmek
- Scope ve redirect URI yetkisini yalnız imzaya bırakmak
- Uzun ömürlü Request Object kullanmak
- Anahtar rotasyonu ve kid politikasını tanımlamamak
JAR nedir: Sık Sorulan Sorular
JAR nedir?
OAuth authorization request parametrelerini JWT Request Object ile güvenceye alan RFC 9101 standardıdır.
JAR ile PAR aynı mı?
Hayır. JAR request içeriğini korur; PAR requestin backchannel üzerinden taşınmasını sağlar.
Request Object imzalanmak zorunda mı?
Güvenlik profiline göre imza ve/veya şifreleme kuralları uygulanır; bütünlük için imza temel mekanizmadır.
request_uri güvenli mi?
Kontrolsüz fetch edilirse SSRF ve güven sınırı sorunları doğurabilir; sıkı politika gerekir.
JAR FAPI’de kullanılır mı?
Yüksek güvenlikli OAuth profillerinde Request Object ve PAR benzeri mekanizmalar önemli yapı taşlarıdır.
İlgili İçerikler
Resmî ve Güvenilir Kaynaklar
Sonuç: JAR nedir
JAR 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.
JAR, authorization request parametrelerini sıradan query string verisi olmaktan çıkarıp kriptografik olarak doğrulanabilir bir nesneye dönüştürü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.
