Quando gli sviluppatori creano software, include di norma moduli eseguiti su un server web, altri moduli eseguiti nel browser e altri eseguiti come app native per dispositivi mobili. Sia gli sviluppatori che le persone che utilizzano il loro software in genere considerano tutti questi moduli come una singola app.
L'implementazione di OAuth 2.0 di Google supporta questa vista del mondo. Per utilizzare uno qualsiasi dei servizi basati su OAuth2.0, devi configurare il software in Google API Console. L'unità organizzativa nel API Console è un "progetto", che può corrispondere a un'app multi-componente. Per ogni progetto puoi fornire informazioni di branding e devi specificare a quali API l'app avrà accesso. Ogni componente di un'app multi-componente è identificato da un ID client, una stringa univoca generata nell'elemento API Console.
Obiettivi di autorizzazione cross-client
Quando un'app utilizza OAuth 2.0 per l'autorizzazione, agisce per conto di un utente di richiedere un token di accesso OAuth 2.0 per l'accesso a una risorsa, che l'app identifica in base a 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, l'utente sta esaminando 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 considera che quando un utente ha concesso l'accesso a un particolare ambito a qualsiasi ID client in un progetto, la concessione indica la fiducia dell'utente nell'intera applicazione per tale ambito.
L'effetto è che non dovrebbe essere chiesto all'utente di approvare l'accesso a qualsiasi 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 di Chrome, app per iOS, app native per desktop e dispositivi a 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 in cui viene eseguito il codice. Per i dettagli, consulta Utilizzare OAuth 2.0 per accedere alle API di Google. In genere, è necessaria l'approvazione dell'utente quando si concede un token di accesso.
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 al momento di valutare se autorizzare altre persone nello stesso progetto.
L'effetto è che se un'app Android richiede un token di accesso per un determinato ambito e l'utente richiedente ha già concesso l'approvazione a un'applicazione web nello stesso progetto per quello stesso ambito, all'utente non verrà chiesto di nuovo di approvare il consenso. Questa soluzione funziona in entrambi i modi: se l'accesso a un ambito è stato concesso nella tua app per Android, non verrà richiesto nuovamente da un altro client nello stesso progetto, ad esempio un'applicazione web.