This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(243.2, 25%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESL%3C/text%3E%3C/svg%3E)
I am developing a FIDO2 login for our printers to Microsoft Azure Active Directory. The application uses an OIDC Authentication Flow where the user can log in to the Microsoft Login Page using a FIDO2 Security Key.
Today during testing we noticed that the first login to the application registered in azure of any user is not allowed to be by a FIDO2 card but has to be a email + password. Otherwise, the first login will show an error screen to the user: AADSTS165000 Invalid Request
After logging in to our application with the email and password the Fido2 login is also accepted for future logins. But for our customer it is not acceptable to require one manual login.
Information regarding the Azure AD I used:
License
Azure AD for Office 365
Tenant ID
7b7019a0-64f1-444b-b8d4-70cb72cd902b
Primary domain
******.onmicrosoft.com
Screenshots from the Error:
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(195.2, 0%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVM%3C/text%3E%3C/svg%3E)
@Stefan Lobbenmeier Checking on this, will update
@Stefan Lobbenmeier Thanks for your patience on this. We would like to take this offline to investigate, you would be able to drop us an email at azcommunity[at]microsoft[dot]com
with subject "Atten-Vipul" and we can take it further from there.
Thanks, I just wrote the E-Mail.
@Stefan Lobbenmeier Posting for community.
After taking this offline and with further investigation it was found to a generic scenario of how Azure AD handles the CSRF attack and how it uses user session information from the cookies it deploys.
The behavior here is expected and there should be a way of letting AAD know about the user while doing FIDO.