How to Set Up SSO for Your UniLink Team (Single Sign-On With Google or SAML)
How to Set Up SSO for Your UniLink Team (Single Sign-On With Google or SAML)
Let your team log in to UniLink with their existing company credentials via Google Workspace or SAML 2.0 — no separate passwords required.
- SSO is available on the Business and Agency plans — configure it at Dashboard → Settings → Security → SSO.
- Supported providers: Google Workspace (OAuth) and any SAML 2.0 provider (Okta, Azure AD, OneLogin).
- You can enforce SSO so all team members must log in via the configured provider — no UniLink passwords allowed.
When your team already uses Google Workspace, Okta, or Azure Active Directory for everything else, adding another set of credentials for UniLink creates friction and security gaps. Single Sign-On eliminates both problems: team members log in to UniLink with the same identity they use for the rest of your tools, IT has one place to manage access provisioning and revocation, and you can enforce multi-factor authentication through your existing identity provider rather than relying on each user to set it up individually.
What SSO Does
SSO (Single Sign-On) delegates UniLink's authentication to an external identity provider (IdP) that your organization already trusts and manages. Instead of storing and validating usernames and passwords directly, UniLink redirects team members to your IdP at login time. The IdP verifies their identity — using whatever factors you have configured there, including MFA — and sends a token back to UniLink confirming who they are. UniLink maps that identity to an existing team member account and grants access accordingly.
For Google Workspace SSO, the integration uses OAuth 2.0. Team members click "Sign in with Google" on the UniLink login page, authenticate with their Google Workspace account (subject to your Workspace's MFA and session policies), and are returned to UniLink without ever entering a UniLink-specific password. For SAML 2.0, the integration uses a standards-based XML assertion flow supported by enterprise IdPs including Okta, Microsoft Azure AD, and OneLogin. The SAML setup requires exchanging metadata between UniLink and your IdP, a one-time configuration that takes fifteen to thirty minutes.
SSO enforcement is the feature that gives IT teams peace of mind. When enforcement is turned on, UniLink passwords for team members are disabled — the only way in is via the configured SSO provider. When an employee is offboarded and their Google Workspace or Okta account is suspended, their UniLink access is automatically blocked at the next login attempt. You do not need to separately revoke UniLink access — it is handled by the identity layer your IT team already manages.
How to Get Started
- Confirm your plan. SSO requires the Business plan ($49/mo) or Agency plan. Go to
app.unilink.us→ Account → Billing to verify. If you are on Starter or Pro, upgrade before proceeding. - Navigate to Settings → Security → SSO. In the Dashboard sidebar, click Settings, select the Security tab, and scroll to the SSO section. You will see options to configure Google Workspace SSO or SAML 2.0 SSO.
- Choose your provider. Click Configure next to your preferred provider — Google Workspace or SAML 2.0. If your organization uses Okta, Azure AD, or OneLogin, select SAML 2.0 and your IdP's documentation will guide you through the provider-specific steps during configuration.
- Complete the provider-specific setup. For Google Workspace: authorize UniLink in your Google Workspace admin console and paste the Client ID and Client Secret into UniLink. For SAML 2.0: download UniLink's Service Provider metadata XML and upload it to your IdP, then paste your IdP's metadata URL (or XML) into UniLink.
- Test the connection before enforcing. UniLink provides a Test SSO button after configuration. Click it — your browser opens a new tab and attempts the SSO login flow. Verify you can complete the login successfully. Only after a successful test should you consider turning on enforcement.
How to Use SSO
- Configure Google Workspace SSO. In your Google Workspace Admin console, go to Security → API controls → App access control, and authorize UniLink. Copy the OAuth Client ID and Client Secret from the Google console into UniLink's SSO settings. Map your Workspace domain to your UniLink account and save.
- Configure SAML 2.0 with Okta. In Okta, create a new SAML application using UniLink's SP metadata URL (shown in the SSO settings panel). Set the SSO URL and Audience URI as specified by UniLink. Copy Okta's IdP metadata URL and paste it into UniLink's SAML configuration. Save and test.
- Configure SAML 2.0 with Azure AD. In Azure portal, create a new Enterprise Application, select SAML as the sign-on method, and fill in the Identifier and Reply URL from UniLink's SSO settings. Download the Federation Metadata XML from Azure and upload or paste the URL into UniLink's SAML settings.
- Enforce SSO for all team members. After a successful test, go to the SSO settings panel and toggle Enforce SSO. Read the enforcement warning — once enabled, all team members (including Admins) must log in via SSO. UniLink passwords for non-Owner accounts are disabled. The Owner account retains password login as a fallback in case SSO breaks.
- Communicate the change to your team. Before enforcing SSO, notify all team members via email or your internal communication tool. Tell them the date enforcement begins, the provider they will use (Google or SAML), and what to do if they have login issues. Teams that are caught off-guard by SSO enforcement generate support tickets and frustration.
Key Settings
| Setting | What It Does | Recommended |
|---|---|---|
| SSO Provider | Selects between Google Workspace (OAuth) and SAML 2.0 for authentication | Use Google Workspace if your team already uses Google; use SAML 2.0 for Okta, Azure AD, or OneLogin |
| Test SSO | Runs a live authentication test before enabling SSO for all members | Always test before enforcing — a misconfigured SSO can lock all team members out simultaneously |
| Enforce SSO | Disables UniLink passwords for team members — SSO becomes the only login method | Enable after a successful test and after notifying the team; the Owner retains password login as a fallback |
| Auto-provisioning | Automatically creates UniLink team accounts for users authenticated via SSO who do not yet have an account | Enable if you want new employees to get UniLink access automatically when added to the IdP; disable for manual control over who gets access |
| Session timeout | Controls how long an SSO session remains valid before requiring re-authentication | Align with your IdP's session policy; for security-sensitive teams, shorter timeouts (4–8 hours) are preferable |
Get the Most Out Of SSO
The most important benefit of SSO is not convenience — it is centralized offboarding. When an employee leaves your company, your IT team suspends their account in Google Workspace or Okta. That suspension propagates to every SSO-connected application at once. Without SSO, you need a manual checklist that includes every SaaS tool the employee used — and UniLink is easy to forget. With SSO enforcement enabled, forgetting UniLink on the offboarding checklist does not matter, because the suspended IdP account blocks access automatically at the next login attempt.
SAML 2.0 configuration has more steps than Google Workspace SSO, but it also provides more control. With SAML, you can configure exactly which attributes your IdP sends to UniLink — user email, name, department, and role. If your organization uses role mapping (e.g., everyone in the "Marketing" group in Okta automatically gets Editor role in UniLink), SAML is the protocol that enables this. Google Workspace SSO does not support attribute-based role mapping in UniLink's current implementation.
When enforcing SSO, the Owner account's password login is retained as a safety valve. This is by design — if your IdP goes down or your SSO configuration breaks, you need a way to log in, fix the configuration, and restore access for the team. Never disable the Owner password or lose access to the Owner account. Store the Owner credentials in a secure password manager, separately from your IdP credentials, so you have an independent fallback path.
Auto-provisioning is a powerful but double-edged setting. When enabled, any user who authenticates via your IdP and is not yet a UniLink team member gets automatically added with a default role. This makes onboarding seamless — new employees get access without any manual invitation step. The risk is that your IdP may have users who should not have UniLink access (contractors, interns, alumni with delayed deactivation). Review your IdP's user list before enabling auto-provisioning and ensure your deprovisioning process in the IdP is tight.
Troubleshooting
| Problem | Cause | Fix |
|---|---|---|
| SSO option not visible in Settings → Security | Account is on Starter or Pro plan, which does not include SSO | Upgrade to Business ($49/mo) or Agency plan at Account → Billing |
| SAML test fails with "Invalid Assertion" error | The SSO URL, Audience URI, or certificate in the IdP does not match UniLink's SP settings | Double-check the Identifier (Entity ID) and Reply URL (ACS URL) in your IdP against the values shown in UniLink's SSO settings panel |
| Team members are locked out after enabling SSO enforcement | SSO was enforced before all members completed the provider's account linking step | Log in as Owner with password, temporarily disable SSO enforcement, have members link their IdP accounts, then re-enable enforcement |
| Auto-provisioned users receive the wrong default role | The default role for auto-provisioned users is set to a higher level than intended | Go to SSO settings and change the default auto-provisioning role to Viewer; manually upgrade specific users as needed |
- Centralized offboarding — suspending an IdP account immediately blocks UniLink access
- Team members use existing company credentials — no new passwords to remember or lose
- Enforcement lets IT manage UniLink access through existing identity infrastructure
- SAML 2.0 supports attribute-based role mapping for automated permission assignment
- Requires Business or Agency plan — not available on Free, Starter, or Pro
- SAML 2.0 setup involves exchanging metadata between two systems and is more complex than password auth
- If the IdP goes down, all SSO-dependent logins fail until it recovers (Owner retains password fallback)
Which plans include SSO?
SSO is available on the Business plan ($49/mo) and Agency plan. Starter and Pro plan accounts use UniLink's standard email/password authentication and do not have access to the SSO configuration panel.
Can I use both Google SSO and SAML at the same time?
No. UniLink supports one SSO provider per account at a time. If you need to switch providers (e.g., migrating from Google Workspace to Okta), disable the current SSO integration first, configure the new one, test it, then re-enable enforcement.
What happens to existing team members when I enable SSO?
Existing members are not automatically migrated. They will need to link their IdP account to their UniLink login on their next login after SSO is enabled. Until enforcement is turned on, they can still use their UniLink password. After enforcement is on, only SSO login works.
Does the Owner account get locked out if SSO breaks?
No. The Owner account retains password-based login even when SSO enforcement is enabled. This is a deliberate safety mechanism — it ensures someone always has a path to log in and fix a broken SSO configuration without contacting support.
Which SAML providers does UniLink support?
UniLink supports any standards-compliant SAML 2.0 identity provider. Tested and documented providers include Okta, Microsoft Azure Active Directory, and OneLogin. Other SAML 2.0 providers should also work — if you encounter issues with a specific provider, contact UniLink support with your IdP's metadata for troubleshooting assistance.
- SSO is available on Business/Agency plans and is configured at Dashboard → Settings → Security → SSO.
- Supported providers are Google Workspace (OAuth) and any SAML 2.0 provider including Okta, Azure AD, and OneLogin.
- Always run the Test SSO flow and get two successful end-to-end tests before enabling SSO enforcement for the team.
- SSO enforcement is the key security benefit — it ties UniLink access to your IdP, so offboarding in the IdP automatically blocks UniLink access.
- The Owner account retains password login even with enforcement on — protect these credentials as your fallback access path.
Ready to unify your team's login and tighten security? Configure SSO for your UniLink account at app.unilink.us → Settings → Security.
Create Your Free Link-in-Bio Page
Join thousands of creators using UniLink. 40+ blocks, analytics, e-commerce, and AI tools — all free.
Get Started Free