We have a use case where we want to retain user context in a scheduled task in a downstream service. After going through the docs, I found this doc, Set up OAuth 2.0 On-Behalf-Of Token Exchange | Okta Developer. This doc talks about maintaining the context in downstream services after sign in from UI. In this doc, the flow is that you exchange token for the app integration for your access token from the native app.
We have a use case where the downstream service’s task will run long after the user has signed in or given permission in UI. It is not triggered exactly through the native app, it is triggered through a scheduler. We want to keep the user context when it is triggered later.
Our current solution is to save the access token in our DB and use that repeatedly later for the exchange.
Wanted to check if there is any better way to solve this as saving access token in our DB might not be ideal.
typically for a scheduled task you would use the client credentials flow which does not contain a user context, but is designed for machine to machine scenarios.
If you need user context you could,
use a refresh token to keep updating an access_token after a job runs
use the resource owner password grant flow (not recommended requires storing the user credentials and a client secret)
Programmatically do an auth code/PKCE flow. Depending on how this is done, MFA/authenticator requirements this can get complicated and will have some of the same issues as the password grant flow that credentials may need to be stored.
I suggest reaching out to the Okta Professional Services Team who most likely have configured implementations with similar requirements.