So you're worried that a very short lived compromise of a SSI / federated auth layer can lead to long-lived compromises of everything it grants access to because a short time can be used to generate long-lived auth to third parties?
That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc.
Hopefully as the ecosystem matures it'll be easier to en-masse mark an account as compromised and have that status propagate and trigger resets of affected credentials.
A similar threat is insider threat, (probably actually a greater threat) where someone leaving a company could generate tokens which grant them access for long after they've gone.
If reason about how that's typically managed (disabling their upstream accounts) that gives insight into how to deal with your initial concern, it should be managed in the same way.
No, I'm worried that if someone has temporary access to a machine that has one of these long-lived tokens, they may continue to have access to anything that that long-lived token grants access to.
I control my laptops. I control the policy for my identity provider. The service that hosts my source code is a third party, and defines their own policy which may not match mine.
That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc.
Hopefully as the ecosystem matures it'll be easier to en-masse mark an account as compromised and have that status propagate and trigger resets of affected credentials.
A similar threat is insider threat, (probably actually a greater threat) where someone leaving a company could generate tokens which grant them access for long after they've gone.
If reason about how that's typically managed (disabling their upstream accounts) that gives insight into how to deal with your initial concern, it should be managed in the same way.