The Internet of Things (IoT) is an exciting buzz, for the many collections of previously dumb devices that are now gaining 'smart' status and increased network connectivity. Whilst there is an increasing rush to make everything connected, not all egres devices can be on line all the time.
Many IoT devices are small, even compared to the smallest of smart phones. Many have limited memory, processing power and networking capability. This can reduce the ability of the device, to interact with central authentication and authorization services over common approaches such as HTTP and REST.
Without connectivity to a central source, how do devices authenticate users, services and other devices or perform policy enforcement point style use cases? The requirement for offline capabilities forces many to look at cumbersome out of band syncing or caching approaches.
JSON Web Tokens
Asymmetric cryptographic solutions have been around for years and can provide many encryption and signing approaches when it comes to data in transit or authentication assertions. The federation protocol SAML2 relies on PKI crypto heavily. But how can this help in the brave new world of IoT? JSON Web Tokens (JWT) - or jots - can provide a lightweight signed payload that can be verified by an offline device, without the need for runtime communication to a central source. A JWT signed with the private key of a device can contain things like the public key of the identity requiring access as well as any other claims, expiration timestamps and audience attributes. These signed assertions can be quickly provisioned, stored and then presented by users and devices in order to gain access to an offline resource or machine.
(For further information on JWT see - http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html)
The creation of a JWT in this use case would require a few pieces of information. Firstly the payload - this is likely to contain the public key of the user, service or thing wanting access (this is used later in the authentication process during a challenge/response style interaction), an expiration time (Unix timestamp), an aud (or audience) attribute (which advertises who the JWT is for) and any other potential attributes used as claims.
The payload is then signed with a private key, using information from the JWT header, which contains algorithm details. The result, is a dot-separated three valued encoded string.
Integrating With OpenIDM
Once the end user or device has collected the JWT, they can then present the JWT to the device they wish to access in an offline manner. The authenticating device doesn't need to have HTTP access. It can simply use local crypto to verify the signature of the JWT, and create a challenge response using the public key of the subject, that is already contained inside the JWT payload. A successful challenge response process would require the subject presenting the JWT to have the corresponding private key, so is a nice mix of multifactor something their have authentication.
I'll shortly release the code to Github as a community contribution.