Utenti di Identity Platform nei progetti

L'oggetto user di Identity Platform rappresenta un account utente registrato a un'app nel tuo progetto Google Cloud. In genere le app hanno molti utenti registrati e ogni app in un progetto Google Cloud condivide un database di utenti.

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

Proprietà utente

Gli utenti di Identity Platform dispongono di un insieme fisso di proprietà di base (un ID univoco, un indirizzo email principale, un nome e un URL della foto) memorizzato nel database degli utenti del progetto che può essere aggiornato dall'utente (iOS, Android, web). Non puoi aggiungere altre proprietà direttamente all'oggetto utente; puoi invece archiviarle 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 email e una password, viene compilata solo la proprietà dell'indirizzo email 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 compilare 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 quest'ultimo potrebbe aver apportato su un altro dispositivo.

Provider di accesso

Puoi far accedere gli utenti alle tue app utilizzando diversi metodi: indirizzo email e password, provider di identità federati e il tuo sistema di autenticazione personalizzato. Puoi associare più metodi 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. Ciò consente di aggiornare le proprietà di un profilo vuoto utilizzando le informazioni fornite da un provider. Vedi Gestione degli utenti (iOS, Android, web).

L'utente corrente

Quando un utente si registra o accede, diventa l'utente corrente dell'istanza di autenticazione. L'istanza conserva lo stato dell'utente, pertanto l'aggiornamento della pagina (in un browser) o il riavvio dell'applicazione non comporta la perdita delle informazioni dell'utente.

Quando l'utente si disconnette, l'istanza di autenticazione smette di mantenere un riferimento all'oggetto utente e non ne conserva più lo stato; non esiste un utente corrente. Tuttavia, l'istanza utente continua a essere completamente funzionale: se conservi un riferimento all'istanza, puoi comunque accedere ai dati dell'utente e aggiornarli.

Il ciclo di vita dell'utente

Il metodo consigliato per monitorare lo stato attuale dell'istanza di autenticazione consiste nell'utilizzare gli ascoltatori (chiamati anche "osservatori" in JavaScript). Un listener Auth riceve una notifica ogni volta che succede qualcosa di rilevante all'oggetto Auth. Vedi 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à eseguito l'accesso da una sessione precedente o è stato reindirizzato dal flusso di accesso di un provider di identità
Un utente esegue l'accesso (l'utente corrente è impostato)
Un utente si disconnette (l'utente corrente diventa null)
Il token di accesso dell'utente corrente è stato aggiornato. Questo caso può verificarsi nelle seguenti condizioni:
- Il token di accesso scade: si tratta di una situazione comune. Il token di aggiornamento viene usato per ottenere un nuovo set di token valido.
- L'utente cambia la password: Identity Platform rilascia nuovi token di accesso e di aggiornamento, quindi fa scadere i vecchi token. In questo modo, il token dell'utente scade automaticamente e/o l'utente viene disconnesso su tutti i dispositivi, per motivi di sicurezza.
- L'utente esegue nuovamente l'autenticazione: alcune azioni richiedono l'emissione di recente delle credenziali dell'utente. Queste 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 di farlo accedere di nuovo, ottieni nuove credenziali dall'utente e passa le nuove credenziali al metodo di riautenticazione dell'oggetto utente.

Per impostazione predefinita, Identity Platform consente agli utenti di registrarsi ed eliminare i propri account senza intervento amministrativo. In molti casi, ciò consente agli utenti finali di scoprire l'applicazione o il servizio e di eseguire l'onboarding (o l'offboarding) con il minimo attrito.

Tuttavia, in alcune situazioni gli utenti devono essere creati manualmente o in modo programmatico da un amministratore, utilizzando SDK Admin o la console Google Cloud. In questi casi, puoi disabilitare le azioni degli utenti dalla pagina delle impostazioni di Identity Platform, impedendo così la creazione e l'eliminazione degli account da parte dell'utente finale. Se utilizzi l'architettura multi-tenancy, devi effettuare una richiesta HTTP per disabilitare queste funzionalità in base al tenant.

Se un utente finale tenta di creare o eliminare un account all'interno del tuo sistema, il servizio Identity Platform 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 agevolmente l'errore sul tuo front-end chiedendo all'utente di eseguire le azioni appropriate per il tuo servizio.

Token di autenticazione

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

Token ID piattaforma di identità	Creato da Identity Platform quando un utente accede a un'app. Questi token sono JWT firmati che identificano in modo sicuro l'utente in un progetto Google Cloud. Questi token contengono informazioni di base del profilo di un utente, inclusa la stringa ID dell'utente, che è univoca per il progetto Google Cloud. Poiché è possibile verificare l'integrità dei token ID, puoi inviarli a un server di backend per identificare l'utente che attualmente ha 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. Le app utilizzano questi token per verificare che gli utenti abbiano eseguito correttamente l'autenticazione con il provider di identità, per poi convertirli in credenziali utilizzabili dai servizi Identity Platform.
Token personalizzati di Identity Platform	Creato 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 account di servizio. Le app utilizzano questi token in modo molto simile a quelli restituiti dai provider di identità federati.

Indirizzi email verificati

Identity Platform considera un'email verificata se soddisfa due condizioni:

L'utente completa il flusso di verifica di Identity Platform
L'indirizzo email viene verificato da un provider di identità o un IdP attendibile.

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

Fornitori affidabili:

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

Provider non attendibili:

Facebook
Twitter
GitHub
Google, Yahoo e Microsoft per i domini non emessi da quel provider di identità
Email / password senza verifica email

In alcuni casi, Identity Platform collega 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 comprendere il motivo, 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 venissero collegati automaticamente, l'utente malintenzionato potrebbe accedere all'account dell'utente.

Di seguito sono riportati i casi in cui colleghiamo automaticamente gli account e viene generato 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 lo stesso indirizzo email (ad esempio Facebook e GitHub). Questo genera un errore durante la richiesta di collegamento dell'account.
L'utente accede con un provider attendibile, quindi accede con un provider non attendibile con lo stesso indirizzo email (ad esempio, Google seguito da Facebook). Questo genera un errore durante la richiesta di collegamento dell'account.
L'utente accede con un provider non attendibile, quindi accede con un provider attendibile con lo stesso indirizzo email (ad esempio Facebook e Google). Il provider attendibile sovrascrive il provider non attendibile. Se l'utente tenta di accedere di nuovo con Facebook, si verifica un errore durante la richiesta di collegamento dell'account.
L'utente accede con un provider attendibile, quindi accede con un altro provider attendibile con lo stesso indirizzo email (ad esempio, Apple seguito da Google). Entrambi i provider saranno collegati senza errori.

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