Blogs Data Migration Javascript Security Solutions

Using AWS Cognito and API Gateway to Authenticate

Following on from my previous blog on ‘How to use APIs to build Javascript Apps’ I’m going to look at how we can use three of Amazon’s AWS services – Cognito, API Gateway and Lambda – to host, manage and authenticate access to a simple JavaScript REST API.

Authentication is the process of determining the identity of an entity, to verify that they are who they say they are. Cognito uses JSON Web Tokens (JWT) which I’ve covered in this previous blog as a standard for representing claims securely between two parties, where a claim is a name-value pair which represents information about the subject, that the server/service holds to be true.

We are going to use Amazon’s Cognito service to manage the user authentication to the REST API. AWS Cognito service provides user sign-up, sign-in and access control and Cognito’s User Pools provide a secure directory service, which can scale to enable you to manage millions of users.

steps a user must take to access the protected REST API.

The diagram above shows the steps a user must take, in order to be able to access the protected REST API.

1. As the REST API is protected by access control, the user first needs to obtain a valid JWT. The first step of this process is for the user to login to Cognito using their username and password.

2. Cognito then verifies that the user is who they say they are, by checking that the username and password provided match what’s in the User Pool.

Once the user authentication has been validated by Cognito, it generates and signs 3 seperate JWT tokens:

– an ID Token which contains claims about the identity of the authenticated user such as name, email, and phone_number.

– an Access Token which contains scopes and groups and is used to grant access to authorized resources.

– a Refresh Token contains the information necessary to obtain a new ID or access token.

In Cognito you are able to define the claims that you want the JWT to contain.

3. The next step for the user is to make the REST API HTTP request to the Gateway API service, which can be hosted on a different domain, passing the JWT Access Token along as part of the header of the request. The Gateway API service has a lot of different features, however at its core it is used to route requests to a defined backend. In this case it will be the test Lambda function that we’ve set up.

4. The API Gateway has been configured to use a specified Cognito User Pool to handle the authorisation, as you can see in the image below.

API GAteway configuration for a specific user

When a request is received, the API Gateway first checks that the request contains the ‘authorization’ header and then unpacks the JWT Access Token by decoding its contents (excluding the preceding ‘Bearer ’ string) from Base64 to two JSON strings and a signature.

The API Gateway next retrieves the Cognito User Pool’s public key. Amazon Cognito generates RSA key pairs for each user pool, and it’s that private key that is used to sign the JWT token when it’s created. The public keys are made available at an address:


If the JWT is valid then the request is allowed to proceed to the next stage.

5. The API Gateway passes the request on to the configured backend. In this case it’s our simple Lambda function:


6.The response from the REST API is then passed back to the API Gateway.

7. As the final stage, the REST API response is sent back to the requesting client.

This has been an overview on how to apply access control to your REST API using AWS’s Cognito, API Gateway and Lambda Services.

Blogs Data Migration Javascript Security Solutions

How to make your website cookie compliant

Recent research by Colin Stenning showed 37.78% of local government websites did not provide users with the means to enable or disable non-essential cookies or failed to make it easy to configure them.

Those responsible for creating, managing and maintaining a website must meet the requirements set out by the General Data Protection Regulation / UK Data Protection Act 2018 to be cookie compliant .

All websites have to meet these requirements, but users face a variety of confusing and often frustrating pop ups, banners, buttons and barriers to website entry and cookie acceptance or rejection. 

If website administrators can’t provide straight forward, recognisable options, then expecting website users to understand their rights and what cookies actually mean for them is difficult. 

The responsibility to meet the requirements can be overwhelming. Despite being responsible for policing the rules on cookies, the ICO itself has admitted to failing to meet their own rules at first. Additionally, it is worth noting that following our exit from the European Union the General Data Protection act will no longer be applicable. Although, much of the legislation will be merged with the UK Data Protection Act 2018, in 2021 new legislation is highly likely. Even if a website is compliant now changes are likely, so dealing with our website cookies is an ongoing process.

What is a cookie?

Each time a website is accessed a cookie, which is a small text file, is downloaded onto the user’s device, their computer, tablet or smartphone. .

The cookie can be either a session cookie, which is temporary and expires when the browser closes, or a persistent cookie, that will stay on the user’s hard drive until they, or the browser erases them, depending on the cookie’s expiration date (which should be no more than 12 months).

Where do cookies come from?

Websites put cookies on to devices themselves, enabling users to use their features securely. These are often essential and necessary cookies and websites do not need your permission to add these, as use of their site would be impossible without them.

However, many additional cookies such as functional cookies or marketing cookies may come from third parties, such as advertisers or analytics. These cookies must be declared and permission given by the user before they are installed.

Why are websites still failing to meet the requirements?

Most websites provide information about the presence of cookies, but aren’t unified in how effectively cookie compliance is done. As previously mentioned, the research of Local Government websites, by Colin Stenning revealed that although 98.04% of their public facing websites explain what the cookies are doing and why, only 37.78% made sure users had the means to enable or disable non-essential cookies and made it easy to do.

It is not acceptable to assume that website users will take it upon themselves to understand and access your cookie policy and find out how to change their settings. To be fully compliant, a website has to provide this information in an easy to access and completely transparent way.

How do I make sure I have cookie compliance?

You need to ensure that you have explicit consent from all of your users and that you observe their rights to data. The strict rules of compliance are that websites:

  • Do not use any but strictly necessary cookies without users’ consent.

  • List and explain the purpose of the data each cookie tracks

  • Keep a record of all users’ consent.

  • Allow access to your service even if they refuse cookies

  • Make it easy for users to withdraw consent.

There are some straightforward steps everyone can take to be compliant. Webtoffee is a great example of a plugin that ensures you capture all cookies and can efficiently block these cookies if the user elects to reject them.

A whole host of companies offer the help you may need to ensure you can request, act on and store cookie consent date. Check that any plugin or solution you use allows you to:

  • Scan and track all cookies used on your site. This needs to be redone regularly to keep up-to-date.

  • Produce a cookie report listing all cookies, which automatically updates. This can be used as the Cookie policy for your site and a link should be included in your cookie consent banner.

  • Customise a cookie consent banner. This needs to show users they can accept, reject and access a list of all cookies, in categories so users can opt in and out of specific cookie types.

  • Ensure you securely store data from users who have consented.

  • Provide the users with the option to renew their consent annually.

  • Allow users to withdraw or alter their consent easily at any point in their user journey.

Using a plugin facilitates all of the requirements you need to meet, but it is the responsibility of every organisation to make sure each of the steps to full compliance are completed efficiently.

Why is it vital to be cookie compliant?

In the current climate, data breaches cost companies on average $3.86 Million per breach, with 80% of this accounted to breaches of personally identifiable information, according to a report by Juniper Research. It is expected that globally, this number will rise to $5 Trillion by the year 2024.

Data breaches are serious business and organisations should do everything they can do to not only educate themselves but also embed data protection into their everyday culture.

Being “cookie compliant” is one step organisations can take to minimise the amount of breaches they might suffer through poor data protection.

By ensuring that visitors know what data is collected, why it is collected and how long it is stored for, they can make positive steps in the right direction to protect all data.

For more information, feel free to talk to us

Blogs Apps Javascript Uncategorized

How to use APIs to build Javascript Apps

How to use APIs to build Javascript Apps

Javascript as a language has now evolved to a place where it’s used to build both frontend and backend server applications.

It is a high level scripting/programming language built into all modern browsers, enabling dynamic functionality to be added to static web pages, and enables the creation of single page web applications seen in everyday use from Google’s GMail application to Twitter’s website.

This blog will highlight the main parts and concepts involved in creating a simple Javascript Application, concluding with a ‘sum of all parts’ working application. As you’ll see in the diagram below, 3 parts are required to deliver a functioning app.

Delivering a functioning app

The first of these is the client’s device which can be a laptop, pc or mobile device running a modern browser such as Chrome, Firefox or Edge.

Each browser includes an interpreter which executes JavaScript code. V8 is Google’s open source ( high-performance JavaScript engine, which is written in C++ making it easily portable to any platform. It is used in Chrome and also in the new Microsoft Edge browser, which was released in January 2020.

The next is the Web Server, which is responsible for serving up files (such as html, images, javascript, etc) over HTTP to the users browser requests. The most popular Open Source Web Servers are Apache and Nginx, between them they run most of the websites on the internet.

The final piece is the Application Server, which is used to host the application that the Javascript app will talk to, over its API (Application Programming Interface).

The API is a specification of the functionality that the application provides, it is intended to enable software components to communicate with each other. The concept behind API’s is that they should abstract away the more complex functionality of the application’s code and provide a simple, easy to use interface for other applications/programs to be able to use. When two systems connect together via an API we say that they are integrated. In an integration, there are two distinct sides: the client and the server, the server is the side that runs the program that provides the API, and the client is the side that uses/consumes the API.

OpenAPI is one of the more popular API specifications, it was previously known as Swagger, it is used to define the API endpoints as well as the format of the response messages which are defined in JSON, a machine-readable data format.

The following are an example of the steps necessary for a Javascript app to request and display a list of contacts.

Stages 1-2

The browser makes a http request to this requests the index.html page from the Apache web server. Once the browser processes the index page any additional referenced items from the index page such as css, images or javascript are also loaded and then in the case of javascript the script/scripts are run.

Stages 3-4

Once the Javascript app has started up in the browser, it makes a https request, for example to retrieve a list of contacts, to the application server via which on success returns a list of contacts in json format

   "name": "Cassio Zen",
   "email": ""
   "name": "Dan Abramov",
   "email": ""
   "name": "Pete Hunt",
   "email": ""

Once the application has received the json data response from the API, it uses this to render a list of the contacts in the browser.

This has been a high level overview of how javascript applications work in combination with APIs, the next blog will cover the security and authentication side of APIs.

Talk to us

If you’d like to talk to someone on our team about this topic, please get in touch.

More blogs by this author