WPO365 can let WordPress users sign in with a Microsoft Entra ID work or school account. The supported OpenID Connect route needs an Entra app registration, an exact HTTPS redirect URI and matching WPO365 settings. Keep a tested WordPress administrator recovery account until Microsoft sign-in works end to end.
This is an identity change, not a cosmetic login-button change. Build it in staging first.
Prerequisites
You need:
- WordPress administrator access;
- permission to register or manage an application in the correct Entra tenant;
- an HTTPS WordPress site with its final public hostname;
- the current WPO365 LOGIN plugin and its current vendor tutorial;
- an agreed sign-in audience, such as accounts in one organisation only;
- a documented fallback if Entra or the plugin configuration fails.
Do not grant Global Administrator simply to complete this task. Microsoft documents app ownership, Application Developer and application-administrator roles as narrower ways to delegate app work, depending on tenant policy.
1. Install WPO365 and capture its redirect URI
Install and activate WPO365 LOGIN from your approved source. In WordPress, open WPO365 > Single Sign-On and select the Entra workforce tenant type for employee accounts.
Choose OpenID Connect and the Authorization Code flow. Copy the redirect URI shown by the plugin. Do not retype or simplify it.
Keep SSO optional while configuring it. Forcing Microsoft login too early can lock administrators out.
2. Register WordPress in Microsoft Entra ID
In the Microsoft Entra admin centre:
- Go to Entra ID > App registrations > New registration.
- Give the registration an operational name that identifies the WordPress site and environment.
- Choose the supported account type that matches the approved audience.
- Under Redirect URI, select Web and paste the exact WPO365 URI.
- Register the application.
- Record the Application (client) ID and Directory (tenant) ID.
- Assign at least two maintained application owners.
Redirect URIs must match exactly. Microsoft identifies a mismatch as error AADSTS50011. Correct the app registration or plugin setting rather than adding broad or speculative redirect addresses.
3. Configure the plugin
Back in WPO365:
- Enter the client ID and tenant information from the app registration.
- Keep the Authorization Code flow and the vendor's documented response mode unless a tested integration requires otherwise.
- Save the configuration.
- Run WPO365's self-test.
Use only the permissions required by the sign-in scenario. Retrieving SharePoint, profile or Graph data is a separate integration decision and may need extra permissions and consent.
4. Test before enforcing SSO
Use a private browser window and test:
- an allowed employee account;
- an account outside the intended tenant;
- a user without an existing WordPress account, according to your provisioning policy;
- logout and sign-in again;
- direct access to an intended protected page;
- the local WordPress recovery route.
Confirm the WordPress role assigned after sign-in. Authentication proves who the user is. It does not decide what they should be allowed to administer or read.
5. Harden the production setup
- Keep WordPress core and the plugin maintained.
- Review redirect URIs, permissions, credentials and app owners periodically.
- If the selected WPO365 flow needs a credential, store it securely and monitor expiry. Never commit it to source control.
- Apply Conditional Access only after testing its effect on the WordPress sign-in journey and confirming licensing.
- Protect and monitor the WordPress administrator surface separately from the Microsoft identity configuration.
Recovery
If sign-in loops or returns AADSTS50011, compare the browser's redirect URI with the Entra registration and WPO365 value character for character, including scheme, hostname, path and trailing slash.
If every administrator is locked out, use the pre-tested WordPress recovery account or your hosting provider's approved plugin-disable process. Restore service first, then diagnose. Do not delete the Entra app registration unless you have recorded the configuration and understand every dependency.
What this proves
A successful staged test proves that the tested Entra account can authenticate and receives the expected WordPress role through this configuration. It does not prove that every WordPress page is authorised correctly, that Conditional Access covers every scenario, or that the site is secure as a whole.
For practical identity and Microsoft 365 administration guidance, join the SharePoint & Teams Admins Space.