JSON web token verification

JSON web token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained method for securely transmitting JSON-encoded information between parties. At ​Akamai​, you can use JWTs to quickly identify and authorize OTA Updates clients who send requests to origin servers.

A JWT contains information about an entity in the form of claims and combines three elements encapsulated in JSON objects:

  • Header
    Contains information about the media type of the JWT and the hashing algorithm used for encoding the JWT.

  • Payload
    Contains the actual statements represented as public claims that two parties exchange. Currently, the IoT products support the use of pre-defined registered and private claims. For more information, see IoT-supported registered claims.

  • Signature
    Ensures the proper identification of the request sender and protects the request from being tampered with.

JWTs are stateless, which means that incoming JWT requests can be validated on the spot. You don't have to store session states on the server and load user information from a database or cache. This immediate validation increases the scalability of your system and provides an overall faster client-server experience.

​Akamai​ verifies JWT signatures at the edge, which negates the need to go back to origin for verification and offloads your identity provider. This behavior also contributes to improved security by allowing edge servers to filter out unauthorized requests before they can reach your origin infrastructure.

The IoT products support the use of RSA private/public key pairs for JWT signature verification. This ensures the data in the JWT payload has not been modified by third parties. Your identity provider first signs a JWT by using a private key. The IoT products then verify the integrity of the JWT by using a public key that you upload in the Token Access Control application.

Based on your JWT claim configuration, the IoT products check the token for the presence of claims and validates the value of each present claim. If the optional claims are present and their expected values are correct, JWT validation succeeds and the system allows the entity issuing the JWT to access the requested resources.

For more information on the JWT standard, see the JWT specification.

Signing algorithms

The IoT products support verification of JWT signatures generated with these algorithms:

  • RS256
    RSA Digital Signature Algorithm with the SHA–256 hash function. It's an asymmetric algorithm that uses a pair of RSA private and public keys to generate and validate JWT signatures. For IoT, you can use only RSA keys with a key length between 1024 and 4096 bits. See JWT algorithms.

  • ES256
    Elliptic Curve Digital Signature Algorithm with the P–256 curve and the SHA–256 hash function. It's an asymmetric algorithm that uses a pair of ECDSA private and public keys to generate and validate JWT signatures. For IoT, you can use only ECDSA keys using the P–256 (secp256k1) curve. See JWT algorithms.

IoT-supported registered claims

The following table lists the optional public registered claims that you can encode and transmit as the payload of a JSON web token (JWT).

Supported public registered claims

Claim nameDescription
nbfIdentifies the time before which the token is not accepted for processing. The client’s current date and time must be later than or equal to the not-before date and time listed in the nbf claim.

The clock skew amount specifies the allowed time difference between the server and client clocks when validating the nbf claim, is set to 10 seconds.
expIdentifies the expiration time when the token is no longer accepted for processing. The client’s current date and time must be earlier than the expiration date and time listed in the exp claim.

The clock skew amount specifies the allowed time difference between the server and client clocks when validating the exp claim. It's set to 10 seconds.
iatIdentifies the time of issuing the JWT. This value is specified in numeric date format. For example, 1/1/2020, 1-1-2020, or 1.1.2020