Well, you _could_ encrypt the tokens but you can't hash them like a password so they have to be stored in some format in their entirety.

However, it seems reasonable to infer they are referring to storage in the DB itself. How would you suggest they encrypt it securely at rest for an out-of-the-box "setup and go" scenario?

I will note that a lot of the existing "plugin" OAuth type providers for popular web frameworks don't encrypt user tokens in the DB by default either.

You can likely encrypt the tokens symmetrically by a key on the server (can also have that key be stored in a secret manager and retrieved for the purposes of the encryption/decryption only); obv you have to make sure the key doesn't leak but it's significantly better than storing this type of data unencrypted in DB.

Interesting point on existing providers not encrypting user tokens in the DB by default tho - wouldn't expect that hmmm

What I'm doing is have a _separate_ encryption key for _each_ OAuth provider on the server, encrypt with that and save it in a HTTPOnly browser cookie. This way if the key gets stolen from the server, the attacker doesn't even have any user OAuth tokens. If the cookies are stolen from the user's browser, the attacker can't do anything with it. If one user's cookie is stolen AND the encryption key is stolen, only one user is affected. As the cookie is HTTPOnly, there is no XSS surface, the client need to communicate with the server to be able to API requests to the OAuth provider.