SAML 2.0 vs OpenID Connect

Every SAML app you add to Entra ID gets its own signing certificate, valid for three years by default. Entra emails you 60, 30, and 7 days before it expires, and then someone has to update the app. That difference between SAML 2.0 and OpenID Connect matters more day to day than the protocol diagrams, and this note follows it through both flows on the sheet.

SAML 2.0: the app holds a certificate

The app redirects you to Entra with an authentication request. You sign in. Entra posts a signed XML assertion to the app's Reply URL, also called the Assertion Consumer Service URL. The app trusts the assertion because it holds that app's signing certificate.

The Reply URL list is part of the security model. Entra accepts a signed SAML request but doesn't verify its signature. It relies instead on the reply URLs registered for the app, and sends a token only to one of those, so keep the list to URLs the app actually uses.

OpenID Connect: the app reads published keys

The app sends you to the /authorize endpoint. You sign in and consent. The app gets an authorization code, redeems it at the /token endpoint, and receives an ID token, which is a signed JWT, plus an access token. The ID token comes back only when the app asks for the openid scope.

The app validates tokens against signing keys Entra publishes, so there's usually no per-app certificate for you to roll. The keys are listed at the jwks_uri in Entra's OpenID configuration document, served from /.well-known/openid-configuration. Entra rolls them periodically and, in an emergency, immediately, with no set time between rolls. Microsoft's guidance is to use a standard authentication library that keeps the key list current, because an app that checks signatures against an old key rejects valid tokens.

PKCE belongs in every one of these apps. Microsoft's protocol reference recommends it for all application types, public and confidential clients alike, and requires it for single-page apps that use the authorization code flow.

Rolling a SAML certificate without an outage

A certificate's expiration date can't be changed after it's saved, so a rollover always means a new certificate. Microsoft's renewal procedure runs in this order:

1. 01Create the new certificate on the app's SAML Signing Certificate page, with dates that overlap the current one. Any expiration date up to three years out is allowed.
2. 02If the app can roll over on its own, reading the new certificate from Entra's federation metadata, make the new certificate active and skip to the last step.
3. 03If the app accepts only one certificate at a time, schedule a downtime window for the switch.
4. 04Before the old certificate expires, download the new one in the format the app's setup instructions call for, upload it to the app, and make it active in Entra.
5. 05Sign in to the app to confirm the new certificate works.

Two details in the same guidance affect timing. Once a certificate has expired, Entra signs with any newer valid certificate on the app, even one that isn't active yet, and an app still holding the old certificate can stop accepting sign-ins. Meanwhile, an app that doesn't check expiration keeps accepting an expired certificate that still matches. For apps like that, Microsoft says to create the replacement only inside the scheduled maintenance window.

Make the expiry emails reach someone

The 60, 30, and 7-day notices go only to the admin who added the app until you change the list. Entra takes up to five addresses, that admin's included, so use a distribution list to reach more people. The mail comes from azure-noreply@microsoft.com, which Microsoft suggests adding to your contacts so it stays out of spam.

If you set the notification addresses with Microsoft Graph or PowerShell, open the app's SAML settings in the admin center and save them there too. Microsoft notes that the expiry emails might not be sent otherwise.

OIDC apps still expire

OIDC apps that are confidential clients hold client secrets or certificates, and both have expiration dates. Microsoft recommends certificate credentials over secrets. Public clients, which include native and single-page apps, must not use either one to redeem an authorization code. Put the confidential clients' credentials on the same calendar as the SAML certificates.

The post ended on a question worth answering before the next notice arrives: how many SAML signing certificates in your tenant expire in the next 90 days?