Articles in this section

How to Add OAuth Details
  • Updated

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.

 

Configuration Instructions

 

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.

 

Setup

To begin setup:

  1. Go to Settings
  2. Click on Registration.
  3. Scroll down to the bottom
  4. Select OAuth from the Sign-On Provider dropdown menu.
  5. Complete the available OAuth Fields


OAuth Fields to Complete

Fields

Description
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.
Friendly Name Provide a title for this OAuth integration. This name will be shown to your users.
OAuth version 1.0 or 2.0, depending on your version. Ensure that you know which version you are using!
Authorize URL 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:
      • ‘id’,
      • ‘user_id’,
      • ‘uid’,
      • ‘screen_name’,
      • ‘username’
    • 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.

 

Additional Information

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.

Related articles