Understanding Authentication: A Simple Dive into OAuth 2.0

In this article, we'll explore how authentication works—from basic password-based login to modern, secure methods like OpenID Connect—through the lens of a simple library app. The source code can be found at https://github.com/niketansrane/auth101.

1. The library problem

Let's say you run a little library in your hometown and you want to keep track of:

• who borrowed which books,
• when the books were borrowed
• return due dates
• contact details like name and address.

And you have decided to build a small website to do so. For all future references, words library and website are used interchangeably.

In your library, a user's digital identity could be as simple his/her name, phone number and address. Whenever someone logs in your library, they should be able to see:

• all books they have borrowed
• when to return them back.

2. Shared Secrets

Now every time a user logs in, you will have to retrieve all the books which are borrowed by that particular user and display them on the page.

How would you make sure that only information for that particular user is shown and the user is actually the person he claims to be and not someone else?

The simplest approach is you(library) and each user can agree on a shared secret of some kind.

Each time user tries to log in, he presents the shared secret and the website will be like, "since you have the secret value only you and me could have known, I will let you in and here are the books that you have borrowed from the library." In this case the website authenticated the user.

Almost always the shared secret is what we call the password. In typical flow, a user signs up to your website using a combination of username and password. You do not store the plain password in your storage, because if you do so and your storage gets compromised, the attacker has access to passwords for all users. Instead you use a hash function to make it obscure.

Once the user signs up, every time a he tries to login to the library, you check if credentials match and if yes, allow him in.

This is called Password Based Authentication.

Implementation in Python using the bcrypt library.

import bcrypt

def hash_password(password: str) -> bytes:
    """
    Hash the plaintext password using a brypt with salt.
    """
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt())

def verify_password(password: str, hashed_pwd: bytes) -> bool:
    """
    Validate if the given password (after hashing) will match with `hashed`.
    """
    return bcrypt.checkpw(password.encode(), hashed_pwd)

# Example.py
password = "ilovebooks"
hashed_pwd = hash_password(password)
print(hashed_pwd) # outputs => b'$2b$12$mWaihxsvGxYNwzq4Ueozu.hgvjVC5dIKFX...'
print(verify_password("ilovebooks", hashed_pwd)) # outputs => True
print(verify_password("idonotlovebooks", hashed_pwd)) # outputs => False

3. Delegated/Federated Authentication

So far so good. Now let's say you have a friend who runs a startup and he wants all his employees to access your library. But he does not like the idea of each employee creating a separate account with new password. Instead, he wants users from his company @friendstartup.com to login using their existing credentials.

This is a classic case where a user can sign in at one place (friendsstartup.com) and then show proof of sign-in in another place and gain access. This is called federated authentication.

My front-end will now support another login option. sign in with friendsstartup.com.

If the user chooses that option, my auth middleware will redirect user to friendsstartup.com for authentication and say, "can you please authenticate the user for me and once you are done, please share his email and name with me".

(There are prerequisites you will have to do with friendsstartup.com beforehand but let's skip those for now.)

This is powered by the OpenID protocol. OpenID is just what the name suggest. Open + ID => Open (standard) protocol for identification.

So now instead of saving user name and password in your auth database, you will instead receive id information from friendsstartup.com saying that I have verified this user and his id is alias3@friendsstartup.com. You can then use this information to login the user and show his books.

So rather than managing the user credentials yourself, you delegate them to a trusted provider(friendstartup.com, or even Google/Microsoft etc.)

In this article, we explored how authentication starts with shared secrets and scales up to secure, federated login using OpenID Connect.

In the next article, I'll walk you through actual implementation code—how to set up password-based login and integrate OpenID in a FastAPI app step-by-step.

Stay tuned!