Identity, permissions, and short-lived tickets

A business user may log into the console or have their own backend call an API. Both paths must first establish who is acting, then determine which action is allowed on which channel or meeting. Knowing a resource ID is not authorization.

flowchart LR
    Admin["Platform administrator"] --> Session["Login session"]
    Service["Business backend"] --> Pat["Scoped API token"]
    Session --> API["AKStream.Next authorization"]
    Pat --> API
    API --> Ticket["Resource-bound short-lived ticket"]
    Ticket --> Client["Browser / app media request"]

Credential	Holder	Purpose	Do not use it for
Platform login session	Signed-in console	Manage resources allowed by roles	Impersonating another business user
API token	Business backend	Stable server-side integration	Browser code, app binaries, public logs
Short-lived media ticket	Approved player	View or download a specific resource	Managing channels or arbitrary APIs
One-use RTC admission ticket	Device approved to join	Join one specified meeting once	Platform administration or repeated joins

Authorization has two parts: the role/API token must allow the action, and the target resource must be in scope. Revoking a long-lived credential, removing permission, or changing a channel's source invalidates related short-lived tickets. Viewing an image already transfers its bytes; a separate Download action controls a dedicated download response, not whether a viewer can save an image they can see.

Developers can start with API authentication and errors. For conferencing, continue with Issue RTC admission from your backend. Console users do not need to handle tickets manually.