Refresh tokens for impersonating user credentials: how to implement them?
The web app I'm developing makes use of the concepts of "access token" and "refresh token", even though it uses its own auth scheme.
In certain situations, the web app needs to get an "impersonation token" from the OS it's running under, with the credentials of the user, when the user logs in.
This is fine, if the refresh token is used while the session is running, as in that case the server keeps the impersonation token alive, but poses the question of how to implement the case of a "cold start" of the application without asking the user to relogin: in that case the credentials must necessarily be provided automatically to the server, for the impersonation to work without the user explicitly logging in, and the question arises about where and how to store them.
The credentials would have to be encrypted, of course, with a key that is not stored alongside them.
So, let me guide you through my thought process.
Scenario 1: the refresh token might itself contain the credentials, encrypted with authenticated encryption
If refresh token is encrypted with a key on the server, in theory I could store the credentials in the refresh token itself. However, it feels very risky: in case the key were to be exfiltrated from the server, any refresh tokens in the open could be decrypted and credentials stolen.
It feels like a no go.
Scenario 2: the refresh token, itself encrypted with authenticated encryption, might contain a key that was used to encrypt the credentials.
Say the refresh token contained a token id and an encryption key. This key is used to encrypt the user's credentials with authenticated encryption. The whole token is then encrypted with a separate key on the server, with authenticated encryption.
When the server is presented with the refresh token, it first decrypts it, then it extracts from it the token id and the user's credentials encryption key. Then it looks for this token id in the database and tries to decrypt the corresponding user's credentials.
This scenario feels more secure, since an exfiltration of the server's key is not enough anymore to decrypt the users' credentials, one would need to have access to the whole server's database to do that, and to the refresh token.
Yet, I'm not an expert in this field and I'm wondering if any of that makes sense.
The question for you is: does it?
I still have the option to ask the users whose impersonation token is necessary to relogin any time they reopen the app, yet I'd avoid that if possible.
