You're results are effectively that you've manage to create a secure-as-sessions system, but with a bunch of extra steps, and a couple missing features.
Because you are querying your database to validate every request by the "permissions token", you don't actually even need to check the signature is valid (except for the other data, which I'll get to a moment). With a long random string, you have a secure credential by itself. You can instead just use that long random string as the only identifier (in the httpOnly cookie), and when you query your user, also grab the permission from the database. Now your permission are always fresh. For the client, since you don't need to send the permission (or any other "validated" data) back, you can just send the plain data down, no need to encode it or use a JWT at all.
And... that's how regular cookie-based sessions work.
Thank you for your feedback. I appreciate you taking the time to read it and give helpful feedback. I take it as a slight compliment that you said I "managed to create a secure-as sessions system"😃. I suppose I could have done much worse. I agree that the end result doesn't have much advantage over cookie-based sessions and is arguably more complicated. This is the first authentication system I have ever built from scratch. I did it with the purpose of learning authentication a bit better. It started out with the goal of being stateless as I was originally only going to use the split cookie approach. As I realized the need for some additional features for CSRF and expiring tokens if permission changed etc. it changed incrementally to what is shown in the post. At that point it would probably have been a better idea to switch over to a sessions based system.
When I first tweeted with a link to this post I was mainly trying to make the point that if you are talking about using a JWT and storing the token in local storage it would be better and more secure to use a split token with the signature in an httpOnly cookie so that the whole token could not be accessed by javascript in the client.
Again, thank you for your feedback.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You're results are effectively that you've manage to create a secure-as-sessions system, but with a bunch of extra steps, and a couple missing features.
Because you are querying your database to validate every request by the "permissions token", you don't actually even need to check the signature is valid (except for the other data, which I'll get to a moment). With a long random string, you have a secure credential by itself. You can instead just use that long random string as the only identifier (in the httpOnly cookie), and when you query your user, also grab the permission from the database. Now your permission are always fresh. For the client, since you don't need to send the permission (or any other "validated" data) back, you can just send the plain data down, no need to encode it or use a JWT at all.
And... that's how regular cookie-based sessions work.
Thank you for your feedback. I appreciate you taking the time to read it and give helpful feedback. I take it as a slight compliment that you said I "managed to create a secure-as sessions system"😃. I suppose I could have done much worse. I agree that the end result doesn't have much advantage over cookie-based sessions and is arguably more complicated. This is the first authentication system I have ever built from scratch. I did it with the purpose of learning authentication a bit better. It started out with the goal of being stateless as I was originally only going to use the split cookie approach. As I realized the need for some additional features for CSRF and expiring tokens if permission changed etc. it changed incrementally to what is shown in the post. At that point it would probably have been a better idea to switch over to a sessions based system.
When I first tweeted with a link to this post I was mainly trying to make the point that if you are talking about using a JWT and storing the token in local storage it would be better and more secure to use a split token with the signature in an httpOnly cookie so that the whole token could not be accessed by javascript in the client.
Again, thank you for your feedback.