Microsoft Entra ID (Azure AD) SSO: Client-managed setup

This article guides setup of Microsoft Entra ID (Azure AD) as a client-managed identity provider for signing into Finalsite, including what to register in the Microsoft Entra admin center and which values to send to Finalsite to complete the connection.

💡Quick answers

  • What is this setup used for? Signing into Finalsite using a Microsoft work or school account, with the school's own IT team keeping full control over the connection.
  • Which protocol does it use? OAuth 2.0 and OpenID Connect (OIDC), an industry-standard way for one system to confirm a user's identity to another without sharing a password. This connection does not use SAML.
  • What access is needed before starting? Administrative access to the school's Microsoft Entra ID tenant, permission to register a new application, and permission to grant API permissions, or access to a colleague who can.
  • What does Finalsite need at the end of setup? Three values: the Application (client) ID, the Directory (tenant) ID, and a client secret value, sent over a secure channel rather than email.
  • What happens when the client secret expires? Microsoft limits secret lifetimes to 24 months. Once one expires, sign-in stops working until a new secret is generated in Microsoft Entra and sent to Finalsite.
  • Is this the only way to set up Microsoft sign-in? No. Schools that do not need this level of control can use the Quick Setup with Finalsite option instead, which requires no configuration on the school's side.

Microsoft Entra ID, formerly known as Azure Active Directory, is Microsoft's cloud identity service. Not familiar with it? Microsoft's own overview of Microsoft Entra ID covers what it is and how organizations typically use it. Setting it up as a client-managed identity provider lets a school's own IT team register and control the connection Finalsite uses to check who someone is, rather than relying on a connection Finalsite manages by default.

This guide walks through registering an application in the Microsoft Entra admin center, generating the values Finalsite needs, and where to go if something stops working.

In this article


Am I eligible, and how does this work?

This setup is available to schools that manage their own Microsoft 365 or Microsoft Entra ID environment and want full control over the connection Finalsite uses to sign users in. Schools that do not need that level of control can skip this guide entirely and request the Quick Setup with Finalsite option instead, which requires no configuration on the school's side.

Once set up, this works as a sign-in option, not a data sync. Instead of typing a Finalsite password, someone can choose to sign in with the Microsoft account already used at school. Microsoft checks who they are and sends Finalsite a confirmation; Finalsite never sees or stores the Microsoft password.

Setting this up requires registering an application in the Microsoft Entra admin center and sending Finalsite three values from that registration: an Application ID, a Directory ID, and a client secret. The steps below cover exactly what to do and where to find each value.

When to use this setup

Use this setup when a school requires full control over the Microsoft application Finalsite uses for authentication. Schools that do not need this level of control can request the Quick Setup with Finalsite option instead; it requires no configuration on the school's side and is enough for most schools.

Before starting

Confirm access to the following before beginning:

  • Administrative access to the school's Microsoft Entra ID tenant
  • Permission to register new applications in that tenant
  • Permission to grant API permissions on those applications, or access to a colleague who can

Finalsite also provides one value needed during setup:

  • Redirect URI: https://auth-us-east1.finalsite.com/oauth2/callback

Step 1: Register a new application in Microsoft Entra

  • Sign in to the Microsoft Entra admin center with an account that has permission to register applications.
  • In the left menu, select Identity, then Applications, then App registrations.
  • Click + New registration at the top of the page.
  • Fill in the application details:
    • Name: Finalsite SSO, or any name that helps identify it later.
    • Supported account types: select Accounts in this organizational directory only (Single tenant). This restricts sign-in to users in the school's own Microsoft tenant, which is the correct setting for a client-managed setup.
    • Leave the Redirect URI field blank for now; it gets added in a later step.
  • Click Register.

Need more help? Visit Microsoft's quickstart: register an application with the Microsoft identity platform.

Step 2: Capture the Application ID and Directory ID

After registration, the application's Overview page appears.

  • Copy the Application (client) ID: a unique ID displayed near the top of the page.
  • Copy the Directory (tenant) ID: a unique ID displayed just below the client ID.
  • Save both values somewhere secure; they get sent to Finalsite at the end of setup.

Need more help? Microsoft's quickstart: register an application with the Microsoft identity platform also covers where to find these two values on the Overview page.

Step 3: Configure the redirect URI

  • From the application's left menu, select Authentication.
  • Click + Add a platform, then choose Web.
  • In the Redirect URIs field, paste the redirect URI Finalsite provided: https://auth-us-east1.finalsite.com/oauth2/callback
  • Leave the remaining options at their defaults and click Configure.

Need more help? Visit Microsoft's how to add a redirect URI to your application.

Step 4: Create a client secret

  • From the application's left menu, select Certificates & secrets.
  • Under the Client secrets tab, click + New client secret. Microsoft's guide on adding credentials to an application covers this in more detail if needed.
  • Add a description, such as Finalsite SSO, and choose an expiration period.
  • Click Add.
  • Copy the value from the Value column immediately.

⚠️ Important Note

Microsoft displays the secret value only once and hides it permanently after navigating away from the page. The Secret ID column is a different value and is not what Finalsite needs; only the Value column matters. Microsoft also caps secret lifetimes at 24 months. Set a calendar reminder before the secret expires; when it does, sign-in stops working until a new secret is generated and sent to Finalsite.

Step 5: Grant API permissions

  • From the application's left menu, select API permissions.
  • Click + Add a permission, then choose Microsoft Graph, then Delegated permissions.
  • Add the permissions the school's IT lead has approved for this integration. The typical set Finalsite requests is openid, profile, email, and User.Read.
  • Click Add permissions.
  • Recommended: click Grant admin consent for [the school's tenant] so users do not see a consent prompt the first time they sign in.

Check with IT before granting permissions

Confirm the permission set above with the school's IT lead before adding it. Some organizations restrict which Microsoft Graph permissions can be granted to third-party applications, or may want to scope the integration more tightly. If a different set is approved, let the Finalsite contact know; some scopes are required for sign-in to function, and Finalsite will flag anything in the approved set that is incompatible.

Step 6: Send the values to Finalsite

Send the Finalsite contact the following three values. Use a secure channel; the client secret is sensitive and should not be shared by email.

Field Where to find it
Application (client) ID Application Overview page
Directory (tenant) ID Application Overview page
Client secret value The value copied during Step 4: Create a client secret

Finalsite uses these values to configure the connection, tests it, and confirms once sign-in is working.

Troubleshoot common issues

  • The client secret value disappeared after navigating away. Microsoft only displays the secret value once. Return to Certificates & secrets, generate a new secret, and send Finalsite the new value.
  • Users see a consent prompt every time they sign in. Return to API permissions and click Grant admin consent for [the school's tenant]. This applies the permissions on behalf of everyone in the organization.
  • Sign-in used to work but is now failing. The client secret has most likely expired. Check Certificates & secrets; if the expiry date is in the past, generate a new secret and send the new value to Finalsite.

Alternative: Quick Setup with Finalsite

Schools that do not need this level of control, or would rather not manage an application registration, can request the Quick Setup with Finalsite option instead. It requires no configuration on the school's side and is enough for most schools.

Related articles

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please Sign in to leave a comment if you don't see the comment box below.