Being able to immediately revoke user’s access to applications is one of the most requested security related features for Office 365. Because of the different caching mechanisms employed in the service and/or the apps you use, accomplishing this can be a tricky task. As an example, you can refer to this article detailing the different factors that affect this in Exchange (Online). Modern authentication made things even messier, with the very long validity of the refresh tokens and the lack of proper methods to revoke them.
Almost a year ago, the SharePoint Online team gave us the opportunity to revoke access via the Revoke-SPOUserSession cmdlet. I blogged about this here. Now, at long last, we finally have global control over this via the AzureAD PowerShell module and Revoke-AzureADUserAllRefreshToken cmdlet. Here are few examples on how to use the cmdlet:
-
The only parameter the cmdlet accepts is -ObjectId, which isn’t really convenient (if only the folks at Microsoft listened to feedback):
C:\> Revoke-AzureADUserAllRefreshToken -ObjectId 582b2b38-888c-4b85-8471-c9716cb4791b
No output will be returned unless an error occurs.
-
An easier way is to get the objectId via the Get-AzureADUser cmdlet and pipe it to Revoke-AzureADUserAllRefreshToken:
C:\> Get-AzureADUser -SearchString huku | Revoke-AzureADUserAllRefreshToken
-
Similarly, you can do something like this:
C:\> Revoke-AzureADUserAllRefreshToken -ObjectId (Get-AzureADUser -SearchString huku).objectId
-
Our you can get more creative like for example revoking access for all members of a particular group:
C:\> Get-AzureADGroup -SearchString CloudSecGrp | Get-AzureADGroupMember | Revoke-AzureADUserAllRefreshToken
Another similar cmdlet exists, namely Revoke-AzureADSignedInUserAllRefreshToken. It’s used to revoke tokens for the currently signed in user, i.e. the one issuing the cmdlet. It doesn’t accept any parameters and can be used to for testing/development purposes.
Lastly, a word of caution. Although the cmdlet does revoke the refresh token, the access token remains valid and the user will be able to continue to access data until the browser is closed (or the app restarted). In other words, the user is not immediately forced to reauthenticate, but with the refresh token purged he will have to do so as soon as the access token has expired (max 1 hour). Or the app/browser is closed.
An updated version of this article that uses the latest cmdlets from the Microsoft Graph SDK for PowerShell to revoke access can be found here.
Hi, thanks for sharing. Is there a powershell command to validate the current access and refresh token lifetime before i look change the duration or revoke it? I found PS commands to change the token lifetime duration but not able to find the command to validate it.
If you haven’t made any changes, you are using the default values as detailed here: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes
You can get the current policy via Get-AzureADPolicy from the AzureADPreview module. If the cmdlet doesn’t return any info about TokenLifetimePolicy, you are using the defaults.
I see, thank you.
Can we change this for less than an hour, like 5-10 min? Or it’s not recommended.
You can, but the current method to customize validity of access tokens will be deprecated soon, so yes, not recommended.
Any word on the replacement method?
Soon ™
Hi!
Great work there.
I’ve tested on a user but the Outlook continued to send and receive at least 30 minutes after the revoke. Might there a sync delay or simply something to do with the token expiry?
Thank you
Jasmin, this only revokes the Refresh token, as explained in the last paragraph above. Worse case scenario, they will still have access for up to 1 hour.
Hi Vasil
Any recommendations or best practices for adjusting tokens lifetime?
Yeah, don’t. You should only change them if there is a valid need, otherwise leave the defaults. Plus, latest word is that this feature is going away in the future, we’ll see I guess…
You again?! 😀
Thanks!
Thanks for this great article.
Do you know what role is required to run this cmdlet?
I’ve only tested it with Global admin, but I imagine it might work with User admin permissions as well.
I just ran through every single role in a test tenant in order to determine this. It’s Company Administrator (AKA Global Admin) only. You would think Security Administrator and/or User Account Administrator would have this ability, but that’s not the case as far as I can tell.
If the account your trying to run it against has roles like security reader or anything else that is privileged, you will need global admin. If you remove all those roles user admin is all your need.
Vasil, good morning!
Do you know if it’s possible to decrease the token expiration time? I know that it takes 1 hour max, but my client want’s it in 10 minutes.
We can customize it now, 10 mins is the minimum: https://azure.microsoft.com/en-us/documentation/articles/active-directory-configurable-token-lifetimes/
Thank you Vasil!