Batch or long running processes and extending lifetime of a token
ashayraut opened this issue · 5 comments
If we provide refresh token which is signed and contains the original token inside it, then refresh token when passed to Tx token service, then Tx token service can verify if 1) refresh token is signed with its private key, 2) the token inside will be expired but it can still read the token and verify caller's identity is associated with all the claims or not, if yes, then it can get new Tx token with same claims or it can get new token but claims that are associated to them and not the exact claims present in the token inside refresh token. Why not request new token always when batch process or workflow resumes from long pause? Because sometimes the service might just want to use the claims of its caller (as long as its permitted to do so) rather than new token.
For example, if an internal service C is called by A and B, and C is allowed to make requests to D for tax or accounting purpose.
A->C
B->C
C->D
A is allowed to make request and request Tx token for tax purpose.
B is allowed to make request and request Tx token for accounting purpose.
C is allowed for both accounting and tax purpose because is a common service
Now, C simply wants to use usage claim based on who called - A or B. C can do so by passing token generated for A or B to D. But if C is a workflow that pauses for more than TTL of Tx token, then token expires and it loses all the context about claims associated with A and B. In such case, before going on long pause, C can request refresh token from Tx Token service by passing original valid token it receives. It requests this token before going into long pause. It receives refresh token which it will use when it resumes. Refresh token will have longer TTL. Tx Token can configure TTL per use case and/or per caller (e.g. C). Tx token service will include claims in the input valid token in the refresh token but the refresh token cannot be used to access data from any service. Services should ignore refresh tokens in case someone (C) tries to use it directly. C has to make an exchange and pass refresh token to TxToken issuer service to get new token to pass to D.
Interesting proposition.
Thanks. I think we can generalize it a bit and share some guidance for batch proposes. Important thing is to think through all security threats.
Just to make sure I understand... the "refresh token" (I'm going to call it the "batch token") is ONLY valid at the Transaction Token Service (potentially encrypted such that ONLY the Transaction Token Service can decrypt it). The "batch token" contains the context from the A/B transaction token with the longer TTL. I think this "batch token" should also be sender constrained in some way. Is this along the lines you were thinking?
@ashayraut Please post the description of this issue on the IETF OAuth mailing list, and point people to this issue to add their comments here. This together with Issue #110 should be addressed in a single pull request.