If you follow changes in Microsoft Graph as I do, you may have noticed that you can now create client secrets during the creation of your App Registration in Microsoft Entra when using the Microsoft Graph API. This helps to streamline the creation of apps and where necessary create a client secret at the same time, all in a single request to the Microsoft Graph API.
Use cases
Client secrets are not always the preferred method to connecting to Microsoft Graph, or any other API for that matter. Actually, the best and most secure method is to use a Managed Identity, however, that method is reserved for resources that live within your Microsoft tenant. Actually, most resources external to your Microsoft tenant will rely on either a client secret or a certificate to connect to your application in the app-only context. On the contrary, the delegated context will use your own login credentials, as well as the multi-factor authentication method. In most scenarios, the most common use-cases for client secrets are the following:
- Testing scenarios
- Temporary application access
- Modern SMTP servers using OAuth2 (printers and applications)
- Portable PowerShell scripts (such as an Autopilot registration script)
Requirements
The requirements for creating a client secret during app registration are the same as creating an application without a client secret, you just need the Microsoft Graph SDK installed and ability to consent to the application.readwrite.all permission as a Global Administrator. At this point I suggest you head over to my post titled ‘Register New Applications With Microsoft Graph PowerShell‘. In that post, I go into more detail on the requirements and additional options you have when registering an application.
Generating a client secret during app registration using the Graph API
Whether or not you like to use PowerShell, it is important to understand how the underlying API performs these actions. Below is the minimum amount of information needed to create a new application with a client secret using the Graph API.
POST https://graph.microsoft.com/v1.0/applications
Content-type: application/json
{
"displayName": "Ourcloudnetwork App",
"passwordCredentials": [
{
"displayName": "A new client secret"
}
]
}
This code can be easily copied and pasted into the Microsoft Graph Explorer to demonstrate how it works. Below you can see a successful response which includes the value of the client secret.
Generating a client secret during app registration using PowerShell
The same approach can be used with PowerShell. Below I use Microsoft Graph PowerShell, taking advantage of the Invoke-MgGraphRequest cmdlet, to generate a new app registration with a client secret.
Connect-MgGraph -Scopes Application.ReadWrite.All
$body = @{
displayName = "Ourcloudnetwork App"
passwordCredentials = @(
@{
displayName = "A new client secret"
}
)
}
$App = Invoke-MgGraphRequest -Method POST -Uri "/v1.0/applications" -Body $body -OutputType PSObject
To extract the client secret from the response, use dot notation, like so:
$App.passwordCredentials
From the console, the client secret can be simply extracted.
If you don’t like using the Invoke-MgGraphRequest cmdlet, you can also use the New-MgApplication cmdlet, like so:
$credential = @{
displayName = "A new client secret"
}
New-MgBetaApplication -DisplayName "Ourcloudnetwork App" -PasswordCredentials $credential
Setting a custom expiry date for the client secret
By default, when you create a client secret during app creation using the examples I have provided above, the secret password has a lifetime of 2 years. This is far beyond the recommended lifetime by Microsoft and does not align with the default behaviour when creating an application from the web portal, something I have raised with the Microsoft Graph product team.
To set a default expiry date on your client secret, use the below example and modify the start and end dates.
$credential = @{
displayName = "A new client secret"
endDateTime = "2024-10-23"
startDateTime = "2024-04-26"
}