I'm relatively new to jwt.io and authentication and I'm using JWT.io in following manner.

Server Side

Once user logs in, I generate a token with userid embedded inside and pass it back to the user in the message body

Client Side Browser/JS I'm storing the token in localStorage and for each subsequent request, I'm passing the token in the headers.

Authorization: Basic someEncryptedValue

I've also used

X-Auth-Token: someEncryptedValue

Could I use this in a cookie?

Then on the server side, I'm verifying the token against the secret, checking expiry, getting the id out of the token and then serving the request.

Is everything correct in this workflow?

  • Any reason not to follow a standard like OAuth2? Btw: you should not pass the token as basic auth header, instead use Authorization: Bearer – Arne Burmeister Mar 14 '17 at 7:48
  • yes Bearer is the right one, OAuth2 is I assume is to authenticate users via 3rd parties like google, Facebook etc. whereas this is my own authentication scheme against user password, please enlighten me more if I'm wrong – user2727195 Mar 14 '17 at 7:55
  • 1
    3rd party auth is only one feature of OAuth, work perfectly with JWT and an own auth server – Arne Burmeister Mar 14 '17 at 8:03
  • ok, please enlighten me with some easy tutorials to implement – user2727195 Mar 14 '17 at 8:06
  • 2
    There's no need of oAuth unless you need applications sharing info among them. For so basic feature as authentication, Jwt is enough. – Laiv May 13 '17 at 7:32

Your workflow is correct (assuming you are using HTTPS), and yes you could just store your token in a Cookie instead of passing it in the authorization header.

I don't recommend using OAuth2. Implementing even the simplest flow properly would add a bunch of complexity to your login process, and it looks to me like you don't need it as your "server side" parts all live on the same domain.

If it were me I'd use cookies. Sticking with well-understood schemes leaves less opportunity for confusion and means the browser takes care of sending and updating your cookie (e.g. consider how you might handle sessions with an idle timeout)

  • 1
    Have you considered the differences between an XSS and CSRF attack? I respectfully suggest that using cookies alone can result in a CSRF vulnerability that is easier to exploit than an XSS-style attack, whereas a token based authentication, while still vulnerable, is harder to exploit. Either way, to absolutely guard against both types of attack, you need both cookie and header token present in the request to safely consider the user authenticated and authorized. – RibaldEddie May 14 '17 at 19:27
  • @RibaldEddie No I hadn't - I guess I assumed that some other mechanism would be used to prevent CSRF. Any chance you could go into more detail? How is token based authentication still vulnerable? And how does using both methods protect against CSRF? – Justin May 15 '17 at 16:05
  • The encrypted token pattern is one solution. So is the double submit cookie. Both of those need another value sent with the request when using cookies to pass the credentials. – RibaldEddie May 15 '17 at 16:16

A good read. It talks about saving tokens to local storage and then sending back via javascript in the http request.

: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

  • 6
    Please, do not just link to external websites to prevent link rot. If the article contains valuable information, provide a summary of the article and post it here. – Andy Mar 14 '17 at 6:43
  • 1
    There's plenty of valuable info in there, a summary of the high points would be nice (like take advantage of JWT signing, use cookies, and some other steps). – Berin Loritsch Jun 13 '17 at 17:59

All browsers now support Digest Auth, which is secure even over HTTP. Depending on your exact requirements, this may be sufficient.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.