I have 2 apps one spring boot and another in angular. Currently I have integrated my application with azure ad and hence authenticating through it. Now the question here is when the user logs out from the front end app, how to invalidate the JWT token provided by Azure AD, if the token is not expired. Because, if someone is able to get the token despite user gets logged out, he can use that token to retrieve data from the backend. Any idea how to do this ?
-
why not deleting the token when user logs out ? – Krunal Shah Jan 07 '20 at 08:49
-
But let's suppose someone has stored the token before the user logs out, then in that case we need to invalidate. – Tapesh Gupta Jan 07 '20 at 08:50
-
what you described in question was how to invalidate token when user logs out! – Krunal Shah Jan 07 '20 at 08:52
3 Answers
Your question is one that has got many people looking for a definitive answer. In short: there is no clear-cut answer. Sure, there are some options that kinda work, but none of them are fool-proof.
I think the answer to the SO question Invalidating JSON Web Tokens sums up your options best:
- Remove the token from the client
- Create a token blacklist
- Just keep token expiry times short and rotate them often
I've seen option 3 to be the most successful 'in the field'.

- 14,105
- 2
- 40
- 53
As far as I know, there is no way to invalidate an Id token / access token after it has been issued. You can invalidate refresh tokens though: https://learn.microsoft.com/en-us/graph/api/user-revokesigninsessions?view=graph-rest-1.0&tabs=http. Those do not apply to a front-end SPA though.

- 54,244
- 13
- 113
- 149
-
Then how to deal with the situation : If someone gets the token before the user logs out, and uses it post that, provided jwt token is not expired. – Tapesh Gupta Jan 07 '20 at 08:59
-
How will they get the token? You are passing it over TLS connections and the browser should keep local storage/session storage specific to an application. – juunas Jan 07 '20 at 09:22
-
browser local/session storage can be accessed through java script.. and would be vulnerable to cross site scripting – Tapesh Gupta Jan 07 '20 at 09:50
-
Sure, and so are authentication cookies. Even if you could invalidate the token when the user logs out, the XSS would still work while the user is logged in. – juunas Jan 07 '20 at 09:53
-
1The revokesigninsessions is a global reset of all of the user's tokens. The user will basically be signed out of every single app including their mobile and desktop apps. This is a very disruptive API call and should not be used lightly. – Merill Fernando Jan 07 '20 at 21:39
-
@juunas is correct. That is how the protocol is designed. If you use the ADAL / MSAL libraries, they store the JWT securely. – rbrayb Jan 14 '20 at 18:33
I wanted to share an Azure AD specific answer to this.
The issue your raising here is the same across the board for all Azure AD tokens. This includes first party apps by Microsoft (SharePoint, Word, Teams, Outlook). The default token expiry is 60 minutes for access tokens and 90 days for refresh tokens. Then you have other factors like MaxInactiveTime, MaxSessionAge etc that affect the refresh token's lifetime.
Microsoft toyed with the idea of configurable token lifetimes (see https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes) but it caused issues so they have dropped it in favour of using Conditional Access policies where the Azure AD tenant owner can specify tenant level sign in frequency). Note however this only applies to refresh tokens.
The access token is hard set to a 60 minute window after which it expires. It is the responsibility of the app developer to ensure the safety of the access token. The best practice is to always have it in memory and never write it to a permanent store or expose it over urls where it can be logged.

- 177
- 1
- 4