Fact-checked by Grok 2 weeks ago

Session ID

A session ID, also known as a session identifier or session token, is a unique alphanumeric string generated by a web server to identify and track a user's interaction with a web application across multiple stateless HTTP requests.^[1] It enables the maintenance of user-specific state, such as authentication status, shopping cart contents, or preferences, despite the inherent statelessness of the HTTP protocol.^[2] Typically, the session ID is created upon the user's initial access or login and is stored server-side in a session object or database, while a client-side reference—often in the form of an HTTP cookie—is sent back to the user's browser.^[1] The session ID is transmitted in subsequent requests via mechanisms like the Cookie header, allowing the server to associate incoming traffic with the correct user session and apply appropriate access controls.^[2] For security, session IDs must be generated using a cryptographically secure pseudorandom number generator (CSPRNG) with at least 64 bits of entropy—ideally 128 bits or more—to resist prediction or brute-force attacks, and they should be renewed after authentication or privilege changes.^[1] Common vulnerabilities include session fixation, where an attacker forces a known ID on a victim, and hijacking via interception of the ID, underscoring the need for transmission over HTTPS with Secure and HttpOnly cookie flags to prevent exposure.^[1] Sessions typically include idle timeouts (e.g., 2–30 minutes of inactivity) and absolute expiration (e.g., 4–8 hours) to limit exposure duration.^[1] Beyond web applications, session IDs appear in other protocols, such as the Session Initiation Protocol (SIP) for multimedia communications, where they provide end-to-end identification across devices and intermediaries.^[3] In versions of Transport Layer Security (TLS) up to 1.2, session IDs identify resumable session states to optimize handshakes. In TLS 1.3 and later, session resumption uses session tickets instead.^[4]^[5] However, the web context remains the most prevalent use, integral to modern frameworks like Django and PHP, which automate session handling through default cookie-based IDs.

Fundamentals

Definition and Purpose

A session ID is a unique alphanumeric string assigned by a web server to a user's interaction session with a server-based application, serving as an identifier to track and maintain state across multiple stateless requests.^[6] This identifier, often referred to as a session token, binds transient user-specific data—such as authentication credentials, preferences, or shopping cart contents—to the session on the server side, allowing the application to retrieve and update this information without requiring it to be resent in every request.^[1] The primary purpose of a session ID is to enable stateless protocols, such as HTTP, to emulate stateful interactions by associating session data with the ID rather than embedding it in each request's parameters or URL, which enhances efficiency and user privacy.^[7] For instance, in e-commerce applications, the session ID links a user's browsing history and selections across page loads, simulating a continuous conversation between client and server.^[8] This mechanism supports dynamic web experiences without compromising the protocol's design for simplicity and scalability. Session IDs emerged in the mid-1990s amid the growth of dynamic web applications, as developers sought solutions to HTTP's inherent statelessness; a key early proposal was the 1996 W3C working draft on Session Identification URIs by Phillip M. Hallam-Baker and Dan Connolly, which aimed to facilitate user tracking while addressing privacy concerns.^[9] Key properties of a session ID include uniqueness to distinguish individual sessions, unpredictability to resist guessing attacks, and temporariness, typically enforced through inactivity timeouts of 2-5 minutes for high-value applications or 15-30 minutes for low-risk applications to limit exposure duration.^[1]^[10]^[11]

Relation to Stateless Protocols

HTTP is fundamentally a stateless protocol, meaning that each request from a client to a server is treated as an independent transaction without any inherent memory of previous interactions. This design simplifies server implementation and enables scalability, as the server does not need to retain session state across requests, but it poses challenges for applications requiring continuity, such as user authentication, shopping carts, or multi-step forms in web-based e-commerce and login processes.^[12]^[13] Session IDs address this statelessness by serving as a lightweight, opaque identifier that links a series of requests to a specific server-side session store, allowing the server to associate and retrieve user-specific data—such as authentication status or temporary preferences—without transmitting sensitive information in every client request. Upon initial interaction, the server generates and assigns the session ID, which the client includes in subsequent requests, effectively simulating statefulness over the stateless protocol.^[1]^[13] In comparison to alternatives like URL parameters, which embed state directly in request URIs and risk exposure through logs, referer headers, or browser history, or general cookies used for persistent client-side storage of non-sensitive data, session IDs provide a more secure mechanism for server-controlled state management that minimizes client-side data leakage. This approach keeps sensitive session details on the server, reducing attack surfaces while maintaining protocol efficiency.^[1] Session IDs integrate with HTTP through protocol extensions, primarily via the Set-Cookie response header for initial assignment and the Cookie request header for transmission in follow-up requests, as standardized in RFC 6265, which defines the state management mechanism for HTTP cookies often used to carry session IDs. This enables seamless handling of session-based interactions without altering the core stateless nature of HTTP.^[2]

Generation and Management

Methods of Generation

Session IDs are primarily generated using cryptographically secure pseudorandom number generators (CSPRNGs) to produce high-entropy values that resist prediction and brute-force attacks.^[1] These generators ensure the output is indistinguishable from true randomness, typically yielding strings of 128 to 256 bits in length to provide sufficient entropy for secure applications.^[1] In Java-based systems, the SecureRandom class serves as a standard CSPRNG for this purpose, often employed in web frameworks like Tomcat to create session identifiers during initialization.^[14] Similarly, in C/C++ environments leveraging OpenSSL, the RAND_bytes function generates the required random bytes, drawing from the system's entropy pool to fill buffers for session ID construction.^[15] Common formats for representing these generated values include Base64-encoded strings of raw random bytes, which offer a URL-safe and compact encoding while retaining the full entropy of the underlying data.^[16] Another widely adopted format is the Universally Unique Identifier (UUID), standardized in RFC 4122, where version 4 UUIDs use 122 bits of randomness to achieve near-unique identifiers suitable for sessions.^[17] Less commonly, session IDs may be derived from hashed combinations of elements like timestamps and user agent strings, typically using a secure hash function such as SHA-256 applied to these inputs concatenated with additional random salt, though this method requires careful implementation to avoid introducing patterns.^[18] Uniqueness is assured by selecting lengths that render collision probabilities negligible under the birthday paradox. For example, a 32-character session ID—often hexadecimal or Base64-encoded to represent 128 bits—has a probability of at least one collision of less than 1 in 70 quadrillion across up to hundreds of billions of sessions, making it practical for high-volume systems with millions of concurrent sessions.^[19] This low probability holds as long as the generator provides full entropy across the bits, preventing attackers from exploiting partial predictability.^[1] While deterministic approaches like sequential incrementing counters have been used historically for simplicity, they are avoided in modern practice due to their inherent predictability, which enables session enumeration by guessing subsequent values.^[1] Non-deterministic random generation remains the preferred method, aligning with security standards that emphasize unpredictability to protect against fixation and hijacking threats.^[1]

Storage and Transmission

Session IDs are stored on the server side, where they serve as keys to access associated session data objects that contain variables such as user identifiers, timestamps, client IP addresses, and user agents.^[1] This storage typically occurs in memory for single-server applications or in distributed caches like Redis or SQL Server for scalability across multiple instances.^[20] In frameworks such as ASP.NET Core, session state is backed by an implementation of IDistributedCache, which can use in-memory options like DistributedMemoryCache for local storage or external providers for persistence.^[20] Transmission of session IDs to clients occurs primarily through HTTP cookies, where the server includes the ID in the Set-Cookie response header upon session creation, such as Set-Cookie: session_id=abc123.^[21] The client browser then automatically attaches the ID to subsequent requests via the Cookie request header, enabling the server to retrieve and validate the session.^[21] In environments where cookies are unavailable or disabled, alternatives include embedding the session ID in URL parameters through rewriting or in hidden form fields within POST requests.^[1] The lifecycle of a session ID involves expiration mechanisms to limit its validity, either through absolute timeouts (e.g., 4-8 hours for full-day sessions) or idle timeouts based on user activity (e.g., 15-30 minutes for low-risk applications).^[1] Upon expiration or user logout, the session is invalidated by clearing server-side data and removing the client-side identifier, using framework-specific methods like HttpSession.invalidate() in Java or Session.Clear() in ASP.NET Core to prevent reuse.^[1]^[20] Regular cleanup of expired sessions is essential to avoid resource accumulation, often handled automatically by the storage mechanism.^[20] In clustered environments, scalability requires shared storage solutions to ensure session ID portability across servers, such as using Redis as a centralized cache or SQL Server for persistent backing.^[20] Load balancers can employ session affinity, also known as sticky sessions, to route requests with the same ID to the originating server, configured via attributes like jvmRoute in Apache Tomcat.^[22] Alternatively, session replication protocols in frameworks like Tomcat distribute data across nodes using multicast or TCP, supporting all-to-all or backup models for larger deployments.^[22]

Security Considerations

Common Vulnerabilities

Session IDs are susceptible to several key vulnerabilities that can compromise user authentication and enable unauthorized access to web applications. These threats primarily arise from weaknesses in generation, transmission, and handling practices, allowing attackers to exploit the stateless nature of HTTP to impersonate legitimate users. One prevalent vulnerability is session fixation, where an attacker tricks a user into authenticating with a pre-set session ID known to the attacker, thereby hijacking the session post-login. This occurs when applications fail to issue a new session ID upon authentication, permitting the reuse of an existing one fixed by the attacker through mechanisms like URL parameters, cookies, or hidden form fields.^[23]^[1] Session hijacking involves the interception and reuse of a valid session ID to impersonate the victim, often via network sniffing on unsecured connections such as public Wi-Fi or through cross-site scripting (XSS) attacks that steal cookies. Attackers can capture the ID in transit if not encrypted or use client-side scripts to extract it from the browser, enabling seamless takeover of active sessions without needing credentials.^[24]^[1] Prediction attacks exploit weakly generated session IDs that follow predictable patterns, allowing attackers to guess valid tokens and bypass authentication. Early implementations, such as those in PHP relying on insufficiently random functions like rand() before improvements to use cryptographically secure pseudorandom number generators (CSPRNGs), demonstrated high predictability due to low entropy in seeding, enabling brute-force or analytical guessing of IDs.^[25]^[26] Side-channel leaks expose session IDs through unintended channels like application logs, error messages, or insecure browser storage, such as localStorage or unencrypted caches, rather than secure cookies. For instance, including session IDs in URLs can log them in proxies or servers, or displaying them in error pages can reveal them to attackers probing the application.^[27]^[1] These vulnerabilities have been highlighted in security standards, including the OWASP Top 10 under Authentication Failures (A07:2025), which encompasses issues like session fixation and hijacking as critical risks to broken authentication mechanisms. Real-world impacts include exploits in PHP-based applications where predictable randomness led to widespread session compromise, as detailed in analyses of pre-2012 PHP randomness flaws.^[28]^[26]

Mitigation Strategies

To mitigate risks associated with session IDs, secure generation practices are essential. Session identifiers must be generated using a cryptographically secure pseudorandom number generator (CSPRNG) to ensure high entropy and unpredictability, typically requiring at least 64 bits of entropy (ideally 128 bits or more) to resist brute-force attacks.^[1] Additionally, session IDs should be regenerated upon privilege level changes, such as user login, to prevent session fixation attacks where an attacker pre-sets a session ID before authentication.^[1] Transmission of session IDs requires robust protections to prevent interception or exposure. Applications should enforce HTTPS with TLS 1.3 or higher for all session-related communications, encrypting the channel to safeguard against man-in-the-middle attacks. Cookie attributes further enhance security: the Secure flag restricts transmission to HTTPS connections only, the HttpOnly flag prevents JavaScript access to mitigate cross-site scripting (XSS) theft, and the SameSite attribute (set to Strict or Lax) blocks cross-site requests to defend against cross-site request forgery (CSRF).^[1] Server-side validation and monitoring mechanisms are critical for detecting and responding to threats. All incoming session IDs must be validated against the server's session store to ensure they correspond to active, untampered sessions, rejecting any invalid or manipulated identifiers.^[1] Rate limiting on session creation requests helps thwart brute-force guessing attempts, while logging and monitoring for anomalous patterns—such as rapid session invalidations or unusual geographic access—enable proactive detection of hijacking or fixation.^[1] In specific frameworks, built-in tools support these mitigations. For ASP.NET, anti-forgery tokens provide CSRF protection by generating unique, session-bound values validated on state-changing requests, complementing session ID security.^[29] In Express.js, the express-session middleware facilitates secure session handling with options for signed cookies, secret keys for integrity checks, and integration with secure flag configurations.^[30] Compliance with regulatory standards ensures session data aligns with privacy and security requirements. Under GDPR, session handling must adhere to data minimization and security principles, treating session-stored personal data as requiring pseudonymization or deletion upon expiration to avoid unnecessary retention.^[31] For e-commerce, PCI-DSS mandates session timeouts (e.g., no more than 15 minutes of inactivity without re-authentication) and secure transmission to protect cardholder data during transactions.

Applications and Implementations

In Web Development

In web development, session IDs play a crucial role in maintaining user authentication, personalization such as language preferences, and application state across stateless HTTP requests in model-view-controller (MVC) frameworks like Django and Ruby on Rails.^[32]^[33] By associating a unique identifier with server-side data, session IDs enable seamless user experiences, such as preserving login status or shopping cart contents without requiring repeated data entry.^[34] Various frameworks provide built-in mechanisms for session management. In PHP, the $_SESSION superglobal array allows developers to store and retrieve session data after initiating a session with session_start(), facilitating straightforward state persistence in web applications.^[34] Similarly, Django's session framework uses a server-side store (defaulting to a database) and sets a session ID cookie named 'sessionid' to track per-user data via the request.session dictionary, integrating seamlessly with its authentication system.^[32] In Node.js, the express-session middleware stores session data server-side and attaches the session ID to a cookie, accessible through req.session for handling user-specific information in Express applications.^[35] For Ruby on Rails, sessions default to encrypted client-side cookies via ActionDispatch::Session::CookieStore, with the framework automatically managing the session object to reuse or create IDs as needed.^[33] In serverless environments like AWS Lambda with API Gateway, sessions often rely on external stores such as DynamoDB to maintain state, as the stateless nature of functions requires persistent backends for ID lookups.^[36] To support multi-device usage, such as across browsers or mobile apps, web applications increasingly employ token-based systems where JSON Web Tokens (JWTs) serve as session surrogates. These self-contained tokens, issued post-authentication and validated via headers like Authorization: Bearer, allow stateless verification without server-side storage, enabling concurrent sessions on multiple devices while adhering to standards like RFC 7519.^[37]^[38] Session management introduces performance overhead from ID lookups and data retrieval, typically adding latency in high-traffic scenarios, which can be mitigated through in-memory caches like Redis to reduce database queries and improve response times.^[35] Over time, session handling has evolved from purely server-side approaches to hybrid models in progressive web apps (PWAs), incorporating client-side storage options such as localStorage or IndexedDB for offline persistence and faster access, complementing traditional server IDs with browser-based state synchronization.

In Other Computing Contexts

In API and microservices architectures, session IDs extend beyond web contexts to manage state in stateless protocols like RESTful APIs, where OAuth 2.0 access tokens often function as temporary session-like identifiers to authorize subsequent requests without re-authentication.^[39] These tokens encapsulate user consent and permissions, enabling secure, stateless interactions between clients and servers, as seen in implementations for services like Google APIs and Azure DevOps, where tokens are obtained via authorization flows and included in API headers for validation.^[40] In load-balanced gRPC environments, session affinity is implemented by proxies or load balancers, often using cookies or custom headers, to route requests from the same client to the same backend instance, preserving state for ongoing streaming RPCs.^[41] For mobile and desktop applications, session IDs facilitate secure backend communication by storing server-issued tokens locally, ensuring continuity across app restarts or network interruptions. In iOS apps, the Keychain services provide encrypted storage for these identifiers, protecting them from unauthorized access while allowing retrieval for API calls, as recommended for handling authentication tokens in native networking frameworks like URLSession.^[42] Similarly, Android apps leverage SharedPreferences to persist session data, such as login states or tokens, in a key-value format that survives app lifecycle events, enabling seamless server synchronization without repeated logins.^[43] This approach ties local storage to remote sessions, supporting features like offline queuing of requests until reconnection. In enterprise systems, session IDs maintain continuity for remote access protocols, ensuring reliable user interactions over networks. The Remote Desktop Protocol (RDP) assigns a unique session ID to each logon, tracking resource allocation and state for multi-user environments on Windows servers, which allows administrators to monitor and manage active connections via tools like qwinsta.^[44] For Secure Shell (SSH), the transport layer generates a session identifier during key exchange as a hash of the shared secret and protocol parameters, serving as a unique marker for the entire connection to derive encryption keys and authenticate higher-level services.^[45] In IoT and real-time systems, session IDs enable efficient, low-overhead authentication and persistence in constrained environments. MQTT, a lightweight protocol for IoT messaging, uses short-lived session IDs—often tied to client identifiers or tokens—for device authentication during connect packets, allowing brokers like AWS IoT Core to resume sessions without full re-authentication if the clean session flag is disabled.^[46] WebSockets, for persistent real-time connections, inherit or generate session IDs from the initial HTTP upgrade handshake, maintaining stateful channels for bidirectional data exchange in applications like live updates, with brokers enforcing affinity to prevent disruptions.^[36] Emerging applications in blockchain wallets as of 2025 incorporate session IDs for secure, temporary transaction signing sessions, leveraging session keys derived from user wallets to authorize batched operations without exposing primary private keys. These keys, often implemented in account abstraction standards like ERC-4337, enable gasless or multi-signature flows in wallets such as Argent, reducing user friction while adhering to decentralized identity principles.^[47]

References

[1]
Session Management - OWASP Cheat Sheet Series
The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls ...
[2]
RFC 6265 - HTTP State Management Mechanism - IETF Datatracker
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP ...
[3]
RFC 7329 - A Session Identifier for the Session Initiation Protocol (SIP)
This document proposes a new SIP header to carry such a value: Session-ID. The mechanism defined in this document has been widely deployed.
[4]
RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2
RFC 5246 TLS August 2008 session identifier An arbitrary byte sequence chosen by the server to identify an active or resumable session state. peer ...
[5]
What is a session ID? | Definition from TechTarget
Dec 20, 2023 · A session ID, also called a session token, is a unique identifier that a web server assigns to a user for the duration of the current session.
[6]
How Do Web Sessions Work? | Hazelcast
To avoid storing massive amounts of information in-browser, developers use session IDs to store information server-side while enabling user privacy. Every time ...
[7]
Session Identifiers | Microsoft Learn
Oct 21, 2014 · In this article The session ID enables an ASP.NET application to associate a specific browser with related session data and information on the ...
[8]
Session Identification URI - W3C
Session identifiers are only created by clients. A Session-Id header should only be present in a response if one was specified in the corresponding request and ...
[9]
Session Identifier - an overview | ScienceDirect Topics
Session identifiers, also known as session IDs, are values used to identify each unique session in applications, enabling the maintenance of state between a ...
[10]
Session Timeout | OWASP Foundation
Session timeout represents the event occuring when a user does not perform any action on a web site during an interval (defined by a web server).
[11]
RFC 9110: HTTP Semantics
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.
[12]
https://www.rfc-editor.org/rfc/rfc9110.html
[13]
Slow startup on Tomcat 7.0.57 because of SecureRandom
Jan 28, 2015 · sessionIdGeneratorBase.createRandom=Creation of SecureRandom instance for session ID generation using [{0}] took [{1}] milliseconds.session ID generation using [SHA1PRNG] is not secure?Difference between java.util.Random and java.security ...More results from stackoverflow.com
[14]
RAND_bytes - OpenSSL Documentation
RAND_bytes() generates num random bytes using a cryptographically secure pseudo random generator (CSPRNG) and stores them in buf.
[15]
Storing UUID as base64 String - Stack Overflow
Apr 21, 2009 · I have been experimenting with using UUIDs as database keys. I want to take up the least amount of bytes as possible, while still keeping the UUID ...Is it safe to use UUID v4 to generate session IDs? - Stack OverflowHow to convert a Base64 encoded string to UUID formatMore results from stackoverflow.comMissing: hashed | Show results with:hashed
[16]
RFC 4122 - A Universally Unique IDentifier (UUID) URN Namespace
This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier).
[17]
How are session identifiers generated? - Stack Overflow
Mar 23, 2010 · Take a counter (generates unique value for new session) and append random bits generated by a CSPRNG. Make sure to get the minimum number of bits required ...PHP session IDs -- how are they generated? - Stack OverflowHow does a cryptographically secure random number generator work?More results from stackoverflow.com
[18]
How unique is the php session id - Stack Overflow
Sep 26, 2008 · So the the probability of one or more collision is less than one in 70 thousand billions. Hence the a 128-bit-size of the session_id should be ...Does the length of the text to be hashed affect the probability of a ...SHA collision probability when removing bytes - Stack OverflowMore results from stackoverflow.com
[19]
Session and state management in ASP.NET Core - Microsoft Learn
Apr 24, 2025 · Session state uses a store maintained by the app to persist data across requests from a client. The session data is backed by a cache and ...<|separator|>
[20]
Using HTTP cookies - MDN Web Docs - Mozilla
Oct 8, 2025 · The browser sends the cookie containing the session ID along with the corresponding request to indicate that it still thinks the user is signed ...
[21]
Apache Tomcat 9 (9.0.111) - Clustering/Session Replication How-To
Oct 10, 2025 · Tomcat can perform an all-to-all replication of session state using the DeltaManager or perform backup replication to only one node using the BackupManager.
[22]
Session fixation | OWASP Foundation
Session fixation is an attack where an attacker hijacks a valid user session by using an existing session ID before the user logs in.
[23]
Session hijacking attack - OWASP Foundation
The Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the Web Server.
[24]
Session Prediction - OWASP Foundation
Session prediction attacks predict session IDs to bypass authentication by analyzing ID generation, using predictable info or brute force.
[25]
[PDF] Randomness Attacks Against PHP Applications - USENIX
We provide a number of practical techniques and algorithms for exploiting randomness vulnerabilities in PHP applications.We focus on the predictability of.
[26]
Testing for Exposed Session Variables - OWASP Foundation
The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application ...
[27]
A07 Identification and Authentication Failures
Notable CWEs included are CWE-297: Improper Validation of Certificate with Host Mismatch, CWE-287: Improper Authentication, and CWE-384: Session Fixation.
[28]
https://owasp.org/Top10/A07_2025-Authentication_Failures/
[29]
Express session middleware
Create a session middleware with the given options. Note: Session data is not saved in the cookie itself, just the session ID. Session data is stored server- ...
[30]
Cookies, the GDPR, and the ePrivacy Directive - GDPR.eu
Companies do have a right to process their users' data as long as they receive consent or if they have a legitimate interest. Cookies and ePrivacy Directive.
[31]
How to use sessions - Django documentation
The session framework lets you store and retrieve arbitrary data on a per-site-visitor basis. It stores data on the server side and abstracts the sending and ...Enabling sessions · Configuring the session engine · Using sessions in views
[32]
Securing Rails Applications - Rails Guides - Ruby on Rails
Rails provides a session object for each user that accesses the application. If the user already has an active session, Rails uses the existing session. ...
[33]
$$_SESSION - Manual - PHP
Note: This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script.Session Functions · Session_start · $_ENV
[34]
express-session
### Summary of express-session Usage in Node.js for Web Session Management
[35]
Managing sessions of anonymous users in WebSocket API-based ...
Mar 10, 2023 · This blog post demonstrates how to reconnect anonymous users to WebSocket API without losing their session context.Managing Sessions Of... · Understanding Sample Code... · Deleting Inactive Users
[36]
https://aws.amazon.com/blogs/compute/managing-sessions-of-anonymous-users-in-websocket-api-based-applications/
[37]
https://tools.ietf.org/html/rfc7519
[38]
Using OAuth 2.0 to Access Google APIs | Authorization
Sep 15, 2025 · 1. Obtain OAuth 2.0 credentials from the Google API Console. 2. Obtain an access token from the Google Authorization Server. 3.
[39]
OAuth 2.0 Authentication for Azure DevOps REST APIs
Jul 14, 2025 · Azure DevOps Services uses the OAuth 2.0 protocol to authorize applications and generate access tokens for REST API calls.<|separator|>
[40]
Stateful session affinity for stateful services · Issue #30171 · grpc/grpc
Jul 1, 2022 · In stateful services, once a particular "session" is assigned by a load-balancer to a particular service backend, all future activity on that session must be ...
[41]
Sharing access to keychain items among a collection of apps
Enable apps to share keychain items with each other by adding the apps to an access group.
[42]
Save simple data with SharedPreferences | App data and files
Feb 10, 2025 · A SharedPreferences object points to a file containing key-value pairs and provides simple methods to read and write them.
[43]
Remote Desktop Sessions - Win32 apps - Microsoft Learn
Aug 19, 2020 · Each session is identified by a unique session ID. Because each logon to a Remote Desktop Connection (RDC) client receives a separate session ID ...
[44]
RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol
SSH maintains its own group identifier space that is logically distinct ... It also derives a unique session ID that may be used by higher-level protocols.
[45]
MQTT - AWS IoT Core
MQTT (Message Queuing Telemetry Transport) is a lightweight and widely adopted messaging protocol that is designed for constrained devices.
[46]
From Sign-In with Ethereum to Session Keys - SpruceID
Feb 3, 2022 · Session keys will emerge as a dominant design pattern that simultaneously enables seamless UX while also replacing cookie-based sessions.