I want my clients to be able to schedule a purchase for a given date. When they perform this scheduling action, they are authenticated with an oauth2 token. However the date could be so far from now that the token might have expired when the purchase is triggered. I need to check the user identity and whether they still can perform the purchase when it is triggered, not when it is scheduled.

What would be the best practice to be able to perform this scheduling action ? Should I increase the refresh token expiring date, so that the token can be refreshed before performing the check, when it is triggered ? I have seen other people do this (ex: here), but I don't know if it is a best practice to increase to, say, 2 years, if I want my clients to be able to schedule a purchase for 2 years.


  • Are you sure the scheduled purchased should be performed on the client (which requires a token) and not on the server (which would "just" be an entry in a scheduled_purchases table)? The way I feel it is that it should be done on the server side with scheduled purchases being created on an API (with a token) but I might not have grasped what you use-case is exactly.
    – Tangui
    Oct 21 '20 at 21:23
  • Am I missing something here? Cause I assume you know you can create a token that will be valid in the future for such a condition (there JWT after all)granted that would mean you have compleet control over your key cycle and know in advance when a specific key will be valid. And such a token must be extremely limited in scope since anything might happen to it between now and than...
    – LvB
    Oct 21 '20 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.