How HTTP authentication works

- [Instructor] Before we dig into how to add authentication and authorization to the API, it's important to first understand how authentication works over HTTP. The terms authentication and authorization are different, but closely related, and the differences can be confusing. As you'll see in a moment, we'll talk about the HTTP authorization header when we're really referring to authentication, which certainly doesn't help the confusion. When I refer to authentication in this chapter, I mean the process of verifying that the user is who they say they are. An example of this would be submitting your username and password to log in to a website.

This is different than authorization, which means checking whether a particular user or client has the permissions to do something in the system. An example in the Landon Hotel API would be that guests at the hotel have permission to see their own booking resources, but they can't see other guests' bookings. An administrator account, however, would be authorized to get any booking. As a rough rule of thumb, you can think of authentication as making sure someone is logged in and authorization as what they're allowed to do. So far, all the requests that we've made to our API have been unauthenticated requests.

When a client needs to make an authenticated request to a server, it'll include the authorization header on the request. Despite the confusing name, this header is really being used here for authentication, not authorization. The value of the authorization header consists of the name of an authentication scheme and a corresponding value. The value might be a username and password, an API key, a token, or some other value that the server can verify the client with. If the server understands the authentication scheme, it will parse the value and validate it. If validation fails, the server will respond with a 400 series error like 401 Unauthorized.

If validation succeeds, the request is considered authenticated and the server can continue processing the request. It's important to note that the authorization header is not a replacement for transport security. In fact, if the authorization header is sent over a plain HTTP connection, anyone can sniff the packets going over the wire and steal the authorization value, which means they can potentially start making requests as you. All of the authentication schemes we'll discuss in this chapter should always happen over an encrypted HTTPS connection. If you want a refresher on how this works, see the chapter on securing the API.

There are a few common authentication schemes that are used with the authorization header. The first and simplest is HTTP basic authentication. With basic auth, the client attaches a username and password to each outgoing authenticated request. The server checks the incoming credentials and validates the request if the credentials are good. Many APIs use basic auth and replace the username and password with an API key in secret. The downside of basic is that you're sending the raw credentials over the wire on every request, which can be extremely risky.

Because of this, HTTPS is mandatory if you're using basic auth. Another scheme that's common with APIs and web apps is bearer authentication. Instead of sending the password or API credentials on every request, the client first gets a token from the server. The token is then attached to requests to authenticate them. The token is only valid for a limited time, so eventually the client will need to go back to the server to get a fresh token. Digest authentication is a less common scheme that provides some extra security. With digest authentication, a hash is computed from the client's credentials and some other pieces of the request, like the headers, time stamp, request payload, et cetera.

This hash is sent in the authorization header, and the server tries to recompute the hash on the other side using the incoming request data. If the hash is matched, the server knows the request has not been tampered with. So which authentication scheme makes the most sense for a RESTful API? We'll compare the pros and cons in the next video.