-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long-living Access Token needed for internal batch processes/offline tasks? #62
Comments
So a couple of thoughts here:
|
The use cases you mention are pretty much what we had to implement.
So my argument is against using (and potentially abusing) long-living access tokens, and instead for allowing expired Txn-Tokens to be presented to the TTS to re-issue Txn-Tokens for the purpose of finalizing a delayed operation. |
I do not think we should allow the use of expired TraTs to authorize the issuance of new TraTs. This can be abused for token replay attacks, and negates the security we get through short-lived TraTs. |
@tulshi Good point. In order to get a new TraTs, the caller needs proper client authentication (e.g. SPIFFE, mTLS, or Basic Auth credentials). My point was to only allow specific authenticated clients the exchange of expired TraTs. It is true that if those clients get hacked themselves (and the client authentication can be done by an attacker) new TraTs can be created and abused. However, longer living TraTs have also the risk of being abused with replay attacks. I think the risk for replay attacks with longer living TraTs is even higher as an attacker would just need to get hold of the long-living TraTs and does not have the need to renew it. |
Using an expired Txn-Token has some interesting properties. Assuming the I would probably recommend creating very specific In my mind, using an expired Txn-Token is a bit like requesting a replacement Txn-Token except the processing rules are even more strict. |
Indeed, the spec does not say anything about whether and how the TTS is validating the txn token before issuing a replacement txn-token. So presenting an already expired txn-token can be accepted based on the authenticated client, purpose and scope. After all, it can be a specifically defined policy. I recommend that we at least acknowledge this case in the spec and give guidance when to use it. As we also have the case of not presenting any token when requesting a txn-token (see #53), I think that as long as a workload is in possession of a txn-token - even if it is expired - we should recommend to present it when requesting replacement txn-tokens. It should be the decision of the TTS whether to accept the expired txn-token and not of the workload (the workload could just take the subject from the expired token and present it as the subject_token to the TTS). One additional aspect came to our attention. There are actually two cases for expired txn-tokens:
Depending on how frequently a TTS is rotating its key material, the second case might occur for such long running processes like deleting account data several weeks after the customer has cancelled their contract. For instance our TTS implementation is rotating the keys daily. Only the next, current and previous signing keys are provided to workloads (via JWKS uri). Even if a workload is not able to verify the signature of a txn-token it received several weeks ago, the TTS might still be able to keep the old key material for a longer period so that it can at least validate the signature of those txn-tokens. |
The current spec states:
"Even for long-running "batch" jobs, a longer lived access token should be used to initiate the request to the batch endpoint. It then obtains short-lived Txn-Tokens that may be used to authorize the call to downstream services in the call-chain."
I assume the reasoning behind this is that there would be no need to define a Txn-Token Request without an original Access Token. However, I think that creating long-living Access Tokens just for the purpose of exchanging them for short-lived Txn-Tokens and then throwing them away can be considered wasteful (energy costs). Every internally originating job would need at least two calls instead of just one to obtain the Txn-Token.
Keeping those long-living Access Tokens around to re-use them for longer time is usually not useful for batch processes as those processes operate on a lot of user accounts in quick succession. Maintaining all those Access Tokens in memory is often not feasible. Neither is a storage system. I also think that using long-living Access Tokens in this scenario can add security risks. Those Access Tokens could leak and another party could use them to create Txn-Tokens or access resources the Access Token was meant for.
In our own implementation of a Txn-Service, the Txn-Service (Token Exchange) is also providing the Token endpoint and allows specific internal clients to use the Client Credentials Grant Type (mTLS client certificates) to obtain Txn-Tokens right away. The necessary input parameters are essentially a combination of the Token Request based on Client Credentials Grant and Token Exchange with a Txn-Token profile.
Is it possible to extend the Txn-Token Service interface to allow Txn-Token Requests without the Access Token as input? This would essentially mean to define a Txn-Token profile for the Token endpoint in addition to the Token Exchange protocol.
The text was updated successfully, but these errors were encountered: