[Bug] DeviceCode Verification Url is incorrect for Entra External ID tenants

[Johno-ACSLive]

Library version used

4.59.0

.NET version

Brand new .NET 8 Console application.

Scenario

PublicClient - desktop app

Is this a new or an existing app?

This is a new app or experiment

Issue description and reproduction steps

Create a Entra External ID tenant and follow the remaining instructions. The arcticle here provides details on the steps and issues.

The URL provided in devicecode.VerificationUrl is "https://microsoft.com/devicelogin" but when logging in with a local account the follow error is displayed "AADSTS500208: The domain is not a valid login domain for the account type". The article here documents the issue.

Relevant code snippets

No response

Expected behavior

The correct URL for the domain should be provided e.g. "https://tenant_sub_domain.ciamlogin.com/common/oauth2/deviceauth". I'm not sure if this is an issue with Microsoft.Identity.Client or MSAL but I'm using Microsoft.Identity.Client library.

Identity provider

Microsoft Entra External ID

Regression

No response

Solution and workarounds

N/A - at the moment I have hardcoded the correct Uri in my prototype console application

[bgavrilMS]

@Johno-ACSLive - are you saying that the deviceCode.VerificationUrl is wrong? And if you replace the value provided by the token issuer the flow works?

[Johno-ACSLive]

@bgavrilMS yes if I use the url "https://microsoft.com/devicelogin" as provided by the library I receive the error "AADSTS500208: The domain is not a valid login domain for the account type".

If I use the alternate url I mentioned I'm successfully able to authenticate and the user flow works as expected.

[bgavrilMS]

CC @SammyO - this looks like a CIAM service issue

[bgavrilMS]

Just to confirm what @Johno-ACSLive mentioned, as I have now tested.

With device code flow, the app developer is supposed to display a message to their device, which ESTS suggests as:

But "https://microsoft.com/devicelogin" is wrong in this message. If I use https://msidlabciam2.ciamlogin.com/common/oauth2/deviceauth as suggested by @Johno-ACSLive , then I can complete the flow and I get tokens.

Note:

• the ID token has ver=2.0 claim, so MSAL does the right thing in terms of the endpoint used.
• https://msidlabciam2.ciamlogin.com/common/v2.0/oauth2/deviceauth does not work

[bgavrilMS]

@Johno-ACSLive - I had a chat with the CIAM team and they have confirmed that device code flow is not yet ready and we've published samples by mistake.

Of course, you may continue to use the workaround you found, but we cannot guarantee that it'll work forever.

Let's keep this work item open until the CIAM service fixes all of this.

CC @SammyO

[rayluo]

Issue description and reproduction steps

Create a Entra External ID tenant and follow the remaining instructions. The arcticle here provides details on the steps and issues.

The URL provided in devicecode.VerificationUrl is "https://microsoft.com/devicelogin" but when logging in with a local account the follow error is displayed "AADSTS500208: The domain is not a valid login domain for the account type". The article here documents the issue.

For what it's worth, I used an internal test tenant "msidlabciam2" to test Device Code flow just now. It still fails, but with a different error: AADSTS399266: Blob grant token received with wrong issuer type.

[Johno-ACSLive]

@Johno-ACSLive - I had a chat with the CIAM team and they have confirmed that device code flow is not yet ready and we've published samples by mistake.

Of course, you may continue to use the workaround you found, but we cannot guarantee that it'll work forever.

Let's keep this work item open until the CIAM service fixes all of this.

CC @SammyO

@bgavrilMS it seems some of the earlier documentation has been updated to indicate this. All good, I'm happy to use the workaround until the Device Code flow is finalised (presumably nothing should break as it will continue to follow the standards which MSAL will follow).

Good idea to keep this open until it's been resolved. Does the CIAM team have a ballpark estimate on when they think it might be ready?

[bgavrilMS]

I don't have a estimate, but it is being worked on. As with all Security / Identity work streams, priorities can change quicky :)