Managing expiration of Azure Active Directory Application Client Secrets

Hi,

As I am more and more using Azure Active Directory Applications to consume online services such as SharePoint Online, Yammer etc., I found myself annoyed with the duration of the client secrets.

As you know, when creating an app from the UI, you can set permissions and create a secret key with the GUI:

but it only lets you chose either 1 year either 2 years with a startdate being the creation date.

My goal is to prevent certificate/secrets etc. expiration to impact business applications. I want the AD team to seamlessly renew those things for me in a transparent way. They have more control and the application doesn’t hold the secrets/pfx on its side. Keyvault is perfect for that but the problem is that you need a client/secret combination to connect to it given you connect as an app and therefore that secret should be known by the business application…which is very annoying since these secrets expire soon or later.

So, I found a workaround to extend (could also make it shorter) the duration of the secret key specifically created to access keyvault (and nothing else). With the double security check (AD first and keyvault’s own authorizations), I don’t think it’s a problem to extend the duration of the key.

To do that, you can create the key the usual way as shown by the above screenshot and you copy the secret value when saving the changes. After that, you download the app manifest and you should see something like this in the manifest:

"passwordCredentials": [
    {
      "customKeyIdentifier": null,
      "endDate": "2016-01-13T15:45:11.9881092Z",
      "keyId": "b9865f07-c4de-404b-b492-1f1fefdf5767",
      "startDate": "2014-01-14T14:45:11.9881092Z",
      "value": null
    }
  ],

the value is set to “null” to avoid disclosing the secret. So, from there on, you can empty the passwordCredentials like this:

"passwordCredentials": [   
  ],

and you reupload the manifest as this is required to remove the key first! Afterwards, you can modify the passwordCredentials block again this way:

"passwordCredentials": [
    {
      "customKeyIdentifier": null,
      "endDate": "the end date you want",
      "keyId": "b9865f07-c4de-404b-b492-1f1fefdf5767",
      "startDate": "2014-01-14T14:45:11.9881092Z",
      "value": "the value of the copied key"
    }
  ],

and you reupload the manifest to overwrite it. That will let you specify the end date of your choice. To make sure there was no side effect, I tested all the scenarios (extending, defining an expired end date) and consumed the API using that clientid/secret combination and all behaved as expected.

As I didn’t find any info about that, I thought it could be a good idea to share this tip!

Update September 2016 : it is now possible to chose an infinite expiration date from the New Portal. Behind the scenes, it’s actually not infinite but it sets a date very far in the future. Note that the above technique still works. Also note that the manifest can also be changed directly from the New Portal and downloading it isn’t required anymore

Happy Coding

Advertisements

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Azure Active Directory and tagged , , . Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s