What is a cloud session?¶
A cloud session is the ongoing signed-in connection between a cloud service and one browser, application or device. It lets the service recognise a series of requests as part of the same authorised use, so the user does not have to enter a password and complete multi-factor authentication every time they open a folder or save a file.
Think of it as one continuing conversation¶
Suppose Dave signs in to cloud storage on his laptop. The service checks his login and starts a session for that browser. When the browser later asks to list a folder, open a document and save a change, it sends session material with each request. The service uses it to recognise the same signed-in conversation and apply Dave's account permissions.
If Dave also signs in on his phone, that normally creates a different session. Both sessions use the same account, but the provider needs to keep their requests and activity apart.
The account identifies whose permissions apply. The session tells the service which continuing exchange each new request belongs to.
| Route | Session | Example activity |
|---|---|---|
| Laptop browser | SES-L41 | Opens folder, edits route-sheet.docx |
| Phone application | SES-P09 | Previews the file, downloads an offline copy |
| Desktop sync client | SES-S72 | Uploads a later local change |
The labels in this example are simplified, but they show the purpose: without a way to distinguish the routes, the service could not reliably decide which signed-in exchange each request belongs to.
What travels between the client and service?¶
Web and application requests arrive as separate exchanges. After login, the provider gives the client something it can present again - commonly a cookie, a session identifier or an access token. Depending on the service, the value may point to a server-side session record or carry signed information about the authorised access.
The provider checks that material when later requests arrive. It can then associate the request with an account, permissions, application and other session details. A refresh token may allow the client to obtain replacement access tokens and continue without another visible login.
Providers use these terms differently, so the important question is what the particular value does in that service.
Microsoft session and sign-in context - checked 2 September 2026
Microsoft Entra sign-in details can include correlation, request and unique token identifiers, along with application, resource, authentication and device context. Microsoft notes that a correlation ID is based on values supplied by a client and does not guarantee its accuracy.
Use identifiers as tested joins between records, not as labels whose wording alone proves that two events share a person or device.
A session can outlast the visible login¶
The login is the event that establishes access. The session carries that access forward. It may remain active when the user closes a browser window, changes network or leaves an application running in the background.
A session can expire, be ended by signing out or be deliberately revoked. Some password changes end existing sessions; others do not end every token or connected application.
Why this matters in the records¶
A file action may occur during a session created hours or days earlier, so there may be no fresh login beside it. Provider records may use a session or client identifier to connect the original authentication with later access, edits or security changes.
That connection is technically useful but it does not identify a person by itself. Someone else may use the same browser profile, a session may be stolen, or an application may act automatically.
The point to remember
A cloud session is one continuing signed-in conversation between a client and the service. Follow it from login through later requests and eventual expiry or revocation, then use device and contextual evidence to identify who controlled it.
