Scrollport keeps its customer-facing authentication planes separate.
Human plane
The web app uses the human session for wallet, connections and other account surfaces. Anonymous visitors are sent through the app's sign-in flow before protected pages render.
Agent plane
The device flow issues an API key bound to an account and the fixed scopes discover, inspect, run, wallet, apps and files. Keys are hashed at rest. Signing in and authorising the pending device request are separate human actions.
Authorization: Bearer sp_live_<secret>sys-admin is not requestable through device authorisation. It is an operator scope, not a customer or agent grant.
Connector OAuth plane
Remote MCP connectors use the Scrollport OAuth issuer at https://scrollport.com. Authorisation code with S256 PKCE gives one connector its own short-lived access tokens and a stable refresh credential. The fixed six scopes are the same as device setup, and sys-admin is never available. Only hashes reach the database; no token is rendered to a human.
OAuth and sp_live_… are separate credential forms over the same account and nine-tool contract. The dashboard lists each connector authorisation as one revocable OAuth connection.
Provider plane
Provider connections are keyed by account. The run layer resolves the account to a connection and a provider proxy; raw provider tokens do not enter the agent's context.
Safe handling
Treat a key as a secret with account-wide spending authority. Store it in a secret manager, rotate it by issue → verify → revoke, and never include it in a URL, screenshot or support message.
See headless setup for the device endpoints, transports for how the same contract travels over HTTP and MCP, and the published Remote MCP guides for client-specific setup.