Skip to main content
All CollectionsAPIs and IntegrationsNovi SSO
Single Sign-On For Novi Data Handshake Sites
Single Sign-On For Novi Data Handshake Sites

Setup SSO for multiple related Novi instances

Jaime Morgan, CAE avatar
Written by Jaime Morgan, CAE
Updated over a week ago

If your organization uses Novi's Data Handshake to connect multiple sites via API, you have the option to set up singular logins for members between these sites (known in the tech world as Single Sign-On, or SSO).

This allows your members to have a seamless experience moving from one website to another, without having to maintain multiple logins.

For example, an association that has a Novi site for their foundation may have folks who log in to both, or a state association whose affiliates also have Novi sites.

You'll want to work with your affiliate staff to get this process up and running. We are happy to assist with any questions you may have, but cannot set this up for you, since it involves sharing sensitive information.

Table of Contents:

Note: At this time, using SSO to log into a Novi site is only available for Novi sites utilizing the data handshake with other Novi sites. See: How to set up a Novi API feed to receive member data from an affiliate association

For third parties wanting to use Novi logins as their third-party login, check out third-party SSO information here.

The Basics - Set Up

SSO settings will need to be configured on both the Novi site where logins are coming from and the Novi site utilizing the logins.

Before we begin, there are two key phrases you'll want to be familiar with:

  • SSO Client - This is set up by the website that is providing the logins.

  • SSO Provider - This is set up by the website that will be utilizing those logins.

For example, Association A is where members currently login. Association B wants to use Association A's logins. Association A will set up an SSO Client. Association B will set up an SSO Provider.

Setting up an SSO Client

First, navigate to the gear icon in the top right of the backend and select SSO Clients.

Then, click the blue Add SSO Client button found in the top right corner.

  • Name: Enter the name of the website that will be utilizing the SSO. In our earlier example, you'd enter Association B.

  • Permitted Groups: This is not required, but can be used to limit the SSO to certain members. If nothing is entered here, it will be available for use by anyone in your database.

Once this SSO Client has been saved, a Client ID and Secret Key will appear. These will need to be given to the receiving association. (Note: Treat these as securely as you would a password. These are the "keys" to allowing the site to use your member's logins.)

Setting up an SSO Provider

Once the sending association has set up their SSO Client, the receiving association can set up the SSO Provider.

Navigate to the gear icon in the top right of the backend and select SSO Providers.

Then, click the blue Add SSO Provider button found in the top right corner.

  • Client Id: Enter the Client ID provided from the SSO Client.

  • Client Secret: Enter the Secret Key provided by the SSO Client.

  • Login Button Text: Label what the button will say to users who will use this SSO. You may choose something like "Login With Association A"

  • Provider Name: Enter the name of the sending association.

Once these are both setup, you're ready to get started with SSO from two connected Novi sites! Note that you can use more than one SSO Provider on a site.

What does the user see?


On the login screen, as well as on event and product checkout for users not logged in, users will see one login button for each active provider set up. They'll be able to choose whether they'd like to log in with their email address or login using a provider.

In the example below, there are two providers set up in the client site for the user to select from:

If the user is already logged in to a provider...

...Novi will automatically log them in and they won’t need to enter their credentials again.

If they're not already logged into the provider...

...they will be redirected to the provider site to log in with their provider credentials.

  • If they have an existing record in both sites (determined by the Data Handshake), Novi will log them in.

  • If the customer in the receiving site has a record, but no user account, Novi will create a login in the client site with the email used in the provider.

  • If their account exists on the provider, but there is no corresponding customer record in the client, the user will see an Access Denied message and will need to use the typical login process.

Note: If they try to log in with the provider, but the email is already being used in the client site on a different record, the user will see an error.

Settings For Sites with One Provider

For an example such as an Association and a Foundation, where you only have one provider (the Foundation), you may only want your users to log in to the main site but not login to the secondary instance at all.

If your association has this scenario, we have two settings that can be turned on to provide a better user experience for your members. Note: these are both Novi Admin settings, so reach out to us via Intercom if you'd like us to turn these on.

1) Disable member signup and account creation. This will remove the Join link from the provider site. Logged out users will not see the "Join" link on the client site, and users will not be able to create accounts or signup on the client (Foundation) site.

2) Set a Primary Login Provider in the Novi Admin settings. When users click the Login link they won't see a login screen - instead, they'll automatically be logged in with the provider. (In the Association/Foundation example, the user will be automatically logged in with the Association site.)

In cases where you may need to access it, the /login page is still accessible by manually typing in the URL.

Member Compass

On the Login & Password tab of the Member Compass, members will see any external SSO logins that they use.

As long as the setting for Primary Login Provider has not been turned on, the user will be able to update their login email and password for the receiving site they are in.

What does an Association Admin see?

If someone logs in via SSO they are considered to “have an account” by the admin system.

You can see which provider they are connected to in the Settings tab of their record.

What happens if records are merged?

During the merge, the admin will see the account email, last login date, and a message “Logged in with {external login provider name}”

Did this answer your question?