> For the complete documentation index, see [llms.txt](https://hub.equipme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.equipme.io/equipme/settings-1/portal-settings/single-sign-on-sso/how-to-setup-microsoft-entra-sso/understanding-equipmes-access-to-your-entra-data.md).

# Understanding equipme's access to your Entra data

Here you will find detailed technical information about which data equipme has access to through the Microsoft Entra SSO setup.

#### What equipme actually requests: openid, email, profile <a href="#what-equipme-actually-requests-openid-email-profile" id="what-equipme-actually-requests-openid-email-profile"></a>

The integration uses only three standard OpenID Connect scopes:

**`openid`** Required for all OIDC logins. Provides the user’s unique identifier (`sub`) and the security framework of the token.

**`email`** Provides the user’s primary email address.

**`profile`** Provides basic profile information such as name, given name and family name.

No additional scopes or Graph API permissions are used. Nothing beyond identity-level data is requested.

#### Identity claims returned by Entra ID <a href="#identity-claims-returned-by-entra-id" id="identity-claims-returned-by-entra-id"></a>

Based on these scopes, Microsoft Entra ID includes the following user-related fields in the ID token:

`sub` Unique identifier of the user inside the Microsoft tenant.

`email` Primary email address.

`name` Full display name.

`given_name` First name.

`family_name` Last name.

`preferred_username` Login identifier inside Entra ID (often identical to the email).

`oid` Object ID of the user in the directory. Common in Entra-based tokens.

In addition to these identity claims, the token also includes standard OIDC protocol fields such as:

`iss`, `aud`, `iat`, `exp`, `nonce`, `tid`

These protocol fields are required for validation but are not processed as user attributes.

equipme uses only the identity-related claims to authenticate and match the user. All other values in the token are ignored after verification.

#### No access to directory data <a href="#no-access-to-directory-data" id="no-access-to-directory-data"></a>

Because equipme uses only the scopes `openid`, `email` and `profile`, the application does **not** access or receive:

* directory roles
* security groups
* group memberships
* custom attributes
* organisational units
* job titles
* manager relationships
* phone numbers
* device information
* Microsoft Graph API data

The integration does not request permissions such as `Directory.Read.All`, `User.Read.All`, or any elevated access.

This keeps the authentication flow strictly limited to identity confirmation.

#### Understanding the consent screen <a href="#understanding-the-consent-screen" id="understanding-the-consent-screen"></a>

When an admin completes the Microsoft consent, Microsoft displays two permission descriptions. These look broader than the underlying scopes, but they refer to standard OIDC behavior.

**“View your basic profile”** This corresponds directly to the scopes `openid`, `email` and `profile`. It includes only name, email and the basic identity claims listed above.

**“Maintain access to data you have given it access to”** This does not grant additional rights. It means the consent stays active until it is manually revoked. The application does not gain extra directory permissions from this statement.

Microsoft shows these descriptions for all OIDC apps, even when only the minimal scopes are used.

#### Why permissions inside equipme remain separate <a href="#why-permissions-inside-equipme-remain-separate" id="why-permissions-inside-equipme-remain-separate"></a>

Even though Entra ID confirms the user’s identity, equipme does not inherit or rely on:

* Entra roles
* group memberships
* conditional access structures
* role-based access control in the tenant

All permissions inside equipme — including roles, access levels, and what a user can see or do — are fully controlled within equipme.

This separation avoids complex mapping rules and ensures consistent behavior across all customers.

#### SSO vs HR Sync <a href="#sso-vs-hr-sync" id="sso-vs-hr-sync"></a>

SSO handles authentication only.

It does **not** import:

* department
* location
* job role
* employment status
* custom fields
* organisational data

If you want to synchronise user and organisational data automatically from your HR system or directory service, this is done via HR Sync and not via SSO.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hub.equipme.io/equipme/settings-1/portal-settings/single-sign-on-sso/how-to-setup-microsoft-entra-sso/understanding-equipmes-access-to-your-entra-data.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.