Home » Posts » Tech » Tech Tips » How to fix AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.
How to fix AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.
This post was most recently updated on December 7th, 2022.
3min read.
Have you run into the cryptical “AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.” error? I have. This post will tell you how to fix it.
How to fix AADSTS50059?
I encountered this error while trying to reload a page with some JavaScript that authenticates against Graph API. It completely blocks the functionality, as it redirects the user to the login page, but instead of successfully logging in (and perhaps redirecting back), it fails with an error.
Luckily, at least in my case, this was easily fixed! Your error might look something like this:
Sorry, but we’re having trouble with signing you in.
AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.
Request Id: <guid>
Correlation Id: <guid>
Timestamp: 2019-11-27T20:58:36Z
Message: AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.
Okay – so the error claims Azure AD fails to recognize your tenant, as the request or provided credentials didn’t provide that.
… But is that even true?
The URL of the login page will look something like this:
So.. Wait a minute. The login URL actually has all the info about the tenant and everything! You should be able to log in with that. What’s wrong, then?
The issue is, that you’ve already got login information on your machine – just not the correct one for this tenant! It’s all cached in the Local Storage, and the info conflicts with what you have in the URL. So the whole login process is trying to implicitly use the wrong cached credentials to log in to the tenant automatically.
Solutions
After originally writing this article in 2018, I actually uncovered another way to mess up your authentication flow in your code that results in getting the AADSTS50059 error.
However, let’s go through the easy, user-oriented fix first, and then briefly take a look at the more developer-centric option!
Solution 1: Remove everything related to ADAL from Local Storage
ADAL login, when successful, caches the login info into your browser’s local storage. That’s convenient, as it eliminates the need to log in again anytime soon, but in a situation where you’ll be authenticating against multiple Azure AD instances (such as when you’re switching between different SharePoint tenants running code against Graph API), it’ll mess up the authentication. You’ll be trying to use the wrong tenant’s info automatically – and there’s very little you can do about it by default!
The solution is simple – you’ll just need to clear the browser’s local storage. Below, I’m showing what to remove in case you’re using Google Chrome. You’ll need to hit F12 to open developer tools, browse to the “Application” tab, and then find your tenant from the “Local Storage” -section.
Application Storage – ADAL-related properties. Go ahead, and remove them all – that should do the trick!
After removing all the storage entries for ADAL, refresh the page that threw the error before, and you should be greeted with a fresh, neat login screen!
Azure AD account selection.
At this point, whatever you’re selecting, will then be cached for your browser, and used automatically the next time you try to log in again.
Solution 2: You’re not crafting the authentication request properly. Fix it.
Okay, so let’s take another look at the authentication URL, shall we?
So, quite a while after the original issue I documented, I encountered another way to mess up. Apparently, a careless developer might be crafting the query based on the email address of the user. However – that is not necessarily what you need to use!
The email in question needs to be the UPN of the user, not an email address. So wherever you’re picking your user’s account name from, make sure to not use “just” an email address – fetch the UPN instead.
So, that’s the 2 things to check. For now, you should be good!
Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
