OAuth 2.1 with Dynamic Client Registration, explained without the PhD

If you have ever clicked "Sign in with Google" or approved an app's access to your calendar, you have used OAuth. The screen that says "This app wants to read your data. Allow?" is OAuth doing its job: the app gets a limited token, and it never sees your password.

The Model Context Protocol (MCP), which clariBI uses to connect to apps like Stripe, Linear and Notion, builds its authorization on OAuth 2.1 and a piece called Dynamic Client Registration (DCR). This post explains both, then walks through what actually happens when you click Connect in clariBI, and when an AI assistant connects to clariBI.

The old way: the developer console

Before DCR, connecting a tool to a vendor's API meant registering an "app" by hand:

1. Log in to the vendor's developer console.
2. Create a new app and name it.
3. Enter a redirect URL you had to look up somewhere.
4. Copy a client ID and a client secret.
5. Paste both into the other tool.
6. Pick scopes, and usually get one wrong on the first try.

It works, but most people who are not developers stop at step 1. It also scatters long-lived client secrets across settings pages and chat messages.

Dynamic Client Registration

DCR (defined in RFC 7591) lets an application register itself with a vendor's authorization server through an API call, with no human in a console. The flow has two preparatory steps:

1. Discovery. The client fetches the vendor's authorization server metadata from a well-known address (/.well-known/oauth-authorization-server, RFC 8414). If the MCP server and the authorization server are separate, the MCP server first points to the right one through /.well-known/oauth-protected-resource (RFC 9728). The metadata lists the authorization, token and registration endpoints.
2. Registration. The client posts its name, its redirect URL and the grant types it needs to the registration endpoint, and gets back a client ID (and, for some servers, a secret).

After that, the normal OAuth authorization code flow runs.

What happens when you connect Stripe in clariBI

Here is the sequence for a vendor that supports DCR, such as Stripe:

1. clariBI discovers the vendor's endpoints from its well-known metadata.
2. clariBI registers itself, once per vendor. The registration is cached and reused for every organization that connects the same vendor, so the vendor sees one clariBI client, not thousands.
3. clariBI creates a PKCE pair. It keeps a random secret (the code verifier) and sends only its SHA-256 hash (the code challenge) with the authorization request.
4. Your browser opens the vendor's consent screen. You sign in to Stripe, not to clariBI, and approve the requested access.
5. The vendor redirects back to clariBI with a one-time code.
6. clariBI exchanges the code for tokens, sending the original code verifier. Someone who intercepted the code alone cannot use it, because they do not have the verifier.
7. clariBI encrypts the tokens with Fernet (AES-128 in CBC mode with an HMAC-SHA256 signature) before storing them. The key is kept in the server's configuration, not in the database, so a copy of the database alone does not reveal the tokens.

From your side, that is: click Connect, approve on the vendor's page, done. clariBI then uses the token only to call the vendor's read tools: each vendor has a read-only allowlist, and any discovered tool whose name suggests it creates, changes, deletes or refunds something is filtered out before a call is made.

Vendors that do not support DCR yet

Not every vendor publishes a registration endpoint. Of the 86 active MCP apps in clariBI's catalog, most use DCR, some use an API key or need no sign-in at all, and a handful still need the developer-console route. HubSpot is one of them at the time of writing: you create an app in HubSpot's developer settings and paste its client ID and secret into clariBI. PKCE is still used in that flow. The MCP integrations docs describe each of these connection methods.

OAuth 2.1 compared with OAuth 2.0

OAuth 2.1 is not a new protocol. It is a consolidation of OAuth 2.0 and a decade of security advice into one document, still being finalized at the IETF. The changes that matter:

• PKCE is required for every client using the authorization code flow, not just mobile apps.
• The implicit flow is gone. Tokens are no longer returned in the browser URL.
• The password grant is gone. Apps never collect your vendor password.
• Redirect URLs must match exactly. No prefix or wildcard matching, which closes a family of token-theft tricks.
• Refresh tokens for public clients must be protected, typically by rotating them: each refresh returns a new refresh token and invalidates the old one.

The MCP authorization spec builds on this, which is why most hosted MCP servers support PKCE and DCR.

The other direction: AI assistants connecting to clariBI

clariBI also runs its own MCP server, so an assistant such as Claude, Cursor or ChatGPT can list your dashboards, run an analysis or generate a report. Here clariBI is the authorization server, and the same rules apply:

• Open registration, forced consent. Any MCP client can register at /mcp/v1/oauth/register, but no token is issued until a signed-in clariBI user approves the consent screen. Registration is rate-limited per IP address.
• PKCE is mandatory for public clients, with SHA-256 challenges only.
• Exact redirect URL matching.
• Short lifetimes. Authorization codes are single-use and expire after 60 seconds. Access tokens last one hour. Refresh tokens last 30 days and rotate: each use revokes the old one.
• Hashed storage. clariBI stores tokens as SHA-256 hashes, so its own database cannot hand out working tokens.
• Scopes. Read scopes (dashboards, reports, data sources, usage, billing status) are separate from write scopes (generate reports, upload data, run analyses that use credits).
• Revocation. You can see connected clients and revoke them from clariBI's developer settings, and clients can revoke tokens through the standard revocation endpoint (RFC 7009).

The MCP server is available on the Trial, Starter, Professional and Enterprise plans. Clients that cannot do OAuth can use a claribi_mcp_ API key instead, which clariBI exchanges for a short-lived token that expires after 15 minutes. The MCP authentication docs and the help article on JWT tokens, API keys and MCP keys cover both options.

What disconnecting does

When you disconnect an MCP app in clariBI, the stored access and refresh tokens are wiped immediately, the app's data sources are marked disconnected, and the connection record is deleted after 30 days. You can also revoke clariBI's access from the vendor's own settings; that invalidates the token on their side.

The short version

You do not need to remember any of this to use it. Click Connect, approve on the vendor's page, and ask your question. The protocol is what makes that safe: no passwords shared, no secrets pasted, short-lived codes bound to a verifier, and tokens encrypted at rest. For the reasoning behind choosing MCP in the first place, read why we bet on MCP, and for the full set of controls, the security model behind clariBI's MCP integrations.