# Account Authentication & Account Linking > This page covers **human account authentication** (signing into the Gakaso web app) and account linking/unlinking. It does not cover MCP/agent authentication — that uses a separate project-scoped API key mechanism described in `/mcp/overview.md`. ## Sign-in providers Gakaso account sign-in supports multi-provider OAuth: - **GitHub** - **Google** Both are wired through the shared `@atasino/auth` authentication library, with session cookies, CSRF protection, brute-force lockout, and rate limiting applied uniformly regardless of which provider a user signs in with. A user does not have to pick a provider once and stick with it — account **linking** lets one human account have multiple sign-in methods attached simultaneously. ## Account linking / unlinking From account settings (the "Login methods" card), a signed-in user can: - **Link** an additional OAuth provider to their existing account, so they can subsequently sign in with either. - **Unlink** a previously-linked provider, removing it as a valid sign-in method. Safety rules enforced server-side (not just in the UI): - **You cannot unlink your last remaining sign-in method.** The server computes "is this the user's only login method" atomically at unlink time (not via a separate pre-check, to avoid a check-then-act race) and rejects the request with a `LAST_METHOD` error if it would leave the account with zero ways to sign in. - Unlink requests are same-origin checked, session-authenticated, and rate-limited (a stricter budget than most routes, since this operation can affect the account's entire authentication surface). - Every link/unlink outcome is written to an explicit audit trail, independent of the underlying auth library's own event log. ## What this means for you as an agent - You generally do not need to worry about account-linking mechanics — it's a human-facing account settings feature. It's mentioned here mainly so you don't mistake "sign-in provider" for "MCP authentication": **they are unrelated**. Your MCP session is authorized by an API key scoped to a project, not by which OAuth provider the human used to sign into the dashboard. - If a human asks you to "log them out of GitHub and use Google instead" or similar, that is a browser/account-settings action outside MCP's scope — direct them to account settings rather than trying to perform it via MCP tools. ## Session mechanics (for context only) - Sessions use an HttpOnly, Secure session cookie plus a JWT. - CSRF tokens are required for all state-changing requests in the browser app. - Brute-force protection locks out repeated failed sign-in attempts. - Redirect targets after sign-in are restricted to same-origin URLs (no open-redirect). These are standard web-session protections and are not relevant to how you, as an MCP client, authenticate — see `/mcp/overview.md` for that.