DEV Community: Mariano Calandra

Five tools to deliver stunning online presentations and courses

Mariano Calandra — Fri, 30 Apr 2021 08:58:00 +0000

In the early days of 2020, when Coronavirus starts hitting the world of businesses, the first job activities that have been stopped was the so-called workplace learning. According to a study by McKinsey:

As of early March 2020, roughly one-half of in-person programs through June 30, 2020, have been postponed or canceled in North America; in parts of Asia and Europe, the figure is closer to 100 percent.

A terrible loss of knowledge.

Luckily the industry recovered quickly through remote training and applications like Zoom and Teams have been essential tools in our daily job.

Unluckily, good public speaking skills are no longer sufficient. Today, to bring out these skills you also need the right tools or your presentations will lose their effectiveness, no matter your elocution.

In this article, I have put together five fundamental tools that you must have if you want to deliver stunning online courses and presentations.

1. Microphone

If you are using your laptop microphone in your courses, chances are that your audio doesn’t sound really enjoyable to the students. So the first step is to buy a decent microphone, like:

Blue Yeti Nano (desktop)
Rode SmartLav+ (clip)

The first is a desktop microphone (but can be mounted on a stand); the other one is a lavalier microphone with a handy clip to fix it on your shirt.

What’s the best? It depends on your presentation style: if you tend to move easily, Rode is fine, otherwise, Nano sounds slightly better.

ProTip #1: To have the best possible result you should be able to calibrate your mic on your voice. This video explains thoroughly how to set Blue Yeti using a well-known free tool called VoiceMeter.

2. Drawing tablet

In a real class, usually, you have a whiteboard or a flipchart where you can draw a sketch. Now you are alone, and if slides aren’t enough, you are in big troubles.

A drawing tablet can be considered the remote version of a flipchart. There are various types to choose from. The XP-PEN Artist 12 PRO, for instance, has a good value for money.

ProTip #2: Use your tablet to enrich slides with extra contents (do not overdo it), or open a site like Ziteboard to draw something from scratch.

3. Webcam or DSLR camera

A study published in Cognitive Science decyphers how gestures improve the effectiveness of teaching. For this, of course, you will need a good webcam like Logitech Brio.

ProTip #3: Logitech Brio has a wide-angle lens, so it can better capture your gesture.

If you have a greater budget consider a DSLR camera like Canon M200 with Elgato CamLink to have a stunning quality.

4. Lights

Natural light is great, but if you are streaming late at night or have poor quality lights in your room then this could be a problem.

In this case, a classic lamp may not be useful as it would create strong shadows on the face, and therefore a set of soft-dimmable lights such as the Elgato Key Light set may be better.

5. Presenter

If during your class you are sitting at a desk, having your computer handy, you could skip this tool. On the contrary, if you like to deliver your presentation standing then a presenter, like the Logitech Spotlight, is mandatory.

It works as a normal presenter (next slide, previous slide,…) but, as a plus, it allows you to darken your screen, casting a spot of light just on the point of the discussion.

The spot can be driven through hand movement and, if you are a traditionalist, can be replaced with a classic laser pointer effect.

A great boon for online presentation!

ProTip #4: The spotlight effect is fancy and cool but sometimes the thing that you want to highlight is bigger (or much smaller) than the spot of light; this will give an awkward sensation and, for this reason, the virtual laser effect could be a better choice.

Conclusions

Tools hardly change the matter of things. A good trainer will be a good trainer even in a virtual classroom; a bad trainer will be a bad trainer even with better gears.

Nevertheless, even the best trainer will lose part of effectiveness by moving from a real to a virtual class. The tips in this article are just an attempt to reduce this gap.

Hope that helps. If you like this story and want to support click here and buy me a coffee.

Take care and never stop teaching.

And learning!

Note: Commissions may be earned from some of the links above.

Cover photo by Jonathan Farber on Unsplash

Five books every serverless developer must read

Mariano Calandra — Mon, 15 Mar 2021 09:41:26 +0000

Five books every serverless developer must read

So here’s the thing: you are an experienced developer thrilled by the opportunities of serverless architectures. You read books, watch any possible video courses but when it comes to starts building a real serverless solution you feel completely naked; like if you are missing something.

Over the years I have taught many developers and architects who had the same problem as you and all did one thing, apparently sensible but useless in practice. All of them focused (erroneously) on serverless, but serverless is just an execution model, things that matter are elsewhere.

So what is serverless?

Serverless is many things. It could be a serverless database, serverless storage, serverless runtime, and so on. It goes without saying that the latter represents the glue that binds any other serverless component together, so this is where we have to start.

In this scenario, we have mainly two options: serverless runtime based on containers (e.g. AWS Fargate) or serverless runtime based on functions (e.g. AWS Lambda or Azure Functions). Despite differences, they have one thing in common: to work at their best, the applications hosted should be made of many small services rather than a single monolithic one.

Welcome Microservices

Microservices architectures are an architectural style that structures the application as a collection of small services. These services can communicate with each other so they can resolve a more complex business scenario.

When these microservices have to be deployed, we can do so using containers or, if we prefer, using functions.

Microservices is a design concept.
Containers or functions are just deployments offers.

If you want to be successful in serverless adoption, you will first need solid microservices’ knowledge. Only in this way you can be prepared and avoid the common pitfalls of serverless adoption.

For this reason, I grouped together five books that every good serverless developer must read, and surprise, these books are mostly about microservices, rather than AWS, Azure, or serverless.

1. Eric Evans — Domain-Driven Design: Tackling Complexity in the Heart of Software

We said that microservices are a collection of small services. But does that means that microservices have to be small? How small they need to be?

To answer these questions properly, we need to understand the business capabilities and design accordingly and that’s all this book is about.

The volume is full of information and insight that would worth reading at least twice. People usually tend to focus on chapters 5 and 6 where the author defines the concept of Entities, Value Objects, and Aggregates, commonly known even outside the DDD community today.

Even though these components are crucial I strongly suggest focusing attention on Ubiquitous Language and Bounded Contexts. These concepts are core to our needs because can help to answer the question: how small a microservice should be?

Click here to buy Domain-Driven Design by Eric Evans

2. Sam Newman — Building Microservices: Designing Fine-Grained Systems

If you are new to microservices this is where you have to start. The book is generic enough and doesn’t require any knowledge of a particular programming language, that’s why I love it at first.

The first three chapters start with a great introduction about the software world and microservices, then the book is well divided into categories (one for each chapter): Integration, Deployments, Testing, and so on, which makes it handy to find and (re)read a concept in the future.

Click here to buy Building Microservices by Sam Newman

3. Richard Rodger — The Tao of Microservices

I fell in love with this book at the time because it explicitly talks about messages. The author invites the reader to avoid the temptation to design systems start thinking about services; rather he suggests starting from messages as their flow well describes the system behaviour.

This way of thinking allows us to feed two birds with one scone. First, it naturally drives you into event-driven applications. Second, it simplifies the design of your system (in this regard, I strongly suggest taking a look at
Alberto Brandolini’s Event Storming workshop).

Back to the book, as microservices completely change the way we think of data, Chapter 4 is essential, as you may discover a lot of things that will be useful when you are building serverless applications.

Same for Chapter 6 (i.e. Measurement) which talks about the limits of traditional monitoring when it comes to microservices and FaaS.

Click here to buy The Tao of Microservices by Richard Rodger

4. Chris Richardson — Microservices Patterns

After a first introduction to the world of microservices, we can see in detail what are the industry best practices that we should adopt.

In addition to a ritual introduction, the book focuses on what are the decomposition strategies, or how to think in terms of microservices and here Domain-Driven Design and its teachings come useful.

Do you have a doubt about testing? Want to learn more about deployment strategies? Have you heard of patterns like circuit-breakers or saga but you don’t know what they are for? Then this book is the most authoritative source in
which to find the answers.

Click here to buy Microservices Patterns by Chris Richardson

5. Ethan Garofolo — Practical Microservices: Build event-driven architectures with Event Sourcing and CQRS

After four books of theory, we close the series with a practical book, a real hands-on tutorial.

The thing I like most about it is that, like for the Tao of Microservices, it too focuses on messages. It starts with these two hot topics — CQRS and Event Sourcing.

Click here to buy Practical Microservices by Ethan Garofolo

Conclusion

We often read posts about the benefits of serverless; as I’m a strong advocate for serverless adoption I like to share these posts. However, the problem with this type of post is the illusion of having a silver bullet in your gun. This is
not true as silver bullets do not exist.

Serverless is a powerful weapon but you need to be trained or the recoil could hurt you. This post would like to prevent the problem.

Commissions may be earned from some of the links above.

How Chaos Engineering Practices Will Help You Design Better Software

Mariano Calandra — Thu, 25 Feb 2021 06:16:43 +0000

Wind extinguishes a candle and energizes fire.

Likewise with randomness, uncertainty, chaos; you want to use them, not hide from them.

Thus begins the prologue to Antifragile by Nassim Nicholas Taleb, one of the most popular authors of recent years.

What does the randomness have to do with our work as engineers? What does chaos have to do with cloud computing? Much more than you can imagine and in this story, we will understand why.

Fig.1 – Antifragile — Nassim Nicholas Taleb

Generally, a cloud application is composed of various components: virtual machines, databases, load balancers and other services that by communicating with each other support our business. Complex and distributed systems which, as such, could suddenly fail.

The answer to this type of problem has often resulted in a greater number of tests; mostly end-to-end tests that stimulate all the layers of an application. A sort of black-box testing where, in front of an input A, an output B is expected. If the answer is C, somewhere in the system something went wrong.

In some cases, such tests are stimulated at regular intervals on production systems to verify them over a 24-hour period, but in case of a failure, we won’t know much about the error.
Even worse, this practice exposes us to another risk: the illusion of control. Each time a test is successfully completed, we become more and more convinced of the robustness of the system; day after day we become more and more proud of the excellent work done.

The Black Swan

A metaphor by Bertrand Russell, later adapted by the Taleb himself, tells the “great turkey problem”:

A turkey is fed for a thousand and more days; every day together with the other turkeys they takes pleasure in comfort of their life. Then comes Thanksgiving and being a turkey won’t have been cool at all.

This surprise represents what is called a Black Swan: an unexpected event, with catastrophic effects.

Fig.2 – Until 1697, when Cygnus atratus was discovered, no one thought black swans could exist. (photo Holger Detje from Pixabay)

The (fake) illusion of control forced the turkey to revise his beliefs about the comfort of his life, just as they were at their peak.
Likewise, repeated positive end-to-end tests could lead us to the equally fallacious conclusion that our systems are indeed foolproof.

This superficiality of judgment, to use a lexicon dear to Taleb, exposes us to the Black swan: the possibility that an unforeseen problem could ruin our plans for the weekend.

Possible examples of Black swans:

server’s shutdown;
database fail;
CPU overhead;
memory exhaustion;
disk-space exhaustion;
high network latencies;
misconfigurations;
insufficient permissions;

To protect your system from these and other issues, a cloud provider offers various possibilities. In AWS, to counter the sudden shutdown of a machine, the potentialities of the EC2 Auto Scaling service could be exploited; to mitigate the impact of a database fail, you could take advantage of Amazon RDS’s automatic failover mechanism, and so on.

These tricks will certainly make our application less fragile, but will they reduce the chance of a Black Swan?

Antifragile

By the term «fragile», in general, we mean an object that could be damaged – even irremediably – due to random events (e.g. a crystal glass that breaks after accidentally falling on the floor).

Fig. 3 – Copyright Elnur Amikishiyev

On the contrary, terms such as «robust» or «resistant» are used to define objects which, upon the occurrence of random events, maintain the exact same initial properties.
Randomness has made these objects neither better nor worse.

With the term «antifragile», however, Taleb refers to everything that benefits from randomness and stress factors. The muscles of our body, for example, benefit from the right amount of stress, as this is a prerequisite for their growth.

Returning to our systems, if everything we have done to counteract their fragility has ended with configuring the Auto Scaling feature, we will be robust but not yet antifragile; therefore still exposed to a Black Swan.

If you want to become antifragile, place yourself in the “love error” position.

Taleb offers us the main suggestion to avoid nasty surprises. To be antifragile, and reduce the chances of a Black Swan as much as possible, we have to crave for error.
But what if we are in a situation where our end-to-end tests keep running smoothly and the error just doesn’t come?

Chaos engineering

By «chaos engineering» we mean the practice of deliberately injecting an error into a system, in order to observe, in vivo, the consequences.

What would happen if, one of the production web servers, suddenly goes down?

The main advantage of this approach, compared to the more classic end-to-end test, comes from no longer having to depend on our assumptions. The impact of the mistake will be right before our eyes. By doing so, we will have the opportunity to highlight aspects of the system that we were not aware of: chain reactions, performance problems, metrics that escaped the monitoring tools and so on.

Knowing the weak points of the system is already a great start, as it forces us not to let our guard down; what we will have to aim for, however, will be the resolution of those weaknesses. This improvement will make systems a little more «antifragile».
The greater the error cases that we will be able to inject – and solve – the lower the chance of a Black Swan.

The process of chaos

The choice of the word «engineering» next to the word «chaos» might sound like an oxymoron, but it isn’t; indeed, it well represents the essence of the process underlying the practice itself. Just as a scientific experiment has its well-coded phases, the chaos engineering experiment has its own.

Definition of the steady-state

In this phase, we are going to make it clear what should be the capacity of the system when there are no errors. This step is crucial and it will be essential to have monitoring infrastructures that allow us to accurately collect the metrics useful to define it. System metrics (e.g. CPU, memory) are certainly useful, but it would be even more useful to get business metrics:

«Between 10am and 11am, an average of 100 orders per minute is handled»

Or:

«Between 8pm and 9pm the homepage is requested 1000 times»

Formulation of a hypothesis
Once this is done we will formulate a hypothesis; that is, we will try to imagine what the system behaviour might be following a specific error.

«What would happen if a webserver fails?»

Or:

«What if communication with the database suddenly had an extra 100ms latency?»

A useful exercise at this stage would be to ask each team member for answers to the above questions. This practice should not have the purpose of finding the first or last of the class but, simply, to show how, in some cases, the knowledge of the system can vary between members of the same team.

Another way to remind everyone to stay prepared.

Definition of a stop-condition

It will be crucial to understand when and how to stop the experiment.

The when can be manual, timed or dynamic. We will resort to manual blocking if we realize that the experiment is having unexpected consequences. Time, on the other hand, is the upper limit, that is the maximum time within which, for better or for worse, the experiment will have to end. Finally, a dynamic stop-condition will block the experiment if our monitoring tool signals an alarm situation (eg: the average of orders has fallen by 70% for more than five minutes).

How to stop the experiment is a bit more complex and depends on the available tool.

Run the experiment

Once this is done, we just have to launch our experiment and inject the errors we had foreseen when defining the hypotheses. Easy to say, a little less to do. Until recently, the practice of chaos engineering required good scripting skills to make the occurrence of the error programmatic.

This made chaos engineering less accessible to unstructured teams, reducing the practice to the prerogative of a bunch of large groups. Not surprisingly, some of the most famous chaos engineering scripts were those created within Netflix in the Simian Army project, such as chaos monkey: a script that randomly knocked down production machines.

Fig. 4 – The Netflix Simian Army logo.

Nowadays, the need for this type of practice is raising and advanced tools for chaos engineering are starting to become available. At re:Invent 2020, AWS unveiled Fault Injection Simulator (FIS) a fully-managed service for injecting errors into our systems.

System improvement

The most interesting work comes after the experiment. There we can learn more about our system by asking ourselves questions like:

how did our system behave?
the countermeasures (ex: autoscaling, failover, circuit-breaker) have managed the error?
Were there any unexpected errors in other parts of the system?
Were there any performance problems?
Was the error detected by our monitoring tools?
How long did it take to get restored?

The answers and any solutions to these questions will then be prioritized and applied as soon as possible. By doing this we will be a little safer from a Black Swan.

Chaos Engineering in production (?)

To take advantage of chaos engineering as much as possible, the experiments must be launched into production. Point.

However, this practice carries its own risks and thinking of starting directly from production would be a bit risky. Better to start with experiments in development scenarios, and then, as soon as we feel a little more confident and practical, move towards staging and, why not, production.

Conclusion

The conclusions to this article are obvious and can be summarized once again by quoting Taleb’s words: «Don’t be a turkey!».

That is, we have to avoid simplistically believing that, in the absence of errors for an extended period, we are safe from any risk. A Black Swan can always be on the prowl and show up as soon as we let our guard down.

Instead, we have to try to stress our system, injecting the most probable errors, observing its behaviour in search of any unpredictable behaviour. Only in this way will we be able to truly know our system and be a little more confident in its ability to withstand error and our ability to know how to manage it properly.

Fig. 5 – Photo by Andrew Gaines on Unsplash

In a 2011 talk, Jesse Robbins, a volunteer firefighter then hired at AWS with the title of Master of Disaster, reported the phrase they teach every firefighter on the first day of training school:

You don’t choose the moment, the moment chooses you.

You only choose how prepared you are when it does.

— Fire Chief Mike Burtch

Let’s never forget that.

Why do we need the JSON Web Token (JWT) in the modern web?

Mariano Calandra — Mon, 15 Feb 2021 09:21:19 +0000

Hold on tight: the HTTP protocol is terribly flawed and when it comes to user authentication this problem screams loudly.

For a long time we, as developers, fought with it: sometimes with good results, sometimes not, but we thought we were happy.
Unfortunately, the web moves fast and many of these solutions were getting old too quickly.

He who hesitates is lost…

Later on, a group of people realised that it was time to stop fighting with the “problem” and try to embrace it. The result of that epiphany is called JSON Web Token (JWT for short) and here we will try to tell its story…

Once upon a time

Suppose you have a REST API (e.g. GET /orders) and you want to restrict access to authorized users only.
In the most naïve approach, the API would ask for a username and password; then it will be searched in a database for whether those credentials really exist. We check for authenticity. Finally, it will be checked if the authenticated user is also authorized to perform that request. If both checks pass, the real API will be executed. It seems logical.

A problem of state

The HTTP protocol is *stateless, this means a new request (e.g. GET /order/42) won’t know anything about the previous one, **so* we need to reauthenticate for each new request (fig.1).

Fig. 1 — Due to the stateless nature of HTTP protocol, every new API request needs a complete authentication.

The traditional way of dealing with this is the use of *Server Side Sessions *(SSS). In this scenario, we first check for username and password; if they are authentic, the server will save a session id in memory and return it to the client. From now on, the client will just need to send its *session id *to be recognized (fig.2).

Fig. 2–Using SSS, we reduce the number of authentications towards the Credentials database.

This solution will fix a problem but it will create another one.
Probably bigger.

A problem of scale

In the IT world, time goes fast and a solution that yesterday was commonly used, might be outdated now. Server Side Sessions are one of these.

In the API era, our endpoints can face a huge amount of requests, so our infrastructures needs to scale. There are two types of scaling:

*vertical scaling – *scaling up your infrastructure merely means adding more resources to a server. This is an expensive solution with a low upper limit (i.e. the server’s maximum allocation of resources);
*horizontal scaling – *scaling out your infrastructure is simpler and more cost-effective as it only involves adding a new server behind a load balancer;

Now it’s seems pretty clear that the second approach will be far most beneficial; but let’s take a look at what may happen.

In the initial scenario, behind the load balancer, there’s just one server. When a client performs a request, using session id xyz, its record will surely be found in the server’s memory (fig.3).

So far, so good.

Fig. 3–One single server behind the load balancer. The session id of the request will be found in memory.

Now imagine that the above infrastructure needs to scale. A new server (i.e. Server 2:2) will be added behind the load balancer and this brand new server will handle the next request issued by xyz client…

Fig.4–A new server is behind the LB, it knows nothing about the previous session so the user won’t be recognized.

Unauthenticated! The brand new server has no xyz sessions in its memory, so the authentication process will fail. To fix this, we have three main workarounds that can be used:

*Synchronize sessions between server*s — tricky and error-prone;
Use an external in-memory database — good solution, but it will add another component to the infrastructure;

Third: embrace the stateless nature of HTTP and search for a better solution!

The better solution

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a way for transmitting information –like authentication and authorization facts– between two parties: an issuer and an audience. Communication is safe because each token issued is digitally signed, so the consumer can verify if the token is authentic or has been forged.

Each token is self-contained, this means it contains all information needed to allow or deny any given requests to an API. To understand how we can verify a token and how authorization happens, we need to take a step back and look into a JWT.

Anatomy of a JWT

A JSON Web Token is essentially a long encoded text string. This string is composed of three smaller parts, separated by a dot sign. These parts are:

the header;
a payload or body;
a signature;

Therefore, our tokens will look like this:

header.payload.signature

Header

The header section contains information about the token itself.

{
  "kid": "ywdoAL4WL...rV4InvRo=",
  "alg": "RS256"
}

The following JSON explains which algorithm has been used to sign the token (alg) and which is the key (kid) that we need to use to validate it. One moment of patience, please, we will look into this soon. :)

The JSON is finally encoded as Base64URL:

eyJraWQiOiJ -TRUNCATED- JTMjU2In0

Payload or body

The payload is the most important part of a JWT. It contains information (claims in JWT jargon) about the client:

{
  [...]
  "iss": "https://cognito-idp.eu-west-1.amazonaws.com/XXX",
  "name": "Mariano Calandra",
  "admin": false
}

The iss property is a registered claim, it represents the identity provider that issued the token — in this case, Amazon Cognito. Finally, we can add further claims based on our needs (e.g. admin claim).

The payload is then encoded as Base64URL:

eyJzdWIiOiJkZGU5N2Y0ZC0wNmQyLTQwZjEtYWJkNi0xZWRhODM1YzExM2UiLCJhdWQiOiI3c2Jzamh -TRUNCATED- hbnRfaWQiOiJ4cGVwcGVycy5jb20iLCJleHAiOjE1N jY4MzQwMDgsImlhdCI6MTU2NjgzMDQwOH0

Signature

The third part of the token is a hash that is computed following these steps:

join with a dot the encoded header and the encoded payload;
hash the result using the encryption algorithm specified in alg property of the header (in this case RS256) and a private key;
encode the result as Base64URL;

Here we can look at it as pseudo-code:

data = base64UrlEncode(header) + "." + base64UrlEncode(payload);
hash = RS256(data, private_key);
signature = base64UrlEncode(hash);

And here it is the computed signature:

POstGetfAytaZS82wHcjoTyoqhMyxXiWdR7Nn7A29DNSl0EiXLdwJ6xC6AfgZWF1bOsS_TuYI3OG85 -TRUNCATED- FfEbLxtF2pZS6YC1aSfLQxeNe8djT9YjpvRZA

Put everything together

Once we have the encoded header, the encoded payload and the encoded signature, we can join everything together simply by merging every piece with a dot:

eyJzdWIiOiJkZGU5N2Y0ZC0wNmQyLTQwZjEtYWJkNi0xZWRhODM1YzExM2UiLCJhdWQiOiI3c2Jzamh -TRUNCATED- hbnRfaWQiOiJ4cGVwcGVycy5jb20iLCJleHAiOjE1N jY4MzQwMDgsImlhdCI6MTU2NjgzMDQwOH0.eyJzdWIiOiJkZGU5N2Y0ZC0wNmQyLTQwZjEtYWJkNi0xZWRhODM1YzExM2UiLCJhdWQiOiI3c2Jzamh -TRUNCATED- hbnRfaWQiOiJ4cGVwcGVycy5jb20iLCJleHAiOjE1N jY4MzQwMDgsImlhdCI6MTU2NjgzMDQwOH0.POstGetfAytaZS82wHcjoTyoqhMyxXiWdR7Nn7A29DNSl0EiXLdwJ6xC6AfgZWF1bOsS_TuYI3OG85 -TRUNCATED- FfEbLxtF2pZS6YC1aSfLQxeNe8djT9YjpvRZA

Note: Even if the above token seems encrypted, it isn’t! Unlike RS256, Base64URL is not an encryption algorithm, so mind your payload!

JWT validation

Since the token is self-contained, we own all the information needed for its validation. For example, we know the token has been signed using RS256 (alg property of the header) and a private key. Now we need to know how to get the right public key to perform the validation. Yes, the public key!

Note: In asymmetric encryption, we all know that a public key is used to encrypt a message, whereas a private key is used to decrypt it.
In a signing algorithm, this process is completely switched! Here the message (the data in the pseudo-code above) is signed using the private key and the public key is used to verify that the signature is valid.

The iss property of the body represents the endpoint of the issuer (Amazon Cognito in our case, but there should be no great differences with other providers), copy that URI and prepend it to the string/.well-known/jwks.json. It should look something like:

https://cognito-idp.eu-west-1.amazonaws.com/XXX/.well-known/jwks.json

Following this URL, we will find a JSON:

{
  "keys": [
    {
      "alg": "RS256",
      "e": "AQAB",
      "kid": "ywdoAL4WL...rV4InvRo=",
      "kty": "RSA",
      "n": "m7uImGR -TRUNCATED AhaabmiCq5WMQ",
      "use": "sig"
    },
    {...}
  ]
}

In the keys array, search for the element that has the same kid of the token’s header. The properties e and n are the public exponent and modulus that compute the public key.

Once we get it, we can verify the signature. If it’s valid, we can be sure that the information contained in the token is trusted.

Note: The process of public key calculation or sign verification is not easy and is beyond the scope of this post.

A real case scenario

At the first access, a client needs to contact the *authentication server *(Amazon Cognito here, but Microsoft, Salesforce or any other provider should be pretty similar), sending username and password to it. If credentials are valid, a JWT token will be returned to the client that will use it to request an API (in this example Amazon API Gateway endpoint).

Fig.5 — The complete flow of a real case scenario.

In the above scenario (fig.5), API itself is the only responsible for token validation and it’s able to reject the request if the signature seems forged.

Going further

Suppose a client wants to invoke a protected API to delete an order (e.g. DELETE /order/42) and this action should be only performed by administrators.

With a JWT in place, this operation is hard as add a custom claim to the payload body (i.e. the admin: true claim of the example above). When invoked, the API will first verify the signature authenticity and afterwards, it’ll check if admin claim is true.

Summary

In this article, we have seen many things about JWT with the aim to provide a historical and conceptual perspective of the topic.
If you need a more hands-on guide here you can read how to protect APIs with JWT and API Gateway Lambda Authorizer.

That’s all for now but something still misses:

How do we configure Amazon Cognito to get a JWT token?
How do we configure Amazon Cognito to add a custom claim?

Don’t worry, we have room for answering this questions in a later story. For now, let’s summarise some key points:

HTTP protocol is stateless, that means a new request won’t know anything about the previous one;
Server Side Sessions was a solution to the statelessness of HTTP, but these, in the long run, were a threat to our scaling abilities;
JWT is self-contained, that means it contains every information needed to allow or deny any given requests to an API;
JWT is stateless by design, so we don’t have to fight with the stateless design of HTTP;
JWT is encoded, not encrypted have it in mind;

Disclaimer

Stateless nature of HTTP is clearly not a flaw. Just a provocation :)

If you liked this post, please support my work!

What Is Amazon Cognito User Pool and How Does It Differ From a Cognito Identity Pool

Mariano Calandra — Mon, 01 Feb 2021 10:06:24 +0000

Amazon Cognito is an AWS service that lets you easily add users’ management to web and mobile apps. It supports social identity providers, such as Facebook, Google and enterprise identity providers via SAML 2.0.

A powerful service.

At first, hard to understand.

One of the things that generate the biggest confusion is the fact that Amazon Cognito comes with two main components:

Amazon Cognito User Pools
Amazon Cognito Identity Pools (aka Federated Identities)

This is the first blocker because, in the common language, users and identities are almost the same things.
In this brief story, we will try to clarify real differences and what scenarios can be solved using one of these components or combining the two.

Cognito User Pool

According to the AWS official documentation:

A user pool is a user directory in Amazon Cognito. With a user pool, your users can sign in to your web or mobile app through Amazon Cognito […]

This means an anonymous user of our application (e.g. a mobile or a Single Page Application) can fill a registration form and then become a registered user. The chosen credentials (i.e. username and password) will be safely stored into Cognito User Pool.

In this case, Amazon Cognito acts as an Identity Provider (IdP).

When this registered user wants to log in, the User Pool will be used as the source of truth to assess the authenticity of provided credentials; if valid, a JSON Web Token (JWT) will be returned (click here, if you want to know more about JWT).

Fig. 1 – During a user’s login, Cognito User Pool will handle the credential’s verification process, if valid, a JWT will be issued. This token could be eventually used to invoke protected APIs.

Eventually, if we have a protected API (e.g. GET /orders/42) this token can be used to authenticate requests (fig.2) through the Authorization header.

If this API has been created using Amazon API Gateway, there’s the opportunity to easily protect it through the Cognito User Pool. In this scenario, API Gateway will ask Amazon Cognito User Pool to validate that token; if successful the backend Lambda function will be invoked.

Fig.2 – API Gateway can be integrated natively with Cognito User Pool to validate the provided JWT.

Easy like Sunday morning.

But what if our application needs to interact directly with DynamoDB (fig.3)?

Cognito Identity Pool

Usually, REST APIs are protected through the use of a token – e.g. a JSON Web Token (JWT) – and that’s why Amazon API Gateway with the help of Cognito User Pool supports this scenario natively.

Fig.3 – Sometimes your client application may want to access directly to an AWS service (e.g. DynamoDB) without the API Gateway as a proxy. Will the JWT still be useful?

Alas, the vast majority of AWS resources, doesn’t support a JWT as a means of authentication! For instance, if our application would read the order item 42 directly from DynamoDB, we need an IAM Role that has the permission to read data from the Orders table.

And here it comes Cognito Identity Pool:

Identity pools provide AWS credentials to grant your users access to other AWS services.

Here, “your users” are the users registered into our Cognito User Pool.

To enable users in your user pool to access AWS resources, you can configure an identity pool to exchange user pool tokens for AWS credentials.

To enable these users to access directly to DynamoDB and read the given order, we can’t use JWT straight; but we have to use Cognito Identity Pool to trade JWT with an access key and secret key (fig.4).

Fig.4

Each couple of keys has an IAM role associated with the right set of permission.

Here, thanks to the Identity Pool, Amazon Cognito acts as an Identity Broker.

Some caveats

In a simple scenario everything can be summarised in a general rule:

If our application needs to access an API Gateway endpoint then, Cognito User Pool is sufficient.

If our application needs to talk directly with an AWS service (DynamoDB, S3, …) we need Amazon Cognito Identity Pool too.

Unlikely, things are not necessarily black or white and real life has many nuances. For instance, our application could have users registered on a third-party Identity Provider and, in this case, we would use Cognito Identity Pool but not Cognito User Pool (more info in the Further reading section).

Conclusion

Even the most mundane things, if not well understood, will seem difficult. Amazon Cognito is no exception. I hope this story helps those who did not have a very clear understanding of the topic.