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 app credentials, the authorization happens entirely in your browser between you and Google (or Microsoft), and FileFortress never touches the resulting tokens.

The Old Way: What Happens to Your Token

Historically, filefortress remotes add gdrive used FileFortress's own registered Google OAuth application. You clicked "Allow" in your browser, Google handed back an access token and a refresh token, and those tokens were stored in your local encrypted database. That command no longer connects anything — Google Drive is Bring-Your-Own only. The trade-offs it involved are worth understanding, because they are the reason it went away:

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. You create your own OAuth application in Google Cloud Console (or Azure for OneDrive) and get your own credentials — a Client ID and Secret for Google, a Client ID alone for Microsoft. You run the command, provide them, 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 gdrive \
  --name "My Google Drive" \
  --client-id YOUR_CLIENT_ID \
  --client-secret YOUR_CLIENT_SECRET

The command prints the setup steps for your provider, then prompts for the provider, your credentials, and a friendly name. Google asks for a Client ID and a Client Secret; OneDrive asks only for a Client ID — a Microsoft desktop app issues no secret, and the sign-in is protected by PKCE instead. Then it opens your browser for the standard consent screen. Authorize, come back to the terminal, and you're done.

What This Means for the gdrive and onedrive Commands

This is where the story diverged by provider, and the honest answer is different for each.

OneDrive kept its command, and it got better. remotes add onedrive now signs you in with a single browser visit using an app we registered — but the exchange happens on a loopback listener on your own machine, protected by PKCE, and the connection then renews its own access directly with Microsoft. No FileFortress server is in the token path at any point. That is the same privacy property Bring-Your-Own gives you, without asking you to register anything, so it is the recommended way to connect OneDrive. Bring-Your-Own remains available if you want to control the exact scopes.

Google Drive went the other way: Bring-Your-Own is now the only option. remotes add gdrive no longer connects anything and points you at remotes add oauth --provider gdrive instead.

The reason is Google's, not ours. Whole-Drive access is a restricted scope, which means an app offering it to the public needs Google's verification plus an annual third-party security assessment. Our application was not granted that verification, and an unverified app shows every user a warning screen and is capped at 100 accounts. Rather than keep a path we could not stand behind, we retired it — the same direction rclone is taking for the same reason.

As we add support for more OAuth-based providers in the future — Dropbox, Box, and others — the pattern will be the same: a one-click path wherever we can offer one honestly, and Bring-Your-Own always available underneath it.

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