What’s the problem?
In this post, I’m going to show you how we can bypass the Azure Active Directory (Azure AD) sign-in prompt. As with most Microsoft Apps that use Azure Active Directory for authentication, you will get this familiar prompt when signing in for the first time:
In some cases if you’ve signed-in already, the username will be pre-populated but you still need to click on it to proceed. Of course, Azure AD needs to know who you are to redirect you to the correct tenant. But if the user has already authenticated, this might be unnecessary. The use cases where we don’t need the sign-in prompt would be when we’re certain the user doesn’t need to switch tenants. For instance, if we have a portal with a list of corporate applications (like a corporate intranet), clicking on those applications shouldn’t require user selection because we can confidently say that the user intends to stay on our tenant. This can also be useful when the user may not know their UPN (perhaps, Alternate Login ID is not setup or can’t be).
How can we solve it?
For some Microsoft Apps, we have Smart Links which use Windows Home Realm (WHR) feature as part of ASP.NET. Fellow Microsoft geek Jack Stromberg has a nice utility on his blog to generate Smart Links. But, this doesn’t work for Windows Virtual Desktop because it uses OpenID Connect (which is built on OAuth 2.0). We can however construct a URL that will work for Windows Virtual Desktop using domain hints. This URL is going to be very long, however in our use case the URL will be hidden behind a button, icon, or hypertext on a webpage so our user’s don’t need to know anything about it.
Constructing the URL
Let’s break down how the URL needs to be constructed:
- https://login.microsoftonline.com/common/oauth2/v2.0/authorize?: Azure AD OAuth 2.0 endpoint
- response_type=id_token&: This must be id_token.
- scope=https://www.wvd.microsoft.com/.default openid profile&: The scope must include OpenID (“Sign you in” permission) and can include other scopes.
- client_id=a85cf173-4192-42f8-81fa-777a763e6e2c&: This is the id of “Windows Virtual Desktop Client” as documented on Microsoft Docs.
- redirect_uri=https://rdweb.wvd.microsoft.com/arm/webclient&: HTML5 web client URL as documented on Microsoft Docs.
- domain_hint=contoso.com&: The validated domain in Azure AD for the tenant where authentication should occur. Change this to your domain.
- response_mode=form_post&: HTTP POST
- nonce=11128bbe-070f-4ec8-a5f5-0ccb78db7d5e: A nonce is required per the documentation and should be dynamically generated (more on that below).
You can find out more about each parameter in the URL by reviewing Microsoft identity platform and OpenID Connect protocol – Microsoft identity platform | Microsoft Docs. Everything in this URL can be hard-coded except for the nonce, which must be dynamically generated to prevent token replay attacks. For a lab, you could pass 1 or more digits and things will work fine. In a production scenario you would need to find a way to generate the nonce dynamically. There are many ways to do this but a simple suggestion would be to randomly append some numbers using JavaScript when the page loads. Here’s how the fully constructed URL looks:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=id_token&scope=https://www.wvd.microsoft.com/.default openid profile&client_id=a85cf173-4192-42f8-81fa-777a763e6e2c&redirect_uri=https://rdweb.wvd.microsoft.com/arm/webclient&domain_hint=contoso.com&response_mode=form_post&nonce=8675309
Now, when the user clicks on the WVD icon, the browser gets redirected to the URL which already contains a domain hint, the tenant to which we want to sign-in and the application (rdweb) so no more. If the user has previously logged in (for instance to our corporate intranet or portal page), they won’t need to type in a password, perform MFA, or other interactions. This works well for federated Azure AD domains as well (e.g., Azure AD using AD FS).