How to Secure Your API With JSON Web Tokens

A simple way of adding authorisation to your Linx solutions See the sample

JSON Web Tokens (JWT) have become somewhat of an industry-standard for securing REST API’s. The main advantage of JWT is that each token is self-contained, meaning that it contains all information needed to allow or deny any given requests to an API. This means JWT authentication can be implemented in a distributed fashion, is less resource-intensive and generally the preferred choice in enterprise-level services. 

Unfortunately, implementing JWT is not always straightforward and can quickly become very complex. Amongst the things you will need to learn are how to format and encode payloads, sign and encrypt messages and format HTTP headers correctly. There are plenty of coding tutorials and libraries out there for any programming language and, with some time and effort, you will probably be able to implement JWT correctly to make your API secure. 

However, in this article, I will explain to you how you can easily and simply secure a REST service with Linx. When you use Linx, you can use JWT without having to learn encoding techniques, cryptography and the https protocol and secure your REST API in just a few clicks. 

Defining API Security

Here are the common myths explained and debunked.

The OpenAPI3 specification defines the security scheme for token-based authentication, like JWT, as “Bearer authentication”. The scheme is called “bearer” and the type is “http” (see spec at So, in Linx, we call this scheme the “HTTP Bearer” security scheme. 

In order to implement the “HTTP Bearer” security scheme for a REST Web Service in Linx, we first need to create a new solution in the Linx Designer. We then add the REST plugin to our solution and can drag the SimpleRESTHost service into our solution. 

In the properties panel of the SimpleREST Host service, we can find a range of properties to configure the API. The two I want to focus on in this article are: 

Security scheme – a simple drop-down where you can choose between two currently supported security schemes Operations – the property where you will configure the operations, sometimes also called methods, for your service

To set the security scheme for the service, you just need to select “HTTP Bearer” in the dropdown. When you do this a field called “Bearer secret” appears. The value from the “Bearer secret” field will be used to digitally sign and to validate JWT security tokens for the service. 

To make this service secure, it is advisable to enter a long string of random characters into this field. In order to be able to access the secret when I generate the token, I need to add the secret as a setting. I can then select that setting in any property where I want to refer to the secret in my solution. 

Creating Secure Operations

In any typical business, there are a multitude of business-enhancing applications that don’t require full-stack development teams, where practices such as continuous deployment or test-driven development might be overkill. Similarly, a true developer will know, 50-80% of the code they write doesn’t directly support business-specific use cases; it goes into coding and supporting a number of non-unique systems that every application needs – authentication, authorization, database, etc.

Now, I want to create two operations under

Continue reading

This post was originally published on this site