This section describes the most common use cases for leveraging public keys stored in the Token Access Control application for IoT products such as Edge Connect and OTA Updates.

JWT with Edge Connect

Let's analyze the most popular scenario for using JWTs to identify the IoT Edge Connect clients and grant them access to the topics permitted with the token.

First, let's have a look at the sample namespace configuration in the IoT Edge Connect application. To publish or subscribe to the topics defined in the access control lists of the sample Diagnostics - JP namespace configuration, you need to provide a JWT. When building the token, you need to include the authorization groups whose permissions you want to grant to the client and sign it with a private RSA key. Signed JWTs act as temporary user credentials and allow you to communicate with the topics until the specified expiration time. See IoT-supported registered claims.

Access control lists of the Diagnostics - JP namespace configuration

A JWT with client ID,expiry date, and selected authorization groups configured for the Diagnostics - JP namespace configuration

📘

The private RSA or ECDSA key you use to sign the JWT must be a digital match for the public key you upload to a key collection in the Token Access Control application and refer to in your property configuration. Also, allow the use of your signing algorithm in the JWT behavior. See Signing algorithms.

Now let's analyze how this sample IoT Edge Connect property configuration tells the ​Akamai​ platform to search for and process JWTs in requests. Here, it directs edge servers to check the X-JWT-Location request header for tokens, use the public keys stored in the EdgeConnectKeySet key collection to authenticate the client by checking the integrity of their JWT signatures, and extract authorization and client specific information from the authGroups and clientId claims in these tokens.

IoT Edge Connect sample property configuration

Once the edge server extracts the JWT from the request and validates the client's identity, it checks the payload and permits the client to access the topics that the included authorization groups are entitled to in the Diagnostics - JP namespace configuration. Also, the client may use the token with a client identifier to access topics specified by device identity topic filters.

JWT with OTA Updates

Let's analyze the popular scenario for using JWTs to identify the OTA Updates clients who want to receive updates of software on their devices.

To receive software updates, you need to provide a JWT in a header or a query parameter of your request. When building the token, you can include IoT-supported registered claims and custom information. You then sign the token with a private RSA key. Signed JWTs act as temporary user credentials and allow you to receive software updates until the specified expiration time. See IoT-supported registered claims.

A JWT with an expiry date

📘

The private RSA or ECDSA key you use to sign the JWT must be a digital match for the public key you upload to a key collection in the Token Access Control application and refer to in your property configuration. Also, allow the use of your signing algorithm in the JWT behavior. See Signing algorithms.

Now, let's analyze how this sample IoT OTA Updates property configuration tells the Akamai platform to search for and process JWTs in requests. Here, it directs edge servers to check the X-JWT-Location request header for tokens and use the public keys stored in the OTAUpdatesKeySet key collection to authenticate clients by checking the validity of their JWT signatures.

JWT Verification behavior in the OTA Updates property

Once the edge server extracts the JWT from the request and validates the client's identity and present claims, it permits the client to download the requested file with software updates.