[ShroudedNight]

I'm not sure I understand the argument that expirations are inadequate: what's the likelihood of ending up with a token compromise without the client machine also being compromised? Further, if the client machine is compromised, isn't token revocation not much more than a fig leaf? If the machine is working correctly, and the user wants to explicitly terminate a session, why is erasing / forgetting the session secret not adequate?

I feel like I'm missing some critical, but non-obvious threat model here.

[jcrites]

One threat model that people worry about is whether credentials can be lifted from a compromised machine once and then used to have permanent ongoing access -- without requiring ongoing access to the compromised machine.

If you have ongoing access to a compromised machine, then all bets are off. However, one security goal in these kinds of situations is to be able to rapidly "lock down" and quarantine a suspected breach; which in this case means revoking all of the credentials that the machine had access to. You want to be able to do this, and then once you've done this, be confident that the attacker has no further access.

If an attacker can lift a 'refresh token' from the machine, and use it to generate their own unlimited number of new credentials (that can be periodically refreshed indefinitely), then the challenge of revoking compromised credentials is more difficult; by the time you add a compromised token to a refresh list, it may have already been used to create another.

So you can't just say: "What credentials were on the machine? Revoke them all." That's not enough if the attacker can create their own new credentials using the refresh token.

If access tokens can be used to create additional access credentials, then it's more difficult to track and revoke all of them -- you'd need to revoke some kind of 'session' that all of the access tokens can be attributed to.

[brianpan]

They mention lifecycle at the top: logout now, log out specific devices (I forgot to logout of Netflix after I left the AirBnB), log out unknown/old devices. I don't know Biscuit, but this is just normal security design.

Besides normal lifecycle, compromises can happen any number of ways. You won't know them all ahead of time, but having something like revocation designed into your system means you have one more mitigation option when something goes wrong.

Examples: all user-side compromises would be covered by "lifecycle" (give them a way to logout if they accidentally pasted a cookie somewhere, logged in to a public computer, etc). On the application side: discovered a security flaw (CVSS bug in a library or you designed a flaw), discovered suspicious activity in your network, suspect some browser or other exploit is allowing tokens to be stolen. After deploying fixes, you might want to revoke some set of token immediately instead of waiting for them to expire out.

Having revocation as an option might mean that you can make default expirations longer. Maybe we're ok with letting users be logged in for one week instead of 24 hours if we have the option to revoke. Otherwise if a token is compromised, an attacker has a whole week to play with the token.