Bu model response bütünlüğü, sender authentication, audience restriction ve mix-up benzeri tehditlere karşı ek doğrulama katmanı sağlar. Bu rehber, JARM 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.
JARM nedir: Hızlı Bakış
| Kontrol Alanı | Temel Amaç |
|---|---|
| Yanıt formatı | JWT içinde authorization response |
| İmza | Sunucu kaynağını ve bütünlüğü doğrulama |
| Audience | Yanıtın doğru client için olduğunu kontrol etme |
| Issuer | Doğru Authorization Server kaynağı |
| FAPI | Yüksek güvenlikli finansal API akışları |
JARM Nedir? OAuth Authorization Response İçin 10 Güçlü Güvenlik Kontrolü
1. JARM Response Mode’u Açıkça Talep Edin
İstemci hangi response mode ile çalışacağını net olarak belirtmelidir.
Beklenmeyen klasik response ile JARM response arasında sessiz fallback güvenlik belirsizliği doğurur.
2. JWT İmzasını Her Yanıtta Doğrulayın
JARM’ın temel değeri imzalı authorization response üretmesidir.
İmza doğrulanmadan code veya error parametresi işlenmemelidir.
3. Issuer Değerini Kontrol Edin
JWT içindeki iss beklenen Authorization Server ile eşleşmelidir.
Aynı istemcinin birden fazla issuer ile çalıştığı yapılarda mix-up riskini azaltmak için kritik kontroldür.
4. Audience Değerini Client ID ile Eşleyin
aud claim yanıtın doğru istemci için üretildiğini kanıtlamaya yardımcı olur.
Başka client için üretilmiş geçerli imzalı JWT kabul edilmemelidir.
5. Zaman Claimlerini Doğrulayın
exp ve ilgili zaman alanları makul toleransla kontrol edilmelidir.
Süresi geçmiş authorization response kabul edilmemelidir.
6. Authorization Code’u JWT Dışında Kabul Etmeyin
JARM kullanırken code parametresinin imzalı yanıt dışında taşınmasına izin vermek bütünlük modelini zayıflatır.
İstemci yalnız doğrulanan JWT içindeki parametreleri işlemelidir.
7. JWKS ve Anahtar Rotasyonunu Yönetin
İmza doğrulaması Authorization Server public keylerine bağlıdır.
kid değişimi ve JWKS cache politikası kesinti yaratmayacak fakat eski anahtarı sonsuza kadar güvenilir tutmayacak şekilde tasarlanmalıdır.
8. Hata Yanıtlarını da Doğrulayın
JARM yalnız başarılı code yanıtını değil error yanıtlarını da koruyabilir.
İstemci hata JWT’sini de aynı issuer, audience ve imza kontrollerinden geçirmelidir.
9. Şifrelemeyi Tehdit Modeline Göre Ekleyin
İmza bütünlük ve kaynak doğrulaması sağlar; gizlilik farklı bir ihtiyaçtır.
Yanıt içeriğinin kullanıcı aracısında görünmesi istenmiyorsa JWE tabanlı şifreleme değerlendirilebilir.
10. Negatif JARM Testleri Yazın
Yanlış issuer, yanlış audience, bozuk imza, süresi dolmuş JWT ve beklenmeyen alg testleri otomatikleştirilmelidir.
İstemci bu durumlarda code’u token endpointine göndermeden akışı sonlandırmalıdır.
JARM nedir: Uygulama Mimarisi
Authorization Server klasik code ve state parametrelerini ayrı query alanları olarak döndürmek yerine bunları JWT içine koyar ve imzalar. İstemci redirect yanıtını aldıktan sonra önce JARM JWT imzasını ve claimlerini doğrular, ancak bundan sonra authorization code’u token endpointinde 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.
JARM nedir: Tehdit Modeli Nasıl Kurulmalı?
JARM 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 JARM nedir mimarisinin tehdit modeli, üretim mimarisi değiştikçe yeniden gözden geçirilmelidir.
JARM 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.
JARM nedir: Operasyon, Loglama ve Olay Müdahalesi
Üretimde iyi tasarlanmış bir JARM 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.
JARM 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. JARM nedir için doğru mimari, tehdidi anlamlı ölçüde azaltırken ekibin yönetebileceği kadar sade kalan mimaridir.
JARM nedir: Sık Yapılan Hatalar
- JARM JWT imzasını doğrulamadan code işlemek
- iss ve aud doğrulamasını atlamak
- Beklenmeyen response mode için sessiz fallback yapmak
- JWKS rotasyonunu yönetmemek
- Error response JWT doğrulamasını atlamak
- alg seçimini açık allowlist olmadan kabul etmek
JARM nedir: Sık Sorulan Sorular
JARM nedir?
OAuth authorization response parametrelerini imzalı JWT içinde taşıyan response mode standardıdır.
JARM hangi kuruluş tarafından standartlaştırıldı?
OpenID Foundation FAPI çalışma grubu tarafından Final Specification olarak yayımlanmıştır.
JARM neyi korur?
Authorization response bütünlüğü, kaynak doğrulaması ve audience bağını güçlendirir.
JARM ile JAR farkı nedir?
JAR authorization requesti, JARM authorization response’u korur.
JARM şifreleme yapar mı?
İmza temel özelliktir; spesifikasyonda isteğe bağlı şifreleme de desteklenebilir.
İlgili İçerikler
Resmî ve Güvenilir Kaynaklar
OpenID Foundation — JARM Specification
OpenID Foundation — JARM Final Specification
Sonuç: JARM nedir
JARM 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.
JARM özellikle birden fazla issuer, yüksek değerli yetkilendirme ve FAPI sınıfı tehdit modellerinde authorization response güvenini belirgin biçimde artı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.
