So I've setup a few Blazor projects thus far, most of which have used custom identity providers to deal with disconnected or legacy provider situations. However I've done one Blazor (and multiple MVC/RazorPages) project using the original MSAL Azure AD support which I found setting up a pain.
Imagine my joy when the new 'simple' Microsoft.Identity.Web package hits release
Microsoft.Identity.Web is the new way to authenticate and manage tokens in https://t.co/sPv2lEgqtm Core. Read up and get your mind blown away by the power and simplicity of the library - https://t.co/tTTBltIjXX #microsoftIdentity #425Show #security #dotnet @dotnet @azureAD pic.twitter.com/dF1nWE6ugx— C:\hristos.matskas #blackLivesMatter (@ChristosMatskas) October 9, 2020
To be clear, it does live up to it's claims, but if you are playing late at night without paying attention, you may run into the error that is the title of this post.
So what did I mess up this time.
I asked @ChristosMatskas if there was any new guidance, and he pointed me to the new templates
Absolutely! There is a new set of templates that you can install (manually for now) to get the .NET 5 goodness https://t.co/F2ULrm2OvF. Then you can do `dotnet new blazorwasm2 -au SingleOrg` :) Ping me if you get stuck— C:\hristos.matskas #blackLivesMatter (@ChristosMatskas) October 9, 2020
I installed the new template, and followed the existing docs, setting up the new server API app in Azure AD, and the client app (this is what I messed up).
Having created the necessary entries in Azure AD, I created a new Blazor WASM project from the new templates, and successfully logged in. Having confirmed it all worked (it didn't), it got distracted by whatever was going on that day and didn't come back to the project for an hour or so, which is when I first encountered "There was an error trying to log you in: 'No account to get tokens for.'"
During the early days of Blazor, I've run into a fair amount of issues that can be resolved by manually deleting the
obj folders, so that was my first attempt, which made no difference.
I then attempted clearing the site data, which changed things. I was once again promoted for login, went through the login process fine, and at this stage noticed that the login process itself appeared to be fine (it wasn't), but still ended up with the same error message.
Off to DuckDuckGo I went, searching for the error message, but I found no-one else had reported this issue... clearly I'm capable of making mistakes no other person has thought of!
Knowing it was likely my own mistake (oh yes), but being utterly confused about the initial success and then failure, I reached out to @ChristosMatskas again
This sounds weird. Do you have a GitHub repo I can check? Or repro steps? /cc @AzureAndChill— C:\hristos.matskas #blackLivesMatter (@ChristosMatskas) October 14, 2020
After some sanity checks, I re-ran the project creation with the same settings in another directory, and once again the login seemed to be working, while the original project was still failing
Re-ran the same dotnet new in a different directory, and the created project worked so not a setting issue. But then i went back to the original and it still doesn't work, then I noticed this. pic.twitter.com/zJa4lsqHip— Steve Croxford (@CodedBeard) October 14, 2020
I was now completely bemused as to what was going on, but thankfully, reaching out to @ChristosMatskas had paid off.
It turns out the issue was very simple, I had missed a crucial step in the Azure AD client setup, I hadn't switched the app type to SPA from the default Web. I had also presumed this sort of oversight would have caused the authentication to fail completely, but instead causes the error in the title of this blog after x mins. Thankfully @AzureAndChill had the answer
Make sure you register the app redirect uris as a SPA in the portal. Web will not work— John Patrick Dandison ☁☁☁ (@AzureAndChill) October 14, 2020
The joy of modern Microsoft
I've made these sorts of 'late night' mistakes a lot over the past almost two decades! The days of struggling through MSDN and 'official' support channels are mainly over though. Thanks to @ChristosMatskas and @AzureAndChill for finding my oversight in quick order.