Files
ratebubble/doc/decisions/ADR-003-api-key-strategy.md
2026-02-28 02:44:41 +03:00

64 lines
1.3 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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
```env
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