Skip to main content

​
At a glance

Copy-paste values for registering and approving Checksum in Microsoft Entra ID:Admin consent URL (tenant-wide pre-approval, Option A). organizations can be replaced with a tenant ID or primary domain (e.g. contoso.onmicrosoft.com):
  • Permissions are delegated only. No app-only permissions, offline access, or refresh tokens.
  • Data written to the tenant: none. Data stored: email, display name, given name, surname.
  • The Microsoft access token is used once for the Graph call, then discarded. Checksum issues its own session JWT.
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 guide describes what Checksum requests at sign-in and what data it receives. Just as importantly, it describes what Checksum does not have access to. It is written for IT and security administrators reviewing Checksum before adding it to their approved application list.

​
Application details

​
Controlling who can sign in

Whether Checksum is available to your whole company or only 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. Both approaches work out of the box with the same 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 try to sign in see Microsoft’s standard “You can’t access this application” error. The request never reaches Checksum.
  • You can add or remove access at any time by updating the assignment, with no configuration changes on Checksum’s side.
Most enterprise customers choose this approach, and it’s 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 can sign in to Checksum with their Microsoft account.
Sign-in is not the same as workspace accessSign-in and workspace access are two separate layers. Checksum has its own workspace membership, administered by your Checksum admin. A user who authenticates with Microsoft still has to be added to your Checksum workspace to see any tests, data, or settings. A user who signs in without being added to the workspace can’t access your organization’s data.

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

No. Both options above use the 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 between open access and group-based access, it’s a single toggle in the Entra admin center.

​
What Checksum requests

When a user signs in for the first time, Microsoft shows a consent screen listing these delegated permissions: From the returned profile, Checksum reads and stores only these four fields:
  • Display name
  • Given name (first name)
  • Surname (last name)
  • User principal name (email)
No other fields returned by /me are read or retained, for example job title, phone numbers, office location, or the user’s object ID.

​
What Checksum does NOT request

Checksum does not request the following and can’t access them, however 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 doesn’t read which groups the user belongs to
  • Write permissions: Checksum can’t 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 holds no long-lived credentials and can’t act on a user’s behalf in the background

​
How sign-in works

1

Start sign-in

A user goes to https://app.checksum.ai and clicks Continue with Microsoft.
2

Microsoft login

The browser redirects to Microsoft’s standard login and consent screen.
3

Authenticate and consent

The user authenticates with their Microsoft account and reviews the requested permissions.
4

Redirect back

After consent, Microsoft redirects back to Checksum with a short-lived access token.
5

Single profile read

Checksum uses that access token once to call https://graph.microsoft.com/v1.0/me and retrieve the user’s name and email.
6

Token discarded

The Microsoft access token is then discarded.
7

Checksum session

Checksum issues its own signed session token (JWT) for use within the Checksum application.
After the initial sign-in, Checksum never holds or uses a Microsoft-issued token. Because the Microsoft access token is used once and then discarded, its lifetime doesn’t affect the ongoing Checksum session. Microsoft enforces any Conditional Access policies in your tenant at sign-in, as it does for any other Entra-registered application.

​
Data Checksum stores from Microsoft

Retrieved at sign-in, refreshed on each login

Email address · Display name · Given name · Surname

Never retained

Microsoft access 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 isn’t 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. In one step, this registers Checksum as an Enterprise Application in your tenant and grants tenant-wide consent.
Admin consent URL
If you prefer, replace organizations with your specific tenant ID or primary domain (for example, contoso.onmicrosoft.com) to scope the consent prompt to your tenant explicitly. After consent, Checksum appears 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 at https://app.checksum.ai causes Checksum to register as an Enterprise Application in your tenant automatically. If your tenant’s user-consent settings let regular users consent to third-party apps, no admin action is needed. If user consent is restricted, that user is sent 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).
  • Review the granted permissions. They should match the openid, email, and User.Read scopes described here.
  • Apply Conditional Access policies (MFA, device compliance, location restrictions) as for any other Entra-registered application.
  • Monitor sign-in activity in the standard Sign-in logs.

​
Revoking access

You can revoke access at any time:
Existing sessionsRevoking access in Entra ID blocks future sign-ins immediately. However, an existing Checksum session stays valid in the user’s browser until it’s explicitly invalidated on Checksum’s side. If you need an active session ended right away (for example, after offboarding), contact Checksum support, and Checksum will invalidate the session on its server.

​
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 the “Sign in with Microsoft” buttons in other business applications.

Security & Access

Network, repository, and credential overview.

Onboarding & POV

What your team provides before kickoff.