Port OS checks who is making a request and whether that caller can perform the requested action on the selected resource.

## Principals and identities

A principal represents a caller or resource owner. An identity lets Port OS recognize that principal when the caller signs in. A client is the application that acts for the user.

## Authentication

Authentication establishes the caller's identity. OAuth lets an application obtain a token after the user signs in and approves access. Tokens have an expiry and a target resource, such as REST or MCP. Use a token with the audience required by that API.

## Authorization

Authorization decides whether the caller may perform an action. OAuth scopes limit the authority delegated to the client. Resource access rules select which endpoints and actions the principal may use. Both must allow a request; a scope does not share a device by itself.

## Example

An assistant with endpoint:read can discover permitted devices. To control a light, it also needs message:send and a resource rule that allows control of that light. See [Access rules](/docs/user-guides/how-to-set-up-access-rules-for-port-os/) and [OAuth setup](/docs/user-guides/how-to-set-up-an-oauth-client-for-port-os/).