FAPI 2.0 Nedir? Yüksek Güvenlikli API’ler İçin 12 Kritik Kontrol

FAPI açılımı geçmişten gelen adıyla Financial-grade API olsa da FAPI 2.0 yalnızca bankacılık sistemleri için tasarlanmış bir standart değildir. OpenID Foundation, profilin yüksek değerli ve hassas veri sunan API’lerde genel amaçlı kullanılabileceğini; sağlık ve e-devlet sistemleri gibi alanlara da uygulanabileceğini belirtmektedir.

FAPI 2.0 Security Profile, klasik OAuth yapılandırmalarında geliştiriciye bırakılabilen birçok seçimi sınırlandırır. Confidential client kullanımı, güçlü client authentication, sender-constrained access token, PKCE, Pushed Authorization Requests yani PAR ve güvenli TLS kullanımı gibi kontrolleri zorunlu veya temel davranış hâline getirir.

Bu nedenle FAPI 2.0 nedir sorusuna yalnızca “finansal API standardıdır” şeklinde cevap vermek eksik kalır. Daha doğru tanım; yüksek riskli API’lerde OAuth 2.0 akışını daha dar, doğrulanabilir ve saldırıya dayanıklı bir güvenlik profiline dönüştüren OpenID Foundation standardıdır.

FAPI 2.0 Nedir? Hızlı Bakış

FAPI 2.0 Nedir ve Neden Geliştirildi?

FAPI 2.0 nedir sorusunun temelinde OAuth 2.0’ın esnekliği bulunur. OAuth çok farklı uygulama ve istemci türlerini destekleyebilmek için geliştiricilere çeşitli seçenekler sunar. Ancak yüksek değerli finansal veya hassas veri içeren sistemlerde fazla seçenek güvenlik yapılandırma hatalarına yol açabilir.

FAPI 2.0 bu nedenle OAuth 2.0’ın güvenli bir alt profilini oluşturur. Hangi grant türlerinin, client authentication mekanizmalarının, token modellerinin ve authorization akışlarının kabul edileceğini daha sıkı biçimde belirler.

OpenID Foundation tarafından yayımlanan FAPI 2.0 Security Profile, OAuth Security Best Current Practice önerilerini de temel alır ve saldırı modeline karşı formel güvenlik analizinden geçirilmiş yüksek güvenlikli bir profil sunmayı amaçlar.

Özellikle aşağıdaki sistemlerde değerlendirilebilir:

• açık bankacılık API’leri,
• ödeme sistemleri,
• finansal veri paylaşımı,
• sağlık API’leri,
• e-devlet servisleri,
• yüksek değerli kurumsal API’ler,
• hassas kişisel veri sağlayan platformlar.

FAPI 2.0 Nedir? Yüksek Güvenlikli API’ler İçin 12 Kritik Kontrol

1. Yalnızca Confidential Client Kullanın

FAPI 2.0 Security Profile’ın önemli farklarından biri istemci güvenliği konusunda daha katı olmasıdır. Profil yalnızca confidential client kullanımını kapsar.

Confidential client, Authorization Server karşısında güvenilir biçimde kimlik doğrulayabilen istemcidir.

Bu yaklaşım özellikle yüksek değerli API’lerde istemcinin kim olduğuna ilişkin güveni artırır. Authorization Server, yalnızca client_id değerine bakarak erişim sağlamaz; istemcinin kriptografik kimlik doğrulamasından geçmesini bekler.

FAPI 2.0 nedir yaklaşımında client identity, sistem güvenliğinin temel katmanlarından biridir.

2. Client Authentication İçin private_key_jwt veya mTLS Kullanın

FAPI 2.0, client authentication için güçlü kriptografik yöntemleri kullanır.

Authorization Server aşağıdaki yöntemlerden birini desteklemelidir:

• private_key_jwt
• Mutual TLS yani mTLS

private_key_jwt yaklaşımında istemci private key kullanarak imzalanmış bir client assertion üretir. Authorization Server ilişkili public key üzerinden bu assertion’ı doğrular.

mTLS kullanıldığında ise istemci TLS seviyesinde certificate ile kimlik doğrular.

Bu yöntemler basit ve uzun ömürlü client secret kullanımına göre daha güçlü bir kriptografik güven modeli oluşturabilir.

3. Authorization Code Flow Kullanın

Authorization endpoint kullanılan FAPI 2.0 akışlarında response_type değeri code olmalıdır.

Bu yaklaşım Authorization Code Flow kullanılmasını sağlar.

Access Token’ın doğrudan browser üzerinden dönmesi yerine istemci kısa ömürlü Authorization Code alır ve bunu güvenli token endpoint üzerinden token ile değiştirir.

FAPI 2.0, daha eski ve daha riskli OAuth akışlarını yüksek güvenlikli kullanım alanından çıkararak daha kontrollü authorization modeline yönelir.

4. PKCE İçin Yalnızca S256 Kullanın

PKCE yani Proof Key for Code Exchange, Authorization Code’un ele geçirilmesine karşı önemli OAuth güvenlik mekanizmalarından biridir.

FAPI 2.0 authorization code flow içerisinde PKCE kullanımını ve S256 code challenge metodunu zorunlu kılar.

İstemci her authorization isteği için benzersiz bir code_verifier üretir.

Bundan:

code_challenge = BASE64URL(SHA256(code_verifier))

değeri hesaplanır.

Authorization Code token endpoint’e gönderildiğinde istemci gerçek code_verifier değerini de sunar.

Bu nedenle FAPI 2.0 nedir güvenlik modelinde yalnızca Authorization Code’u ele geçirmek token almak için yeterli olmayabilir.

5. Pushed Authorization Requests Kullanımını Zorunlu Tutun

FAPI 2.0’ın en dikkat çekici kontrollerinden biri PAR yani Pushed Authorization Requests kullanımını zorunlu kılmasıdır.

Normal OAuth akışında:

client → browser → authorization endpoint

üzerinden çok sayıda authorization parametresi gönderilebilir.

PAR modelinde istemci authorization parametrelerini önce doğrudan Authorization Server’ın PAR endpoint’ine gönderir.

Authorization Server başarılı doğrulama sonrasında kısa ömürlü bir:

request_uri

oluşturur.

Browser daha sonra uzun authorization parametreleri yerine bu request URI ile authorization endpoint’e gider.

Bu model authorization request’in manipüle edilme ve bazı parametrelerin istemci ile Authorization Server arasındaki güvenli kanaldan çıkma riskini azaltmaya yardımcı olur.

6. PAR İsteklerinde Client Authentication Yapın

Yalnızca PAR endpoint kullanmak yeterli değildir.

FAPI 2.0, Pushed Authorization Request işleminin client authentication ile yapılmasını gerektirir.

Böylece Authorization Server:

• authorization isteğini hangi client’ın oluşturduğunu,
• client’ın gerçekten kayıtlı olup olmadığını,
• redirect URI ve istek parametrelerinin hangi istemciye ait olduğunu

daha authorization işlemi başlamadan doğrulayabilir.

FAPI 2.0 nedir yaklaşımının önemli özelliklerinden biri kritik kontrolleri browser yönlendirmesinden önce server-to-server aşamasına taşımaktır.

7. Sender-Constrained Access Token Kullanın

Klasik Bearer Token modelinde token’ı ele geçiren saldırgan token geçerli olduğu sürece API çağrısı yapabilir.

FAPI 2.0 bu riski azaltmak için yalnızca sender-constrained Access Token kullanımını gerektirir.

Authorization Server token’ı belirli istemcinin kriptografik kimliğine bağlar.

Profil iki temel yöntemi destekler:

• DPoP
• mTLS Certificate-Bound Access Token

Böylece saldırgan yalnızca token değerini ele geçirdiğinde, ilişkili private key veya certificate olmadan token’ı başka istemciden kullanamaz.

8. DPoP veya mTLS ile Token Binding Uygulayın

Sender-constrained token politikasının gerçek güvenlik değeri doğru token binding kontrolünden gelir.

DPoP kullanıldığında istemci her API isteği için private key ile imzalanmış DPoP Proof JWT oluşturur.

Resource Server:

• DPoP Proof imzasını,
• Access Token binding bilgisini,
• HTTP metodunu,
• hedef URI’yi,
• proof zamanını

doğrulayabilir.

mTLS modelinde Access Token istemcinin TLS certificate bilgisine bağlanabilir.

Bu nedenle FAPI 2.0 nedir tasarımı OAuth tokenını basit bearer secret olmaktan çıkararak belirli gönderenle ilişkilendirmeye çalışır.

9. Authorization Code Yaşam Süresini Çok Kısa Tutun

FAPI 2.0 Security Profile, Authorization Server tarafından verilen authorization code için maksimum 60 saniyelik yaşam süresi tanımlar.

Authorization Code tek kullanımlık olmalıdır.

Daha önce kullanılmış code yeniden token endpoint’e gönderildiğinde Authorization Server isteği reddetmelidir.

Bu kontrol ele geçirilmiş authorization code’un saldırgan tarafından daha sonra kullanılabileceği zaman penceresini önemli ölçüde azaltır.

Authorization Code zaten PKCE ile korunduğu için kısa yaşam süresi ek savunma katmanı oluşturur.

10. Issuer Doğrulaması ile Mix-Up Saldırılarını Engelleyin

Bir OAuth istemcisi birden fazla Authorization Server ile çalışıyorsa saldırgan istemciyi yanlış Authorization Server cevabına yönlendirmeyi deneyebilir.

Bu saldırı sınıfı OAuth mix-up saldırılarıyla ilişkilidir.

FAPI 2.0 authorization response içerisinde RFC 9207’ye göre iss parametresinin dönmesini ister.

Client gelen issuer değerini beklediği Authorization Server ile karşılaştırmalıdır.

Ayrıca Authorization Server metadata’sının güvenilir issuer URL üzerinden alınması ve metadata içerisindeki issuer ile başlangıç issuer değerinin eşleşmesi gerekir.

Bu kontrol FAPI 2.0 nedir güven zincirinde “token geçerli mi?” sorusunun yanında “doğru Authorization Server mı üretti?” sorusunun da cevaplanmasını sağlar.

11. TLS 1.2 veya Daha Yeni Sürüm Kullanın

FAPI 2.0 yalnızca uygulama katmanındaki OAuth kontrollerine dayanmaz.

Client, Authorization Server ve Resource Server arasındaki endpoint’lerin TLS ile korunması gerekir.

Profil TLS 1.2 veya daha yeni sürüm kullanımını şart koşar ve güncel güvenli TLS kullanım tavsiyelerinin takip edilmesini ister.

TLS server certificate doğrulaması yapılmalıdır.

Browser tarafından kullanılan endpoint’lerde TLS stripping riskine karşı HSTS gibi mekanizmalar uygulanabilir.

Çünkü kriptografik olarak güçlü OAuth mesajları, ağ bağlantısı yanlış yapılandırılmışsa hâlâ saldırı altında kalabilir.

12. En Az Ayrıcalık ve Sürekli Doğrulama Uygulayın

Güvenli bir API yalnızca güçlü authentication’dan oluşmaz.

FAPI 2.0 Security Profile, Access Token’a verilen ayrıcalıkların uygulamanın gerçek ihtiyacıyla sınırlandırılmasını önerir.

Örneğin yalnızca hesap bakiyesi okuyan bir uygulamaya:

• para transferi,
• hesap silme,
• profil değiştirme,
• yönetici işlemleri

gibi gereksiz yetkiler verilmemelidir.

Resource Server her istekte:

• token geçerliliğini,
• expiration durumunu,
• scope veya authorization detayını,
• sender constraint bilgisini,
• gerekli yetkiyi

kontrol etmelidir.

Böylece FAPI 2.0 nedir yaklaşımı yalnızca güvenli login değil, API çağrısına kadar devam eden sürekli yetkilendirme doğrulaması oluşturur.

FAPI 2.0 Nedir? Normal OAuth 2.0 ile Arasındaki Farklar

FAPI 2.0 Nedir? Örnek Güvenli Akış

1. Client güvenilir Authorization Server metadata’sını alır.
2. Client PKCE için benzersiz code_verifier oluşturur.
3. S256 ile code_challenge hesaplanır.
4. Client authorization parametrelerini PAR endpoint’ine gönderir.
5. Client private_key_jwt veya mTLS ile kimlik doğrular.
6. Authorization Server bir request_uri üretir.
7. Browser authorization endpoint’e request URI ile yönlendirilir.
8. Kullanıcı doğrulanır ve gerekli izni verir.
9. Authorization Server kısa ömürlü Authorization Code döndürür.
10. Client response içerisindeki issuer bilgisini doğrular.
11. Authorization Code ve code_verifier token endpoint’e gönderilir.
12. Authorization Server DPoP veya mTLS ile sender-constrained Access Token üretir.
13. Client Access Token’ı Resource Server’a gönderir.
14. Resource Server token ile sender binding bilgisini doğrular.
15. Tüm kontroller başarılıysa korunan API kaynağına erişim sağlanır.

FAPI 2.0 Nedir? PAR Neden Bu Kadar Önemlidir?

PAR yani Pushed Authorization Requests, FAPI 2.0 nedir mimarisinin en belirgin güvenlik parçalarından biridir.

Klasik authorization isteğinde:

https://authorization.example.com/authorize?
client_id=123
&redirect_uri=https://client.example.com/callback
&scope=payments
&state=...

gibi parametreler browser üzerinden taşınabilir.

PAR yaklaşımında ise client önce authorization server’a güvenli server-to-server bağlantısı kurar ve authorization parametrelerini doğrudan PAR endpoint’ine gönderir.

Sunucu daha sonra:

{
  "request_uri": "urn:ietf:params:oauth:request_uri:xyz123",
  "expires_in": 90
}

benzeri kısa ömürlü bir referans döndürebilir.

Browser yalnızca bu request URI üzerinden authorization işlemini sürdürür.

Bu yaklaşım:

• authorization request manipülasyonunu azaltır,
• client authentication’ı flow başlamadan uygular,
• kritik parametrelerin browser üzerinden taşınmasını azaltır,
• Authorization Server’ın isteği önceden doğrulamasını sağlar.

FAPI 2.0 Nedir? DPoP ve mTLS Arasındaki Fark

FAPI 2.0 her iki yöntemi de sender-constrained token için destekler. Seçim kullanılan client teknolojisine, sertifika altyapısına ve güvenlik mimarisine göre yapılmalıdır.

FAPI 2.0 Hangi Alanlarda Kullanılabilir?

FAPI 2.0 nedir denildiğinde “financial-grade” ifadesi nedeniyle yalnızca bankalar düşünülmemelidir.

Profil aşağıdaki gibi yüksek değerli veri sağlayan sistemler için de değerlendirilebilir:

• açık bankacılık,
• fintech platformları,
• ödeme API’leri,
• dijital cüzdan sistemleri,
• sağlık kayıt API’leri,
• sigorta sistemleri,
• e-devlet API’leri,
• kurumsal finans uygulamaları,
• yüksek hassasiyetli kişisel veri API’leri.

FAPI 2.0 Nedir? 12 Maddelik Güvenlik Kontrol Listesi

1. Yalnızca güvenilir confidential client kullanın.
2. Client authentication için private_key_jwt veya mTLS uygulayın.
3. Authorization Code Flow kullanın.
4. PKCE S256 zorunlu tutun.
5. Pushed Authorization Requests yani PAR kullanın.
6. PAR endpoint’inde client authentication yapın.
7. Yalnızca sender-constrained Access Token üretin.
8. Token binding için DPoP veya mTLS kullanın.
9. Authorization Code süresini maksimum 60 saniye tutun ve yeniden kullanımı reddedin.
10. Authorization response issuer değerini doğrulayın.
11. Tüm endpoint’lerde TLS 1.2 veya daha yeni güvenli yapılandırma kullanın.
12. Access Token scope ve yetkilerini en az ayrıcalık ilkesine göre sınırlandırın.

FAPI 2.0 Nedir? En Sık Yapılan 12 Hata

1. Normal Bearer Token kullanmak
2. PKCE kullanmamak
3. PKCE için S256 yerine zayıf veya yanlış yöntem kullanmak
4. PAR kullanmadan authorization request göndermek
5. PAR endpoint’inde client authentication yapmamak
6. Client secret tabanlı zayıf authentication modeline güvenmek
7. DPoP veya mTLS binding kontrolünü Resource Server’da yapmamak
8. Issuer doğrulamasını atlamak
9. Authorization Code’u uzun süre geçerli bırakmak
10. Daha önce kullanılan Authorization Code’u yeniden kabul etmek
11. Geniş scope ve gereksiz yetkiler vermek
12. OAuth akışını sıfırdan geliştirip güvenilir kütüphanelerden yararlanmamak

FAPI 2.0 Nedir? Sık Sorulan Sorular

FAPI 2.0 nedir?

FAPI 2.0 nedir sorusuna; yüksek değerli API’leri korumak amacıyla OAuth 2.0 üzerine daha sıkı client authentication, sender-constrained token, PAR, PKCE ve TLS gereksinimleri ekleyen OpenID Foundation güvenlik profili şeklinde cevap verilebilir.

FAPI neyin kısaltmasıdır?

FAPI adı Financial-grade API ifadesinden gelir. Ancak FAPI 2.0 Security Profile yalnızca finans sistemleriyle sınırlı değildir.

FAPI 2.0 sadece bankalar için mi?

Hayır. Finans alanında geliştirilmiş olsa da sağlık, kamu ve diğer yüksek değerli veya hassas veri API’leri için de kullanılabilir.

FAPI 2.0 OAuth 2.0’ın yerine mi geçer?

Hayır. FAPI 2.0, OAuth 2.0 ve ilişkili standartları daha yüksek güvenlik gereksinimleriyle profilleyen bir güvenlik standardıdır.

FAPI 2.0’da PKCE gerekli mi?

Evet. Authorization Code Flow kullanıldığında PKCE ve S256 code challenge yöntemi zorunlu güvenlik kontrollerindendir.

FAPI 2.0’da PAR gerekli mi?

Evet. Authorization endpoint kullanan FAPI 2.0 Authorization Code akışında Pushed Authorization Requests kullanılır.

FAPI 2.0 DPoP kullanıyor mu?

FAPI 2.0 sender-constrained Access Token için DPoP veya mTLS yöntemlerinden birini kullanabilir.

Sender-constrained token nedir?

Access Token’ın yalnızca token değerine değil, onu kullanmaya yetkili istemcinin belirli kriptografik anahtar veya sertifikasına da bağlandığı token modelidir.

FAPI 2.0’da private_key_jwt nedir?

İstemcinin private key ile imzaladığı JWT assertion üzerinden Authorization Server karşısında kimlik doğrulaması yapmasını sağlayan yöntemdir.

FAPI 2.0 ne zaman final oldu?

OpenID Foundation FAPI 2.0 Security Profile, Şubat 2025’te Final Specification statüsüne ulaştı.

İlgili İçerikler

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

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

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

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

SAML 2.0 Güvenliği Nedir? 12 Kritik Önlem

Resmî ve Güvenilir Kaynaklar

OpenID Foundation — FAPI 2.0 Security Profile Final Specification

OpenID Foundation — FAPI 2.0 Final Specifications Approval

IETF — OAuth 2.0 Security Best Current Practice RFC 9700

Sonuç: FAPI 2.0 Nedir?

FAPI 2.0 nedir sorusuna; OAuth 2.0’ın yüksek değerli ve hassas API sistemlerinde daha güvenli uygulanmasını sağlayan, seçenekleri sınırlandırılmış ve saldırı modeline göre güçlendirilmiş bir API güvenlik profili şeklinde cevap verilebilir.

FAPI 2.0; confidential client kullanımı, private_key_jwt veya mTLS ile güçlü istemci doğrulaması, PKCE S256, Pushed Authorization Requests, kısa ömürlü ve tek kullanımlık Authorization Code, issuer doğrulaması ve sender-constrained Access Token gibi kontrolleri aynı mimaride birleştirir.

Özellikle DPoP veya mTLS sayesinde Access Token’ın yalnızca değerine sahip olmak yeterli değildir; token ilgili istemcinin kriptografik kimliğiyle bağlanabilir. Böylece klasik Bearer Token modelindeki token hırsızlığı ve replay riski önemli ölçüde azaltılabilir.

Tüm bu katmanlar birlikte uygulandığında FAPI 2.0 nedir yaklaşımı, standart OAuth entegrasyonunu bankacılık, ödeme, sağlık, kamu ve diğer yüksek hassasiyetli API sistemleri için çok daha kontrollü ve güçlü bir güvenlik mimarisine dönüştürür.