In this video, Nate will discuss how to think about authentication for a REST API, and which approaches are best.
- [Instructor] In the previous video we looked at some common HTTP authentication schemes. Which scheme makes the most sense for our restful API depends on a few factors The primary question you should consider when deciding on an authentication scheme for your restful API is: Who or what is the target audience? And what credentials will they use to authenticate with your API? If you're building an API service that will be used by other developers, you'll most likely want to issue API keys for your service. This also applies if you're building an API that will primarily be used for machine to machine or service to service communication.
For this scenario, you could consider using basic authentication if you're not too worried about security. A more secure choice would be the OpenID Connect client credentials flow, where API key and secret are exchanged for a bearer token. On the other hand, if you're designing an API that will be consumed by an end user application, like a single page app or a native mobile app, you'll probably be prompting users for a username and password to log-in to your application. A good choice here would be the OpenID Connect resource owner password flow, where the username and password are exchanged for a bearer token.
The SPA or mobile app would then attach that token to outgoing requests to authenticate the user with your API. If your API security needs are high, you could use a form of Digest authentication in either scenario instead. This is more secure, but harder to implement on both the client and the server. An example of a developer oriented API that uses Digest authentication are the Amazon Web Services APIs. The API that we've been building in this course for Landon Hotels is intended to power web and mobile apps. Because of this we'll use the OpenID Connect resource owner password flow.
The server will allow a client to exchange a users credentials for a bearer token, which will be used to authenticate subsequent requests. The resource owner password flow is a form of token authentication. This flow might sound complicated, but don't let that intimidate you. It only has two steps. First, the client sends the users credentials, usually a username and password, to a token route on the server. If the credentials are good, the server creates an access token and sends it back to the client. The token is just some string value that the server can validate later.
Now the client can use that access token instead of the raw credentials to make authenticated requests to the API. The token is placed in the authorization header with the bearer scheme. The OpenID Connect client credentials flow is very similar except a client would exchange and API key and secret instead of a username and password for a token. It's also possible to split up the duties of generating the token and serving resources. In this scenario, the client first gets a token from an authorization server, and then uses that token to access resources on a resource server.
The OpenID Connect spec provides a lot of flexibility for modeling this and even more complicated scenarios. For the Landon Hotel API, we'll take a simple approach. The authorization server and the resource server will be combined in a single application. These past two videos should give you a high level understanding of how HTTP authentication works and how to choose the right authentication scheme for your API. Authentication is a complex topic, and the security space evolves quickly. So I'd recommend doing some research of your own to understand the trade offs and use cases of each authentication scheme.
For a more detailed exploration of software security, I'd recommend another course in our library, Developing Secure Software. Alright, let's get started adding application security and token authentication to the Landon Hotel API.
- 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