CODEWITHSUNDEEP
oauthazure-active-directorymicrosoft-graph-api
FabianTe
FabianTe

Reputation: 649

Is it common practice to persist refresh tokens for background services

I build an application that must use delegated AAD permissions to interact with the Graph API. App permissions are no option due to secruity restrictions.

This application is a background service which has some minimal UI for configuration of the application. The idea is to have users log into the UI once (via AAD), granting the required permissions. After that users will mostly never need to use this UI as there is nothing vital to configure.

This creates a situation where the user will only once present a usable access token. After that initial onboarding, the application will have to use a refresh token once in a while to keep being able to use the Graph API.

Is my assumption correct that in order for this to work, I must persist refresh tokens of each user? Intuitively this seems like both a security risk (if not implemented properly) and also a kind of complex system which would not only store tokens but also have additional background refreshing tokens and potentially informing users about eventual expired tokens (in case of failing token refreshs).

Upvotes: 0

Views: 571

Answers (1)

Tore Nestenius
Tore Nestenius

Reputation: 19921

Yes, the refresh token you receive back is unique for each user, so you really need to keep the refresh and access token separate between each user and store them in a secure way.

Please also note that in some systems you get a new refresh token each time you use it.

Either you use the refresh token with a timer and refresh them each XX minutes. Or you do the refresh when the user receives a 401 Not Authenticated response from the API.

Upvotes: 2

Related Questions