Day 38 (week 8) — Securing APIs with HTTP Basic Auth

Eric Abell
Sep 7, 2017 · 3 min read

Basic Auth has been around since 1996 and provides a super-simple way of securing HTTP requests between server and client. Today, we took a look at one way to provide API access to clients.

APIs can provide clients with access to a number of different resources on the web. Companies like Google, Amazon, Spotify, and Twitter all offer some level of API access to services like maps, music, and searching for tweets. There are a number of ways that these services provide security against unauthorized access. OAuth2 is currently the favorite, I think. A great page describing the details of OAuth2 is located here. In that model, a client first requests some level of access from a provider along with credentials previously arranged between the two parties. Usually this takes the form of something like your Google username and password, for example. After your credentials have been checked, you are granted a token and this token is sent with each new HTTP request and is a way of confirming you are who you say you are and that you have access the resource being requested.

I have done a number of project so far that have made use of Passport’s OAuth2 implementation. My social media app, Gabble, uses Google’s OAuth2 to sign users into the site. My word-guessing-game uses Twitter to authenticate and even lets you send a tweet after every correct word guess.

OAuth2 is complicated, and I think there is an argument for HTTP Basic Auth. In fact, this article lays out a pretty convincing argument. In HTTP Basic Auth, every request is accompanied by a Base-64 encoded version of an API key ID and password. That, in combination with SSL to encrypt the transmitted data, provides for an easy way to give users access to an API.

Today’s daily project was another CRUD application. This time we made an activity tracking app. The user can create any number of activities to track such as walking, running, biking, etc. and the API supports endpoints for recording data and making modification to that data. My version used a single MongoDB collection, although I suppose I could have used Postgres.

I documented the API endpoints and put comments to explain what example requests and responses looked like. Here’s a short excerpt from my Github README

1. GET	/activities	Show a list of all activities I am tracking, and links to their individual pages

Response Example:
"status": "success",
"data": [
"name": "walking",
"url": "http://localhost:3000/activities/walking"
"name": "running",
"url": "http://localhost:3000/activities/running"
"name": "biking",
"url": "http://localhost:3000/activities/biking"

The rest of the endpoints all appear here, on the Github repo.

Last, we got the new weekly project today which is a flashcard app. Users can create decks of cards, like you would in making a set of flashcards to study a subject. They can edit the cards, delete cards, move them between decks, etc. Having already built so many of these CRUD applications already, I feel pretty confident I can build this one. Right now, I’m just thinking about some extra little features that I can add to my app that will make it unique. Not sure what that will look like yet, but I’m sure I can come up with something in the next couple of days.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store