15

I have two applications:

  • server ( REST API Server)
    • node js
    • Express
    • jsonwebtokens
    • express-jwt
    • mongoose
  • client (Portable Front-end)
    • bootstrap
    • Angular JS
    • local-storage
    • angular-facebook
    • angular-jwt

Lateron, the client app will be ported for android, iphone and other platforms using phonegap. For OAuth, I am using Facebook as the provider. Now, I just realized JSON Web Tokens are the way to go for this kind of set up. My question is an architectural one rather than syntactical one - how to manage a secret key when signing the facebook access token and user id with JWT in nodejs?

So this is how the flow works in my app:

  1. Angular client has a Login button
  2. User Clicks the button > Facebook Auth starts
  3. Client receives user_id and FB Access Token
  4. Client sends[POST json body] both user_id and Access Token to Node+Express Server at 'http://server.com/auth/login'

  5. Node Server has applied express-jwt to all routes except /auth/login with a

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

    var jwt = require('jsonwebtoken');

    app.use(expressjwt({ secret: ''}).unless({path: ['/auth/login']}));

  6. Node server receives data from req.body, fetches all profile details from facebook using the JavascriptSDK, and signs it using

    var token=expressjwt.sign({profile}, );

  7. Node Server stores(updates, if user_id exists) the new token in db and sends it as response to client
  8. client stores the new token it received as json data in local-storage
  9. client uses angular-jwt to fetch profile data from the new token and automatically attach the new token in Authorization header for all requests it sends to the server

Now, my questions are:

  1. Do I really need to store the JWT tokens in database? I am certainly not comparing the tokens in request headers with database
  2. Do I need to generate random secret keys for security, each time a person logs in? If yes then how would that fit in both client and server?
  3. When and where do I need to check for token expiration? and How do I refresh it?

I am kind of lost about the design flow and mechanism.

Abhishek Deb
  • 883
  • 1
  • 10
  • 24
  • so finally now how are you doing it ?? are you using some db to store revoked tokens or what ?? please reply must it will be really helpful for me – aman verma Jan 13 '16 at 22:36

1 Answers1

13

Ad 1. You do not have to store the JWT in the database. User ID can be part of the payload, therefore there's no need for it.

Ad 2. It's a common practice for the server side app to use one secret key for generating all JWT.

Ad 3. Check if token has expired on each request to your API and disallow access if the token has expired, return 401 status code. Client app should prompt user for credentials and request new JWT. If you want to avoid users re-submitting the credentials you can issue a refresh token that later can be used to generate new JWT.

JWT refresh token flow

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

Community
  • 1
  • 1
Michal M.
  • 1,072
  • 1
  • 11
  • 14
  • Thanks for the answer. Could you please elaborate a little further : What if I want to revoke access for a particular token from the server side? And, if I try to generate a new secret key for each user, for the client, should I be hashing it too and store it in local storage so as to decode the new token for extracting information from the payload? – Abhishek Deb Feb 10 '15 at 06:28
  • When implemented properly, you can trust that the JWT payloads from your users are the _unaltered_ data you sent them originally. You could leverage that for revoking a token: add a "valid" flag to each payload and force a reauthorization if it's set to false. – sedge May 18 '15 at 20:29
  • yeah but what if someone logout than if u didn't revoke this token now someone else can use this token for the lifetime ?? – aman verma Jan 13 '16 at 22:35
  • 1
    @amanverma Keep your JWT expiry short. That way, all you have to do is revoke the refresh token and then wait for the JWT to expire, at which point revocation is complete. And with a short JWT expiry, you can feasibly implement instant JWT revocation with an in-memory JWT revocation store, as those revocations need not be stored beyond their expiry. – Steve Mar 17 '16 at 08:20