Authentication
Every API request carries one header:
Authorization: Bearer <token>The token is either an API key or a browser token (scoped JWT).
API keys
API keys have the prefix msk_ followed by a role segment:
| Prefix | Role | Use |
|---|---|---|
msk_u_... | user | General-purpose server-side calls |
msk_a_... | admin | Operator/platform tooling |
msk_p_... | platform | Tenant-wide automation |
API keys are server-side only. Never put an msk_* key in browser code, a mobile app, or a public repository.
Browser tokens
For browser-side access - embedding a preview, opening a terminal in an iframe - your backend mints a short-lived scoped token and passes it to the client:
Browser tokens expire, are non-renewable, and are scoped to a single resource. They cannot create new resources.
See Authentication and Browser Tokens for the full reference.
Token types
MIOSA issues five distinct token types. Each covers a different caller and trust level:
| Token | Prefix | Caller | TTL | Read / Write |
|---|---|---|---|---|
| API key | msk_* | Your server | Until revoked | Read + Write |
| JWT | ey... | Admin UI / browser session | ~1 h (refresh 7 d) | Read + Write |
| Browser token | (opaque) | Your user’s browser | Configurable (default 1 h) | Read-only, single resource |
| Preview token | mp_* | Browser / <MiosaPreview> iframe | Configurable (default 1 h) | Read-only, sandbox preview |
| Share token | ms_* | Anyone - no account required | Configurable | Read-only, sandbox preview |
The msk_* API key is the root credential. All other token types are minted downstream from it by your server. Never give an msk_* key to a browser or end user.
For minting flows, revocation, and validation rules see Authentication and Preview Tokens.