Deprovision/Delete/Block use immediately when user is deleted/blocked in Azure AD

We have set up SSO using Auth0.

We are a SAAS provider and our customer has its user on Azure AD. They login to our platform using the Azure AD credentials.

We update the session and fetch a new id_token/access_token before it expires(10 mins) i.e. We use a rotating refresh_token to fetch new id_token/access_token.

Now if the user is deleted or locked in AD, we are still able to fetch new id_token/access_token for that locked/deleted user, and seems like Auth0 doesn’t check the user’s validity.

We want the user’s session to end immediately(or after current access_token expiry). How can we enforce Auth0 to check the user’s validity before it returns the new id_token/access_token?



Hi @RobinNagpal

Have you tried setting your Auth0 session timeout short (like 10 minutes) and relying on your Azure AD timeout being long?

Users will not be validated against Azure AD while their Auth0 session is valid.


@john.gateley thanks for the reply. But that doesn’t have any impact. Here are the settings I am using for testing.

After I login as test user, and then I block the signin in Azure AD, the test user is still able to exchange the id token using the refresh token.

Just to note, the above settings are just for testing i.e. to get early feedback on timeouts

Ah, I missed you are using a refresh token.
You may have to revoke that refresh token when the user is deleted or locked.

I would recommend NOT using a refresh token here and relying on the Auth0 session and silent login.


@john.gateley thanks for the reply.

We want to keep the access_token expiry to a few minutes(~10 mins) considering the best practices.

Also for the silent token to work, we have to keep polling before the access token expires. Even if we do that, if the browser is closed or in the background the token will not be refreshed silently.

Therefore the only solution we found is to implement a SCIM server, which we feel Auth0 should have provided out-of-box