Authentication and Authorization - House keys vs. giving your neighbors a temporary combination to your garage. [The Web Explained: Part 8]

You may rapidly find yourself in a situation where you're going to want to afford some level of security and privacy to your users. You'd like them to be able to log in, manage their account, and choose their favorite cast member from the Mandalorian as a cute profile icon. To do this, we're going to need to lock down certain parts of your application and find some way to assert that random strangers on the internet are who they say they are.

🎟 Authorization vs. Authentication

Simply put, Authentication is the act of verifying who a user is, whereas Authorization is the verification of the user's right to access a specific resource or function. Beyond knowing who a random person from the internet is, it's also essential that you can verify they have the access privileges they claim to have, much like really checking over the ID of everyone's favorite underage hops connoisseur, McLovin (language warning, totally worth it).

🧠 Learn more about Authorization vs. Authentication:

---

> https://www.okta.com/identity-101/authentication-vs-authorization/

---

---

🔑 Basic Password Systems

The easiest thing to do is create a data store somewhere that has a list of user accounts and their respective passwords (encrypted, always!). It's as easy as 1-2-3...

1. A user enters their credentials on the login screen.
2. You encrypt the password and compare it to what you have stored.
3. If valid, log the user in. If not, redirect to login.

This may be perfectly fine for many simple use cases. Yet, eventually you will want to give the user, your customer, and their administrators a little more power regarding how access is granted, altered or revoked. In addition, wouldn't it be nice to have one single login for the myriad of things that you need to access? Luckily, the nerds thought about that too...

---

🎫 SSO

SSO (single sign-on) is a system allows a user to easily log in to any of several independent software systems with a single username and password. This allows the user to log in once and access various disparate services without having to login to each again. There are a few flavors of SSO, and it's not so much a discussion about which is better, but rather when each makes sense for your use case. We're getting pretty deep into the weeds here, so we'll keep it high-level to avoid too much brain overload.

---

💼 SAML: SSO Authentication for Enterprises

SAML (Security assertion markup language) is pretty typical to see in large corporate environments where your corporate login is utilized to access a suite of tools like Microsoft Office, Salesforce, Jira, etc.

With the average office worker switching applications 1,100 times a day, utilizing SAML could lead to real cost savings if you're having trouble getting buy-in to physically remove the alt + tab keys on every keyboard in your company.

🧠 Learn more about SAML:

---

> https://auth0.com/blog/how-saml-authentication-works/

---

> https://www.parallels.com/blogs/ras/saml-vs-oauth/

---

> https://labs.tadigital.com/index.php/2018/11/05/single-sign-on-with-saml-standards/

---

---

🛠 OAuth 2.0: Authorization for Applications

OAuth is an open standard that generates access tokens to give applications access to your data in other applications. Have you ever granted access to some app to see your Facebook friends or other details? You've used OAuth. Essentially, you gave permission for the two apps to communicate with each other on your behalf.

This is pretty neat. You were able allow the two separate apps to communicate without having to share your actual login with the requesting application. You just said, "this is ok" and the requesting application simply gets a token to use.

This means that if you no longer want that random app on your phone to see your Facebook information, you can revoke that token with the click of a button. This is like giving your neighbors a temporary code to the garage while you're away on vacation. When you get back from the beach, you can expire the code, and Tim isn't going to be borrowing any of your tools without your explicit permission again.

🧠 Learn more about OAuth 2.0:

---

https://auth0.com/intro-to-iam/what-is-oauth-2/

---

---

👨‍💻 OpenID Connect: SSO for Consumer Applications

While OAuth 2.0 is primarily used to grant applications the ability to share information, OIDC (OpenId Connect) focuses on granting users access to resources on the internet. Widely used for auth on customer websites and mobile apps, OIDC is actually built on top of the OAuth 2.0 protocols, so sometimes this leads to confusion.

If you've ever used your Google account to sign into something like Youtube, you've used OIDC. Using OIDC is like asking someone to vouch for you and say, "yeah, I know that guy, let him in, and don't give him any grief unless he starts really causing a ruckus again."

🎭 JWT

Where something like SAML uses XML to communicate, OIDC has been responsible for popularizing a data format called JWT (JSON Web Tokens, sometimes pronounced "JOT").

These JSON-based tokens contain information about the user, the claims and access they may have, and some cryptographic information intended to thwart manipulation of anything in the token. This prevents a user, for example, from claiming to be an admin when they aren't.

While the tokens may be stored on the user's machine and can be altered, when they are sent to the server with the request they are verified and any manipulation of the token will result in its rejection due to a mismatch of the cryptographic hash.

It's worth learning about the anatomy of a JWT, as it is becoming a crucial part of most authenticated web applications.

🧠 Learn more about OIDC:

---

> https://scotch.io/tutorials/the-anatomy-of-a-json-web-token

---

> https://goteleport.com/blog/how-oidc-authentication-works/

---

---

📨 Passwordless Login

Imagine that you've just put the finishing touches on an extensive home security system, complete with live video, remote monitoring, (safely) accessible firepower, and a siren that blares Fortunate Son to let any intruder know that you mean business. You tell the family goodnight and then proceed to sleep like a baby wrapped in a blanket of technological (and kinetic) security. You awaken with the morning's orange aura warming your face and walk downstairs to make yourself a cup of coffee, which is where your eyes play host to utter betrayal your brain cannot process.

Someone left the doors unlocked and unarmed your perfectly planned defenses, and now there's a guy named Roger casually eating a pint of ice cream on your couch and watching your TV.

As it turns out, while you slept, the family went out for a walk and disarmed everything. Despite their best efforts, they just couldn't figure out how to arm everything again, and your son accidentally left the basement door unlocked as well. He didn't even think to check the door because surely your house in suburbia is not a target, and besides...ya'll have nothing to hide.

While you had made the perfect system, it was just a little too complex for your users, and they didn't truly understand the consequences of their inaction.

This is just like many of the systems outlined above. They're pretty damn good at locking things down, but if your users use <KIDS_NAME>+<INCREMENTING_NUMBER> as their password for everything, they've basically left the front door wide open.

If we get real and acknowledge that most users don't give a flying shit about password security and that humans often choose convenience over long-term thinking, the paradigm seems ripe for a shift...

Enter Passwordless login...

Passwordless login is a mechanism that does not rely on asking for a username and password; but rather sending the user a one-time link to their (verified) email or short code to their (verified) mobile device that can be used as proof to log them in. This is every bit as secure as giving the user the ability to reset their password, and it could be argued that it's more secure because it meets the user where they are and potentially eliminates the chance of your users choosing another stupid password again.

There are a few providers for passwordless login that can get you up-and-running in minutes, so it's definitely worth checking out as you evaluate your authentication strategy.

🧠 Learn more about Passwordless login:

---

> https://magic.link/

---

> https://auth0.com/passwordless

---

> https://www.okta.com/passwordless-authentication/

---

> https://www.hypr.com/

---

> https://securityboulevard.com/2020/04/8-scary-statistics-about-the-password-reuse-problem/

---

---

🥜 Auth, in a Nutshell

We covered a number of ways to authenticate your users, and I can imagine this section being a little confusing and tricky. I know when I first started learning the differences between all of the various implementations, I often found myself cross-eyed and stricken with vertigo from following countless flow diagrams and reading about the finer details of obscure grant types.

For the most part, it should at least be clear which SSO strategy to deploy for the use-cases you have in mind. I really hope you dig deeper; because adding something like OIDC or Passwordless to your application can really reduce friction in signing up, giving your users a good sense of trust in the security of their data. Understanding the nuances and possibilities contained within will only serve to ensure your users are happy and getting to spend time doing things of value with your app, not creating yet another friggin' web account with vexatious password requirements.

---