Invalid issuer o signature error in SPO Provider-Hosted AddIns affecting Remote Event Receivers

[jcgonzalezmartin]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

we are having problems with SPO Provider-Hosted Add-Ins were we are using remote event receivers...all of these Add-Ins were working last week, but have stopped working Today. Could you please help us with identifying what's happening? We are seeing the problem in 4-5 tenants and with 2-3 different applications. I have attached a document with the troubleshooting we have done and also our findings. As you can imagine, it's quite urgent for us to get information and a workaround about how to fix it...we also opened a support case, but support folks told us that they don't provide help for this kind of issues. Thanks in advance!

Observed Behavior

Starting Today, several of our customers are experiencing problems with SPO Provider-Hosted AddIns when getting the Context Token. The generic error we get is the following one: Invalid issuer o signature. Of course, we have already verified that this is not a problem with expired client secrets

Steps to Reproduce

I have included a document explaining all the troubleshooting we have done and also our findings

Submission Guidelines

Invalid_isuer_or_signature_error_in_SPO.docx

[OliverZeiser]

We are seeing the same issue. It looks like MS is posting back the wrong URL. In our case the application is hosted on azure and the url is https://xxxx.azurewebsites.net/services/service.svc. But the URL in OperationContext that MS is sending is https://xxxx/services/service.svc, so the domain seems to get lost.

[jcgonzalezmartin]

Thanks Oliver,
Just exactly what is causing the exception and so far we have not found a way to solve it. If you find a solution, please post it here. I will do the same.

[OliverZeiser]

We have changed to an app-only context in our case for now. This is working and we don't really need a user context. But this might not be a solution in your case...

[jcgonzalezmartin]

Thanks Oliver, we have done this for some cases, but as you well mention this change is not OK for other cases where we need the user context

[AGerben]

We have experienced the same issue and found that this only occured for Client Secrets created using the New-MsolServicePrincipalCredential Cmdlet. We could not get support on this issue either. Our workaround is as follows:

1. Fully remove the serviceprincipal (Remove-MsolServicePrincipal)
2. Register the app again on appregnew.aspx, using the same Client ID

[jcgonzalezmartin]

Hi again Oliver,
It seems we are not alone with the issue and there is also another posible workaroudn we have no tested yet: https://techcommunity.microsoft.com/t5/SharePoint-Developer/Invalid-issuer-o-signature-error-in-SPO-Provider-Hosted-AddIns/m-p/165697#M4444

[OliverZeiser]

This is not an option for us because we are already using Secondary ClientSecret which has to be created via Powershell...

[jcgonzalezmartin]

We have tried this and worked partially after doing a hack in the TokenHelper class...but this hack is not applicable to other customer experiencing this same error

[jcgonzalezmartin]

Sincé I have received a small update in other channel where we have reported our issue, I wanted just to confirm that the workaround mentioned by @AGerben does not work for us so 4 days later our customer cannot use the App due to this issue

[jcgonzalezmartin]

Steps_To_Reprocuce_AddIn_Error_Invalid_Issuer_Or_Signature.docx
Just for the reference to anyone having this issue, I have attached here the steps to reproduce the issue we are having

[matmig]

We have the same issue on our North Europe Tenant. 2 Provider Hosted Add-Ins (with Remote Event Receiver) stopped to work 3 days ago. Locally Add-In is working fine, but after deploying to Azure Web App, SPRemoteEventType.AppInstalled is not working. We are using AllowAppOnlyPolicy="true" in all add-ins.

[Suresh-Meenakshisundaram]

The Invalid AudienceUri exception is happening due to, the context token carries abc**.azuresites.net**, the host url gives only abc. Hence it is failing in audience validation. . Use web.config’s HostedAppHostNameOverride in appsettings like which solves the issue. Seems like something happened on the azure side for host machine name, though not 100% sure.