The next authentication flow in my series will be the Client Credentials Flow. Be sure to check out the first one here! We will first take a look at the client secret model. I will skip the basics in this article as this has been explained in my other article.

Above you can see this flow provided by the OAuth docs. It's a lot simpler then the Authorization Code Flow, however this is inherent because it is a non-interactive sign-in flow meaning mostly used by daemons, services, etc... There's only one step and it's the exchange of your client secret or a JWT (JSON Web Token) for an access token.

You will see when my next article about the certificate flow gets released, that the client secret flow is very straightforward. Do note to use these flows we have to create our own App Registrations, we can't use the Azure Powershell or Graph Powershell ones as the secrets or certificates have to be uploaded!

The client secret maximum longevity can be only 2 years when being created via the portal. Via Graph / Powershell it can be as long as you want, however, try to avoid this flow as this requires you to store this secret which can be easily stolen.

This is probably the simplest script in this series. It's just one API call towards the /token endpoint

		
Code loading...
      	
    

A quick look at the rather simple client secret flow for machine-to-machine communication. However as it stands for most applications Federated Credentials or Managed Identity can provide a secret-less solution which is more secure!