How to fix AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.

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 login page. Luckily, at least in my case, this was easily fixed! Your error might look something like this:

Request Id: <guid>
Correlation Id: <guid>
Timestamp: 2018-04-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:<guid>&<tenant><site>&state=<guid><guid>&x-client-SKU=Js&x-client-Ver=1.0.14&prompt=none&

So.. Wait a minute. The log-in 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.

Solution: 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 “Application” tab, and then find your tenant from the “Local Storage” -section.

Application Storage - ADAL-related properties
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
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.

So, for now, you should be good!

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!