0

We have a standard microservices setup (Identity Server, API Gateway, services, etc).

Some of the services schedule events to be dispatched in the future (future = anything from mins to months ahead) - the underlying mechanism is an AWS SQS queue. We are looking to implement a feature that means that something might happen to the user/account that would mean the action shouldn't be executed (e.g. the user is deleted, or the account is closed). The timescale would beyond the usual lifetime of an access token.

To support this, we are considering either -

  1. Add the user/account GUIDs to a header on the message in the queue, create an endpoint for the service to check the user/account status when the scheduled event is received. If this returns false, the message is discarded, else retrieve an access token for the service (using the client credentials flow) and pass the user/account on in a non-standard header (as the token will no longer contain the sub).

  2. At the point of scheduling the event, use token delegation to generate an access token and a refresh token - the refresh token with an infinite lifetime, store the refresh token in the event body. If in the meantime something happens to the user/account we revoke the refresh token. When the scheduled event is received the service simply uses the refresh token to get a new access token (scoped for their specific requirements) and carries on as normal (contains the sub). If the token exchange fails the event is discarded.

Having discussed the options internally, some of the team feel it is "wrong" to store a refresh token (although this is how most client applications work), or having an infinite lifetime refresh token is a "hack" (Spotify seems to use infinite lifetime refresh tokens). My feeling is the first option is replicating the purpose of a refresh token, and having to "fallback" to checking the header for the sub on every endpoint a bit "hacky" (and potentially an attack vector).

I've not been able to find any specific guidance on handling authorization in this circumstance (possible Google-fu malfunction), so any guidance/input helpful.

1
  • If user status influences your service, wouldn't the service consume user service's events and modify the records accordingly already? If not, I think this is a bit sus, but if it does, why would you need to request another service for that info?
    – Blaž Mrak
    Jun 15 at 13:03
1

Access tokens are used to ensure that requests from outside your system come from an authenticated user. Once the request is in the system, you don't need the access token when communicating between parts of the system, especially not when long delays or schedules are involved.

Long-lived access tokens can be useful for allowing the user to use a service without re-login, but they should not be stored within your system to impersonate the user at some later point in time.

If actions are scheduled for future execution, you may either re-check the account authorization at the time you're intending to execute them, or you may discard pending actions upon events such as account termination which feels a bit cleaner to me.

2
  • I think they are using the user service's API to check the user's info and do not have an "admin" token for the services. I don't see why else they would need to save user's token.
    – Blaž Mrak
    Jun 15 at 14:52
  • @Hans-Martin Mosner I don't agree with your suggestion that you don't need the access token between different parts of the system - token delegation seems an established pattern. Also there is no suggestion of storing access tokens - just refresh tokens.
    – Keir
    Jun 15 at 17:26

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.