How OAuth Operates: A Simple Breakdown

Chapter 1(b) of Comprehensive Guide to SvelteKitAuth: Secure Authentication for SvelteKit Apps

In the previous article, we explored what SvelteKitAuth is all about. One keyword that we frequently mentioned was "OAuth" authentication. But what exactly is OAuth?

If I were to explain OAuth to a 5 years old:

Imagine you have a box full of toys and you want to share them with your friend. But you don't want to just give them the whole box, because there might be some toys you don't want them to play with yet.

This is kind of like how websites work sometimes. They have information that they want to share with other websites, but they don't want to give them full access to everything.

OAuth is like a special way of sharing. Here's how it works:

  1. You ask your friend's parent: You tell your friend's parent (like a website's login) that you want to play with some of their child's toys (like the website's information).

  2. The parent asks your friend: The parent asks their child (the website asks the user) if it's okay for you to play with some of their toys (access some information).

  3. Your friend gives a special key: If your friend says yes, they give you a special key (like an authorization code) that lets you open a small box of toys (access a specific part of the information).

  4. You show the key to get the toys: You take that key back to the parent (the website sends the code back to a special server) and show it to them.

  5. The parent gives you the small box: The parent sees the key and knows it's okay, so they give you a small box of toys to play with (the website gives the special key to access the specific information you requested).

This way, your friend (the website) gets to control what you can play with (what information you can access), and their parent (the login system) makes sure it's okay.

A little more technical explanation of previous version:

OAuth works behind the scenes when you use a website or app to sign in with another account, like signing into Facebook with your Google account. Here's a simplified breakdown:

The Players:

  • You (the Resource Owner): The person using the website or app.

  • Your Main Account (the Client): The account you want to use to sign in (like Google).

  • The Website/App (the Resource Server): The website or app you're trying to access.

  • Login Service (the Authorization Server): The service handling the login process (like Google in this case).

The Flow:

  1. Website asks to Sign In: The website or app asks you to sign in with your main account.

  2. Choose Account & Permissions: You choose your main account (like Google) and see what information the website wants to access (like your name and email).

  3. Login to Main Account: You log in to your main account if needed.

  4. Permission Decision: You decide to allow or deny the website access to your information.

  5. Code Sent Back (if allowed): If you allow, your main account sends a special code back to the website.

  6. Website Exchanges Code for Token: The website sends the code back to the login service to get a special token.

  7. Website Access Granted: The login service verifies the code and sends a token back to the website. This token acts like a key that lets the website access your information securely.

  8. Website Gets Your Information: The website uses the token to get your information from your main account, without needing your password.


  • Security: You don't share your main account password with the website.

  • Convenience: You can sign in easily without creating a new account for every website.

  • Control: You control what information the website can access.

This is a basic explanation, and OAuth can be more complex depending on the situation. But hopefully, this gives you a general idea of how it works!

OAuth with PKCE

OAuth 2.0 with PKCE (Proof Key for Code Exchange) is an extra secure version of the regular OAuth flow we talked about earlier. It's kind of like adding a special lock to the code exchange process. Here's how it works:

  1. App Makes Secret Key: Imagine the app you're using makes up a super secret message (the code verifier) like a fun codeword only they know.

  2. Secret Key Gets Disguised: The app scrambles this codeword into something unrecognizable (the code challenge). This disguised code is like the secret key hidden inside a puzzle box.

  3. Login Request with Puzzle: The app sends the disguised code (code challenge) to the login service along with your request to sign in.

  4. Login and Permission: You log in to your main account and decide if the app can access your information.

  5. Authorization Code Sent: If you say yes, the login service sends a special code (authorization code) back to the app.

  6. App Reveals Secret Key: The app now reveals the original secret message (code verifier) it created earlier.

  7. Checking the Puzzle: The login service checks if the unscrambled code (code verifier) matches the disguised code (code challenge) it received before.

  8. Token Granted (if match): If the codes match, it proves the app is who it says it is. Then, the login service gives the app a special token to access your information.


Regular OAuth flow might send the authorization code openly, which could be risky if someone peeked at it. PKCE adds a layer of security because only the real app that created the secret message can solve the puzzle and get the token.

Think of it like this:

  • The secret message (code verifier) is like a special key you keep hidden.

  • The disguised code (code challenge) is like a secret message someone else can see, but they can't figure out the real key from it.

  • Matching the codes proves the app has the real key and is who it claims to be.

Understanding OAuth and its enhanced version with PKCE is crucial for implementing secure authentication in modern web applications. OAuth provides a robust framework for delegating access without sharing passwords, ensuring both security and convenience for users. By incorporating PKCE, the security of the OAuth flow is further strengthened, making it resilient against interception attacks. In the next article, we will delve into the practical aspects of configuring the SvelteKitAuth authentication library with SvelteKit, enabling you to implement these concepts effectively in your applications. Stay tuned for a step-by-step guide to secure your SvelteKit apps with SvelteKitAuth.


Did you find this article valuable?

Support Aakash Goplani by becoming a sponsor. Any amount is appreciated!