Why Sign in with Apple beats API keys for MCP connectors

You paste an API key into your AI client's config so it can send you a push notification when a job finishes. That key now lives in a plaintext file, it syncs across your devices, and it's one screenshot away from someone else's terminal. Worse, it works forever, for anyone who has it. That's the exact problem MCP authentication was supposed to fix, and most connectors still don't.

MCP (the Model Context Protocol) is how AI clients like Claude and Cursor talk to outside tools. A notification connector is one of the most useful ones you can add: your agent runs for forty minutes, then pings your phone the second it's done. But wiring a tool into an AI client means handing that client whatever credential the tool needs. How that credential works is the whole security story.

The default: a long-lived key in a config file

Most APIs authenticate with a static key. You generate it once, drop it in a header, and every request carries it:

curl -X POST https://thenotification.app/api/sendNotification \
  -H "app_key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title": "Build done", "body": "All green"}'

For a script you control, that's fine. The full request is in the API reference. The trouble starts when the key stops living in your script and starts living inside an AI client's config.

Now that static key gets written to disk in plaintext, often synced to the cloud with the rest of your settings, sometimes echoed into logs, and copied by hand at least once, which means it's passed through your clipboard and probably a screenshot. It doesn't expire. If it leaks, you find out when your quota drains or something sends in your name. And rotating it means hunting down every place you ever pasted it.

What Sign in with Apple actually changes

TheNotificationApp's MCP connector skips the key entirely. You add the server by URL and sign in with your Apple ID instead:

{
  "mcpServers": {
    "thenotification": {
      "url": "https://thenotification.app/api/mcp"
    }
  }
}

Notice what's missing: there's no secret in that file. When you connect, you're bounced to Apple's login screen, you approve, and the server hands back a short-lived token scoped to your account, not a permanent key you're on the hook for storing. The AI client ends up holding a token that ages out, not a master credential that lives forever.

Three things fall out of that:

• Nothing sensitive sits in your config. The file you sync across machines and might paste into a bug report holds a URL, not a secret.
• Tokens expire. A leaked short-lived token is a far smaller problem than a leaked forever-key. It dies on its own soon enough.
• Revocation is one tap. Pull access from your Apple ID settings and the connector stops working. No hunting through configs, no rotating a key everywhere you pasted it.

Want the step-by-step for wiring it into Claude? The Claude MCP setup guide walks through it: about a five-minute job, OAuth fields left blank on purpose.

What happens when it leaks

Security is easiest to judge by the worst case. Say the credential gets out: a screenshot, a synced backup, a log you forgot was verbose.

• Leaked API key: it keeps working until you notice and rotate it. Whoever holds it can drain your notification quota or send as you, and there's no expiry doing you any favors in the meantime.
• Leaked Apple token: it's already scoped to just sending notifications, and it ages out on its own. Revoke access from your Apple ID and even a still-live token is dead immediately.

For a connector living inside an AI client you don't fully control (one that reads your config, logs its actions, and syncs across devices), that difference is the whole point.

When you still want an API key (the honest part)

Sign in with Apple isn't the answer to everything. Two cases where the plain app_key is still the right call:

Headless stuff. A cron job, a CI runner, a box with no human at the keyboard can't tap through an Apple login screen. Interactive OAuth needs a person; automated pipelines need a static credential. Keep the key for those, just keep it in an environment variable, not hard-coded in the repo.

The Apple dependency. Sign in with Apple means you need an Apple ID. Since these notifications land on your iPhone anyway, that's not much of a stretch here, but it's a real dependency, not a free lunch, and worth naming.

Fair warning on volume while you're testing: the free tier caps at 100 notifications total, not per month. That's plenty to wire up a connector and run it day to day, but if your agent is chatty, check the pricing page: Pro is $2.99/month for 1,000 notifications a month.

The short version

An API key is a house key you photocopy and mail to every tool that asks. Sign in with Apple is a visitor badge that expires and can be cancelled from the front desk. For an MCP connector (code running semi-autonomously with access to your config), the badge wins every time. Worth a look if you're tired of babysitting secrets: thenotification.app.

New to this? Start with what an MCP server is.