📘 Premium Read: Access my best content on Medium member-only articles — deep dives into Java, Spring Boot, Microservices, backend architecture, interview preparation, career advice, and industry-standard best practices.
✅ Some premium posts are free to read — no account needed. Follow me on Medium to stay updated and support my writing.
🎓 Top 10 Udemy Courses (Huge Discount): Explore My Udemy Courses — Learn through real-time, project-based development.
▶️ Subscribe to My YouTube Channel (172K+ subscribers): Java Guides on YouTube
Hey everyone, welcome back.
In this guide, we’ll explore one of the most popular authentication flows used by secure web applications: the OAuth 2.0 Authorization Code Flow.
If you’ve ever logged in to a site using “Login with Facebook” or “Sign in with Google,” chances are this exact flow was used.
Let’s start by understanding what OAuth 2.0 is and who’s involved — then we’ll dive into the real-world flow step-by-step.
What is OAuth 2.0?
OAuth 2.0 is an open standard for authorization. It’s not about verifying who you are — that’s authentication — it’s about verifying what you’re allowed to access.
Think of OAuth 2.0 as a delegation protocol. It allows a user to give limited access to their resources on one site, without giving away their username and password.
For example, you can let Booking.com access your Facebook profile data — but you’re not handing Booking your Facebook credentials. OAuth makes that safe and possible.
Roles in OAuth 2.0 Flow
Now let’s quickly look at the four main players in an OAuth 2.0 flow.
Resource Owner
First is the Resource Owner — that’s the user. It’s their data we’re talking about, so they control the access.
Client
Second is the Client — this is the application requesting access to the user’s data. In our example, that’s Booking.com.
Authorization Server
Third is the Authorization Server—this is where the user logs in and authorizes access. It is Facebook’s secure login interface.
Resource Server
Finally, the Resource Server is where the user’s data actually lives. Facebook might separate its login system from its data access system, so sometimes the authorization server and resource server are different, and sometimes they’re the same.
OAuth 2.0 Authorization code flow
Now that you know the players, let’s walk through the full OAuth 2.0 authorization code flow — the most common and secure flow used by confidential web apps.
Step 1 — User Intention
Everything begins when a user visits a web app — in our example, Booking.com — and clicks “Login via Facebook.” The user is the Resource Owner here.
This action tells the client application — Booking.com — that the user wants to authenticate using Facebook.
Step 2 — Redirection to Authorization Server
Booking.com then redirects the user to the Authorization Server, which is Facebook in this case. The user is now no longer interacting with the client app directly. They’re being taken to Facebook’s secure authorization interface.
Step 3 — User Grants Permission
At this stage, Facebook shows the user a consent screen. This screen outlines what data Booking.com wants to access — like profile info or email address.
The user reviews and confirms the authorization. Once they grant permission, Facebook has the green light to proceed.
Step 4 — Authorization Code Returned
Now Facebook — acting as the Authorization Server — redirects the user back to Booking.com, but not empty-handed.
It sends back an Authorization Code via a pre-registered redirect URL. This code is short-lived and can be used only once.
So far, Booking.com still hasn’t received the user’s credentials. That’s an important part of OAuth’s security design.
Step 5 — Client Requests Token
With the authorization code in hand, Booking.com now makes a back-channel request to Facebook’s authorization server.
This request includes the authorization code, the Client ID, and the Client Secret — credentials known only to Booking.com and Facebook.
This step does not involve the user’s browser anymore. It’s a secure server-to-server call.
Step 6 — Access Token Issued
If everything checks out — the code is valid, the credentials are correct — Facebook responds with an Access Token.
This token represents the user’s authorization and can now be used to access the actual protected data.
Step 7 — Access Token Used
Now Booking.com presents this Access Token to the Resource Server — which again is Facebook’s server.
Booking.com might ask for user profile details, friends list, or email address, depending on what scopes were authorized earlier.
Step 8 — Protected Resources Shared
Finally, Facebook’s resource server checks the access token. If valid, it returns the requested protected data back to Booking.com — and the user is successfully logged in.
At no point did Booking.com ever see the user’s password. All access is securely managed through tokens.
This is why the Authorization Code Flow is the recommended approach for server-side applications — especially confidential ones like Booking.com.
Quick Recap
Let’s summarize the flow using the same diagram:
- The user initiates login via Facebook.
- The app redirects the user to Facebook.
- The user logs in and approves access.
- Facebook sends an authorization code back.
- The client exchanges the code for an access token.
- Facebook issues the token.
- The token is used to request user data.
- Facebook shares the data with the app.
Wrap-Up
And that’s the OAuth 2.0 Authorization Code Flow — one of the most secure ways to implement login and data sharing between applications.
Used by thousands of sites across the web, it keeps your users’ data safe and your app compliant with industry best practices.
Happy coding!
Comments
Post a Comment
Leave Comment