---
schema_version: "1"
id: a80d92cc30a622c95cd66434f985973ea7bbad46113775e218ed80b27a50df1d
title: SAML Single Sign-On Flows
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/identity_provider_about.md
canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.identity_provider_about.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 55deb78beba1d797d4a28055d2f0e6a0285ed16f056b839c42cc1a2294fd6ad2
description: When you set up single sign-on (SSO) with Security Assertion Markup Language (SAML), you can initiate login from the service provider or the identity provider. Service provider-initiated login and identity provider-initiated login use different flows, but both result in the user being logged in to the service provider.
products:
  - Security
release: "264"
---
# SAML Single Sign-On Flows

When you set up single sign-on (SSO) with Security Assertion Markup Language (SAML), you can initiate login from the service provider or the identity provider. Service provider-initiated login and identity provider-initiated login use different flows, but both result in the user being logged in to the service provider.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: both Salesforce Classic and Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>Developer</strong>, <strong>Enterprise</strong>, <strong>Performance</strong>, <strong>Unlimited</strong>, and <strong>Database.com</strong> Editions</td></tr></tbody></table>

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small permission">
      <colgroup>
        <col style="width:50%">
        <col style="width:50%">
      </colgroup>
      <thead class="slds-text-title_caps ">
        <tr class="">
          <th scope="colgroup" class="slds-cell-wrap" colspan="2" style="text-align:center;vertical-align:top;" id="d90183e71">User Permissions
            Needed</th>
        </tr>
      </thead>
      <tbody>
        <tr class="">
          <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d90183e71 ">Define and modify identity providers and service providers:</td>

          <td class="slds-cell-wrap" style="vertical-align:top;" headers="d90183e71 ">Customize Application</td>

        </tr>
      </tbody>
    </table>

## SAML Security

To understand how these SSO flows work, it’s important to understand how providers use SAML to exchange security information.

![Tip](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_tip.png)

Tip To brush up on your SSO vocabulary, see [Single Sign-On Terminology](https://help.salesforce.com/s/articleView?id=xcloud.sso_terminology.htm&release=264.0.0&type=5 "Do you want to configure single sign-on (SSO) for your org? Get acquainted with some key terminology first.") in Salesforce Help.

For both SAML SSO flow variations, the identity provider authenticates the user—confirms that the user is who they say they are. After the identity provider authenticates the user, it uses a SAML response to tell the service provider who the user is and what they’re allowed to do. It stores information about the user’s identity in a specific part of the response called the SAML assertion.

To signal that the service provider can trust the SAML response, the identity provider signs the response body, the assertion, or both. Whether the response body or the assertion is signed depends on the identity provider.

- If you use Salesforce as an identity provider, Salesforce signs the SAML response body and the assertion.
- If you use a third-party identity provider, check with your identity provider to see how they sign SAML responses.

When the service provider receives the SAML response, it validates this signature. How the signature is validated depends on the service provider.

- If you use Salesforce as an identity provider, check with your service provider to see how they validate signatures. Because Salesforce signs the response body and the assertion, it’s compatible with a variety of service providers.
- If you use Salesforce as a service provider, Salesforce can validate signatures in either the response body or the assertion. Salesforce first looks for a signature in the response body. If the response signature is missing or invalid, Salesforce then tries to validate the signature in the SAML assertion. Even if an attacker captures the SAML response from the user’s browser and tampers with the response body, the SSO login isn’t at risk as long as the assertion signature is intact.
    
    If your identity provider supports encrypted SAML assertions for extra security, you can also [Set Up an External Identity Provider to Encrypt SAML Assertions](https://help.salesforce.com/s/articleView?id=xcloud.sso_saml_sp_encrypt_assertions.htm&release=264.0.0&type=5 "When you configure Salesforce as the service provider in a SAML single sign-on (SSO) configuration, you can pick a saved certificate to decrypt inbound assertions from external identity providers. These instructions show you how to edit your SSO configuration so that your external identity provider can encrypt SAML assertions.").

## Service Provider-Initiated SAML Flow

In a service-provider-initiated flow, the service provider begins the login process with a SAML request to the identity provider. Here’s how this flow works.

1. The user requests a secure session to access a protected resource in the service provider. For example, the user clicks a link to fill out a form in the service provider. But the form is a protected resource, meaning the user can only access it after logging in.
2. The service provider initiates login by sending a SAML request to the identity provider, asking it to authenticate the user.
3. The identity provider sends the user to a login page.
4. The user enters their identity provider login credentials and the identity provider authenticates the user.
5. The identity provider now knows who the user is, so it sends a cryptographically signed SAML response to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
6. The service provider validates the signature in the SAML response and identifies the user.
7. The user is now logged in to the service provider and can access the protected resource.

## Identity Provider-Initiated SAML Flow

In an identity provider-initiated login flow, a SAML request is unnecessary because the identity provider starts the flow with a SAML response. An identity provider-initiated flow is a shortened version of a service provider-initiated flow. Here’s how this flow works.

1. The user logs in to the identity provider.
2. The user clicks a button or link to access the service provider. For example, the user clicks an app on the App Launcher page in a Salesforce org.
3. The identity provider initiates login by sending a cryptographically signed [SAML response](https://help.salesforce.com/s/articleView?id=xcloud.identity_provider_about.htm&release=264.0.0&type=5) to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
4. The service provider validates the signature in the SAML response and identifies the user.
5. The user is now logged in to the service provider.

## Example SAML Request and Response

Here’s an example of a SAML request. In a service provider-initiated flow, the service provider sends a SAML request to start the login process.

```markup
<samlp:AuthnRequest ID="bndkmeemcaamihajeloilkagfdliilbhjjnmlmfo" Version="2.0" 
   IssueInstant="2010-05-24T22:57:19Z" 
   ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
   ProviderName="google.com" IsPassive="false" 
   AssertionConsumerServiceURL="https://www.google.com/a/resp.info/acs">
   <saml:Issuer>google.com</saml:Issuer>
   <samlp:NameIDPolicy AllowCreate="true" 
   Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
</samlp:AuthnRequest>
```

Here’s an example of a SAML response. In a service provider-initiated flow, the identity provider sends a SAML response after the service provider sends a SAML request. In an identity provider-initiated flow, the identity provider starts the flow by sending a SAML response.

In this example, the response body is signed, but the assertion itself isn’t.

```markup
<samlp:Response Destination="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"
  ID="_0f551f9288c8b76f21c3d4d15c9cd1df1290476801091"
  InResponseTo="_2INwHuINDJTvjo8ohcM.Fpw_uLukYi0WArVx2IJD569kZYL
    osBwuiaSbzzxOPQjDtfw52tJB10VfgPW2p5g7Nlv5k1QDzR0EJYGgn0d0z8
    CIiUOY31YBdk7gwEkTygiK_lb46IO1fzBFoaRTzwvf1JN4qnkGttw3J6L4b
    opRI8hSQmCumM_Cvn3DHZVN.KtrzzOAflcMFSCY.bj1wvruSGQCooTRSSQ"
  IssueInstant="2010-11-23T01:46:41.091Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>https://myidp.my.salesforce.com</saml:Issuer>
−
<ds:Signature>
−
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
−
<ds:Reference URI="#_0f551f9288c8b76f21c3d4d15c9cd1df1290476801091">
−
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
−
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="ds saml samlp xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>4NVTbQ2WavD+ZBiyQ7ufc8EhtZw=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
−
<ds:SignatureValue>

ExampleSamlSignature</ds:SignatureValue>
−
<ds:KeyInfo>
−
<ds:X509Data>
−
<ds:X509Certificate>ExampleX509 Certificate</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
−
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
−
<saml:Assertion ID="_e700bf9b25a5aebdb9495fe40332ef081290476801092" IssueInstant="2010-11-23T01:46:41.092Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://exampleidp.com</saml:Issuer>
−
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">exampleuser@salesforce.com</saml:NameID>
−
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2010-11-23T01:51:41.093Z" Recipient="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"/>
</saml:SubjectConfirmation>
</saml:Subject>
−
<saml:Conditions NotBefore="2010-11-23T01:46:41.093Z" NotOnOrAfter="2010-11-23T01:51:41.093Z">
−
<saml:AudienceRestriction>
<saml:Audience>https://exampleserviceprovider.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
−
<saml:AuthnStatement AuthnInstant="2010-11-23T01:46:41.092Z">
−
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
−
<saml:AttributeStatement>
−
<saml:Attribute Name="userId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">005D0000001Ayzh</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">admin@identity.org</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">exampleuser@salesforce.com</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="is_portal_user" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">false</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
```

#### See Also

- [Enable Salesforce as a SAML Identity Provider](https://help.salesforce.com/s/articleView?id=xcloud.identity_provider_enable.htm&release=264.0.0&type=5 "You can configure Salesforce as a single sign-on (SSO) SAML identity provider to external service providers. When your org acts as a SAML identity provider, users can access multiple apps with a single login. To get started with this configuration, enable Salesforce as an identity provider and share configuration information with your service provider.")
- [Complete Prerequisites for SAML Service Provider Integration](https://help.salesforce.com/s/articleView?id=xcloud.service_provider_prerequisites.htm&release=264.0.0&type=5 "Before integrating a service provider with Salesforce, enable your org as an identity provider and exchange SAML single sign-on (SSO) information with your service provider.")
- [Integrate Service Providers as SAML-Enabled Apps](https://help.salesforce.com/s/articleView?id=xcloud.service_provider_define.htm&release=264.0.0&type=5 "To configure SAML single sign-on (SSO) with Salesforce as an identity provider, integrate a service provider by using the external client apps framework or the connected apps framework. With this SSO configuration, users log in to the service provider by using the same credentials that they use to log in to your Salesforce org or Experience Cloud site. To change your service provider details, edit your app. Control which users can access your app by managing profiles and permission sets.")
- [Map Salesforce Users to the SAML Service Provider](https://help.salesforce.com/s/articleView?id=xcloud.service_provider_map_users.htm&release=264.0.0&type=5 "To ensure that your SAML service provider can recognize Salesforce users when they log in with single sign-on (SSO), update user information in Salesforce. Provide user identifiers that the service provider recognizes.")