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.

2. Token türlerinin görevini belirleyin
VeriNerede tutulur?Nerede tutulmaz?
Erişim tokenıGereken kısa ömürlü istemci bağlamıURL ve analytics
Refresh tokenCihaz güvenli saklama alanıDüz metin genel tercih dosyası
Sunucu anahtarıYalnızca sunucuMobil 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şlemi

6. 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ü:

Bir sonraki okuma

Tüm içeriklere dön