Comportamento strano del token OAuth2.0 (Credenziali non valide 401)

Question

In genere, il meccanismo di Google OAuth2.0 funziona benissimo.

1. L'utente conferma il permesso di accedere all'account Google con ambiti selezionati.
2. Il token di aggiornamento viene recuperato e salvato nella memoria di lunga durata.
3. Ogni token di accesso necessario (se il token di accesso è scaduto) viene recuperato e utilizzato per accedere alle API.

ma a volte (così lontano solo due volte per più di 6 mesi) ho sperimentato un comportamento strano:

Richieste alle API di Google ritorno credenziali non valide (401) errore. L'aggiornamento del token di accesso (utilizzando il token di aggiornamento memorizzato) non aiuta.

Ecco un output strutturato Ho durante il test di questo numero:

 
    + ------------------------------------------------------------------------- + 
    | 1.TRYING TO REFRESH THE TOKEN.           | 
    | 2.DONE REFRESHING THE TOKEN.            | 
    + ------------------------------------------------------------------------- + 
    | access:   **************************************************** | 
    | refresh:     ********************************************* | 
    | expires:               3600 | 
    | created:           2013-07-23 13:12:36 | 
    + ------------------------------------------------------------------------- + 

Ho anche provato a verificare il token di accesso "fresco" per l'invio di richieste di https://www.googleapis.com/oauth2/v1/tokeninfo

 
    + ------------------------------------------------------------------------- + 
    | 1. TRYING TO CHECK THE TOKEN .           | 
    | 2. DONE CHECKING THE TOKEN THE TOKEN.          | 
    + ------------------------------------------------------------------------- + 
    |  issued_to:     ************.apps.googleusercontent.com | 
    |  audience:     ************.apps.googleusercontent.com | 
    |   user_id:            ************ | 
    |  expires_in:              3600 | 
    |   email:          **********@gmail.com | 
    | verified_email:              1 | 
    |  access_type:             offline | 
    |   scopes::               | 
    + ------------------------------------------------------------------------- + 
    | https://www.googleapis.com/auth/userinfo.email       | 
    | https://www.googleapis.com/auth/userinfo.profile       | 
    | https://www.googleapis.com/auth/plus.me         | 
    | https://www.googleapis.com/auth/drive          | 
    + ------------------------------------------------------------------------- + 

Ma quando provo ad accedere al feed drive la risposta è:

 
    Error calling GET https://www.googleapis.com/drive/v2/files (401) Invalid Credentials 

    domain:   global 
    reason:   authError 
    message:  Invalid Credentials 
    locationType: header 
    location:  Authorization 

Abbiamo anche riscontrato lo stesso problema con i calendari. Quindi:

1. Il token era valido prima (tutto funzionava).
2. Il token di aggiornamento funziona ancora.
3. La richiesta di un feed risponde con l'errore "Credenziali non valide".
4. Tutti gli altri token funzionano ancora bene, il che significa che il codice è valido.

In genere quando viene revocato il token, viene restituito un errore "invalid_grant" quando si tenta di aggiornare il token.

Domande

1. quello che può essere il motivo di questo comportamento? Se il token di aggiornamento è stato revocato o non è più valido in altro modo, la richiesta di un nuovo token di accesso potrebbe produrre un errore?
2. C'è un modo per convalidare il token di aggiornamento?

Answer 1

Per la documentazione API di Google in caso di errori & codici di errore:

https://developers.google.com/drive/handle-errors#401_invalid_credentials

401: Invalid Credentials 

Invalid authorization header. The access token you're using is either expired or invalid. 

error: { 
    errors: [ 
    { 
    "domain": "global", 
    "reason": "authError", 
    "message": "Invalid Credentials", 
    "locationType": "header", 
    "location": "Authorization", 
    } 
    ], 
    "code": 401, 
    "message": "Invalid Credentials" 
    } 
} 

Questo corrisponde alla versione di l'errore esattamente, e così è molto probabilmente quello che pensa di Google è sbagliato con il vostro richiesta.

Ma, come ben sai, le richieste dell'API di Google possono restituire errori che sono decisamente poco utili a diagnosticare effettivamente il problema. Ho ricevuto gli errori "Credenziali non valide" per una serie di motivi. È quasi sempre perché ho fatto una sorta di cambiamento che pensavo non avesse importanza, ma lo è davvero.

Il mio primo pensiero (girato nel buio qui) sarebbe quella di andare alla console di Google API:

https://code.google.com/apis/console

Googles autenticazione verificatore di token (https://www.googleapis.com/oauth2/v1/tokeninfo) può restituire una risposta valida, ma forse il cliente l'ID segreto o client sarà stato modificato.

Anche piccoli cambiamenti nel corpo della risposta possono causare questo errore.

Non so come si stanno facendo richieste, sia tramite chiamate REST o una lib client, ma io uso la Ruby Lib che consente a un'interfaccia a linea di comando di effettuare chiamate API. Ho trovato questo & OAuth2 Playground molto utile per diagnosticare le chiamate API di Google.

Solo una FYI: ho ricevuto solo 2 errori dall'API di Google: "Credenziali non valide" e "Autorizzazioni insufficienti". Quest'ultimo ha quasi sempre avuto a che fare con cattivi scopi. Il primo è praticamente tutto il resto.

Direi anche che se hai avuto solo 2 errori in 6 mesi, sei fortunato!

Answer 2

Recentemente ho riscontrato questo strano errore. La mia correzione: inserisco la funzione che disattiva tutte le sessioni prima del reindirizzamento a AuthUrl.

Answer 3

Ho riscontrato questo problema quando ho provato a provare a modificare l'URL di reindirizzamento in google console e quindi ad aggiornare il file di credenziali json sul server. Ho dovuto cancellare le variabili di sessione prima di ricominciare da capo. Così nel progetto basta farlo una volta:

session_start(); //starts a session 
session_unset(); //flushes out all the contents previously set 

Ricordare di rimuovere il session_unset() dopo funzionamento a secco una volta.

Answer 4

Sono in ambiente di sviluppo. Ho avuto anche questo problema.

Prima ho provato ad aggiornare le credenziali. Nessun risultato. Poi ho cancellato la mia app (dato che sono ancora in fase di sviluppo, che era ok, ma ATTENZIONE QUESTA AZIONE se lo stai già utilizzando in produzione), ne ho creato uno nuovo, ho aggiornato le credenziali JSON sul client. ancora, nessun risultato.

Ho risolto l'errore aprendo una nuova istanza del browser che non è stata registrata nel mio account Google (Navigazione privata, dato che sono su Firefox), ho registrato nuovamente il mio account Google e ho provato ad usare il mio client (che è un'applicazione Web). Sono stato reindirizzato alla schermata di autorizzazione come previsto e dopo, ha funzionato bene per me.

Answer 5

Ho ricevuto (401) Invalid Credentials quando ho rimosso l'accesso al mio account Google per la particolare app. Quindi quello che dovevo fare era chiedere l'URL di autorizzazione (quello che inizia con https://accounts.google.com/o/oauth2/auth), di nuovo.

Answer 6

Mi sono imbattuto in questo stesso problema quando ho avuto bisogno di cambiare i miei ambiti da sola lettura per leggere e scrivere tutti i file.Così, ho aggiornato il mio ambiti da nella parte superiore del mio file da sola lettura a:

// If modifying these scopes, delete your previously saved credentials 
// at ~/.credentials/sheets.googleapis.com-nodejs-quickstart.json 
var SCOPES = ['https://www.googleapis.com/auth/drive']; 

Google, dalla loro guida API, ha questi commenti che dicono ogni volta che si cambia gli ambiti, è necessario aggiornare le credenziali. Credo che questo significhi, anche se non sono sicuro, che il token debba essere aggiornato. Il vecchio token è ancora detenuto da Google e pensava che avessi solo accesso in sola lettura, quindi perché avrebbe restituito un errore 401. Quindi, ho bisogno di rifare il mio token, ma Google non ha mai offerto una nuova schermata di consenso che mi permettesse di dire consentire di leggere e scrivere su tutti i file. Quindi, avevo bisogno di ottenere quello schermo a venire di nuovo, quindi sarebbe creare un nuovo token per sostituire quello vecchio:

fs.readFile(TOKEN_PATH, function(err, token) { 
    if (err) { 
     getNewToken(oauth2Client, callback); 
    } else { 
     getNewToken(oauth2Client, callback); 
    // oauth2Client.credentials = JSON.parse(token); 
    // callback(oauth2Client); 
    } 
    }); 

Dal momento che ho già avuto un gettone salvato, non è mai stato la creazione di uno nuovo. Quindi, ho appena commentato l'uso del vecchio token e gli ho detto di ottenere un nuovo token, non importa se ne abbiamo uno o no. Poi, sono andato alle mie app connesse in Google e ho cancellato le mie vecchie credenziali di connessione. Non sono sicuro che questo passaggio sia necessario, ma sto solo tentando di accedere al mio account personale. Poi, quando ho eseguito il mio programma, mi ha spinto a re-autenticare, e tutto ha funzionato e non ho ricevuto un errore di autenticazione. Al termine, assicurati di rimuovere le righe commentate per utilizzare i token già creati. Stavo usando il file quickstart.js dell'API di Google per tutto questo.

Quindi, quando ho aggiornato i miei ambiti, il vecchio token utilizzava ancora l'ambito di sola lettura, quindi otterrei credenziali non valide (401).

Answer 7

Ho risolto questo problema quando ho rimosso i file json in c: \ Users \ [user] \. Credenziali.

Answer 8

stoccaggio compensazione in Google Chrome ha lavorato per me (non conoscono tutti i dettagli di ciò che 'archiviazione Clear' è di compensazione):

1. F12 (Ctrl + Shift + I)
2. Application Tab
3. Clear storage

Answer 9

Forse questo comportamento è dovuto a una limitazione che Google describes come segue:

Non ci sono attualmente un limite di 50 gettoni di aggiornamento per account utente per cliente. Se viene raggiunto il limite, la creazione di un nuovo token invalida automaticamente il token meno recente senza preavviso. Questo limite non si applica agli account di servizio.

C'è anche un limite maggiore sul numero totale di token che un account utente o un account di servizio può avere su tutti i client. La maggior parte degli utenti normali non supererà questo limite ma l'account di prova di uno sviluppatore potrebbe essere.