2015-02-09 7 views
15

Ho due applicazioni:Mantenere chiave segreta e token di accesso per JWT in veloce e NodeJS con Facebook API REST

  • del server (REST API Server)
    • nodo js
    • espresso
    • jsonwebtokens
    • express-jwt
    • mangusta
  • cliente (Portable front-end)
    • bootstrap
    • angolare JS
    • locale di stoccaggio
    • angolare-facebook
    • angolare JWT

lateron, l'app client verrà portata per android, iphone e altre piattaforme usando phon eGap. Per OAuth, sto usando Facebook come fornitore. Ora, ho appena realizzato che i Token Web JSON sono la strada da seguire per questo tipo di installazione. La mia domanda è di tipo architettonico piuttosto che sintattica: come gestire una chiave segreta quando si firma il token di accesso di Facebook e l'ID utente con JWT in nodejs?

Quindi questo è come il flusso funziona nella mia app:

  1. angolare cliente ha un pulsante per il login
  2. utente fa clic sul pulsante di> Facebook Auth inizia
  3. client riceve user_id e FB Token di accesso
  4. Client invia [POST json body] entrambi ser_id e token di accesso a Nodo + Server a 'http://server.com/auth/login' espresso
  5. nodo server ha applicato Express-JWT per tutte le rotte, tranne /auth/login con un

    var expressJwt = require ('express-jwt');

    var jwt = require ('jsonwebtoken');

    app.use (expressjwt ({secret: ''}). A meno che ({percorso: ['/ auth/login']}));

  6. server del nodo riceve i dati dal req.body, recupera i dettagli tutto profilo da Facebook utilizzando l'JavascriptSDK, e segni utilizzando

    var di token = expressjwt.firmare ({profilo},);

  7. nodo server negozi (aggiornamenti, se esiste user_id) il nuovo token in dB e lo invia come risposta al cliente
  8. cliente memorizza il nuovo token ha ricevuto in dati JSON in locali-storage
  9. client utilizza angolare JWT per andare a prendere i dati del profilo del nuovo token e automaticamente collegare il nuovo token di intestazione di autorizzazione per tutte le richieste che invia al server

Ora, le mie domande sono:

  1. ne ho veramente bisogno di memorizzare i token JWT nel database? Non sto certamente confrontando i token nelle intestazioni delle richieste con il database
  2. Devo generare chiavi segrete casuali per sicurezza, ogni volta che una persona effettua l'accesso? Se sì, allora come si adatterebbe sia al client che al server?
  3. Quando e dove è necessario verificare la scadenza del token? e come lo aggiorno?

Sono un po 'perso per il flusso di progettazione e il meccanismo.

+0

così finalmente ora come stai facendo ?? stai usando qualche db per archiviare i token revocati o cosa ?? per favore rispondi, sarà molto utile per me –

risposta

13

Annuncio 1. Non è necessario memorizzare il JWT nel database. L'ID utente può far parte del payload, quindi non è necessario.

Ad 2. È prassi comune che l'app lato server utilizzi una chiave segreta per generare tutto il JWT.

Annuncio 3. Verificare se il token è scaduto su ogni richiesta all'API e non consentire l'accesso se il token è scaduto, restituire il codice di stato 401. L'app client dovrebbe richiedere all'utente le credenziali e richiedere una nuova JWT. Se si desidera evitare che gli utenti inviino nuovamente le credenziali, è possibile emettere un token di aggiornamento che in seguito può essere utilizzato per generare un nuovo JWT.

JWT refresh token flow

http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/

+0

Grazie per la risposta. Potresti per favore elaborare un po 'oltre: cosa succede se voglio revocare l'accesso per un particolare token dal lato server? E, se provo a generare una nuova chiave segreta per ciascun utente, per il client, dovrei eseguire anch'io l'hashing e archiviarlo nella memoria locale in modo da decodificare il nuovo token per estrarre le informazioni dal payload? –

+0

Se implementato correttamente, è possibile considerare che i payload JWT dei propri utenti sono i dati _unaltered_ che li hanno inviati in origine. Potresti sfruttare questo per revocare un token: aggiungi un flag "valido" a ogni payload e forza una riautorizzazione se è impostato su false. – sedge

+0

sì ma cosa succede se qualcuno si disconnette se non revocare questo token ora qualcun altro può utilizzare questo token per tutta la vita ?? –

Problemi correlati