How Applications Integrate

"The integration expired." The word integration hides a lot. It might mean a SAML single-sign-on setup, an app registration with a client secret, a background connection that calls an API, or an automatic user-provisioning job. The four behave differently, break differently, and are fixed by different people. This chapter names the objects that exist in Entra for any integration, then walks through the four common patterns so that you can say which one you're facing.

Why an Application Needs an Identity

Entra ID can only vouch for people to an application it knows about. Microsoft's documentation puts it this way: to delegate identity and access management to Entra ID, an application must be registered with a Microsoft Entra tenant. Registering creates an identity configuration for the application, which lets it integrate with Entra ID. That configuration is what people loosely call "the integration".

Two Objects: the Registration and the Enterprise Application

Two things appear in the portal for the same application, and they are easy to confuse. Microsoft explains them as a blueprint and an instance of it:

A registration also gives the application a globally unique application (client) ID. That is the value your system quotes when it asks Entra to sign someone in. Microsoft also notes that registering an application through the portal creates both the application object and a service principal in the home tenant automatically. (If you create the registration through Microsoft Graph, creating the service principal is a separate step.)

What the service principal types mean

The enterprise applications list can contain three kinds of service principal, per Microsoft:

• Application: the local instance of a registered application. This is the usual case for an integration.
• Managed identity: an identity for an Azure resource to connect to services without storing credentials. It has no associated application object.
• Legacy: represents an application created before app registrations existed, or through legacy experiences; it can only be used in the tenant where it was created.

Single-Tenant or Multitenant?

When an application is registered, its sign-in audience is chosen. This decides who can use it, and it determines where the pieces end up:

A single-tenant application has one service principal, in its home tenant. A multitenant application also has a service principal created in each tenant where a user or administrator from that tenant has consented to its use. Microsoft's example is a company, Adatum, that builds an "HR app" and registers it in its own tenant; Contoso and Fabrikam each use it, and each ends up with their own service principal, with the permissions their own administrator consented to.

Three typical arrangements, and who holds the keys

How the integration for your system was set up decides who can fix an expired credential. These are the common shapes; check with the people who built it which one applies:

The Four Integration Patterns

Microsoft describes several ways to connect an application to Entra for single sign-on: OpenID Connect and OAuth, SAML, password-based, linked, header-based and Integrated Windows Authentication, with the last three mainly for on-premises apps behind Application Proxy. For a cloud system like yours, four patterns matter, and between them they cover almost every "integration expired" ticket.

Pattern 1: OpenID Connect and OAuth 2.0 sign-in

Microsoft's guidance is to choose OpenID Connect and OAuth 2.0 if the application supports it. OpenID Connect extends OAuth 2.0 into an authentication protocol and issues an ID token to say who signed in. The application's configuration includes:

• its application (client) ID;
• the authority, a URL of the form https://login.microsoftonline.com/{tenant}/v2.0, where {tenant} is a tenant ID or domain name (for a single organisation), or organizations / common / consumers for wider audiences;
• one or more redirect URIs, the exact addresses in your system where Entra is allowed to send users back;
• the scopes it asks for (for sign-in, openid); and
• a credential (a client secret or a certificate) that your system uses to prove its own identity to Entra when it redeems the sign-in for tokens.

Each app registration has a public OpenID Connect metadata document, found under Entra ID > App registrations > (your app) > Endpoints, which lists the endpoints and signing keys that a library needs. The credential is the part that expires; the rest only breaks when somebody changes it.

Pattern 2: SAML single sign-on

SAML is an older but widely used protocol. Microsoft says to choose SAML for existing applications that don't use OpenID Connect or OAuth. It is configured on the enterprise application (Entra ID > Enterprise apps > All applications > (the app) > Single sign-on > SAML), by a Cloud Application Administrator, an Application Administrator, or the owner of the service principal. The settings that matter:

• Identifier (Entity ID): a name for your system, typically a URL specific to the application;
• Reply URL (Assertion Consumer Service URL): where Entra posts the signed assertion;
• Sign on URL: where users start from your side;
• the SAML certificate that signs the assertions, which your system must be given (the portal lets you download it); and
• the values your system needs from Entra: Login URL, Microsoft Entra Identifier and Logout URL.

Two facts from Microsoft's documentation matter for support. SAML SSO can only be configured on single-tenant or gallery applications; for a multitenant app, SAML is greyed out. And the signing certificate Entra creates when SAML is enabled is, by default, valid for three years (the lifetime can be customised), so the date has to be tracked and its renewal processed. Microsoft recommends naming an owner for it and a closely monitored mailing list for certificate notifications.

Pattern 3: API access with the application's own credentials

Sometimes your system acts by itself, with no user present: reading directory data, calling Microsoft Graph, syncing in the background. This is the OAuth 2.0 client credentials flow, which Microsoft describes as letting a confidential client use its own credentials, instead of impersonating a user, to call another service. The settings:

• the client ID, the tenant it operates against, and a credential: a client secret, a certificate, or a federated credential;
• the application permissions it has been given, which an administrator must grant (there is no user to consent), and which can be used only on that organisation's data; and
• the resource it asks for, with the scope written as the resource identifier followed by /.default.

The reply is an access token with an expires_in value in seconds. When it expires, the application asks again; Microsoft notes that this flow never issues refresh tokens, because the client's own credentials can be used to get a new access token whenever needed. This is a good illustration of the difference between "the credential expired" and "a token expired", which is the subject of Chapter 4.

Pattern 4: Provisioning with SCIM, where the direction reverses

In provisioning, Entra is the client and your system is the server. The Microsoft Entra provisioning service connects to a SCIM 2.0 endpoint provided by the application and uses it to create, update and remove users, and for some apps groups. The channel is encrypted with HTTPS using TLS 1.2. For this to work Entra needs credentials to connect to your system's user management API, which an administrator enters when setting up provisioning, and which can be tested from the portal.

Which Pattern Are You Looking At?

Before you open any portal, a few questions usually settle it. Ask the person who reports the problem, or look at your own product's integration screen:

Ownership Summary

The "where to read the evidence" row is a preview; Chapter 7 covers the logs in detail and checks which tab and which role each needs.

Hands-On Exercises

All three use fictional organisations and invented values. Never use real secrets or tenant details in practice notes.