Questo documento spiega come implementare l'autorizzazione di accesso OAuth 2.0 API di Google da un'applicazione web JavaScript. OAuth 2.0 consente agli utenti di condividono dati specifici con un'applicazione, conservando i relativi nomi utente, password le informazioni private. Ad esempio, un'applicazione può utilizzare OAuth 2.0 per ottenere l'autorizzazione consentire agli utenti di archiviare i file nei loro Google Drive.
Questo flusso OAuth 2.0 è chiamato flusso di concessione implicita. È progettata per applicazioni che accedono alle API solo quando l'utente è presente nell'applicazione. Questi non siano in grado di memorizzare informazioni riservate.
In questo flusso, l'app apre un URL di Google che utilizza parametri di query per identificarla e il tipo di accesso all'API richiesto dall'app. Puoi aprire l'URL nel browser corrente o un popup. L'utente può eseguire l'autenticazione con Google e concedere le autorizzazioni richieste. Google reindirizza l'utente alla tua app. Il reindirizzamento include un token di accesso, che l'app la verifica e poi la utilizza per effettuare richieste API.
Libreria client delle API di Google e servizi di identità Google
Se utilizzi la libreria client delle API di Google per JavaScript per effettuare chiamate autorizzate a Google, devi utilizzare Libreria JavaScript dei Servizi di identità Google per gestire il flusso OAuth 2.0. Consulta Google i servizi di identità token model, ovvero in base al flusso di concessione implicita di OAuth 2.0.
Prerequisiti
Abilita le API per il progetto
Qualsiasi applicazione che chiama le API di Google deve abilitare tali API nel API Console.
Per abilitare un'API per il tuo progetto:
- Open the API Library in Google API Console.
- If prompted, select a project, or create a new one.
- API Library elenca tutte le API disponibili, raggruppate per prodotto famiglia e popolarità. Se l'API che vuoi abilitare non è visibile nell'elenco, utilizza la ricerca per trovarlo o fare clic su Visualizza tutto nella famiglia di prodotti a cui appartiene.
- Seleziona l'API da abilitare e fai clic sul pulsante Abilita.
- If prompted, enable billing.
- 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 e creare le credenziali per il tuo progetto. Le applicazioni possono quindi utilizzare le credenziali per accedere alle API che hai abilitato per il progetto.
- Go to the Credentials page.
- Fai clic su Crea credenziali > ID client OAuth.
- Seleziona il tipo di applicazione Web Application.
- Compila il modulo. Applicazioni che utilizzano JavaScript per effettuare richieste API di Google autorizzate devi specificare le origini JavaScript autorizzate. Le origini identificano i domini cui l'applicazione può inviare richieste al server OAuth 2.0. Queste origini devono rispettare alle regole di convalida di Google.
Identifica gli ambiti di accesso
Gli ambiti consentono all'applicazione di richiedere solo l'accesso alle risorse di cui ha bisogno, permettendo agli utenti di controllare la quantità di accesso che concedono alla tua applicazione. Pertanto, potrebbe essere una relazione inversa tra il numero di ambiti richiesti e la probabilità l'ottenimento del consenso degli utenti.
Prima di iniziare a implementare l'autorizzazione OAuth 2.0, ti consigliamo di identificare gli ambiti a cui la tua app dovrà avere l'autorizzazione ad accedere.
Il documento sugli ambiti API OAuth 2.0 contiene un elenco completo degli ambiti che potresti utilizzare per accedere alle API di Google.
Ottenere i token di accesso OAuth 2.0
I passaggi seguenti mostrano in che modo la tua 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 avere Consenso prima che possa 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 a OAuth 2.0 di Google o server web.
Endpoint OAuth 2.0
Genera un URL per richiedere l'accesso dall'endpoint OAuth 2.0 di Google all'indirizzo
https://accounts.google.com/o/oauth2/v2/auth
. Questo endpoint è accessibile tramite HTTPS.
e le connessioni HTTP semplici vengono rifiutate.
Il server di autorizzazione di Google supporta i seguenti parametri delle stringhe di query per il web applicazioni server:
Parametri | |||||||
---|---|---|---|---|---|---|---|
client_id |
Obbligatorio
L'ID client dell'applicazione. Puoi trovare questo valore nella sezione API Console Credentials page. |
||||||
redirect_uri |
Obbligatorio
Determina dove il server API reindirizza l'utente dopo che quest'ultimo ha completato la
flusso di autorizzazione. Il valore deve corrispondere esattamente a uno degli URI di reindirizzamento autorizzati per
il client OAuth 2.0, che hai configurato nella
API Console
Credentials page. Se questo valore non corrisponde a
URI di reindirizzamento autorizzato per il Tieni presente che lo schema |
||||||
response_type |
Obbligatorio
Le applicazioni JavaScript devono impostare il valore del parametro su |
||||||
scope |
Obbligatorio
R delimitato da spazi l'elenco degli ambiti che identificano le risorse a cui la tua applicazione potrebbe accedere per conto dell'utente. Questi valori determinano la schermata di consenso che Google mostra al utente. Gli ambiti consentono all'applicazione di richiedere l'accesso solo alle risorse di cui ha bisogno consentendo agli utenti di controllare il livello di accesso che concedono al tuo un'applicazione. Esiste quindi una relazione inversa tra il numero di ambiti richiesti e la probabilità di ottenere il consenso degli utenti. Consigliamo alla tua applicazione di richiedere l'accesso agli ambiti di autorizzazione nel contesto ove possibile. Richiedendo l'accesso ai dati utente nel contesto, tramite autorizzazione incrementale, aiuti gli utenti a trovare più facilmente comprendi perché la tua applicazione ha bisogno dell'accesso richiesto. |
||||||
state |
Consigliato
Specifica qualsiasi valore stringa che l'applicazione utilizza per mantenere lo stato tra
e la risposta del server di autorizzazione.
Il server restituisce il valore esatto che invii come coppia Puoi utilizzare questo parametro per diversi scopi, ad esempio per indirizzare l'utente alla sezione
risorsa corretta nella tua applicazione, invio di nonce e mitigazione delle richieste tra siti
contraffazione. Poiché |
||||||
include_granted_scopes |
Facoltativo
Consente alle applicazioni di utilizzare l'autorizzazione incrementale per richiedere l'accesso a
nel contesto. Se imposti il valore di questo parametro su |
||||||
enable_granular_consent |
Facoltativo
Il valore predefinito è Quando Google abilita autorizzazioni granulari per un'applicazione, questo parametro non non avranno più effetto. |
||||||
login_hint |
Facoltativo
Se la tua applicazione sa quale utente sta tentando di eseguire l'autenticazione, può utilizzare questo parametro per fornire un suggerimento al server di autenticazione di Google. Il server utilizza il suggerimento semplificare il flusso di accesso precompilando il campo dell'email nel modulo di accesso o e seleziona la sessione con accesso multiplo appropriata. Imposta il valore del parametro su un indirizzo email o un identificatore |
||||||
prompt |
Facoltativo
Un elenco di richieste per presentare all'utente, delimitato da spazi, e sensibile alle maiuscole. In caso contrario questo parametro, all'utente verrà chiesto di inviare il messaggio solo la prima volta che richiede l'accesso. Vedi Richiesta di nuovo consenso per ulteriori informazioni. I valori possibili sono:
|
Esempio di reindirizzamento al server di autorizzazione di Google
Di seguito è riportato un URL di esempio, con interruzioni di riga e spazi per una migliore leggibilità.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Dopo aver creato l'URL della richiesta, reindirizza l'utente a quest'ultimo.
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 OAuth L'endpoint 2.0 non supporta la condivisione delle risorse tra origini (CORS). Lo snippet crea un 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 <form> element to submit parameters to OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // 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', '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 richiede il consenso all'utente
In questo passaggio, l'utente deciderà se concedere alla tua applicazione l'accesso richiesto. In questo momento di Google, Google mostra una finestra per il consenso che mostra il nome della tua applicazione e l'API di Google ai servizi a cui chiede l'autorizzazione ad accedere con le credenziali di autorizzazione dell'utente e un riepilogo degli ambiti di accesso da concedere. La l'utente può quindi concedere l'accesso a uno o più ambiti richiesti dalla tua applicazione oppure rifiutare la richiesta.
La tua richiesta non deve fare nulla in questa fase perché attende la risposta da Server OAuth 2.0 di Google che indica se è stato concesso un accesso. Questa risposta è spiegata in al 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. Codici di errore comuni e suggerimenti le risoluzioni sono elencate di seguito.
admin_policy_enforced
L'Account Google non è in grado di autorizzare uno o più ambiti richiesti a causa dei criteri di amministratore di Google Workspace. Consulta l'articolo del Centro assistenza per amministratori di Google Workspace Controllare quali terze parti e quali le app interne accedono ai dati di Google Workspace per ulteriori informazioni su come un amministratore può limitare l'accesso a tutti gli ambiti o a tutti gli ambiti ambiti con restrizioni finché l'accesso non viene concesso esplicitamente al tuo ID client OAuth.
disallowed_useragent
L'endpoint di autorizzazione viene visualizzato all'interno di uno user agent incorporato non consentito dai Norme relative a OAuth 2.0.
Android
Gli sviluppatori Android potrebbero visualizzare questo messaggio di errore quando aprono le richieste di autorizzazione in
android.webkit.WebView
Gli sviluppatori dovrebbero invece usare librerie Android come
Accedi con Google per Android o OpenID Foundation
AppAuth per Android.
Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per Android apre un link web generale in un uno user agent incorporato e un utente accede all'endpoint di autorizzazione OAuth 2.0 di Google nel tuo sito. Gli sviluppatori devono consentire l'apertura dei link generali nel gestore di link predefinito del sistema operativo, che include Link per app Android oppure l'app browser predefinita. La Schede personalizzate di Android è un'opzione supportata.
iOS
Gli sviluppatori iOS e macOS potrebbero riscontrare questo errore quando aprono le richieste di autorizzazione in
WKWebView
Gli sviluppatori dovrebbero invece usare le librerie iOS come
Accedi con Google per iOS o OpenID Foundation
AppAuth per iOS.
Gli sviluppatori web potrebbero riscontrare questo errore quando un'app per iOS o macOS apre un link web generale in
uno user agent incorporato e un utente accede all'endpoint di autorizzazione OAuth 2.0 di Google da
nel tuo sito. Gli sviluppatori devono consentire l'apertura dei link generali nel gestore di link predefinito del
sistema operativo, che include
Link universali
oppure l'app browser predefinita. La
SFSafariViewController
è 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 specifico Organizzazione Google Cloud. Per ulteriori informazioni su questa opzione di configurazione, consulta Tipo 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. Consulta
origin_mismatch
.
invalid_grant
Quando utilizzi l'autorizzazione incrementale, il token potrebbe essere scaduto o la sua validità è stata invalidata. Autentica di nuovo l'utente e richiedi il consenso dell'utente per ottenere nuovi token. Se continui di visualizzare questo errore, accertati che l'applicazione sia stata configurata correttamente e di avere utilizzando i token e i parametri corretti nella richiesta. In caso contrario, l'account utente potrebbe avere eliminati o disattivati.
origin_mismatch
Lo schema, il dominio e/o la porta del codice JavaScript che ha originato la richiesta di autorizzazione non possono corrispondono a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Rivedi autorizzati Origini JavaScript in Google API Console Credentials page.
redirect_uri_mismatch
Il valore redirect_uri
trasmesso nella richiesta di autorizzazione non corrisponde a un
URI di reindirizzamento per l'ID client OAuth. Esamina gli URI di reindirizzamento autorizzati
Google API Console Credentials page.
Lo schema, il dominio e/o la porta del codice JavaScript che ha originato la richiesta di autorizzazione non possono corrispondono a un URI di origine JavaScript autorizzato registrato per l'ID client OAuth. Rivedi le origini JavaScript autorizzate Google API Console Credentials page.
Il parametro redirect_uri
può fare riferimento al flusso OAuth fuori banda (OOB) che ha
è stata deprecata e non è più supportata. Consulta le
guida alla migrazione per aggiornare
e integrazione.
invalid_request
Si è verificato un problema nella richiesta che hai inviato. Ciò potrebbe essere dovuto a una serie di motivi:
- La richiesta non è formattata correttamente
- Nella richiesta mancano dei parametri obbligatori
- La richiesta utilizza un metodo di autorizzazione non supportato da Google. Verifica il tuo OAuth l'integrazione utilizza 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 al redirect_uri
specificato in
una 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 viene restituito un messaggio di errore 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
, anche la stringa del frammento contiene il parametrotoken_type
, che è sempre impostato suBearer
e il parametroexpires_in
, che specifica la durata del token, in secondi. Se il parametrostate
è stato specificato nella richiesta del token di accesso, anche il suo valore è incluso 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 Accesso di sola lettura per visualizzare i metadati dei file su Google Drive:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Al termine del flusso OAuth 2.0, si aprirà la pagina
http://localhost/oauth2callback
. Tale URL produrrà
404 NOT FOUND
errore, a meno che la tua macchina locale non pubblichi un file in
questo indirizzo. Il passaggio successivo fornisce ulteriori dettagli sulle informazioni restituite nel
URI quando l'utente viene reindirizzato alla tua applicazione.
Chiamata alle API di Google
Endpoint OAuth 2.0
Una volta che l'applicazione ha ottenuto un token di accesso, puoi utilizzarlo per effettuare chiamate a un
API per conto di un utente
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 mediante l'inclusione di una query access_token
o un valore Bearer
dell'intestazione HTTP Authorization
. Se possibile,
è preferibile utilizzare l'intestazione HTTP, in quanto le stringhe di query tendono a essere visibili nei log del server. Nella maggior parte dei casi,
casi puoi utilizzare una libreria client per configurare le chiamate alle API di Google (ad esempio,
chiamata all'API Drive Files).
Puoi provare tutte le API di Google e visualizzarne gli ambiti nel OAuth 2.0 Playground.
Esempi GET HTTP
Una chiamata al
drive.files
(l'API Drive Files) utilizzando il protocollo Authorization: Bearer
potrebbe avere il seguente aspetto. Tieni presente che devi specificare un 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 access_token
parametro della stringa di query:
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 (preferita):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Oppure, in alternativa, l'opzione del parametro della stringa di query:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Codice di esempio JavaScript
Lo snippet di codice riportato di seguito mostra come utilizzare CORS (condivisione delle risorse tra origini) 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 per il supporto per CORS nella documentazione della libreria è probabilmente utile per comprendere meglio queste richieste.
In questo snippet di codice, la variabile access_token
rappresenta il token che hai
per effettuare richieste API per conto dell'utente autorizzato. Il completamento
esempio mostra come archiviare quel 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 Libreria client delle API di Google per JavaScript. Il codice si riferisce a una pagina HTML in cui viene visualizzato un pulsante prova con una richiesta API. Se fai clic sul pulsante, il codice verifica se nella pagina è stato archiviato un Il token di accesso all'API nello spazio di archiviazione locale del browser. In questo caso, esegue la richiesta API. Altrimenti, avvia il flusso OAuth 2.0.
Per il flusso OAuth 2.0, la pagina segue questi passaggi:
- Indirizza l'utente al server OAuth 2.0 di Google, che richiede l'accesso al
https://www.googleapis.com/auth/drive.metadata.readonly
ambito. - Dopo aver concesso (o negato) l'accesso a uno o più ambiti richiesti, l'utente viene reindirizzato la pagina originale, che analizza il token di accesso dalla stringa dell'identificatore di frammento.
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 le informazioni sull'account Google Drive dell'utente autorizzato.- Se la richiesta viene eseguita correttamente, la risposta dell'API viene registrata nella fase di debug del browser Google Cloud.
Puoi revocare l'accesso all'app tramite il Autorizzazioni relative a: Account Google L'app sarà contrassegnata come OAuth 2.0 Demo for Google API Docs.
Per eseguire questo codice localmente, devi impostare i valori per YOUR_CLIENT_ID
e
YOUR_REDIRECT_URI
variabili che corrispondono
credenziali di autorizzazione. Variabile YOUR_REDIRECT_URI
deve essere impostato sullo stesso URL su cui viene pubblicata la pagina. Il valore deve corrispondere esattamente a uno dei
gli URI di reindirizzamento autorizzati per il client OAuth 2.0, che hai configurato nel
API Console Credentials page. Se
questo valore non corrisponde a un URI autorizzato, riceverai un redirect_uri_mismatch
. Il progetto deve inoltre avere
aver abilitato l'API appropriata per questa richiesta.
<html><head></head><body> <script> var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE'; var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE'; // Parse query string to see if page request is coming from OAuth 2.0 server. var fragmentString = location.hash.substring(1); var params = {}; var regex = /([^&=]+)=([^&]*)/g, m; while (m = regex.exec(fragmentString)) { params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]); } if (Object.keys(params).length > 0 && params['state']) { if (params['state'] == localStorage.getItem('state')) { localStorage.setItem('oauth2-test-params', JSON.stringify(params) ); trySampleRequest(); } else { console.log('State mismatch. Possible CSRF attack'); } } // Function to generate a random state value function generateCryptoRandomState() { const randomValues = new Uint32Array(2); window.crypto.getRandomValues(randomValues); // Encode as UTF-8 const utf8Encoder = new TextEncoder(); const utf8Array = utf8Encoder.encode( String.fromCharCode.apply(null, randomValues) ); // Base64 encode the UTF-8 data return btoa(String.fromCharCode.apply(null, utf8Array)) .replace(/\+/g, '-') .replace(/\//g, '_') .replace(/=+$/, ''); } // If there's an access token, try an API request. // Otherwise, start OAuth 2.0 flow. function trySampleRequest() { var params = JSON.parse(localStorage.getItem('oauth2-test-params')); if (params && params['access_token']) { 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) { if (xhr.readyState === 4 && xhr.status === 200) { console.log(xhr.response); } else if (xhr.readyState === 4 && xhr.status === 401) { // Token invalid, so prompt for user permission. oauth2SignIn(); } }; xhr.send(null); } else { oauth2SignIn(); } } /* * Create form to request access token from Google's OAuth 2.0 server. */ function oauth2SignIn() { // create random state value and store in local storage var state = generateCryptoRandomState(); localStorage.setItem('state', state); // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth'; // Create element to open OAuth 2.0 endpoint in new window. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': YOUR_CLIENT_ID, 'redirect_uri': YOUR_REDIRECT_URI, 'scope': 'https://www.googleapis.com/auth/drive.metadata.readonly', 'state': state, 'include_granted_scopes': 'true', 'response_type': 'token'}; // 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(); } </script> <button onclick="trySampleRequest();">Try sample request</button> </body></html>
Regole di convalida dell'origine JavaScript
Google applica le seguenti regole di convalida alle origini JavaScript per aiutare gli sviluppatori tengono al sicuro le loro applicazioni. Le tue origini JavaScript devono ottemperare a queste regole. Consulta la sezione 3 RFC 3986 per definizione di dominio, host e schema menzionata di seguito.
Regole di convalida | |
---|---|
Schema |
Le origini JavaScript devono utilizzare lo schema HTTPS, non il semplice HTTP. URI Localhost (inclusi gli URI degli indirizzi IP localhost) sono esenti da questa regola. |
Host |
Gli host non possono essere indirizzi IP non elaborati. Gli indirizzi IP Localhost sono esenti da questa regola. |
Dominio |
“googleusercontent.com” .goo.gl )
a meno che l'app non sia proprietaria del dominio. |
Informazioni utente |
Le origini JavaScript non possono contenere il sottocomponente userinfo. |
Percorso |
Le origini JavaScript non possono contenere il componente del percorso. |
Query |
Le origini JavaScript non possono contenere il componente della query. |
Frammento |
Le origini JavaScript non possono contenere il componente del frammento. |
Caratteri |
Le origini JavaScript non possono contenere determinati caratteri, tra cui:
|
Autorizzazione incrementale
Nel protocollo OAuth 2.0, la tua app richiede l'autorizzazione per accedere alle risorse, che sono identificati dagli ambiti. È considerata una best practice per l'esperienza utente richiedere l'autorizzazione risorse nel momento in cui ne hai bisogno. Per abilitare questa pratica, il server di autorizzazione di Google che supporta l'autorizzazione incrementale. Questa funzionalità ti consente di richiedere gli ambiti in base alle esigenze e, se l'utente concede l'autorizzazione per il nuovo ambito, restituisce un codice di autorizzazione che potrebbe essere scambiato con un token contenente tutti gli ambiti concessi dall'utente al progetto.
Ad esempio, un'app che permette di campionare tracce musicali e creare mix potrebbe richiedere risorse al momento dell'accesso, magari altro che il nome della persona che effettua l'accesso. Tuttavia, salvare un mix completato richiede l'accesso al suo Google Drive. La maggior parte delle persone lo troverà naturale se agli è stato chiesto l'accesso a Google Drive solo nel momento in cui l'app ne aveva bisogno.
In questo caso, al momento dell'accesso l'app potrebbe richiedere openid
e
profile
ambiti per eseguire l'accesso di base e poi richiedere in un secondo momento
https://www.googleapis.com/auth/drive.file
ambito al momento della prima richiesta per salvare 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 qualsiasi ambito implementato nuova autorizzazione combinata.
- Quando utilizzi il token di aggiornamento per l'autorizzazione combinata per ottenere un token di accesso,
token di accesso rappresenta l'autorizzazione combinata e può essere utilizzato per qualsiasi
scope
valori inclusi nella risposta. - L'autorizzazione combinata include tutti gli ambiti concessi dall'utente al progetto API se le concessioni sono state richieste da clienti 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 allo stesso tramite un client mobile, l'autorizzazione combinata includerà entrambi gli ambiti.
- Se revochi un token che rappresenta un'autorizzazione combinata, accedi a tutto di autorizzazione per conto dell'utente associato vengono revocati contemporaneamente.
Gli esempi di codice riportati di seguito mostrano come aggiungere ambiti a un token di accesso esistente. Questo approccio consente per evitare di dover gestire più token di accesso.
Endpoint OAuth 2.0
Per aggiungere ambiti a un token di accesso esistente, includi 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 archiviato
gli ambiti per i quali il token di accesso è valido nello spazio di archiviazione locale del browser. (La
Nel codice di esempio completo è archiviato un elenco di ambiti per i quali il token di accesso
sia valido impostando la proprietà oauth2-test-params.scope
nel dominio locale
storage.)
Lo snippet confronta gli ambiti per i quali il token di accesso è valido con quelli che vuoi utilizzare
per una determinata query. Se il token di accesso non copre tale ambito, viene avviato il flusso OAuth 2.0.
In questo caso, la funzione oauth2SignIn
è la stessa fornita in
passaggio 2 (che verrà fornito più avanti nella
esempio).
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 di un token
In alcuni casi un utente potrebbe decidere di revocare l'accesso concesso a un'applicazione. Un utente può revocare l'accesso visitando Impostazioni account. Consulta le Rimuovi sezione "Accesso a siti o app" della sezione Siti e app con accesso al tuo account documento di supporto per ulteriori informazioni.
È anche possibile che un'applicazione revoca in modo programmatico l'accesso concesso. La revoca programmatica è importante nei casi in cui un utente annulla l'iscrizione, rimuove un un'applicazione o le risorse API richieste da un'app sono cambiate in modo significativo. In altre parole, parte del processo di rimozione può includere una richiesta API per garantire che le autorizzazioni concessi all'applicazione vengono rimossi.
Endpoint OAuth 2.0
Per revocare un token in modo programmatico, l'applicazione invia una richiesta a
https://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 presenta un corrispondente, verrà revocato anche il token di aggiornamento.
Se la revoca viene elaborata correttamente, il codice di stato HTTP della risposta viene
200
. Per le condizioni di errore, viene restituito un codice di stato HTTP 400
con un codice di errore.
Il seguente snippet JavaScript mostra come revocare un token in JavaScript senza utilizzare
Libreria client delle API di Google per JavaScript. Poiché l'endpoint OAuth 2.0 di Google per la revoca
non supporta la condivisione delle risorse tra origini (CORS), il codice crea un modulo e invia
il modulo nell'endpoint anziché utilizzare il metodo XMLHttpRequest()
per pubblicare
richiesta.
function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke'; // Create <form> element to use to POST data to the OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'post'); form.setAttribute('action', revokeTokenEndpoint); // 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 seguire per proteggere i tuoi utenti che stanno implementando più account Protezione con l'utilizzo del servizio di protezione su più account di Google. Questo servizio ti consente iscriviti alle notifiche di eventi di sicurezza che forniscono informazioni alla tua applicazione su modifiche importanti all'account utente. Puoi quindi utilizzare le informazioni per intervenire in base al come decidi di rispondere agli eventi.
Ecco alcuni esempi di tipi di eventi inviati alla tua app dal Servizio di protezione su più 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
Consulta le Proteggere gli account utente con la pagina Protezione su più account . per ulteriori informazioni su come implementare la Protezione su più account e per l'elenco completo degli eventi disponibili.