Short answer: use OAuth 2.1 when a human connects Claude to Odoo for their own work, and use an API key when you’re wiring up a fixed, headless agent that runs without a person in the loop. Both are legitimate. They solve different problems, and Cledoo MCP supports both out of the box. The rest of this article explains how each one actually works, so you can pick with your eyes open.
What’s the difference, in one paragraph?
An Odoo API key is a long-lived credential tied to one Odoo user, generated in that user’s Account Security settings and used in place of a password. An OAuth 2.1 connection is a login-and-consent flow: the person pastes your Odoo’s MCP URL into claude.ai, gets redirected to a branded Odoo login screen, authenticates, and approves the specific connection — no secret ever changes hands. Both end with Claude holding a bearer token that lets it call Odoo as that Odoo user, under that user’s normal access rights. The difference is in how the credential is created, who holds it, and how you get rid of it later.
How an Odoo API key actually works
Odoo’s own external API documentation describes the mechanism plainly: go to your Preferences → Account Security tab, click New API Key, give it a description and a duration, and Odoo generates the key once — it “cannot be retrieved or shown again later.” From then on, “the way to use API keys in your scripts is to simply replace your password by the key, while the login remains in use.” For security, Odoo caps key lifetime: keys can’t be created to last more than three months, so long-lived integrations must be rotated periodically.
For AI access, that means: you generate a key on a specific Odoo user (often a dedicated service account, sometimes a real person’s login), paste it into Cledoo MCP’s connection settings, and Claude authenticates as that user from then on. Simple. One field to fill in. No redirect, no browser consent screen.
The trade-off is what you’d expect from any shared secret: the key is a string of text that can be copied, pasted into the wrong Slack channel, committed to a repo, or left in a config file after someone leaves. Revoking it means going back into that user’s Odoo profile and deleting the key — which works, but there’s no built-in inventory of “which AI tools currently hold a valid key for this user” unless you build one.
How Cledoo’s OAuth 2.1 flow actually works
The Model Context Protocol’s own specification defines how AI clients should authenticate to MCP servers, and it’s explicit: MCP servers on HTTP transports “SHOULD conform to this specification,” and authorization servers “MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients.” The spec also requires PKCE (Proof Key for Code Exchange) on every flow, because most MCP clients — including claude.ai — are public clients that can’t hold a confidential secret.
OAuth 2.1 itself, per the IETF draft, consolidates OAuth 2.0 (RFC 6749) and its security best practices into one framework: no more implicit grant, no more password grant, and refresh tokens for public clients must be sender-constrained or single-use. It’s a stricter, safer baseline than “classic” OAuth 2.0.
Cledoo MCP implements this natively inside your Odoo. Concretely: the user
pastes your https://<your-instance>/mcp URL into claude.ai, Odoo shows a
branded consent screen (“Claude wants to access your Odoo — Approve /
Decline”), the user logs in with their normal Odoo credentials, approves, and
claude.ai receives a scoped, revocable token — never the user’s password, never
a key they have to copy anywhere. Each approved connection then shows up as a
named entry under the user’s Odoo settings, and can be revoked from there at
any time, instantly, without touching the user’s login credentials at all.
The trade-offs that actually matter
Revocability. With OAuth, killing one AI agent’s access is a single click against a listed connection — the user’s password and other tokens are untouched. With an API key, revoking access means deleting the key, and if the same key was pasted into three different tools, all three break at once (which is sometimes what you want, sometimes not).
Key sprawl. An API key is a piece of text. It travels wherever you paste
it — a .env file, a message, a screenshot. OAuth tokens are negotiated
per-connection and per-client; there’s no string for a person to mishandle in
the first place.
Identity and audit. Both approaches ultimately run Claude’s actions as one Odoo user, so Odoo’s ACLs, record rules, and field-level rights apply either way — that part doesn’t change. Where they differ is how that identity was established. OAuth ties the grant to a live login-and-consent event you can point to; an API key’s origin is whatever your team remembers about who generated it and when.
Setup friction. API keys win here. Generate one, paste it, done — no redirect, no login screen, useful when you’re scripting something quickly or the “user” isn’t a person at all.
Fit for service accounts. A headless agent — a scheduled job, a backend integration with no human at the keyboard to click “approve” — can’t complete an interactive OAuth consent screen. That’s exactly the case an API key is built for.
Use API keys when…
- The connection isn’t tied to one specific person — it’s a service or automation account.
- Nobody is available to click through a login/consent screen (scheduled jobs, server-to-server calls).
- You need something running in the next two minutes and will manage rotation yourself.
Use OAuth 2.1 when…
- A real person is connecting their own claude.ai to their own Odoo access.
- You want every connected agent listed, named, and revocable individually.
- You’d rather no one ever has to copy a secret out of Odoo in the first place.
They’re not mutually exclusive
Most Cledoo MCP deployments end up using both: OAuth for the people on the team who talk to Claude about their own sales pipeline or their own tasks, and one API key for a single automated integration that runs unattended. Classic Cledoo MCP (free, On-Prem/Odoo.sh) ships with both mechanisms available from day one — the choice is per-connection, not a one-time architectural decision for the whole instance. If you later need to scope what an OAuth-connected agent can do beyond plain Odoo ACLs — read-only on financials, no delete anywhere — that’s what Cledoo MCP Pro’s governance layer adds on top, but the authentication mechanics described here stay the same either way.