Authorization - Amazon IoT Core
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Authorization

Authorization is the process of granting permissions to an authenticated identity. You grant permissions in Amazon IoT Core using Amazon IoT Core and IAM policies. This topic covers Amazon IoT Core policies. For more information about IAM policies, see Identity and access management for Amazon IoT and How Amazon IoT works with IAM.

Amazon IoT Core policies determine what an authenticated identity can do. An authenticated identity is used by devices, mobile applications, web applications, and desktop applications. An authenticated identity can even be a user typing Amazon IoT Core CLI commands. An identity can execute Amazon IoT Core operations only if it has a policy that grants it permission for those operations.

Both Amazon IoT Core policies and IAM policies are used with Amazon IoT Core to control the operations an identity (also called a principal) can perform. The policy type you use depends on the type of identity you are using to authenticate with Amazon IoT Core.

Amazon IoT Core operations are divided into two groups:

  • Control plane API allows you to perform administrative tasks like creating or updating certificates, things, rules, and so on.

  • Data plane API allows you send data to and receive data from Amazon IoT Core.

The type of policy you use depends on whether you are using control plane or data plane API.

The following table shows the identity types, the protocols they use, and the policy types that can be used for authorization.

Amazon IoT Core data plane API and policy types
Protocol and authentication mechanism SDK Identity type Policy type
MQTT over TLS/TCP, TLS mutual authentication (port 8883 or 443)) Amazon IoT Device SDK X.509 certificates Amazon IoT Core policy
MQTT over HTTPS/WebSocket, Amazon SigV4 authentication (port 443) Amazon Mobile SDK Authenticated Amazon Cognito identity IAM and Amazon IoT Core policies
Unauthenticated Amazon Cognito identity IAM policy
IAM, or federated identity IAM policy
HTTPS, Amazon Signature Version 4 authentication (port 443) Amazon CLI Amazon Cognito, IAM, or federated identity IAM policy
HTTPS, TLS mutual authentication (port 8443) No SDK support X.509 certificates Amazon IoT Core policy
HTTPS over custom authentication (Port 443) Amazon IoT Device SDK Custom authorizer Custom authorizer policy
Amazon IoT Core control plane API and policy types
Protocol and authentication mechanism SDK Identity type Policy type
HTTPS Amazon Signature Version 4 authentication (port 443) Amazon CLI Amazon Cognito identity IAM policy
IAM, or federated identity IAM policy

Amazon IoT Core policies are attached to X.509 certificates, Amazon Cognito identities, or thing groups. IAM policies are attached to an IAM user, group, or role. If you use the Amazon IoT console or the Amazon IoT Core CLI to attach the policy (to a certificate, Amazon Cognito Identity, or thing group), you use an Amazon IoT Core policy. Otherwise, you use an IAM policy. Amazon IoT Core policies attached to a thing group applies to any thing within that thing group. For the Amazon IoT Core policy to take effect, the clientId and the thing name must match.

Policy-based authorization is a powerful tool. It gives you complete control over what a device, user, or application can do in Amazon IoT Core. For example, consider a device connecting to Amazon IoT Core with a certificate. You can allow the device to access all MQTT topics, or you can restrict its access to a single topic. In another example, consider a user typing CLI commands at the command line. By using a policy, you can allow or deny access to any command or Amazon IoT Core resource for the user. You can also control an application's access to Amazon IoT Core resources.

Changes made to a policy can take a few minutes to become effective because of how Amazon IoT caches the policy documents. That is, it may take a few minutes to access a resource that has recently been granted access, and a resource may be accessible for several minutes after its access has been revoked.