8

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?

user2727195
  • 241
  • 2
  • 7

3 Answers3

1

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)

Justin
  • 1,748
0

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

user2727195
  • 241
  • 2
  • 7
0

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

Hugh Morris
  • 81