Security has always been an important factor in web development and data transfer. In today’s blog I take a look into one method of API (application programming interface) authentication. I’ve gathered a bunch of great resources. It is also noted to make a distinction between authentication and authorization. What is authentication and what is authorization?
Authentication is when you prove an identity.
Authorization is when you prove a right to access
On the internet an API can provide tons of private/sensitive data and many different methods have been developed to facilitate the authentication and authorization of the user.
Like the original OAuth, OAuth 2.0 provides users with the ability to grant third-party access to web resources without sharing a password. Updated features available in OAuth 2.0 include new flows, simplified signatures and short-lived tokens with long-lived authorizations.
In simpler terms OAuth 2.0 is an authentication/authorization protocol that allows us to use information that we have access to from other websites without having to share our password. The less places our login and password is online the more secure or password is.
Originally OAuth 2.0 just provided authorization but with OpenID Connect it also adds an id_token to the OAuth code flow providing authentication alongside the access token that provides authorization for an API. These tokens can be JWTs (JSON Web Tokens). However some companies have developed their own OpenID-like systems like Facebook with Facebook connect. Google OAuth uses OpenID Connect.
Basic OAuth 2.0 Code Flow
This example diagram created by Soham currently depicts a less secure code flow that doesn’t involve using the consumer server to handle the access token. Handling the access token on the server side is much more secure since it’s not available in the browser for man-in-the-middle attacks and etc.
Description of the code flow can also be found here.
Many big name sites have adopted OAuth like Facebook, Google and Twitter. Oauth 2.0 is conducted over SSL (secure sockets layer) for extra protection.
A great overview of OAuth 2.0 is depicted in the video below.
Nate Barbettini does a great breakdown on this general flow of information.
He makes a distinction that OAuth has different kinds of flows and tradeoffs. One particular case is if you are just using a frontend to receive the access token and id token. This method is less secure but doesn’t utilize an extra backend.
Here is also an article on implementing Githubs OAuth2 API with Node.
There are also different grant types to get authorization that should be kept in mind. This will determine how your code flow will be written. Like whether you have a server to handle the exchange of the auth code with the access token which involves the use of a secret for more security.
If you are using a Single Page Application where the entire source code is available in the browser than it isn’t needed to use a secret.
It should be noted that some configuration is needed with the authorization server like ClientId, secret, domain and allowable callback URLs in order to implement OAuth.
Before you can begin the OAuth process, you must first register a new app with the service. When registering a new app, you usually register basic information such as application name, website, a logo, etc. In addition, you must register a redirect URI to be used for redirecting users to for web server, browser-based, or mobile apps.
Aaron Parecki’s article goes in depth on the different grant types and how they should be approached.