To better understand OAuth, it’s helpful to know what problem it solves. OAuth is primarily used when an application wants to access a user's resources. For instance, a web app might need access to a user's Gmail account so the user doesn't have to create a new password when registering on a site. Or, the app might need access to Google Drive to save some data there.
In these cases, there are three parties involved: the application (called the client), the user, and the server that holds the user's resources.
Without OAuth, our application would need the user’s login and password for their Google account. This approach has several issues: it's insecure, and the owner of the login and password gets full access to all resources, without the ability to limit the access to just reading.
OAuth provides security and allows limited access.
OAuth works on redirects. A redirect happens when a server responds with a 302 or 307 status code and a Location header containing a URL. The browser understands this status code, reads the Location header, and automatically makes a new request to that URL.
So, the server can make the browser automatically send a new request through redirects.
When a user clicks "Register with Google" on our site, we redirect them to Google's site. After the user logs in successfully, Google redirects the user back to our site. These two redirects allow the user to temporarily go to Google to log in.
During these redirects, our application and Google’s server exchange information. Eventually, Google sends us a token we can use to make requests to their servers. The data is transferred through URLs during redirects.
There are several key concepts in this process:
1. Code and Access Token: We receive a code during redirects, which our application then exchanges for a token. Only after this exchange can we use the token to access the user's resources.
Why this complexity? The code and token are obtained differently. The code is passed in URLs during redirects. The token is passed when our backend communicates with Google’s backend. This method is more secure because when a browser makes a redirect, the URL used in the redirect is shown in the address bar. Any browser extension can read the data in the URL, and the URL might be accessible to CDN servers, remain in the browser history, or in HTTP server logs. So, many can see the URL with this code.
Backend-to-backend communication is safer with fewer intermediaries.
2. Refresh Token: The access token is issued for a certain period. The shorter the period, the safer it is. But to avoid making the user enter their login and password every time the token expires, Google issues a refresh token, which we can use to get a new access token. Due to constant updates, the access token isn’t frequently transmitted over the network, making it harder for someone to steal and use it. With these updates, the task of stealing the token becomes more difficult.