Freshdesk SSO with Azure (Microsoft Entra ID)

Freshdesk SSO with Azure, now called Entra ID, takes twenty minutes to configure. The failures take longer, so read those first.

Decide what SSO covers before you configure anything

Freshdesk has two populations of user and they are configured separately. Getting this wrong is the most common reason a rollout stalls halfway.

Agents are your staff. They belong in your directory, and this is where SSO earns its keep: central provisioning, central offboarding, MFA enforced by your identity policies.
Contacts are your customers, logging into the support portal. They are usually not in your corporate directory at all. If you force SSO on them without a plan, you have locked your customers out of their own tickets.

The normal configuration is SSO required for agents, and either password login or a separate customer identity provider for contacts. If your customers are all employees of one client organisation, portal SSO makes sense too, but it is a separate decision and a separate setup.

One more thing to settle first: where your account configures identity. Freshworks has been consolidating login and administration at the organisation level across its products, so newer accounts set this once for everything rather than inside Freshdesk. Check which model you are on before hunting for a settings page that may not be where an old article says it is.

How Freshdesk SSO with Azure exchanges SAML

Ignore the screenshots in any tutorial and understand the four values moving between the two systems. Everything else is typing.

From Freshdesk to Entra: an entity ID that identifies your Freshdesk instance as the service provider, and a reply URL, sometimes called the assertion consumer service URL, where Entra posts the signed assertion after a successful login.
From Entra to Freshdesk: a sign-on URL to redirect users to, a logout URL, and the signing certificate Freshdesk uses to verify that the assertion really came from your directory.

Copy those values from each product rather than typing them from memory or from a blog post. A single character wrong in a URL produces an error message that won't tell you which character.

In Entra you're creating an enterprise application. Freshdesk has a gallery entry, and using it saves you filling in the SAML defaults by hand. If you create the app manually instead, everything still works, you just fill in more fields.

Attribute mapping, the part people get wrong

The assertion has to tell Freshdesk who just logged in, in a form Freshdesk recognises.

The identifier is email. Send the user email address as the NameID, in the format Freshdesk expects, and make sure it exactly matches the email on the Freshdesk agent record. Not their username. Not their UPN if the UPN differs from their mail attribute, which in real directories it frequently does. This single mismatch causes most first-day failures.

Send name attributes too, given name and surname, so newly provisioned users arrive with something readable rather than an email address as a display name.

Group or role claims are worth considering if you want directory membership to drive Freshdesk access. Be careful here: role mapping is powerful and it is also how one badly scoped group grants forty people agent licences overnight. Start without it, confirm login works, then add it deliberately.

And check whether just-in-time provisioning is enabled and whether you want it. If it's on, anyone who can authenticate becomes a user. If it's off, you create agents in Freshdesk first and SSO only handles authentication. Both are legitimate, but you should know which one you chose.

The failures, in the order you will hit them

The user is not assigned to the enterprise application. Entra will not issue an assertion for someone who has no assignment. The error looks like a Freshdesk problem and is not.
Email mismatch. The assertion carries a UPN, the Freshdesk record carries a mail address, and they differ. Pull the actual assertion with a SAML tracing extension and read what was sent rather than what you assume was sent.
Certificate expiry. Signing certificates expire, typically a few years out, and when one does every agent is locked out at once with no warning. Put the expiry date in a shared calendar the day you finish the setup. This is the single highest-impact five minutes in the whole project.
Clock skew. Assertions are time-bound. A server whose clock has drifted rejects valid logins with an unhelpful message.
No break-glass account. If SSO is enforced for all agents and the identity provider goes down, nobody gets in, including you. Keep one administrator able to log in with a password, on a strong unique credential, and document it somewhere your team can reach without the help desk.
Signing configuration mismatch. Whether the response, the assertion, or both are signed has to match on each side. If login fails after everything else checks out, look here.
Contacts locked out. Portal login was switched to SSO alongside agent login, and customers who were never in the directory can no longer see their tickets. Test with a real customer account before you enable anything, not after.

Testing and rollout

Do it in this order and you won't have a bad morning.

Test with one pilot agent in a private browser session, so no existing cookie masks a broken flow.
Test both directions. Starting at the Freshdesk login page, and starting from the Microsoft app launcher. They exercise different paths and one can work while the other does not.
Test logout. Confirm what signing out actually ends, the Freshdesk session or the directory session, and tell your team which it is.
Test a portal login as a customer, from an account not in your directory.
Then enforce. Turn on the requirement only once every path above is confirmed, and keep the break-glass account intact.

Broader account hardening, including password policy and IP restrictions, is covered in Freshdesk SSO and security.

FAQ

Frequently asked questions

Is Freshdesk single sign on hard to set up?

Freshdesk SSO setup takes about twenty minutes on each side. Freshdesk single sign on is standard SAML, so the work is attribute mapping rather than anything exotic.

Does Freshdesk SSO with Azure use SAML?

Yes. Entra ID, formerly Azure AD, connects to Freshdesk over SAML, and there's a gallery application that pre-fills the standard settings. Newer Freshworks accounts configure this at the organisation level across products.

Can I use SSO for agents but not for customers?

Yes, and for most companies that's the right configuration. Agent login and portal login are configured separately, so customers can keep password login while staff authenticate through your directory.

Which attribute should be sent as the identifier?

The email address that matches the Freshdesk user record exactly. Sending a UPN that differs from the mail attribute is the most common cause of failed logins.

What happens when the SAML certificate expires?

Every agent loses access at once. Rotate before expiry and put the date in a shared calendar the day you finish the setup.

How do I get in if the identity provider is down?

Only through a break-glass administrator account that can still use a password. Create one, secure it properly, and document where the credential lives.

Once everyone can log in

The next thing to fix is the queue itself. Ticket Merger detects duplicate tickets in Freshdesk and merges them automatically.

Start free trial

14-day free trial. No credit card required.