Jul 2, 2026, 6:26 AMGood morning Europe I have written about the bewildering array of mechanisms available to prevent authentication token theft and also explained why we still basically have none of them available and so the authentication tokens are still being stolen and used. It is here: https://www.codon.org.uk/~mjg59/blog/p/preventing-token-theft/
@mjg59 for the TLS session resumption, do you know if this can easily be activated per user ? To have something like "my token might be stolen, I want to avoid that risk" without impacting other users of the website ? Also, do you know if quick has any impact on that ?
Jul 2, 2026, 7:47 AM@claudex Theoretically sure, but in practice the TLS layer typically knows nothing about the user so you'd need some additional plumbing
Jul 2, 2026, 7:37 AM@mjg59 ooh nice write up, thanks.
Those are all (by design) browser session based. Do you know of anything that would be appropriate to use in a cli i am responsible for? The workflow is often a short burst of requests (3-10?) then nothing for hours or days.
On-device malware is what I’m trying to defend against, and the current approach i am going for is to store our beater token in the system keychain, which at least on macos means malware testing to access it would show a the user a password prompt. But we know that is imperfect protection.
Jul 2, 2026, 7:46 AM@ash RFC8705 is ideal if whoever issues your token supports it, and then make use of a certificate that's associated with a key in the SE
Jul 2, 2026, 7:48 AM@mjg59 👍🏻we issue ourselves (auth0 for user login, but it was prohibitively expensive to use auth0 for everything)
Of course it remains to be seen how easy it will be to plumb mTLS though the entire stack
@mjg59 Thanks for the blogpost, it was an interesting read. The DBSC dance reminded me of Auth0's custom `urn:okta:params:oauth:grant-type:webauthn` flow, which tries to glue together a webauthn/passkey challenge-response exchange and the usual OIDC machinery.
@mjg59 I imagine some of the pushback on TLS based solutions is that it is that getting it to work if you've e.g. decided to let Cloudflare MITM your connections or use some other service to terminate the TLS connections. If that frontend doesn't support the feature or doesn't pass through the relevant info, you're screwed.
I also wonder if the difficulties with OAuth 1.0 tilted people towards simple bearer tokens. I remember having a lot of difficulty with Apache normalising requests in ways that would break signatures by the time the application saw the request. It was bad enough to just recomend people use PLAINTEXT mode. That feels like it directly leads to OAuth 2.0 only defining bearer tokens at launch.
Jul 2, 2026, 10:41 PM@mjg59 surely high risk targets like GHA and AWS have implemented... nevermind
@mjg59 My favorite idea is a variant of chrome's device-bound credentials, but also binding the individual cookies to the IP or prefix they were issued to (/64 in the case of v6) such that you must refresh the cookie (thus hitting the asymmetric crypto) when you change networks.
About the only thing that would break that is certain types of CGNAT or NAT64 AFAIK (ones where pool IPs aren't "sticky" for any given client, so a client can get different v4 addresses for every connection)