All Access
Everyone is familiar with logging into apps. It’s a process that’s been around since the dawn of personal computing. It’s the most basic and recognizable security check we go through routinely with our apps, and yet there’s quite a lot that goes into securely logging in a user as well as securing their navigation experience.
Modern web usage is a conversational relationship between three kinds of entities: users (like you), clients (websites and apps), and servers (where data is stored). Each entity needs to communicate and interact with the others in some way but they all need their own kinds of security to protect themselves and the other entities involved.
If you’re in web development, you’ve probably encountered lots of terminology related to security, and if you’re like me, it can get overwhelming keeping track of what they all mean; so, I’m going to go over some of the most common terms and concepts that come up.
Identification — this is the process of creating unique relationships between data and associating them accordingly. Database are indexed with primary keys and foreign keys to accomplish this. When you log into something using a username and password, your username identifies which data the server should fetch for you. This is why new users are almost universally required to make unique usernames when they sign up for things. Which leads to our next term…
Validation — the process of ensuring inputs into a form are sensible in order to prevent all sorts of problems that might happen behind the scenes. If you get an error because your username isn’t unique or doesn’t have enough special characters etc it’s because your inputs aren’t passing validations. Validation can be implemented numerous ways on both the front and backend.
Encryption — the process of obscuring the readability of data by converting it with ciphers. Often, secure data, such as a password or payment information, has the opportunity to be seen as it travels between entities, sometimes out of necessity but also potentially from maliciousness. As a precaution, apps and servers will encrypt such data making it functionally unreadable. When you make an account for an app, your password will need to be saved into a database so that you can be recognized, but your password will be stored in an encrypted form so that it’s unreadable. You wouldn’t be expected to develop your own encryption technique for an app. There’s lots of installable tools that will encrypt data for you.
Authentication — the process of verifying that someone is who they claim to be. If we go back to our login example, your username is used to identify who you are, but it’s your password thats meant to authenticate who you are. A password represents one of the simplest forms of authentication but many apps opt to add additional layers to the process. If you’ve ever had to verify your account by clicking a link in an email, or by entering a code that was texted to you, then you participated in multi-layer authentication.
Authorization — the process of granting access to varying levels of data based on your authenticated identity. Not only does this term sound a lot like the previous one, but the term ‘auth’ is used quite frequently, so it makes it easy to mix these terms up. And the terms are certainly related, too.
A common analogy to explain the two concepts is gaining access to a festival. If authentication is the process of checking that your ID matches the name on the ticket, then authorization is the issuing of a pass that grants you access to parts of the venue.
It might not be obvious to the user, but the process of navigating an app often involves repeatedly making requests to a server for protected resources. A normal user shouldn’t be able to inadvertently navigate to administrative information or another users information. To prevent this, servers are continuously authenticating the users identity as they fulfill requests. But even if the user logs in at a landing page, how does the server know that its the same authenticated user still as they navigate to different pages. You can have them log in repeatedly, or you can grant them a “pass” that travels with them during their navigation, which leads us to our next concept.
Cookies, Sessions, and JSON Web Tokens (JWT)— I put these concepts together because they are closely related in regards to the authorization process (implementing the “pass”). Note that these concepts have uses outside of implementing security features, but I won’t be discussing them here.
Going back to our festival pass analogy, one way to grant continued access to protected resources is to have the client or browser keep track of an authenticated IDand pass this around from view to view as the user navigates this. There’s several ways to implement this, but its commonly done using some combination of cookies, sessions, and JWT. They all represent ways to move data client-side.
Cookies — You ought to be familiar with the term, cookies. Many websites have a separate pop-up that asks that you enable cookies. That’s because they crucial part of storing user data client-side to enable a smooth experience. Cookies are key-value pairs of data that can be sent along http requests and stored in a browser. Information such as user ID can be relayed back in forth to servers with cookies to maintain your access as you navigate the client.
Sessions — Sessions are a security feature built off of cookies. Servers create and locally store files for a session, which has an ID that corresponds to a user ID. They issue this session ID to the client, instead of directly passing along user information, however it accomplishes a similar function. Sessions will also expire when the user closes the browser. They also can’t be tampered with on client side, and therefore are considered more secure than cookies.
JSON Web Tokens (JWT) —these are vehicles for transferring user authentication as well. They contain headers, a payload, and a signature. The payload will contain claims of authentication such as name and admin status, and the signature is used to verify the authenticity of the token itself.
OAuth — the last thing I want to cover is OAuth. This term refers to a protocol thats followed when authorization is being granted between apps. If you ever signed in to an app using Google then you’ve experienced OAuth protocol. It’s embodied in a pop-up that shows up to request your permission for certain access from another app.
The process is meant to bring transparency to the user that permission is being requested from another app, and to make explicit the scope of those permissions. This procedure builds off concepts like authorization tokens such as JWT to prevent the need for you to have to share your passwords from different accounts.
I hope you found this overview of terms helpful. Web security is a very complicated subject with entire industries built around it, but hopefully this glossary of terms will help you make sense of the concepts in your own experience with web development. Happy coding!
