How Cloud authentication works

Appwrite Cloud is a hosted OAuth 2.1 Resource Server served over MCP Streamable HTTP. On every request it validates the client's bearer token and forwards it to the Appwrite REST API, which accepts the OAuth2 access token directly.

The flow

MCP-aware clients run this automatically:

sequenceDiagram
    participant C as MCP Client
    participant S as MCP Server (/)
    participant A as Appwrite OAuth Server
    participant API as Appwrite REST API

    C->>S: GET / (no token)
    S-->>C: 401 + WWW-Authenticate → metadata URL
    C->>S: GET /.well-known/oauth-protected-resource
    S-->>C: auth server + scopes (RFC 9728)
    C->>A: Discover (RFC 8414 / OIDC)
    C->>A: Self-register as public PKCE client (RFC 7591)
    A-->>C: client_id (no secret to pre-provision)
    C->>A: OAuth 2.1 + PKCE auth-code flow (RFC 8707 resource)
    A-->>C: access token (audience bound to this server)
    C->>S: GET / + Authorization: Bearer <token>
    S->>API: Forward bearer token
    API-->>S: Response
    S-->>C: Response

The key detail is that clients self-register — the auth server exposes an open registration_endpoint (RFC 7591), so there's no client ID or secret to pre-provision. Everything else is standard OAuth 2.1 + PKCE, with the RFC 8707 resource indicator binding each token's audience to this server.

The conventional /mcp endpoint is a direct alias. It publishes matching protected-resource metadata at /.well-known/oauth-protected-resource/mcp, and tokens audience-bound to either URL are accepted by the shared service.