IoT Hub - Concepts

Auto-provisioning

Auto-provisioning allows your hub to automatically onboard an unknown device when that device provides valid TLS credentials.

Client

A client refers to any software connected to the IoT Hub. The software could be running on a connected device (firmware), an IoT Gateway or a server (application).

Device

A device is a representation of a client. Each device that connects to the hub is represented by a unique ID. The concept of devices allows the hub to authenticate clients and modify its behavior towards each one appropriately. This includes the way the client connects to the hub, the way messages are filtered and the way metrics are collected. See Understanding Devices for more information.

Device authentication

Device authentication ensures that only authorized devices can connect to a hub. To authenticate a device, the hub may use:

• the client certificate signature and common name, matched to the Hub certificate authority and device name
• the client certificate fingerprint, matched to a device certificate
• the MQTT username, matched to a device ID (if the device is configured to allow insecure connections)

Device certificate

A device certificate is a method of client authentication. A customer can provide any certificate for a specific device. In this case, the certificate does not need to be signed by the hub Certificate Authority.

Hub server certificate authority

Upon connecting to an IoT Hub using TLS, MQTT clients will be provided with a hub server certificate. The client can verify this certificate using the hub server Certificate Authority.

Hub certificate authority

This is the Certificate Authority the hub will use to verify the certificate provided by a connecting client.

Hub Events

Hub Events may be understood as log entries for your hub. They are triggered by events such as errors, security notices and auto-provisioning events, and then published on the hub.

Insecure connection

A connection is deemed insecure if mutual TLS is not enabled for it. This implies authenticating with a token, which is weaker than using a certificate. Devices may be configured to allow or deny insecure connections. If allowed, TLS and Plaintext are available. mTLS is always available.

Last Will Message

When connecting, a client can provide a Last Will message to the Broker. This is a regular message which will be published by the Broker if the client disconnects unexpectedly. This mechanism allows clients to make sure other clients will be notified when they disconnect, whether properly or unexpectedly.

Message

Messages are the base data transmission unit for IoT Hub. A message contains a payload (which can be any data) and a topic (which can be any string, and indicates what is in the payload). The hub dispatches messages between connected clients.

Message Broker

IoT Hub is a message broker. It dispatches messages from publishers to subscribers (connected clients). With IoT Hub, subscribers receive a copy of published messages they are subscribed to. See Understanding Hubs.

Message Filter

Message filters restrict the messages a device can publish or subscribe to. Each filter can be configured to allow or reject given topics.

MQTT

Message Queuing Telemetry Transport (MQTT) is a lightweight publish/subscribe protocol for exchanging messages between devices and/or applications. Find out more about MQTT on our blog.

Mutual TLS (mTLS)

Mutual TLS is a method of mutual authentication. It indicates that both the TLS client and TLS server are required to authenticate each other. Each party must therefore possess a certificate to provide to the other, as well as a Certificate Authority to verify the certificate provided by the other party.

Network

Networks are the front doors to a Hub. Each Network supports a different protocol to exchange messages with the hub. See Understanding Networks for more information.

Publish/Subscribe

The publish/subscribe model (also known as pub/sub) provides an alternative to traditional client-server architecture. In the client-sever model, a client communicates directly with the application supposed to receive the information. The pub/sub model decouples the client that sends a message (the publisher) from the client or clients that receive the messages (the subscribers). The publishers and subscribers never contact each other directly. In fact, they are not even aware that the other exists. MQTT is a publish/subscribe protocol.

Quality of Service levels (QoS)

Quality of Service level determines the reliability of the data flow between a client and a message broker. The message may be sent in three ways:

• QoS 0: the message will be received at most once (also known as “fire and forget”).
• QoS 1: the message will be received at least once.
• QoS 2: the message will be received exactly once.

Increasing the QoS level decreases message throughput because of the additional exchanges required between the client and the broker.

Routes

IoT Routes forward messages to non publish/subscribe destinations such as databases, REST APIs, Serverless functions and Object Storage buckets. See Understanding Routes for further information.

TLS

Transport Layer Security, and its now-deprecated predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. See also Mutual TLS.

Topic

A topic indicates what information is contained in a message. The message broker uses topics to forward published messages to the right subscribers. Learn more about topics on our blog.

WebSocket

WebSocket is a way for a browser to upgrade an HTTP connection into a somewhat “raw” TCP connection. By doing so, the HTTP server is now able to send data to the HTTP client without the client having to request it.