ArturkA

Ever wondered what's behind that big long number that we call a "SteamID"? It isn't just random; there are actually four numbers packed into it.
 
A SteamID has four parts:
Universe - The "instance of Steam" in which this ID is used. There is only one public Steam instance. Its name is "public", and its number is 1. The other universes are used internally at Valve for testing. Type - A SteamID can actually stand for several different types of accounts. The most common is individual, which is an individual user account. There are also types for clans (Steam groups), gameservers, anonymous gameservers, anonymous users, and more. Instance - This number is a bit finnicky. For the most part it's just a static number. For example, for individual SteamIDs the instance is pretty much always 1 (for desktop). Account ID - This is the actual ID of the account. Account IDs increment over time. If you know what universe, type, and instance an ID is for, then this is all you need to uniquely identify the account. As I mentioned previously, a 64-bit SteamID is actually broken down into four parts:
8 bits for the universe 4 bits for the type 20 bits for the instance 32 bits for the account ID This means that in order to get an account ID out of a 64-bit SteamID, all you need to do is steamID & 0xFFFFFFFF.
 
Warning: The Steam WebAPI and Steam Community website actually don't care about the instance as long as you've set the type and universe correctly. This means that if you're taking user input for SteamIDs, you could end up with duplicate accounts. For example, the SteamIDs 76561198006409530 and 76561202301376826 are considered identical because the universe, type, and accountids are the same. Try it for yourself: https://steamcommunity.com/profiles/76561198006409530 https://steamcommunity.com/profiles/76561202301376826
 
Failure to take this into account can result in such exploits as this:
 

 
(Yes, those are actually the same Steam account)
 
Common SteamID Confusion
SteamID aspects are a common source of confusion. For starters, what do you call various SteamID formats?
This is the 64-bit SteamID (or just SteamID) format: 76561198006409530 This is the Steam3 format: [U:1:46143802] This is the Steam2 format: STEAM_0:0:23071901 (or the newer Steam2 format: STEAM_1:0:23071901) The "partner ID" in trade offer URLs is actually the account's account ID.
 
Reading Rendered IDs
Here's how to interpret the rendered ID formats.
Steam3 Format
[T:U:A] or [T:U:A:I]
T - This is a single letter (case-sensitive) which tells you what type of account this is. The characters are documented on the Valve developer wiki. U - This is the universe to which this SteamID belongs. Unless you work for Valve, this will always be 1. A - This is the account ID for this SteamID. I - This is the SteamID's instance number. May be omitted if the instance is the default for that ID type or can be determined in other ways. Steam2 Format
The Steam2 rendered format can only be used for individual SteamIDs.
STEAM_X:Y:Z
X - This is the universe to which this SteamID belongs. Older games use 0 to stand for public, newer ones use 1. Y - This is the SteamID's accountid modulo 2. Z - This is the SteamID's accountid halved and rounded down. Working with SteamIDs in code
If you're using Node.js, you can use node-steamid to parse, create, and deal with SteamIDs.
If you're using PHP, you can use php-steamid.
If you're using C#, SteamKit has a SteamID class.

This post is outdated. Please see the updated version.
Every website out there (that doesn't use HTTP authentication) uses cookies to identify user sessions. Cookies usually contain session IDs, which are looked up on the server in order to determine who the session belongs to. Steam is no different.
All Steam websites (the store, community, the help site) use the same cookies to identify user sessions. There are four cookies which are required to identify a Steam session:
sessionid steamLogin steamLoginSecure* steamMachineAuth* * = this cookie should only be sent over HTTPS
Despite its name, the sessionid cookie is merely a CSRF token. Its value can be anything, as long as it matches the sessionid POST parameter in your POST requests. Steam will randomly assign you one the first time you hit one of the websites without already having one, even if you aren't logged in. They are not tied to accounts or to sessions.
steamLogin and steamLoginSecure are the actual session cookies. Their format is: (your 64-bit SteamID + two pipe characters, percent encoded as %7C + a 40-character uppercase hexadecimal token). The hexadecimal token will differ between the two cookies, but the SteamID will be the same. steamLoginSecure should be sent with all HTTPS requests, and only for HTTPS requests. These cookies are short-lived and once invalidated (the exact circumstances that cause them to be invalidated are unclear), you will be logged out.
steamMachineAuth is your Steam Guard identification cookie. You should replace with your actual 64-bit SteamID, so for example the name of my cookie would be steamMachineAuth76561198006409530. This cookie's value is simply a 40-character uppercase hexadecimal token. The cookie identifies a "machine" for Steam Guard, so that you don't have to provide an email code every time. This cookie is still present if you're using the mobile authenticator, even though you have to provide a code for every login. This cookie's issue date is also used as the "first sign in" date for purposes of determining trade restrictions. This cookie effectively lasts forever, so you should save it and reuse it between sessions. This cookie is required for trade offers to work.
Note: Since Steam switched to HTTPS-only, steamLogin appears to no longer be necessary and is therefore no longer issued to web logins. It does seem to still be issued to Steam client-based logins.
How to Get Cookies
You can get Steam login cookies in one of three ways.
You can log in to any Steam site in a browser, which will issue you cookies for that domain (and also do some JavaScript to set those cookies for other Steam domains). node-steamcommunity can do this for you. You can use the undocumented IMobileAuthService/GetWGToken WebAPI method with an oAuth token. node-steamcommunity can do this for you. You can use the ISteamUserAuth/AuthenticateUser WebAPI method with a nonce (loginkey) received from the CM. Sessions negotiated this way will have no steamMachineAuth cookie, and that cookie is unneeded for these sessions (trade offers will still work). Sessions negotiated this way will be invalidated as soon as the client session which received the CM nonce disconnects. node-steam-user can do this for you. Once you have cookies, you can use them with any of a number of modules, e.g. node-steam-trade, node-steamcommunity, node-steamstore, etc.
Cookie Expiration
Cookies expire and become invalid at seemingly-random times. There seems to be no real rhyme or reason as to when it happens, but it generally does happen whenever an account is logged in somewhere else, and on some unspecific time interval.
If you log in to Steam using node-steam-user, you will be issued cookies, but they are only linked to the CM session in that they will expire if the session disconnects. They also follow normal expiration rules, meaning that even if your Steam client session is still connected, your cookies might have expired and thus your web requests will indicate that you aren't logged in. If this happens, you'll need to use webLogOn() to get new cookies.

Cookie Usage
I'll briefly explain how cookies and sessions work in my libraries. A quick overview on statefulness: HTTP is stateless. Each request is distinct from every other request, and thus there is no way to link two requests together (except by using cookies). For this reason, to keep track of which user is logged in, every site on the planet uses cookies. Typically, cookies contain an opaque session ID which the server looks up to see which account you're using. Steam is no exception. TCP is stateful. Each message sent over a TCP connection belongs to that connection and thus it's easy to link two messages together.
node-steam-user connects to the CM using TCP (or optionally UDP, but it acts like TCP anyway). This is a stateful connection, and there is no need to use cookies to identify it.  Therefore, node-steam-user has no need for cookies. While it is capable of producing cookies, it does not save them and doesn't use them in any way except to make them available to the end-user for use elsewhere. node-steamcommunity communicates with Steam over HTTP, which is stateless. Thus, cookies are required in order to authenticate your requests to your account. node-steamcommunity can either accept cookies using the setCookies method (which can accept cookies obtained by any means, including node-steam-user), or it can produce cookies using the login method. Either method will save the cookies internally in the SteamCommunity object and those cookies will be used to authenticate every HTTP request. node-steamstore is identical to node-steamcommunity, although it cannot create cookies (i.e. it can only accept them using setCookies). node-steam-tradeoffer-manager is identical to node-steamstore, except it uses node-steamcommunity under the hood for its HTTP communication. Thus, if you instantiate TradeOfferManager and pass a community instance to the constructor, calling setCookies on the TradeOfferManager will also call setCookies on the SteamCommunity, and therefore you need not call setCookies on SteamCommunity (although it doesn't hurt anything, either). In list form, where a producer can create cookies and a consumer can use cookies:
steam-user: producer steamcommunity: producer, consumer steamstore: consumer steam-tradeoffer-manager: consumer steam: producer steam-trade: consumer

When using Steam in-home streaming, network communication is encrypted with the auth secret. It's called a pre-shared key because it's an encryption key that is shared with both parties (in this instance, the machine the games are getting streamed from and the machine they're getting played on) by Steam, before the in-home connection is established.