Entra External Id: the Graph revokeSignInSession endpoint doesn't invalidate refresh tokens for users on social sso identity provider

John Runyen 0 Reputation points
2026-10-30T14:41:58.4766667+00:00

I have an Entra External Id tenant which I use as my IdP. It has local accounts + Google enabled as a social SSO provider. I'm seeing weird behavior for google sign-ins where when I revoke a user's sessions on the graph api, I get a 200 back, but the refresh token can continue to be redeemed for fresh access tokens. I gave it 30 minutes in my testing, and the refresh token worked the whole time. I imagine it probably won't suddenly revoke after the 30 minute mark, which says to me revoking sessions for social sso sign-ins isn't working at all.

I also verified the user object's signInSessionsValidFromDateTime gets updated to whenever the revoke request is sent. The refresh tokens are from before that time but still working.

My tenant has a confidential-client/redirect login flow and native sign-in enabled for local accounts, and the session revocation works for both of those scenarios. It's only when the user signs in through the google sso provider that session revocation fails.

Has anyone else seen this or is there anything you suggest trying here? I'm not seeing anyone online talk about this nor do I see it documented anywhere as a product limitation and I'm fairly sure it's not a configuration issue or a code issue. A minimal harness that redeems the refresh token/revokes the session/checks the redeem again shows the revocation works for local accounts but not a google sso account.

Microsoft Security | Microsoft Entra | Microsoft Entra External ID
0 comments No comments

1 answer

Sort by: Newest
  1. AI answer

    2026-10-30T14:43:13.1366667+00:00

    The Google-federated result matches Microsoft Graph’s documented exclusion for external users, but it conflicts with the External ID feature matrix, so treat this as a product/documentation gap and open a Microsoft support case with your minimal reproduction rather than continuing configuration changes.

    revokeSignInSessions normally resets signInSessionsValidFromDateTime, after which refresh-token redemption should fail following a delay of a few minutes. However, the API documentation explicitly says that it doesn’t revoke sessions for external users because they authenticate through their home identity provider.^1^

    A Google-federated identity authenticates outside the tenant, while External ID creates a corresponding user object in the external tenant.^2^ This is consistent with the behavior you observed:

    • Graph returns success and advances signInSessionsValidFromDateTime.
    • Locally authenticated users’ refresh tokens stop working.
    • Google-federated users’ existing refresh tokens remain redeemable.
    • Thirty minutes is well beyond the API’s documented “few minutes” propagation period.

    Why this still warrants a support case

    The External ID feature comparison says that session and token revocation is the same for workforce and external tenants, and specifically states that an administrator can invalidate all refresh tokens and sessions for a user.^3^ It does not qualify that statement by authentication method or exclude Google federation.

    That conflicts with the Graph API’s external-user exclusion. The available documentation also does not clearly establish whether a customer account created through Google federation is intended to fall under that exclusion for this operation. Therefore, the evidence supports the observed limitation, but not whether it is intended behavior or a defect.

    Open a support request and include:

    1. External tenant ID and application/client ID.
    2. Affected user’s object ID, without posting it publicly.
    3. UTC timestamps for:
      • Google authentication,
      • refresh-token issuance,
      • revokeSignInSessions,
      • successful post-revocation redemptions.
    4. Graph request ID/client-request ID and the 200 response.
    5. signInSessionsValidFromDateTime before and after revocation.
    6. Token endpoint correlation IDs from successful post-revocation redemption.
    7. A side-by-side trace using the same app and scopes:
      • local account: redemption fails after revocation;
      • Google account: redemption continues.
    8. Confirmation that both refresh tokens were issued by the External ID token endpoint—not directly by Google.
    9. The two conflicting documentation statements above.

    A separate public report also describes revokeSignInSessions not invalidating refresh tokens, although it does not establish the same Google-federated External ID case.^4^

    Immediate containment

    For security-sensitive logout or account-compromise handling, do not rely solely on this endpoint for Google-federated customers:

    1. Block the customer account in External ID. Microsoft’s revocation guidance pairs disabling the account with revoking sessions; after those actions, the user should be unable to obtain new tokens.^5^
    2. Invalidate your application’s own session and deny further API access for the user. Entra cannot revoke a session cookie issued by your application; the application must do that itself.^5^
    3. Continue rejecting the user at the API authorization layer until the account is intentionally restored. Existing access tokens can otherwise remain usable until expiry.
    4. Do not revoke the user’s Google account or Google grants as a substitute. The refresh token under test was issued by External ID, so Google-side logout is a separate session boundary.

    The successful Graph response only confirms that the revocation operation was accepted and the timestamp reset; in this federated case, it does not demonstrate that the previously issued refresh token has become unusable.


    References

    1. user: revokeSignInSessions
    2. Identity providers for external tenants
    3. Supported features in workforce and external tenants
    4. Graph API RevokeSignInSessions not invalidating refresh tokens
    5. Revoke user access in Microsoft Entra ID
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.