Connected Apps are third-party applications you've authorized to use the GitDocAI API on your behalf — MCP clients like Claude or Cursor, custom IDE plugins, or any tool that speaks OAuth 2.1. This page covers the consent flow, where connected apps live in the dashboard, and how to revoke access.
The OAuth model
GitDocAI is a fully-conformant OAuth 2.1 authorization server. Any client that follows the standard can connect — no out-of-band coordination with GitDocAI is required.
The model has three roles you should know:
Dynamic Client Registration
New OAuth clients register themselves by hitting GitDocAI's registration endpoint (RFC 7591). You don't need to pre-create anything in the dashboard — the moment a fresh MCP client tries to connect, it registers, you walk through consent, and it's live.
PKCE on every flow
All authorization flows use Proof Key for Code Exchange (PKCE). This makes the flow safe even for clients that can't keep a static secret — there's no shared password that a leaked token would expose.
Refresh tokens
Once you authorize a client, it can refresh its access tokens indefinitely until you revoke it. Refresh tokens are tracked per OAuth client so revocation is precise — revoking one client doesn't sign others out.
The consent flow
When a third-party client wants access for the first time, you'll go through a one-time consent step:
The client opens a browser window pointing at GitDocAI's authorization endpoint. If you aren't already signed in, you'll be prompted to log in first.
GitDocAI displays the client's name and the scopes it's requesting (read documentations, write entries, etc.). Read carefully — these scopes determine what the client can do once authorized.
On approval, GitDocAI redirects back to the client with an authorization code. The client exchanges it for an access token and a refresh token using PKCE.
From here on, the client uses the refresh token to stay signed in across sessions. You don't need to consent again unless you revoke access.
Authorization is bound to your user account, not to your organization. If you belong to multiple organizations, the client's effective permissions are scoped by your role in each — the same as when you log into the dashboard.
Managing connected apps
Open Account Settings → Connected Apps to see every client you've authorized. For each entry you'll find:
The client's name and OAuth client ID.
The list of scopes it currently holds.
The last refresh time — useful for spotting clients that haven't been active in a while.
A Revoke action.
Revoking a client
Clicking Revoke invalidates every token issued to that client. The next API call from the client will fail with 401, and the client will have to walk you through consent again to regain access. There's no partial revocation — it's all or nothing per client.
Revoke aggressively if you're not sure whether you still use a client. Re-authorizing is one click; living with an unused authorization is a slow leak in your security posture.
Permissions over OAuth match dashboard roles
Tokens issued via OAuth carry your user's role in the relevant organization. So:
A Viewer's token can browse but not write.
An Editor's token can write content but not change billing or team.
An Admin's token can do everything you can do in the dashboard.
If a client tries to call a tool you don't have permission for, it gets a 403 back. The dashboard and OAuth APIs share the same permission engine, so there are no surprises.
Common clients
Related
MCP Server — the actual toolset exposed to authorized clients.
Managing Team, Billing, Support — where Account Settings (and the Connected Apps tab) lives.