OAuth on an iPhone for a Health Connector: What "Approve on Your Phone" Does and Does Not Protect
The sign-in screen that asks you to approve a health connector has become table stakes. Tap approve, and a service can read your data. It feels like the whole privacy story. It is one chapter of it, and a narrow one. Here is what that grant actually covers, and the three things it never touches.
AI-assisted, human reviewed. How we use AI
Quick answer
OAuth with an approve-on-your-phone step does two real things: it proves that you, the account holder, granted the access, and it gives you a revocable grant, so the connector can be cut off later. What it does not do is decide where your data goes. It is a consent control, not a custody control. A remote connector still holds a copy on a machine you do not own, because that is how it answers your agent. Revoking the token stops the next read; it does not delete the copy already made. The privacy question is not "did I approve this". It is "where does the data live once it is through the door".
What OAuth is actually for
OAuth is a delegation protocol. It exists so you can let a third party read something on your behalf without handing over your password. The flow issues a scoped token to the connector, the connector presents that token on each request, and you can revoke it. On a phone the flow also uses PKCE, because an app cannot keep a client secret. A secret shipped inside an app is a secret anyone can read from the app bundle. PKCE replaces it with a one-time verifier generated per sign-in, so a stolen authorization code is worthless without it.
All of that is good engineering, and none of it is a lie. The problem is what people hear when they see it. They hear "my data is protected". What the screen proved is narrower: the connector is allowed to read, and you can change your mind. It said nothing about what happens to the data after the read.
The one-sentence version. Approve-on-your-phone answers "who may read this, and can I stop them?" It does not answer "where is it stored, how long is it kept, and who else can open it?" Those are different questions, and only the second set is about custody.
The three things the approve screen never covers
- Where the data lives. A remote connector answers your agent over the network from a machine someone else runs, so the data has to be on that machine. The approve step is what let it get there. Consent to read and custody of the copy are separate facts, and only one of them is on the screen.
- How long the copy is kept. Revoking the token stops future reads. It is not a delete button. If the service stored what it read, that store does not empty itself when you revoke. Retention is a number, and "as long as needed" is not a number.
- What happens when the door closes. Revocation protects you from a connector acting again. It does not survive the operator changing a policy, being acquired, or shutting down. If the account was the data path, the data path ends with the account, and anything held on their side goes with it.
There is a fourth one that catches people: the answer your agent receives travels wherever your agent logs. A connector can be perfectly scoped and still leak through the chat history, the model provider, or a sync folder on the other end. The grant covered the read. It never covered the destination.
What to check before you tap approve
None of this makes remote connectors dishonest. It makes them a deal you should sign knowingly. Five things are answerable in writing before you approve:
- What does the consent screen actually grant? Scopes are not decoration. A connector that asks for everything when it needs sleep and heart rate is telling you how it thinks about least privilege.
- Is the data stored at all, raw or derived? Ask whether they keep the values or only the answer. "We do not store your data" and "we store derived aggregates" are different sentences, and only one is usually true.
- What is the retention number, and what deletes it? A number and a mechanism, not a paragraph.
- Does revocation actually work? Revoke the token, then ask again. If the connector still answers, the grant was not the only path.
- Is there an export and delete path? If you cannot take the copy out or tell them to erase it, you do not hold it. They do.
The test that settles it in a minute
Here is the check nobody runs, and it is the one that tells you the truth. Sign in, do one query, then revoke the token at the provider and ask the same question again. Two outcomes. If the connector now fails, you had a real revocable grant, and you have just proven the door works. If it still answers, the grant was never what was holding your data, and the service kept its own copy. That is exactly the case where the approve screen gave you a feeling of control without the substance of it.
A local connector has no version of this test, because there is no token and no door. Nothing to revoke means nothing was ever handed over. That is not a stronger promise. It is the absence of the question.
Why our whole bridge is on the other side of this
We do not run a remote health server, so there is no OAuth flow to audit, and that is deliberate. The bridge is a local MCP server your own client starts as a child process and talks to over stdio. It reads a file on your machine. There is no URL, no token, no account in the middle, and no copy on a server of ours, because there is no server of ours in the path at all.
That claim is checkable rather than asserted. We scanned the shipped server, version 1.10.2 on 12 November 2026: 22 tools, 20 read-only, 194 metrics, zero dependencies, and no HTTP client anywhere in the read path. The only socket in the repository is an optional inbound LAN receiver, and you have to start it yourself. The server is MIT and on GitHub, so you can clone it and grep for a network call yourself. You will not find one, because there is not one.
Stated exactly, because "private" is a word people overreach with: your health data never reaches us or a cloud AI. The MCP server makes zero network calls, so an export goes only where you point it. The iOS app reports install, trial-start and purchase events to Meta for ad attribution, never health data, and only if you allow tracking when iOS asks. And once you export, the file travels wherever you send it, because a file you own is a file you can move.
So is OAuth bad?
No. Approve-on-your-phone is better than a password pasted into a form, and a revocable grant beats a permanent one. It is just not the whole privacy story, and treating it as the whole story is how people end up choosing remote while believing they chose local. The honest framing: OAuth decides who may read. The architecture decides where the data lives. When you are picking a health connector, the second question is the one that follows you for years, and it is the one almost nobody puts on the sign-in screen.
And a boundary that applies to every shape, local or remote: none of this is a medical device. A connector reads your own data and describes it against your own baseline. It does not detect, treat or monitor a condition, and it should not be asked to.
FAQ
What does OAuth actually protect when I approve a health connector on my phone?
It proves that you, the account holder, granted the access, and it scopes what was granted. It also gives you a revocable grant: revoke the token and the connector stops being able to read new data. It is about consent and control of the door. It does not decide where the data goes once it is through the door.
If I revoke the token, is the data the connector already read deleted?
No. Revoking a token stops future reads. It does not reach back and delete the copy the service already made, because the reason it could answer your agent in the first place is that the data is on its machine. Deletion is a separate action, and you should ask for one in writing.
Why does a mobile health connector need PKCE instead of a client secret?
A phone cannot keep a client secret, because anything shipped in the app can be extracted from it. PKCE replaces the secret with a one-time code verifier generated per sign-in, so a stolen authorization code is useless on its own. Seeing PKCE in the flow tells you the consent step is built for a public client, which is the correct shape for an iPhone.
Does a connector that reads a local file need OAuth at all?
No, because there is no remote service to authorize. A local MCP server over stdio is a process your own client starts, and it reads a folder you point it at. There is no token to issue and none to revoke, because there was never a server of theirs in the data path. The consent step is the folder you choose.
Skip the token. Keep the data path local.
Export all 194 metrics on the iPhone, then let Claude, Cursor or any MCP client read them locally over stdio. No URL, no token, no server of ours to approve or revoke.
Where it goes: the app reads Apple Health read-only and writes JSON to a folder you pick. Your health data never reaches us or a cloud AI; the MCP server makes zero network calls. What you get: all 194 metrics, on-device Ask with a provenance card on every answer, the Weekly Brief, and the Mac and Apple Watch apps. Price: $24.99 one time after a 7-day free trial, not a subscription. Wellness, not medical advice.