Comment by d4mi3n
2 days ago
Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device.
In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.
This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.
This is an implementation detail in my opinion. There are cases where having the capability to force a refresh is desired. There are also cases where you want to be able to lock out a specific session/user/device. YMMV, do what makes sense for your business/context/threat model.
It is, but its an architectural decision that forces expiry by default. So you should probably even have both. AWS runs 12 hour session tokens, but you can still revoke those to address a compromise in that 12 hour gap. The nice thing that forced expiry does is you just get token revocation For Free by virtue of not allowing renewal
This is really just an optimization. It means that you don't need to do an expiry check on the regular token, only on the refresh token. It doesn't change the fact that you should be able to revoke a session before it naturally expires.
Having a short session expiry is a workaround for not being able to revoke a token in real time. This is really the fault of stateless auth protocols (like OAuth) which do offline authentication by design. This allows authentication to scale in federated identity contexts.
3 replies →
Yeah but depending on how you set it up, you could have a very short expiry. If your auth system is as simple as: Verify refresh token -> Check a fast datastore to see if revoked -> Generate new auth token, this is very easy to scale and and you could have millions of users refreshing with high regularity (<10s) at low cost, without impacting on your actual services (who can verify the auth token offline).
Say you had 1,000,000 users, and they checked every ten seconds, that's 100,000 requests per-second. If you have 1,000,000 users and can't afford to run a redis/api that can handle an O(1) lookup with decode/sign that can handle that level of traffic, you have operational issues ;)
It's all a tradeoff. Yes, it means some user may have a valid token for ten more seconds than they should, but this should be factored into how you manage risk and trust in your org.
You only have to do that if you must validate a token, without having access to session data.
I doubt most systems are like that, you can just use what you call "your actual token" and check if the session is still valid. Adding a second token is rarely needed unless you have disconnected systems that can't see session data.
Not having to start all my API handlers with a call to the DB to check token validity significantly improves speed for endpoints that don't need the SQL db for anything else, and reduces the load on my SQL db at the same time.
2 replies →
[dead]
That's a great way to interfere with local work when the network goes down.
If you've built a local app that has to authenticate you against a remote web service even when offline, and all the actual work is being done locally, you have much bigger design issues than authn IMHO
Access tokens are used for network calls so if the network is down nothing works anyway ?
2 replies →
I was somewhat pondering along these lines.
At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for services needing the VPN. And users don't notice much of this during normal operation.
You say users don’t notice much of this - I disagree. I had to authenticate with our SSO provider 9 times yesterday (I started counting because it’s getting so frustrating). All on the same device; once on initial login, once on VPN connect, once to the SSO dashboard, twice (!) to Microsoft for Outlook and Azure access via our IDP, once for perforce (no 2FA required thankfully) and three times to Jenkins because it doesn’t remember the OIDC token if you close your browser. IT say it’s normal and here I am spending 10 minutes a day waiting for my Authenticator app to log in.
I work on a corporate controlled machine, with a corporate VPN app and custom certificates installed. I’m pretty sure it knows when I sneeze, but yet remembering who I am for more than 15 minutes seems out of scope.
That sounds like a horrible setup though and is a good way to MFA fatigue and other security issues.
In our case - I counted this morning too - I have 2 MFA authentications (VPN and the IDP used by Keycloak) until I have my Keycloak session. This session has an idle timeout of I think 2 hours, so if I don't do anything for 2 hours I'd have to re-auth. And it has a max session length of 10 or 11 hours so it lasts even for long workdays. This has been setup so users generally have to login via MFA once a day in the morning. Since we're using the same authentication and setup, we know this works.
Further token refreshes and logins then bounce off of that session. So our Jenkins just bounces us over to Keycloak, we have a session there, it redirects us right back. Other systems similarly drop you to the Keycloak on first call of the day and Keycloak just sends you back. It's very nice and seamless and dare I say, comfortable to use.
It is however supposed to be easy and we spent some time getting it working this well.. because now people just integrate with the central auth because it's quick and easy and we have full control and tracking of all access :)
You don't need reauthenticate for that, you just need to renew existing tokens. Separate the timeouts for authentication and authorization.
Frequent reauth only makes people figure out hacks to work around it.
Passwords get written down, passwords end up in Google Docs, Arduinos with servos get attached to Yubikeys, SMS gets forwarded to e-mail, TOTP codes get sent over Wechat, the whole works
> SMS gets forwarded to email
This hop is actually more secure than receiving an SMS natively. Your mobile network provider can already read all of your SMS and there are tons of exploits for modifying the receiver of SMS in the wild. SMS is a terrible way to send information securely.
Because much of what passes as "security" is a bunch of theater.
> SMS gets forwarded to e-mail, TOTP codes get sent over Wechat,
Here we are deep into 2FA land. Where you have institutions blocking SMS/MMS to IP telephony because they want to capture real people (and this locks out rural customers). Using your cell phone was never a suitable 2nd factor and now it is evolving into a check to make sure you're not a robot/script.
Passkeys are adding another layer to this... The police department getting a court order and forcing you to unlock your phone and then everything else is coming. Or here if you live in some place with fewer laws.
Whether or not you can be compelled to unlock your phone doesn't really have anything to do with passkeys. If you can be compelled to unlock your phone, then whatever you have on your phone (including the stuff in your password manager/credential manager) is potentially up for grabs. In this threat modeling scenario there's nothing unique about a passkey vs. a password.
And if you're against using credential managers at all, because you only want to have the password stored in your brain and nowhere else.... then that creates different problems, namely it dramatically increases the odds that you will use the same password across multiple services, which is bad because then attackers can steal your password from one service and use it to login to a bunch of other services.
> The police department getting a court order and forcing you to unlock your phone
If you live under a tyrannical regime, neither passkeys nor passwords will help you. The police state will find a way to do what they want with you.
It's a balancing act. The more annoying your auth requirements are, the more likely users are to look for insecure shortcuts that make using their computer less miserable.