Utenti nei progetti Firebase

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

Le istanze utente sono indipendenti dalle istanze di autenticazione Firebase, quindi puoi avere più riferimenti a utenti diversi all'interno dello stesso contesto e continuare a chiamare uno qualsiasi dei loro metodi.

Proprietà utente

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

La prima volta che un utente si iscrive 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 compilata 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 messe a disposizione 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 desiderate al profilo dell'utente

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

Provider di accesso

Puoi accedere agli 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 corrente

Quando un utente si registra o effettua l'accesso, 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 perdano le informazioni dell'utente.

Quando l'utente si disconnette, l'istanza Auth smette di mantenere un riferimento all'oggetto utente e non mantiene più il suo stato; non c'è nessun utente corrente. 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 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 Auth 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 accede (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 di token valido.
    • L'utente cambia la propria password: Firebase emette un nuovo accesso e aggiorna i token e rende i vecchi token scaduti. Questo fa scadere automaticamente il token dell'utente e/o disconnette l'utente su ogni dispositivo, per motivi di sicurezza.
    • L'utente effettua nuovamente l'autenticazione: alcune azioni richiedono che le credenziali dell'utente siano state rilasciate di recente; tali azioni includono l'eliminazione di un account, l'impostazione di un indirizzo e-mail principale e la modifica di una password. Invece di disconnettere l'utente e quindi accedere nuovamente all'utente, ottenere nuove credenziali dall'utente e passare le nuove credenziali al metodo di riautenticazione dell'oggetto utente.

Token di autorizzazione

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

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 utente, che è univoca per il progetto Firebase. Poiché è possibile verificare l'integrità dei token ID , è possibile inviarli a un server back-end per identificare l'utente attualmente connesso.
Token del provider di identità Creato da provider di identità federati, come Google e Facebook. Questi token possono avere formati diversi, ma spesso sono 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 usando il tuo sistema di autenticazione. I token personalizzati sono JWT firmati utilizzando la chiave privata di un account di servizio . Le app usano questi token in modo molto simile a come usano i 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à affidabile, 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 attendibili. Gli IdP che possiedono il dominio o richiedono sempre la verifica sono considerati attendibili.

Fornitori fidati:

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

Fornitori non affidabili:

  • 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 e-mail. 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 malintenzionato crea un account utilizzando lo stesso indirizzo @gmail.com, ma accedendo tramite Facebook. Se questi due account fossero collegati automaticamente, l'attore malintenzionato otterrebbe l'accesso all'account dell'utente.

I seguenti casi descrivono quando colleghiamo automaticamente gli account e quando generiamo 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 effettua l'accesso con un provider attendibile, quindi accede con un 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 nuovamente 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 fornitori saranno collegati senza errori.

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