DPoP Nedir? OAuth Token Güvenliği İçin 12 Güçlü Önlem

Klasik Bearer Token modelinde token’ı elinde bulunduran taraf çoğu durumda token’ın sağladığı yetkileri kullanabilir. Bu nedenle access token yanlışlıkla loglara yazılır, zararlı yazılım tarafından ele geçirilir veya başka bir katmandaki açık nedeniyle sızarsa saldırgan token’ın geçerlilik süresi boyunca yetkisiz API çağrıları yapabilir.

DPoP bu problemi sender-constrained token yaklaşımıyla azaltmaya çalışır. İstemci bir public/private key çifti oluşturur ve DPoP Proof adı verilen imzalı JWT üretir. Authorization Server token’ı istemcinin public key’iyle ilişkilendirir. Resource Server ise hem access token’ı hem de ilgili private key’e sahip olunduğunu gösteren DPoP Proof’u doğrular.

IETF tarafından yayımlanan RFC 9449, DPoP mekanizmasının nasıl uygulanacağını ayrıntılı şekilde tanımlar. Bu nedenle DPoP nedir konusu modern OAuth güvenliği açısından yalnızca teorik bir yaklaşım değil, standartlaştırılmış bir token koruma yöntemidir.

DPoP Nedir? Hızlı Bakış

DPoP Nedir ve Neden Kullanılır?

DPoP nedir sorusunun temel cevabı, OAuth tokenını onu kullanan istemcinin kriptografik kimliğiyle bağlayan bir proof-of-possession mekanizmasıdır.

Normal bir Bearer Access Token düşünüldüğünde temel mantık şöyledir:

Token'a sahip olan → API'yi kullanabilir

DPoP kullanıldığında ise denklem değişir:

Token + doğru private key'e sahip olan → API'yi kullanabilir

Böylece saldırgan yalnızca access token değerini ele geçirirse, buna bağlı private key olmadan aynı token’ı başarılı biçimde kullanması önemli ölçüde zorlaşır.

DPoP özellikle browser tabanlı uygulamalar, mobil istemciler ve mTLS tabanlı sender-constrained token kullanımının uygun olmadığı bazı OAuth mimarilerinde değerlendirilebilir.

DPoP Nedir? OAuth Token Güvenliği İçin 12 Güçlü Önlem

1. Her İstemci İçin Güvenli Bir Anahtar Çifti Oluşturun

DPoP güvenliğinin temelinde istemcinin public/private key çifti bulunur. Private key yalnızca istemcide kalmalı, Authorization Server veya Resource Server’a gönderilmemelidir.

Public key ise DPoP Proof içerisinde JWK formatında bulunabilir ve sunucu tarafından token binding işlemlerinde kullanılabilir.

DPoP nedir güvenlik modelinde private key’in korunması kritik önemdedir. Eğer saldırgan hem token’ı hem de private key’i ele geçirirse DPoP’un token hırsızlığına karşı sağladığı koruma önemli ölçüde azalır.

2. DPoP Proof İçin Asimetrik Algoritma Kullanın

DPoP Proof imzasında güvenilir asimetrik dijital imza algoritmaları kullanılmalıdır.

Sunucu, DPoP JWT içerisindeki alg değerini kontrol etmeli ve güvenlik politikasında izin verilen algoritmalar dışında kalan değerleri reddetmelidir.

none gibi imzasız seçenekler kabul edilmemelidir.

DPoP Proof header bölümünde public key bulunabilir ancak private key kesinlikle bulunmamalıdır.

3. Her HTTP İsteği İçin Yeni DPoP Proof Oluşturun

DPoP Proof normal access token gibi uzun süre tekrar tekrar gönderilecek bir token değildir.

Her HTTP isteğinde yeni ve benzersiz bir proof üretmek gerekir.

Bu yaklaşım aynı imzalı proof’un farklı API çağrılarında yeniden kullanılmasını engellemeye yardımcı olur.

İstemci:

1. İsteğin HTTP metodunu belirler.
2. Hedef URI’yi belirler.
3. Yeni benzersiz jti oluşturur.
4. iat zaman bilgisini ekler.
5. Gerekirse access token hash değerini ekler.
6. DPoP Proof’u private key ile imzalar.

4. jti Değerini Benzersiz Oluşturun

jti, DPoP Proof JWT için benzersiz tanımlayıcıdır.

Aynı jti değerinin kısa süre içerisinde tekrar görülmesi replay saldırısının göstergelerinden biri olabilir.

Bu nedenle tahmin edilmesi güç ve yeterince rastgele değerler kullanılmalıdır.

Sunucu yüksek güvenlik gerektiren ortamlarda kısa süreli replay cache tutarak daha önce kabul edilen jti değerlerini yeniden gördüğünde isteği reddedebilir.

DPoP nedir mekanizmasındaki replay korumasının önemli parçalarından biri bu benzersiz proof kimliğidir.

5. htm Claim ile HTTP Metodunu Doğrulayın

DPoP Proof içerisindeki htm claim’i proof’un hangi HTTP metodu için oluşturulduğunu belirtir.

Örneğin:

htm = POST

olarak oluşturulmuş proof farklı bir GET isteğinde geçerli kabul edilmemelidir.

Resource Server, proof içerisindeki htm ile gerçek HTTP request method değerini karşılaştırmalıdır.

Bu kontrol DPoP Proof’un farklı türde HTTP isteğinde yeniden kullanılmasını zorlaştırır.

6. htu Claim ile Hedef URI’yi Doğrulayın

htu yani HTTP URI değeri DPoP Proof’u belirli bir endpoint’e bağlar.

Örneğin proof:

https://api.example.com/payments

için oluşturulduysa:

https://api.example.com/admin

endpoint’inde kabul edilmemelidir.

Sunucu gelen request URI ile proof içerisindeki htu değerini RFC 9449 kurallarına uygun biçimde karşılaştırmalıdır.

Bu sayede saldırganın aynı proof’u başka API endpoint’inde kullanması zorlaşır.

7. iat ile DPoP Proof Yaşam Süresini Kısa Tutun

iat yani Issued At değeri DPoP Proof’un oluşturulduğu zamanı belirtir.

Sunucu proof’un kabul edilebilir bir zaman aralığında üretildiğini doğrulamalıdır.

Çok eski DPoP Proof kabul edilirse saldırgan daha önce yakaladığı proof’u daha sonra yeniden kullanmayı deneyebilir.

Bu nedenle DPoP nedir güvenlik modelinde DPoP Proof oldukça kısa ömürlü olarak değerlendirilmelidir.

Dağıtık sistemlerde küçük saat farklılıkları için sınırlı clock tolerance uygulanabilir ancak gereksiz geniş zaman penceresi replay saldırı yüzeyini büyütebilir.

8. ath Claim ile Access Token’ı Proof’a Bağlayın

Korunan API kaynaklarına erişim sırasında DPoP Proof içinde ath claim’i önemli rol oynar.

ath değeri ilgili Access Token’ın hash bilgisini içerir.

Resource Server gelen Access Token’ın hash değerini hesaplar ve DPoP Proof içerisindeki ath ile karşılaştırır.

Böylece saldırgan geçerli bir DPoP Proof’u alıp başka bir Access Token ile kullanamaz.

Bu kontrol:

• DPoP Proof,
• Access Token,
• Client Private Key

arasında daha güçlü bir ilişki oluşturur.

9. DPoP-Bound Access Token Doğrulamasını Resource Server’da Yapın

Authorization Server’ın DPoP token üretmesi tek başına yeterli değildir.

Resource Server gelen istekte hem Access Token’ı hem DPoP Proof’u doğrulamalıdır.

Sunucu aşağıdaki kontrolleri birlikte gerçekleştirmelidir:

• DPoP Proof signature geçerli mi?
• Public key doğru mu?
• Access Token aynı public key’e bağlı mı?
• htm doğru mu?
• htu doğru mu?
• iat kabul edilebilir mi?
• ath Access Token ile eşleşiyor mu?

Kontrollerden biri başarısız olduğunda korunan kaynağa erişim verilmemelidir.

10. DPoP Nonce ile Replay Korumasını Güçlendirin

Authorization Server veya Resource Server gerektiğinde istemciden nonce içeren yeni DPoP Proof isteyebilir.

Sunucu istemciye DPoP-Nonce header’ı gönderir.

İstemci sonraki proof içerisinde:

nonce

claim’iyle bu değeri taşır.

Sunucu nonce değerinin kendi verdiği güncel değerle eşleştiğini kontrol eder.

Bu yöntem özellikle proof yaşam süresini kontrol etmek ve belirli replay saldırılarına karşı daha sıkı doğrulama uygulamak için kullanılabilir.

Buradaki DPoP nonce ile OpenID Connect ID Token nonce değerinin farklı mekanizmalar olduğu unutulmamalıdır.

11. Access Token ve Refresh Token Binding Politikasını Birlikte Tasarlayın

DPoP yalnızca Access Token kullanımında değerlendirilen bir mekanizma değildir.

RFC 9449, uygun OAuth akışlarında Refresh Token’ın da DPoP anahtarıyla ilişkilendirilmesini tanımlar.

Böylece saldırgan yalnızca Refresh Token değerini ele geçirse bile istemcinin private key’ine sahip olmadan yeni token üretmesi zorlaşır.

DPoP nedir mimarisini tasarlarken:

• Access Token,
• Refresh Token,
• Authorization Code,
• Client Key

arasındaki güven ilişkisi bütün olarak değerlendirilmelidir.

12. DPoP Hatalarını ve Replay Denemelerini Merkezi Olarak İzleyin

DPoP yalnızca kriptografik kontrol değildir; güvenlik operasyonu açısından da güçlü sinyaller üretir.

Örneğin aşağıdaki olaylar izlenebilir:

• geçersiz DPoP signature,
• aynı jti değerinin tekrar kullanılması,
• htm uyuşmazlığı,
• htu uyuşmazlığı,
• yanlış ath değeri,
• key binding hatası,
• eski iat değeri,
• nonce uyuşmazlığı,
• beklenmeyen DPoP token kullanımı.

Bu olayların SIEM veya merkezi log sistemine gönderilmesi token hırsızlığı ve replay girişimlerinin daha hızlı tespit edilmesini sağlayabilir.

Ancak gerçek Access Token, Refresh Token veya private key değerleri loglarda tutulmamalıdır.

DPoP Nedir? Bearer Token ile Arasındaki Fark

DPoP Proof JWT İçinde Hangi Alanlar Bulunur?

DPoP nedir mekanizmasını anlamanın en kolay yollarından biri DPoP Proof yapısına bakmaktır.

Basitleştirilmiş bir DPoP Proof payload şu alanları içerebilir:

{
  "jti": "benzersiz-proof-id",
  "htm": "GET",
  "htu": "https://api.example.com/profile",
  "iat": 1717590000,
  "ath": "access-token-hash"
}

Gerektiğinde sunucu tarafından verilen:

"nonce": "server-generated-value"

claim’i de proof içerisine eklenebilir.

DPoP Nedir? Token İsteği Nasıl Çalışır?

1. Client public/private key çifti oluşturur.
2. Client token endpoint için yeni DPoP Proof oluşturur.
3. Proof private key ile imzalanır.
4. DPoP Proof, token isteğinin HTTP header bölümünde gönderilir.
5. Authorization Server proof signature ve claim değerlerini doğrular.
6. Token istemcinin public key’ine bağlanır.
7. Client API çağrısı için yeni bir DPoP Proof üretir.
8. Resource Server hem Access Token’ı hem DPoP Proof’u doğrular.
9. Private key/token binding eşleşiyorsa API isteği kabul edilir.

DPoP Hangi Saldırılara Karşı Fayda Sağlar?

DPoP nedir güvenlik yaklaşımı özellikle çalınan OAuth tokenlarının başka bir sistem tarafından yeniden kullanılmasını zorlaştırmayı hedefler.

Öne çıkan kullanım alanları şunlardır:

• Access Token replay saldırıları
• Çalınmış Bearer Token kullanımı
• Refresh Token kötüye kullanımı
• Farklı API endpoint’lerinde proof tekrar kullanımı
• Bir DPoP Proof’un farklı Access Token ile eşleştirilmesi

Ancak DPoP tüm OAuth saldırılarını tek başına çözmez. XSS, kötü amaçlı istemci kodu, Authorization Server ele geçirilmesi, zayıf kullanıcı kimlik doğrulaması veya private key hırsızlığı gibi diğer riskler için ek kontroller gerekir.

DPoP Nedir? DPoP ile mTLS Arasındaki Fark

Hangi yöntemin kullanılacağı istemci türüne, OAuth mimarisine, altyapıya ve tehdit modeline göre belirlenmelidir.

DPoP Nedir? 12 Maddelik Güvenlik Kontrol Listesi

1. Güvenli public/private key çifti oluşturun.
2. Private key’i cihaz veya istemci dışında paylaşmayın.
3. Yalnızca izin verilen asimetrik algoritmaları kabul edin.
4. Her HTTP isteği için yeni DPoP Proof üretin.
5. Benzersiz jti kullanın.
6. htm değerini gerçek HTTP metoduyla doğrulayın.
7. htu değerini gerçek request URI ile doğrulayın.
8. iat için kısa kabul penceresi kullanın.
9. API çağrılarında ath kontrolü yapın.
10. Public key ile token binding eşleşmesini doğrulayın.
11. Gerektiğinde DPoP-Nonce kullanın.
12. Replay ve DPoP doğrulama hatalarını merkezi olarak izleyin.

DPoP Nedir? Sık Yapılan 10 Güvenlik Hatası

1. Aynı DPoP Proof’u birden fazla istekte kullanmak
2. jti değerini benzersiz üretmemek
3. htm kontrolünü atlamak
4. htu kontrolünü yapmamak
5. iat için çok geniş zaman penceresi kullanmak
6. ath kontrolünü atlamak
7. Token ile public key binding’i doğrulamamak
8. Private key’i uygulama loglarına veya sunucuya göndermek
9. DPoP Proof’u tek başına erişim yetkisi olarak kabul etmek
10. Nonce ve replay hatalarını izlememek

DPoP Nedir? Sık Sorulan Sorular

DPoP nedir?

DPoP nedir sorusuna; OAuth tokenlarını istemcinin sahip olduğu kriptografik anahtara bağlayarak token hırsızlığı ve replay saldırılarının etkisini azaltmayı amaçlayan Demonstrating Proof of Possession mekanizması şeklinde cevap verilebilir.

DPoP neyin kısaltmasıdır?

Demonstrating Proof of Possession ifadesinin kısaltmasıdır.

DPoP Bearer Token’dan daha güvenli midir?

DPoP, token kullanımını private key possession şartına bağlayarak yalnızca token değerinin çalınmasına karşı ek bir güvenlik katmanı sağlayabilir.

DPoP Proof nedir?

İstemcinin private key’e sahip olduğunu kanıtlamak amacıyla oluşturduğu ve HTTP isteğiyle birlikte gönderdiği imzalı JWT’dir.

DPoP JWT kullanır mı?

Evet. DPoP Proof, belirli header ve claim kurallarına sahip imzalı JWT yapısını kullanır.

ath claim ne işe yarar?

Access Token’ın hash değerini DPoP Proof’a bağlayarak proof’un farklı token ile kullanılmasını önlemeye yardımcı olur.

htm ve htu nedir?

htm HTTP metodunu, htu ise proof’un oluşturulduğu hedef HTTP URI değerini ifade eder.

DPoP nonce ile OIDC nonce aynı mı?

Hayır. DPoP nonce ve OpenID Connect nonce farklı protokol amaçlarına hizmet eden ayrı değerlerdir.

DPoP OAuth 2.0 yerine mi geçer?

Hayır. DPoP, OAuth 2.0 tokenlarının sender-constrained biçimde korunmasına yardımcı olan ek bir güvenlik mekanizmasıdır.

İlgili İçerikler

OAuth 2.0 Güvenliği Nedir? 10 Kritik Önlem

JWT Güvenliği Nedir? 12 Kritik Önlem

OpenID Connect Güvenliği Nedir? 12 Kritik Önlem

Workload Identity Federation Nedir?

Resmî ve Güvenilir Kaynaklar

IETF / RFC Editor — RFC 9449: OAuth 2.0 Demonstrating Proof of Possession

IETF Datatracker — RFC 9449

Sonuç: DPoP Nedir?

DPoP nedir sorusuna basitçe, OAuth Access Token ve Refresh Token kullanımını istemcinin kriptografik anahtar sahipliğine bağlayan proof-of-possession mekanizması şeklinde cevap verilebilir. Ama gerçek güvenlik değeri yalnızca DPoP header kullanmaktan değil, bütün doğrulama adımlarının eksiksiz uygulanmasından gelir.

Her istek için benzersiz DPoP Proof oluşturmak, güçlü private key yönetimi kullanmak, jti, htm, htu, iat ve ath değerlerini doğrulamak, gerektiğinde nonce mekanizmasını etkinleştirmek ve Resource Server tarafında key binding kontrolü yapmak güvenli bir uygulamanın temel parçalarıdır.

Bu kontroller birlikte kullanıldığında DPoP nedir yaklaşımı, klasik Bearer Token modelindeki “token’ı çalan kullanabilir” riskini azaltarak OAuth 2.0 mimarisine güçlü bir token possession katmanı ekler.