Skip to main content


Identity Cloud supports SAML 2.0, and serves as identity provider.

Applications supporting SAML 2.0 serve as service providers, and can use Identity Cloud to authenticate users using the Web Browser SSO Profile.

Single sign-on service

Service providers can trigger a login by redirecting the user agent (browser) to the Identity Cloud single sign-on service.

The single sign-on (SSO) service also supports HTTP-POST binding. The SSO service URL is the following:


When using HTTP redirect binding, the SAML authentication request is to be sent using query parameters. The following example illustrates the basic structure:


The order of query parameters does not matter.

The SAMLRequest query parameter is required, and has to contain a deflated, base64-encoded, and URL-encoded AuthnRequest message.

For Identity Cloud, it is required that the message contains an Issuer element, and the AssertionConsumerService attribute. When validating incoming requests, both values are compared to what you entered when adding the application.

The RelayState parameter is optional. Identity Cloud returns the provided value after successful authentication.

Known issues and limitations

During login, an initial session is created in Identity Cloud. The session has a short idle timeout.

If the session expires during login, the next request restarts the login flow from the beginning.

In case of HTTP-POST binding, the SAML authentication request is lost, and thus the login fails.

Metadata service

SAML metadata is an XML document that contains information about SAML-enabled parties.

Identity Cloud offers a metadata service that can provide such a document to describe the Identity Cloud as identity provider.

The metadata service URL is the following:


The following XML extract illustrates a typical response.


To improve readability, we removed elements that are long or too specific, and added line breaks and indention.

<?xml version="1.0" encoding="UTF-8"?>
<md:EntitiesDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="__e18a16e3d97b260042dbf7eb4ac37286d9ffcf48">
<ds:Signature xmlns:ds="">
<ds:CanonicalizationMethod Algorithm=""/>
<ds:SignatureMethod Algorithm=""/>
<ds:Reference URI="#__e18a16e3d97b260042dbf7eb4ac37286d9ffcf48">
<ds:Transform Algorithm=""/>
<ds:Transform Algorithm=""/>
<ds:DigestMethod Algorithm=""/>
<md:EntityDescriptor ID="__d0c493ef2ea31c0bc4519070cc731b32d16a02ad" entityID="">
<md:IDPSSODescriptor ID="__5315c454545db30fd0b313eb9c091081caa6073a" WantAuthnRequestsSigned="false" cacheDuration="P0Y0M0DT1H0M0.000S" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" validUntil="2022-03-01T10:06:24.584Z">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="">
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://${instanceId}"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://${instanceId}"/>
Known issues and limitations