OneLifeVibe

Glossary

The identity, assistant-connector and webhook terms behind OneLifeVibe, in plain words.

The standards and patterns behind Sign in with OneLifeVibe, the assistant connectors and the Platform API, each with exactly how OneLifeVibe uses it.

• Access token audience (aud)The claim that names which service a token is meant for; a service must refuse tokens addressed to someone else.
• API keyA secret string a program sends with each request to prove which client it is.
• API key scopes and worldsPermissions on an API key: what it may do, and on which websites.
• At-least-once deliveryA delivery guarantee where every message arrives, but some may arrive more than once.
• Authorization server metadataA JSON document listing an OAuth server's endpoints, supported grants and keys.
• Cursor paginationPaging through a list by passing back an opaque position (a cursor) instead of a page number.
• Dynamic client registrationA way for an OAuth client to register itself with an authorization server through an API instead of by hand.
• Event ingestAn endpoint where trusted producers publish their own events into a shared log.
• IdempotencyThe property that doing the same request twice has the same effect as doing it once.
• Issuer identification (iss)An iss parameter in the authorization response that lets a client confirm which server answered, defeating mix-up attacks.
• JSON Web Token (JWT)A signed, compact token whose claims (issuer, audience, expiry, subject) a server can verify without a database lookup.
• JSON-RPC 2.0A small remote-procedure-call format: a JSON object with jsonrpc, id, method and params, answered with result or error.
• llms.txtA plain Markdown file at a site's root that tells language models what the site offers and where to find it.
• MCP tool annotationsHints a server attaches to each tool so an assistant knows whether it reads, writes, can be repeated or reaches other people.
• Model Context Protocol (MCP)An open protocol that lets AI assistants discover and call tools on remote servers.
• OAuth 2.1The consolidated version of OAuth 2.0 that makes PKCE mandatory and drops the implicit and password grants.
• OAuth protected resource metadataA JSON document at a well-known URL that tells a client which authorization server protects an API.
• OAuth scopesNamed permissions a client asks for at sign-in and the person approves on a consent screen.
• OAuth token exchangeA grant that trades one access token for another, usually narrower one, for a specific downstream service.
• OpenID Connect (OIDC)An identity layer on top of OAuth 2.0 that lets a website sign a person in and learn who they are.
• PKCE (Proof Key for Code Exchange)A one-time secret a client creates per sign-in so that a stolen authorization code cannot be redeemed by anyone else.
• Rate limiting and quotasCaps on how many requests a client may make per minute and per day.
• Refresh token rotationIssuing a new refresh token every time one is used, so a stolen old one stops working.
• Replay protectionRefusing a valid, signed message that is old or already processed, so a captured request cannot be sent again.
• Resource indicatorsAn OAuth parameter (resource) that tells the authorization server which API the token is for.
• Retry schedule with backoffRetrying failed deliveries after growing delays instead of all at once.
• Sandbox (free API tier)A free plan for prototyping against an API before paying.
• Single sign-on (SSO)One account and one sign-in that work across several independent websites.
• Streamable HTTPThe MCP transport where a client sends JSON-RPC messages to one HTTP endpoint with POST.
• Tool input schemaA JSON Schema that declares the arguments a tool accepts, with types, ranges and required fields.
• WebhookAn HTTP POST a service sends to your endpoint when something happens, so you do not have to poll.
• Webhook signature (HMAC-SHA256)A keyed hash sent with each webhook so the receiver can prove the body came from the sender and was not changed.