Ask HN: How do you do authorization for background jobs?
2 comments
For this type of background job use-case (ex. some backfill, processing etc), I would think the main reason for authn/authz would be to ensure that only the background job process can read and edit the appropriate user data. In that case, you would need some token-based machine-to-machine authz with scoped tokens that limit what data the background process can access.
Generate a one-time or short-lifespan token, pass that with the user ID and simulate a login/session.
For a web app I work on that does this we generate auth tokens in the database, with an associated lifetime. Tokens are long-ish hashes from random bytes. The token is passed in the URL with the user ID. The app logs in as that user, deletes the token. Expired tokens that weren't used for some reason get purged when they expire (scheduled event running in the database).
You could associate the token with a specific user ID in the database, use a secret to base the hash on so you don't need the database... multiple possible variations depending on your needs and security requirements.
For a web app I work on that does this we generate auth tokens in the database, with an associated lifetime. Tokens are long-ish hashes from random bytes. The token is passed in the URL with the user ID. The app logs in as that user, deletes the token. Expired tokens that weren't used for some reason get purged when they expire (scheduled event running in the database).
You could associate the token with a specific user ID in the database, use a secret to base the hash on so you don't need the database... multiple possible variations depending on your needs and security requirements.
However when we need to run background jobs or some asynchronous workflow on behalf of the user, we do not have the Cookie/Token of the user. We do have the user id but not the session. How do you solve for AuthZ specifically for your background jobs and dependent microservices?