> ## Documentation Index
> Fetch the complete documentation index at: https://checksum.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Microsoft Entra ID SSO
> OAuth 2.0 / OpenID Connect setup guide for approving Checksum in your Microsoft Entra ID (Azure AD) tenant. It's written for IT and security administrators.
## At a glance
| Question | Answer |
| - | - |
| What does Checksum ask for? | Only basic sign-in permissions: your identity, your email, and your own profile |
| Can we limit who signs in? | Yes, with standard Entra ID user and group assignment ([how](#controlling-who-can-sign-in)) |
| How do we approve it? | Pre-approve with the admin consent link, or let the first user register it ([how](#approving-checksum-in-entra-id)) |
Copy-paste values for registering and approving Checksum in Microsoft Entra ID:
| Setting | Value |
| - | - |
| Application (Client) ID | `0fca6895-7be3-4c7b-ac3d-316d5e38fc08` |
| Redirect URI | `https://app.checksum.ai` |
| Sign-in URL | `https://app.checksum.ai` |
| Protocol | OAuth 2.0 with OpenID Connect (multi-tenant) |
| Delegated scopes | `openid`, `email`, `User.Read` |
| Graph call made once at sign-in | `GET https://graph.microsoft.com/v1.0/me` |
Admin consent URL (tenant-wide pre-approval, [Option A](#option-a-pre-approve-with-the-admin-consent-url-recommended)). `organizations` can be replaced with a tenant ID or primary domain (e.g. `contoso.onmicrosoft.com`):
```text theme={null}
https://login.microsoftonline.com/organizations/adminconsent?client_id=0fca6895-7be3-4c7b-ac3d-316d5e38fc08
```
* 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
| Property | Details |
| - | - |
| Application name | **Checksum** |
| Publisher | Checksum AI, Inc. |
| Application (Client) ID | `0fca6895-7be3-4c7b-ac3d-316d5e38fc08` |
| Sign-in URL | `https://app.checksum.ai` |
| Redirect URI | `https://app.checksum.ai` |
| Protocol | OAuth 2.0 with OpenID Connect |
| Multi-tenant | Yes. Users sign in with their own Microsoft account. |
| Admin consent required | Not required by Checksum. Depends on your tenant's user-consent policy (see [Approving Checksum in Entra ID](#approving-checksum-in-entra-id)). |
| Requested permissions | `openid`, `email`, `User.Read` (delegated) |
| Data written to your tenant | None |
| Access control | Managed in your tenant (group/user assignment or open). See [Controlling who can sign in](#controlling-who-can-sign-in). |
## 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.
### Option 1: Restrict to specific users or groups (recommended)
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 access**
Sign-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:
| Permission | What it allows |
| - | - |
| `openid` | The standard OpenID Connect scope. It lets Microsoft issue an ID token confirming the user signed in. On its own, this scope returns no profile data beyond the user's identifier. |
| `email` | Returns the signed-in user's primary email address, so Checksum can identify the user's account. |
| `User.Read` (Microsoft Graph) | Read access to the **signed-in user's own Microsoft Graph profile** (`/me`). It's limited to the user's own record and does **not** grant access to other users, the directory, or any organizational data. |
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
A user goes to `https://app.checksum.ai` and clicks **Continue with Microsoft**.
The browser redirects to Microsoft's standard login and consent screen.
The user authenticates with their Microsoft account and reviews the requested permissions.
After consent, Microsoft redirects back to Checksum with a short-lived access token.
Checksum uses that access token **once** to call `https://graph.microsoft.com/v1.0/me` and retrieve the user's name and email.
The Microsoft access token is then discarded.
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
Email address · Display name · Given name · Surname
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.
### Option A: Pre-approve with the admin consent URL (recommended)
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.
```text Admin consent URL theme={null}
https://login.microsoftonline.com/organizations/adminconsent?client_id=0fca6895-7be3-4c7b-ac3d-316d5e38fc08
```
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](#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:
| Scope | How |
| - | - |
| Tenant-wide | Entra admin center → **Enterprise applications** → **Checksum** → **Properties** → **Delete** |
| Per user | The user revokes Checksum from their own account at `https://myapps.microsoft.com` → **Manage your applications** |
**Existing sessions**
Revoking 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](mailto:support@checksum.ai), 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.
## Related
Network, repository, and credential overview.
What your team provides before kickoff.