Add Batch token for asynchronous long running workloads #149
Conversation
Batch token for asynchronous long running workloads
| @@ -168,8 +168,14 @@ A service within a call chain may choose to replace the Txn-Token. This can typi | |||
|
|
|||
| To get a replacement Txn-Token, a service will request a new Txn-Token from the Txn-Token Service and provide the current Txn-Token and other parameters in the request. The Txn-Token service must exercise caution in what kinds of replacement requests it supports so as to not negate the entire value of Txn-Tokens. | |||
|
|
|||
| ## Batch Txn-Tokens | |||
|
|
|||
| A service within a call chain may start asynchronous flows by invoking a workflow, or sending a message in queue or starting a batch job. Asynchronous flows may take minutes, hours or days to complete depending on the business use case. The service cannot pass Txn-Token to downstream as the asynchronous flow could outlive the lifetime of the Txn-Token. In such cases, the service can call Txn-Token Service to exchange a valid Txn-Token for a long lived Batch Txn-Token. Then use the Batch Txn-Token to invoke downstream asynchronous workload. At later point of time, when asynchronous workflow requires to call an internal service, resembling a synchronous flow, the workload can use the Batch Txn-Token to call Txn-Token service and request a valid short lived Txn-Token. The workload will then use the Txn-Token to call another internal service. A Batch Txn-Token MUST be encrypted and only Txn-Token Service MUST be able to decrypt a Batch Txn-Token. A validating party will not be able to decrypt the Batch Txn-Token. During exchange of a Batch Txn-Token to Txn-Token, Txn-Token service MUST only add those claims back which are still valid at that issuance time. | |||
There was a problem hiding this comment.
This would effectively function as a refresh token. Having an opaque (random) value (not encrypted) would be sufficient (encrypted token could also work).
It would be important to require that the service must authenticate itself to acquire the batch token, and that the batch token should be bound to the originating service. For a long-lived token it would also be important to define invalidation semantics (e.g. based upon the Txn-Id).
An alternative approach would be to allow Txn-Token refreshing with service identity.
|
|
||
| 6. An intermediate service determines that it needs to start a workflow. Once workflow is started successfully, then it can respond back to incoming request. The workflow will then can run for longer duration. The intermediate service needs to obtain a Batch Txn-Token to pass to the workflow as the workflow execution will outlive Txn-Token lifetime. It requests a Batch Txn-Token from the Txn-Token Service. It passes the incoming Txn-Token in the request, along with any additional context it needs to send the Txn-Token Service. | ||
| 7. The Txn-Token Service responds with a Batch Txn-Token | ||
| 8. The service that requested the Batch Txn-Token uses that Batch Txn-Token for invoking workflow |
There was a problem hiding this comment.
Would it not be the responsibility of the workflow system to acquire/exchange the batch token? If the service creating the batch token is not the same as the one using it to create further tokens, there may be opportunities for breaches. At the very least the workflow/receiver would not be able to verify the batch token validity.
Batch token was discussed here at #111. The PR is first draft to add batch token in RFC.