Compatibility between old access_token storage and new steam-session refreshToken (+2 refreshToken questions)

[3urobeat]

Hey, I'm implementing the new `steam-session` login flow at the moment and I'm storing the retrieved `refreshToken` in a database so the user doesn't need to input a Steam Guard code on every start. 

If I understand correctly `steam-user` did basically the same thing (I do not understand the difference between access_token and refreshToken yet) by storing an access token in a sentry file. This token seems to be available at `client._logOnDetails.access_token` when logged in.

So my question:
Is it possible to retrieve this token before being logged in so that I can transfer it to my new `steam-session` database?
Otherwise everyone updating to the new version of my bot would need to type in the guard codes again for every account (which would also cause downtime since the automatic updater would update, restart the bot and then get stuck when trying to log in again with the new system as it would wait for a guard code input).

My compatibility feature runs after the update but before logging in so I don't have access to the old steam-user client object.

 

Also two more things I'm a little unsure about this new system, which I would like a second opinion on:
Should I encrypt my refreshToken database somehow? It looks like you did that with the sentry .bin files but how could I go about that myself? The login data supplied by the user is unencrypted anyway so I'm not sure if it would even make a difference.

Is there any possibility that a refreshToken can be "renewed" (while still valid) without asking for a steam guard code or is the user forced to go through the steam guard code process at least every 200 days for each account? I'm asking because this would get really annoying when using my bot with many accounts.

 

Thank you in advance!

[Dr. McKay]

access_token (client._logOnDetails.access_token) and refreshToken are the same thing. The field in the logon message is named access_token, but steam-user accepts it as refreshToken to make it less confusing which type of token you need to supply (since steam-session returns both an access token and a refresh token).

As far as I can tell, the refresh token you receive from steam-session is good for the full 200 days, so you can just keep using it over and over. I'm not aware of a way to get a new refresh token without going through the entire auth flow again. I wouldn't be surprised in the slightest of the official Steam client just pops up the login flow again in 200 days.

It's up to you how you store your tokens. Encryption at rest is rarely a bad idea, but it's also pretty useless if you're also storing the keys alongside the encrypted data, for example. Sentry files aren't encrypted either, they're just blobs of random binary data by design.

[3urobeat]

Alright, thank you very much for the response. Sad to see the 200 days limit but I guess it makes sense from Valve's perspective.

Two more things I just stumbled about:
The steam-session lib does not support proxies right? I always used proxies for steam-user and steam-community when using many accounts to avoid cooldowns (not specifically for the logins itself but I always figured it could help there as well as Steam will surely block lots of logins from the same IP).
Could I now run into errors when trying to create many new sessions in a short period of time? Or does Steam only care about the steam-user logOn itself with the refreshToken?

You state in the steam-user readme "If you attempt to log on using a refresh token that isn't valid for use with client logins, the app will crash with a relevant error message.".
Since this is pretty vague I skimmed through the EResult enums. The only steam-user error event eresults on which I should invalidate the token used and get a new session would probably be InvalidLoginAuthCode and ExpiredLoginAuthCode I guess? Or am I missing something?

Edited October 11, 2022 by 3urobeat

[Dr. McKay]

8 hours ago, 3urobeat said:

The steam-session lib does not support proxies right? I always used proxies for steam-user and steam-community when using many accounts to avoid cooldowns (not specifically for the logins itself but I always figured it could help there as well as Steam will surely block lots of logins from the same IP).

Not yet, but it will.

8 hours ago, 3urobeat said:

You state in the steam-user readme "If you attempt to log on using a refresh token that isn't valid for use with client logins, the app will crash with a relevant error message.".
Since this is pretty vague I skimmed through the EResult enums. The only steam-user error event eresults on which I should invalidate the token used and get a new session would probably be InvalidLoginAuthCode and ExpiredLoginAuthCode I guess? Or am I missing something?

Maybe this is a little vague, I'll try to rewrite it. This is only talking about a case where you supply a token that wasn't generated using EAuthTokenPlatformType.SteamClient. If the token is invalid for any other reason, you'll get the normal error event with an EResult value (probably InvalidPassword, but I haven't checked).

Edited October 12, 2022 by Dr. McKay

[jaymie]

On 10/11/2022 at 6:04 PM, 3urobeat said:

Hey, I'm implementing the new `steam-session` login flow at the moment and I'm storing the retrieved `refreshToken` in a database so the user doesn't need to input a Steam Guard code on every start. 

If I understand correctly `steam-user` did basically the same thing (I do not understand the difference between access_token and refreshToken yet) by storing an access token in a sentry file. This token seems to be available at `client._logOnDetails.access_token` when logged in.

So my question:
Is it possible to retrieve this token before being logged in so that I can transfer it to my new `steam-session` database?
Otherwise everyone updating to the new version of my bot would need to type in the guard codes again for every account (which would also cause downtime since the automatic updater would update, restart the bot and then get stuck when trying to log in again with the new system as it would wait for a guard code input).

My compatibility feature runs after the update but before logging in so I don't have access to the old steam-user client object.

 

Also two more things I'm a little unsure about this new system, which I would like a second opinion on:
Should I encrypt my refreshToken database somehow? It looks like you did that with the sentry .bin files but how could I go about that myself? The login data supplied by the user is unencrypted anyway so I'm not sure if it would even make a difference.

Is there any possibility that a refreshToken can be "renewed" (while still valid) without asking for a steam guard code or is the user forced to go through the steam guard code process at least every 200 days for each account? I'm asking because this would get really annoying when using my bot with many accounts.

 

Thank you in advance!

sir, can you tell me how to use refresh_token to get new access_token, request /jwt/finalizelogin again?

[Dr. McKay]

steam-session should be able to handle all your auth needs for you. It's mostly complete at this point.