Why Do I Need Google OAuth?

Managing email attachments at scale is harder than it sounds.

One of my friends Abhijeet Shinde recently ran into a real-world problem:
his Gmail inbox had thousands of emails, and finding specific documents or attachments became almost impossible. Search was slow, filters were messy, and downloading everything manually was not an option.

That sparked an idea:

What if we could authenticate with Gmail once and automatically download the attachments we need?

That’s where Google OAuth comes in.

The Core Idea

The goal of this project is simple:

• Authenticate a user using Google OAuth

• Access their Gmail

• Download attachments automatically

• Do not store any email content for privacy

This is not a data analytics system.
It’s a secure file retrieval tool.

The Big Constraint: No Database

I intentionally avoided using a database.

Why?

• Databases add cost

• They add complexity

• They require maintenance

• And this project does not need to store user data long-term

We are not storing:

• Emails

• Attachments

• Metadata

We only need to store:

• Authentication credentials

That’s it.

So using MySQL, PostgreSQL, or even SQLite would be overkill.

The Real Problem: Where Do We Store Credentials?

Google OAuth gives us:

• Access tokens

• Refresh tokens

• Client secrets

We need to store them securely.

But without a database.

The Solution: keyring

Python provides a fantastic module called keyring.

keyring stores credentials inside the OS credential manager:

• Windows Credential Vault

• macOS Keychain

• Linux Secret Service

These stores are:

• Encrypted

• Protected by the operating system

• Not readable by other applications

This makes keyring:

• Secure

• Lightweight

• Perfect for our use case

Instead of building our own vault, we let the OS handle security.

Authentication Flow

Here’s how the system works.

1. Create Google OAuth Credentials

From Google Cloud Console:

• Create a project

• Enable Gmail API

• Create OAuth credentials

• Select Web Application

• Add a redirect URL for Flask

2. User Runs gmail-auth

When the user runs:

gmail-auth

A Flask server starts.

The user is redirected to Google:

• They log in

• Grant Gmail access

Google then sends a callback to our Flask app.

3. Store Credentials Securely

From the callback:

• We receive OAuth tokens

• We store them in keyring

No database
No plaintext files
No risk

4. Track Login State with session.txt

To avoid forcing users to log in every time, we create:

session.txt

This file contains:

• The logged-in user’s email address

On startup:

• If session.txt exists → user is already authenticated

• If not → we trigger OAuth again

This gives us session management without a database.

Downloading Attachments

Once authenticated, the user runs:

gmail_download

This command:

• Loads credentials from keyring

• Connects to Gmail API

• Finds messages with attachments

• Downloads them to a chosen folder

At no point do we store:

• Email bodies

• Message content

• File contents in a database

Files are downloaded, then forgotten.

The Flask Shutdown Problem

One challenge I ran into was automatically stopping the Flask server after authentication.

I tried:

• Killing the thread

• Shutting down from inside the route

• Running Flask in a separate process

Every attempt resulted in:

• Internal Server Error

• Frozen processes

• In one case, even requiring a system restart

So for now:

The Flask server stays running until the user manually stops it.

If someone has a clean solution for this, feel free to submit a PR on the repository.

Why Google OAuth Was Necessary

We use Google OAuth because:

• Gmail does not allow username/password login

• OAuth is:

  • Secure

  • Revocable

  • Permission-based

• It lets users:

  • Grant access

  • Revoke access anytime

  • Keep their password private

It is the only safe and scalable way to access Gmail.

Since you have all the attachments you can just run organize command and organize that. Simple , easy and time efficient.

What’s Next?

In the next blog, we will cover:

• Adding a GUI

• Proper separation of concerns

• Making this tool usable by non-technical users

Feel free to add suggestions !

Github repo : https://github.com/VivekPrajapati-Git/setfile