WIP WIP WIP WIP
As mentioned in the interlude, a goal of mine this year is to build the Lukebox, a modern take of the jukebox. At its core, the Lukebox is really a music recommendation system; two basic features will be a playlist generator based on natural-language user input as a song vibe checker that’s based on genre similarity and community input. Before we can dive into the fun AI stuff, we have to build the foundation of the project first.
API integrations are a centerpiece of many products nowadays. They enable secure access to massive amounts of proprietary data and enable innovation across every industry. For the Lukebox, we care about music data, playlists, songs, user listening history, etc., and the company with the best API for that kind of data is Spotify! There are, however, a bunch of questions that need to be answered before one say they’ve properly integrated an external API into their project – security, rate limiting, and more. Let’s get to it.
The Oauth2.0 Authorization Protocol
There are a few industry standards for public API security. Depending on the company and the type of data they hold, external developers will usually have two options: API keys or Oauth2 access tokens. In most cases, API keys are issued by the owner of the data or resources and used by the developer. The developer passes the keys into the company’s SDK or attaches the keys to an REST authorization header. This method of authorization is more straightforward to most developers and is offered by many SaaS companies and enterprises.
Oauth2, on the other hand, is an authorization protocol that enables an application (Client) to access resources that is hosted by another server (Resource Owner) on behalf of a user (usually called Resource Server). The most common example of an oauth integration is Google’s oauth that enables a user to create an account and login into a random website via their Google account. Implementing the full protocol requires a few steps as shown in the following image:
At the end of the workflow, the implementer will receive a user access token (typically a JWT) and can use that token to make secure request to the resource owner (the holder of data and provider of token). To learn more about the specifics of Oauth2.0, feel free to visit the following links:
You can go quite deep with oauth, pkce, device code, etc, but the point of this article is provide an example on how these integrations are done in a real-world setting. Let’s focus on that because its more practical and useful for the average developer.
What happens in Production?
WIP
Cover Photo: shameless plug of my most followed playlist
