Learn how HTTP authentication and the Authorize works to authenticate client requests.
- [Narrator] Before we dig in to 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 Landing Hotel API would be that guests at the hotel have permission to see their own booking resources but they can't see other guest's 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 Basic authentication. With Basic auth the clients 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 and 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, timestamp, request payload, etc.
This hash is sent in the authorization header and the server tries to recompute the same hash on the other side using their incoming request data. 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's match the server knows the request has not been tampered with. So which authentication scheme makes the most sense for our restful API? We'll compare the pros and cons in our next video.
- REST vs. RPC
- Using HTTP methods (aka verbs)
- Returning JSON
- Creating a new API project
- Building a root controller
- Routing to controllers with templates
- Requiring HTTPS for security
- Creating resources and data models
- Returning data and resources from a controller
- Representing links (HREFs)
- Representing collections
- Sorting and searching collections
- Creating forms
- Caching and compression
- Authentication and authorization for RESTful APIs