In this Article...
How it Works
SSO works by creating an integration between a client's IdP and Apply via the OAUTH protocol. The handshake passes along key user information, including the UID. The key role of the IdP is to verify, for Apply, that the users information is known, and correct account details have been provided.
Due to the technical nature of implementing an SSO Integration, and the vast number of authentication services that clients can have, Apply requires there to be a technical expert on the client’s end who has a background or strong knowledge of SSO.
Things to note
- We operate in a multi-tenant environment and do not allow for any custom OAuth development, our OAuth integration is already coded and complete
- Ensure your IT person is familiar with your IdP server environment, and that none of their colleagues are making unknown changes to it while you are setting up and testing your SSO configuration
- If you would like us to be able to troubleshoot your OAuth config, please provide us with credentials for a test user account (username & password)
- Seeing an error message of `redirect_uri_mismatch` means that you have not permitted your OAuth configuration (on the IdP side) to communicate with the following URI: https://<yoursite>.fluidreview.com/sso/oauth/
- Seeing an error message of `invalid_grant` this means that the authorization code or refresh token that you are using is expired. There can be a number of reasons why this may be happening - please review your configuration.
- If you are able to successfully sign on to SurveyMonkey Apply but your email address is not appearing correctly, make sure that you have not already created an account using the same email that is being sent via the SSO. If you have, then there is a conflict. Please notify your Specialist or Support if this occurs in order to disassociate the accounts.
To begin setup:
- Go to Settings
- Click on Registration.
- Scroll down to the bottom
- Select OAuth from the Sign-On Provider dropdown menu.
- Complete the available OAuth Fields
OAuth Fields to Complete
|Consumer Key (Client ID)
|API Key associated with the software you are authenticating with (identification for the client). It must be unique across all clients that the authorization server handles.
|Provide a title for this OAuth integration. This name will be shown to your users.
|1.0 or 2.0, depending on your version. Ensure that you know which version you are using!
|Taken from your resource server after the user has been authorized. This can be considered a log-in point to the software identifying server. https://example.com/oauth/authorize
|Access Token URL
An object that contains the security identity. An access token is the string used when making authenticated requests to the API. https://authorization-server.com/token
|Access Token URL (Method)
The HTTP method to use when communicating with the above Access Token URL
If Version 1.0 Authenticate URL: The endpoint for the authorization server, which retrieves the authorization code.
If Version 2.0 Profile URL: Leads to the profile that you are providing SM Apply Access to. You will have control of what the system has access to.
- This should be a URL that returns a JSON object, containing all of the properties you are passing to Apply, such as Entity ID, First Name, Last Name, Email and any custom fields.
- Examples of an Entity ID include:
- SurveyMonkey Apply requires Entity ID, First Name, Last Name and Email Address for all users in order to successfully create the user account. Any additional properties you wish to pass are optional and dependent on your specific requirements.
In addition to testing that the sign-in components are working correctly, full tests through complete applications should be run using users coming in through the SSO, testing all potential submissions, links, tasks and resources ensuring everything is working as desired.
If issues are discovered during initial testing of the SSO there are some key pieces of information required to help resolve the issue: the type of user being tested, the login credentials for that user, and the error message (if one is displayed). Screenshots of error messages are always encouraged.