I've been testing the WellSaid Labs Chrome extension for a potential workflow. The core functionality is decent, but the authentication layer is a persistent problem. The extension forces a logout every 24-48 hours, sometimes more frequently. It's not a browser restart issue; it happens during active sessions.
This is more than an annoyance—it's a security and compliance red flag. It points to poorly implemented token management. Either the refresh token lifecycle is misconfigured or local storage is being incorrectly cleared. Have the developers not heard of persistent sessions? Every forced logout is a workflow interruption and pushes users toward insecure practices like writing down credentials.
What's the official stance on this? I need a reliable session for audit logging. My current assessment is that this instability makes it unsuitable for any environment that takes SOC2 controls like access management seriously. I'm not seeing this behavior with other similar SaaS extensions.
— geo
— geo
This is a vendor cost-cutting measure you're diagnosing.
Short-lived sessions mean smaller auth server capacity. No persistent tokens, no need for a distributed token store or database read capacity. They're running on cheap, stateless infrastructure.
Your SOC2 controls won't be pleased, but the CFO running the service probably is. They get to run a smaller, cheaper cloud footprint. Every forced logout is a penny saved on their monthly AWS DynamoDB bill.
Look for a different vendor. Their product philosophy starts with engineering decisions that save them money, not with user workflow stability.
show me the bill
The cost-cutting angle is plausible, but I'd be careful attributing it directly to DynamoDB savings. A stateless session architecture can be a legitimate design choice for scalability, not just cost. The real issue is the 24-48 hour cadence; that's far too short for a professional tool and suggests they haven't implemented a proper background token refresh.
If this were purely a cost play, they'd likely use a longer-lived, but still non-persistent, token to reduce auth server load. The current implementation feels like an oversight or a stopgap, which is almost worse for long-term reliability.
Have you checked if their main web app has the same behavior? That could confirm if it's a systemic philosophy or just a neglected extension.
Buy once, cry once.
Yeah, the stateless vs. cost-cutting distinction is a good one. I've seen teams adopt stateless auth for horizontal scaling, but then they couple it with a solid refresh mechanism in the client. The complete lack of one here is what screams "unfinished feature" to me.
Your point about checking the main web app is key. If the website uses a proper session cookie that lasts for weeks, then the extension is definitely an afterthought. That pattern happens a lot - the web team builds a full auth flow, and the extension gets a rushed OAuth implementation that nobody revisits.
It shifts the problem from a company-wide philosophy to a specific engineering debt, which somehow feels more frustrating to troubleshoot.
cost first, then scale