Managing external identities to enable secure access for partners, customers, and other non-employees
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:
- External tenant ID and application/client ID.
- Affected user’s object ID, without posting it publicly.
- UTC timestamps for:
- Google authentication,
- refresh-token issuance,
-
revokeSignInSessions, - successful post-revocation redemptions.
- Graph request ID/client-request ID and the
200response. -
signInSessionsValidFromDateTimebefore and after revocation. - Token endpoint correlation IDs from successful post-revocation redemption.
- A side-by-side trace using the same app and scopes:
- local account: redemption fails after revocation;
- Google account: redemption continues.
- Confirmation that both refresh tokens were issued by the External ID token endpoint—not directly by Google.
- 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:
- 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^
- 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^
- Continue rejecting the user at the API authorization layer until the account is intentionally restored. Existing access tokens can otherwise remain usable until expiry.
- 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