Manan Shah
Lead Engineer
Manan Shah is a seasoned SharePoint Developer at Nitor Infotech. From custom workflows to seamless integration with Microsoft 365 services, he is... Read More

In the ever-evolving landscape of digital collaboration and data management, SharePoint has emerged as a pivotal platform, revolutionizing the way organizations handle information. Developed by Microsoft, SharePoint provides a robust framework for creating, sharing, and managing content and applications, fostering seamless collaboration within teams.

It has truly become a linchpin for businesses aiming to boost productivity and maintain organized digital ecosystems. Well, not always! The need for custom applications and services to interact with SharePoint Online without user authentication often makes it a difficult road for organizations to counter. Such a gap prompted the development of SharePoint App-Only principles.

What is SharePoint App Only?

The SharePoint App-only principles operate on the OAuth 2.0 protocol, offering a secure means to programmatically access SharePoint resources. To leverage this capability, one must register an application in Azure Active Directory (Azure AD) and subsequently grant the requisite permissions for accessing SharePoint resources seamlessly.

Note – For the Online SharePoint user, understanding the significance of the Client ID and Client Secret becomes paramount. These credentials play a pivotal role in authenticating applications and services seeking access to SharePoint Online.

My blog today will make you well-versed with the concepts of Client ID and Secret. Also, it will guide you through the process of setting up your Client ID and Secret in SharePoint Online and focus on the best practices for you to follow.

Keep reading for a special bonus section waiting to be explored!

What is a Client ID and Client Secret?

A Client ID and Secret serve as credentials, authenticating an application or service to access SharePoint Online. The Client ID, a unique identifier, and the Secret, a password/token,

authenticate the application, crucial for making calls to SharePoint Online API and accessing platform data.

This dynamic duo not only identifies and authenticates the application but also ensures a secure layer, permitting access exclusively to authorized applications. The Client ID and Secret’s multifaceted role safeguards the integrity of SharePoint Online API. Thus, emphasizing their pivotal function in securing and enabling seamless access to SharePoint resources for authenticated applications.

Now that you grasp the basics, let’s dive into the process of setting up Client ID and Client Secret.

Steps to Set up Client ID and Client Secret

Below are the crucial steps you must adhere to:

Step 1: Log in to the SharePoint site and append the URL with appregnew.aspx. For example: https://yoursite.sharepoint.com/_layouts/15/appregnew.aspx

Log in to SharePoint

Step 2: Click on the Generate button to generate the Client ID and Client Secret and add the

below details –

Title: It will be the name of the Application. In this case, it is TokenBasedApp.

App Domain: You can provide www.localhost.com as we are not redirected. Redirect URL: You can provide https://www.localhost.com as we are not directed to any page or application after authentication.

Generate button

Step 3: By clicking on next, it will provide the Client Secret and Client ID with the Application name and URL. Please store it in Notepad for Reference.

Step 4: Next, you need to update the URL to find the above app, by appending with /_layouts/15/appinv.aspx

For example: https://yoursite.sharepoint.com/sites/o365poc/_layouts/15/appinv.aspx

Now search by the Client ID that you just noted down and click ‘Lookup’. It will auto-populate app details.


Step 5: Now we will need to update the ‘App’s permission request XML’. This is an important step to tell this app what kind of rights your client application needs. The permission XML follows the structure provided below:

<AppPermissionRequests AllowAppOnlyPolicy="true"> 
<AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

Additionally, be aware that the following rights can be specified:

  • Full Control
  • Write
  • Read
  • Manage

After updating the access, click on the ‘Create’ button.

Step 6: Then, you will be asked for consent. Click on ‘Trust It’.

Trust It

Following these steps completes the process of establishing the Client ID and Client Secret, granting your client application ‘Full Control’ access to the SharePoint site.

Next, allow me to assist you in building the client application.

Creating the Client Application

Here’s a guide to creating your client application in just 4 easy steps:

1. Open Visual Studio and create a blank console application project based on .Net Framework.

Blank console application project

2. Now go to “Tools” -> “Manage Nugget Packages for the solution.”

Manage Nugget Packages

Note: In the Nuget Packager console it is required to install the following packages



3. Then, add the App.config file to the project.

App.config file

Update the app.config with the provided code, ensuring to substitute the placeholder values with the Client ID and Client Secret generated during the setup process:

<?xml version="1.0" encoding="utf-8" ?>
<add key="ClientId" value="Client Id Value"/>
<add key="ClientSecret" value="Client Secret Value "/> <add key="SiteUrl" value="https://cts229051.sharepoint.com/sites/o365poc"/>

4. Finally, click on program.cs and have the below code pasted:

string site_Url = ConfigurationManager.AppSettings["SiteUrl"];
string client_ID = ConfigurationManager.AppSettings["ClientId"];
string client_Secret = ConfigurationManager.AppSettings["ClientSecret"]; using(ClientContext context = new AuthenticationManager().GetACSAppOnlyContext(site_Url, client_ID, client_Secret)) {
context.Load(cc.Web, p => p.Title);
Console.WriteLine( context.Web.Title);

Now, to streamline and execute the entire process effectively, take a brief look at the recommended best practices.

Optimal Practices for Handling Client ID and Client Secret in SharePoint Online

Follow best practices and security recommendations provided by Microsoft to ensure you’re using SharePoint Online in a secure and supported manner.

1. Limiting Access Permissions

– Grant the minimum necessary permissions to each client application.

– Avoid granting excessive or overly permissive access.

– Follow the principle of least privilege to restrict what actions and data the client can access.

– Use role-based access control (RBAC) and SharePoint Online permissions to finely tune access for clients.

2. Secure Storage of Information

– Store Client IDs and Secrets in a secure location that is inaccessible to unauthorized personnel.

– Consider using Azure Key Vault or a similar secure storage mechanism to protect sensitive information.

– Implement strong access controls and encryption to safeguard stored data.

3. Regularly Updating Secrets

– Periodically rotate Client Secrets. The frequency of rotation can depend on your organization’s security policies, but typically, secrets should be rotated every few months.

– When secrets are rotated, ensure that all dependent services and applications are updated with the new secrets.

– Revoking and replacing secrets when compromised or outdated is crucial for maintaining security.

4. Implement Multi-Factor Authentication (MFA)

– Enforce MFA for all user and client access to SharePoint Online.

– This adds an extra layer of security by requiring users and clients to provide a second form of verification, such as a text code or biometric data, in addition to a password or Client Secret.

– It significantly reduces the risk of unauthorized access, even if credentials are compromised.

5. Documentation and Guidance

– Stay informed about Microsoft’s official documentation and guidance for managing Client ID and Client secrets.

– Microsoft regularly updates its security recommendations, so keeping up to date is essential.

Here’s a BONUS for you – To get you the whole idea of moving towards SharePoint App-Only, I’ve jotted down a major difference below.

Take a look!

Using a Client Secret and Client ID VS. Using a Username and Password

Aspect  Client ID and Username/Password  Client ID and Client Secret 
Security  Usernames and passwords are sensitive and can be intercepted or misused.  Client secret is known only to the application and the authentication server, reducing the risk of unauthorized access. 
Least Privilege  Requires exposing user credentials; goes against the principle of least privilege.  Enables granting specific resources and permissions without exposing user credentials, aligning with the principle of least privilege. 
User Experience  Asking users for their credentials may lead to a poor user experience and potential phishing vulnerabilities.  OAuth with client credentials doesn’t require users to share their credentials, improving the user experience and reducing phishing risks. 
Revocable Access  Revoking access involves handling user credentials and impacting the user’s login credentials.  Revoking access is simplified by disabling or regenerating the Client Secret, providing more control over the application’s access without affecting user credentials. 
Single Sign-On (SSO)  Not inherently part of a single sign-on solution.  Can be integrated into a single sign-on (SSO) solution, allowing users to authenticate once for access to multiple applications. 
Compliance  Use of shared usernames and passwords may conflict with security and compliance standards (e.g., GDPR).  Aligns with security and compliance standards, as OAuth-based authentication is favored for improved security and auditability. 

So, the App-Only Approach stands out with approximately 80% as the preferred choice for accessing SharePoint resources, ensuring a balance between robust security measures and a seamless user experience. However, in the remaining 20% of cases where specific requirements dictate, the username and password approach may be considered.

Therefore, the key is to align the authentication method with the precise needs of the organization to achieve an optimal balance between security and usability. To know about specific use cases and insights into the SharePoint App-Only approach, stay tuned for our upcoming blogs.

Additionally, reach out to us and stay abreast with the cutting-edge tech pioneers Nitor Infotech.

subscribe image

Subscribe to our
fortnightly newsletter!

we'll keep you in the loop with everything that's trending in the tech world.

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Accept Cookie policy