Estimated task time: ~15 minutes
Sign up for a developer account to access additional developer documentation and set the stage for a new integration. There is no need to go through the entire setup process. Your ID.me team will assist with configuring a new SAML integration.
Once an account is created, SAML metadata (along with keys) must be exchanged to ensure proper configuration of the endpoints.
Preserving formatting and whitespace is critical when importing any XML metadata
The metadata document describes the IdP to a SP, including the following elements:
The client app must send the user to the authorization endpoint in order to initiate the SAML process. At the authorization endpoint, the user authenticates on the ID.me server and then grants or denies access to the app. See the examples below:
Parameters
All ID.me SAML messages are digitally signed. This includes all requests, assertions and metadata. The XML signature is contained within the element. The signature serves as proof that only the IdP could have signed the element, and also to guarantee the integrity of the assertion. ID.me signs messages using SHA256, SHA384 and SHA512 algorithms.
ID.me requires all SAML assertions to be encrypted. This helps protect any confidential data in the response. The encrypted assertion is contained within the element. ID.me supports using AES-128, AES-192 and AES-256 as message encryption algorithms.
After decrypting the assertion invoke your Business logic to use the Assertion and guide the user to the next steps per the response received.
Note: If an attribute is missing, the system will return a null value
It is best practice to develop code in a manner that gracefully handles variations in data. For example, a name that contains a hyphen.
Payload specification
International users will have a higher rate of Null values for the address attributes.
Additional attributes may be available. Discuss your use case with your ID.me team.