10 steps to integrating SSO with Microsoft Entra ID for IT professionals

SSO Integration with Microsoft Entra ID in 10 Steps for IT Professionals

Yes, SSO through Microsoft Entra ID (Azure AD) is achievable and, in practice, a fairly predictable process. For older enterprise applications, use SAML 2.0; for modern applications and APIs, use OpenID Connect. The path is always the same: register the application in Entra ID, configure the ACS/redirect values, test the login, and mandatorily add MFA and conditional access. Without that last step, the integration is only half done.

In short:

• For a successful SSO integration through Microsoft Entra ID, you first need to verify your role in Entra ID and gather all necessary application details and certificates.
• When choosing a protocol, OIDC is recommended for new internal projects, since it's easier to integrate and enables better automation of user account management.
• Configuration involves precisely setting URLs, certificates, attributes, and scopes, with special attention paid to correctly mapping claims and token values.
• For on-premises applications, it's recommended to use Application Proxy for reliable access without directly exposing your network, or Seamless SSO for automatic login within a domain environment.
• To ensure strong security, using MFA, conditional access, and certificate rotation is mandatory, together reducing risk in a centralized SSO system.

Table of Contents

• Prerequisites and a Quick Checklist Before Starting Your Azure AD SSO Integration
• Which Protocol to Choose: SAML, OIDC, or Password-Based SSO
• How to Register an Application and Configure SSO in Entra ID
• SSO for On-Premises Applications: Application Proxy and Seamless SSO
• Security Practices: MFA, Conditional Access, and Certificate Rotation
• How to Test SSO and Fix Common Errors
• What Actually Goes Wrong in SSO Projects
• How Moxy-web Helps You Implement SSO Integration
• Sources
• Frequently Asked Questions

Prerequisites and a Quick Checklist Before Starting Your Azure AD SSO Integration

Before you open the Microsoft Entra portal, check that you have everything you need. Poor preparation is the most common reason configuration drags on for several afternoons instead of taking one hour.

For the Azure AD SSO integration itself, you need the following:

• The right role in Entra ID — the Application Administrator or Cloud Application Administrator role, not a Global Administrator for everyday work.
• Application details — whether it supports SAML, OIDC, or only a password login form, and where its configuration page is located.
• Information about the tenant type — whether the application is single-tenant (for your organization only) or multi-tenant (for multiple clients at once), since this affects the Entity ID and registration.
• Synchronized server time — SAML tokens are sensitive to clock skew; even a few minutes' difference causes a rejected login.
• Valid certificates — if the application requires its own signing certificate, prepare it before configuration, not during it.
• Test users and test URLs — a separate test account without production permissions, and a test environment for the application where you can experiment without risk.

Use admin privileges only for the duration of configuration, then revoke them or time-limit them through conditional access. Never test an SSO login with a global administrator account. If the configuration goes wrong, you'll have broader access than you need, and that's an unnecessary risk.

Which Protocol to Choose: SAML, OIDC, or Password-Based SSO

Choosing a protocol isn't an aesthetic decision — it's a consequence of the architecture of the application you're connecting. Microsoft Entra ID supports three main approaches: SAML 2.0, OpenID Connect (OIDC), and password-based SSO for older systems that don't understand modern standards.

SAML works based on XML assertions. Entra ID, as the identity provider (IdP), signs an XML document, which the application (the service provider) verifies and uses to grant access. This protocol is still the standard for enterprise applications like ERP systems, HR platforms, and older intranet portals built a decade or more ago.

OIDC, built on OAuth2, uses JSON tokens (JWT) instead of XML. For developers, that means easier work. OIDC integrates far more easily with modern libraries, mobile apps, and APIs, since the token format is more compact and almost every modern development framework already understands it without additional libraries.

Password-based SSO and Application Proxy come into play when an application supports neither SAML nor OIDC at all. In that case, Entra ID stores the credentials and enters them automatically at login. This isn't true federation — it's a stopgap solution for systems you can't modify.

The decision also affects user provisioning. If you're planning automatic account creation and deprovisioning via the SCIM protocol, that's practically always tied to OIDC or SAML applications with a properly supported provisioning connector, while password-based SSO practically doesn't allow for this kind of automation.

Expert tip: Default to OIDC for new internal projects, even if the current requirement sounds like "just login." Migrating later from SAML to OIDC means rewriting your authentication logic; the reverse migration almost never happens.

How to Register an Application and Configure SSO in Entra ID

Configuration happens on two sides at once — in Entra ID and in the application itself — so the order of steps matters.

1. Open the Entra ID admin center and, in the Enterprise Applications section, select "New application." If the application isn't in the gallery, select "Create your own application" and enter a name.
2. Choose your SSO protocol in the Single sign-on tab: SAML or OIDC, based on the decision from the previous section.
3. For SAML configuration, enter the Identifier (Entity ID), which is the application's unique identifier, and the Reply URL (also called the ACS URL), where Entra ID sends the signed assertion after a successful login. Get both of these values from the application's documentation, not by guessing.
4. Download the SAML certificate (Base64 or raw format) from Entra ID and upload it into the application's configuration, where it's used to verify the signature of incoming assertions.
5. Check attributes and claims — Entra ID sends email, first name, and last name by default, but most enterprise applications expect additional attributes, such as role or department. Add these in the Attributes & Claims section.
6. For OIDC configuration, create an App registration in Entra ID, where you get the client_id and tenant_id. Create a client secret (or, better, a certificate, which is more secure than a static secret) and store it safely — for example, in Azure Key Vault, not in a config file.
7. Enter the redirect URI exactly as the application expects it, including the protocol (https) and any path. An incorrect redirect URI is the most common reason for a rejected OIDC login.
8. Set your scopes (e.g., openid, profile, email) and think through token lifetime — a shorter lifetime means better security, but more frequent re-authentication.
9. Enter the values you obtained into the application — client_id, client secret or certificate, tenant endpoint URL, and scope settings go into the application's config file or environment variables.
10. Test the login using the "Test" button in the Entra ID portal, which simulates a test user login and returns diagnostic information about any errors.

Expert tip: The most common source of errors at launch isn't a wrong certificate — it's incorrect attribute mapping or a wrong audience/issuer value. It's worth automating a check on this mapping as part of your CI/CD tests, rather than checking it manually with every change.

SSO for On-Premises Applications: Application Proxy and Seamless SSO

Not every application lives in the cloud. For on-premises systems running in your own data center, Entra ID offers two mechanisms that solve different problems.

Application Proxy works as a reverse proxy. An external user accesses a public URL, Entra ID verifies their identity, and only then routes the request into the internal network where the application actually runs. This means an on-premises application doesn't need to be exposed directly to the internet, significantly reducing the attack surface.

Seamless SSO solves a different problem: automatic login within a domain network, without re-entering a password, when a user is already logged into Windows. To work, it needs properly configured Microsoft Entra Connect and appropriate settings on client devices, or automatic login simply won't trigger.

In hybrid scenarios, one detail is critical and often overlooked:

• Seamless SSO creates a special computer account in your on-premises Active Directory called AZUREADSSOACC.
• This account holds a Kerberos key that actually powers automatic login for the entire organization.
• Microsoft recommends regularly rotating this key, typically every 30 days.
• Without key rotation, this single account becomes one of the biggest unnoticed vulnerabilities across the entire hybrid environment.

Operationally, the rule is: if you have a mix of on-premises and cloud applications, roll out Application Proxy and Seamless SSO together, not separately, since they solve complementary access and login problems.

Security Practices: MFA, Conditional Access, and Certificate Rotation

SSO centralizes access into a single entry point, which means Entra ID becomes the most critical resource in your entire infrastructure. This centralization calls for additional security layers, not less security, since a compromised SSO account opens the door to every connected application at once.

Key measures you shouldn't skip:

• Multi-factor authentication (MFA) should be mandatory for all users, not just administrators. Passwordless options, such as FIDO2 keys, significantly ease everyday SSO login in this context.
• Stricter policies for admin accounts — separate admin accounts without an email mailbox, limited session duration, mandatory conditional access.
• Conditional Access should require additional verification (step-up authentication) when logging in from a new location, an unknown device, or outside working hours.
• Certificate and key rotation on a predefined schedule, not only once they expire and logins start failing.
• Shortening token lifetime for sensitive applications, reducing the window in which a stolen token is useful.
• Integration with a SIEM system to monitor for login anomalies, and regular security audits of access permissions.

SSO isn't a substitute for MFA — it's its essential partner. As analyses of the relationship between these two mechanisms point out, SSO is part of a broader Zero Trust strategy, not a standalone security solution, and implementing one without the other leaves the system exposed.

How to Test SSO and Fix Common Errors

Testing SSO isn't a one-time event at launch — it's a repeating process with every change to configuration, certificates, or the application.

There are three basic diagnostic tools: the Test SSO feature within the Entra ID portal, which simulates a login and returns a structured error description; the SAML tracer browser extension, which displays the content of the XML assertion in real time; and your browser's developer console (Network tab), where you can see the actual HTTP requests and responses during login. Combining these three tools covers almost every error scenario, from a wrong URL to a missing attribute.

The most common errors and quick fixes:

1. Incorrect ACS/Reply URL — check that the value in Entra ID matches the value in the application character for character, including any trailing slash.
2. Clock skew — synchronize your server clock via NTP; SAML tokens typically allow only a few minutes of tolerance.
3. Invalid or expired certificate — check the expiration date and that the correct format is uploaded (Base64 vs. raw).
4. Claim mismatch — an attribute the application expects (e.g., role) isn't mapped in Entra ID, or is named differently than in the configuration.

Expert tip: When login fails without an obvious error, check the audience and issuer values in the token first. These two account for a surprisingly large share of "mysterious" rejections that developers otherwise chase down the wrong path.

What Actually Goes Wrong in SSO Projects

In practice, the same mistakes repeat over and over in SSO implementations, regardless of company size or industry. The most common is underestimating the attribute-mapping phase, since "just login" seems simple until the first rejected session hits production. Another common mistake is testing with an admin account, which hides problems that only appear for a regular user with limited permissions.

In external system integration projects, Moxy-web uses a phased approach that minimizes these mistakes: first, analyzing the existing environment and choosing a protocol, then a pilot rollout to a limited group of users, followed by a controlled rollout to the entire organization, and finally ongoing monitoring of logins and certificates. This sequence isn't bureaucratic overhead — it's the reason production errors get caught during the pilot phase, not on a Monday morning when the entire company is waiting to log in.

— Ziga

How Moxy-web Helps You Implement SSO Integration

Moxy-web is a sensible choice for businesses that want to get SSO right the first time, not through several rounds of fixes after launch. Our offering covers the entire integration cycle: analyzing your existing IT environment and choosing a protocol, configuring the SAML or OIDC connection, thorough testing before production, and ongoing maintenance and upgrades as applications or security requirements change. Instead of your development team spending weeks testing configurations alongside their regular work, a partner who already understands attribute mapping, certificate rotation, and conditional access settings takes on the project. For inquiries about SSO integration or a broader digital overhaul, visit Moxy-web and describe your current environment and the applications you use. An initial assessment reveals which protocol and approach best fit your infrastructure.

Sources

For a deeper dive into the technical details, the following sources are available:

• What is single sign-on
• Single sign-on (SSO): what it is, how it works

Frequently Asked Questions

What is SSO integration with Azure AD or Entra ID?

SSO integration with Microsoft Entra ID means a user logs in once and then accesses every connected application through the SAML, OIDC, or password-based protocol without re-entering their password.

Do I need SAML or OIDC for my application?

For older enterprise systems, use SAML 2.0; for modern web and mobile applications and APIs, OpenID Connect is generally the better choice, since it's easier to integrate with modern libraries.

How often should I rotate the Kerberos key for Seamless SSO?

Microsoft recommends rotating the AZUREADSSOACC account key at least every 30 days, since without regular rotation, this key becomes a vulnerable point across the entire hybrid environment.

Does SSO replace the need for MFA?

No. SSO and MFA complement each other within a Zero Trust strategy; centralized access through SSO actually increases the need for mandatory multi-factor authentication, rather than reducing it.

How does Moxy-web help with SSO implementation?

Moxy-web carries out an environment analysis, configures the SAML or OIDC connection, tests before launch, and provides ongoing maintenance of the integration, so the business doesn't have to take on the entire technical risk alone.

Recommended

• A Guide to Integrating External Systems for Businesses
• Examples of Web Tool Integration for Efficient Business Operations
• An Example of Integrating a Web Application with Logistics
• A Guide to Integrating Business Systems