OAuth Article
Uploaded by
sangpalishaOAuth Article
Uploaded by
sangpalishaBehind the Scenes of ‘Login with Google’: Understanding OAuth 2.
0
Isha Sangpal
4 min read
This blog breaks down the OAuth 2.0 framework using a real-world example. Learn how
secure login works when you use options like “Continue with Google,” and explore the
behind-the-scenes interaction between the user, the client application, and the OAuth
service provider.
Whenever you come across “login with social media” option, it’s OAuth. OAuth 2.0 is the
most commonly used framework. That’s why it becomes a n attractive target for hackers.
Let’s dive in to understand how it is implemented and integrated into applications.
For example, imagine you are signing up on a website called xyz. Instead of creating a
username and password, it gives an option tocontinue with Google.
What’s happening behind the scenes?
When user clicks “Continue with Google”, the xyz website will redirect to Google’
authorization page. The user will enter their Google password directly on Google’s secure
page, note that the user is not entering Google password into the xyz app. Now, user grants
access by clicking “Allow”. Google sends back a token (not a password) to the xyz website,
which acts like a temporary permission slip. Xyz website sends the token to Google to fetch
only the allowed info. Xyz website now knows who you are and creates user account.
Let’s see how it works. There are three distinct entities between which a series of
interactions takes place.
1. Client application: the website/app which wants to access the user’s data.
2. Resource owner: the user
3. OAuth service provider: It provides support for the interaction between the client and the
resource owner. It controls the user’s data and access to it.
Moving on to the Grant types. A grant type defines the flow of OAuth or the sequence of
steps that are involved in the process. Let’s look at two main types:
1. Authorization code grant type:
The flow of events is similar as previously described. When a user accepts to grant the
access, the client application is granted an authorization code. The exchange of this code
takes place between the client application and the OAuth service to receive an access token
to make the API calls for fetching the relevant data. All these communication happens
server-to-server over a secure channel, invisible to end-users. This secure channel is
established once the user signs up using OAuth. A client_secret also gets generated which
the client application uses to authenticate itself before beginning server-to-server
communication.
Let’s explore the steps involved in this.
1. Authorization request: The client application sends a request to OAuth service’s
/authorization endpoint. This request looks like this.
GET /authorization?client_id=12345&redirect_uri=https://client-
app.com/callback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3
c24 HTTP/1.1 Host: oauth-authorization-server.com
client_id : unique identifier of the client application
redirect_uri : the URI to which the user’s browser should be redirected when sending the
authorization code to the client application. This is also known as the “callback URI” or
“callback endpoint”. Many OAuth attacks are based on exploiting flaws in the validation of
this parameter.
response_type : it defines what type of response the client application is expecting, for
example, in this case, the value should be code.
scope : subset of user’s data the client application wants to fetch
state : unique, unguessable value, which is tied to the current session of the client
application. The OAuth service should return the same value in the response along with the
authorization code.
2. User login and consent: After the initial request of authorization, the user is redirected to
the login page of the OAuth service provider, for example, Google, Github etc. Now, based
on the scope, he is prompted to access the data, where they can choose whether or not to
consent to this access. This process takes place only once when signing up an account.
3. Authorization code grant: If the user consents to the requested data, it redirects to the
/callback endpoint specified in redirect_uri. The resulting GET request would contain a code
like this:
GET /callback?code=j4b2d3d4f5f6g5h7&state=ae13d489bd00e3c24 HTTP/1.1 Host: client-
app.com
4. Access token request: The client application has the code, now it needs to exchange it for
an access token. To do this, it sends it server-to-server POST request to OAuth’s /token
endpoint. The request occurs over a secure channel and cannot be intercepted by an
attacker.
POST /token HTTP/1.1 Host: oauth-authorization-server.com …
client_id=12345&client_secret=SECRET&redirect_uri=https://client-
app.com/callback&grant_type=authorization_code&code=j4b2d3d4f5f6g5h7
client_secret : a unique code set when the client application was registered with the OAuth
service
grant_type : it specifies the grant type which the client application wants to use. In this case,
authorization_code.
5. Access token grant: The OAuth service validates the access token request and, if
successful, the server responds with the requested data based on the scope.
6. API call: Now the client application has the access token, it can fetch the user’s authorized
data. To do this, it makes an API call to the OAuth service’s /userinfo endpoint. The token is
then submitted in the Authorization: Bearer header to prove that the client application has
permission to access this data.
GET /userinfo HTTP/1.1 Host: oauth-resource-server.com Authorization: Bearer
z0y9x8w7v6u5
7. Resource grant: The resource server should verify that the token is valid and belongs to
the current client application. If this is as expected, it will respond by sending the requested
resource based on the scope.
{ "username":"johndoe", "email":"[email protected]", … }
2. Implicit grant type
This flow is similar to the one above, but with a few differences. Instead of first obtaining the
authorization code and then exchanging it for an access token, the client application receives
the access token immediately after the user gives their consent. However, this method is less
secure.
Conclusion:
OAuth 2.0 offers a secure way for applications to access user data without handling
passwords directly. While it improves user experience, its implementation must be done
with care, especially around parameters like redirect_uri and state, to prevent vulnerabilities
like token leakage, CSRF, or open redirect attacks.
Understanding OAuth helps both developers and security researchers recognize how
sensitive data is shared and protected across platforms. Whether you’re building apps or
testing them, having a clear view of this flow is essential in today’s interconnected web.
