Single sign-on (SSO) implementation consists of several steps. The implementation can be done concurrently with Widen Collective site implementation.

Below are steps that will be taken to implement an SSO.

Step 1Refer to our SSO FAQs and SAML SSO configuration documentation. This documentation is technical in nature and should be shared with your developer(s) or IT personnel.


Step 2. Decide on the type of SSO that will work best for your site and identify the developer(s) or IT personnel who will implement the SSO on your team.

Step 3. If the Google OpenID or SAML SSO method is selected, you'll enable the appropriate feature on the Features page, then the selected developer or IT personnel logs in to the Collective and completes the SSO settings in the Admin app. If a custom SSO method is chosen, developers on your team and our development team communicate back and forth until the SSO is implemented. Additional calls may be set up to coordinate the implementation.

Step 4. The SSO is in place and tested. You'll train users on how to leverage the SSO.


In addition to technical details of an SSO, consider the following questions surrounding the user experience.

  • User authentication. Will all roles in the Collective authenticate via the SSO? If no, which roles will use it?
  • Authentication criteria. Will users authenticate by navigating to the Collective login page?
    • If yes, should users be automatically authenticated or should they initiate the process by clicking Service Provider Authenticated when logging in?
      • If yes, provide the text for the label and button as shown in the example below.
  • Login page. Review the layout for the login box on your login page (shown below).
    • The SSO login will be placed at the top of the login box.
    • Button labels within the login box can be changed, but the position of the buttons cannot.

SSO login positioned at the top

  • Initial user role assignment. Should users be assigned into specific roles in the Collective upon authentication?
    • Should those users be automatically assigned to the role, do you want to approve users, or should they be placed in a general role where you will manually assign them to the desired role?
    • Does your IT team store information for users that can be passed to your customer success manager to use for role determination in the Collective (e.g., marketing department users map to the marketing role)?
  • Ongoing user role assignmentWill users always remain in the role assigned to them from the first time they log in through the SSO?
    • If yes, we can create a safe list that never allows change. Users on this list will be verified each time they log in, and roles can be reset to the original, if necessary.
    • If no, we will not verify users against a list or change a user’s role and you will be able to manually change the role at any time.