Utenti di Identity Platform nei progetti
L'oggetto user di Identity Platform rappresenta un account utente che ha eseguito la registrazione per un'app nel tuo progetto Google Cloud. Le app in genere hanno molti utenti registrati e ogni app in un progetto Google Cloud condivide un database utente.
Le istanze utente sono indipendenti dalle istanze di Identity Platform, quindi puoi avere diversi riferimenti a utenti diversi nello stesso contesto e chiamare comunque uno dei relativi metodi.
Proprietà utente
Gli utenti di Identity Platform hanno un insieme fisso di proprietà di base (un ID univoco, un indirizzo email principale, un nome e un URL di una foto) memorizzate nel database utente del progetto, che possono essere aggiornate dall'utente (iOS, Android, web). Non puoi aggiungere altre proprietà direttamente all'oggetto utente, ma puoi archiviare le proprietà aggiuntive in qualsiasi altro servizio di archiviazione, ad esempio 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 si è registrato con un provider di identità federato, come Google o Facebook, i dati dell'account resi disponibili dal provider vengono utilizzati per compilare il profilo dell'utente.
- Se l'utente si è registrato con il tuo sistema di autenticazione personalizzato, devi aggiungere esplicitamente le informazioni che ti interessano al suo profilo.
Una volta creato un account utente, puoi ricaricare le informazioni dell'utente per incorporare eventuali modifiche apportate 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 o utilizzando Accedi con Google.
Le istanze utente monitorano tutti i fornitori collegati all'utente. In questo modo puoi aggiornare le proprietà del profilo vuoto utilizzando le informazioni fornite da un fornitore. Consulta la sezione Gestione degli 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 mantiene più il relativo stato; non è presente alcun utente corrente. Tuttavia, l'istanza dell'utente continua a essere completamente funzionale: se 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 corrente dell'istanza Auth è utilizzare gli ascoltatori (chiamati anche "osservatori" in JavaScript). Un ascoltatore Auth viene notificato ogni volta che accade qualcosa di pertinente all'oggetto Auth. Consulta la sezione Gestione dell'attività (iOS, Android, web).
Un ascoltatore Auth riceve una notifica nelle seguenti situazioni:
- L'inizializzazione dell'oggetto Auth è terminata 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 (viene impostato l'utente corrente)
- Un utente effettua la disconnessione (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: si tratta di una situazione comune. Il token di aggiornamento viene utilizzato per ottenere un nuovo insieme valido di token.
- L'utente cambia la password: Identity Platform emette nuovi token di accesso e di aggiornamento e rende scaduti i token precedenti. Per motivi di sicurezza, il token dell'utente scade automaticamente e/o l'utente esce da ogni dispositivo.
- L'utente si autentica di nuovo: alcune azioni richiedono che le credenziali dell'utente siano state emesse di recente, ad esempio l'eliminazione di un account, l'impostazione di un indirizzo email principale e la modifica di una password. Anziché far uscire l'utente e farlo accedere di nuovo, ottieni nuove credenziali dall'utente e passale al metodo di autenticazione dell'oggetto utente.
Self-service per gli utenti
Per impostazione predefinita, Identity Platform consente agli utenti di registrarsi ed eliminare i propri account senza intervento amministrativo. In molte circostanze, questo consente agli utenti finali di scoprire la tua applicazione o il tuo servizio e di eseguirne l'onboarding (o il logout) con il minimo sforzo.
Esistono però situazioni in cui vuoi che gli utenti vengano creati manualmente o tramite programmazione da un amministratore, utilizzando l'SDK Admin o la Console di Google Cloud. In questi casi, puoi disattivare le azioni utente dalla pagina delle impostazioni di Identity Platform, impedendo la creazione e l'eliminazione degli account da parte di un utente finale. Se utilizzi la multitenancy, devi inviare una richiesta HTTP per disattivare queste funzionalità in base al tenant.
Se un utente finale tenta di creare o eliminare un account all'interno del sistema, il servizio Identity Platform restituirà un codice di errore:auth/admin-restricted-operation per le chiamate all'API web o ERROR_ADMIN_RESTRICTED_OPERATION per Android e iOS. Devi gestire in modo corretto
l'errore nel front-end chiedendo all'utente di intraprendere le azioni appropriate per il tuo servizio.
Token di autenticazione
Quando esegui l'autenticazione con Identity Platform, potresti riscontrare tre tipi di token di autenticazione:
| Token ID di Identity Platform | Creati da Identity Platform quando un utente accede a un'app. Questi token sono JWT firmati che identificano in modo sicuro un utente in un progetto Google Cloud. Questi token contengono informazioni di base sul profilo di un utente, inclusa la stringa ID dell'utente, che è univoca per il progetto Google Cloud. Poiché l'integrità dei token ID può essere verificata, puoi inviarli a un server di backend per identificare l'utente che 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 si siano autenticati correttamente con il provider di identità e poi li convertono 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 li utilizzano in modo molto simile ai token 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'email viene verificata da un provider di identità attendibile, o IdP per breve.
Le IdP che verificano l'email una volta, ma poi consentono agli utenti di modificare gli indirizzi email senza richiedere una nuova verifica, non sono attendibili. Le IdP che possiedono il dominio o richiedono sempre la verifica sono considerate attendibili.
Fornitori 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 con autenticazione a più fattori)
Fornitori non attendibili:
- 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 se vengono soddisfatti criteri specifici. Per capire il motivo, prendi in considerazione 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 viene generato un errore che richiede l'intervento dell'utente o dello sviluppatore:
- L'utente accede con un fornitore non attendibile, quindi accede con un altro fornitore non attendibile con lo stesso indirizzo email (ad esempio Facebook seguito da GitHub). Viene visualizzato un errore che richiede il collegamento dell'account.
- L'utente accede con un fornitore attendibile, quindi accede con un fornitore non attendibile con lo stesso indirizzo email (ad esempio, Google seguito da Facebook). Viene visualizzato un errore che richiede il collegamento dell'account.
- L'utente accede con un fornitore non attendibile, quindi accede con un fornitore attendibile con lo stesso indirizzo 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, verrà visualizzato un errore che richiede il collegamento dell'account.
- L'utente accede con un fornitore attendibile, quindi accede con un altro fornitore attendibile con lo stesso indirizzo email (ad esempio Apple seguito da Google). Entrambi i fornitori 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 il proprietario dell'email.