Firebase Authentication user nesnesi, projenizdeki bir uygulamaya kaydolan kullanıcı hesabını temsil eder. Uygulamaların genellikle çok sayıda kayıtlı kullanıcısı vardır ve bir projedeki her uygulama, kullanıcı veritabanını paylaşır.
Kullanıcı örnekleri, Firebase Authentication örneklerinden bağımsızdır. Bu nedenle, aynı bağlamda farklı kullanıcılara yönelik çeşitli referanslarınız olabilir ve yine de yöntemlerinden herhangi birini çağırabilirsiniz.
Kullanıcı özellikleri
Authentication kullanıcılarının, proje kullanıcı veritabanında depolanan sabit bir temel özellikler grubu (benzersiz bir kimlik, birincil e-posta adresi, ad ve fotoğraf URL'si) vardır. Bu özellikler kullanıcı tarafından güncellenebilir (iOS, Android, web). Kullanıcı nesnesine doğrudan başka özellikler ekleyemezsiniz. Bunun yerine, ek özellikleri Google Cloud Firestore gibi diğer depolama hizmetlerinde saklayabilirsiniz.
Bir kullanıcı uygulamanıza ilk kez kaydolduğunda, kullanıcının profil verileri aşağıdaki bilgiler kullanılarak doldurulur:
- Kullanıcı e-posta adresi ve şifreyle kaydolduysa yalnızca birincil e-posta adresi özelliği doldurulur.
- Kullanıcı, Google veya Facebook gibi bir federasyon kimlik sağlayıcısıyla kaydolduysa sağlayıcı tarafından sunulan hesap bilgileri, kullanıcının profilini doldurmak için kullanılır.
- Kullanıcı, özel kimlik doğrulama sisteminizle kaydolduysa istediğiniz bilgileri kullanıcının profiline açıkça eklemeniz gerekir.
Kullanıcı hesabı oluşturulduktan sonra, kullanıcının başka bir cihazda yapmış olabileceği değişiklikleri dahil etmek için kullanıcının bilgilerini yeniden yükleyebilirsiniz.
Oturum açma sağlayıcıları
Kullanıcıların uygulamalarınızda oturum açmasını sağlamak için çeşitli yöntemler kullanabilirsiniz: e-posta adresi ve şifre, birleştirilmiş kimlik sağlayıcılar ve özel kimlik doğrulama sisteminiz. Bir kullanıcıyla birden fazla oturum açma yöntemi ilişkilendirebilirsiniz. Örneğin, kullanıcılar aynı hesapta e-posta adresi ve şifre kullanarak veya Google ile oturum açma özelliğini kullanarak oturum açabilir.
Kullanıcı örnekleri, kullanıcıya bağlı her sağlayıcıyı takip eder. Bu sayede, sağlayıcı tarafından verilen bilgileri kullanarak boş profil özelliklerini güncelleyebilirsiniz. Kullanıcıları Yönetme bölümüne bakın (iOS, Android, web).
Geçerli kullanıcı
Bir kullanıcı kaydolduğunda veya oturum açtığında Auth örneğinin geçerli kullanıcısı olur. Örnek, kullanıcının durumunu korur. Böylece, sayfanın yenilenmesi (tarayıcıda) veya uygulamanın yeniden başlatılması kullanıcının bilgilerinin kaybolmasına neden olmaz.
Kullanıcı oturumu kapattığında Auth örneği, kullanıcı nesnesine referans vermeyi bırakır ve durumunu artık kalıcı hale getirmez. Şu anda kullanıcı yoktur. Ancak kullanıcı örneği tamamen işlevsel olmaya devam eder: Referansını saklarsanız kullanıcının verilerine erişmeye ve bunları güncellemeye devam edebilirsiniz.
Kullanıcı yaşam döngüsü
Auth örneğinin mevcut durumunu izlemenin önerilen yolu, dinleyicileri (JavaScript'te "gözlemciler" olarak da adlandırılır) kullanmaktır. Bir Auth dinleyicisi, Auth nesnesiyle ilgili bir şey olduğunda bildirim alır. Kullanıcıları Yönetme (iOS, Android, web) başlıklı makaleye bakın.
Kimlik doğrulama dinleyicisi aşağıdaki durumlarda bilgilendirilir:
- Auth nesnesinin başlatılması tamamlanır ve önceki bir oturumda kullanıcı oturum açmış veya bir kimlik sağlayıcının oturum açma akışından yönlendirilmişse
- Bir kullanıcı oturum açtığında (geçerli kullanıcı ayarlanır)
- Kullanıcı oturumu kapattığında (geçerli kullanıcı null olur)
- Mevcut kullanıcının erişim jetonu yenilenir. Bu durum aşağıdaki koşullarda ortaya çıkabilir:
- Erişim jetonunun süresi dolduğunda (bu yaygın bir durumdur). Yenileme jetonu, geçerli yeni bir jeton grubu almak için kullanılır.
- Kullanıcı şifresini değiştirir: Authentication yeni erişim ve yenileme jetonları oluşturur ve eski jetonların süresinin dolduğunu gösterir. Bu işlem, güvenlik nedeniyle kullanıcının jetonunun süresini otomatik olarak sona erdirir ve/veya kullanıcının oturumunu her cihazda kapatır.
- Kullanıcı yeniden kimlik doğrular: Bazı işlemler için kullanıcının kimlik bilgilerinin yakın zamanda verilmiş olması gerekir. Hesap silme, birincil e-posta adresi ayarlama ve şifre değiştirme gibi işlemler bu kapsamdadır. Kullanıcının oturumunu kapatıp tekrar açmak yerine, kullanıcıdan yeni kimlik bilgileri alın ve bu bilgileri kullanıcı nesnesinin yeniden kimlik doğrulama yöntemine iletin.
Kullanıcı self servisi
Varsayılan olarak Firebase Authentication, kullanıcıların hesaplarını yönetici müdahalesi olmadan kaydetmesine ve silmesine olanak tanır. Bu, birçok durumda son kullanıcıların uygulamanızı veya hizmetinizi keşfetmesini ve minimum zorlukla kullanmaya başlamasını (veya kullanmayı bırakmasını) sağlar.
Ancak, kullanıcıların Yönetici SDK'sını veya Firebase konsolunu kullanarak bir yönetici tarafından manuel olarak ya da programatik olarak oluşturulmasını istediğiniz durumlar olabilir. Bu gibi durumlarda, kullanıcı işlemlerini Firebase Authentication Ayarlar sayfasından devre dışı bırakabilirsiniz. Bu sayede, son kullanıcıların hesap oluşturması ve silmesi engellenir. Çoklu barındırma kullanıyorsanız bu özellikleri kiracı bazında devre dışı bırakmak için bir HTTP isteği göndermeniz gerekir.
Bir son kullanıcı sisteminizde hesap oluşturmaya veya silmeye çalışırsa Firebase Authentication hizmeti bir hata kodu döndürür: Web API çağrıları için auth/admin-restricted-operation, Android ve iOS için ERROR_ADMIN_RESTRICTED_OPERATION. Kullanıcıdan hizmetiniz için uygun işlemleri yapmasını isteyerek hatayı ön uçta düzgün bir şekilde ele almalısınız.
Yetkilendirme jetonları
Authentication ile kimlik doğrulama işlemi yaptığınızda karşılaşabileceğiniz üç tür kimlik doğrulama jetonu vardır:
| Authentication Kimlik jetonları | Kullanıcı bir uygulamada oturum açtığında Authentication tarafından oluşturulur. Bu jetonlar, bir Firebase projesinde kullanıcıyı güvenli bir şekilde tanımlayan imzalı JWT'lerdir. Bu jetonlar, kullanıcının kimlik dizesi de dahil olmak üzere kullanıcının temel profil bilgilerini içerir. Bu kimlik dizesi, Firebase projesine özgüdür. Kimlik jetonlarının bütünlüğü doğrulanabildiğinden, bunları arka uç sunucusuna göndererek şu anda oturum açmış kullanıcıyı tanımlayabilirsiniz. |
| Kimlik sağlayıcı jetonları | Google ve Facebook gibi birleşik kimlik sağlayıcılar tarafından oluşturulur. Bu jetonlar farklı biçimlerde olabilir ancak genellikle OAuth 2.0 erişim jetonlarıdır. Uygulamalar, kullanıcıların kimlik sağlayıcı ile kimlik doğrulama işlemini başarıyla tamamladığını doğrulamak için bu jetonları kullanır ve ardından bunları Authentication hizmetleri tarafından kullanılabilir kimlik bilgilerine dönüştürür. |
| Authentication özel jetonlar | Kullanıcıların kimlik doğrulama sisteminizi kullanarak bir uygulamada oturum açmasına izin vermek için özel kimlik doğrulama sisteminiz tarafından oluşturulur. Özel jetonlar, bir hizmet hesabının özel anahtarı kullanılarak imzalanan JWT'lerdir. Uygulamalar, bu jetonları birleştirilmiş kimlik sağlayıcılardan döndürülen jetonları kullandıkları gibi kullanır. |
Doğrulanmış e-posta adresleri
Authentication, bir e-postanın kimliğinin doğrulanmış olması için iki koşulun karşılanması gerektiğini belirtir:
- Kullanıcı, Authentication doğrulama akışını tamamlar.
- E-posta, güvenilir bir kimlik sağlayıcı (IdP) tarafından doğrulanır.
E-postayı bir kez doğrulayan ancak daha sonra kullanıcıların e-posta adreslerini yeniden doğrulama gerektirmeden değiştirmesine izin veren IdP'ler güvenilir değildir. Alana sahip olan veya her zaman doğrulama gerektiren IdP'ler güvenilir olarak kabul edilir.
Güvenilir sağlayıcılar:
- Google (@gmail.com adresleri için)
- Yahoo (for @yahoo.com addresses)
- Microsoft (@outlook.com ve @hotmail.com adresleri için)
- Apple (hesaplar her zaman doğrulanıp çok öğeli kimlik doğrulamasıyla korunduğundan her zaman doğrulanır)
Güvenilmeyen sağlayıcılar:
- GitHub
- Google, Yahoo ve Microsoft, söz konusu kimlik sağlayıcı tarafından verilmeyen alanlar için
- E-posta doğrulama olmadan e-posta / şifre
Bazı durumlarda, kullanıcı aynı e-posta adresini kullanarak farklı sağlayıcılarla oturum açtığında Authentication hesapları otomatik olarak bağlar. Ancak bu durum yalnızca belirli ölçütler karşılandığında ortaya çıkabilir. Bunun nedenini anlamak için şu durumu göz önünde bulundurun: Bir kullanıcı, Google ile @gmail.com hesabını kullanarak oturum açıyor ve kötü niyetli bir aktör, aynı @gmail.com adresini kullanarak Facebook üzerinden oturum açarak bir hesap oluşturuyor. Bu iki hesap otomatik olarak bağlanırsa kötü niyetli kişi, kullanıcının hesabına erişim kazanır.
Aşağıdaki durumlarda hesapları otomatik olarak bağlarız ve kullanıcı veya geliştirici işlemi gerektiren bir hata gösteririz:
- Kullanıcı, güvenilmeyen bir sağlayıcıyla oturum açtıktan sonra aynı e-postayla başka bir güvenilmeyen sağlayıcıyla oturum açar (örneğin, önce Facebook, ardından GitHub). Bu işlem, hesap bağlama gerektiren bir hataya neden olur.
- Kullanıcı, güvenilir bir sağlayıcıyla oturum açtıktan sonra aynı e-postayla güvenilmeyen bir sağlayıcıyla oturum açar (örneğin, önce Google, ardından Facebook). Bu işlem, hesap bağlama gerektiren bir hataya neden olur.
- Kullanıcı, güvenilmeyen bir sağlayıcıyla oturum açtıktan sonra aynı e-posta adresiyle güvenilen bir sağlayıcıyla oturum açar (örneğin, önce Facebook, ardından Google). Güvenilen sağlayıcı, güvenilmeyen sağlayıcının üzerine yazar. Kullanıcı Facebook ile tekrar oturum açmayı denerse hesap bağlamayı gerektiren bir hata oluşur.
- Kullanıcı, güvenilir bir sağlayıcıyla oturum açtıktan sonra aynı e-posta adresiyle farklı bir güvenilir sağlayıcıyla oturum açar (örneğin, önce Apple, ardından Google). Her iki sağlayıcı da hatasız şekilde bağlanır.
Yönetici SDK'sını kullanarak bir e-postayı manuel olarak doğrulanmış şekilde ayarlayabilirsiniz ancak bunu yalnızca kullanıcının e-postanın sahibi olduğundan emin olduğunuz durumlarda yapmanızı öneririz.