Three related ideas show up in KEY1-CORE side by side: long-lived API keys, human-facing passwords (rarely stored as such in vault UIs), and OAuth flows that yield tokens after you approve access in a provider window.
You generate or copy it from a dashboard, paste into the vault, and apps attach it to outbound API calls. Rotation is manual unless you build automation — you visit the provider and invalidate the old key.
Used when a human authenticates (often with MFA). Modern APIs rarely want your Netflix password; they want a token or key issued after that login. If you store passwords in any vault, assume breach impact is total for that account — keys are bad, passwords are worse.
You click “Sign in with Google,” approve scopes, the app receives a short- or medium-lived token (and often a refresh token). The vault stores those under stable ids (e.g. kip_token) so other Coffee pages can call provider APIs without embedding a raw API key for Google.
On KEY1-CORE, the Connect AI + socials card is OAuth-shaped; preset rows under Active Credentials are often plain API keys. Same vault; different acquisition story.