Office 365 – AADSTS50008: SAML token is invalid

If you’ve made it to this post because you are troubleshooting your AD FS sign in with Office 365 due to “AADSTS50008: SAML token is invalid” I still recommend you do all the standard troubleshooting steps provided in this article below the image:

https://support.microsoft.com/en-us/kb/3015526

Generally speaking, if you’re getting issued a token from your AD FS server and Microsoft’s STS is stopping you from logging in, it would be because of your token signing certificate:

Has your Token-Signing Certificate changed since you last told Microsoft?

It’s never a bad idea to re-run the following:

Executing this MSOL cmdlet will get Microsoft’s STS service to check your Metadata, which in turn will update any certificate changes you may have made. If you’re really clever you can go to your WS-Federation Metadata and check what you’re telling the world is your public token signing certificate.

1. Navigate to https://<AD FS Namespace>.com.au/federationmetadata/2007-06/federationmetadata.xml in Internet Explorer.
2. Search for KeyDescriptor use=”signing” in the metadata document.
3. If you copy the raw certificate data from <X509Certificate> into a text file and save with extension ‘cer‘ you can validate it matches what’s in your AD FS console > Service > Certificates > Token-Signing

Good, we have that under control. I experienced an issue the other day where I still got the error post running this cmdlet and performing the above nifty check….. Head scratches. Firstly, I know that my AD FS services has processed my sign on attempt and given me the required information to take to Office 365 and log in. Secondly, I know that my signing certificate is correct. Still the error remains;

We received a bad request.
Additional technical information:
Correlation ID: 82121251-3634-4afb-8014-fb5298d6f2c9
Timestamp: 2016-03-04 00:25:35Z
AADSTS50008: SAML token is invalid

My issue was a little unique but worth a notable mention on the internet. In my scenario, If I left my browser page up with the error shown above for a length of time, suddenly if my browser refreshed I would get dropped into whatever it was I was trying to authenticate to. So my authentication was successful with Microsoft after a point in time. I highlight those words cause I literally had to say them out loud to myself before I found the fix. Looking at the AD FS servers where my token is issued from, I took a quick look at the time. I then took a look at the time on the AD workstation I was trying from, they both seemed to be in synchronisation with each other.  What about from my BYOD Surface that I use at Kloud which uses a internet time source?

Great Scott! 7 minutes difference!

My token was being accepted by Office 365, but only once Microsoft had caught up to the future from which I had came from. This isn’t unreasonable from Microsoft to not allow my issued token until that time had actually happened in Microsoft cloud land. This wasn’t an issue that showed its face as easily with internal applications as all domain controllers and workstations were following orders from the time source in the domain. The problem was that the domain couldn’t synchronise with a internet time source at the time master. So it was slowly but surely sneaking ahead. Once we had come back from the future, the issue with ‘AADSTS50008: SAML token is invalid’ was resolved and authentication was instantaneous on the first attempt once again.

I don’t want to put the fear of the ‘internet time gods’ on you, I believe that there is some kind of threshold that Microsoft will allow. Just not in 10 minutes time or maybe tomorrow, in the future.  Possibly the magic number for token timestamp issuance is plus or minus 5 minutes. Once I rolled the AD FS servers time back within a couple of minutes/seconds of the internet time gods, tokens were accepted. Now over to the AD and Network teams to restore order on a wider scale.