What is single sign-on in a cloud environment?¶
Single sign-on (SSO) lets one identity system authenticate a user for several applications, so the user does not enter separate credentials into each service. The central sign-in and the later application activity may therefore be recorded in different systems.
Dave signs in once, but two services make records¶
Dave signs in to Northstar's Microsoft Entra identity at 08:42 and selects a case-management application from the My Apps portal. Entra authenticates him and sends identity information that the application trusts. The application maps that information to local user caseuser-184, creates its own session and records Dave opening case CR-4821 at 08:44.
There may be no application password event because the application never checked one. That is not missing authentication: the check happened at the identity provider.
Reconstruct the mapping rather than searching every system for the same username or a second password event.
The identity provider and application do different jobs¶
| Evidence holder | Representative record | Question it answers |
|---|---|---|
| Identity provider | Sign-in time, user/object ID, authentication methods, client, resource/application ID, result and correlation ID | Which central identity route was accepted for which application? |
| Trust transaction | Issuer, subject/name identifier, audience, issue time and assertion/token identifier | What identity information crossed the boundary? |
| Application | Local user ID, tenant/workspace, session ID, operation, object and result | What did the local application record after accepting that identity? |
| Device/browser | Account profile, browser state, application artefacts and local activity | Which device held or used the resulting access? |
The user may experience this as one seamless sign-in, but the evidence chain remains central identity → trusted information → local account/session → application event.
Do not merge the identifiers¶
Entra user object 4a86…91bd and application user caseuser-184 may represent the same mapped identity without being interchangeable fields. Preserve the home tenant, resource tenant, application ID and local user ID. A display name or email address can change, while a provider's internal identifiers may continue.
The federated identity explainer examines the trust mechanism that often carries this information. SSO describes the sign-in experience and centralised access arrangement; federation describes one way identity information crosses the service boundary.
Microsoft Entra SSO example - checked 2 September 2026
Microsoft says Entra SSO can authenticate a user centrally and send identity information to applications using protocols including SAML and OpenID Connect. Each application receives identity information in the protocol format it supports and can maintain its own application session.
Microsoft Entra sign-in details identify the user, client application and target resource and can include identifiers used to correlate the sign-in. The receiving application's own audit schema and retention remain separate and must be checked for that product.
Use absence carefully¶
An application with SSO may have no local password event because it relied on the central identity provider. Conversely, a central sign-in does not prove that every assigned application was opened. The application session and audit event show whether the relying service actually accepted and used that route.
The point to remember
With SSO, find the central authentication, preserve the identity-to-application mapping, and then obtain the local session and activity. One sign-in experience can produce a chain of distinct records.
