Serverless authentication
You've got a feature that only a few people should use. How do you keep it safe?
Authentication.
It's easy in theory: Save an identifier on the client, send with every request, check against a stored value on the server.
In practice, authentication is hard.
Where do you save the identifier? How does the client get it? What authentication scheme do you use? What goes on the server? How do you keep it secure? What if you need to run authenticated code without the user?
Authentication is a deep rabbit hole. In this chapter, we look at the basics and build 2 examples.
What is authentication
A typical authentication system deals with everything from user identity, to access control, authorization, and keeping your system secure.
It's a big job :)
Identity answers the "Who are you?" question. The most important aspect of authentication systems. Can be as simple as an honor-based input field.
Access control answers the "Can you access this system?" question. You ask for proof of identity (like a password) and unlock restricted parts of your app.
Authorization answers the "Which parts of the system can you use?" question. Two schemes are common: role-based and scope-based authorization. They specify which users can do what.
Security underlies your authentication system. Without security, you've got nothing.
Typical concerns include leaking authentication tokens, interception attacks, impersonating users, revoking access, how your data behaves, and whether you can identify a breach.
Factors of authentication
Proof of identity is key to good authentication.
something the user knows, something the user has, something the user is
Each authentication factor covers a different overlapping proof of identity. 2 factors is considered safe, 3 is best. Typical is 1 🙈
Knowledge factors include hidden pass phrases like passwords, PINs, and security questions. You know the answer and verify the user also knows.
Ownership factors include ID cards, token apps on your phone, physical tokens, and email inboxes. You ask the user to prove they have something only they should have.
Inference factors include biometric identifiers like fingerprints, DNA, hand-written signatures, and other markers that uniquely identify a person.
Credit card + PIN is 2-factor authentication. You own the card and know the PIN.
Username + password is 1-factor. You know the username and know the password.
Passwordless email/sms login is 2-factor. You know the username and own the email inbox. Proof by unique link or pin.
Role-based and scope-based authorization
The 2nd biggest job after access control is authorization. What can this user do?
Two flavors of authorization are common:
- role-based authorization depends on user types. Admins vs. paid users vs. freeloaders.
- scope-based authorization depends on fine-grained user properties. Enable subscriber dashboard or don't.
Technically they're the same – a user property. It's like utility vs. semantic classes in CSS. Debate until you're blue in the face then pick what feels right :)
Role-based authorization is perfect for small projects. You need admins and everyone else. Being an admin comes with inherent rights.
Scope-based authorization is perfect for large projects with granular needs. Yes you're an admin, but what kind of admin?
In practice you'll see that roles get clunky as your needs grow and scopes are tedious to use. Like when I had permission to configure CloudFront, but not to see what I'm doing. 🙃
At an organizational level you end up with roles that act as bags of scopes. Engineers get scopes x, y, z, admins can do so and so, and users get user things.
Build your own auth
In this section, you're going to build an auth system meant for API use. API auth is different from