Identità cross-client

Quando gli sviluppatori creano software, di solito includono moduli che vengono eseguiti su un server web, altri moduli che vengono eseguiti nel browser e altri ancora che vengono eseguiti come app mobile native. Sia gli sviluppatori sia le persone che utilizzano il software in genere considerano tutti questi moduli come parte di un'unica app.

L'implementazione di OAuth 2.0 di Google supporta questa visione del mondo. Per utilizzare uno dei servizi basati su OAuth 2.0, devi configurare il software in Google API Console. L'unità di organizzazione in API Console è un "progetto", che può corrispondere a un'app multicomponente. Per ogni progetto, puoi fornire informazioni sul branding e devi specificare le API a cui l'app accederà. Ogni componente di un'app multicomponente è identificato da un ID client, una stringa univoca generata in API Console.

Obiettivi di autorizzazione tra client

Quando un'app utilizza OAuth 2.0 per l'autorizzazione, agisce per conto di un utente per richiedere un token di accesso OAuth 2.0 per accedere a una risorsa, che l'app identifica tramite una o più stringhe di ambito. In genere, all'utente viene chiesto di approvare l'accesso.

Quando un utente concede l'accesso alla tua app per un determinato ambito, visualizza la schermata per il consenso dell'utente, che include il branding del prodotto a livello di progetto che hai configurato in Google API Console. Pertanto, Google ritiene che quando un utente ha concesso accesso a un determinato ambito a qualsiasi ID cliente in un progetto, la concessione indichi la fiducia dell'utente nell'intera applicazione per quell'ambito.

L'effetto è che all'utente non deve essere chiesto di approvare l'accesso a una risorsa più di una volta per la stessa applicazione logica, ogni volta che i componenti dell'applicazione possono essere autenticati in modo affidabile dall'infrastruttura di autorizzazione di Google, che oggi include app web, app per Android, app per Chrome, app per iOS, app desktop native e dispositivi con input limitato.

Token di accesso cross-client

Il software può ottenere i token di accesso OAuth 2.0 in diversi modi, a seconda della piattaforma su cui viene eseguito il codice. Per maggiori dettagli, consulta Utilizzare OAuth 2.0 per accedere alle API di Google. Di norma, per concedere un token di accesso è necessaria l'approvazione dell'utente.

Fortunatamente, l'infrastruttura di autorizzazione di Google può utilizzare le informazioni sulle approvazioni degli utenti per un ID client all'interno di un determinato progetto per valutare se autorizzare altri utenti nello stesso progetto.

Il risultato è che se un'app per Android richiede un token di accesso per un determinato ambito e l'utente che effettua la richiesta ha già concesso l'approvazione a un'applicazione web nello stesso progetto per lo stesso ambito, all'utente non verrà chiesto di nuovo di dare l'approvazione. Questo funziona in entrambi i modi: se l'accesso a un ambito è stato concesso nella tua app per Android, non verrà richiesto di nuovo da un altro client nello stesso progetto, ad esempio un'applicazione web.