Compartilhar via

Provider Hosted App fails on SPO

  • Artigo

This post is a contribution from Pavan Kumar, an engineer with the SharePoint Developer Support team 

Recently worked with a customer who had deployed a Provider hosted App to their Sharepoint O365 tenant and the remote web was an IIS website which was OnPremise. The App worked fine for a while and it started to fail after sometime with following error

Invalid issuer or signature.

at Microsoft.IdentityModel.S2S.Tokens.JsonWebSecurityTokenHandler.VerifySignature(String signingInput, String signature, String algorithm, SecurityToken signingToken)

at Microsoft.IdentityModel.S2S.Tokens.JsonWebSecurityTokenHandler.ReadTokenCore(String token, Boolean isActorToken)

at ECompliance.ApplicationForms.TokenHelper.ReadAndValidateContextToken(String contextTokenString, String appHostName)

at ECompliance.ApplicationForms.TokenHelper.GetClientContextWithContextToken(String targetUrl, String contextTokenString, String appHostUrl)

at ECompliance.ApplicationForms.Masters.AppInitiator.Page_Load(Object sender, EventArgs e)

By executing below command we identified that the Client Secret had expired

Get-MsolServicePrincipalCredential -AppPrincipalID "<ClientID> as outlined in this article.

We created a new Client Secret and used that in the web.config file of the Remote Web, but the issue persisted.

We used below command to remove all the client secrets which were already available including the expired one.

Remove-MsolServicePrinicipal -AppPrincipalId "<ClientID>" -KeyIds "<GUID>"

Refer to this article to get more information about this command.

We created a new client secret and added it to the web.config file. Refer to this article on how to create and update to use new client secret.

After creation and updating to new client secret we will have to wait for 8 hours for this to work.

Reason for this 8 hour wait is Sharepoint Online servers are in PST time zone and Azure is in UTC time zone. Time difference between PST and UTC is 8 hours.

We tested the App after 8 hours and issue resolved.

Hope this post helps if you happen to hit this issue at some point in time !!!

Comments

  • Anonymous
    January 05, 2017
    Thanks for this, I found the deleting of old tokens the way that solved this same issue for me. One tweak I made was to set the -StartDate and -EndDate when setting the new client secret. That way, using $startDate = (Get-Date).AddDays(-1) to create a start date in the past and then adding on the duration (we used 3 years) for the end date $endDate = $startDate.AddYears(3) allowed us to be able to use the secrets straight away.