How to Set Up SSO (SAML) in Front (Okta / Google Workspace)

Where SSO lives in Front (and what "SSO" means here)

Front's SSO settings are company-wide, not per-workspace. You'll find them under the gear icon, in the Company settings tab, under Security → Single sign on. Per Front's single sign-on documentation, that panel offers three mutually exclusive options: Disabled, Google or Office 365 login, and SAML.

The distinction matters. Google or Office 365 login is a lightweight OAuth-style option — teammates click "Sign in with Google" and that's it, no metadata to exchange. SAML is the enterprise path: you wire Front to a dedicated identity provider, control the assertion, and get the full audit and provisioning story. This guide is about the SAML path, because that's what "Front SSO" usually means when Okta or Google Workspace is involved as a formal IdP.

One thing to fix in your head before you start: SSO governs teammates, not contacts. Your customers writing into a shared inbox never authenticate — they're contacts, and they email you like they always did. SSO only changes how the people on your team log in to Front. If you're new to that vocabulary, what is Front and the Front shared inbox model explain the teammate-versus-contact split that underpins everything here.

SP-initiated vs IdP-initiated SAML

Before you touch a single field, decide which direction your login flow runs — because the two behave differently for your users.

SP-initiated means the flow starts at the service provider, which is Front. A teammate goes to Front's sign-in page — https://[your-subdomain].frontapp.com/signin per the Okta SAML setup guide for Front — Front bounces them to your IdP to authenticate, and the IdP sends them back with a signed assertion. This is the flow most people expect: someone opens Front, and login "just happens."

IdP-initiated means the flow starts at the identity provider. A teammate opens their Okta or Google Workspace dashboard, clicks the Front tile, and the IdP pushes a SAML assertion straight to Front's ACS URL — no visit to Front's sign-in page first. Front supports both. In practice most teams enable both and let people use whichever entry point they prefer; the tile in the IdP dashboard is convenient, and the direct Front URL is what deep links and bookmarks resolve to.

The reason this distinction earns its own section: login loops almost always come from a mismatch between the two. If your IdP is configured for IdP-initiated only but a user hits Front's SP-initiated sign-in page, or the RelayState is wrong, the browser can bounce endlessly between Front and the IdP. More on that below.

The Okta walkthrough

Here's the end-to-end shape with Okta as your IdP.

1. In Okta, add the Front application. Front is in the Okta Integration Network, so search for it rather than building a generic SAML app — the pre-built integration pre-fills the endpoints for you.
2. Set your Front subdomain in Okta. The Okta docs are explicit that you must enter the correct subdomain in the app's General settings — a wrong subdomain is the single most common cause of authentication failures.
3. Grab the IdP details from Okta. You need the entry point (Okta's Identity Provider Single Sign-On URL) and the signing certificate in PEM text format from the Okta admin dashboard.
4. In Front, choose SAML under Security → Single sign on, and paste in the entry point, the request binding (HTTP Redirect or HTTP POST), the requested authentication context, and the signing certificate.
5. Copy Front's SP values back into Okta. Front exposes an Entity ID, an ACS URL (the assertion consumer service endpoint that receives the SAML response), a Name ID Format, and an encryption certificate. Those go into Okta's SAML settings so the assertion is addressed correctly.
6. Assign the app to your users/groups in Okta, then test with one account before rolling it out.

A critical caveat straight from Front's docs: Front does not provide a backup login URL. Once SAML is on, "we do not provide a backup log-in URL where users can sign-in using their normal username and password." If your IdP goes down or a cert expires, the only way out is to email Front support at [email protected] to disable SAML. Keep that email handy.

The Google Workspace walkthrough

Google Workspace can act as your SAML IdP through a custom SAML app. The shape mirrors Okta, with Google-specific menu paths per Google's custom SAML app documentation.

1. In the Google Admin console, go to Apps → Web and mobile apps → Add app → Add custom SAML app. Name it "Front" and optionally upload an icon.
2. On the Google Identity Provider details page, copy the SSO URL and Entity ID and download the certificate (or download the full IdP metadata). These are Google's equivalents of Okta's entry point and signing certificate.
3. In Front (Security → Single sign on → SAML), paste Google's SSO URL as the entry point and the downloaded certificate as the signing certificate.
4. Back in Google's Service Provider Details window, enter Front's ACS URL — Google requires it to start with https:// — and Front's Entity ID (a globally unique name). The Start URL / RelayState is optional; set it if you want IdP-initiated clicks to land somewhere specific.
5. Under User access, turn the app ON for the org unit or everyone, then Save. Provisioning can take a few minutes to propagate before the tile appears.

Test with a single account first, exactly as with Okta. Google Workspace changes sometimes need a fresh browser session to take effect.

Provisioning, contacts, and the plan gate

SAML SSO is not on every plan. Front's documentation states SAML requires "the latest Professional plan or above." On lower tiers, the Single sign on panel will still show Google/Office 365 login, but the SAML option is gated. That's worth confirming before you schedule an IdP project — nothing is more deflating than doing the Okta config and discovering the toggle is locked.

SCIM auto-provisioning is narrower still. Front supports SCIM user provisioning for select IdPs — notably, "Front SCIM user provisioning functionality is accessible on Microsoft Entra ID P1 or Microsoft Entra ID P2 plans." SCIM is what auto-creates and deactivates teammate accounts when someone joins or leaves in your directory; without it, you're still manually adding and removing teammates in Front even though login runs through the IdP.

And to say it once more because it's the most common misconception: contacts don't authenticate. SSO is teammate auth. The customer emailing your team inbox never logs into anything. If you're thinking about customer-facing login — say, a help center or portal — that's a different mechanism entirely, not Front SSO.

The login loop — and other common breakages

Here's the honest troubleshooting section, because SAML setups break in a small number of predictable ways.

The login loop deserves the callout it gets. Because Front supports both SP- and IdP-initiated SAML, a half-configured setup — for example, an assertion that lacks a valid RelayState, or a subdomain typo in the IdP — will send the browser back and forth until it gives up. The first thing to check is always the subdomain in the IdP app config; the second is whether both initiation flows are actually enabled; the third is a hard cookie clear. Getting those three right resolves the overwhelming majority of loops.

Where an AI layer fits after login

SSO answers one question: who is allowed into Front. It has nothing to say about the harder question — how quickly the conversations inside Front get resolved. That's a different layer of the stack, and it's worth being clear that the two don't compete.

Once your team is authenticated and working their shared inboxes, the category of AI agents for customer service exists to take on the reading-and-answering work that no login system touches. Macha is one such layer: it runs on top of the Front you already use, through the live Macha–Front connector — it does not replace Front, your SSO, or your identity provider. Your teammates still sign in through Okta or Google Workspace exactly as configured here. Then, on the conversations flowing into your inboxes, a Macha agent reads the message, understands intent, and drafts or sends a grounded reply — pulling a real order or account status through a custom tool that turns your REST API into something the agent can call, much the way you'd build against the Front API yourself. SSO decides who's in the door; the agent helps the people who are in the door clear their queue faster. Macha's credits are consumed per AI action, never per resolution — because automation and reasoning have different costs, and it's honest to price them that way.

FAQ

What plan do I need for SAML SSO in Front? SAML SSO requires the latest Professional plan or above. Lower tiers can still use Google or Office 365 login under Security → Single sign on, but the SAML option is gated. SCIM auto-provisioning is narrower — it's available for select IdPs such as Microsoft Entra ID on the P1 or P2 plans.

Where do I turn on SSO in Front? Open the gear icon → Company settings → Security → Single sign on. You'll see three options: Disabled, Google or Office 365 login, and SAML. SSO is company-wide; it can only be enabled at the company level and applies to all teammates once on.

What's the difference between SP-initiated and IdP-initiated SAML? SP-initiated starts at Front's sign-in page (https://[subdomain].frontapp.com/signin), which redirects to your IdP. IdP-initiated starts at your Okta or Google dashboard, where clicking the Front tile pushes an assertion straight to Front. Front supports both; enabling both avoids most login-loop issues.

How do I fix a Front SSO login loop? Check three things in order: the Front subdomain in your IdP app config (a wrong value is the top cause), whether both SP- and IdP-initiated flows are enabled, and your browser cookies (clear them and retry). Also confirm the teammate's Front email matches their IdP email.

What if we get locked out — is there a backup login? No. Front does not provide a backup login URL for username/password sign-in once SAML is enabled. If your IdP is down or a certificate expired, email Front support at [email protected] to disable SAML. As a precaution, keep one admin session open whenever you rotate certificates.

Ready to turn "logged in" into "actually answered"? Start a free trial of Macha and connect it to your Front in minutes.