Microsoft Account Integration plugin does not connect with Microsoft endpoint(s)

[CodeOfConduct]

Steps to reproduce the issue

a) Follow all configuration instructions at https://github.com/akeeba/sociallogin/wiki/Microsoft-Account except the procedure for the app registration;

b) Register the app in the Azure portal because the Microsoft Application Registration Portal is no longer available for registrations and apply the app ID and secret to the plugin as per instructions;

c) Click on the “Sign in with Microsoft” button created by the plugin on the front end.

Expected result

User is taken to the Microsoft account login screen (if logged out).

Actual result

Page at https://login.live.com/oauth20_authorize.srf?response_type=code&client_id=..... is loaded with the following error message:

“We're unable to complete your request

unauthorized_client: The client does not exist or is not enabled for consumers. If you are the application developer, configure a new application through the App Registrations in the Azure Portal at https://go.microsoft.com/fwlink/?linkid=2083908.”

Troubleshooting already performed

A log of the network traffic after clicking the button was analysed: it shows that at no time did the plugin connect with the correct Microsoft endpoints that start with https://login.microsoftonline.com/ (e.g. the OAuth 2.0 authorization endpoint (v2): https://login.microsoftonline.com/common/oauth2/v2.0/authorize). Microsoft confirmed that the problem is not with their authentication.

System information

Current versions of the System and Microsoft Account Integration plugins

Mandatory information

• Joomla! version: 3.9.23
• PHP version: 7.4
• Am I using HTTPS: Yes
• Server Operating System: Linux
• My device's Operating System: Windows
• My device's Operating System version: Win 10 Pro
• Browser: Chrome, Firefox and Edge (Chromium)
• Browser version: current versions of all 3 browsers

Good to have information

You can skip some or all of this information. However, the more information you provide the faster and better we can help.

• MySQL version: x.y.z
• Server type: Apache, NginX, IIS, Lighttpd, LiteSpeed, ...
• Server version: x.y.z
• Hosting company / Local server: Enter the name of your site's hosting company or the prepackaged local server (e.g. MAMP, XAMPP, WAMPServer, ...) that you're using
• Server Operating System version: e.g. Windows 10, Ubuntu 16.04, ... Type N/A if it's a live host and you have no idea.

Additional comments

[nikosdion]

Not a bug, you just didn't scroll down on the Microsoft Application Registration Portal. The "Add an app" button is still there. See the following screenshot.

Please note that applications created in Azure are very different than applications created with a personal Microsoft account using the Live SDK. Azure applications use Azure Active Directory for authentication and are therefore tied to a specific Azure tenant, i.e. the only allow logging in with Microsoft accounts belonging to that specific organisation. You cannot currently have an Azure application allow logins from personal Microsoft accounts or Microsoft accounts belonging to other organisations. That's why Microsoft still allows creating applications from a personal account using the old Live SDK API which allows login from any Microsoft account (unless, of course, it belongs to an organisation and the organisation has explicitly disabled the ability to use that account to login to external services but that's besides the point).

I am therefore labelling this as invalid and closing it.

[CodeOfConduct]

Thanks for your prompt response. However, I have grounds to disagree with some of your statements:

1. Microsoft account holders that do not have registered apps on the Microsoft Application Registration Portal can no longer register new apps there (confirmed by Microsoft this morning). Here is a screenshot of what I see after logging in to that portal (with a personal or a work/school account):

So “just didn’t scroll down… “ is incorrect. There simply is nothing more on the page “to scroll down to” other than what is shown on the screen shot.

2. “Azure applications … only allow logging in with Microsoft accounts belonging to that specific organisation.” – Microsoft confirmed to me this morning that this is not correct. There is a configuration setting in Azure that allows authentication of four different “Account types”. Two of those cover personal account types:

   a. Personal Microsoft accounts only b. Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)

I had selected the second one of these when registering and configuring the app in the Azure Portal. Microsoft confirmed this morning that these options do indeed cover authentication of personal accounts (i.e. no connection with an organisation).

I have a high regard for the quality of Akeeba’s products, especially Akeeba Backup. So, my hope is that – in spite of the application differences that you pointed out – it will be possible to enable the existing Social Login plugin for Microsoft accounts to connect to Azure Active Directory for authentication, as that identity provider supports personal Microsoft accounts.

[nikosdion]

Let me check again later today or tomorrow. I last looked into Microsoft's Azure AD in May when it was only possible to create organization-level applications.

[nikosdion]

Have you created the Azure application using the default Azure Active Directory or have you created an Azure AD B2C tenant?

[nikosdion]

Oh for crying out loud, Microsoft's documentation is all kinds of wrong! Of course you can't successfully create a B2C tenant following their stupid documentation. I have to write my own. Wow, so much for a multibillion dollar company.

[CodeOfConduct]

Thanks for the update! I understand the frustration. After following the official instructions dated 22 Oct. 2020 (https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-create-tenant), the creation of the AAD B2C tenant failed and the link in the error message did not lead to the intended article. I have therefore submitted a new Support Request to Microsoft and should hear from them by tomorrow. I'll let you know when I have been able to create the AAD B2C tenant.

[nikosdion]

I can tell you why it failed. By default, your Azure subscription isn't registered to use the Microsoft.AzureActiveDirectory provider which is a requirement for setting up an Azure AD B2C tenant.

Make sure you are logged into the tenant under which the Azure AD B2C tenant will be create. Look at the top right of the page. The tenant is under your name / email. If that’s not the correct tenant click there and select Switch Directory, then click on the correct one.

From the hamburger menu at the top left select Home.

Click on the big key icon (Subscriptions). You will see your active subscriptions to Azure. Click on the one where excess usage will be billed to. Do note that Microsoft gives you the first 50,000 monthly active users for free. You will be charged a small fee for monthly active users beyond that limit. That’s why you need a subscription and payment information to use Azure.

From the left hand sidebar scroll down and select Resource Providers.

In the main area’s search bar type Microsoft.AzureActiveDirectory

If the entry displaying has a NotRegistered status click on it and then click on Register from the toolbar. The icon will change to Registering. Because this is Microsoft and things don’t make sense, the status will never change. Wait for three minutes. Click on Resource providers again. It should show Registered. If not wait another three minutes, rinse, repeat.

Then you can create the Azure AD B2C tenant.

[nikosdion]

After wasting most of my day with Microsoft's horrible, convoluted, contradicted, misleading and often wrong documentation, a lot false starts and many, many, many tests I have come to some conclusions.

Live SDK applications and Microsoft Azure AD applications are not interchangeable, despite the misleading wording on Microsoft's blog post linked to from the Live SDK page. They use completely different login URLs, they use completely different token URLs, they use a completely different API (Live SDK and Microsoft Graph respectively) to get client information.

You can still create Live SDK applications using a personal Microsoft Account. You can no longer create Live SDK applications using a Microsoft Account that is tied to a tenant, i.e. an organisation or school account. This is why you didn't see that part of the page. If you use a personal account you can still follow the instructions in the wiki.

You do not need to create an Azure AD B2C tenant. This is misleading bollocks in Microsoft's documentation. This only applies if you are creating a SaaS which can be optionally added to a tenant by its administrator. This does NOT apply to logging into a site.

You only need to create an application registration in the Azure AD of your main Azure tenant. Even if you have a personal account there is a "Default directory" where you can do that. This is very badly documented in https://docs.microsoft.com/en-gb/azure/active-directory/develop/scenario-web-app-sign-user-app-registration?tabs=aspnetcore

I basically need to create two parallel flows – one for the Live SDK and one for Microsoft Graph. I am working on it. It's not just the SDKs are different. They need different data too! The Microsoft Graph SDK requires the tenant ID, the app ID and the app secret. The former is used in the login URL. Not putting it there causes the error you experienced. The only way I know about any of this is absolutely not thanks to Microsoft's convoluted and often wrong documentation but my previous work on implementing OneDrive for Business integration with Akeeba Backup which does use Microsoft Graph and I had already done that research.

So, to sum it up:

• For now, you can create a Live SDK app using your Personal Microsoft Account.
• In the future I'll add support for Azure AD applications.

The worst thing is that Microsoft could have just said as much in their blog post they linked to in the Live SDK apps page. But, no. It's Microsoft. If it were straightforward you wouldn't have earned the privilege to use their services.

[CodeOfConduct]

Thank you very much for all the effort you put into this. Tomorrow, I'll try to register an application in the Azure AD of the main Azure tenant following your link. I hope that works, as my attempts that triggered the original error behind this issue were indeed made with an Azure account created with a personal Microsoft account. Just in case my previous comments were not clear: whenever I tried to create apps in the old Microsoft Application Registration Portal, even with a personal Microsoft account, the result was the error screen of which I included a screenshot above..

[nikosdion]

Hm, so Microsoft is basically lying in its documentation when they are saying that personal Microsoft accounts can still create Live SDK apps. I am not surprised, just disappointed that it's my consistent experience with Microsoft. Their documentation is consistently wrong and misleading.

Don't bother trying to use the Login with Microsoft integration just yet. Azure AD applications cannot use the Live SDK API. They can only use the Microsoft Graph API. I have to write new code to do that.

I was actually in the process of doing that but we have an issue with the hosting provider of the live development site I was using. I am waiting for them to fix the problem on their end so I can continue working on this.

[CodeOfConduct]

Thanks for saving me the effort of testing with Azure AD at this time. Wrt the MS documentation, I think part of the problem is that, in connection with the multitude of new and phased-out features, a large quantity of new documentation is produced daily. Unfortunately, it seems that superseded documents are not always updated, flagged as out-of-date or deleted; and there is probably the common approach of "develop now and document later"... which has caused me a lot of frustration, too.

[nikosdion]

I could understand that and even relate to it. However, linking to outdated / invalid documentation from inside the Azure Portal itself and error messages is just crazy. Oh, well.

[nikosdion]

I have updated the plugin to support Azure AD app registrations. Please download and install the dev release below

pkg_sociallogin-rev9DAD016.zip

Let me know how that worked for you and I'll update the documentation Wiki as well.

[CodeOfConduct]

It is definitely an improvement on the previous version, but login failed both with a work/school and a personal Microsoft account, although I had configured the app in Azure for "Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)". Interestingly, I got further with a work account: After clicking on "Sign in with Microsoft" and entering my work account credentials, the following error was displayed:

With a personal account, the old error "We're unable to complete your request unauthorized_client: The client does not exist or is not enabled for consumers. If you are the application developer, configure a new application through the App Registrations in the Azure Portal at https://go.microsoft.com/fwlink/?linkid=2083908." was displayed as soon as I submitted my personal account's email address - i.e. I did not even get to the password prompt.

I don't know whether this matters, but the publisher domain is unverified. The verification process repeatedly failed although I had carefully followed the instructions (which is by now the subject of another Support Request to Microsoft).

What surprises me, is that in the error message for the attempt with the work account, the directory in which the app is being searched (blacked out in the screen shot on the 2nd line after "...was not found in the directory...") is the login work account's domain name, not the domain or ID of the directory where I registered the app... i.e. the authentication flow seems to be directed to the account of the user who is logging in, rather than the AAD tenant.

[nikosdion]

Ah, welcome to Microsoft hell! I was getting that last night too. I went to bed. Woke up. Tried it again. It worked. It looks like there is a lag of several minutes to hours between creating a credentials pair and it working.

[nikosdion]

BTW, you can see the code in action at https://myoldsite.com

[CodeOfConduct]

Ok, I'll try again tomorrow. In the meantime, I tried on your testsite, but as I get the error "You do not have an account on this site that corresponds to this Microsoft Account." I imagine the plugin was configured to not register new users.

[nikosdion]

Correct. I've only set it up to log in existing users. But since you got that far it means Microsoft logged you in, send the site a code, the site exchanged it for a token, accessed the Microsoft Graph API with it and got your name and email address. So, it does work – it's just that Microsoft is being Microsoft. Sigh.

[nikosdion]

FWIW I created a second credentials pair for the same app registration ten hours ago. It still shows me the error message about the application not being registered. Same app, different set of credentials, different results.

I am currently wondering if I should just remove the plugin. How can you possibly tell people that a multibillion dollar company is doing crazy things and it's not a bug in your software? Who would believe the small company over the tech giant?

[CodeOfConduct]

10 hours?! That's very bad. I'll leave my current credentials and will keep trying my registered app later today and tomorrow to see how long it takes for it to become functional and then open a Support Request and see how they respond... I can only see it in their interest to fix this.

[nikosdion]

It might be even worse than 10 hours.

I was following the rabbit hole about registering for the Microsoft Partner Network and verifying the app registration with the MPN ID just in case it made any difference. It shouldn't; the requirement for an MPN ID is only applicable to applications requiring more than basic profile information.

Anyway. I spend a few hours getting everything registered and verified and all that. I created an app registration with the tenant created by the MPN account. Funnily, I cannot link the MPN ID to the app registration. Looking at Microsoft's GutHub account there's an issue stating that the common workaround for my error code is to wait for 48 hours!

I have a feeling that Azure needs 24 to 48 hours to figure its shit out. I create a new app just now (8pm GMT on December 2nd) and I will continue monitoring it to see when it becomes active. I'm also VERY seriously considering just tossing the entire login with Microsoft plugin. I'm disgusted at Microsoft. This is shoddy developer experience and they do fuck all about it!

[nikosdion]

I made some changes in the code to display a better interface when entering the settings and updated the wiki.

There is a lot of confusion in the Microsoft documentation due to the many different things called an "ID". You need to use the application ID that you see in the app registration, not the ID you see in the client secrets. The client secret value, however, is the one you see in the client secrets page. Because that somehow makes sense.

In any case, I tried registering an Azure AD app and it works just fine. So there's that.

[CodeOfConduct]

Thank you, your new documentation in the Wiki made the difference between failure and success - at least for logins with Microsoft work / school accounts (i.e. for them the login and registration works). However, for logins with Microsoft personal accounts I now always get the message "Warning: You do not have an account on this site that corresponds to this Microsoft Account." in the Joomla! systems messages block. I have also created a user via the User menu that has the same email address as a Microsoft personal account user, but when attempting to log in such a user with the Social Login the above-mentioned warning is still displayed. Do you have any ideas what this might be due to?

[CodeOfConduct]

PS: I have been using pkg_sociallogin-rev9DAD016.zip for the tests.

[nikosdion]

Oh my God, the Microsoft Graph API is really stupid.

When you log in with a work/school account the MS Graph API returns your email in the mail field which is documented to be your email address. The userPrincipalName field contains the fake email using your organization domain name (which may or may not be your email address). When you log in with a personal account the mail field is null. Your actual email address is in the userPrincipalName field.

Of course you cannot really distinguish between the two types of accounts. So I have to make a stupid change where I try the mail field first and if it's empty I need to fall back to the userPrincipalName field.

Try using this dev release https://www.akeeba.com/download/developer-releases/sociallogin-dev/rev499e631.html

[CodeOfConduct]

The new dev release works - thank you very much! Do you have an approximate release date in mind for the "stable" version?

[nikosdion]

Thank you for the feedback!

Most likely release date would be next week, possibly Wednesday.