- Kimler için?
- Mobil uygulamasına kullanıcı hesabı ekleyen backend ve istemci geliştiricileri.
- Başlamadan önce
- HTTPS, sunucuda kimlik doğrulama ve cihazın güvenli anahtar saklama alanı.
1. Ürün hesabı ile platform hesabını ayırın
Uygulama Cloud paneline giriş, sizin mobil kullanıcılarınız için Auth servisi anlamına gelmez. Bu rehber kendi uygulamanızın kimlik sistemini tasarlamak içindir. E-posta doğrulama, parola sıfırlama, oturum ve kaynak yetkisi ayrı akışlardır. Bir hesabın giriş yapabilmesi tüm proje verisine erişebilmesi anlamına gelmemelidir.
2. Token türlerinin görevini belirleyin
Erişim tokenı API isteğinde kullanılır; yenileme tokenı yeni erişim almak için daha dar bir endpoint’e gider. Yenileme tokenını mobil güvenli saklama alanında tutun. Tokenları URL query, analytics olayı veya hata loguna koymayın. JWT kullanılması otomatik iptal yeteneği sağlamaz; oturum kaydı, sürüm veya iptal mekanizması tasarlayın.
| Veri | Nerede tutulur? | Nerede tutulmaz? |
|---|---|---|
| Erişim tokenı | Gereken kısa ömürlü istemci bağlamı | URL ve analytics |
| Refresh token | Cihaz güvenli saklama alanı | Düz metin genel tercih dosyası |
| Sunucu anahtarı | Yalnızca sunucu | Mobil paket |
3. Yenilemeyi eşzamanlı isteklerle test edin
Bir ekranda beş istek aynı anda 401 alırsa beş ayrı refresh çağrısı token rotasyonunu bozabilir. İstemcide tek bir yenileme işi paylaşın; başarıdan sonra bekleyen istekleri kontrollü yeniden deneyin. Sunucuda refresh kullanımının tekrarını ve oturum ailesini izleyin. Rotasyon başarısız olduğunda sonsuz giriş-yenileme döngüsü yerine kullanıcıdan yeniden giriş isteyin.
4. Çıkış ve hesap kurtarmayı tamamlayın
Çıkış yalnızca ekrandaki tokenı silmek değildir. Sunucu oturumunun veya yenileme yetkisinin iptalini de planlayın. Parola değişiminde diğer cihazların oturum politikası belirli olmalıdır. Reset tokenları tek kullanımlı ve süreli olmalı; hesap varlığını gereksiz yere ifşa etmeyen cevaplar verin. OTP denemeleri ve e-posta gönderimi için ayrı limit uygulayın.
5. Her veri erişiminde yetki kontrolü yapın
İstek body’sindeki user_id ya da project_id doğru kabul edilmemelidir. SQL sorgusu ve servis işlemi doğrulanmış kullanıcının tenant sınırında çalışsın. RLS kullanıyorsanız API’nin bağlandığı rolün bu politikaları atlayıp atlamadığını test edin. İstemcide gizlenen bir buton güvenlik kontrolü değildir.
İstek → Kimlik doğrulama → Oturum geçerliliği
→ Tenant / kaynak yetkisi → İş kuralı → Veri işlemi6. Negatif senaryoları yayın kriteri yapın
Başka kullanıcının kayıt kimliği, iptal edilmiş token, çalınmış refresh denemesi, eşzamanlı yenileme, offline çıkış ve hesap silme akışlarını test edin. Oturum listesindeki cihaz açıklamasını doğrulanmış kimlik gibi kullanmayın. Bildirim tokenları ve offline kuyruklar çıkış yapan hesapla ilişkili kalmamalıdır.
- Oturum ve yenileme sırlarını loglamayın.
- Parolayı uygun parola hash algoritmasıyla sunucuda saklayın.
- Kullanıcılar arası erişim testini her veri türünde uygulayın.
- Giriş ve kurtarma endpoint’lerinde kötüye kullanım sınırı koyun.
Uygulama özeti
- Kimlik ve kaynak yetkisini ayırın.
- Yenileme ve iptali birlikte tasarlayın.
- Çıkış, kuyruk ve bildirim bağlantılarını temizleyin.
Sık sorulan sorular
JWT kullanmak yeterli güvenlik sağlar mı?
Hayır. Süre, saklama, iptal, yenileme ve kaynak yetkisi ayrıca uygulanmalıdır.
Mobil uygulamada service-role anahtarı kullanılabilir mi?
Hayır. Yetkili sunucu sırları istemci paketi içinde gizli tutulamaz.
Kaynaklar ve kapsam
Teknik kaynaklar aşağıda. Örnekler açıklama ve kendi ortamınızda uygulama içindir; gerçek müşteri ölçümü veya çalışan Uygulama Cloud servisi iddiası içermez. Sağlayıcı ayarlarını uygulamadan önce ilgili belgenin güncel sürümünü kontrol edin.
Kaynak kontrolü: