DEV Community: Andrea Roveroni

What are tokens and cookies in web authentication. Webauth Wizardry pt 1

Andrea Roveroni — Mon, 25 Mar 2024 16:58:16 +0000

Why this post

Searching for answers when dealing with web authentication can be challenging.

I researched this topic some time ago, and one thing I noticed is that there are a lot of useful resources and informations, but they're spread across Stackoverflow answers, blog posts, online documentation, Reddit posts, and so on.

Some posts compare bearer token VS cookies, some other explain how cookies might be more secure than tokens, some others go into session authentication, others deal with cookie attributes and CORS and so on. This requires you to jump from page to page and might lead to lose some useful informations regarding security practices or caveats, just because you did not read that Stackoverflow answer that for some reason is not marked as the correct one!

What I think is missing is a guide that starts from the beginning, explains what are cookies and what are their pros, while also considering some cons and difficulties when implementing them (CORS? Third party cookies? Partitioned what?).

So this is the first post of a serie that I called "Webauth Wizardry", that I hope will help other developers to understand and build a system that provides authentication via http cookies.
In general, I'll try to explain things as I went throught them, by trying solutions and finding which one has the most advantages (at least in my opinion), and to note down what disadvantages you might have with cookies, and eventually some solutions.

This serie will cover the following topics:

Brief comparison of bearer token VS cookie auth
Cookie fundamentals: lifetime, attributes, sending rules
Basic web authentication: how to authenticate users and keep them authenticated
Sign in with email/pw: I'll start with a brief explanation, but this topic might be expanded later
Sign in with OpenID Connect: Build on top of Oauth2, OIDC allows an application to authenticate users via third party services (called providers) like Sign in with Google. This topic has some key consideration and caveats, especially regarding requests coming from different origin and some difficulties that will happen when managing our cookies

"I like your funny words magic man"

Since we're programmers and we like code, I published two repository on my Github account:

The finished Webauth Wizardry code, consisting in a main part under src folder, along with a testing setup. I also published this as an npm package, in case someone wants to reuse it (some work is still needed)
A FE application, something as minimal as possible to demonstrate how to integrate all of this (and also how unobtrusive the cookie solution is on FE)

Blue pill or red pill?

First thing first, let's state something that is not always clear:
Tokens and cookies serve different purposes and they're not mutually exclusive

Questions like "Do I need to use tokens or cookies in my application?" might be misleading:

Tokens represent someone

Tokens are strings that represent a user (or an application) in some way. They might be just an identifier that corresponds to some user data saved on DB (like a mapping token => user), or they might contain that same data themselves as encoded JSON web tokens (jwts). A signin mechanism is applied when the jwt is created (aka issued) to ensure that the token cannot be modified by someone else (or at least, without invalidating the sign and thus invalidating the token).

Since this token identifies a user and grants him permission to access protected resources, this is called an Access Token (AT).

A never expiring AT is not a good idea:

You want to control if a user is still allowed to access a resource, for example after logout of when banning a user
Someone stealing your AT might be able to operate on your behalf forever on that application

For these reasons, an AT is usually short-lived (expiration might be set even after 10 minutes), and is paired with a so-called Refresh Token (RT).

Refresh tokens do not directly identify a user, but rather allow to exchange an expired (or expiring) AT with a new one. This operation is called "token refresh", and when succeded returns both a new AT and a new RT, invalidating the provided ones. This also means that RT are single use only.

Access Token might be passed by Authorization Bearer or Cookie

Now we need a way to pass the AT (and RT if needed) back and forth from our BE and FE.

We can use:

Authorization: Bearer MY_TOKEN HTTP header
Custom cookie

Which one to use? They both have pros and cons:

Authorization bearer are more flexible than cookies, as that they can be passed without much browser restrictions. Also, they can be set only on request that actually need them. On the other hand, they must be manually handled by the FE, which needs to keep track of both AT and RT, place the AT on the header on every request, handle manually refreshing the token before it expires, and save those tokens somewhere. In addition, since they're available to client side Javascript, they might be stolen by an attacker that manages to execute some custom code on the victim's browser.
Cookies are more "transparent" to client, meaning that when handled correctly, they cannot be accessed client side, so their entire handling occurs on BE. On the other hand, browsers enforce more strict policies on cookies, they're sent on every request (even if not needed) and they're subsceptible to other forms of attacks, like CSRF. Thus they require a precise configuration to be used correctly for authentication purposes.

Session cookies

The combination of simple (non encoded) tokens and cookies might be called the "session authentication", or "session cookies". This is sometimes confused with simple cookies, but as seen before, cookies does not exclude jwt tokens.

Session cookies are just cookies containing a token that identifies the user. The user's data is then recovered from the token on the server side, which might store data in-memory or on a fast DB, for example Redis might be a good option.

I'll take the red pill

After considering all the possibilities, I choose to go with jwt tokens, to prevent retrieving user info from a db on every request, and cookies instead of Bearer Token, in order to eliminate all possible handling from the FE.

Let's see how deep does the rabbit hole go.

Ending considerations

Feel free to comment for any question, error correction, or just to say hi. Also, you're welcome to visit my Github profile and open some issues or pr!
This is one of my first posts, hope you liked it, and thanks for reading.

Other resources (not sponsored :))

See this Stackoverflow Answer
Also this Stackoverflow Question

Used in this article

Cover image designed by Freepik
Morpheus's choice image generated with Imgflip

Playing Bad Apple! by throwing Javascript errors

Andrea Roveroni — Tue, 19 Mar 2024 20:44:21 +0000

Inspired by all those beautiful videos playing Bad Apple! on, well, literally everything, I started thinking about contributing to the effort.
But were to play Bad Apple on? After some time I got the idea! Playing Bad Apple on a Node process (or multiple processes as I explain later), not by using random console.log, but rather by throwing errors and letting them display the stack trace on the terminal.

So there it is:

Bad Apple but it's Javascript errors

Bad Apple video played on terminal.

Note: if you want to follow along with the code, please check my repository on Github, and if you enjoyed this small project, consider leaving a star (no pressure I Promise 😄✌️. ~~Ok that joke was terrible~~).
You can also check out this video I recorded.

Let's start

Each frame is a NodeJS process that tries to execute some bugged functions, throwing an Error. The stack trace is printed on the console, resulting in a single frame. By spawning multiple processes on different scripts, the complete Bad Apple video can be rendered.

How it works

When an Error is thrown, Node prints its stack trace on stderr, which normally is the console.
For example, this is a stack trace consisting of just one function call:

$ node
> function myBuggedFunction() { return null.toString()}
> myBuggedFunction()

Uncaught TypeError: Cannot read properties of null (reading 'toString')
    at myBuggedFunction (REPL10:1:42)

We can nest it to create a stack trace with two rows:

> function myBuggedFunction2() { return myBuggedFunction()}
> myBuggedFunction2()

Uncaught TypeError: Cannot read properties of null (reading 'toString')
    at myBuggedFunction (REPL1:1:42)
    at myBuggedFunction2 (REPL2:1:38)

By correctly naming each function, we can print some ASCII art on it:

> function ____$____(){return null.toString()}
> function ___$$$___() {____$____()};
> function __$$$$$__() {___$$$___()};
> function _$$$$$$$_() {__$$$$$__()};
> 
> _$$$$$$$_()
Uncaught TypeError: Cannot read properties of null (reading 'toString')
    at ____$____ (REPL1:1:34)
    at ___$$$___ (REPL2:1:23)
    at __$$$$$__ (REPL3:1:23)
    at _$$$$$$$_ (REPL4:1:23)

The only adjustment needed is to change the maximum stack size that Node has to keep, in order to print all the rows needed:

// Allows to keep and print 50 function calls in the stack trace
Error.stackTraceLimit = 50;

The main.js process loads all bmp files, and for each of them writes the corresponding js file consisting in a function for each image row,
It then spawns a child process via fork for each frame, piping its stderr to the console. It handles all the timings and clears the console between each frame

From bmp to error stack trace

Assuming we already have a decoded bmp file (representing a single frame), what we need is to generate some code that, when runned by Node, creates a stack trace that appears like the bmp frame and then throws an error (see example above).

So we need to name each function like the corresponding row in the bitmap.
For this, there are some constraints regarding which characters can be used as function names. I decided to go with the dollar sign $ for white pixels, and underscores _ for black ones. In order to have unique function names even when generating identical rows, a suffix is added to each function name.

So each row is converted like so:

function_name = <row_encoding>__<row_index>

After all js scripts have been generated, the main process spawns multiple subprocesses (one for each script). Since spawning takes some time, childrens are created in advance and put in a queue. Each child then waits for a message from the parent process before calling the bugged functions chain. With the right timing, the parent process sends the start message to each child, resulting in the corresponding error thrown and frame printed onto the console.

Resolution VS fps

You can customize both the video resolution and framerate when using ffmpeg.

To customize the video resolution, change the scale=W:H property.
To customize the framerate, you need to adjust both the -r VALUE property and the target fps when calling the runAll() function. The first value changes the number of frames generated by ffmpeg, while the second one changes the frequency of which child processes are executed. You need to set both to the same value to keep the video at 1x speed.

Increasing resolution also increases the size of the buffer to print on console for each frame. Writing on the console takes some time, so when settings high resolution and high framerate, it might happen that the next frame starts before the previous one has been fully printed. This causes the console to clear in the middle of a frame print, causing some visual flickering on screen. The best solution would be delaying the next frame until the first one has been completedly printed, thus decreasing the video framerate, hovewer I didn't manage to find a reliable way to tell if the stderr buffer is completely empty and written onto the console, so for now you need manually decrease the fps if you experience flickering.

With my hardware, I found that a 50x50 resolution works well with 20 fps video, which is 1000ms / 20frames/s = 50ms between each frame. Lower resolutions (30x30 or 20x20) work good at 30 and even 60fps.

From .mp4 to .bmp (optimization needed)

Converting from mp4 to bmp is done via ffmpeg. Since each pixel is only black or white, I tried to generate bitmaps with less bits-per-pixel bpp as possible, like -pix_fmt monow that uses a single bit (allowing to represent just black or white for each pixel), or -pix_fmt gray that uses 8 bits (allowing for 0-255 colors for each pixel). Unfortunately, those bitmaps where generated with some sort of compression or encoding alghorytm which I didn't manage to decode, and I didn't want to use any kind of external library to help me.

So I switched to -pix_fmt rgb0, that uses one byte for each color channel (rgb, but not alpha) of a pixel. This pixel format it's not compressed (althought bitmap format spec says it might be) so I managed to make it work, but now I need to reserve 24 bits for storing just a single black or white pixel! This is surely something that can be optimized.