the not so scary auth- cookies and tokens
Published: 2022-10-11 21:30:12

What the hell is “Auth” and why does everyone make it sound so scary and complex? There is definitely a lot to it but it doesn't have to make you shake in your boots. In our world, it applies to at least two terms; which are often used interchangeably but they are different things that serve specific purposes. There are also several ways to use them both; and pros and cons to each. Seeing as I'm pretty new to learning about this topic, I'm going to focus on it being an overview. Mostly, because this seems to be a topic that you can really go down the rabbit-hole with.

First and foremost, let's discuss what the word “auth” covers.  Authentication happens first; this is the login part of things, verifying that you are who you say you are. It is done several ways, the standard username and password, captcha tests and two factor authentication, or even biometric authentication. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4v65ufnedo7vg1coqahz.png)

After a user has been authenticated they can move on to authorization. When a user is authorized it allows them access to certain pieces of protected data or features of your app. An IRL example would be a subscription service, one I use all the time is the NewYorkTimes cooking app, or a subscription to a blog host like medium; you get to see a certain amount of things before you’re logged in, maybe you can even see a certain number of posts per month, or a specific promoted recipe. But at a certain point you have to show some credentials before you can go deeper into the castle, some users may only be able to see and read parts of your app, while others may have access to edit, create or delete their own content and then you have an even more select group of users that has access to all that and more. Authorization is where I start to feel a bit like Alice, about to drop into a deep rabbit hole. 

So from what I can tell so far, authorization falls into one of two varieties, cookie based, or token based; I say as far as I can tell, because like I said there seems to be a lot of change and specific ideology around this. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/udsqn92g5pd54nfo2wwf.png)

Let’s talk a little about cookies authorization to start. Cookies work with a web browser, so it’s not the best option for authorizing users on mobile devices. It is also stateful, so the authentication records should be stored in both the front and back end; the browser and server can essentially exchange validations as new protected data is exchanged. It starts with the browser sending the server the user's credentials, username and password for example. The server checks to see if you are legit. If you check out, the server then sends a cookie, or small piece of data proving that you are who you say you are, this piece of data is sent back to the browser with a users session id. A session is basically just the time the user is logged in. The browser then can make requests that only an authorized user has access to, like unlimited recipe views. The browser sends that request to the server with the cookie as a part of the HTTP request. The server will then take the cookie that the browser sent with the request and make sure it matches up to the session id, if it does the browser receives the requested data. 

Now lets explore token based authorization, it can be used in mobile apps, or web browsers and there are still some similarities and overlap in how authorization is done. The process starts in a similar way, a user provides credentials and if they are valid then a signed token is sent back to the browser. The server creates and validates tokens but does not store anything about them, a widely used standard for token based authorization is JWT, or JSON WebToken. Once a token is provided it needs to be stored somewhere on the client-side,(as opposed to cookies, which are stored on both the client-side and server-side) some common places in the client-side would be in local storage, or in session storage, or it can even be stored in a cookie. Once it is stored client-side, it is sent with every request to the server. The token based approach is stateless, so it doesn’t save any info about the user or a user session in the server or database.

This is how I started to understand a broad overview of what ‘auth’ is. I figured out it's not that scary, and why it's important, as well as some of the options for how to use it. And most importantly, I have learned that there is so much more that I can learn about, like OAuth, OpenId Connect, and Firebase Authentication. 

I found a lot of really great blogs that helped me piece this understanding together, heres some links. and the podcast Code Newbie [S13:E3](https://open.spotify.com/episode/7nbcbrDgZS39WWWPch5qQy) was what really got my interest piqued.
[Intro to Authentication & Authorization](https://dev.to/ryanmoragas/into-to-authentication-authorization-3122)
[Beginners Guide to Authentication Basics](https://levelup.gitconnected.com/beginners-guide-to-authentication-basics-ead786af0e77)
[Web Authentication: Cookies vs. Tokens](https://blog.bitsrc.io/web-authentication-cookies-vs-tokens-8e47d5a96d34)