Why FileFortress Never Sees Your Google Drive Tokens (And Why That Matters)

When you connect Google Drive to most cloud management tools, you hand the tool an access token. The tool stores it. The tool uses it. You trust the tool. That's the deal — and it's a deal most people accept without thinking twice.

With FileFortress, we decided that deal wasn't good enough. So we built something different: Bring Your Own OAuth. You supply your own Client ID and Client Secret. The authorization flow happens entirely in your browser, between you and Google (or Microsoft). FileFortress never touches the resulting tokens.

The Old Way: What Happens to Your Token

When you run filefortress remotes add gdrive, FileFortress uses its own registered Google OAuth application. You click "Allow" in your browser, Google hands back an access token and a refresh token, and those tokens get stored in your local encrypted database.

That sounds fine — and in practice, it mostly is. But there are a few things worth thinking about:

• FileFortress's app credentials are shared across all users. The permissions granted are determined by what FileFortress registered with Google, not what you actually need.
• You're trusting the app's scope choices. If FileFortress registered for read-write access, that's what you're granting — even if you only want read-only.
• The initial token exchange passes through the authorization flow tied to FileFortress's Client ID. The token itself is stored locally, but the OAuth app is still ours, not yours.

For most users, this is perfectly acceptable. But for users who care deeply about privacy and control — and we think that's most of our users — it's worth doing better.

The New Way: Bring Your Own OAuth

The remotes add oauth command works differently. Instead of using FileFortress's registered app, you create your own OAuth application in Google Cloud Console (or Azure for OneDrive). You get your own Client ID and Client Secret. You run the command, provide those credentials, and authorize in your browser.

Here's what FileFortress sees during that process: nothing. The token exchange happens between your browser and Google. The resulting tokens are stored in your local encrypted database, tied to your app credentials — not ours.

At no point in that flow does a FileFortress server receive your access token or refresh token. The entire process is local.

Why It Matters for Privacy and Security

You might be thinking: "FileFortress already stores everything locally. Why does this matter?" It's a fair question. Here's the answer:

Your App, Your Audit Trail

When you use your own OAuth app, Google's audit log shows your app accessing your Drive — not a third-party tool. You can see exactly what's happening in Google Cloud Console. You can revoke access at any time from Google's security settings, independently of FileFortress.

No Shared App Limits

Google's Drive API has rate limits per OAuth application. When many users share the same app credentials, those limits are shared too. With your own Client ID, you have your own quota — completely independent of other FileFortress users.

Zero Trust in the Middle

Privacy-first architecture means minimizing the number of parties who could see your data, even if they don't. With BYO-OAuth, FileFortress is not in the trust chain for your cloud credentials at all. Your tokens exist only between you, Google, and your local machine.

Full Permission Control: Your Scopes, Your Rules

This is where BYO-OAuth becomes genuinely powerful for advanced users.

When you create your own Google Cloud OAuth app, you choose exactly which API scopes to request. Need read-only access? Set https://www.googleapis.com/auth/drive.readonly. Want full access including the ability to create, modify, and delete files? Add the write scope. Need access to a specific folder only? There's a scope for that too.

With FileFortress's shared app, you get whatever scopes we registered. With your own app, you decide. This matters in a few specific scenarios:

• Security-conscious users who want to grant the minimum permissions necessary — read-only is enough for indexing and search.
• Power users who want full write access to manage files directly through future FileFortress features, without restrictions.
• Enterprise or team environments where IT policy requires that only approved, internally-registered apps can access company Drive accounts.
• Developers who want to inspect and control exactly what their tools are doing with their data.

Getting Started in 5 Minutes

The interactive setup walks you through everything, but here's the quick version:

# Start the interactive OAuth setup
filefortress remotes add oauth

# Or specify everything upfront (non-interactive)
filefortress remotes add oauth \
  --provider google-drive \
  --name "My Google Drive" \
  --client-id YOUR_CLIENT_ID \
  --client-secret YOUR_CLIENT_SECRET

The command will prompt you for your provider (Google Drive, OneDrive, or others), your Client ID and Secret, and a friendly name for the remote. Then it opens your browser for the standard OAuth consent screen — the same one you've seen a hundred times. Authorize, come back to the terminal, and you're done.

What This Means for the gdrive and onedrive Commands

The remotes add gdrive and remotes add onedrive commands are now deprecated. They still work — we're not breaking anything today — but they will be retired in a future release.

The reason is straightforward: remotes add oauth does everything they do, plus it gives you full credential ownership. There's no reason to keep two separate paths for the same providers when one of them is strictly better for privacy.

As we add support for more OAuth-based providers in the future — Dropbox, Box, and others — they will all go through remotes add oauth. One command, any provider, your credentials.

The Bigger Picture

FileFortress has always been built on a simple principle: your files are yours, and the tools you use to manage them shouldn't need to be trusted with more access than absolutely necessary. BYO-OAuth is the next step in that direction.

We don't want to be in the trust chain for your cloud credentials. We want to be a tool you use — not a service you depend on for access. That's the difference, and it's why we built this.

Learn More

• remotes Command Reference — Full documentation for remotes add oauth
• Your Cloud Provider Can Read Your Files — Why client-side encryption matters
• Complete Guide to Cloud Storage Privacy — Understanding provider privacy practices