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.
Important The infinite loop 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 request page. If this is the case and the user is not signed into your WordPress website, it will redirect the user to Microsoft. Microsoft will send the user back to your website (more specifically, to the URL that you configured as Redirect URI) and again the plugin will inspect the incoming request. I 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.
Now that you understand how the plugin basically works, it will be easier to understand the possible causes of an 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.
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
Last but not least 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.