Microsoft Entra ID single sign-on in a web application

Single sign-on with Microsoft Entra ID (formerly Azure Active Directory) lets your staff sign in to a business application with the same account they use for Microsoft 365. The application is registered in your company’s tenant, which is its Microsoft 365 user directory. Sign-in uses the OpenID Connect standard: the application receives a signed token from Microsoft that says who the user is and which roles they have.

As a result, you do not store any passwords. Multi-factor authentication (MFA, for example a code on a phone), Conditional Access and account blocking work in the application exactly as they do in email or Teams. We use this kind of sign-in in our internal tools.

What your company gains from Microsoft 365 sign-in

• The application stores no passwords. There is nothing to hash, reset or leak from your database.
• The MFA and Conditional Access policies you set in Entra ID also cover your application. Conditional Access requires a Microsoft Entra ID P1 licence, which is included in Microsoft 365 Business Premium, among others (Conditional Access licensing on Microsoft Learn, as of 13 November 2026).
• When someone leaves, you deal with it in Entra ID. Blocking the account there cuts off access to every application that uses it, so nobody has to track down and disable a separate account in each system. One caveat: an application with long sessions will let the user in until the session expires, so choose the session length deliberately.
• There is a single list of users. Your IT team manages access in a console they already know, instead of learning yet another application.

Conetso Software is the software development team of Conetso Group, based in Lublin, Poland. How to set up MFA and Conditional Access in Microsoft 365 itself is covered on the Conetso Group cybersecurity page.

One organisation or many?

When you register the application, you choose who can sign in to it. This decision affects the code, so make it at the start:

Option	Who can sign in	When to choose it
Single tenant	Users and guests in your tenant	An internal company application. Microsoft recommends this option for most applications
Multitenant	Work accounts from any Entra ID tenant	A SaaS application for many companies, each with its own Microsoft 365
Multitenant and personal accounts	Also personal Microsoft accounts such as Outlook.com	Rarely needed in business applications

Source: registering an application on Microsoft Learn and Tenancy in Microsoft Entra ID, as of 13 November 2026.

A multitenant application also has to handle admin consent from each organisation and tokens issued by different tenants. If you are building a tool for one company, do not add that complexity just in case.

The sign-in flow: authorization code with PKCE

For web applications, Microsoft recommends the authorization code flow with PKCE (Proof Key for Code Exchange). The implicit grant is an older approach. Do not enable it in new applications unless a specific scenario requires it.

In practice, you do not implement the protocol yourself. You use Microsoft’s libraries (MSAL, or Microsoft.Identity.Web for .NET) or a proven library for your framework. The library checks the token’s signature, issuer, audience and expiry. Hand-written token validation easily skips one of these checks, and then the application accepts a token it should reject.

App roles or groups?

Signing in tells the application who the user is. It also needs to know what that user is allowed to do. Entra ID offers two ways:

• App roles are defined in the application registration, for example “Employee” and “Administrator”. They appear in the token’s roles claim. Because they belong to the application, they keep working when someone renames a group in the company.
• Groups arrive in the groups claim as group IDs from the tenant. When a user belongs to a very large number of groups, Entra ID omits the groups from the token, and the application has to fetch them separately.

For business applications, we recommend app roles. An administrator assigns users or whole groups to them. Assigning groups to roles requires an Entra ID P1 licence (app roles on Microsoft Learn, as of 13 November 2026). The application must also handle a token with no role at all: a user without a role should only see a message that they have no access.

Keep in mind that a role in the token only gets the user through the door. Checking access to specific data, for example whether staff members see only their own orders, stays with the application.

Access for selected users only

By default, every user in the tenant can sign in to a single-tenant application. If the application is only for the accounts team, turn on “Assignment required?” in the enterprise application settings. Only the people and groups assigned to the application will then receive a token.

One trap from Microsoft’s documentation: the assignment requirement does not apply to accounts with the Global Administrator role. So test access with an ordinary account that has no admin roles (restricting an app to a set of users on Microsoft Learn, as of 13 November 2026).

Certificate or client secret?

In production, Microsoft recommends certificates or federated credentials and treats client secrets as something for developers working locally. Every web application that signs users in on the server side or calls Microsoft APIs (application programming interfaces) needs a credential of its own. You can choose a client secret (a string of characters), a certificate or federated credentials.

A secret can be valid for at most 24 months, and Microsoft recommends less than 12 (application credentials on Microsoft Learn, as of 13 November 2026).

Whichever you choose, watch two things:

1. Keep the credential out of the code, in a secrets management service, and never in the repository.
2. Track the expiry date. An expired secret or certificate stops sign-in overnight, so the renewal date has to be in someone’s calendar or in your monitoring.

Checklist before go-live

• Application registered in the company tenant with the right option (single tenant or multitenant).
• Redirect URIs on HTTPS only, and only those the application actually uses.
• App roles defined, including a basic role without elevated permissions.
• “Assignment required?” turned on if the application is not for everyone.
• Certificate or federated credential in production, with the expiry date in monitoring.
• Access tested with an ordinary account that has no admin roles.
• Tenant MFA and Conditional Access policies cover the new application.

Microsoft 365 can also trigger automations in your application, as described in our article on HubSpot webhooks and Microsoft 365 onboarding. We build Microsoft 365 integrations as part of our system integration service.

We can review your tenant configuration and plan the integration with the Conetso Group security team. Send us a short description of your application.