L'oggetto Firebase Authentication user rappresenta un account utente che ha eseguito la registrazione per un'app nel tuo progetto. In genere, le app hanno molti utenti registrati e ogni app in un progetto condivide un database utenti.
Le istanze utente sono indipendenti dalle istanze Firebase Authentication, quindi puoi avere più riferimenti a utenti diversi nello stesso contesto e comunque chiamare uno qualsiasi dei loro metodi.
Proprietà utente
Authentication utenti hanno un insieme fisso di proprietà di base (un ID univoco, un indirizzo email principale, un nome e un URL della foto) archiviate nel database utenti del progetto, che possono essere aggiornate dall'utente (iOS, Android, web). Non puoi aggiungere altre proprietà direttamente 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 suo profilo vengono compilati utilizzando le informazioni disponibili:
- Se l'utente ha eseguito la registrazione con un indirizzo email e una password, viene compilata solo la proprietà dell'indirizzo email principale.
- Se l'utente ha eseguito la registrazione con un provider di identità federato, come Google o Facebook, le informazioni dell'account rese disponibili dal provider vengono utilizzate per compilare il profilo dell'utente.
- Se l'utente ha eseguito la registrazione con il tuo sistema di autenticazione personalizzato, devi aggiungere esplicitamente le informazioni che vuoi al profilo dell'utente.
Una volta creato un account utente, puoi ricaricare le informazioni dell'utente per incorporare eventuali modifiche apportate dall'utente su un altro dispositivo.
Provider di accesso
Puoi consentire agli utenti di accedere alle tue app utilizzando diversi metodi: indirizzo email 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 Accedi con Google.
Le istanze utente tengono traccia di ogni provider collegato all'utente. In questo modo, puoi aggiornare le proprietà del profilo vuoto utilizzando le informazioni fornite da un provider. Consulta Gestire gli utenti (iOS, Android, web).
L'utente corrente
Quando un utente si registra o accede, 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 comporti la perdita delle informazioni dell'utente.
Quando l'utente si disconnette, l'istanza Auth smette di mantenere un riferimento all'oggetto utente e non ne mantiene più lo stato; non esiste un utente corrente. Tuttavia, l'istanza utente continua a essere completamente funzionale: se ne mantieni un riferimento, puoi comunque accedere e aggiornare i dati dell'utente.
Il ciclo di vita dell'utente
Il modo consigliato per monitorare lo stato attuale dell'istanza Auth è utilizzare i listener (chiamati anche "osservatori" in JavaScript). Un listener Auth riceve una notifica ogni volta che si verifica qualcosa di pertinente per l'oggetto Auth. Consulta Gestire gli utenti (iOS, Android, web).
Un listener Auth riceve una notifica nelle seguenti situazioni:
- L'oggetto Auth termina l'inizializzazione e un utente ha già eseguito 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 null).
- Il token di accesso dell'utente corrente viene aggiornato. Questo caso può verificarsi nelle seguenti condizioni:
- Il token di accesso scade: si tratta di una situazione comune. Il token di aggiornamento viene utilizzato per ottenere un nuovo insieme di token validi.
- L'utente cambia la password: Authentication emette nuovi token di accesso e di aggiornamento e rende scaduti i vecchi token. Per motivi di sicurezza, il token dell'utente scade automaticamente e/o l'utente viene disconnesso su ogni dispositivo.
- L'utente esegue di nuovo l'autenticazione: alcune azioni richiedono che le credenziali dell'utente siano state emesse di recente; queste azioni includono l'eliminazione di un account, l'impostazione di un indirizzo email principale e la modifica di una password. Anziché disconnettere l'utente e poi accedere di nuovo, recupera nuove credenziali dall'utente e passale al metodo reauthenticate dell'oggetto utente.
Self-service utente
Per impostazione predefinita, Firebase Authentication consente agli utenti di registrarsi ed eliminare i propri account senza l'intervento amministrativo. In molte circostanze, ciò consente agli utenti finali di scoprire la tua applicazione o il tuo servizio e di eseguire l'onboarding (o l'offboarding) con il minimo attrito.
In alcune situazioni, tuttavia, vuoi che gli utenti vengano creati manualmente o a livello di programmazione da un amministratore, utilizzando l'SDK Admin o Firebase console. In questi casi, puoi disattivare le azioni utente dalla pagina Firebase Authentication Impostazioni, che impedisce la creazione e l'eliminazione di account da parte degli utenti finali. Se utilizzi la multi-tenancy, dovrai effettuare una richiesta HTTP per disattivare queste funzionalità per ogni tenant.
Se un utente finale tenta di creare o eliminare un account all'interno del tuo sistema, il
Firebase Authentication servizio restituirà un codice di errore:
auth/admin-restricted-operation per le chiamate API web o ERROR_ADMIN_RESTRICTED_OPERATION per Android e iOS. Devi gestire l'errore in modo corretto nel frontend chiedendo all'utente di intraprendere le azioni appropriate per il tuo servizio.
Token di autenticazione
Quando esegui l'autenticazione con Authentication, potresti riscontrare tre tipi di token di autenticazione:
| Authentication Token ID | Creati da Authentication quando un utente accede a un'app. Questi token sono JWT firmati che identificano in modo sicuro un utente in un Firebase progetto. Questi token contengono informazioni di base del profilo di un utente, inclusa la stringa ID dell'utente, che è univoca per il Firebase progetto. Poiché l'integrità dei token ID può essere verificata, puoi inviarli a un server di backend per identificare l'utente che ha attualmente eseguito l'accesso. |
| Token del provider di identità | Creati da provider di identità federati, come Google e Facebook. Questi token possono avere formati diversi, ma spesso sono token di accesso OAuth 2.0 token. Le app utilizzano questi token per verificare che gli utenti abbiano eseguito l'autenticazione con il provider di identità e poi li convertono in credenziali utilizzabili dai servizi Authentication. |
| Token personalizzati Authentication | Creati dal tuo sistema di autenticazione personalizzato per consentire agli utenti di accedere a un'app utilizzando il tuo sistema di autenticazione. I token personalizzati sono JWT firmati utilizzando la chiave privata di un service account. Le app utilizzano questi token in modo simile a quelli restituiti dai provider di identità federati. |
Indirizzi email verificati
Authentication considera un'email verificata se soddisfa due condizioni:
- L'utente completa il flusso di verifica Authentication.
- L'email viene verificata da un provider di identità (IdP) attendibile.
I provider di identità che verificano l'email una volta, ma poi consentono agli utenti di modificare gli indirizzi email senza richiedere una nuova verifica, non sono attendibili. I provider di identità che possiedono il dominio o richiedono sempre la verifica sono considerati attendibili.
Provider attendibili:
- Google (per gli 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 con l'autenticazione a più fattori)
Provider non attendibili:
- GitHub
- Google, Yahoo e Microsoft per i domini non emessi dal provider di identità
- Email / password senza verifica dell'email
In alcune situazioni, Authentication collegherà automaticamente gli account quando un utente accede con provider diversi utilizzando lo stesso indirizzo email. Tuttavia, questo può accadere solo quando vengono soddisfatti criteri specifici. Per capire perché, considera la seguente situazione: un utente accede utilizzando Google con un account @gmail.com e un utente malintenzionato crea un account utilizzando lo stesso indirizzo @gmail.com, ma accedendo tramite Facebook. Se questi due account fossero collegati automaticamente, l'utente 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'intervento 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). Viene generato un errore che richiede il collegamento dell'account.
- L'utente accede con un provider attendibile, quindi accede con un provider non attendibile con la stessa email (ad esempio, Google seguito da Facebook). Viene generato 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 altro provider attendibile con la stessa email (ad esempio, Apple seguito da Google). Entrambi i provider verranno collegati senza errori.
Puoi impostare manualmente un'email come verificata utilizzando l'SDK Admin, ma ti consigliamo di farlo solo se sai che l'utente è effettivamente proprietario dell'email.