SSO guide
SSO guide for Business & Enterprise
Set up SAML 2.0 Single Sign-On for your organization.
Single Sign-On (SSO) lets your team authenticate through your organization's identity provider and access Magnific without separate credentials. SSO is available on Business and Enterprise plans.
SSO uses the SAML 2.0 protocol to securely exchange authentication data between your identity provider (IdP) and Magnific. When a user attempts to log in, they are redirected to your organization's IdP for authentication. Once verified, they gain access to Magnific without entering additional credentials.
Key benefits include:
Enhanced security through centralized authentication
Simplified access management for administrators
Reduced password fatigue for team members
Automatic user provisioning
Compliance with enterprise security policies
In this article
SSO availability by plan
Feature | Business | Enterprise |
|---|---|---|
SSO via SAML 2.0 | Yes (self-service) | Yes (advanced) |
Domain verification | Yes | Yes |
Multiple domains | Limited | Unlimited |
Dedicated SSO support | No | Yes |
Before you begin
To configure SSO you will need:
Administrator access to your Magnific Business or Enterprise account.
Administrator access to your identity provider (Okta, Microsoft Entra ID, Google Workspace, or another SAML 2.0 provider).
Access to your domain's DNS settings for domain verification.
The Magnific SAML values listed below (available in Settings → Security SSO in your Magnific admin panel).
Magnific SAML values
These values are the same regardless of which identity provider you use. Copy them from Settings → Security SSO in your Magnific admin panel.
Entity ID (Audience): https://id.magnific.com/sp/{teamId}
ACS URL (Reply URL): shown in your SSO settings panel. Each organization has a unique identifier appended to this URL.
Sign-on URL: shown in your SSO settings panel.
Required attribute mappings
All identity providers must send the following three attributes. Use Unspecified as the Name Format for each one.
Attribute name | Source attribute |
|---|---|
user.mail | |
first_name | user.givenname |
last_name | user.surname |
Step 1: Verify your domain
Before configuring your identity provider, you must verify ownership of your company domain.
Go to Settings → Security SSO in your Magnific admin panel.
Enter your company's domain (e.g., yourcompany.com). This is the domain after the @ symbol in your employees' email addresses.
Copy the verification code provided by Magnific.
Log in to your DNS provider (e.g., GoDaddy, Cloudflare, AWS Route 53) and add a new TXT record at the root domain with the verification code as the value.
Return to Magnific and click Verify domain.
DNS propagation may take up to 48 hours but typically completes within minutes.
Step 2: Configure your identity provider
Magnific supports any SAML 2.0 compatible identity provider. In all cases you will create a new SAML application, paste the Magnific SAML values, configure the required attribute mappings, assign users, and download the IdP metadata XML for the next step.
Okta
In your Okta Admin Console, go to Applications → Create App Integration and select SAML 2.0.
Name the app Magnific. Click Next.
In SAML settings, paste the Entity ID into Audience Restriction, and the ACS URL into Single Sign On URL, Recipient URL, and Destination URL.
Configure the three attribute mappings (email, first_name, last_name).
Click Next, select I'm an Okta customer adding an internal app, then click Finish.
Go to the Assignments tab and assign the app to the users or groups who need access.
Go to the Sign On tab and copy the Metadata URL or download the metadata XML.
Microsoft Entra ID
In the Microsoft Entra admin center, go to Identity → Applications → Enterprise applications → New application. Create your own application named Magnific.
Click Set up single sign on and select SAML.
In Basic SAML Configuration, paste the Entity ID, ACS URL, and Sign-on URL.
Under Attributes and Claims, configure the three attribute mappings (email, first_name, last_name).
In the SAML Certificates section, download the Certificate (Base64) and copy the App Federation Metadata URL.
Go to Users and groups and assign the users or groups who need access.
Google Workspace
Sign in to your Google Admin console (admin.google.com) with a super administrator account.
Go to Apps → Web and mobile apps → Add app → Add custom SAML app.
Name the app Magnific. Click Continue.
Download the IdP metadata XML from the Google Identity Provider details page. Click Continue.
Enter the Entity ID, ACS URL, and Sign-on URL as service provider details.
Add the three attribute mappings (email, first_name, last_name). Click Finish.
In the app settings, click User access and enable the app for your users or organizational units.
Other providers like Duo, OneLogin, Auth0, and Ping Identity also work with the same Magnific SAML values and attribute mappings.
Step 3: Complete setup in Magnific
Return to Settings → Security SSO in Magnific.
Upload the metadata XML file from your identity provider.
SSO starts in Flexible mode by default so you can test without disrupting existing logins.
Once confirmed working, choose your preferred enforcement mode.
Where SSO sign-in starts
Magnific always starts the sign-in process. Your users can reach it in two ways, and both end up in the same place.
From the login page. On the Magnific login page, your users choose Continue with SSO and enter their work email
address. We use the domain of that address to find your organization and redirect them to your identity provider.
From your direct SSO link. In Settings → Security SSO you will find a link unique to your organization that
starts the sign-in immediately, without asking for an email address:
https://id.magnific.com/sso?client_id=magnific&provider_id=your-organization-id
Copy it exactly as shown in your panel — both parameters are required, and the link will not work without them.
This is the link to share with your users: add it to your intranet, your onboarding emails, or your browser bookmarks.
The identifier in this link is not the same as the one in your ACS (Reply) URL. They look similar but they are different values, and swapping them will stop the sign-in from working. Copy each one from the field it belongs to in your SSO settings panel.
Enforcement modes
Mode | Behavior |
|---|---|
Flexible | Users can sign in via SSO or email and social login. Ideal for testing before full rollout. |
Restricted | Existing users keep email and password login. New registrations are blocked outside of SSO. |
Strict | All users must sign in via SSO only. Email and password login is disabled. |
Start with Flexible mode to verify the configuration works. Once confirmed, switch to Restricted or Strict.
Troubleshooting
Email address not valid error
This error occurs when the SSO Attribute Statements are not correctly configured in your Identity Provider (IdP).
Our system expects specific user attributes to be sent during the SSO authentication process. If these attributes are missing, misnamed, or mapped incorrectly, the login will fail and return the “Given email address is not valid” error.
Verify that your IdP sends the three required attributes (email, first_name, last_name) with the correct source values and Unspecified name format.
Certificate error
This error occurs when there is an issue with the XML metadata file uploaded during the SSO configuration.
Specifically, the certificate included in the XML file is not valid or does not match the expected configuration. As a result, the system is unable to verify the identity provider and the SSO setup fails.
Common causes
The XML file uploaded is outdated.
The certificate in the XML does not belong to the active IdP.
The certificate has expired.
The XML file was modified manually and the certificate is malformed or incorrect.
How to fix it
Re-download the latest XML metadata from your identity provider.
Make sure the certificate in the XML is correct and active.
Upload the new XML file without modifying it.
If the error persists, contact your IT or security team to verify the certificate configuration in your IdP.
The test button in my identity provider doesn't work
What you see. You finish your SAML configuration, click the button your identity provider offers to test the application, and instead of signing in, your browser shows a page of plain text like this:
{"success":false,"message":"We couldn't complete your single sign-on because it wasn't started from our login page. Please sign in using the SSO link available in your account settings on the website, or the one provided by your administrator.","errorCode":0}
Why it happens. Magnific SSO is service-provider initiated: the sign-in has to begin on our side. When it begins from Magnific, we build the authentication request, hand it to your identity provider, and keep track of that specific attempt for a few minutes.
The test button in your identity provider skips that first step — it sends us a response to a request we never made, so we have nothing to match it against and we stop the sign-in.This does not mean your configuration is wrong. This is the part that surprises most administrators. We verify your signature, your certificate, the attributes you send and your verified domain before reaching this point, and all of that can be perfectly correct — the test button will still fail. So this failure tells you nothing about your SAML setup, and you cannot use that button to validate it.How to test your configuration instead. Use either of the two real entry points described in Where SSO sign-in starts: the Continue with SSO button on the login page, or your direct SSO link from Settings → Security SSO. We recommend leaving SSO in Flexible mode while you test, so existing logins keep working if something is not right yet.
Don't retry with the wrong link. After five failed attempts with an invalid organization identifier, your IP address is blocked for 15 minutes. If you hit this, wait it out and then copy the link again from your settings panel rather than editing it by hand.
Frequently asked questions
Can I use SSO with multiple domains?
Yes. Business plans support a limited number of domains. Enterprise plans allow unlimited domains, which is useful for organizations with multiple subsidiaries or regional domains.
What happens to existing users when I enable SSO?
It depends on the enforcement mode. In Flexible mode, nothing changes. In Restricted mode, existing users keep their current login methods but new registrations are blocked outside SSO. In Strict mode, all users must use SSO.
Can I enforce SSO for all users?
Yes. Set the enforcement mode to Strict. All users with emails matching your verified domain will be required to sign in through SSO.
Which identity providers are supported?
Any provider compatible with SAML 2.0. This guide covers Okta, Microsoft Entra ID, and Google Workspace, but others (Duo, OneLogin, Auth0, Ping Identity) work with the same Magnific SAML values.
Can I make my identity provider's test button work?
Not by configuring a relay state or a default relay state value. The value we use to tie a sign-in attempt together is generated fresh for each attempt when Magnific starts the flow, and it is only valid for a few minutes — so a fixed value configured in your identity provider can never match it. If your identity provider allows its application tile or test action to simply open a URL in the browser, instead of sending a login response, then pointing it at your direct SSO link will work: it enters through our supported path like any other sign-in. Whether your provider offers that option, and what the setting is called, depends on the provider — check its documentation. Otherwise, the direct SSO link from Settings → Security SSO is the way to start a sign-in without going through the login page.