I am managing a Provider-Hosted SharePoint App/Add-in and the Client Secret that we use to authenticate with SharePoint is due for expiration soon. 3 years ago, when the previous Client Secret was about to expire, we created a new one using the process documented here: https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in However, when the original Secret expired, the site went down, because the new Secret was not working for some unknown reason. We created a new Secret and waited 24 hours for it to propagate before the site resumed working.

In order to avoid an outage this time, I'd like to somehow validate that the new Secret is working before the old one expires. Problem is, according to the documentation and my personal experience:

  1. The new Client Secret will not be valid/usable for 24 hours, because it must be propagated to SPO
  2. The new Client Secret cannot be used until the old Client Secret has expired.

So if I create a new Client Secret, I have to wait until the old one expires to see if it is working and if I need to create a 2nd new Client Secret, I will have to wait an additional 24 hours to see if that works.

So how can I get a new Secret set up without risking a 24 hour or longer outage?

1 Answer 1


You can automate secret rotation with help of Azure Key Vault and Azure function.

below are high level steps

  • Azure Function will be triggered by azure key vault's "Secret near expiry event".

  • Azure function will have PowerShell or code that will generate and create new version of key in Azure key vault.

For more details refer this Microsoft docs

$startDate = Get-Date
$endDate = $startDate.AddYears(3)
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId f254eafb-5a7a-4df4-b9f4-ec0b70d5717e -CustomKeyIdentifier "Secret01" -StartDate $startDate -EndDate $endDate
  • Unless I'm mistaken, the keys for SharePoint Apps/Add-ins cannot be managed using Azure AD. They can only be managed either when setting up the app at /_layouts/15/appregnew.aspx or by using the MSOnline Powershell utility.
    – J Waltz
    Feb 9 at 13:18
  • this approach "/_layouts/15/appregnew.aspx" is sunset by Microsoft instead use azure ad app registration. Feb 9 at 13:26
  • Can you link me to some documentation on how to set up a SharePoint App using the Azure AD approach? I know I can register and App in AD and connect it to SharePoint from there, but it doesn't seem like that would work with the existing SharePointContext code used in the SharePoint provider-hosted Apps. Does that require a code rewrite to use the AD approach?
    – J Waltz
    Feb 9 at 13:57
  • Yes it will require one new method, for getting the context. Feb 9 at 14:16
  • Did you find an answer to this J Waltz?
    – Brandon P.
    Feb 28 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.