OpenID Connect SSO
Updated
What is SSO?
Single Sign-On capability provides the end users an easier way to login compared to the email/password login method. Users can log in to the Sprinklr platform via their company’s enterprise login only, with just a click.
For example, for a user, who is logged into their brand’s employee portal, once the SSO setup is done for the brand then this user will be able to directly log in to Sprinklr. Login will happen via the brand's identity provider directly and no separate username and password needs to be created for logging in to Sprinklr
Benefits of Using SSO login:
Adds convenience for the customer: Fewer logins that they need to create and remember
Increases security:
Any individual leaving the company will lose Sprinklr access as well.
This would result in any security measures built into the customer’s login such as two-factor authentication, being on an internal network, etc., applied to Sprinklr login as well
Here is a sample screenshot of what the client will see when SSO is enabled, which will vary for each implementation:
How does SSO work?
There are two parties involved in a SSO login:
IDP: Identity Provider where the user’s identity is stored. Eg: Microsoft Azure
An IDP is a service that maintains and manages digital identities to verify user credentials throughout applications, networks, and web services. Its primary role is to safeguard the integrity of user credentials and federate user identity where SSO logins are desired.SP/Client: Service Provider (The application users want to access). Eg: Sprinklr platform
Service providers are a resource that users authenticate into using SSO, usually a private website or application. They receive, accept, or deny assertions (in case of SAML 2.0) & ID tokens (in case of OIDC) from IDPs for each client profile prior to granting users access.
The IDP has the information of the various SPs/Clients and vice versa. The architecture is a handshake protocol. Sprinklr validates the information and only then allows the user to be logged in.
What information is required to for the Customer to register Sprinklr in their IDP for OpenID Connect SSO?
Client (Sprinklr in this case) details including:
Redirect URL/ Reply URL/ ACS URL : https://{prefix-of-domain}.sprinklr.com/ui/openid/login?provider=OPEN_ID_CONNECT
The naming convention is https://x.sprinklr.com /ui/openid/login?provider=OPEN_ID_CONNECT for the production and https://staging-x.sprinklr.com /ui/openid/login?provider=OPEN_ID_CONNECT for the staging, where x is the name of the Client. The staging URL should be the custom domain that we can fetch from the backend for any partner.
How to register Sprinklr as a Client on the IDP for OpenID Connect SSO?
Navigate to the section where you can add new applications or clients on the IDP
Enter Basic Client Details
Client Name: Enter a descriptive name for the client application, such as "Sprinklr SSO."
Client ID: The IdP may automatically generate a unique identifier for the client. Ensure to note this down as it will be needed later.
Redirect URL: Specify the URL where the IdP should send the authorization code or tokens after authentication. This is provided by Sprinklr.
Configure Authentication and Authorization Settings
Response Type: Typically, this will be set to code for authorization code flow.
Grant Type: Select authorization_code. If applicable, you may also configure other grant types like refresh_token.
Scopes: Define the OpenID Connect scopes that the client application will request. Common scopes include openid, profile, and email.
Configure Security Settings
Client Secret: Generate a client secret. This secret will be used by Sprinklr to authenticate itself to the IdP when exchanging the authorization code for tokens.
Token Endpoint Authentication Method: Choose the method Sprinklr will use to authenticate at the token endpoint (e.g., client_secret_basic).
Define Additional Endpoints (if applicable)
Post-Logout Redirect URI: Specify a URL where users should be redirected after they log out.
JWKs URI: If the IdP supports JSON Web Key Sets, specify the URL where Sprinklr can retrieve the IdP’s public keys for validating tokens.
Save the Configuration
After entering all the required details, save the configuration. The IdP will now recognize Sprinklr as an authorized client application.
Provide Configuration Details to Sprinklr
Client ID/Client Key: The unique identifier for Sprinklr.
Client Secret: The secret key generated during client registration.
Authorization Endpoint: The URL to initiate the authorization request.
Token Endpoint: The URL to exchange the authorization code for tokens.
Userinfo Endpoint: The URL to obtain user profile information.
Scopes: The scopes that Sprinklr is authorized to request.
How to configure an OpenID SSO on Sprinklr?
Ensure SSO configurations are enabled on Sprinklr before proceeding with below steps, raise a support ticket for the same if they are not enabled
Navigate to All Settings -> Manage Customer -> Single Sign-Ons -> Click Add Single Sign On -> Click ’Open ID’ under Select the Type of Single Sign On
Fill all the mandatory fields with information received from the IDP and click Save.
The following table showcases the difference between the steps involved in setting up a SAML 2.0 SSO and an OpenID Connect SSO-
Steps | SAML 2.0 SSO | OpenID Connect SSO |
Information Needed to be Shared by the Client to the IdP | Parameters | Parameters |
Details | Public Key Certificate of Sprinklr for SAML, Service Provider Login URL/ Sign On URL, Entity ID, Redirect URL/ Reply URL/ ACS URL -Sprinklr supports HTTP POST and HTTP Redirect both for AuthNRequest. -Sprinklr supports HTTP POST, REDIRECT and ARTIFACT for Assertion. | Redirect URL/Reply URL/ACS URL: URL for authorization code/tokens (Mandatory), Scope: OpenID scopes (e.g., openid) (Mandatory), Post Logout Redirect URL: URL for post-logout redirection (Optional) |
Information Needed to be Shared by the IdP to the Client (Sprinklr) for Configuration | Parameters | Parameters |
Details | Entity ID, Issue Name, IDP Login URL, IDP Logout URL (Optional), SAML User ID Type, SAML User ID Location, Request Binding Type, IDP Certificate Details | Client ID, Client Secret, Authorization Endpoint, Token Endpoint, User Info Endpoint, Scopes (Optional) |
Configuration Steps on the IdP Side | Steps | Steps |
Access IdP Admin Console | Access IdP admin console to create a new | SP entry Access IdP admin console to create a new client entry |
Register New Client | Register new SP with provided details | Register new client application with provided details |
Input Shared Information | Input entityID, AssertionConsumerServiceURL, NameIDFormat, Public Key Certificate of Sprinklr (if applicable) | Input client_id, redirect_url, response_type, scope, post_logout_redirect_uri (if applicable) |
Save Configuration | Save the SP configuration | Save the client application configuration |
Configuration Steps on the Client Side (Sprinklr) | Steps | Steps |
Configuration | Enter the details shared by the IDP- Entity ID, Issue Name, IDP Login URL, IDP Logout URL (Optional), SAML User ID Type, SAML User ID Location, Request Binding Type, IDP Certificate Details and Save the configuration | Enter the details shared by the IDP- Client ID, Client Secret, Authorization Endpoint, Token Endpoint, User Info Endpoint, Scopes (Optional) and Save the configuration |
Test SSO Setup | Perform test SSO login and logout | Perform test SSO login and token exchange |
Ensure successful SSO and attribute transfer | Ensure successful token validation and user info retrieval |
Although the login flow of OpenID Connect SSO is like that of SAML SSO, this table showcases the differences between both:
SAML SSO Flow | OpenID Connect SSO Flow |
1. User Accesses Service Provider (SP): | 1. User Accesses Client Application: |
User tries to access a resource at the SP. | User tries to access a resource at the client application. |
2. SP Redirects to Identity Provider (IdP): | 2. Client Redirects to Identity Provider (IdP): |
Parameters: | Parameters: |
SAMLRequest, AssertionConsumerServiceURL (ACS URL)/Re-direct URL/Reply URL | - client_id, redirect_uri, response_type (code), scope (openid, profile, email), state, nonce |
3. User Authenticates with IdP: | 3. User Authenticates with IdP: |
User provides credentials to IdP. | User provides credentials to IdP. |
4. IdP Generates SAML Response: | 4. IdP Generates ID Token and Authorization Code: |
Parameters: | Parameters: |
SAMLResponse, RelayState | code, id_token, state |
5. IdP Redirects to SP with SAML Response: | 5. IdP Redirects to Client with Authorization Code: |
Parameters: | Parameters: |
- SAMLResponse, RelayState | - code, state |
6. SP Validates SAML Response: | 6. Client Exchanges Code for Tokens: |
Parameters (in the exchange request): | Parameters (in the exchange request): |
- SAMLResponse, RelayState | - client_id, client_secret, code, redirect_uri, grant_type (authorization_code) |
7. User Granted Access to SP: | 7. Client Validates Tokens: |
Upon successful validation, user is granted access to the SP. | Client validates the ID token using the IdP’s public key. |
Parameters (in the ID token): | Parameters (in the ID token): |
- Issuer (iss), Subject (sub), Audience (aud), Expiration (exp), Signature | - Issuer (iss), Subject (sub), Audience (aud), Expiration (exp), Signature |
8. SP Initiates User Session: | 8. User Granted Access to Client Application: |
SP establishes a session for the user. | Upon successful validation, user is granted access to the client application. |