Integration permissions and effective operations

Integration access depends on the accepted identity and permitted operation at each system involved, including server policy and underlying resource access.

An integration performs operations under an identity accepted by each system it contacts. On the media server, that can be a user-authenticated context or the documented static API-key arrangement.

Those identities have different contracts. Adding a user ID to a path does not by itself authenticate as that user or guarantee permission to act on that user's behalf.

Identify the operation and its effective access

An original policy model permits playback and denies deletion:

Request Identity accepted? Operation permitted? Result under this model
Play an allowed title Yes Yes Continue to required media operations
Delete that title Yes No Refused
Play with an unaccepted credential No Not reached Authentication fails
Read a denied library Yes No Refused

The model describes separate gates rather than claiming this is every Emby endpoint's exact implementation. Use the current endpoint and account/key contract for the real result.

Successful authentication is not a universal authorization grant.

Storage introduces another identity

A permitted playback request still needs Emby Server to open the source under its operating-system storage identity. A permitted sidecar save needs the relevant write access.

Conversely, a server process having filesystem write access does not imply that every viewer or API caller is permitted to request deletion.

The chain can be:

Integration credential -> accepted server identity
Server operation policy -> applicable request permission
Server process identity -> source/storage access
External action credential -> destination-system permission

Each arrow introduces a relationship to establish, not inherited authority that automatically flows from the preceding label.

The destination evaluates its own caller

If an integration sends a lighting command, the lighting service evaluates the integration's credential there. It does not automatically know or apply an Emby viewer's media permissions.

A useful design ties each credential to the needed supported operations and keeps its revocation boundary clear. Emby's API-key documentation recommends distinct keys per integration; it does not supply an invented set of narrowly scoped OAuth permissions.

For diagnosing a failure, preserve which system refused which operation. A storage error, media-server policy refusal and rejected downstream credential may all appear during one workflow while having different causes.

See Also

References