Connecting Your Systems with Single Sign-On (SSO)

Enhance your users’ experience and strengthen security by setting up Single Sign-On (SSO) through Workvivo to third party applications.

By enabling SSO between Workvivo and your other platforms, you simplify how users access key tools, reducing the need for repeated logins and minimizing friction when switching between systems.

Why use SSO

Implementing SSO offers a range of benefits, but the most notable improvements come in usability and security.

With SSO, users can:

Sign in once and access all connected systems without remembering multiple credentials directly from Workvivo with one secure login
This makes it easier for teams to adopt and consistently use your tools, while also reducing password fatigue and improving data protection across your org.
No repeated logins or forgotten passwords, just simple, secure access to all your apps in one place.
Make Workvivo the go-to entry point for daily work, driving adoption of your connected tools.

Sample Use Cases

Centralized Learning Experience
Connect Workvivo with your Learning Management System via SAML SSO, allowing users to access training directly from their personal device.
Benefit: Easier access drives higher course completion and a smoother learning experience for frontline workers.

Secure Access to IT & Support Tools

Use SSO to link Workvivo with platforms like Jira Service Management or Zendesk so employees can manage support requests with a single login.
Benefit: Improves security and efficiency while ensuring only authorized users access support tools.

Configuring SAML in Workvivo

Navigate to Resources, Apps.
Use the Admin option to add a new App and name it appropriately and add there required URL. You will need to have the IT Administrator Role to be able to view this information.
Note: To add this to an existing App, hover over the existing app, click the three dots, click 'edit', then click 'Add SAML Details'
For Workvivo to act as your Identity Provider (IdP) (meaning users log in through Workvivo to access another application) you will need specific information from that application’s Service Provider (SP)
To add these details click on the option to Add SAML Details - this information is usually found in configuration pages or you can ask your third party service provider if this is supported.

Item	Details	Where to find
SP Entity ID	Unique identifier for the service provider - the app you want to log on to.	Usually found in the apps SSO/ SAML setup page or metadata(xml) file. It often has the format of https://appname.com/saml/metadata
Assertion Consumer Services (ACS) URL	The service providers endpoint where the IdP sends the authentication response.	Found in the same page or in the metadata file. Typically looks like: https://appname.com/saml/acs
Name ID	The user identifier - e.g. Email that is passed to the SP.	Typically Email
Custom Attribute Name	Extra info to pass to the SAML assertion, the value will be email or 3rd party id.	Typically Email
Name ID Format	The structure or value we provide to the SP.	Typically Email
Relay State	Optional url to redirect users to a specific page after login	This is optional.

Enter all required SAML details from the table above into the corresponding fields in Workvivo.
Click Save to generate your Workvivo Identity Provider (IdP) information that you'll need to provide to the Service Provider.
Go to view the SAML metadata
Share the generated Metadata URL and/or XML file with your Service Provider to complete the connection, this will typically be the last URL - SAML metadata endpoint. This can be confirmed with the Service provider.
NOTE: if your instance of Workvivo has a Content Security Policy (CSP), the relative URLs will have to be added to the whitelist for this to work. If you are redirected to a blank page after clicking on the link, this is a sign of the CSP needing updating.

How sign in works on Desktop

On web, SAML works seamlessly by redirecting you from the app’s login page to your identity provider (e.g. Workvivo) for authentication, then automatically returning you to the app once your identity is verified, all handled through the browser.

How this works on mobile

SAML is a web technology and relies on browsers to carry sign-in details. So when you tap Login, we open the app’s sign in page in a web view, complete the SSO in the browser flow, and you are then logged onto the app in web mode. Some apps may prompt you to install or open their native app. What happens here is controlled by each third-party app.

What users can expect on Mobile

Depending on the 3rd party app:
- Majority of apps: Open a web view, log you in, and then continue in the webview.
- Some apps: Open a web view, complete sign in, then ask to download or open their native app to continue.

When to use Workvivo as an IDP

Smaller or mid-sized customers who don’t already use a dedicated identity provider like Okta or Azure AD.
Customers using Workvivo as their main employee hub, where it makes sense for Workvivo to manage authentication for connected tools.
Organizations wanting simple SSO between Workvivo and a few third-party apps (e.g. Jira, Wrike, Moodle) without adding complex infrastructure.
Customers with limited IT resources, where maintaining a full IdP isn’t practical but they still want consistent login and account control.
When specific teams or departments within an organization need secure access to applications without implementing enterprise wide authentication for that app.

When Workvivo as an IdP may not work

Enterprises already using an existing IdP may prefer to make Workvivo a Service Provider under that system - this would have to be identified directly with the customer.
Customers with strict security, MFA, or compliance policies that require enterprise-level identity governance.
Organizations needing advanced provisioning or lifecycle management, which Workvivo IDP doesn’t cover.

Frequently Asked Questions (FAQs)

What is Single Sign-On (SSO)?

Single Sign-On (SSO) is an authentication method that allows users to access multiple applications with one set of login credentials. With Workvivo's SSO integration, users can sign in once and gain access to connected third-party applications without having to log in separately to each one.

What are the main benefits of implementing SSO?

The main benefits include:

Improved user experience with fewer login prompts
Enhanced security through centralized authentication
Reduced password fatigue for employees
Increased adoption of connected tools
Simplified access management for IT teams

Which authentication protocol does Workvivo use for SSO?

Workvivo uses SAML (Security Assertion Markup Language) for SSO connections, which is an industry-standard protocol for exchanging authentication data between systems.

What is the difference between an Identity Provider (IdP) and a Service Provider (SP)?

An Identity Provider (IdP) is the system that verifies user identities and issues authentication assertions. A Service Provider (SP) is the application or system that users want to access. In SSO configurations with Workvivo as the IdP, Workvivo handles the authentication, and the third-party application trusts Workvivo's verification.

Workvivo implements Identity Provider (IdP) initiated SSO, where the authentication flow begins within Workvivo itself rather than at the third-party application. This means users first log into Workvivo, then select and access connected applications without additional login steps. This differs from Service Provider (SP) initiated SSO, where users would start at the third-party application and be redirected to Workvivo for authentication. IdP initiated flows provide a more centralised experience with Workvivo as the primary entry point, reinforcing its position as your digital hub.

Troubleshooting

Users are being redirected to a blank page after clicking the SSO link. What's happening?

This typically indicates a Content Security Policy (CSP) issue. If your instance of Workvivo has a CSP enabled, the relative URLs for the SSO connection need to be added to the whitelist for the integration to work properly. Contact your IT administrator to update the CSP.

Can I test the SSO connection before rolling it out to all users?

Yes, it's recommended to test the SSO connection with a small group of users before full deployment. This allows you to identify and resolve any configuration issues without affecting your entire organization.

What happens if the SSO connection fails?

If an SSO connection fails, users typically receive an error message. Common causes include misconfigured SAML settings, network issues, or expired certificates. Check your configuration settings and ensure that all required information has been correctly entered on both the IdP and SP sides.