2016-05-24 60 views
5

Sto scrivendo un'app Android per le chat vocali e ho deciso di utilizzare Google Sign-In per un'autenticazione utente semplice con il mio server back-end. Tuttavia, non capisco come l'app dovrebbe autenticarsi con il mio back-end. Quando un utente effettua l'accesso utilizzando il suo account Google e ricevo il token ID, posso inviare il token ID al server, quindi il server lo verifica. E poi cos'è? Come autenticare le seguenti richieste, ad esempio quando l'utente invia/riceve un messaggio vocale e l'app deve caricare/scaricare il messaggio sul/dal server? Il server deve sapere quale utente sta effettuando la richiesta, ma il token ID non è appropriato perché scade a breve e la sua verifica dell'integrità è un processo complesso e relativamente lungo.Autenticazione del server back-end di Google Sign-in

+0

hey Salivan, hai mai trovato una soluzione o un approccio per questa situazione? – rastadrian

+0

Penso che la risposta di Utsav Dusad sia la più appropriata. – Salivan

+0

Quindi ogni richiesta conseguente con forse un'intestazione di autorizzazione contenente il valore idToken? Se è così, e dato che idToken è una JWT, forse come Autorizzazione: Bearer {idToken}? – rastadrian

risposta

5

Google API Sign-in: sono coinvolti passaggi seguenti:

  • segni utente nella Google utilizzando l'applicazione iOS/Android.
  • Google restituisce tokenid (e alcune informazioni aggiuntive. Vedere lo link per ulteriori informazioni) al client (app iOS/Android).
  • Il client invia il tokenid al server di back-end.
  • Il server
  • utilizza l'API del client di Google (o chiama il punto di fine di google effettuando la richiesta GET ma attenzione che abbia un ritardo di rete associato) per verificare l'integrità del token. In questa fase devono essere soddisfatti determinati criteri. Vedi Here.
  • GoogleAPI restituisce alcune informazioni al server. Che tipo di informazioni? Qualcosa di simile a questo:

{u'picture ': u' https://lh3.googleusercontent.com/-RD4yn7rqIc8/AAAAAAAAAAI/AAAAAAAALQI/9Ab_kR3_CII/s96-c/photo.jpg ' u'sub ': u'10270538098780639-55', u'family_name ': u'Dusad', u' iss ': u' https://accounts.google.com 'u'email_verified ': vero, u'name': u'Utsav Dusad', u'at_hash ': u'BMjN0mWeOMqVVBhjW_W9A', u'given_name ': u'Utsav', u 'exp': 1484582338, u'azp ': u'85959433390-npk1ss7juimjqt5hrlhm7v2fj2u7593f.apps.googleusercontent.com', u'iat ': 1484578738, u'locale': u'en-GB ', u'email': u'[email protected] ', u'aud': u'85959433390-npk1ss7juimjqt5hrlhm7v2fj2u7593f.apps.googleusercontent.com '}

sub: Soggetto. ID utente. Non utilizzare l'ID e-mail come chiave primaria in quanto potrebbe cambiare. usa userID.

Un identificatore per l'utente, unico tra tutti gli account Google e mai riutilizzato. Un account Google può avere più email in diversi punti in tempo, ma il valore secondario non viene mai modificato. Utilizzare sub all'interno dell'applicazione come chiave identificatore univoco per l'utente.

Per informazioni dettagliate consultare here:

  • Server restituisce login successo al client.
  • client effettua successive richieste HTTP POST, GET con tokenID.
  • Il server serve i dati verificando l'idtoken e controllando le informazioni "sub" (sub è l'identità univoca di un utente).
1

Sembra che la spiegazione che vi serve è a: https://developers.google.com/identity/sign-in/web/backend-auth#verify-the-integrity-of-the-id-token

E spiega:

Dopo aver ricevuto il token ID da HTTPS POST, è necessario verificare la integrità del token. Per verificare che il token è valido, in modo che i seguenti criteri sono soddisfatti:

Il token ID è un JWT che è correttamente firmato con un appropriato Google chiave pubblica (disponibile in formato JWK o PEM). Il valore di aud nel token ID è uguale a uno degli ID client della tua app. Questo controllo è necessario per impedire che i token ID rilasciati a un'app dannosa vengano utilizzati per accedere ai dati relativi allo stesso utente sul server di back-end della tua app. Il valore di iss nel token ID è uguale a accounts.google.com o https://accounts.google.com. Il tempo di scadenza (exp) del token ID non ha superato . Se la tua richiesta di autenticazione ha specificato un dominio ospitato, il token ID ha un reclamo hd corrispondente al dominio ospitato da Google Apps.

Essa afferma:

Invece di scrivere il proprio codice per eseguire questa procedura di verifica, si consiglia vivamente di utilizzare una libreria client API di Google per la propria piattaforma , o chiamando il nostro endpoint convalida tokeninfo.

Continua a mostrare esattamente ciò che è necessario fare.

+1

No, assolutamente non risponde alla mia domanda. Quindi dovrei inviare il token ID ad ogni richiesta? Perché è ridicolo. :) – Salivan

+1

Hai appena mostrato come verificare il token e ho chiesto come autorizzare le seguenti richieste dopo quella che ha verificato il token. – Salivan

+1

Ok, penso che quello che stai cercando sia monitorare la sessione dell'utente (argomento correlato: https://developers.google.com/identity/sign-in/web/session-state) Una volta che l'utente è autenticato, la sessione può essere "fidato". – raddevus

Problemi correlati