X.509 certificates are a cornerstone of Public Key Infrastructure (PKI). A device is issued a unique certificate containing its public key, identity information, and a digital signature from a trusted CA. When the device connects to a cloud service, it presents this certificate. The cloud service then verifies the certificate's signature against the CA's public key, checks its validity period, and ensures it hasn't been revoked. This process cryptographically proves the device's identity. For embedded systems, managing these certificates securely on resource-constrained devices is a key challenge, often involving hardware security modules (HSMs) or secure elements.

Pre-shared keys are a symmetric cryptography approach. A secret key is securely provisioned onto each device and stored on the cloud server. When a device attempts to connect, it might engage in a challenge-response protocol using the PSK. For example, the server could send a random nonce (a number used once), and the device would encrypt it with the PSK and send it back. If the server can decrypt it correctly, the device is authenticated. While simpler to implement than PKI, managing and securely distributing unique PSKs to a large fleet of devices can be a significant operational challenge, and if a PSK is compromised, all devices using it are at risk.

Token-based authentication is widely used in web and cloud services. For IoT, a device might initially authenticate using credentials (like a certificate or PSK) to obtain a short-lived access token. This token, often a JWT, is then sent with each subsequent API request. The token contains signed claims about the device's identity, roles, and permissions. The cloud service can verify the token's signature and expiration without needing to query a database for every request, making it efficient. However, securely storing and managing the initial credentials used to obtain the token on the embedded device is still critical.

Role-Based Access Control (RBAC) is a common and effective authorization model. Instead of assigning permissions directly to individual devices, permissions are grouped into roles. Devices are then assigned to one or more roles. For example, a 'temperature sensor' role might only have permission to send temperature readings, while an 'actuator' role might have permission to receive commands to turn a device on or off. This simplifies management, especially for large fleets of devices, as you only need to manage permissions for roles, not for each individual device. The cloud platform or IoT platform typically enforces these role-based permissions.

Attribute-Based Access Control (ABAC) provides a more dynamic and granular approach to authorization. Access decisions are made by evaluating policies that combine attributes. For instance, a policy might state: 'Allow devices with attribute 'location' = 'factory_floor' and attribute 'status' = 'operational' to perform the 'read_sensor_data' action on resources with attribute 'type' = 'machine_data' during 'business_hours'.' This allows for highly flexible and context-aware access control, but it can be more complex to implement and manage than RBAC.