If you've ever connected a third-party app to your Google account, you've used OAuth. The popup that says "MyApp wants to access your email — Allow?" — that's OAuth doing its job. clariBI's MCP catalog uses a newer variant called OAuth 2.1 with Dynamic Client Registration, and it's worth understanding why we picked it.
The old way: developer consoles
Until MCP, connecting any AI tool to a vendor like Stripe or HubSpot used to require this:
- You log into the vendor's developer console.
- You register a new "app" for your account.
- You copy a client ID and a client secret out of the console.
- You paste those into the AI tool.
- You configure scopes (and probably misconfigure them on the first try).
- You go back to the AI tool and complete the auth flow.
That works, but it's a wall. Most non-developers will bounce off step 1.
The new way: Dynamic Client Registration
OAuth 2.1 added a piece called Dynamic Client Registration (DCR) — basically a way for an app to register itself with the vendor on the fly, without anyone ever opening a developer console.
When you click "Connect HubSpot" in clariBI, here's what actually happens:
- clariBI's backend talks to HubSpot's MCP server.
- It says "I'd like to register as a client" and gets back fresh client credentials.
- clariBI redirects your browser to HubSpot's authorization screen.
- You click "Allow" — granting read-only access.
- HubSpot redirects back to clariBI with a code.
- clariBI exchanges the code for an access token, encrypts it, and stores it.
From your perspective, all you did was click two buttons. No developer console. No client IDs. No copy-paste.
"OAuth 2.1" vs "OAuth 2.0"
OAuth 2.0 has been the workhorse for ten years. OAuth 2.1 is essentially OAuth 2.0 with the parts everyone agreed were footguns removed (the implicit flow, password grants) and the security-critical bits (PKCE, refresh token rotation) made mandatory instead of optional. If you ever worried about token theft via redirect URI confusion, OAuth 2.1 closes that.
What this means for credential storage
Even with DCR, the access token still has to live somewhere. clariBI encrypts every token at rest with Fernet (AES-128-CBC + HMAC-SHA256) before it touches the database. The encryption key lives in our secrets manager — the application doesn't carry it in plaintext. Decryption only happens server-side, at request time, just long enough to make the MCP call.
If you disconnect a vendor, we drop the row. The encrypted token is gone, and even if a backup tape leaks years later, the token without the key is useless.
The TL;DR for non-engineers
You don't need to know any of the above. Click "Connect", click "Allow" on the vendor's screen, get back to asking questions about your data. The protocol is doing the work. See how the catalog works for the full picture.