MCP OAuth and security - Niblet

Niblet MCP uses browser OAuth and binds issued tokens to the exact MCP resource. A token intended for another API audience is rejected.

Permission scopes

Scope	Allows
`apps:read`	Read developer projects and revisions
`apps:write`	Create projects and update public metadata
`submissions:write`	Submit an uploaded immutable revision
`displays:read`	Read displays, catalog data, installations, policies, and scenes
`displays:write`	Change display, app, scene, schedule, and firmware state
`offline_access`	Maintain the authorized connection with rotating refresh tokens

Server safeguards

Tokens must use the Niblet client-token format and correct MCP audience.
Every tool checks its required OAuth scope.
Tenant and user identity come from the token, not tool arguments.
Request bodies and rates are bounded.
Input schemas reject unknown or malformed fields.
Destructive tools require explicit confirmation strings.
Tool mutations produce account audit events.
Responses use no-store caching.

Data excluded from MCP

Wi-Fi details, physical enrollment values, device credentials, app credentials, provider tokens, Starlark source changes, local preview bytes, and publication approval remain outside the protocol.

Use a read-only request first. Expand to write scopes only when the assistant needs to make a specific change.