Qdrant RBAC MCP server

qdrant-mcp-rbac

Maintained by Fidonis · See TRADEMARK.md for the trademark notice.

A FastMCP server that exposes a Qdrant vector database over streamable HTTP with OIDC-based authentication (Keycloak-compatible) and role-based access control mapped onto Qdrant's native JWT access rules.

Role grants are stored as data inside a dedicated Qdrant collection, not in configuration files — admins manage them at runtime via MCP tools.

┌──────────┐   OIDC Bearer   ┌─────────────────┐   Qdrant JWT    ┌──────────┐
│ MCP host │ ──────────────▶ │ qdrant-mcp-rbac │ ──────────────▶ │  Qdrant  │
│ (client) │                 │   (FastMCP)     │                 │          │
└──────────┘                 └─────────────────┘                 │  ┌─────┐ │
                                     │                           │  │_rbac│ │
                                     ▼                           │  │_acl │ │
                                 Keycloak                        │  └─────┘ │
                                 (JWKS, OIDC discovery)          └──────────┘

Quick start (Docker)

docker run --rm -p 8000:8000 \
  -e OIDC_ISSUER_URL=https://kc.example.com/realms/myrealm \
  -e OIDC_AUDIENCE=mcp-server \
  -e QDRANT_URL=http://qdrant:6333 \
  -e QDRANT_JWT_SECRET=<same secret as Qdrant's api-key> \
  ghcr.io/fidonis/qdrant-mcp-rbac:latest

/mcp is the streamable-HTTP endpoint, /health is unauthenticated. See the full docker/.env.example for every variable.

How it works

(signature, expiry, audience, issuer; see Token validation).

1. The MCP client sends a request with an OIDC access token (Authorization: Bearer …).
2. The OIDCAuthMiddleware validates the token against the OIDC provider's JWKS

1. The JWTBuilder derives a Qdrant JWT for the user:

a global-manage token is minted directly.

• If the user is in the break-glass admin role (RBACADMINROLE),

mapping built from the ACL collection (RBACACLCOLLECTION, default rbacacl).

• Otherwise, the AclResolver returns the cached role -> [grants]

and forwards the request to Qdrant using the derived JWT.

1. The Qdrant JWT is attached to the request scope.
2. Each MCP tool checks the user's effective access for the targeted collection

Token validation

Tokens are validated with PyJWT against the keys published by the issuer ({OIDCISSUERURL}/.well-known/openid-configuration, then its jwks_uri):

ES256 for an RSA / EC key without one), never from the token header. Only RS256, RS384, RS512, ES256, ES384 and ES512 are accepted; symmetric (HS*) and none tokens are rejected.

• Signature algorithm comes from the signing key (its alg, or RS256 /

equal the issuer in the discovery document) and a non-empty sub. A token without exp or aud is rejected. nbf is enforced when present.

• Required claims: exp, aud (must contain OIDC_AUDIENCE), iss (must

provider does not reject freshly issued tokens.

• iat is not checked, so clock skew between this host and the identity

with an unknown kid triggers exactly one JWKS refresh before it is rejected.

• Key rotation: keys are cached for OIDCJWKSCACHE_TTL seconds. A token

• Roles are read from realmaccess.roles and from every resourceaccess..roles.

ACL collection schema

Each grant is one point in rbacacl. The point id is a deterministic uuid5(role, collection), so re-granting is idempotent. Payload:

{ "role": "data-scientist", "collection": "embeddings_v2", "access": "rw" }

access is one of:

Shortened. The full README is on GitHub.