Provider Hosted App Error – Invalid issuer or signature persists after update

The Client Secret for one of our provider hosted apps expired yesterday and we started receiving the expected “[SecurityTokenException: Invalid issuer or signature.]” error.


This happens every 12 months as the secret key by default expires 12 months after it is generated. When you create Provider/Remote Hosted app you have to generate a Client ID and Secret ID for your app. These are used as part of the technique for ensuring the app can only be accessed from your Office 365 tenant and by someone who is authenticated against it. The problem is that unless you make a note in your calendar 12 months in advance you wont know the client secret is about to expire as the system wont warn you.

The expiration hasn’t been a issue in the past as I understand the process of generating a new key and updating the app (e.g. This example plus updating the app config through Azure has worked before). The problem is that I worked through the process yesterday and the error was still occurring.

Most of the information I’v seen regarding updating the key says that it can take anywhere up to 24 hours for the change to propagate within the O365 and Azure environments. Whilst this hasn’t be the case in previous years I waited over 12 hours and there was no change to the problem. I checked the app principal and confirmed that the keys had propagated using the following PowerShell

Get-MsolServicePrincipalCredential -AppPrincipalID {YOUR-CLIENT-ID} -ReturnKeyValues 1

After some further research I found a blog post from Microsoft Developer Support that described almost exactly the issue we were experiencing.

I first tried removing the numerous expired client secrets to leave only the new valid one using the following PowerShell

Remove-MsolServicePrincipalCredential -AppPrincipalID {YOUR-CLIENT-ID} -KeyIds @("{KEY-GUID-1}","{KEY-GUID-2}","{KEY-GUID-3}")

This made no difference to the issue so I did the following:

  1. First I removed the remaining, valid, client secret from the app principal using the PowerShell above,
  2. next I checked the app principal again using the first PowerShell cmdlet above to confirm that there were now no keys associated with the app,
  3. I then generated a new Client Secret key,
  4. checked the app principal using PowerShell again and verified the new key was there,
  5. updated the Client Secret in the apps web.config  as well as the Application Settings of the Azure web app with the new key. This is required specifically when you are hosting the app in an Azure Web Application,
  6. I then published the web application to the Azure web app so that the web.config was deployed.

After following these steps provider hosted app was working again and I was able to access an run it with no issues.


Leave a comment

Filed under Office 365, SharePoint, SharePoint Online

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s