Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
Thank you good sir! I love the way you explored this concept. Authentication has become a black box to most developers these days. Don't get me wrong, services like Azure AD and Auth0 are awesome and great for quick prototyping, but I feel many developers are so used to having authentication abstracted away that they don't really understand what is going on and all. Thank you for reminding everyone that the token is not encrypted and needs to be checked every time.
The only frustrating thing with JWT is revocation, mainly because it's impossible. If you are building a security-critical app where user rights may need to be revoked at any time, JWT may not be the best choice. The workaround is to maintain a revocation list in the database, preferably with the most recent revocations in a cache, and to check the token against the revocation list.
We had the exact scenario and used JWT very successfully. You state it exactly, create a server based revocation list. In a database, memory cache...whatever. On any incoming requests you will have verify() method to you know, verify the JWT. As one of the many steps of verify(), ensure that the user is not in the revocation list. If they are, the request is denied and a response of unauthorized is generated. We also had a requirement that each login could be revoked. In that case we added a unique serial number (actually a timestamp) to the body of each JWT. Added a check to the verify() method to look up the serial number. We then managed both of these list with time to live and fast caching to ensure performance. And this was all for a Fortune 50 Financial Services company with millions of users world wide.
Wow, this is an amazing story. I see you added some extra steps, which is really cool. Gives me the idea to add a revocation status to my users as well. 👍
This sounds awesome! I have a question though:
What does the unique serial number achieve that blacklisting the JWT doesn't?
By the way, if you are interested in adding more levels of security while maintaining scalability, have a look at supertokens.io. It's one of the most extensive and well thought out solutions that prevents against all session attacks including detecting session hijacking using rotating refresh tokens. Also, this solution is end to end, taking care of all race conditions and network failure issues, so that developers have a very easy time implementing it. For details on how this works, please visit: supertokens.io/blog/the-best-way-t...
First, thanks for your kind words. I appreciate the encouragement a lot 🤗
I always add generated tokens to the user object, so they could themselves remove other logged-in sessions (upon login I check for users with the given id AND token in user object). To block someone, you can delete all their existing tokens and set a flag in the user object to deny any further token generation.
I could write up another blog post on this when I get some time
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.
Thank you good sir! I love the way you explored this concept. Authentication has become a black box to most developers these days. Don't get me wrong, services like Azure AD and Auth0 are awesome and great for quick prototyping, but I feel many developers are so used to having authentication abstracted away that they don't really understand what is going on and all. Thank you for reminding everyone that the token is not encrypted and needs to be checked every time.
The only frustrating thing with JWT is revocation, mainly because it's impossible. If you are building a security-critical app where user rights may need to be revoked at any time, JWT may not be the best choice. The workaround is to maintain a revocation list in the database, preferably with the most recent revocations in a cache, and to check the token against the revocation list.
We had the exact scenario and used JWT very successfully. You state it exactly, create a server based revocation list. In a database, memory cache...whatever. On any incoming requests you will have verify() method to you know, verify the JWT. As one of the many steps of verify(), ensure that the user is not in the revocation list. If they are, the request is denied and a response of unauthorized is generated. We also had a requirement that each login could be revoked. In that case we added a unique serial number (actually a timestamp) to the body of each JWT. Added a check to the verify() method to look up the serial number. We then managed both of these list with time to live and fast caching to ensure performance. And this was all for a Fortune 50 Financial Services company with millions of users world wide.
Wow, this is an amazing story. I see you added some extra steps, which is really cool. Gives me the idea to add a revocation status to my users as well. 👍
This sounds awesome! I have a question though:
What does the unique serial number achieve that blacklisting the JWT doesn't?
By the way, if you are interested in adding more levels of security while maintaining scalability, have a look at supertokens.io. It's one of the most extensive and well thought out solutions that prevents against all session attacks including detecting session hijacking using rotating refresh tokens. Also, this solution is end to end, taking care of all race conditions and network failure issues, so that developers have a very easy time implementing it. For details on how this works, please visit: supertokens.io/blog/the-best-way-t...
Thanks!
First, thanks for your kind words. I appreciate the encouragement a lot 🤗
I always add generated tokens to the user object, so they could themselves remove other logged-in sessions (upon login I check for users with the given id AND token in user object). To block someone, you can delete all their existing tokens and set a flag in the user object to deny any further token generation.
I could write up another blog post on this when I get some time