Skip to main content
Checksum is a SaaS application your engineering team uses to generate and run end-to-end tests against your web applications. To let users sign in with their company Microsoft account, Checksum acts as an OAuth 2.0 / OpenID Connect application registered in your Entra ID (Azure AD) tenant. This document describes exactly what Checksum requests at sign-in, what data it receives, and — just as importantly — what it does not have access to. It is written for IT and security administrators reviewing Checksum before adding it to their approved application list.

​
At a glance

PropertyDetails
Application nameChecksum
PublisherChecksum AI, Inc.
Application (Client) ID0fca6895-7be3-4c7b-ac3d-316d5e38fc08
Sign-in URLhttps://app.checksum.ai
Redirect URIhttps://app.checksum.ai
ProtocolOAuth 2.0 with OpenID Connect
Multi-tenantYes — users sign in with their own Microsoft account
Admin consent requiredNot required by Checksum; depends on your tenant’s user-consent policy (see Approving Checksum in Entra ID)
Requested permissionsopenid, email, User.Read (delegated)
Data written to your tenantNone
Access controlManaged in your tenant (group/user assignment or open) — see below

​
Controlling who can sign in

Whether Checksum is available to your entire company or restricted to specific users or groups is controlled entirely through standard Entra ID application settings. No custom integration or backend work is required on your side or on Checksum’s side — both approaches are supported out of the box using the same underlying OAuth configuration. In Entra admin center → Enterprise applications → Checksum → Properties, set Assignment required to Yes. Then, under Users and groups, assign the individual users or the security/Microsoft 365 groups that should be able to sign in. With this setting:
  • Only assigned users (or members of assigned groups) can authenticate to Checksum.
  • Unassigned users who attempt to sign in see Microsoft’s standard “You can’t access this application” error — the request never reaches Checksum.
  • Access can be added or removed at any time by updating the assignment, with no configuration changes required on Checksum’s side.
This is the approach most enterprise customers choose and is what we recommend.

​
Option 2 — Open to the entire tenant

If Assignment required is left at No (the default), any authenticated user in your tenant may sign in to Checksum using their Microsoft account. Note that sign-in and workspace access are two separate layers. Checksum has its own workspace membership model administered by your Checksum admin, so a user who authenticates via Microsoft still needs to be added to your Checksum workspace to see any tests, data, or settings. If a user signs in but has not been provisioned into the workspace, they will not have access to your organization’s data.

​
Do we need to build anything to support group-based access?

No. Both options above use standard Entra ID application-assignment controls that Microsoft provides to every tenant. Checksum does not require:
  • SCIM provisioning
  • Group claims in the ID token
  • A separate groups API permission (e.g., GroupMember.Read.All)
  • Any custom claim mapping or federation setup
If you later want to switch from open access to group-based access (or vice versa), it is a single toggle in the Entra admin center.

​
What Checksum requests

When a user signs in for the first time, Microsoft presents a consent screen listing the following delegated permissions:

​
openid

Standard OpenID Connect scope. Allows Microsoft to issue an ID token confirming the user signed in successfully. No profile data beyond the user’s identifier is returned by this scope alone.

​
email

Returns the signed-in user’s primary email address, so Checksum can identify the user’s account.

​
User.Read (Microsoft Graph)

Grants read access to the signed-in user’s own Microsoft Graph profile (/me). This scope is limited to the user’s own record — it does not grant access to other users, the directory, or any organizational data. From the profile returned, Checksum reads and stores only the following four fields:
  • Display name
  • Given name (first name)
  • Surname (last name)
  • User principal name (email)
No other fields returned by /me (for example, job title, phone numbers, office location, or the user’s object ID) are read or retained.

​
What Checksum does NOT request

The following are not requested and cannot be accessed by Checksum, regardless of how the consent flow is approved:
  • Mail, Calendar, Contacts — no access to Outlook, Exchange, or any messaging data
  • Files — no access to OneDrive, SharePoint, or any document storage
  • Teams & chat — no access to Microsoft Teams channels, chats, or meetings
  • Directory data — no access to other users, groups, org structure, or tenant settings
  • Group membership — Checksum does not read which groups the user belongs to
  • Write permissions — Checksum cannot modify any user or tenant data
  • Application (app-only) permissions — all permissions are delegated and tied to an active user session
  • Offline access / refresh tokens — Checksum does not hold long-lived credentials and cannot act on a user’s behalf in the background

​
How sign-in works

  1. A user navigates to https://app.checksum.ai and clicks Continue with Microsoft.
  2. The browser is redirected to Microsoft’s standard login and consent screen.
  3. The user authenticates with their Microsoft account and reviews the requested permissions.
  4. After consent, Microsoft redirects back to Checksum with a short-lived access token.
  5. Checksum uses that access token once to call https://graph.microsoft.com/v1.0/me and retrieve the user’s name and email.
  6. The Microsoft access token is then discarded.
  7. Checksum issues its own signed session token (JWT) for subsequent use within the Checksum application.
At no point after the initial sign-in does Checksum hold or use a Microsoft-issued token. Because the Microsoft access token is used exactly once and then discarded, its lifetime is not relevant to the ongoing Checksum session. Any Conditional Access policies configured in your tenant are enforced by Microsoft at sign-in as they would be for any other Entra-registered application.

​
Data Checksum stores from Microsoft

Checksum stores only the following fields, retrieved once at sign-in and refreshed on subsequent logins:
  • Email address
  • Display name
  • Given name
  • Surname
Checksum does not store:
  • Microsoft access tokens or refresh tokens
  • Tenant ID or directory ID
  • User object ID (GUID)
  • Group memberships
  • Any other Microsoft Graph data

​
Approving Checksum in Entra ID

Checksum is a multi-tenant OAuth application, so it does not live in the Azure AD app gallery. There are two ways to add it to your tenant: An Entra ID administrator can visit the admin consent URL below while signed in to your tenant. This registers Checksum as an Enterprise Application in your tenant and grants tenant-wide consent in a single step. 
https://login.microsoftonline.com/organizations/adminconsent?client_id=0fca6895-7be3-4c7b-ac3d-316d5e38fc08
If you prefer, you may replace organizations with your specific tenant ID or primary domain (for example, contoso.onmicrosoft.com) to scope the consent prompt explicitly to your tenant. After consent, Checksum will appear under Entra admin center → Enterprise applications, where you can configure user/group assignment, sign-in logs, and conditional access policies.

​
Option B — Register on first user sign-in

Alternatively, the first user from your tenant who signs in via https://app.checksum.ai will trigger Checksum to register as an Enterprise Application in your tenant automatically. If your tenant’s user-consent settings allow regular users to consent to third-party apps, no admin action is needed. If user consent is restricted, that user will be directed through your tenant’s admin consent request workflow.

​
After the app is registered

Once Checksum appears in Enterprise applications, administrators can:
  • Configure Properties → Assignment required and Users and groups to scope access (see Controlling who can sign in above).
  • Review the permissions granted — these will match the openid, email, and User.Read scopes described in this document.
  • Apply Conditional Access policies (MFA, device compliance, location restrictions) like any other Entra-registered application.
  • Monitor sign-in activity in the standard Sign-in logs.

​
Revoking access

Access can be revoked at any time:
  • Tenant-wide: Entra admin center → Enterprise applications → Checksum → Properties → Delete.
  • Per user: a user can revoke Checksum from their own account via https://myapps.microsoft.com → Manage your applications.
Revoking access in Entra ID immediately prevents future sign-ins. An existing Checksum session will remain valid in the user’s browser until it is explicitly invalidated on Checksum’s side. If you need an active session terminated immediately (for example, after offboarding), contact Checksum support and we will invalidate the user’s session server-side.

​
Security summary

  • Checksum receives read-only access to the signed-in user’s own basic profile.
  • No access to mail, files, calendars, directory data, or group membership.
  • No long-lived tokens are issued or stored.
  • No admin-level or application-level permissions are requested.
  • Access can be revoked at any time from the Entra admin center.
This is a standard, low-scope SaaS sign-in integration comparable to “Sign in with Microsoft” buttons on other business applications.