OAuth 2.0 per applicazioni web lato client (original) (raw)

Questo documento spiega come implementare l'autorizzazione OAuth 2.0 per accedere alle API di Google da un'applicazione web JavaScript. OAuth 2.0 consente agli utenti di condividere dati specifici con un'applicazione, mantenendo privati i propri nomi utente, le password e altre informazioni. Ad esempio, un'applicazione può utilizzare OAuth 2.0 per ottenere l'autorizzazione dagli utenti per archiviare i file nei loro Google Drive.

Questo flusso OAuth 2.0 è chiamato flusso di concessione implicita. È progettato per applicazioni che accedono alle API solo quando l'utente è presente nell'applicazione. Queste applicazioni non sono in grado di memorizzare informazioni riservate.

In questo flusso, la tua app apre un URL Google che utilizza i parametri di query per identificare la tua app e il tipo di accesso API richiesto. Puoi aprire l'URL nella finestra del browser corrente o in un popup. L'utente può autenticarsi con Google e concedere le autorizzazioni richieste. Google reindirizza quindi l'utente alla tua app. Il reindirizzamento include un token di accesso, che la tua app verifica e poi utilizza per effettuare richieste API.

Libreria client delle API di Google e Google Identity Services

Se utilizzi la libreria client delle API di Google per JavaScript per effettuare chiamate autorizzate a Google, devi utilizzare la libreria JavaScript dei Servizi di identità Google per gestire il flusso OAuth 2.0. Consulta il modello di token dei servizi di identità di Google, che si basa sul flusso di concessione implicita OAuth 2.0.

Prerequisiti

Abilitare le API per il progetto

Qualsiasi applicazione che chiama le API di Google deve abilitarle in API Console.

Per abilitare un'API per il tuo progetto:

1. Open the API Library nella Google API Console.
2. If prompted, select a project, or create a new one.
3. API Library elenca tutte le API disponibili, raggruppate per famiglia di prodotti e popolarità. Se l'API che vuoi attivare non è visibile nell'elenco, usa la ricerca per trovarla o fai clic su Visualizza tutto nella famiglia di prodotti a cui appartiene.
4. Seleziona l'API che vuoi abilitare, poi fai clic sul pulsante Abilita.
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

Crea le credenziali di autorizzazione

Qualsiasi applicazione che utilizza OAuth 2.0 per accedere alle API di Google deve disporre di credenziali di autorizzazione che identificano l'applicazione nel server OAuth 2.0 di Google. I passaggi seguenti spiegano come creare le credenziali per il tuo progetto. Le tue applicazioni possono quindi utilizzare le credenziali per accedere alle API che hai abilitato per quel progetto.

1. Go to the Clients page.
2. Fai clic su Crea cliente.
3. Seleziona il tipo di applicazione Applicazione web.
4. Compila il modulo. Le applicazioni che utilizzano JavaScript per effettuare richieste autorizzate alle API di Google devono specificare le origini JavaScript autorizzate. Le origini identificano i domini da cui la tua applicazione può inviare richieste al server OAuth 2.0. Queste origini devono rispettare le regole di convalida di Google.

Identificare gli ambiti di accesso

Gli ambiti consentono alla tua applicazione di richiedere l'accesso solo alle risorse di cui ha bisogno, consentendo al contempo agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Pertanto, potrebbe esserci una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso dell'utente.

Prima di iniziare a implementare l'autorizzazione OAuth 2.0, ti consigliamo di identificare gli ambiti a cui la tua app dovrà accedere.

Il documento Ambiti API OAuth 2.0 contiene un elenco completo di ambiti che puoi utilizzare per accedere alle API di Google.

Ottenere token di accesso OAuth 2.0

I seguenti passaggi mostrano come l'applicazione interagisce con il server OAuth 2.0 di Google per ottenere il consenso di un utente a eseguire una richiesta API per suo conto. La tua applicazione deve disporre di questo consenso prima di poter eseguire una richiesta API di Google che richiede l'autorizzazione dell'utente.

Passaggio 1: reindirizza al server OAuth 2.0 di Google

Per richiedere l'autorizzazione ad accedere ai dati di un utente, reindirizza l'utente al server OAuth 2.0 di Google.

Endpoint OAuth 2.0

Genera un URL per richiedere l'accesso dall'endpoint OAuth 2.0 di Google all'indirizzohttps://accounts.google.com/o/oauth2/v2/auth. Questo endpoint è accessibile tramite HTTPS; le connessioni HTTP semplici vengono rifiutate.

Il server di autorizzazione Google supporta i seguenti parametri della stringa di query per le applicazioni server web:

Di seguito è riportato un URL di esempio, con interruzioni di riga e spazi per facilitarne la lettura.

https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly%20https%3A//www.googleapis.com/auth/calendar.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//developers.google.com/oauthplayground& client_id=client_id

Dopo aver creato l'URL della richiesta, reindirizza l'utente.

Codice di esempio JavaScript

Il seguente snippet JavaScript mostra come avviare il flusso di autorizzazione in JavaScript senza utilizzare la libreria client delle API di Google per JavaScript. Poiché questo endpoint OAuth 2.0 non supporta la condivisione delle risorse tra origini (CORS), lo snippet crea un modulo che apre la richiesta a quell'endpoint.

/*

• Create form to request access token from Google's OAuth 2.0 server. */ function oauthSignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

// Create

// Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': 'YOUR_CLIENT_ID', 'redirect_uri': 'YOUR_REDIRECT_URI', 'response_type': 'token', 'scope': 'https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly', 'include_granted_scopes': 'true', 'state': 'pass-through value'};

// Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); }

// Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); }

Passaggio 2: Google chiede il consenso all'utente

In questo passaggio, l'utente decide se concedere alla tua applicazione l'accesso richiesto. In questa fase, Google mostra una finestra di consenso che indica il nome dell'applicazione e i servizi dell'API di Google che sta richiedendo l'autorizzazione ad accedere con le credenziali di autorizzazione dell'utente, nonché un riepilogo degli ambiti di accesso da concedere. L'utente può quindi acconsentire a concedere l'accesso a uno o più ambiti richiesti dall'applicazione o rifiutare la richiesta.

A questo punto, l'applicazione non deve fare nulla, ma attende la risposta dal server OAuth 2.0 di Google che indica se è stato concesso l'accesso. Questa risposta è spiegata nel passaggio successivo.

Errori

Le richieste all'endpoint di autorizzazione OAuth 2.0 di Google potrebbero mostrare messaggi di errore rivolti agli utenti anziché i flussi di autenticazione e autorizzazione previsti. I codici di errore comuni e le relative soluzioni sono:

admin_policy_enforced

L'Account Google non è in grado di autorizzare uno o più ambiti richiesti a causa delle norme del suo amministratore di Google Workspace. Per maggiori informazioni su come un amministratore può limitare l'accesso a tutti gli ambiti o agli ambiti sensibili e con restrizioni finché l'accesso non viene concesso esplicitamente all'ID client OAuth, consulta l'articolo del Centro assistenza Google Workspace Admin Specificare quali app di terze parti e interne possono accedere ai dati di Google Workspace.

disallowed_useragent

L'endpoint di autorizzazione viene visualizzato all'interno di un user agent incorporato non consentito daicriteri OAuth 2.0 di Google.

Gli sviluppatori iOS e macOS potrebbero riscontrare questo errore quando aprono richieste di autorizzazione inWKWebView. Gli sviluppatori devono invece utilizzare librerie iOS comeAccedi con Google per iOS o AppAuth per iOS di OpenID Foundation.

Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per iOS o macOS apre un link web generico in un user agent incorporato e un utente passa all'endpoint di autorizzazione OAuth 2.0 di Google dal tuo sito. Gli sviluppatori devono consentire l'apertura dei link generali nel gestore di link predefinito del sistema operativo, che include sia i gestori dilink universali sia l'app browser predefinita. Anche la libreriaSFSafariViewController è un'opzione supportata.

org_internal

L'ID client OAuth nella richiesta fa parte di un progetto che limita l'accesso agli Account Google in un' organizzazione Google Cloud specifica. Per saperne di più su questa opzione di configurazione, consulta la sezioneTipo di utente nell'articolo del Centro assistenza Configurare la schermata per il consenso OAuth.

invalid_client

L'origine da cui è stata effettuata la richiesta non è autorizzata per questo client. Vedi[origin_mismatch](#authorization-errors-origin-mismatch).

deleted_client

Il client OAuth utilizzato per effettuare la richiesta è stato eliminato. L'eliminazione può avvenire manualmente o automaticamente nel caso diclient non utilizzati. I clienti eliminati possono essere ripristinati entro 30 giorni dall'eliminazione.Scopri di più.

invalid_grant

Quando utilizzi l'autorizzazione incrementale, il token potrebbe essere scaduto o essere stato invalidato. Autentica di nuovo l'utente e chiedi il suo consenso per ottenere nuovi token. Se continui a visualizzare questo errore, assicurati che la tua applicazione sia stata configurata correttamente e che tu stia utilizzando i token e i parametri corretti nella tua richiesta. In caso contrario, l'account utente potrebbe essere stato eliminato o disattivato.

origin_mismatch

Lo schema, il dominio e/o la porta di JavaScript che ha generato la richiesta di autorizzazione potrebbero non corrispondere a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Controlla le origini JavaScript autorizzate in Google Cloud ConsoleClients page.

redirect_uri_mismatch

Il redirect_uri passato nella richiesta di autorizzazione non corrisponde a un URI di reindirizzamento autorizzato per l'ID client OAuth. Esamina gli URI di reindirizzamento autorizzati nel Google Cloud ConsoleClients page.

Lo schema, il dominio e/o la porta di JavaScript che ha generato la richiesta di autorizzazione potrebbero non corrispondere a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Controlla le origini JavaScript autorizzate in Google Cloud ConsoleClients page.

Il parametro redirect_uri potrebbe fare riferimento al flusso OAuth out-of-band (OOB) che è stato ritirato e non è più supportato. Consulta laguida alla migrazione per aggiornare l'integrazione.

invalid_request

Si è verificato un problema con la richiesta che hai effettuato. Ciò potrebbe essere dovuto a diversi motivi:

• La richiesta non è stata formattata correttamente
• Nella richiesta mancavano i parametri obbligatori
• La richiesta utilizza un metodo di autorizzazione non supportato da Google. Verifica che l'integrazione OAuth utilizzi un metodo di integrazione consigliato

Passaggio 3: gestisci la risposta del server OAuth 2.0

Endpoint OAuth 2.0

Il server OAuth 2.0 invia una risposta a redirect_uri specificato nella richiesta di token di accesso.

Se l'utente approva la richiesta, la risposta contiene un token di accesso. Se l'utente non approva la richiesta, la risposta contiene un messaggio di errore. Il token di accesso o il messaggio di errore viene restituito nel frammento hash dell'URI di reindirizzamento, come mostrato di seguito:

• Una risposta del token di accesso:
  https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600
  Oltre al parametro access_token, la stringa del frammento contiene anche il parametro token_type, che è sempre impostato su Bearer, e il parametro expires_in, che specifica la durata del token in secondi. Se il parametro state è stato specificato nella richiesta del token di accesso, il relativo valore è incluso anche nella risposta.
• Una risposta di errore:
  https://oauth2.example.com/callback#error=access_denied

Esempio di risposta del server OAuth 2.0

Puoi testare questo flusso facendo clic sul seguente URL di esempio, che richiede l'accesso di sola lettura per visualizzare i metadati dei file in Google Drive e l'accesso di sola lettura per visualizzare gli eventi di Google Calendar:

https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly%20https%3A//www.googleapis.com/auth/calendar.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//developers.google.com/oauthplayground& client_id=client_id

Dopo aver completato il flusso OAuth 2.0, il browser ti reindirizza aOAuth 2.0 Playground, uno strumento per testare i flussi OAuth. Vedrai che OAuth 2.0 Playground ha acquisito automaticamente il codice di autorizzazione.

Passaggio 4: controlla quali ambiti sono stati concessi dagli utenti

Quando richiedi più autorizzazioni (ambiti), gli utenti potrebbero non concedere alla tua app l'accesso a tutte. La tua app deve verificare quali ambiti sono stati effettivamente concessi e gestire con grazia le situazioni in cui alcune autorizzazioni vengono negate, in genere disattivando le funzionalità che si basano su questi ambiti negati.

Tuttavia, ci sono delle eccezioni. Le app Google Workspace Enterprise condelega dell'autorità a livello di dominio o le app contrassegnate comeattendibili ignorano la schermata per il consenso alle autorizzazioni granulari. Per queste app, gli utenti non vedranno la schermata di consenso per le autorizzazioni granulari. Invece, la tua app riceverà tutti gli ambiti richiesti o nessuno.

Per informazioni più dettagliate, vediCome gestire le autorizzazioni granulari.

Endpoint OAuth 2.0

Per verificare se l'utente ha concesso alla tua applicazione l'accesso a un ambito specifico, esamina il campo scope nella risposta del token di accesso. Gli ambiti di accesso concessi da access_token espressi come elenco di stringhe sensibili alle maiuscole e minuscole delimitate da spazi.

Ad esempio, la seguente risposta di esempio del token di accesso indica che l'utente ha concesso alla tua applicazione l'accesso alle autorizzazioni di sola lettura per l'attività di Drive e gli eventi di Calendar:

{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }

Chiamata alle API di Google

Endpoint OAuth 2.0

Dopo che l'applicazione ha ottenuto un token di accesso, puoi utilizzarlo per effettuare chiamate a un'API Google per conto di un determinato account utente se sono stati concessi gli ambiti di accesso richiesti dall'API. Per farlo, includi il token di accesso in una richiesta all'API includendo un parametro di query access_token o un valore di intestazione HTTP Authorization Bearer. Se possibile, è preferibile l'intestazione HTTP, perché le stringhe di query tendono a essere visibili nei log del server. Nella maggior parte dei casi puoi utilizzare una libreria client per configurare le chiamate alle API di Google (ad esempio, quandochiami l'API Drive Files).

Puoi provare tutte le API di Google e visualizzare i relativi ambiti inOAuth 2.0 Playground.

Esempi di HTTP GET

Una chiamata all'endpoint drive.files (l'API Drive Files) utilizzando l'intestazione HTTP Authorization: Bearer potrebbe essere simile alla seguente. Tieni presente che devi specificare il tuo token di accesso:

GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token

Ecco una chiamata alla stessa API per l'utente autenticato utilizzando il parametro della stringa di query access_token:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl esempi

Puoi testare questi comandi con l'applicazione a riga di comando curl. Ecco un esempio che utilizza l'opzione dell'intestazione HTTP (opzione preferita):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

In alternativa, l'opzione del parametro stringa di query:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Codice di esempio JavaScript

Il seguente snippet di codice mostra come utilizzare CORS (condivisione delle risorse tra origini diverse) per inviare una richiesta a un'API di Google. Questo esempio non utilizza la libreria client delle API di Google per JavaScript. Tuttavia, anche se non utilizzi la libreria client, la guida al supporto di CORS nella documentazione della libreria ti aiuterà probabilmente a comprendere meglio queste richieste.

In questo snippet di codice, la variabile access_token rappresenta il token che hai ottenuto per effettuare richieste API per conto dell'utente autorizzato. L'esempio completo mostra come archiviare il token nello spazio di archiviazione locale del browser e recuperarlo quando si effettua una richiesta API.

var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.googleapis.com/drive/v3/about?fields=user&' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null);

Esempio completo

Endpoint OAuth 2.0

Questo esempio di codice mostra come completare il flusso OAuth 2.0 in JavaScript senza utilizzare la libreria client delle API di Google per JavaScript. Il codice è per una pagina HTML che mostra un pulsante per provare una richiesta API. Se fai clic sul pulsante, il codice verifica se la pagina ha memorizzato un token di accesso API nello spazio di archiviazione locale del browser. In questo caso, esegue la richiesta API. In caso contrario, avvia il flusso OAuth 2.0.

Per il flusso OAuth 2.0, la pagina segue questi passaggi:

1. Indirizza l'utente al server OAuth 2.0 di Google, che richiede l'accesso agli ambitihttps://www.googleapis.com/auth/drive.metadata.readonly e https://www.googleapis.com/auth/calendar.readonly.
2. Dopo aver concesso (o negato) l'accesso a uno o più ambiti richiesti, l'utente viene reindirizzato alla pagina originale, che analizza il token di accesso dalla stringa dell'identificatore di frammento.
3. La pagina controlla a quali ambiti l'utente ha concesso l'accesso all'applicazione.
4. Se l'utente ha concesso l'accesso agli ambiti richiesti, la pagina utilizza il token di accesso per effettuare la richiesta API di esempio.
   La richiesta API chiama il metodo about.get dell'API Drive per recuperare informazioni sull'account Google Drive dell'utente autorizzato.
5. Se la richiesta viene eseguita correttamente, la risposta dell'API viene registrata nella console di debug del browser.

Puoi revocare l'accesso all'app tramite la paginaAutorizzazioni del tuo Account Google. L'app è elencata come nome dell'applicazione fornito nella pagina del branding all'interno della schermata per il consenso OAuth durante la creazione dell'ID client.

Per eseguire questo codice localmente, devi impostare i valori per le variabili YOUR_CLIENT_ID eYOUR_REDIRECT_URI che corrispondono alle tuecredenziali di autorizzazione. La variabile YOUR_REDIRECT_URI deve essere impostata sullo stesso URL in cui viene pubblicata la pagina. Il valore deve corrispondere esattamente a uno degli URI di reindirizzamento autorizzati per il client OAuth 2.0, che hai configurato in Cloud Console Clients page. Se questo valore non corrisponde a un URI autorizzato, riceverai un errore redirect_uri_mismatch. Il progetto deve anche averabilitato l'API appropriata per questa richiesta.

Try sample request

Regole di convalida dell'origine JavaScript

Google applica le seguenti regole di convalida alle origini JavaScript per aiutare gli sviluppatori a mantenere sicure le loro applicazioni. Le origini JavaScript devono rispettare queste regole. Consulta la sezione 3 dell'RFC 3986 per la definizione di dominio, host e schema, menzionati di seguito.

Autorizzazione incrementale

Nel protocollo OAuth 2.0, la tua app richiede l'autorizzazione per accedere alle risorse, che sono identificate dagli ambiti. È considerata una best practice per l'esperienza utente richiedere l'autorizzazione per le risorse nel momento in cui ne hai bisogno. Per consentire questa pratica, il server di autorizzazione di Google supporta l'autorizzazione incrementale. Questa funzionalità ti consente di richiedere gli ambiti in base alle necessità e, se l'utente concede l'autorizzazione per il nuovo ambito, restituisce un codice di autorizzazione che può essere scambiato con un token contenente tutti gli ambiti che l'utente ha concesso al progetto.

Ad esempio, un'app che consente alle persone di ascoltare campioni di tracce musicali e creare mix potrebbe richiedere pochissime risorse al momento dell'accesso, forse solo il nome della persona che esegue l'accesso. Tuttavia, per salvare un mix completato è necessario l'accesso a Google Drive. La maggior parte delle persone troverebbe naturale se venisse chiesto l'accesso a Google Drive solo nel momento in cui l'app ne ha effettivamente bisogno.

In questo caso, al momento dell'accesso l'app potrebbe richiedere gli ambiti openid eprofile per eseguire l'accesso di base e poi richiedere l'ambitohttps://www.googleapis.com/auth/drive.file al momento della prima richiesta di salvataggio di un mix.

Le seguenti regole si applicano a un token di accesso ottenuto da un'autorizzazione incrementale:

• Il token può essere utilizzato per accedere alle risorse corrispondenti a uno qualsiasi degli ambiti inclusi nella nuova autorizzazione combinata.
• Quando utilizzi il token di aggiornamento per l'autorizzazione combinata per ottenere un token di accesso, quest'ultimo rappresenta l'autorizzazione combinata e può essere utilizzato per qualsiasi valore di scope incluso nella risposta.
• L'autorizzazione combinata include tutti gli ambiti che l'utente ha concesso al progetto API anche se le concessioni sono state richieste da client diversi. Ad esempio, se un utente ha concesso l'accesso a un ambito utilizzando il client desktop di un'applicazione e poi ha concesso un altro ambito alla stessa applicazione tramite un client mobile, l'autorizzazione combinata includerà entrambi gli ambiti.
• Se revochi un token che rappresenta un'autorizzazione combinata, l'accesso a tutti gli ambiti di questa autorizzazione per conto dell'utente associato viene revocato contemporaneamente.

Gli esempi di codice riportati di seguito mostrano come aggiungere ambiti a un token di accesso esistente. Questo approccio consente alla tua app di evitare di dover gestire più token di accesso.

Endpoint OAuth 2.0

Per aggiungere ambiti a un token di accesso esistente, includi il parametro include_granted_scopes nella richiesta al server OAuth 2.0 di Google.

Il seguente snippet di codice mostra come farlo. Lo snippet presuppone che tu abbia memorizzato gli ambiti per cui il token di accesso è valido nello spazio di archiviazione locale del browser. (Il codice dell'esempio completo memorizza un elenco di ambiti per i quali il token di accesso è valido impostando la proprietà oauth2-test-params.scope nello spazio di archiviazione locale del browser.)

Lo snippet confronta gli ambiti per i quali il token di accesso è valido con l'ambito che vuoi utilizzare per una query specifica. Se il token di accesso non copre questo ambito, viene avviato il flusso OAuth 2.0. Qui, la funzione oauth2SignIn è la stessa fornita nelpassaggio 2 (e fornita più avanti nell'esempio completo).

var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly'; var params = JSON.parse(localStorage.getItem('oauth2-test-params'));

var current_scope_granted = false; if (params.hasOwnProperty('scope')) { var scopes = params['scope'].split(' '); for (var s = 0; s < scopes.length; s++) { if (SCOPE == scopes[s]) { current_scope_granted = true; } } }

if (!current_scope_granted) { oauth2SignIn(); // This function is defined elsewhere in this document. } else { // Since you already have access, you can proceed with the API request. }

Revoca del token

In alcuni casi, un utente potrebbe voler revocare l'accesso concesso a un'applicazione. Un utente può revocare l'accesso visitando le impostazioni dell'account. Per saperne di più, consulta la sezioneRimuovere l'accesso di un sito o di un'app del documento di assistenza App e siti di terze parti con accesso al tuo account.

È anche possibile che un'applicazione revochi programmaticamente l'accesso che le è stato concesso. La revoca programmatica è importante nei casi in cui un utente annulla l'iscrizione, rimuove un'applicazione o le risorse API richieste da un'app sono cambiate in modo significativo. In altre parole, parte della procedura di rimozione può includere una richiesta API per garantire che le autorizzazioni precedentemente concesse all'applicazione vengano rimosse.

Endpoint OAuth 2.0

Per revocare un token in modo programmatico, la tua applicazione invia una richiesta ahttps://oauth2.googleapis.com/revoke e include il token come parametro:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded"
https://oauth2.googleapis.com/revoke?token={token}

Il token può essere un token di accesso o un token di aggiornamento. Se il token è un token di accesso e ha un token di aggiornamento corrispondente, verrà revocato anche il token di aggiornamento.

Se la revoca viene elaborata correttamente, il codice di stato HTTP della risposta è200. Per le condizioni di errore, viene restituito un codice di stato HTTP 400 insieme a un codice di errore.

Lo snippet JavaScript seguente mostra come revocare un token in JavaScript senza utilizzare la libreria client delle API di Google per JavaScript. Poiché l'endpoint OAuth 2.0 di Google per la revoca dei token non supporta la condivisione delle risorse tra origini (CORS), il codice crea un modulo e lo invia all'endpoint anziché utilizzare il metodo XMLHttpRequest() per pubblicare la richiesta.

function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke';

// Create

// Add access token to the form so it is set as value of 'token' parameter. // This corresponds to the sample curl request, where the URL is: // https://oauth2.googleapis.com/revoke?token={token} var tokenField = document.createElement('input'); tokenField.setAttribute('type', 'hidden'); tokenField.setAttribute('name', 'token'); tokenField.setAttribute('value', accessToken); form.appendChild(tokenField);

// Add form to page and submit it to actually revoke the token. document.body.appendChild(form); form.submit(); }

Implementare la Protezione su più account

Un ulteriore passaggio da intraprendere per proteggere gli account dei tuoi utenti è l'implementazione della protezione cross-account utilizzando il servizio di protezione cross-account di Google. Questo servizio ti consente di abbonarti alle notifiche degli eventi di sicurezza, che forniscono alla tua applicazione informazioni sulle modifiche principali all'account utente. Puoi quindi utilizzare le informazioni per intraprendere azioni a seconda di come decidi di rispondere agli eventi.

Ecco alcuni esempi dei tipi di eventi inviati alla tua app dal servizio di protezione cross-account di Google:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

Per ulteriori informazioni su come implementare la protezione su più account e per l'elenco completo degli eventi disponibili, consulta la pagina Proteggere gli account utente con la protezione su più account.