Entra ID Single Sign-On: One Password to Rule Them All (Well, Most of Them)

Hi there! It's BOB again.

Let me guess. Your users have a password for email, a password for the HR system, a password for the expense tool, a password for the ticketing system, and a sticky note under the keyboard holding all of them together.

Don't worry. We've all been there. Today we're going to talk about single sign-on, or SSO. It's one of the nicest things you can do for your users and your security team at the same time. That doesn't happen very often, so let's enjoy it.

So… What Is SSO?

Single sign-on means a user signs in once and then gets into all the apps they're allowed to use without typing another password.

In the Microsoft world, the thing doing the signing-in is Microsoft Entra ID (the service formerly known as Azure Active Directory. Yes, it got renamed. Yes, half the documentation still says Azure AD. No, I don't know why either).

Here's the big idea:

• Entra ID is the identity provider (IdP). It knows who you are, checks your password, asks for MFA, and decides whether you're allowed in.
• The app (Salesforce, ServiceNow, your homegrown web app, whatever) is the service provider (SP). It trusts Entra ID to vouch for you.
• When you sign in, Entra ID hands the app a signed token that basically says: "This is Jeff. I checked. He's fine. Probably."

The app never sees the password. It just sees the token, checks Entra ID's signature, and lets you in.

Why Should I Care?

That offboarding row is the one that makes auditors smile. Auditors smiling is rare. Treasure it.

The Different Flavors of SSO

When you add an app in Entra ID and open its Single sign-on page, you'll be asked to pick a method. Here's the menu:

💡 BOB's tip: If the app supports SAML or OIDC, use it. Password-based SSO is fine for the stragglers, but it's still a password, just one your users don't have to remember.

Before You Start

You'll need a few things:

• A role that can manage apps. Cloud Application Administrator or Application Administrator is enough. You don't need Global Administrator for this, and you shouldn't be using it for everyday work anyway. (I'm looking at you.)
• Admin access to the app's side. SSO is a two-way handshake. You'll be pasting values into the app's settings too.
• Licensing: basic SSO to enterprise apps works on the free tier. Group-based assignment and Conditional Access need Entra ID P1 (which comes with Microsoft 365 Business Premium and E3/E5).

Setting Up a SAML App (The Most Common One)

Let's walk through it. I'll use a "gallery" app as the example. The app gallery is Microsoft's catalog of thousands of pre-configured apps, and it saves you a lot of typing.

1. Add the app

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Entra ID → Enterprise apps → All applications.
3. Click New application.
4. Search the gallery for your app. Found it? Click it, give it a name, and click Create.
   • Not in the gallery? Click Create your own application and choose Integrate any other application you don't find in the gallery (Non-gallery).

2. Pick SAML

Open your new app, go to Single sign-on, and choose SAML. You'll see a page with numbered boxes. Don't panic, there are only a few that matter.

3. Basic SAML Configuration

This is where Entra ID and the app agree on who's who. The app's vendor documentation will tell you exactly what to put here.

Gallery apps often fill in some of these for you. How thoughtful!

4. Attributes & Claims

Claims are the facts about the user that Entra ID puts in the token: email, first name, last name, and so on.

The most important one is the Unique User Identifier (Name ID). By default it's the user's UPN (user.userprincipalname), like jeff@contoso.com. The app uses this to figure out which of its accounts belongs to the person signing in.

💡 BOB's tip: The Name ID must match what the app has on file for that user. If the app knows Jeff as jeff.rainey@contoso.com and Entra ID sends jeff@contoso.com, the app will politely (or not so politely) refuse. This is the #1 cause of "SSO is set up but it doesn't work."

5. SAML Certificates

Entra ID signs every token with a certificate so the app knows it's genuine. In this box you'll find:

• App Federation Metadata Url: the easiest option, if the app can read it. Paste the URL, and the app pulls everything it needs.
• Federation Metadata XML or Certificate (Base64): download and upload to the app if it wants a file.

⚠️ Heads up: These signing certificates expire (three years by default). Entra ID can email you before that happens. Add a notification email address in this box so you hear about it before the CEO can't get into the expense app.

6. Set up the app's side

Box 4 on the page (Set up [app name]) lists the values the app needs from Entra ID:

• Login URL
• Microsoft Entra Identifier
• Logout URL

Copy those into the app's SSO settings, along with the certificate or metadata from step 5.

7. Assign users

Go to Users and groups → Add user/group and pick who should have access.

Under Properties, the Assignment required? setting controls whether only assigned people can sign in. Leave it on Yes unless you have a good reason not to.

8. Test it!

Back on the Single sign-on page, there's a Test button at the bottom. Click it, and Entra ID will try a sign-in and tell you what went wrong if it fails. It's surprisingly helpful. More helpful than Clippy, anyway.

Setting Up an OpenID Connect App

If you (or your developers) are building an app, you'll usually use OIDC through an app registration instead.

1. Go to Entra ID → App registrations → New registration.
2. Give it a name and pick who can sign in. Accounts in this organizational directory only is the usual answer.
3. Add a Redirect URI: the address your app listens on for the sign-in response (like https://myapp.contoso.com/signin-oidc).
4. Click Register.

Your app now needs three things from the Overview page:

Most frameworks (ASP.NET, Node, Python, you name it) also want the discovery URL, which tells them where everything else lives:

https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration

⚠️ Heads up: Client secrets expire too, and they're a secret. Store them in something like Azure Key Vault, not in your source code. Certificates are even better than secrets. Future you will be grateful.

Registering an app also creates a matching enterprise app automatically. That's where you assign users and turn on Assignment required?, just like with SAML.

Where Do Users Find Their Apps?

Your users get a lovely little launch pad at My Apps (myapps.microsoft.com). Every app they're assigned shows up as a tile. Click a tile, and they're in. No password. Like magic. Very well-documented magic.

Apps also show up in the Microsoft 365 app launcher (that waffle icon in the corner).

What About Signing In to Windows?

Good question! SSO isn't just for web apps.

• Entra-joined and hybrid-joined Windows devices get a Primary Refresh Token (PRT) when the user signs in to Windows. That token quietly signs them into Microsoft 365 and their Entra apps in Edge and Chrome. Sign into the laptop, and you're signed into everything.
• Older domain-joined devices can use Seamless SSO, which works with Entra Connect and on-premises Active Directory. That's a whole other article. Good thing I wrote one!

Making It Safer: Conditional Access

Once your apps are behind Entra ID, you can wrap them in Conditional Access policies (Entra ID P1 or higher). For example:

• Require MFA for every app.
• Only allow the payroll app from compliant, company-managed devices.
• Block sign-ins from countries where you have no employees.

This is the real superpower of SSO: one front door, with one very good lock.

Quick Troubleshooting

💡 BOB's tip: The AADSTS error code is your best friend. Paste it into a search engine (or login.microsoftonline.com/error) and you'll usually find the answer in about thirty seconds. Then you can spend the rest of the afternoon pretending it took three hours.

Wrapping Up

So there you have it:

• SSO lets users sign in once and get to everything.
• Entra ID is the identity provider; your apps trust it.
• SAML for most business apps, OIDC for modern and custom ones, password-based for the stubborn old-timers.
• Assign users, test with the Test button, and keep an eye on those certificate expiry dates.

Your users get fewer passwords, your security team gets MFA everywhere, and you get to disable just one account when someone leaves.

Everybody wins! Well, except the sticky note company.

See you next time!

— BOB