Quando gli sviluppatori creano software, questo include di routine moduli che vengono eseguiti su un server web, altri moduli che vengono eseguiti nel browser e altri ancora che vengono eseguiti come app mobile Android o iOS. Sia gli sviluppatori che le persone che utilizzano il loro software in genere considerano tutti questi moduli parte di un'unica app.
L'implementazione di OAuth 2.0 di Google supporta questa visione del mondo. Per utilizzare uno qualsiasi dei servizi basati su OAuth2.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 a quali API accederà l'app. Ogni componente di un'app multicomponente è identificato da un ID client, una stringa univoca generata in API Console.
Obiettivi di autorizzazione cross-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. Normalmente, 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 configurato in Google API Console. Pertanto, Google ritiene che quando un utente ha concesso l'accesso a un determinato ambito a qualsiasi ID client in un progetto, la concessione indichi la fiducia dell'utente nell'intera applicazione per quell'ambito.
L'effetto è che all'utente non deve essere richiesto 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 Chrome, app per iOS, app per computer e dispositivi con input limitato.
Token di accesso cross-client
Il software può ottenere token di accesso OAuth 2.0 in vari modi, a seconda della piattaforma in cui viene eseguito il codice. Per i dettagli, vedi Utilizzare OAuth 2.0 per accedere alle API di Google. Di norma, l'approvazione dell'utente è necessaria per concedere un token di accesso.
Fortunatamente, l'infrastruttura di autorizzazione 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.
L'effetto è che se un'app per Android richiede un token di accesso per un ambito specifico e l'utente richiedente ha già concesso l'approvazione a un'applicazione web nello stesso progetto per lo stesso ambito, all'utente non verrà chiesto di approvare di nuovo. 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.