Trust Is a Feature: Verification Lessons From Building the Calendrz Mobile Backend

Trust was everywhere in my LinkedIn feed last week. LinkedIn is testing a feature that lets verified members confirm their connections’ work and school history, with enough confirmations earning a profile badge. Its engineering team also explained how it detects low-quality AI content. And in Europe, the AI Act’s transparency rules had their first real effect: OpenAI said it will add invisible watermarks to text generated in the EU.

Each of those is a different problem, but the theme is the same. “Trust me” isn’t good enough any more. Platforms are being asked to prove things: that a person really worked where they say, that a piece of text really came from where it claims, that an account is really who it says it is.

I’ve spent the last couple of weeks on a less glamorous version of the same problem: preparing the Calendrz backend for native iOS and Android apps. Most of that work wasn’t about features. It was about making sure that the thing calling our API really is who it claims to be, and that the trust stops when it should.

Why mobile apps make trust harder

A web app has an easy setup: a session cookie, on a domain you control, in a browser that enforces a lot of rules for you. A mobile app is a public client. It runs on a device you don’t control, it can’t keep a secret (anything shipped in an app binary can be extracted), and it stays signed in for weeks. If a token leaks, you need to know, and you need to be able to shut it down.

Calendrz holds access to people’s work and personal calendars. That’s sensitive data: who you meet, when, and often why. So the bar here isn’t “good enough for a to-do app”.

What we built: verification at every hop

Here’s a quick tour of the trust-related pieces that landed in the Calendrz backend over the past couple of weeks.

1. Proof of who’s calling: PKCE public clients

The iOS and Android apps are registered as first-party OAuth clients with no secret, because a secret in an app isn’t really secret. They sign in with PKCE instead, which proves that the app finishing the login is the same app that started it. A malicious app that intercepts the redirect can’t do anything with the code it grabbed.

2. Proof that the link is really ours: Universal Links and App Links

When a login finishes, the browser has to hand control back to the app. Custom URL schemes can be claimed by any app, so we serve the Apple and Android “well-known” verification files from our own domain. That’s how the operating system knows a link to calendrz.com really belongs to the Calendrz app. If an environment isn’t configured, the files return a 404, so a misconfigured server can never claim links it shouldn’t.

3. Detecting stolen tokens: refresh-token reuse detection

This is the one I’m proudest of. The mobile apps get short-lived access tokens (60 minutes) and a refresh token that rotates: every time it’s used, it’s replaced. The catch is that a plain rotation setup only knows about the current token. If an attacker copied an older one, the server just sees an unknown token and rejects it, but never notices that something is wrong.

So we now keep a record (a SHA-256 hash, never the token itself) of every refresh token that has been rotated out. If one of those shows up again, that’s the signature of a stolen token chain, as described in the OAuth security best-practice RFC (RFC 9700). Calendrz then revokes the whole authorization, so both the attacker and the legitimate app have to sign in again, while the user’s other sessions are left alone. Refreshes for a given authorization are serialized at the database level, so two refreshes racing each other can’t be mistaken for an attack, and can’t undo a revocation.

4. Trust that ends when it should: revoke on account deletion

When you close your Calendrz account, or unlink one of your connected calendar accounts, every OAuth authorization tied to that identity is now removed. That covers the mobile apps and any AI assistants you’ve connected over MCP. Their refresh tokens die with the account. The revocation runs only after the deletion has committed, so a failure can’t leave you half-deleted.

5. Failing honestly instead of failing quietly

A smaller one, but it’s the same idea. When the new mobile event endpoints can’t load your calendar from Google or Microsoft, they now return an explicit “service unavailable” error instead of an empty list. An empty calendar is a claim (“you’re free all day”), and an app or agent would act on it. If we can’t verify the answer, we say so.

Trust is a feature, even if nobody sees it

LinkedIn’s colleague vouching will show up as a badge on a profile. Most of the work I’ve described won’t show up anywhere. Nobody opens an app and thinks “great refresh-token rotation”. But it follows the same principle: don’t take identity on faith; verify it, and be able to revoke it.

There’s also a lot of AI in this story. Much of this backend work was planned, written and code-reviewed with AI agents, and several of the review rounds caught real issues: a race between two concurrent refreshes, a revocation that could have been rolled back, a log line that leaked more than it should have. As more code gets written this way, having automated checks verify the work before it ships is the engineering version of the trust problem LinkedIn and the EU are trying to solve for content.

The Calendrz mobile apps are still in progress, but most of the trust layer underneath them is already in place. That felt like the right order: build the part people need to rely on before the part they’ll see.

Calendrz keeps your work and personal calendars in sync, privately and securely. Find out more at calendrz.com.

Originally published on liviutudor.com.