How to integrate Azure AD (Microsoft Entra ID) with cloud and on-premises applications: complete guide to SSO, OAuth, SAML, and Application Proxy

Quick summary: integrate Azure AD with applications in 12 points

1. Start with inventory: what applications exist (SaaS, custom apps, APIs, on-premises), who uses them, and what risk/criticality they have.
2. Choose the right pattern: OIDC/OAuth for modern apps and APIs; SAML for many enterprise SaaS apps; Application Proxy for internal web apps.
3. Understand key objects: App registration (definition) vs Enterprise application / service principal (tenant instance + assignments).
4. SSO first: SSO reduces support load, improves user experience, and enables stronger security without breaking access.
5. Provisioning: if supported, enable SCIM for automated joiner/mover/leaver processes and identity consistency.
6. Roles and groups: assign access by groups and/or app roles, avoiding per-user permissions in critical applications.
7. Govern consent: restrict app consent and define an approval workflow (prevents unreviewed access to data).
8. On-premises without permanent VPN: publish internal apps with Entra Application Proxy and control access with Conditional Access.
9. Hybrid done right: if there is on-premises Active Directory, define sync (Entra Connect Sync or Cloud Sync) and the sign-in method.
10. Security applied to everyone: MFA, Conditional Access by risk/location/device, and blocking legacy authentication where possible.
11. Operations and auditing: sign-in logs, audit logs, alerts, and procedures for incidents related to tokens, claims, and certificates.
12. Scale without chaos: naming, templates, automation (IaC), secret rotation, and periodic access reviews (Access Reviews / PIM).

Introduction: what “integrating Azure AD” (Microsoft Entra ID) means in 2026

Context summary: integrating Azure AD is no longer “adding a login.” It is defining a complete access model: how authentication works, how authorization is enforced, how access is logged, how it is revoked, and how it is protected for each application.

In day-to-day work, “integrating Azure AD with applications” usually answers very specific questions: Can the customer sign in with the corporate account across all applications?, Can MFA and Conditional Access be applied without modifying every system?, Can onboarding/offboarding be automated?, Can it be verified who accessed what and when?

Microsoft renamed Azure AD to Microsoft Entra ID. The name matters little to end users, but it helps identify the current documentation and capabilities. Practically, Entra ID is the central point for:

• Authentication (SSO): one sign-in across multiple apps.
• Authorization: access by groups/roles, token claims, and user assignment to applications.
• Security: MFA, Conditional Access, session controls, and risk signals.
• Governance: access reviews, consent control, privileged roles, and auditing.

This guide focuses on a practical approach: how to choose the right pattern for each application (cloud or on-premises), how to implement it without turning it into an “endless project,” and how to leave it ready to operate and scale.

1. Pre-decisions: identity, domains, licensing, and responsibilities

Section summary: before touching a single application, it helps to agree on who decides what, which security baseline is required, and how access will be governed from now on.

1.1 Tenant, domains, and users: where integration begins

In most organizations, a Microsoft 365 tenant already exists. Still, it is worth confirming the items that later block integrations:

• Verified domains: avoids scenarios where users end up with UPNs that do not match email addresses and SSO becomes harder.
• Identity model: cloud-only accounts, hybrid accounts with on-premises Active Directory, or a mix (common after mergers).
• “Technical” accounts: decide whether they are allowed or whether everything must be tied to a named identity.

1.2 Roles and responsibilities (a realistic RACI)

Integrating applications is not just an IT task. The business side must be involved because it decides who needs access, which processes change, and what controls are acceptable. A common split:

1.3 Licensing and “what can be done”

Many basic integrations (SAML/OIDC SSO, app registrations, assigning to users/groups) are possible with baseline licensing, but some advanced controls (for example, advanced governance, certain reviews, or risk signals) depend on the plan. The operational recommendation is not to block phase 1 due to licensing: start with SSO + group assignment + logs, and harden later with the right plan.

Bridge to the next section: with these minimal agreements, the next step is to inventory applications and assign the most reasonable integration pattern to each one.

2. Application inventory: cloud, on-premises, APIs, and dependencies

Section summary: you do not “integrate Azure AD with everything at once.” You integrate one application at a time, but with a clear map that avoids duplicate effort.

2.1 Practical classification (the one that helps decisions)

• SaaS (cloud): Salesforce, ServiceNow, Dropbox, Google Workspace, etc. Usually SAML or OIDC.
• Custom applications: internal web apps, SPAs, mobile apps, and APIs. Usually OIDC/OAuth 2.0.
• On-premises web apps: intranets, ERPs on IIS/Apache, internal tools. Typical Application Proxy candidates.
• Legacy or non-web: apps expecting direct LDAP/Kerberos, thick clients, RDP, etc. Requires a specific strategy.

2.2 What data to capture for each application

2.3 Prioritize to avoid the “infinite project”

An order that usually works: (1) apps with the most users, (2) apps with the highest risk (sensitive data), (3) apps that generate the most tickets (password resets, access requests, guest invites), (4) on-premises apps that currently require an always-on VPN.

Bridge to the next section: with inventory done, the next common blocker is conceptual: understanding what is created in Entra ID when an app is “integrated” and what is managed afterward.

3. Key concepts: App registration, Enterprise application, and Service Principal

Section summary: an orderly integration depends on knowing “which object is which” and where users, permissions, and policies are actually applied.

3.1 App registration: the definition

The App registration defines the application from an identity perspective: redirect URIs, certificates/secrets, API permissions (for example Microsoft Graph), scopes, and whether it is single-tenant or multi-tenant. This is typically the starting point for custom applications and APIs.

3.2 Enterprise application / Service principal: the “instance” in the tenant

The Enterprise application (service principal) represents the real presence of that app inside the tenant: this is where users and groups are assigned, SSO (SAML/OIDC) is configured, provisioning (SCIM) is enabled, and access-related policies are applied. This distinction prevents classic mistakes such as configuring everything correctly in the App registration but assigning nobody to the Enterprise application.

3.3 Consent: the sensitive area many teams leave ungoverned

With OAuth/OIDC integrations, consent appears: which permissions are granted to the application to act on data. If every user can consent to applications freely, the organization loses traceability and increases the risk of apps with excessive permissions. This is why it is best to define: when user consent is allowed, when admin consent is required, and how requests are submitted.

Bridge to the next section: with these concepts clear, it is possible to address the most visible and appreciated improvement: SSO for SaaS applications.

4. SSO for cloud applications (SaaS): integrate Azure AD with SAML and OpenID Connect

Section summary: for SaaS, the most common pattern is SSO with SAML (very frequent) or OIDC (increasingly common). The goal is that users sign in with corporate accounts and security is enforced from Entra ID.

4.1 SAML vs OpenID Connect: how to decide without endless debate

• SAML 2.0: widely used in enterprise SaaS; works very well for browser-based SSO.
• OpenID Connect (on OAuth 2.0): more natural for modern applications, mobile, and SPAs; JWT tokens and modern flows.

If the application supports both, review the use case: for a corporate web portal, SAML may be sufficient; for a modern app with an API and mobile clients, OIDC usually fits better.

4.2 Typical SaaS integration flow using the gallery

1. Add the application from the Enterprise applications gallery.
2. Configure SSO (SAML or OIDC) using the vendor values (ACS/Entity ID or Redirect URI).
3. Map claims (for example, email, UPN, groups) based on what the app requires.
4. Assign users/groups and test with a pilot.
5. Enable Conditional Access specific to that app if needed (MFA, device, location).

4.3 Claims, groups, and roles: where many integrations get stuck

In practice, the SaaS vendor typically needs a stable identifier (email/UPN) and sometimes roles. In Entra ID, there are two common approaches:

• Groups as a claim: send group membership (with care for size and limits).
• App roles: define roles (for example “Admin,” “Editor,” “Read-only”) and assign users/groups to those roles inside the Enterprise application.

Bridge to the next section: SSO solves sign-in, but many organizations also want automated onboarding/offboarding. That is where SCIM comes in.

5. Provisioning users and groups: SCIM, synchronization, and lifecycle

Section summary: provisioning removes manual work and reduces risk: when a user leaves the company, access should be removed without relying on email chains.

5.1 What “good provisioning” means

The goal is not only to create users. It is to align the full lifecycle: join (create account and permissions), move (department, role, group changes), leave (revoke access, disable account, invalidate tokens).

5.2 SCIM: the most common provisioning standard for SaaS

When a SaaS supports SCIM, Entra ID can push user and group changes automatically. Practically, this enables:

• Create and disable accounts without manual intervention.
• Keep attributes consistent (name, email, department).
• Manage groups/roles from Entra ID (depending on vendor capabilities).

5.3 What typically breaks provisioning (and how to avoid it)

• Inconsistent attributes: if the “source of truth” is unclear, provisioning becomes unpredictable.
• Different primary identifier: some SaaS use email; others use an internal ID. Lock the identifier in from the start.
• Duplicate role models: if the SaaS supports local roles and also roles from SCIM, decide what is authoritative.

A reasonable approach is: start with user provisioning (join/leave) and, once stable, expand to groups/roles.

Bridge to the next section: once SaaS is covered (SSO + provisioning), the next block is integrating custom applications: portals, APIs, and SPAs.

6. Integrate custom applications: OpenID Connect and OAuth 2.0 with Microsoft identity platform

Section summary: for custom applications, the goal is to use OIDC/OAuth with supported libraries (MSAL) and avoid “homegrown” authentication that becomes difficult to secure later.

6.1 Recommended pattern (general)

• Server-side web app: Authorization Code Flow (with PKCE when applicable).
• SPA (single-page app): Authorization Code Flow + PKCE (avoid the legacy implicit flow).
• Mobile app: Authorization Code Flow + PKCE.
• Protected API: validate JWTs, scopes/roles, and enforce authorization based on claims.

6.2 App registration: what to configure so you do not have to redo it

In a typical App registration, review:

• Redirect URIs per environment (dev/test/prod).
• Scopes and permissions (delegated for user-based access, application permissions for daemon apps).
• Certificates & secrets (prefer certificates if the app supports it and operations maturity exists).
• Token claims required: roles, groups (if needed), email/UPN, tenant ID.

6.3 Conceptual example: an API with roles (without infinite edge cases)

A common practice: define app roles in the application (for example Api.Read, Api.Write), assign those roles to groups (not individual users), and validate in the API whether the token includes the required role. This creates a maintainable model: business manages group membership, IT maintains the app.

If token.roles includes "Api.Write" → allow write
If not → return 403 (Forbidden)

6.4 MSAL: why it matters

MSAL (Microsoft Authentication Library) prevents building token handling, caching, refresh logic, and identity-provider compatibility manually. In real projects, this reduces incidents such as “weird sessions,” failed renewals, and inconsistent behavior across browsers.

Bridge to the next section: many integrations get stuck when “the API” and service-to-service access appear. That is where client credentials, on-behalf-of, and managed identities come in.

7. Integrate APIs: scopes, app roles, client credentials, and on-behalf-of

Section summary: a well-integrated API clearly distinguishes “a user calls” from “a service calls,” and applies different controls in each case.

7.1 Delegated vs application permissions (the difference that changes the model)

• Delegated: the app acts on behalf of a user. Ideal for portals and front-ends.
• Application: the app acts as itself (daemon/service). Ideal for batch integrations and backend-to-backend.

7.2 Client Credentials Flow: service-to-service

When a service must call an API without a user, the typical pattern is client credentials. The operational recommendation is: use a certificate or, if on Azure, consider Managed Identity to reduce expiring secrets.

7.3 On-behalf-of (OBO): when there is frontend + backend

In modern architectures, a frontend receives a token and calls a backend that in turn calls another API. The on-behalf-of pattern lets the backend exchange the token and obtain another token for the next API while keeping the user context. This is relevant for auditing, permission control, and traceability.

7.4 Microsoft Graph: a common integration (and governance)

Many apps eventually request permissions to Microsoft Graph (users, groups, calendar, mail, files). Here it is especially important to be careful with:

• Least privilege principle: request only what is needed.
• Managed consent: avoid broad permissions granted without review.
• Auditing: know which app has access to what and why.

Bridge to the next section: once cloud is integrated, the big leap for many companies is on-premises: how to provide secure access without exposing the network or relying on always-active VPNs.

8. Integrate on-premises applications: Microsoft Entra Application Proxy to publish internal apps

Section summary: Application Proxy publishes internal web applications to the Internet without opening inbound ports to the server, enforcing Entra ID authentication and policies such as Conditional Access.

8.1 What Application Proxy solves (business + security)

• Access internal applications without a permanent VPN just to “open a portal.”
• Apply MFA and Conditional Access to apps that previously could not support them.
• Reduce exposure: the connector makes an outbound connection to Microsoft; the server is not directly published.

8.2 High-level architecture (to understand where risk “lives”)

The typical pattern:

1. Install a Microsoft Entra private network connector in the internal network or a controlled zone.
2. The connector establishes a secure outbound connection to the service.
3. The user accesses a published URL and authenticates in Entra ID.
4. After authentication and policy evaluation, the request is routed to the internal resource.

8.3 Pre-authentication and user experience

In most scenarios, Entra ID pre-authentication is recommended. The user sees the corporate sign-in (with MFA if required) and then enters the app. This enables Conditional Access even if the internal application lacks modern capabilities.

Bridge to the next section: Application Proxy solves access, but sometimes the customer needs true SSO to the internal app using Kerberos/IWA. That requires careful design to avoid a cascade of incidents.

9. SSO to on-premises with Kerberos / IWA: when it applies and how to avoid surprises

Section summary: “real” SSO to internal apps often involves Kerberos (KCD). It works very well when designed properly, but it requires clear prerequisites.

9.1 When Kerberos Constrained Delegation (KCD) makes sense

KCD is typically used when:

• The on-premises application uses Integrated Windows Authentication and it should not be changed.
• The customer wants to avoid double authentication (sign in to the proxy and then the app prompts again).
• The experience should resemble “being in the office” without opening the network.

9.2 Typical risks if not designed carefully

• Misconfigured SPNs and name resolution issues.
• Domain dependency: devices not domain-joined or poorly defined hybrid scenarios.
• Intermittent incidents: perceived as “it works sometimes,” consuming significant support time.

9.3 Practical approach to reduce incidents

1. Validate prerequisites (domain, name resolution, SPNs, service account).
2. Run a small pilot (users + a non-critical app if possible).
3. Document a clear diagnosis guide: which logs to check and in what order.

Bridge to the next section: for cloud and on-premises to share identity without duplicating users, hybrid integration with Active Directory is needed: sync and SSO.

10. Hybrid integration with Active Directory: Entra Connect Sync, Cloud Sync, and SSO

Section summary: if on-premises Active Directory exists, hybrid identity defines the daily user experience: one user, one password experience, and a reliable joiner/mover/leaver process.

10.1 What hybrid aims for (without idealizing)

• Single identity: the user does not “have two accounts.”
• Reliable onboarding/offboarding: changes in AD reflect in Entra ID.
• Consistent SSO: fewer prompts, fewer tickets.

10.2 Entra Connect Sync vs Cloud Sync

In classic environments, Entra Connect Sync has been the baseline. Cloud Sync introduces an agent-based model managed from the cloud. The choice depends on topology, requirements, and future strategy.

10.3 Sign-in methods (operational concept)

In hybrid setups, the customer usually chooses a primary sign-in method (for example, password hash sync or pass-through authentication) and, if applicable, defines a fallback. The decision should align with:

• Availability requirements (what happens if the on-premises part goes down).
• Compliance and auditing requirements.
• Operational capacity (what can be maintained securely).

10.4 SSO: Seamless SSO and PRT (device reality)

For a smooth experience, it is essential to understand device types: domain-joined, Entra joined, hybrid joined, registered. A well-closed hybrid deployment usually reduces repeated prompts and makes it feasible to strengthen security with less friction.

Bridge to the next section: with identities integrated, the natural next step is security: MFA, Conditional Access, and session control to reduce risk without blocking operations.

11. Security in Azure AD integrations: MFA, Conditional Access, and session controls

Section summary: identity integration is the lever that improves security without “different controls in every application.”

11.1 MFA: the minimum baseline for corporate applications

In practice, the question is not “whether MFA,” but “how MFA is applied without punishing users.” This is why MFA is combined with signals (risk, location, device) and app-specific policies: not all apps carry the same risk.

11.2 Conditional Access: context-based control

Conditional Access enforces conditions before allowing access:

• User/Group: by role or criticality.
• Application: app-specific policies (crucial for sensitive apps).
• Location and risk: block anomalous access.
• Device: require compliant devices for sensitive data.

11.3 Session controls (when data is sensitive)

For critical data, it is not only “who gets in,” but also “what can be done” during the session: downloads, persistence, and session behavior based on policy. It is not always required, but when it is, implement in waves and validate with business stakeholders.

Bridge to the next section: technical security must be backed by governance: controlling consent, reviewing access, and reducing privilege through repeatable processes.

12. Governance and control: consent, Access Reviews, PIM, and auditing

Section summary: without governance, the initial state may look good but degrades over time: new apps without review, accumulated permissions, and overly broad privileged roles.

12.1 Consent governance (apps requesting data permissions)

Customers often benefit from a simple approach:

• Allow user consent only for low-risk permissions (if the organization decides to allow it).
• Require admin consent for sensitive permissions (mail read, broad user read, files, etc.).
• Establish a request workflow: who approves, by which criteria, and how decisions are recorded.

12.2 Access Reviews: keep access aligned with reality

Access Reviews periodically validate who should keep access, especially for:

• Critical applications (finance, HR, legal).
• High-privilege groups.
• External collaboration (guest accounts).

12.3 PIM: privileged access only when needed

Privileged Identity Management (PIM) reduces the risk of permanent privileged accounts. For sensitive operations, it enables “just in time” role activation, with approvals or stronger MFA, and full auditability.

12.4 Auditing: what is needed to investigate and prove control

Beyond troubleshooting, logs help to: detect anomalous access, respond to audits, and justify security decisions. In multi-application integrations, centralized auditing is one of the most valuable benefits.

Bridge to the next section: for sustainability, the team must operate the model: diagnose token/claim/certificate issues and keep secrets and certificates rotating on time.

13. Operations and troubleshooting: tokens, claims, certificates, and logs

Section summary: most real incidents repeat: incorrect redirect URI, server clock issues, missing expected claim, expired certificate, or missing Enterprise application assignment.

13.1 Typical errors (and why they happen)

• Incorrect redirect URI: common when separating dev/test/prod or after domain changes.
• Incomplete consent: the app requests a permission the tenant has not granted.
• Misaligned claims: the app expects email but upn is sent (or vice versa).
• App assignment: user not assigned to the Enterprise application (if assignment is required).
• Expired secret/certificate: a classic issue when no rotation procedure exists.

13.2 Where to look first (practical order)

1. Sign-in logs: exact error and flow details.
2. Enterprise application: assignment, SSO configuration, provisioning.
3. App registration: redirect URIs, permissions, credentials, manifest.
4. Conditional Access: whether a policy blocks or requires something not satisfied.

1) Is the user assigned to the application?
2) Does the redirect URI match exactly (including https and path)?
3) Does the token include the claim/role the app validates?
4) Is there a Conditional Access policy requiring compliant device/MFA that is not satisfied?
5) Is the secret or certificate still valid?

Bridge to the next section: the most delicate operational point is secret/certificate management. If it is not governed, the integration “works” until the day a secret expires.

14. Secrets and certificates: rotation, Azure Key Vault, and best practices

Section summary: security is not only MFA. An app with an exposed or expired secret becomes both a risk and an outage. Credential discipline is part of success.

14.1 Secrets vs certificates: practical view

• Secrets (client secret): easy to implement, but require rotation and strict protection.
• Certificates: more robust when operated well; require lifecycle management (issuance, deployment, renewal).

14.2 Rotation: what is defined before an incident happens

A minimum procedure:

• Inventory apps with credentials (which app, which type, expiration).
• Rotation window and ownership (who executes, who validates).
• Controlled post-rotation test (login + API calls).

14.3 Key Vault and Managed Identities (when applicable)

When the application runs in Azure, it is common to reduce secrets stored in configuration. Two approaches:

• Azure Key Vault: store secrets and certificates with access control and auditing.
• Managed Identity: avoid explicit credentials for Azure resources when the scenario fits.

Bridge to the next section: with operations under control, the challenge becomes scale: more applications, more teams, more changes. Scaling requires templates, naming, and automation.

15. Scale Azure AD integrations: templates, automation, and an application catalog

Section summary: integrating 5 applications can be artisanal; integrating 50 requires a system: catalog, standards, and automation.

15.1 Elements that help scale without losing control

• Naming convention: apps, environments, service principals, groups, and roles.
• Templates: OIDC pattern for custom apps, SAML pattern for SaaS, Proxy pattern for on-premises.
• Standard groups: at least “App-XYZ-Users”, “App-XYZ-Admins” for clear assignment.
• Minimum documentation: per app record (owner, support, risks, applied CA, provisioning).

15.2 Automation: when it is worth it

Automation makes the most sense when:

• The same pattern repeats across many apps (for example, similar internal apps).
• Consistency across environments (dev/test/prod) is needed without “missed steps.”
• Change traceability is required (who changed what and when).

App registration:   APP-CRM-PORTAL-PROD
Enterprise app:     ENT-CRM-PORTAL-PROD
Groups:             GRP-CRM-PORTAL-USERS / GRP-CRM-PORTAL-ADMINS
Roles (app roles):  CRM.Reader / CRM.Admin

Bridge to the next section: to turn all this into action, the most useful output is usually a checklist: what to review in design, what to validate in deployment, and what to maintain in operations.

16. Operational checklists for integrating Azure AD (Entra ID) with applications

16.1 Design checklist (before configuration)

• Application inventory and classification (SaaS, custom, API, on-premises).
• Integration pattern per app (SAML/OIDC/Proxy) and rationale.
• Business owner and technical owner per application.
• Access model: groups/roles, assignment required yes/no.
• Provisioning decision (SCIM) when supported by the vendor.
• Security policies: MFA/CA by criticality (not “one policy for everything”).
• Operations plan: logs, alerts, credential rotation, support.

16.2 Deployment checklist (by waves)

• Create/validate App registration and Enterprise application.
• Configure SSO (SAML/OIDC) and the claims expected by the app.
• Assign groups (pilot first) and validate end-to-end access.
• Enable provisioning (if applicable) and verify join/leave processes.
• Apply Conditional Access and validate it does not break operations.
• Document results and a simple rollback procedure.

16.3 Operations checklist (monthly/quarterly)

• Review access to critical applications (Access Reviews when applicable).
• Review guests and external access (if present).
• Check secret/certificate expirations and rotate on time.
• Review anomalous access logs and recurring incidents.
• Verify the app catalog reflects reality (owners, support, applied CA).

17. Frequently asked questions (FAQ) about integrating Azure AD with applications

18. Official resources and recommended links

• Microsoft Entra ID documentation
• Microsoft identity platform (v2)
• MSAL (Microsoft Authentication Library)
• Hybrid identity: Entra ID + Active Directory
• Seamless SSO (hybrid)
• Microsoft Entra Application Proxy overview
• Private network connectors (configuration)
• Kerberos Constrained Delegation (KCD) SSO
• Conditional Access overview
• Access Reviews overview
• Privileged Identity Management (PIM)
• SCIM provisioning: users and groups
• Microsoft Graph permissions overview

Related MSAdvance services: Identity & access / Security & Compliance, Modern Workplace, and Services catalog.

19. Conclusion: how to integrate Azure AD with cloud and on-premises apps without losing control

Final takeaway: success is not “turning on SSO.” It is choosing the right pattern per application, governing access via groups/roles, automating joiner/mover/leaver where possible, and enforcing security and auditability from Entra ID.

Integrating Azure AD (Microsoft Entra ID) with cloud and on-premises applications works when it stands on four pillars: model (inventory + per-app pattern), security (MFA + Conditional Access + session control when applicable), governance (consent, reviews, privilege control), and operations (logs, credential rotation, support).

As next steps, it is usually useful to:

• Complete the inventory and prioritize 5–10 applications for a first wave.
• Define a minimum standard: naming, groups, roles, and per-app documentation.
• Roll out SSO and Conditional Access by criticality (pilot + waves).
• Enable SCIM where possible to automate onboarding and offboarding.
• Design on-premises publishing with Application Proxy to reduce VPN dependency.