Hello All, I have raised a github issue describing my thoughts on how to generate and use transaction tokens in batch long running processes. Link: https://github.com/oauth-wg/oauth-transaction-tokens/issues/111
We already have established that Tx tokens must be short lived. However, the claims that the token carries are valid even for asynchronous/batch jobs that outlive the token lifetime. In these cases, there is need to securely obtain the Tx token as the batch process resumes after a pause or a consumer gets a message from message queue after a long delay. The core idea revolves around the concept of refresh token which is essentially a special type of signed token with longer lifetime (higher TTL) and issued by Tx token service. The token cannot be used for data access but only for obtaining a new Tx token. There are two operations the Tx token service have to support – getRefreshToken(TxToken) and getTxToken(RefreshToken). The refresh token will contain the encrypted claims from the token or it can a uniqueId generated by TxToken service and TxToken service stores claims against that uniqueId in a persistent store. The later adds overhead on Tx token service to maintain persistent store. Either way, with refresh token, if a workflow pauses for long duration, when it resumes it can use refresh token to obtain Tx Token. TxToken service must authenticate the calling service and can also do additional fine grained authorization if required before issuing Tx token. On similar lines, I have opened another github issue for updating guidance on replacement token lifetime to include that replacement token lifetime should be whatever is left on the original token used to obtain a new one. https://github.com/oauth-wg/oauth-transaction-tokens/issues/110 Regards, Ashay
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
