Question: I am working on a api server which revives requests from a mobile app. I am using `JWT` with `ASP.Net MVC Web API 2`. In this Admin gives access of various departments to mobile app users. I set these DeptIds in `Claims` at the time of Login. On every authorised request from app, in a custom action filter attribute I read claims to match deptId in request URL with claims. This all scenario works fine.

Now my problem is, when Admin revokes access of any particular dept from app user, how should I expire the `access_token` of that user so that, on Login request call, I can set new `Claims`. Otherwise, as Admin removes access from server but the deptId still exists in user's `Claims` so user still have access to that department.

One way is on every request, check in database for access but that increases overhead of server also increases response time. So I don't want to go this way.

I didn't find anything on web how to expire token in `JWT`. Can any one help on this?

Answer: 
[Authentication](https://en.wikipedia.org/wiki/Authentication) and [Authorization](https://en.wikipedia.org/wiki/Authorization) are different things.

Use JWT for Authentication but not for Authorization. I mean that using JWT you can know who the user are but don't put information about what user can do into the JWT. Check permissions for the user on the server side basing on just user's identity that you got from JWT. You may also put into JWT some information that additionally limits access rights (i.e. blacklisting; for example, social network site creates an access token for a game to access my identity and friends list but not my posts) but don't put there information that directly provides access to some features (i.e. whitelisting). In that way you can easily remove access to some features on your sever-side despite that fact that the user is already logged in with JWT.
I understand you are interested in *revoking* or *invalidating* tokens instead of *expiring* them.

Revoking or invalidating tokens
-------------------------------

Unfortunately​ it's not possible to achieve it
without keeping the track of the tokens somewhere:

* Issue a token and add it to a whitelist to keep the track of it.
* When validating a token, check the whitelist and refuse the request if it is not whitelisted.
* To revoke or invalidate a token, remove it from the whitelist.

This security schema require some trade-offs. *Deal with it.*

Performance considerations
--------------------------

Regarding your performance concerns: Bear in mind that [*premature optimization is the root of all evil*](https://softwareengineering.stackexchange.com/a/80092/122966). You shouldn't optimize until you have a performance problem and you *have proven* that the performance problem comes from the way you store your tokens.

You could start storing the tokens in the database and then consider a cache in memory, for example. But always be careful when fixing a problem that you currently don't have.

Token identifier
----------------

The [`jti`](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7) claim should be used to store the token identifier on the token. When validating the token, ensure that it's valid by checking the value of the [`jti`](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7) claim against the token identifiers you have on server side.

For the token identifier you could use a [UUID](https://www.rfc-editor.org/rfc/rfc4122).