Access token to refresh token

Scenario:

We would like our hosted software to connect to our APIs impersonating a client user, as the user is hosting this software on our environment. We would like to give every user a private access token so the backend can always impersonate a user when needed. In order to do so, can we use the end users access token to generate a refresh token for this user once and reuse it in our backend applications?


Update: (follow-up to @jmangelo answer)

If I understand correctly, the flow would than be as follows:

  1. SPA requests offline access token (wouldn’t this create a security problem?)
  2. SPA sends offline access token for secured central storage to api
  3. Client enables one of our unattended SAAS services (runs entirely on its own and separated from the web api and SPA) → this SAAS application runs not as an API but a standalone app
  4. SAAS service retrieves the offline access token from secured central storage
  5. SAAS service impersonates the user to request for user data
  6. User logs out of SPA and the service keeps using the offline access token
  7. SAAS discovers it needs to increase on capacity, uses the clients offline access token to start up new instances and impersonates user.

Overall we need to create an API token for each user we have in order to host services and impersonate the user.

I might be missing something, but if your client application requires offline access on behalf of the user then it should state that as part of the authentication/authorization request.

Assuming that all necessary conditions are met, like using a suitable grant type and the API in question allowing offline access then if the client applications requests the offline_access scope as part of the initial request a refresh token would be issued along-side the access token.

The issued refresh token would allow the application itself to obtain new access tokens without further involvement of the user which seems to meet your requirements.

In conclusion, there’s no exchange of an access token for a refresh token. Instead, the refresh token would be requested and issued alongside the access token during the initial authentication request.


Update:

For a SPA the above does not apply exactly as stated; however, you failed to mention this was a scenario in specific for a SPA in your original question.

In a SPA + backend you still perform the initial request including the offline_access scope to signal that you want to request a refresh token as part of the authentication/authorization process. However, you need to do this using an hybrid flow where ID tokens and access tokens can be returned immediately from the authorization endpoint, but refresh tokens are obtained through your back-end by exchanging the authorization code that was also returned as part of the authorization endpoint response.

For reference information on the hybrid flow see: