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: 
A JWT token happens to be a kind of token that allows it to be self-contained i.e. one can validate it without consulting an external entity.

That also means that there's no external entity that will tell you that the token was revoked or expired. Expiration can only happen by some property in the JWT itself; the [`exp`](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4) claim was standardized for that purpose: it will tell the recipient the time after which the information in it must no longer consider to be valid
[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.