Get-MsolServicePrincipalCredential - how to get the expiration date for a clientId

Fastest way to verify your Client Id and Client Secret are valid with PowerShell

This post was most recently updated on June 15th, 2021.

4 min read.

So, you have a Client Id and a Client Secret, but don’t know if they work anymore? Maybe they are expired? Maybe someone removed them? No worries! We can use PowerShell to validate them easily!

This article explains a simple way to validate and debug your client id and client secret using PowerShell.


By using PowerShell, it’s fairly straightforward to verify, that your Client Id and Client Secret work.

Time needed: 10 minutes.

How to verify your Microsoft 365 / Office 365 Client Id and Client Secret are valid using PowerShell?

  1. First we validate, that the values work.

    This can be done by running a simple PowerShell script, as shown here:

  2. If they’re invalid, validate the expiration

    If they don’t work, let’s run another script to see if the Client Id exists but has expired. A snippet for that is shown here:

  3. If you’re having issues in general, verify other configuration issues

    Of course plenty of other things could go wrong as well! See this part of the article for some additional pointers:

See the snippets below for the 2 different steps:

Validate your Client Id by trying to connect with it

We can validate the Client Id and Secret, by using Connect-PnPOnline to connect to SharePoint Online. 

In other words, in the example, I’m using the PnP PowerShell commandlets to authenticate against a SharePoint Online site, using a Client Id (called AppId) and a Client Secret (called App Secret).

# First, we install the PnP cmdlets in case we don't have them already
Install-Module SharePointPnPPowerShellOnline

# If you have them, let's import the module!
Import-Module SharePointPnPPowerShellOnline

# After this, we can run Connect-PnPOnline
Connect-PnPOnline -Url [your_sharepoint_site_url] -AppId [clientId] -AppSecret [clientSecret]

This shouldn’t return anything. If it doesn’t, it means the AppId (or “Client id”) and AppSecret (“Client Secret”) are valid.

However, that doesn’t necessarily mean it works for your use case exactly. A good thing to try might be to try requesting the current SPWeb object to see, if you have permissions to access it. See an example below:

# Running the command below will return information about your context - pay attention to the "AuthenticationMode". It shouldn't be "Anonymous".

PS C:\> Get-PnPContext

RetryCount                   : 10
Delay                        : 1000
PropertyBag                  : {}
Web                          : Microsoft.SharePoint.Client.Web
Site                         : Microsoft.SharePoint.Client.Site
RequestResources             : Microsoft.SharePoint.Client.RequestResources
FormDigestHandlingEnabled    : True
ServerVersion                : 16.0.8720.1220
Url                          :
ApplicationName              : SharePoint PnP PowerShell Library
ClientTag                    : 
DisableReturnValueCache      : True
ValidateOnClient             : True
AuthenticationMode           : Default
FormsAuthenticationLoginInfo :
Credentials                  : Microsoft.SharePoint.Client.SharePointOnlineCredentials
WebRequestExecutorFactory    : Microsoft.SharePoint.Client.DefaultWebRequestExecutorFactory
PendingRequest               : Microsoft.SharePoint.Client.ClientRequest
HasPendingRequest            : False
Tag                          :
RequestTimeout               : 1800000
StaticObjects                : {[Microsoft$SharePoint$SPContext$Current, Microsoft.SharePoint.Client.RequestContext], [
                               Microsoft$SharePoint$TenantSettings$Current, Microsoft.SharePoint.Client.TenantSettings]
ServerSchemaVersion          :
ServerLibraryVersion         : 16.0.8720.1220
RequestSchemaVersion         :
TraceCorrelationId           : 

# The one below fetches the current web, and shouldn't throw an error either.
PS C:\> Get-PnPWeb

Title       ServerRelativeUrl  Id
-----       -----------------  --
Test /sites/test

In case that didn’t work, your principal might have expired, or your values are simply not valid. This should lead to an authentication error!

"connect-pnponline : Token request failed." when running Connect-PnpOnline with AppId and AppSecret.
“connect-pnponline : Token request failed.” when running Connect-PnpOnline with AppId and AppSecret.

Check your Client Id’s expiration date

To verify that the Client Id hasn’t expired, but rather is still valid, we’ll query the service principals in PowerShell using some of the available cmdlets. See below for different options…

Azure AD v1 (MSOnline)

You can run this in SharePoint Online Management Shell or Windows PowerShell:

# First, we install the cmdlets in case we don't have them already
Install-Module MSOnline

# If you have them already, let's import the module!
Import-Module MSOnline

# Then connect 
(Get-MsolServicePrincipalCredential -AppPrincipalId [clientId] -ReturnKeyValues $true).EndDate.ToShortDateString() | select -first 1

This (almost) one-liner will get all valid entries with your clientId (it’ll probably return 3 service principals), then fish out their end dates, and pick the first one.

You should get just a short date in response.

But wait! What if you don’t have MSOnline (Azure AD v1 cmdlets) installed? What if you hate legacy technology, and want to only use the coolest new commandlets? I actually got a question about this on Twitter – how to query the end date with Azure AD v2 cmdlets?

Azure AD v2 (AzureAD)

It’s not that difficult, luckily! See below for a script sample:

# This is only needed, if you don't have AzureAD (v2) cmdlets installed already
Install-Module AzureAD

# If you have them already, we'll import the package
Import-Module AzureAD

# Then we connect, and query for the service principals
(Get-AzureADServicePrincipal -All $true -Filter "appId eq '[clientId]'").KeyCredentials.EndDate.ToShortDateString() | select -first 1

Not that complicated either! You should get just a short date in response.

Note that you’ll need to use single quotes for the filter statement – otherwise PowerShell will fail miserably at parsing your filter!

Other configuration issues

This section contains some notes on what other things can go wrong.

TLS deprecation 😬

If you’re getting errors somewhat like the ones below:

The underlying connection was closed: An unexpected error occurred on a send.

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

Check out this blog post:

ClientId and ClientSecret are valid but authentication fails for all add-ins?

Your tenant might’ve been hit by the CustomAppAuthentication -issue, as Peter points out in the comments. I’ve posted about the solution here:

Note on ClientId and ClientSecret

If you ended up on this page looking for instructions on how to generate client id and client secret in SharePoint Online, please note that nowadays you can either register them directly in SharePoint or simply create them in Azure AD like any app principal. The latter model is definitely the recommended way, as you can specify it to never expire (if you’re using PowerShell, or 2 years if you’re using the GUI) and have better control and transparency of your app anyway.

There are awesome articles online about this already, so I’m not going to explain it further – this blog post by Microsoft MVP Sergei Sergeev describes the steps really well, so check it out instead!


  • See the documentation for Connect-PnPOnline here.
  • Check out the docs for
    • AADv1 command Get-MsolServicePrincipalCredential here
    • AADv2 command Get-AzureADServicePrincipal here
  • See more information about SharePoint PnP commandlets here.
5 1 vote
Article Rating
Notify of
most voted
newest oldest
Inline Feedbacks
View all comments