Azure AD defaults to SAML Logout, but not all apps support that

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 read 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 read 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 wsfederation 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 sam2 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 saml2 endpoint. 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:

• https://login.windows.net/common/oauth2/logout
• https://login.microsoftonline.com/common/oauth2/logout
• https://login.microsoftonline.com/common/oauth2/v2.0/logout

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 https://login.microsoftonline.com/{Tenant-Id}/oauth2/v2.0/logout, 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 wsfederation endpoint.

• Share this article: