Freshdesk SSO Explained (SAML, OAuth & JWT)
Single sign-on lets someone log into Freshdesk with the identity they already have somewhere else — their company's Okta tile, an Azure AD account, or your own customer login — instead of maintaining a separate Freshdesk password. It sounds like one feature, but it's really several: Freshdesk speaks three broad protocols (SAML, OAuth/OIDC and JWT), and it draws a hard line between signing in your agents and signing in your customers. Get the mental model right and the setup is straightforward; get it muddled and you end up configuring the wrong policy for the wrong audience. This guide walks through the three SSO modes, the agent-versus-contact split, where each lives in the Freshworks Neo Admin Center, and when to reach for which.
The two audiences: Agent SSO vs Contact SSO
Before the protocols, understand the split, because it decides almost everything else. Per Freshworks' Agent SSO and Contact SSO documentation, Freshdesk lets you configure SSO separately for two distinct groups of people.
Agent SSO covers the people who work inside the help desk — admins, agents and employees across the organization. This is the classic corporate case: your staff already authenticate through a company identity provider, and you want them landing in Freshdesk without a second credential to manage or a second password to leak.
Contact SSO covers the people you support — your customers, logging into the support portal or knowledge base. This one is flagged "Only for Freshdesk" in the docs, because it's a product-specific need: if you run a customer portal behind your own product's login, Contact SSO lets a signed-in customer move into your Freshdesk portal without logging in again.
The reason to keep these straight is that they can run on entirely different identity providers. Agents might sign in through Azure AD while contacts flow through your own application's JWT-based login. When you sit down to configure, the very first question the interface asks is which of these two audiences the policy is for.
The three SSO modes Freshdesk supports
Under the hood, all of this rides on standard protocols. Per the Single Sign-On in Freshdesk reference, Freshdesk supports SAML 2.0, OAuth2 / OpenID Connect (OIDC), and JWT. Here's what each is actually for.
SAML 2.0 is the enterprise default. It's an XML-based standard, and it's what most identity providers — Okta, Azure AD, ADFS, OneLogin, Auth0, G-Suite — expose out of the box. If your organization already has an IdP and you just want agents to use it, SAML is almost always the right pick. You exchange a couple of URLs and a certificate, and you're done.
OAuth2 / OIDC is the modern token-based option, common when you're integrating with an identity provider that speaks OAuth natively or when you want the OpenID Connect flavor of the exchange. Functionally it lands in the same place as SAML — the user proves who they are at the IdP and gets dropped into Freshdesk — but the wire format and endpoints differ.
JWT is the build-it-yourself option. Rather than plugging into a packaged IdP, you generate a signed JSON Web Token in your own application and hand it to Freshworks. This is the natural fit for Contact SSO, where the "identity provider" is your own product's login system. It's the most flexible and the most hands-on of the three.
| Mode | Best for | Who runs the IdP | Effort |
|---|---|---|---|
| SAML 2.0 | Agents at companies with Okta/Azure AD/ADFS | A packaged IdP vendor | Low — exchange URLs + cert |
| OAuth2 / OIDC | Agents on OAuth-native identity platforms | A packaged IdP vendor | Low–medium |
| JWT | Contacts logging in via your own product | You (your app) | Higher — you sign tokens |
Where you configure it: the Neo Admin Center
All of this now lives in the Freshworks Neo Admin Center, not in Freshdesk's own admin. From your organization URL (yourcompany.freshworks.com), you open Security in the left sidebar. From there you either edit the default policy, which applies org-wide to every user, or create custom policies for a specific portal or subset of users. Freshworks documents the custom-policy path in Configuring custom SSO policies under Org.
Freshdesk's own Admin → Security area is the on-ramp to this. It surfaces the Freshworks SSO login card alongside the other account-hardening controls — IP range restriction, portal security and cookie policy — and it's where you'll click through to configure SSO. Two honest caveats worth knowing before you start: the Freshworks SSO card sits Inactive until configured, and the detailed setup can be configured only if you are an Org admin, so a regular Freshdesk admin may find the deeper form gated.
Setting up SAML: the fields that matter
SAML setup is a certificate-and-URL exchange between your IdP (the Identity Provider) and Freshworks (the Service Provider). Per Freshworks' SAML 2.0 configuration guide, the pieces you'll wire up are:
- The ACS URL — the public Service Provider endpoint that your IdP posts the SAML response to. You copy this from Freshworks into your IdP.
- The SAML SSO / login URL — the IdP endpoint that Freshworks sends the authentication request to. You copy this from your IdP into Freshworks.
- The security certificate — used by Freshworks to validate that the SAML responses coming back are genuinely signed by your IdP.
- The attribute mapping — email (mandatory), plus first name, last name and any custom fields you want passed through on login.
Because the field names differ slightly by IdP, Freshworks maintains provider-specific walkthroughs for Okta, Azure AD, ADFS and OneLogin rather than one universal form.
Setting up JWT: signing your own tokens
JWT is where the effort concentrates, and it's the mode most likely to matter for Contact SSO. Per the custom JWT implementation guide, Freshworks accepts RS256 only as the signing algorithm — you sign with an RSA private key and give Freshworks the matching public key. The token your app mints needs these claims:
{
"sub": "external-user-id-123",
"email": "[email protected]",
"given_name": "Jordan",
"family_name": "Lee",
"iat": 1720800000,
"nonce": "a1b2c3d4e5f6",
"phone": "+1-555-0100",
"picture": "https://cdn.example.com/u/123.png"
}
The required claims are sub (the user's ID in your system), email, iat (Unix epoch seconds, with a 300-second clock-drift tolerance), nonce (a random alphanumeric string valid for 10 minutes), and the given/family name. phone and picture are optional. On the Freshworks side you configure an Authorization URL (where Freshworks redirects the user to log in), a Redirect URL (where they come back after success), the RSA public key, and an optional Logout URL.
The flow itself: Freshworks redirects the user to your Authorization URL with client_id, state, nonce, grant_type=implicit and scope parameters; your app authenticates them and mints the signed JWT; the user is redirected to your Redirect URL with the JWT in the query string; and Freshworks validates the signature with your public key before opening the session.
When to use which — and the honest limits
The decision usually falls out of the two questions above. If you're signing in agents and you already have a corporate IdP, use SAML (or OIDC if your platform prefers it) — it's the lowest-effort, best-supported path. If you're signing in contacts through your own product's login, JWT is almost certainly what you want, because your app becomes the identity provider. Reach for OAuth2/OIDC when your identity platform speaks it more naturally than SAML.
Credit where it's due: Freshdesk's SSO is standards-based and genuinely flexible — four protocols, a clean agent/contact split, and per-portal custom policies is more than many help desks offer. But be clear-eyed about the edges. SSO configuration is Org-admin gated, so a day-to-day Freshdesk admin may not be able to finish the setup alone. The JWT path shifts real work onto you — you own the signing keys, the token minting, the nonce and clock-drift handling, and any bug there becomes a login outage. And SSO only governs who gets in; it does nothing for what happens next inside the ticket. It won't read the customer's problem, it won't pull an order status, and it won't draft a reply. If you're hardening access, it's worth pairing this with the broader Freshdesk security best practices and understanding your Freshdesk API rate limits before you wire integrations on top.
That "what happens after login" gap is where an AI agent layer fits. The category of AI agents for customer service exists to do the reasoning work authentication can't — and it's worth weighing the build-versus-buy tradeoff before you commit engineering time. Macha is one such layer: it runs on top of the Freshdesk you already use as a native connector, and it explicitly does not replace your help desk, your login, or your SSO policies. You connect it with your Freshdesk subdomain and API key — the same tickets your signed-in agents and contacts already work land in front of Macha, where it can draft grounded first replies, triage by intent, and look up order or account status through a custom tool. If you want the fuller picture, we cover how to automate Freshdesk with AI end to end. (Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice or Freshcaller. And credits are consumed per AI action, not per resolution — see the pricing breakdown.)
FAQ
What SSO protocols does Freshdesk support? Freshdesk supports SAML 2.0, OAuth2, OpenID Connect (OIDC) and JWT. SAML is the usual choice for agents at organizations with a packaged identity provider (Okta, Azure AD, ADFS, OneLogin), while JWT is the flexible option when your own application acts as the identity provider — typically for signing in contacts.
What's the difference between Agent SSO and Contact SSO? Agent SSO signs in the people who work inside the help desk — admins, agents and employees — usually through a corporate IdP. Contact SSO (Only for Freshdesk) signs in your customers to the support portal, often through your own product's login. They can use completely different identity providers, and you configure them separately.
Where do I configure Freshdesk SSO? In the Freshworks Neo Admin Center under Security, reached from your organization URL. You can edit the org-wide default policy or create custom policies per portal. Freshdesk's own Admin → Security page surfaces the Freshworks SSO card as the entry point — but note the SSO card is Inactive until configured and the setup can be completed only by an Org admin.
What signing algorithm does Freshdesk JWT SSO use? RS256 only. You sign the token with your RSA private key and provide Freshworks the matching public key. The required claims are sub, email, iat (with 300-second clock drift allowed) and nonce (valid for 10 minutes), plus the user's given and family name.
Can I add AI to Freshdesk without touching my SSO setup? Yes. An AI agent layer like Macha connects to Freshdesk as a native connector via subdomain and API key and runs on top of your existing help desk — it doesn't replace or interfere with your SSO policies. It helps after login by drafting grounded replies and triaging by intent, while Freshdesk stays the system of record for identity and access.
Want your signed-in agents and customers to get answers faster, not just get in faster? Start a free trial of Macha and connect it to your Freshdesk in minutes.
Add AI agents to your Freshdesk
Macha resolves tickets end to end on Freshdesk — no migration, no code.
Zendesk
Freshdesk
Gorgias
Front
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

