Overview: Authentication and Authorization
Authentication and authorization are two critical components in the everyday quest to secure clients and devices on the Internet. That makes these components vital to any IoT project because, at its most fundamental level, the Internet of Things is simply devices—from simple sensors to complicated cars and mobile devices—connecting together to share data. These connections must be secured, and authentication and authorization help to do that.
The two concepts have some similarities, but really each one means something very specific for this discussion:
- Authentication is the process of identifying the device. For Message Queuing Telemetry Transport (MQTT), the process of authentication is to confirm that the device’s client ID is valid; that is, the ID belongs to the device in question.
- Authorization provides a mechanism to bind a specific device to certain permissions. With Edge Connect, authorization is broken into two tasks:
- Binding devices to groups
- Binding groups to topics (this is covered in greater detail below)
There are two types of authentication and authorization: device-based and user-based. Let’s take a deeper look at each one, and specifically how they’re used.
Device-based authentication and authorization
For devices that do not have operators (or users), or devices in which the connection is independent of the operator, device-based authentication and authorization will likely be used. A good example of this is a car: whether or not the car has user-specific communication—like running user applications or providing user-specific configurations—the device (i.e., the car) is likely to want to be connected to exchange car-specific information. Examples include diagnostics, command and control, software updates, and availability of advanced features, which are all types of data that would be specific to the car, not the driver.
Device-based authentication and authorization use client-side certificates stored in the car. Authentication takes place during the TLS handshake. As part of the handshake, the car will send up its certificate, signed by a preconfigured signing authority, and will send information signed by its private key. Once the handshake is complete, the device is authenticated and the client ID will be extracted from the certificate. For a car, the client ID could be the car’s vehicle identification number (VIN).
Once the car has been authenticated and the client ID is known, it’s time to determine the proper authorization groups. By just connecting, a device can be part of an authorization group. In this example, the device is a car, so all cars connecting will get the authorization group “car”. Additional groups can be extracted from the certificate, just as they can from the client ID. For example, a variety of groups can be extracted from our car’s VIN. A diagram describing a typical VIN is shown here:
In this case, we already know the manufacturer because the manufacturer has already validated the client. But the brand and year can also be extracted from the certificate/VIN. In this case, the car would be assigned the authorization group “B-BH” (which stands for “Brand=BH”) and the group “Y-M” (which stands for “Year=M). Additionally, other fields that may present features can also be extracted and converted into groups. Assuming we extracted information out of some other field and determined that the car was a premium package with a navigation system, the car’s device-based authorization groups would be something like: car, B-BH, Y-M, NAV.
User-based authentication and authorization
User-based authentication and authorization focus on the user rather than the device. While a device still needs to provide a unique device ID, the user’s identity determines the authorization groups in this scenario. For this type of connection, Edge Connect supports JSON Web Tokens (JWT). As shown in Figure A below, the user will log in with credentials on the device by making a request to a JWT server (not included with Edge Connect); once authenticated and authorized, a JWT token is returned. This token contains claims that state the client ID, user, authorization groups, and an expiry. It is also signed to ensure that the token is valid.
Note: the JWT token can be used for HTTP-based requests including remote procedure calls (RPC) or other APIs such as shopping carts, etc.
The next step
Once a device or user has been authenticated and assigned authorization groups, the next step is to bind these authorizations to topics (topics are basically named channels, or queues, that messages are published against). This binding activity is done by first defining topic access control lists, or “topic ACLs”. Topic ACLs consist of a topic or a topic filter (i.e., a topic with a wildcard) and a list (or lists) of publishers and/or subscribers. The chart below shows some interesting ACLs with topic filters, publishers, and subscribers. The first ACL shows a typical wildcard topic filter and PUB1 as the only publisher and SUB1 as the only subscriber. Any connection with the PUB1 authorization group would be permitted to publish to any topic that matched the filter. So, in this case, a connection with the PUB1 authorization group could publish to topic/foo, topic/bar, and topic/foo/bar. The # wildcard means that any number of paths can follow “topic/”; if the topic filter was topic/+, topic/foo and topic/bar would have matched, but topic/foo/bar would not have matched.
Note that there are two sets of ACLs the have the %c path defined and the %u path defined. For the %c ACLs, a device whose client ID matches %c would have permissions to the topic. So, for the device/%c/up topic, only a device whose client ID is dev0001 would be able to publish to device/dev0001/up. Of course, anyone with the SUB2 authorization group could subscribe to (or read from) the topic. This is called a device-specific topic. You are guaranteed that only the device with an authenticated client ID that matches the topic can publish to (or subscribe to, in the second ACL) the specific topic.
The %u works the same as the %c, but instead of the client ID, the username is used. This is called user-specific topics. In order to gain access to these topics as a user, the connection must pass a JWT token with a username in a claim—often the sub(ject) claim is used. This type of topic ACL is great for user-based services. Chat is a helpful example of such a service: with chat, a user can be connected via their mobile device, a desktop device, and a web-based device at the same time. They must each have different client IDs, but they are all servicing the same user. Therefore, it’s a user-specific topic.
When determining permissions, all of the ACLs are checked, so one or more ACLs may apply to a particular topic. As you can see in the chart below, there are five ACLs, and the topic my/topic/foo/bar matches three of them. In this case, the publishers and subscribers are pub1, pub2, and sub1, sub2, sub3, respectively. When matching more than one ACL, the authorization groups are additive as shown below.
As the usage and importance of the Internet of Things continue to grow, IoT connections must be as secure as possible; authentication and authorization are two critical components that help achieve that security. Akamai Edge Connect includes industry-leading mechanisms that you can use to authenticate and authorize devices or users and help your IoT projects become and remain successful.
To see these authentication and authorization capabilities in action, simply get started with Akamai Edge Connect.