Why the authorization code user flow is now recommended

Introduction

Until version 17.5 the WPO365 | LOGIN plugin for connecting WordPress with Azure AD / Microsoft 365 enabled WordPress administrators to configure Microsoft based Single Sign-on (SSO) for (some of) its users. To implement SSO, the plugin offered two alternatives:

• OpenID Connect
• SAML 2.0

This article may not be of interest for those who configured (or are about to configure) SAML 2.0 based SSO. Instead, it focuses on a change that concerns the OpenID Connect User Flow. Starting with version 18.0 of the WPO365 | LOGIN plugin, administrators who configured (or are about to configure) OpenID Connect based SSO can choose between two user flows:

• Hybrid User Flow
• Authorization Code User Flow

The paragraph Important information in the SAML 2.0 implementation guide will help you choose between SAML 2.0 and OpenID Connect. The short story, however, is that OpenID Connect is recommended since it allows for a more streamlined experience when you plan deeper integration with Microsoft Service such as Microsoft Graph, Azure AD or SharePoint.

Especially administrators that are looking to configure or have already configured Azure AD B2C based Single Sign-on for WordPress are strongly recommended to choose the Authorization Code User Flow. Starting with version 18.0 of the WPO365 | LOGIN plugin they can configure the ID Token as a source for custom user fields (instead of Microsoft Graph). Please note that mapping custom user fields is a premium feature and requires - for example - the WPO365 | LOGIN+ extension.

Hybrid User Flow versus Authorization Code User Flow

When a user signs in with Microsoft, the application where the user wants to sign in with Microsoft, will send that user to Microsoft. When the user entered valid credentials and thus authenticated successfully, Microsoft will sent the user back to the website. Microsoft also gives the user a small piece of information "in the hands" (actually, Microsoft adds this to the header of the request). Now it is up to the website to detect this piece of information and process it and try use that piece of information to automatically sign in the user (unless the information reports that an error occurred).

Depending on the user flow that has been configured, that piece of information can contain sensitive or even secret information. Have a look at the following table:

Also have a look at the following - simplified - definitions of those various pieces of information:

• ID token An ID Token is a small JSON Web Token (JWT) that contains user-related information e.g. the user's first and last name, email address and some technical information about the Azure AD instance that issued it. 
• Access Token An Access Token is also JSON Web Token. However, an Access Token has the same weight as a password. With an Access Token a user can request information from specific resources and the token itself knows which resources these are. Possible resources can be - for example - Microsoft Graph or SharePoint.
• Authorization Code Think of an Authorization Code as one half of a password. The code itself is useless but when it is sent to Microsoft together with a username (the ID of the application that you registered in Azure AD) and (the other half of the) password (the Client Secret that your created for the application that you registered in Azure AD) then Microsoft will respond with an ID Token and Access Token.

Why the Authorization Code User Flow is now recommended

From the preceding table it follows that with the Authorization Code User Flow only half of a password is sent to the client's browser. The server will then detect this code and use it to request from Microsoft an ID Token (and optionally an Access Token if integration with Microsoft Services is configured). Since a server is considered far more secure than a user's browser, the Authorization Code is therefore the recommended user flow.

Important information

Administrators that decide to switch from the Hybrid User Flow to the Authorization Code User Flow must be aware of the following:

• They can remove the Implicit Grant for ID Tokens and Access Tokens on the registered application's Authentication page.
• For the Authorization Code User Flow it is mandatory to have created a Client Secret on the registered application's Certificates and secrets page.

You can verify your current configuration by reviewing the updated guide to configure Single Sign-on. Alternatively, administrators can start the Plugin self-test when they navigate to WP Admin > WPO365 > Plugin self-test and follow the recommendations provided to update the configuration.