Is client side jwt-decode safe?

[bhtabor]

First of all, thank you for this simple and elegant starter kit.

I do have one reservation over decoding JWT tokens on the client side. It is unsafe to have a JWT secret on the client side as it may be used to generate fake tokens that will pass server validation.

If this is just for highlighting how to use JWT, I think it would be best to at least mention such vulnerability on the README. What I usually do is generate the JWT token on an API server up on authentication request from the client. Then the client will save it locally (without decoding since the client doesn't have the JWT secret anyway) and, when requesting a protected data, send the token back to the API server with an Authorization header.

[cloudmu]

Hi, thanks for the comments.

JWT token in this use case is "signed" (vs. encrypted) with JWT secret on the server. The client can decode it to extract the payload. You are right that the token should then be sent back to API server in subsequent calls with an Authorization header. The server can "verify" the token signature (with its JWT secret). A forged token (without the JWT secret) will have an invalid signature and will be rejected. You can play around here:
https://jwt.io/
(change the "secret" and you will see the signature validation would fail)

With that said, the JWT is definitely a rudimentary placeholder here and I will add some comments in the readme or in the code to warn people about security concerns.

[bhtabor]

Ohh okay. Thanks for clearing that up. I've mistaken jwt-decode for a jwt decoding with validation. Now I see that it doesn't actually validate the token but just decodes a well formatted JWT. Hence it won't need any secrets. It all started when I assumed that jwt.config.json was being used for jwt-decode.

To be fair, you commented on callMockupLoginApi that the JWT token would have been generated from the API server side. All clear I think. You can close this issue.

[cloudmu]

Ah I see. Good catch. jwt.config.json was indeed used as the secret by the server to generate the token. You can check out an older version to see the server.js. The server.js (along with all my webpack stuff) was removed after porting to create-react-app . jwt.config.json will be removed.

[cloudmu]

There are some discussions for create-react-app to support custom servers. Once it's available I may add the JWT backend back.

[bhtabor]

The custom server support discussion on create-react-app led me to this common use case. Are you planning to include a custom node.js API server for JWT generation? Or, am I missing something?

That would be interesting. I wouldn't use it in my current project since I already have a Rails API server but it could be useful. Is this something that would be relevant in a starter-kit though? May be just a how-to section on the README could be enough. Your starter-kit is too beautiful to be embroiled in such a convoluted setup. :)

If it helps you in your feature addition road map, this is basically how I plan to use this starter-kit.

1. Replace bootstrap-4 with react-bootstrap and bootstrap-3 (this way I don't have to include jquery)
2. Include redux-json-api for syncing to redux store the json-api response from my Rails API server
3. Include reselect for memoized data selection of some expensive calculated results from api reducer state of the redux store
4. Deploy with heroku buildpack for create-react-app

[cloudmu]

There was a minimum JWT based authentication implementation (prior to porting to create-react-app) in my starter kit. But I had to remove it for create-react-app porting to work. It can be added back once create-react-app can support custom server. Hope this clarifies.

@bhtabor Thanks for your suggestions on the road-map. Regarding react-bootstrap, I am on the fence. It would help greatly in most cases, but it's another dependency/lock-in (that may turn out be a hassle). For example the starter kit was using bootstrap 3, and it was very easy to upgrade to bootstrap 4 directly.

[bhtabor]

Clear! Thanks. Fair point on react-bootstrap. I did mind the lock-in like you but then again I had to support IE 8. So, using bootstrap-3 and avoiding jquery happened to be a win-win. Plus, I think react-bootstrap has solid maintainers.

I do agree that it is a tough choice but since this is a slightly opinionated starter-kit I don't think users would mind if you went either way. If they have specific requirements, it is easy to customize it like I do.

[cloudmu]

JWT based API server is added back, thanks to the latest create-react-app feature Proxying API Requests