When you create an enterprise app in Azure AD and configure SAML-based single sign-on, the portal shows you the Login URL and Logout URL that your application needs to use. For most applications from the catalog (including the Google Cloud one), it looks like this:
If you look closely, you notice that the Login URL and Logout URL are the same – both
https://login.microsoftonline.com/[Tenant-Id]/saml2. This is consistent with the federation metadata:
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor use="signing"> .. </KeyDescriptor> <SingleLogoutService Location="https://login.microsoftonline.com/[Tenant-Id]/saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/> <SingleSignOnService Location="https://login.microsoftonline.com/[Tenant-Id]/saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/> <SingleSignOnService Location="https://login.microsoftonline.com/[Tenant-Id]/saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/> </IDPSSODescriptor>
But it wasn’t always like this – up until a few months ago, the Logout URL used to
https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 for most types of applications.
So what’s the difference between these two endpoints?
WS-Federation and SAML 2.0 endpoints
As their URLs suggest, the
https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 endpoint has
its roots in WS-Federation while
https://login.microsoftonline.com/[Tenant-Id]/saml2 is related to SAML 2.0.
But that’s not the only difference – the two endpoints also behave quite differently: while the
endpoint works without passing any parameters, the
saml2 endpoint expects you to
pass a SAML LogoutRequest..
The semantics are different enough that swapping one for the other
can cause trouble for some applications. One example where using the wrong URL breaks things is Cloud Identity/Google Workspace.
Google Sign-In supports SAML 2.0-based single sign-on,
but doesn’t implement the SAML 2.0 single sign-out protocol.
If you configure a Sign-out URL in the Admin Console, Google Sign-In will use that URL as-is and won’t pass any extra
parameters. And that’s no problem if you use the
wsfederation endpoint, but if you configure it to use the
endpoint, AzureAD will show you this error message when you try to log out:
To fix this error, make sure you’re configuring your Cloud Identity or Workspace account to use the
wsfederation endpoint instead of the
I updated the Google Cloud docs accordingly.
OAuth 2.0 endpoints
These days, OAuth 2.0 and OpenID Connect are obviously more popular than SAML and WS-Federation, so Azure AD also provides some OAuth 2.0-themed endpoints. Can we use those too?
The endpoints are:
The first one (
login.windows.net) is deprecated
and should not be used. The other two endpoints largely seem to do the same, but there is a UX difference.
If you have multiple sign-in sessions and hit one of the endpoints, they’ll both ask you which account to sign out from:
But if you’re only signed in once, the behavior is different: while the (older)
oauth2/logout endpoint immediately
signs you out, the
oauth2/v2.0/logout continues to show a prompt:
There are also tenant-specific variants for each of these endpoints (like
but in my tests, they seem to behave the same as their “common” counterparts.
For the purpose of an application like Cloud Identity or Workspace that doesn’t support SAML Logout, the OAuth
endpoints seem to work just as well as the