OAuth, API Tokens and Pasted Cookies: What Each One Actually Lets a Tool Do

Every tool that touches your ad accounts had to get in somehow, and there are only three doors. The difference between them — OAuth vs tokens and cookies — decides what that tool can reach, what it can do on a bad day, and how quickly you can shut it out. Almost nobody checks which door a tool used before connecting it, and then judges the tool by its dashboard. This article is the boring part underneath: what each form of access actually grants, how you take it back, and why the way software arrives on your machine belongs in the same conversation.

---

The Three Doors

1. OAuth: delegated, scoped, revocable

An OAuth flow has a shape worth recognising, because the shape is the security property.

1. The tool sends you to the platform's own domain to sign in. Your password is typed into the platform, not into the tool.
2. The platform shows you a named list of permissions the tool is asking for — manage ads, read reports, list business assets.
3. You approve, and the platform issues a token to the tool. The token carries those permissions and nothing else.
4. The grant appears in your account under connected apps or business integrations, with a name attached.
5. You can remove it from that screen whenever you want, and the tool loses access on its next call.

Four of those five steps exist for your benefit rather than the tool's. The password never leaves the platform. The permission list is written down. The grant is inventoried. The removal is one screen and does not disturb anything else.

2. A raw API token: a key, and no record of who holds it

Some tools skip the flow and ask you to generate a token yourself, then paste it in. The token can still be scoped — that part depends on how it was minted — but three of the five properties above disappear.

There is no consent screen recording what was asked for. There is usually no entry in the connected-apps list, so six months later nothing in your account tells you that this tool exists. And revocation is no longer a per-tool action: you have to go back to wherever the token was issued and kill it there, which in practice means remembering that you issued it.

A pasted token is not automatically dangerous. It is unaccounted for, which is a different and slower problem. Inventories that depend on memory decay, and the decay is invisible until an audit or an incident forces the question.

3. A pasted session cookie: you, duplicated

This is the one that deserves a hard look, and it is covered in more depth in our piece on Facebook token and cookie security.

A session cookie is what your browser holds after you log in. It is not a delegated permission — it is the logged-in session. Anything holding a copy is indistinguishable from you: same permissions, same reach, for as long as the session stays alive.

That means there is no scope to narrow, because a session has no scope. There is no permissions screen entry, because nothing was granted. And there is no individual revocation, because there is nothing individual to revoke — the only lever is ending the session itself, which signs out every other place you were using it.

The three doors side by side

None of this is a statement about which tools are good. Plenty of capable software asks for a pasted cookie because the platform it automates never shipped a public API. The point is that the three rows behave differently on the worst day, and you should know which row you are in before that day.

---

What a Scope Actually Limits

"Scoped token" gets used as a reassurance, so it is worth being precise about what the reassurance covers.

An advertising scope typically lets the holder read performance data, create and edit campaigns, and enumerate the business assets you approved. It does not let the holder change your password, add a login method, read your private messages, or reach an unrelated product you happen to use with the same account. A token issued for one platform is meaningless on another.

What scope does not do is make the access harmless. A token with campaign-management permissions can spend money, because spending money is what campaign management is. Scope shrinks the blast radius; it does not remove it. The reasonable expectation is "smaller than the account, and removable from one screen", not "nothing can go wrong".

This is also why the permission list on the consent screen is worth two seconds of attention. If a reporting tool asks for asset-management permissions, the mismatch is visible right there, once, and never again afterwards.

---

Revocation Is the Part Everyone Skips

Access hygiene fails at the end, not the beginning. Granting is a deliberate act with a button; ungranting is a chore nobody schedules.

Three habits cover most of it.

Know the path before you need it. For most platforms, connected applications live in security or business settings, listed by name with the date they were approved. Open that screen today, while nothing is wrong, and read it. The list is usually longer than anyone expects, and some entries will belong to tools that were evaluated once and never adopted.

Revoke on the way out, not eventually. When a tool is dropped, a contractor rolls off, or a trial ends, the grant should go the same week. One agency we wrote about built the whole offboarding routine around exactly this and made it a single click, which is the right instinct: if it is a chore, it will not happen.

Remember that a password change is not a revocation. It ends sessions, so it does kill pasted cookies. It generally does not touch OAuth grants or issued tokens, which is deliberate — otherwise every password rotation would break every integration you rely on. Two different mechanisms, two different levers, and confusing them is how "we rotated everything" turns out to have rotated one of the three.

---

Why the Update Channel Belongs in Your Threat Model

Now the part that has nothing to do with advertising and applies to everything you install.

Any component that updates itself has a standing agreement with your machine: run whatever the distribution chain sends next, without asking. That agreement is not a flaw. It is the reason security fixes reach you in hours instead of quarters, and every serious product ships it — browsers, password managers, IDE plugins, the operating system underneath all of them.

The cost is that the trust is granted in advance. So the useful question about any installed component is never "do I trust this vendor" — you already answered that when you installed it — but what can this component reach if an update does something you did not expect?

The answer is always the same shape: exactly what you allowed it to reach, and nothing more.

• An add-on with permission to read and change data on every site can read and change data on every site, including the pages where you are logged in.
• An add-on scoped to one domain is confined to that domain.
• A component that manages high-value, irreversible secrets can reach those secrets, because that is its job.
• A server-to-server integration with no local presence has nothing on your machine to reach, because nothing was installed.

That last line is not a boast, it is a shape. It is also why the practical advice reduces to segmentation rather than brand-picking:

1. Keep irreversible secrets out of shared environments. Recovery phrases, private keys, root credentials and payment instruments do not belong in the same browser profile that runs general-purpose add-ons. Irreversible is the operative word: a stolen session can be ended, a leaked private key cannot be un-leaked.
2. Read the permission prompt the one time it appears. "Read and change all your data on all websites" is a real sentence with a real meaning, and it is shown exactly once.
3. Prefer revocable, scoped access over stored credentials wherever the platform offers the choice.
4. Keep the installed list short. Every add-on is a standing agreement. Ten of them are ten.
5. Assume that any auto-updating component will eventually ship something surprising, and design so that the sentence ends with "and it reaches this much, and no further".

None of these five steps require you to predict which vendor will have a bad quarter. That is the point — predictions are unreliable and segmentation is not.

---

Two Layers, Two Jobs

There is a persistent framing that anti-detect browsers and campaign platforms are competing answers to one question. They are not; they answer different questions, and the stacks that work usually contain both.

Connecting an ad account to a campaign platform does not remove the browser layer from your setup and does not ask you to migrate anything. You open the profile the way you always did, connect the ad account once through the platform's own consent screen, and from then on the launching, the rules and the margin live in one panel instead of six tabs. The longer version of this argument is in Wevion vs anti-detect browsers.

---

Where Wevion Sits, Architecturally

One paragraph, because it is a fact about our construction rather than a verdict on anyone else's.

Wevion connects to ad accounts through OAuth against the official APIs. You authenticate on the platform's own domain, we receive a scoped token, that token is encrypted at rest, and you can remove the grant from the platform's settings at any time without touching your password or any other integration. There is no client-side component of ours on your machine, which means there is no update channel of ours in your threat model. The mechanics are written out in how Wevion connects.

What that does not mean: it is not a promise that an account will never be restricted. Accounts get restricted on official APIs too, for policy and quality reasons that have nothing to do with how a tool authenticated, and anyone who has bought media at volume knows it. Broader account-level habits are collected in Meta ad account safety practices.

---

Conclusion

Three doors, and they are not interchangeable. OAuth gives away a scoped, named, revocable token and keeps your password on the platform. A raw token works but leaves no record of itself, so it survives in your setup long after you have forgotten it exists. A pasted session cookie is not a grant at all — it is your session, duplicated, and the only way to take it back is to end the session for everyone including yourself.

Around all three sits the question of what runs on your machine. Every auto-updating component is a standing agreement, and the way to stay comfortable with that agreement is not vendor prediction but blast-radius arithmetic: grant narrowly, keep irreversible secrets in their own environment, keep the installed list short, and know the revocation path before the morning you need it.

Start a 14-day free trial of Wevion and connect one ad account through the platform's own consent screen. The rest of your stack stays exactly where it is.

Related Reading

• How Wevion Connects: OAuth, Encrypted Tokens, and Why We Never Ask for Your Password
• Facebook Token and Cookie Security: What Every Advertiser Should Know
• Meta Ad Account Safety in 2026: The Practices That Actually Protect You
• Wevion vs Anti-Detect Browsers: Two Layers of the Same Stack