Use this guide to help find the root cause of why the plugin keeps sending you to Microsoft, even though you successfully signed in with your corporate or school account.
How the plugin works and why the infinite loop may actually be a good sign
The infinite loop - in most cases - is basically a result from the plugin simply doing its job. It intercepts and inspects each incoming request. And when it does, it checks the WPO365 configuration to understand whether or not the user should authenticate in order to see the requested page. If this is the case and the user is not signed into your WordPress website, it will redirect the user to Microsoft. Once the user signed in with Microsoft, he / she will be sent back by Microsoft to your website (more specifically, to the URL that you configured as Redirect URI) and again the plugin will inspect the incoming request. It will search for a so-called authentication response. If it finds such a response - the so-called ID token - it will try to sign the user into your WordPress website. Once the user is signed into your website the plugin will redirect user to the URL he or she initially intended to load.
Possible causes of the infinite loop
1. Your website is reachable using different schemes
To use Azure AD App registration your website must use SSL. As a result your website address in all cases start with https://... and you must make sure that user cannot access your website via the non-secure http://... scheme. If you haven't prevented users from accessing your website using the non-secure scheme it is possible that the user is in fact signed into the secure version of your website but when he or she navigates (back to) the non-secure version the login information in the form of a WordPress cookie is not found and the plugin starts the authentication workflow.
Tip As a remedy, try to install and active the Really Simple SSL plugin from the WordPress plugin directory (see https://wordpress.org/plugins/really-simple-ssl/ for details). It will help ensure all traffic gets redirected to HTTPS plus it will help fix your general WordPress configuration such as WordPress Home and Site Address URLs.
2. Your website is reachable using multiple URLs
In case you have configured a shorter URL for your website e.g. https://your-website.com but also still allow users to access your website via https://www.your-website.com you'll end up in a similar situation as described above. The user is in fact signed into the shorter version of your website but when he or she navigates (back to) the longer version the login information in the form of a WordPress cookie is not found and the plugin starts the authentication workflow.
3. The authentication response is dropped
It is possible that the authentication response, added to the request by Microsoft when the user authenticated successfully, is dropped when the user is being redirected back to your website. There is not one particular reason why this may happen e.g. a load balancer may redirect the user but not pass on all headers or an additional redirect occurs and the authentication response is simply dropped. In such cases the authentication will never make it to the plugin and thus the plugin will start the authentication workflow from scratch.
Last but not least Finding the root cause of this problem is not easy. Very often it has proven valuable to analyze the network traffic. To do so you can use for example your browser's developer tools. In Chrome press F12 to open the developer tools and activate the Network tab. Check the Preserve log option and navigate to your website and reproduce the infinite loop. Once the loop occurred, stop the browser from loading and carefully analyze the traffic and search for signs of any of the aforementioned possibly causes. If you can not find the cause then please feel free to download the network log as a HAR file and send it to support [@] wpo365 [.] com.