This is the first article in a series about Authentication Strategies.

When a user visits a URL, they are kicking off a beautiful series of events to find a specific piece of content on the web. The server on which that content resides needs to know a few things about the user before it can send back the content. Anticipating this need, the browser sends a request with a set of 

If the requested content is protected, one way for a browser to authenticate the request is by sending one or more authentication headers. What those headers look like will depend on your authentication strategy, but most of the time you’ll need an 

Perhaps the simplest way to handle server-side authentication is with the 

 scheme with the Base64 encoded username/password provided as a single parameter.

When the user tries to access a protected resource, the server will look for the header and decode its credentials.

If the credentials are valid, the server sends a 200 response with the protected content. If not, it’s a 401.

 header back to the browser, which will trigger the browser’s built-in dialog to enter a username/password to be sent back in a follow-up request with the encoded credentials.

The server will again try to validate the credentials, and this cycle will continue until the user is validated or the server refuses a connection.

If you have a simple app where protected data doesn’t have major security needs, basic auth is 

. And it’s super straight forward and easy to set up.

only use basic auth with HTTPS connections.

 Credentials sent over an insecure HTTP connection can be easily snagged and decoded by sneaky bad actors.

Basic auth is … well, basic. There’s no fancy encryption used to lock down credentials before sending them over the wire, and your server has less fine-grained control over user sessions than it might with other techniques.

Even with a secure connection, simply passing around Base64 encoded credentials can be risky. In the even that a bad actor intercepts the request, decoding is a breeze for anyone doing a quick search for 

So if you’re looking for the most robust, secure or scalable authentication, you probably want to consider other options.

The Basic HTTP authentication strategy is the simplest way to handle server-side authentication. It works by including specific information in the HTTP headers.

Auth Headers and the Basic Authentication Strategy

Instead of sending the user’s credentials in each request, a common approach is to use tokens. A token is simply an encoded string originating from the server after a user successfully logs in. That token is used to authenticate the user until it is invalidated, at which point the user must login again for a new token.

The interesting thing about tokens is that the server doesn’t hold onto them, either in memory or a database, making means that token-based auth 

. We’ll cover the tradeoffs with stateless auth in a later post.

A token generally consists of three components: a 

 an HTTP header) contains information about the type of token being used, as well as how to interpret its signing signature (more on that below).

 consists of data related to the user’s auth session. What this data looks like depends on the type of token we’re working with.

So how the heck does your server know how to validate a token is authentic if it doesn’t store it somewhere? That’s where the 

A token’s signing signature is generated by an algorithm based on some data provided by the user’s client. The token can only be decoded and validated with a secret value kept safe on the server. So all the server needs is the user’s unique token in each request to handle authentication.

Similar to server sessions, token-based auth is more secure than basic auth because validated credentials are never passed between the server and client directly. This makes requests are less vulnerable if intercepted.

Because token-based auth is stateless, it is highly portable. Any server or service can validate a token based only on the data in the token itself and its secret. It’s a solid approach when used with cloud architecture or distributed systems where state is much more difficult to manage.

Imagine if you serve different pieces of data from multiple servers*.

Which server is responsible for handling sessions, and how do other servers validate them? This isn’t an issue with tokens, so long as all servers have a reference to the secret.

*Why would you serve your app data from different servers? Stay tuned to 

A big downside to token-based auth is that 

What if you need to suspend a user’s account? How will our server know the token is bad if it’s validating against a signature we’ve already validated? You can’t simply change the secret since it’s needed for all other validated tokens.

There are a number of solutions here, each one with its own tradeoffs. That’ll be covered another day, but the bottom line is 

With tokens you also need to worry about 

. If somehow your secret is leaked, hackers can easily gain access to sensitive user data. Nobody wants that (except for maybe hackers). You’ll need to rotate secrets often enough to minimize risk, but not so often that users have to constantly re-authenticate to use your app.

Instead of sending the user’s credentials in each request, a common approach is to use tokens. Tokens generally consist of a header, a payload, and a signature.

Authentication with Auth Tokens

, as the name implies, is a form of token-based authentication. Its mechanisms and format are defined by an open standard that 

 (though you probably need a few advanced degrees to understand the nitty gritty details).

At a high level JWT works pretty much the same as other tokens. The key difference is in how the token is generated.

A JWT’s header will contain the token type (

We won’t cover how algorithms work in this series (because it’s out of scope and because I’m certainly not a cryptographer!), but the 

 course will cover how we might determine the right algorithm to use in certain scenarios.

 the right to access for these privileges)

How long should authentication last? (token 

Arbitrary data can also be sent in the payload, though it’s generally good practice to keep the payload small to decrease latency.

The pros and cons of any token-based auth apply to JWTs. Because all JWTs are cryptographically signed, they are great for security. The slower the signing algorithm, the more secure the token.

However, there are a few common footguns that can undermine a JWT’s security. A user can send an unsigned JWT with the 

 signature, and if the recipient accepts the token without validating, a malicious actor can easily gain access.

Additionally, it’s important that the signature requires a secure secret. Many developer demos will use a simplistic secret value that is easier to guess. Think of your secrets like your own passwords: 

make them long and obscure, and you’ll be secure

JSON Web Tokens (JWT) are a form of token-based authentication. The key differences are in how the token is generated.

JSON Web Token (JWT) Authentication

Another commonly used token-based authentication, OAuth is an open-standard protocol that gives one application access to another. When you login to a SAAS application via Facebook or Google, the OAuth protocol is used to tell Facebook or Google that it should grant the app access to some of your data.

An OAuth transaction requires three components:

 is an identifier of the person or organization requesting authentication.

My name is Chance and I’d like to sign into Blurggl with data from my Google account.”

 is the app that requires data from another service. The consumer can specify what data it needs, and whether or not certain bits of data are optional.

Blurggl here! Let me go ask Google for permission to use that data!

Google here! Let me check to see if Chance allowed you to do that. If not, I might ask him real quick and get back to you.

If the provider grants access, data is exchanged, and the user will be redirected to the consumer, validated to use your app.

OAuth is useful because users don’t need to create another password to access your service, and it’s as secure as the provider’s auth service. You don’t need to pass credentials back and forth which reduces risk that your data is compromised. OAuth is easy for the developer 

The biggest risk with OAuth is that it makes phishing scams easier. Imagine one of your users gets an email:

To: chance@fronttoback.dev
From: joe@blurggl-admin-real.co

Hello Chance,
Joe from Blurggl here! We need you to update some of your data so we can send you 5 million dollars. Log into your account here and we’ll get the check sent out ASAP.

Your very real pal,
Joe from Blurggl

A less sophisticated user might think this email is legit, but fake Joe might then set up their own OAuth service that grants fake Blurggl access to all sorts of sensitive data. Sadly, Chance never gets 5 million dollars but does get a big mess to clean up.

Another risk is that your app asks for data it doesn’t really need. Now you’re on the hook for handling potentially sensitive user data. This is a huge problem if a breach does occur.

OAuth is a token-based auth protocol that gives one application access to another. It's commonly used to login to SAAS apps with Facebook or Google. 

Articles

Auth Headers and the Basic Authentication Strategy

Authentication with Auth Tokens

JSON Web Token (JWT) Authentication

Token-Based Authentication with OAuth