The OAuth Token Security Question Every Team Should Be Asking

TL;DR

• Encryption at rest protects your database. It does not protect tokens that have been decrypted and loaded into runtime memory or caches, which is where attackers actually go.
• The real security question isn't "do you encrypt at rest?" It's: what is your architecture for the runtime layer, and what's the blast radius if it's compromised?
• Scalekit uses a dedicated Data Encryption Key per customer environment, with the master key in GCP KMS, architecturally separated from both the database and the application layer. A database breach yields encrypted blobs with no path to decryption.
• Management API credentials are stored as one-way hashes. Shown once, then gone. Not recoverable even by Scalekit.
• Key rotation is a live operation, not a maintenance event. It's one of the most important incident response tools you have, and most teams don't have it.
• If a vendor answers "do you encrypt at rest?" and stops there, that's the answer.

OAuth and token security breaches have become almost routine news over the last few months, we've been following them closely, writing about them, sharing our take on what went wrong each time. But this week hit closer to home. Composio, a well-known player in the same space we operate in, had a security incident. It prompted a lot of real conversations. Customers and prospects reached out with questions they hadn't asked before, or hadn't asked this seriously.

But they're worth answering in detail and in public, because I don't think the industry has been honest enough about what token security actually requires.

The "encryption at rest" problem

Every auth vendor says they encrypt at rest. It's in every security page, every compliance doc, every SOC 2 summary. And it's true and also, by itself, not enough.

Here's what rarely gets explained: encryption at rest protects data in your primary store. It does not protect tokens that have been decrypted and loaded into runtime, application memory, caches, execution sandboxes. And here's the uncomfortable part: tokens have to be decrypted to be useful. When a user connects their Google or Salesforce account, that OAuth token needs to be readable by the system. It gets loaded into runtime. That's not a design flaw, that's how tokens work.

What this means is that an attacker doesn't need to break your encrypted database. They need to reach the layer where tokens are already live. And in most architectures, that layer is far more accessible than the database itself.

This is the gap the industry consistently undersells. Encryption at rest is table stakes. The actual security question is: what is your architecture for the runtime layer?

What good token storage architecture actually looks like

When I was at Freshworks managing auth infrastructure across a suite of products used by tens of thousands of businesses, the thing that kept me up at night wasn't database breaches. It was the blast radius question. If any single layer of the stack was compromised, how far could an attacker get, and whose data would they touch?

That thinking directly shaped how we built Scalekit's token vault.

Every OAuth token and API key is encrypted with a dedicated Data Encryption Key. One DEK per customer environment. Not one shared encryption key across all tenants. The master key that protects each DEK lives in GCP KMS, architecturally separated from both the database and the application layer.

The practical consequences of this are significant:

• A database breach yields nothing actionable. An attacker who exfiltrates the database gets encrypted blobs they cannot decrypt without the DEK. The DEK is only accessible through GCP KMS. I repeat. Not from the database itself.
• Tenant isolation is structural, not just policy. Every read and write is scoped by environment ID at the query layer. A compromise of one tenant's context cannot reach another's. This matters because in a shared-infrastructure world, policy-level isolation is only as strong as the weakest misconfiguration.
• The only path to decrypted tokens runs through the application layer, behind a VPC, MFA-enforced GCP IAM, and SSH-protected access. There is no path from the database directly to plaintext tokens.
• Key rotation is a live operation, not a maintenance event. Signing keys rotate via JWKS with overlap TTL. DEK rotation re-encrypts all values in a zero-downtime background migration. This matters more than most teams realize. This is the ability to rotate credentials instantly, without downtime. It is one of the most important incident response tools you have.

The credential you use to manage all of this

There's a second attack surface that gets even less attention: the management API credentials themselves, the keys your team uses to administer the auth platform.

At Scalekit, when you create a client secret to access our management APIs, we store only a one-way hash of that value. Not the raw secret or a reversible encrypted form. A hash. It's shown once at creation and then it's gone! It is not archived or recoverable. Not even by us! A database breach on our end yields nothing usable for your Scalekit credentials.

This should be standard practice. It sadly, isn't.

The incident response question no one asks until they need to

Here's a question worth asking any vendor before something goes wrong: if you had a confirmed breach affecting my data, how quickly would I know, and what would you tell me?

Vague answers to this question are a signal. "We take security seriously" is not an answer. Neither is a link to a status page.

At Scalekit we've committed to 24-hour breach notification with a clear scope of what was and wasn't accessed. Post-incident reports for P0/P1 events are available on request. Our status page runs live through any incident. These aren't marketing claims. They're commitments we've put in writing because I've been on the other side of this, waiting for answers that took too long to come.

What I'd tell any team re-evaluating right now

The Composio incident will not be the last one. OAuth tokens are increasingly the most valuable credential in modern SaaS stacks. They're the keys to your customers' data, their workflows, their connected tools. The infrastructure handling them deserves the same architectural scrutiny you'd apply to your own production systems.

The question to ask any auth vendor — including us — isn't "do you encrypt at rest?" It's: what happens after the token is decrypted? Who can reach it, through what path, and what's the blast radius if something goes wrong?

Push for a specific, architectural answer. If you get a compliance checklist instead, that tells you something.

If your team is reconsidering its stack after this week, we've put together a migration guide for teams moving from Composio to Scalekit. And if you want to talk through your specific architecture, I'm reachable directly.

Wondering how the architectures stack up? Composio vs. Scalekit — a direct comparison.

Scalekit is SOC 2 Type II and ISO 27001 certified, GDPR compliant. Trust center and full security reference: trustcenter.scalekit.com