Utenti nei progetti Firebase

L'oggetto utente Firebase rappresenta un account utente che ha firmato per un app nel progetto. Le app di solito hanno molti utenti registrati e ogni app in un progetto condivide un database di utenti.

Le istanze utente sono indipendenti dalle istanze di Firebase Authentication, quindi puoi avere più riferimenti a utenti diversi nello stesso contesto e chiamare comunque uno qualsiasi dei loro metodi.

Proprietà utente

Gli utenti Firebase hanno una serie fissa di proprietà, una base di identificazione unico, un indirizzo email principale, un nome e una foto-URL memorizzato nel database utenti del progetto, che possono essere aggiornati dall'utente ( iOS , Android , web ). Non è possibile aggiungere direttamente altre proprietà all'oggetto utente; puoi invece archiviare le proprietà aggiuntive in qualsiasi altro servizio di archiviazione, come Google Cloud Firestore.

La prima volta che un utente si registra alla tua app, i dati del profilo dell'utente vengono compilati utilizzando le informazioni disponibili:

  • Se l'utente si è registrato con un indirizzo e-mail e una password, viene popolata solo la proprietà dell'indirizzo e-mail principale
  • Se l'utente si è registrato con un provider di identità federato, come Google o Facebook, le informazioni sull'account rese disponibili dal provider vengono utilizzate per popolare il profilo dell'utente
  • Se l'utente si è registrato con il tuo sistema di autenticazione personalizzato, devi aggiungere esplicitamente le informazioni che desideri al profilo dell'utente

Una volta creato un account utente, puoi ricaricare le informazioni dell'utente per incorporare eventuali modifiche che l'utente potrebbe aver apportato su un altro dispositivo.

Fornitori di accesso

Puoi accedere gli utenti alle tue app utilizzando diversi metodi: indirizzo e-mail e password, provider di identità federati e il tuo sistema di autenticazione personalizzato. Puoi associare più di un metodo di accesso a un utente: ad esempio, un utente può accedere allo stesso account utilizzando un indirizzo email e una password oppure utilizzando Google Sign-In.

Le istanze utente tengono traccia di ogni provider collegato all'utente. Ciò consente di aggiornare le proprietà del profilo vuoto utilizzando le informazioni fornite da un provider. Vedere Gestione degli utenti ( iOS , Android , web ).

L'utente attuale

Quando un utente si registra o accede, quell'utente diventa l'utente corrente dell'istanza Auth. L'istanza mantiene lo stato dell'utente, in modo che l'aggiornamento della pagina (in un browser) o il riavvio dell'applicazione non perda le informazioni dell'utente.

Quando l'utente si disconnette, l'istanza di Auth smette di mantenere un riferimento all'oggetto utente e non mantiene più il suo stato; non c'è nessun utente attuale. Tuttavia, l'istanza utente continua a essere completamente funzionante: se mantieni un riferimento ad essa, puoi comunque accedere e aggiornare i dati dell'utente.

Il ciclo di vita dell'utente

Il modo consigliato per tenere traccia dello stato corrente dell'istanza Auth consiste nell'usare i listener (chiamati anche "osservatori" in JavaScript). Un ascoltatore Auth riceve una notifica ogni volta che accade qualcosa di rilevante all'oggetto Auth. Vedere Gestione degli utenti ( iOS , Android , web ).

Un listener di autenticazione riceve una notifica nelle seguenti situazioni:

  • L'oggetto Auth termina l'inizializzazione e un utente ha già effettuato l'accesso da una sessione precedente o è stato reindirizzato dal flusso di accesso di un provider di identità
  • Un utente effettua l'accesso (l'utente corrente è impostato)
  • Un utente si disconnette (l'utente corrente diventa nullo)
  • Il token di accesso dell'utente corrente viene aggiornato. Questo caso può verificarsi nelle seguenti condizioni:
    • Il token di accesso scade: questa è una situazione comune. Il token di aggiornamento viene utilizzato per ottenere un nuovo set valido di token.
    • L'utente cambia la password: Firebase emette un nuovo accesso e aggiorna i token e rende scaduti i vecchi token. Questo fa scadere automaticamente il token dell'utente e/o disconnette l'utente su ogni dispositivo, per motivi di sicurezza.
    • L'utente si riautentica: alcune azioni richiedono che le credenziali dell'utente siano rilasciate di recente; tali azioni includono l'eliminazione di un account, l'impostazione di un indirizzo email principale e la modifica di una password. Invece di disconnettere l'utente e quindi eseguire nuovamente l'accesso dell'utente, ottenere nuove credenziali dall'utente e passare le nuove credenziali al metodo di riautenticazione dell'oggetto utente.

Token di autenticazione

Quando esegui l'autenticazione con Firebase, ci sono tre tipi di token di autenticazione che potresti incontrare:

Token ID Firebase Creato da Firebase quando un utente accede a un'app. Questi token sono JWT firmati che identificano in modo sicuro un utente in un progetto Firebase. Questi token contengono informazioni di base sul profilo di un utente, inclusa la stringa ID dell'utente, che è univoca per il progetto Firebase. Perché l'integrità dei token ID può essere verificata , è possibile inviare a un server back-end per identificare il momento firmato-in dell'utente.
Token del provider di identità Creato da provider di identità federati, come Google e Facebook. Questi token possono avere formati diversi, ma sono spesso token di accesso OAuth 2.0. Le app utilizzano questi token per verificare che gli utenti si siano autenticati correttamente con il provider di identità, quindi convertirli in credenziali utilizzabili dai servizi Firebase.
Token personalizzati Firebase Creato dal tuo sistema di autenticazione personalizzato per consentire agli utenti di accedere a un'app utilizzando il tuo sistema di autenticazione. Token personalizzati sono JWTs firmati utilizzando la chiave privata di un account di servizio . Le app usano questi token in modo molto simile ai token restituiti dai provider di identità federati.

Indirizzi email verificati

Firebase considera un'e-mail verificata se soddisfa due condizioni: 1. L'utente completa il flusso di verifica di Firebase 2. L'e-mail viene verificata da un provider di identità attendibile, o IdP in breve.

Gli IdP che verificano l'e-mail una volta, ma poi consentono agli utenti di modificare gli indirizzi e-mail senza richiedere una nuova verifica, non sono affidabili. Gli IdP che possiedono il dominio o che richiedono sempre la verifica sono considerati attendibili.

Fornitori di fiducia:

  • Google (per indirizzi @gmail.com)
  • Yahoo (per gli indirizzi @yahoo.com)
  • Microsoft (per gli indirizzi @outlook.com e @hotmail.com)
  • Apple (sempre verificato, perché gli account sono sempre verificati e autenticati a più fattori)

Fornitori non attendibili:

  • Facebook
  • Twitter
  • GitHub
  • Google, Yahoo e Microsoft per i domini non emessi da quel provider di identità
  • Email/Password senza verifica e-mail

In alcune situazioni, Firebase collegherà automaticamente gli account quando un utente accede con provider diversi utilizzando lo stesso indirizzo email. Tuttavia, ciò può accadere solo quando vengono soddisfatti criteri specifici. Per capire il motivo, considera la seguente situazione: un utente accede utilizzando Google con un account @gmail.com e un attore malintenzionato crea un account utilizzando lo stesso indirizzo @gmail.com, ma accedendo tramite Facebook. Se questi due account fossero collegati automaticamente, il malintenzionato otterrebbe l'accesso all'account dell'utente.

I seguenti casi descrivono quando colleghiamo automaticamente gli account e quando viene generato un errore che richiede l'azione dell'utente o dello sviluppatore:

  • L'utente accede con un provider non attendibile, quindi accede con un altro provider non attendibile con la stessa email (ad esempio, Facebook seguito da GitHub). Questo genera un errore che richiede il collegamento dell'account.
  • L'utente accede con un provider attendibile, quindi accede con provider non attendibile con la stessa email (ad esempio, Google seguito da Facebook). Questo genera un errore che richiede il collegamento dell'account.
  • L'utente accede con un provider non attendibile, quindi accede con un provider attendibile con la stessa email (ad esempio, Facebook seguito da Google). Il provider attendibile sovrascrive il provider non attendibile. Se l'utente tenta di accedere di nuovo con Facebook, si verificherà un errore che richiede il collegamento dell'account.
  • L'utente accede con un provider attendibile, quindi accede con un provider attendibile diverso con la stessa email (ad esempio, Apple seguita da Google). Entrambi i provider verranno collegati senza errori.

Puoi impostare manualmente un'e-mail come verificata utilizzando l'SDK Admin, ma ti consigliamo di farlo solo se sai che l'utente possiede davvero l'e-mail.