ratebubble/doc/decisions/ADR-003-api-key-strategy.md

ADR-003: Named API Keys Stratejisi

Durum

Kabul edildi

Bağlam

API güvenliği için authentication yöntemi belirlememiz gerekiyor. Birden fazla frontend olacak (Web, Mobile, Admin).

Seçenekler

1. Tek API Key: Tüm frontend'ler aynı key'i kullanır
2. Named API Keys: Her frontend için ayrı key
3. Database API Keys: Key'ler DB'de tutulur, yönetim paneli ile

Karar

Named API Keys (.env'de tanımlı) seçildi.

Yapılandırma

API_KEY_WEB=web-frontend-key-xxx
API_KEY_MOBILE=mobile-app-key-yyy
API_KEY_ADMIN=admin-key-zzz

Gerekçe

Tek Key Eksikleri

• Hangi frontend'in istek attığı belli değil
• Tek bir frontend engellenemez
• Audit trail yok

Database Key Eksikleri

• Ekstra kompleksite
• Yönetim paneli gerektirir
• Başlangıç için overkill

Named Keys Avantajları

1. İzlenebilirlik: Hangi frontend'in istek attığı bilinir
2. Kontrol: Tek bir frontend'in erişimi kapatılabilir
3. Basitlik: .env ile yönetim
4. Güvenlik: Her frontend için ayrı secret

Sonuçlar

Olumlu

• Frontend bazlı rate limiting
• Kolay key rotasyonu
• Basit yapılandırma

Olumsuz

• Yeni frontend için .env güncellemesi gerekir
• Key yönetimi manuel

Gelecek

Gerekirse Database API Keys sistemine geçiş yapılabilir.

Tarih

2025-02-27