How Does OAuth 2.0 Work? [with diagrams and examples]

OAuth is an open industry standard authorization protocol that enables applications to obtain limited access to user accounts without giving away any passwords. For example, I'm sure you've seen sign-in requests like this when trying to log into an application that allows you to authenticate with a different provider instead of creating a brand new account. In this case, we're trying to sign in using the Google provider. What we're doing here by successfully signing in is we're telling these apps, " I grant you permission to access my account" or "a portion of my account". Notice in this image, Google tells us exactly what information this app will have access to. In this case, it's the name, email, language preferences, and profile picture. Signing in via OAuth has some major advantages. In the event that the applications we're signing into suffers a data breach, our Google password in this context remains safe because OAuth doesn't share passwords but instead uses authorization tokens to prove identities. In addition, OAuth allows us to leverage other platforms where users most likely already have accounts created to authenticate and authorize new users. In our tiny house application, we're going to use Google OAuth to authenticate and sign in our users. OAuth between different providers behave very similar to one another. And though Google OAuth differs slightly depending on the application making the request, that is to say whether it's a web server application, client-side application, installed apps, etc., they all follow a very similar pattern. We'll go through the steps of how Google OAuth will be used in our application. In our context, OAuth includes the following roles. The resource owner or that is to say the user, this is the person that signs in and grants our app access to their accounts. There's the app or our app. Once the user grants us access to their accounts, we, that is to say, tiny house, can make API calls to Google servers on behalf of the user. For example, we perhaps could add an item to their Google calendar, send an email on their behalf, etc. And finally, there's the authorization and resource server. This is the server that holds the data and provides the APIs. In our case, this is Google. With the roles identified, let's dive into how the flow will behave. The first step in the process is redirecting our user to Google to log in. Google handles the user authentication, session selection, and user consent. Once logged in, Google will return an authorization code to our client application. From our client, we'll pass this code to our node server application. Once our server receives the code, it will make another request to Google using the code to get the user's access token. With the user's access token, we've obtained access and can use the token to interact with Google APIs to act on behalf of the user. In our application, we'll use the access token to interact with Google's people API to get the user's name, email address, and image to store in our database. Here's the flow we've just shown being summarized in a UML sequence diagram from Google's developer documentation. Sequence diagrams, or otherwise known as UML sequence diagrams, show how items in a system or code interact with one another and in more detail show the interactions in the sequence of events that occur. The user first requests a token, which takes the user to the login and consent screen. From there, an authorization code is returned. A request is then made to Google servers with the authorization code to retrieve the access token. With the access token available, the app is now able to make requests to Google APIs. We'll get a clear understanding of this as we begin to introduce a dysfunction ality into our application. [BLANK_AUDIO]