Understanding OAuth..

For me, at the outset, OAuth seems to be a complex topic, and the acquired knowledge often seems to evaporate with time. To better understand OAuth, let's look at the need for it in the first place. As the internet exploded in the last decade or so, numerous applications were built to solve different problems for end-users. New and interesting use cases emerged that required user data to be shared across applications. For example, a software-as-a-service fitness application that manages users' daily workout routines as its core business requires access to users' calendar data, probably to better resolve conflicting meetings with their workout routine stored in a different application like Google Calendar.

Earlier, there were no standards in place to access such data. Often, applications like the fitness app in our example asked users to enter Google Calendar credentials within the fitness app, after adding disclaimers that they would only access the calendar data and add a few invites for the workout routine but nothing else.

As you can see, there are a lot of issues with this approach that can go wrong. Despite the pure intentions of the fitness application, the user's credentials can be compromised due to weak secure practices in storing the credentials (like storing them in plain text), excessive access beyond what is needed by the application, changes, or expiration in credentials causing application failures, and so on.

Genesis of OAuth to solve this delegated authorization problem:
With the above challenges, it's apparent that there is a need for a standard/protocol in place. The idea here is to substitute the user's credentials with a short-lived password called an access token with restricted access.

To ensure this token is provided to the fitness app, there needs to be a one-time registration with Google beforehand, by configuring a few values. So, in our example above, instead of asking the user to enter credentials for the Google Calendar API within the fitness app, the app redirects the user to Google's authorization server, where the user can enter their credentials, knowing it is the Google URL asking for the credentials. Now, Google sees that this request is different from the regular sign-in requests by the user, and it's being requested as part of an application (which was registered earlier) asking for an access token. Google then shares a short-lived access token, and the application can access the calendar API using the access token to accomplish its use case.

This is an oversimplification of what happens in different flows that are possible in OAuth 2.0. For a more detailed explanation, here is an excellent talk by Nate Barbettini, who does a great job of explaining this: _https://lnkd.in/gfYKWVQB