Print this page

OAuth with SAML 2.0 authentication, relayState may be longer than 80 char

Knowledge Article Number 000214100
OAuth with SAML 2.0 authentication, relayState may be longer than 80 char. 
SAML 2.0 is standard based, 
"RelayState data MAY be included with a SAML protocol message transmitted with this binding. The value
MUST NOT exceed 80 bytes in length and SHOULD be integrity protected by the entity creating the
However Salesforce does not enforce this requirement for a number of reasons. Salesforce, acting as a Service Provider, may send a relayState with the SAMLRequest that is greater than 80 bytes.
For example:
Authenticating a user of a OAuth (Connected App) enabled client using the User-Agent flow.
1) https://<MyDomain><your_client_id>&redirect_uri=<your_redirect_uri>&display=touch&state=<some_state>
The response will redirect the user to the organisations configured authentication service to authenticate the user whom can then authorise the Client Application, i.e. If the organisation has login Page and SAML enabled they will land on a URL like below:

2) If the user selects to be authenticated by their SAML Identity Provider Salesforce will send a SAMLRequest like:
RelayState: /setup/secur/RemoteAccessAuthorizationPage.apexp?source=l86Hcy6qEKtWNqzXVErZDlmcRQs0D_HBE55MLVuP3x8t5wXkyHYyrVx2Xb5JoWzyVOJrnTqMM...
SAMLRequest: PD94bWwgdmVyc2lv................==
(SAMLRequest truncated for brevity)
3) The RelayState is longer than 80 bytes, this is required in order to continue the initiated OAuth flow and allow the user to authorise the Client App. The Identity Provider should echo this relayState back to Salesforce in the SAMLResponse and ensure not to enforce the limit of 80 bytes on any custom IDP implementation.
Salesforce doesn't enforce the relayState limit based on current industry usage of SAML 2.0 and our experience with how customers want to use SAML.

promote demote