WHERE does 'auth' happen?
If you read any selection of API docs (Spotify, Pinterest and so on), there is a distinct change in the language used when trying to access protected APIs.
A flurry of tokens, ids, scopes, response types and more that can seem like a foreign language to the untrained eye.
This blog post started its journey with this video, Authentication: It’s Easier Than You Think, by Theo Browne.
When we talk about auth, we talk about things that aren't actually authentication. We talk a lot about different packages…contexts that contain piles of data that describe who a user is, but auth is two things…authentication and authorisation.
Theo went on to ask (and answer) the question, “WHERE does auth happen?.”
In trying to understand the question - and the answer, “on the server” - I sought out specifics of the mystery “server” in question.
As it turns out, (at least in the land of JavaScript driven, single-page applications) most of this information concerns requests that a client application will make to an OAuth server.
The keyword here is OAuth. OAuth is an open-source protocol that provides clients a "secure delegated access" to server resources (read: API) on behalf of a resource owner (read: user).
The OAuth server is a “role” (one of five involved in an ‘authorisation flow’) introduced in OAuth 2.0 to allow applications to access data from third party apps without the users sharing their password.
Knowing the foundations of OAuth, the terminology and core flows is an excellent way to demystify API authentication docs. For further information I'd recommend resources by Aaron Parecki.