ASP.Net Web Api 2, json web token, logout and ensure that the server should not authenticate token anymore

Question

I am working on asp.net web api 2 and used JWT for authentication. The application is working fine as it generates token on login request from user, and then user can use that token for subsequent request. But I have some security concerns like

1. What if the token is stolen from user's browser, How can server detect a valid request among two requests sent from two different computers.
2. When user will sign out, how server can detect that this particular token is now invalid/loggedout. As I read about log out, it is merely deletion of token from client browser, so stolen token will still be there, requesting from other pc.
3. How can server revoke a token when expiration period reached?

Please comment if my question is not clear.

Answer 1

Please find the answers as below:

1) Access tokens like cash, if you have it then you can use it, if you have valid access token there is no way to identify if the request is coming Authorized party or not, thats why HTTPS must be used with OAuth 2.0 and bearer tokens.

2) Self contained tokens like JWT are not revocable, so there is no DB checks and this is the beauty of it, you need to leave those tokens until they expire. If you used reference tokens then you will be able to revoke them, but the draw back for this approach is hitting the DB with each API call to validate the token.

3) Already answered in part 2.

You can check my series of posts about this topic using the below links:

Token Based Authentication using ASP.NET Web API 2, Owin, and Identity.

AngularJS Token Authentication using ASP.NET Web API 2.

JSON Web Token in ASP.NET Web API 2 using Owin.

Answer 2

When it comes to JWT revocation the general idea seems to be either that:

• it simply can't be done
• or it can be done, but it goes against the stateless nature of JWT.

I generally don't agree with either. First JWT is just a token format (Learn JSON Web Tokens), yes it can be used to shift some state from servers to clients, but that does not impose any restriction on what we can and should do to consider them valid from the point of view of our application.

Second, if you understand the implications and the associated cost of implementing revocation functionality and you think it's worthwhile to use self-contained tokens instead of alternatives that could simplify revocation but increase the complexity elsewhere then you should go for it.

Just one more word on the stateless thing, I think I could only agree to it in the remote chance that the application receiving and validating tokens does not maintain any state at all. In this situation, introducing revocation would mean introducing a persistent store where one did not exist before.

However, most applications already need to maintain some kind of persistent state so adding a few more bits to track blacklisted/invalid tokens is a non-issue. Additionally, you only need to track that information until the token expiration date.

Having covered the general theory, lets go through your individual questions:

1. If your security requirements mandate that you need to employ additional measures to try to detect malicious use of a token then you're free to do so. A simple example would be blacklisting a token if you detect usage of the same token coming from very different geographical locations.
2. With support for token revocation in place the application logout scenario would just need to include a step to blacklist the associated token.
3. I may be missing something here, but if the token expiration time was reached the regular process to validate a JWT would already include a check to make sure that the token was not yet expired.