Dr. McKay Posted October 2, 2023 Report Share Posted October 2, 2023 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. In order to identify a Steam session, only a single steamLoginSecure cookie is required. You may also see a sessionid cookie. Despite its name, this cookie is merely a CSRF token (this is verified on Steam's cookie preferences page). Its value can be anything, as long as it matches the sessionid parameter in your state-mutating requests (which should ordinarily only be POST requests, but Valve is Valve and they use GET for some mutation 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. steamLoginSecure is the actual session cookie. It begins with your 64-bit SteamID, followed by two pipe characters percent-encoded as %7C, and then a JWT. If you want to know when your cookie expires, you can decode the JWT and check the exp field. Your IP address is also encoded into the JWT, and it appears that your session may be invalidated if you make a request from a differing IP address. Steam Guard auths are handled by the new auth server, and aren't described here. They don't appear to be used if you're using TOTP as your authenticator. How to Get Cookies The auth server launched in August 2022, alongside the beta of the new Steam Mobile App. The auth server provides a unified authentication interface that is consistent between the three Steam platforms (desktop client, website, mobile app). As of time of writing (2023-10-01), all of the old auth schemes still work, but this can't be expected to remain the case forever. Upon successful authentication, the auth server issues an access token and a refresh token. Access tokens are used for the steamLoginSecure cookie. Refresh tokens are used to get new access tokens, and also are used to log into the Steam client. If you want to maintain a session for an extended duration without re-entering your password (or putting it into a config file), refresh tokens are the way to do it. The steam-session npm package was created to interface with the auth server. If you need login cookies, this is the best way to get them. If you're already using steam-user or steamcommunity, they are using steam-session internally to generate cookies. Outside of special cases, there's no reason for you to use steam-session directly if you're already using steam-user or steamcommunity. steam-user steam-user uses steam-session for authentication as of v4.28.0, and cookies are generated using the new auth scheme as of v4.29.0. Use the webSession event to acquire your cookies. Cookies generated this way will be invalidated when your SteamUser client disconnects. steamcommunity steamcommunity uses steam-session for authentication as of v4.0.0. Cookies are returned to you when the login() method promise resolves. 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. steam-user connects to CMs (connection managers, i.e. Steam servers) using long-lived TCP connections. This is a stateful connection, and there's no need to use cookies here. steam-user is capable of producing cookies, but 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. steamcommunity interacts with Steam over HTTP, which does require cookies to authenticate requests. steamcommunity can either accept cookies using the setCookies() method (which can accept cookies obtained by any means, including steam-user), or it can produce cookies by using the login method (which internally uses steam-session). Either method will save the cookies internally in the SteamCommunity object, and those cookies will be used to authenticate every HTTP request. steamstore is identical to steamcommunity, although it cannot create cookies and can only accept them using setCookies(). steam-tradeoffer-manager is identical to steamstore, except it uses steamcommunity internally for HTTP communication. Thus, if you instantiate TradeOfferManager and pass a community instance to the constructor, then calling setCookies() on the TradeOfferManager instance will also call setCookies() on the SteamCommunity instance. Therefore, you don't need to call setCookies() on the SteamCommunity instance in this case (although it doesn't hurt anything, either). steam-session is what every producer module uses internally to authenticate with Steam and to produce cookies. If you only need session cookies and don't need to make use of any other modules' features, then you can use steam-session directly. Here's a summary table, where a producer can create cookies and a consumer can use cookies. Producer Consumer steam-user ✅ steamcommunity ✅ ✅ steamstore ✅ steam-tradeoffer-manager ✅ steam-session ✅ Link to comment Share on other sites More sharing options...
Recommended Posts