Third-Party Apps: What They Are, How Permissions Work, and Security Risks
Third-Party Apps: What They Are, How Permissions Work, and Security Risks
Third-party apps are software built by developers outside the platform you are using. When you connect Zapier to your Gmail, install a Slack bot, or authorize Cursor to use your Claude account, you are granting a third-party app access to a first-party service. This guide covers how that access works, what risks it creates, and how to keep your accounts secure.
What Counts as a Third-Party App
A first-party app is built and maintained by the same company that runs the platform. Gmail is a first-party app on Google. iMessage is first-party on Apple. Everything else is third-party.
The distinction matters because third-party apps need explicit permission to access your data. First-party apps already have access by design.
| Category | First-party examples | Third-party examples | |---|---|---| | Email | Gmail (on Google), Outlook (on Microsoft) | Superhuman, Spark, Mailchimp | | Cloud storage | Google Drive (on Google), iCloud (on Apple) | Dropbox, Box, Notion | | AI models | Claude on claude.ai, ChatGPT on openai.com | Cursor, Windsurf, Claude Code, Cline | | Code hosting | GitHub web UI | VS Code GitHub extension, GitKraken, Linear | | Communication | Slack native features | Slack bots, Zapier integrations, Loom | | Mobile | Apple Health, Google Fit | Strava, MyFitnessPal, Oura |
The key question is always: who built it, and whose data is it accessing?
How Third-Party Apps Get Access to Your Data
Third-party apps use one of three mechanisms to connect to first-party platforms. Each carries different security properties.
OAuth 2.0 (Token-Based Authorization)
OAuth is the standard for third-party app authorization. When you click "Sign in with Google" or "Connect your GitHub account," the platform handles authentication directly. The third-party app never sees your password. Instead, it receives a scoped token that limits what it can access.
OAuth tokens have three important properties:
- Scoped: the token only grants the permissions the user approved (e.g., "read email" but not "send email")
- Revocable: the user can disconnect the app at any time, which invalidates the token
- Expiring: most tokens expire after 1 to 24 hours and must be refreshed
This is how Cursor connects to Claude, how Figma plugins access your designs, and how Slack bots interact with your workspace.
API Keys (Direct Credential Sharing)
Some platforms let you generate an API key and paste it into a third-party app. This is common with AI services (OpenAI, Anthropic, Replicate) and developer tools (Stripe, Twilio, SendGrid).
API keys are simpler than OAuth but riskier. The third-party app holds a credential that can make requests as you. If the app is compromised, your API key is exposed. There is no consent screen, no scope restriction (unless you create a restricted key), and no automatic expiration.
Username and Password (Legacy)
Some older third-party apps ask for your username and password directly. This is the least secure method. The app has full access to your account and can do anything you can do. If the app stores your password insecurely or gets breached, your account is compromised.
Modern platforms have mostly eliminated this pattern in favor of OAuth.
Permission Scopes: What You Are Actually Granting
When a third-party app requests access, the consent screen lists permission scopes. These scopes determine what the app can and cannot do. Understanding them is essential.
| Scope level | What the app can do | Example | |---|---|---| | Read-only | View data but not modify it | "View your Google Calendar events" | | Read-write | View and modify data | "Create and edit Google Docs on your behalf" | | Admin | Full control over the resource | "Manage members of your GitHub organization" | | Offline access | Maintain access when you are not actively using the app | "Access your data while you are away" (refresh tokens) |
Over-Permissioning Is the Default
Most third-party apps request more permissions than they need. A calendar scheduling tool might ask for full read-write access to your calendar when it only needs to check availability (read-only on free/busy data). A code formatting extension might request repository write access when it only needs to read files.
This happens because:
- Developers anticipate future features. Requesting broad scopes now avoids re-prompting users later.
- Scope granularity varies by platform. Some APIs bundle permissions (you cannot get "read email subjects" without "read email bodies").
- Documentation defaults are permissive. Quickstart guides often use broad scopes to reduce setup friction.
Before approving a third-party app, compare the scopes it requests against what it actually does. If a note-taking app wants access to your contacts, that is a signal to investigate further.
Security Risks of Third-Party Apps
Third-party apps expand your attack surface. Each connected app is another pathway to your data. Here are the five most common risks.
1. Token Theft Through App Compromise
If a third-party app gets breached, every user's OAuth token or API key is exposed. The attacker does not need your password. They can use the stolen tokens to access your data on the platform directly.
In 2024, a compromised GitHub OAuth app was used to exfiltrate private repository data from dozens of organizations. The platform was not breached. The third-party app was.
2. Excessive Permissions Sitting Idle
Apps you authorized months ago still hold their tokens. That Trello power-up you tried once? It might still have read access to all your boards. Unused apps with active permissions are dormant vulnerabilities.
A 2023 study by Astrix Security found that the average enterprise has over 100 third-party app integrations connected to their SaaS platforms, with 37% of those integrations having excessive permissions and 46% being unused for over 90 days.
3. Supply Chain Attacks
An attacker compromises the third-party app's build pipeline or dependency chain. Users who update the app unknowingly install malicious code that uses their existing permissions to exfiltrate data or perform unauthorized actions.
4. Phishing Through Fake OAuth Consent
An attacker creates a convincing-looking OAuth consent screen for a malicious app. If you click "Authorize," the attacker's app gets legitimate tokens to your account. This works because the OAuth flow itself is real; only the app requesting authorization is fraudulent.
5. Data Leakage Through Broad Scopes
A third-party app with broad read permissions can index, cache, or store more data than you expect. Even if the app is not malicious, its data handling practices might not meet your security standards. Data processed by the third-party app is only as secure as that app's infrastructure.
How to Audit and Manage Third-Party App Permissions
Every major platform provides a way to review connected third-party apps. Here is where to find the settings.
| Platform | Where to audit | URL | |---|---|---| | Google | Security > Third-party apps with account access | myaccount.google.com/permissions | | GitHub | Settings > Applications > Authorized OAuth Apps | github.com/settings/applications | | Slack | Workspace Settings > Manage Apps | [workspace].slack.com/apps/manage | | Microsoft | Account > Privacy > Apps and services | account.live.com/consent/Manage | | Apple | Settings > [Your Name] > Sign-In & Security > Sign in with Apple | appleid.apple.com | | Anthropic (Claude) | Settings > Connected Apps | claude.ai/settings |
Quarterly Audit Checklist
Run this review every 90 days:
- List all connected apps. Visit each platform's third-party app settings page.
- Remove apps you no longer use. If you have not used it in 90 days, revoke access.
- Check permission scopes. For each remaining app, verify the scopes match what you actually use.
- Review API keys. Rotate keys that have been active for more than 90 days. Delete keys for discontinued projects.
- Check for unknown apps. If you see an app you do not recognize, revoke it immediately and change your password.
Third-Party Apps in AI Development Workflows
The rise of AI coding assistants has created a new category of third-party app connections. Tools like Cursor, Claude Code, Windsurf, Cline, and GitHub Copilot authenticate against AI model providers (Anthropic, OpenAI) and code platforms (GitHub, GitLab) simultaneously.
This creates a unique permission surface:
AI coding tools typically hold credentials for at least two external services plus full read-write access to your local codebase. When evaluating these tools, check:
- How the tool authenticates to the AI model. OAuth (through your Claude or OpenAI account) means usage is billed to you and limited by your plan. API keys mean you control the billing directly but hold responsibility for key security.
- What code context gets sent. Most AI coding tools send file contents, terminal output, and sometimes git history to the model provider. Understand what leaves your machine.
- Whether the tool stores data remotely. Some tools sync settings, conversation history, or code snippets to their own servers. Check the privacy policy.
Best Practices for Managing Third-Party App Risk
- Use OAuth over API keys when available. OAuth provides scoped, revocable, time-limited access. API keys are all-or-nothing.
- Apply the principle of least privilege. Only approve the minimum scopes an app needs. If a platform offers granular scope selection, use it.
- Set calendar reminders for quarterly audits. Permissions drift is gradual. Scheduled reviews catch it before it becomes a problem.
- Use separate accounts for sensitive data. If your organization stores confidential data in a platform, limit third-party app connections to accounts that do not have access to that data.
- Monitor for anomalous activity. Enable audit logs on platforms that support them (Google Workspace, GitHub Enterprise, Slack Enterprise Grid). Unusual API calls from a connected app may indicate compromise.
- Prefer third-party apps with SOC 2 or ISO 27001 certification. These certifications mean the vendor's security practices have been independently audited.
FAQ
What is a third-party app? A third-party app is software built by someone other than the platform provider. When you use a Slack bot made by an external company or connect an AI coding tool to your GitHub account, that is a third-party app accessing a first-party platform on your behalf.
Are third-party apps safe to use? It depends on the app. Third-party apps from reputable companies with transparent security practices and appropriate permission scopes are generally safe. The risk increases with excessive permissions, unknown developers, and apps that have not been updated recently. Always review the scopes before authorizing.
How do I remove a third-party app's access? Go to the platform's security or privacy settings, find the connected apps section, and revoke access. On Google, this is at myaccount.google.com/permissions. On GitHub, check Settings > Applications. Revoking access invalidates the app's tokens immediately.
What is the difference between OAuth and an API key? OAuth lets you authorize an app without sharing your password. The app gets a scoped, time-limited token. An API key is a static credential you generate and paste into the app. It typically grants broader access and does not expire unless you rotate it manually.
How often should I audit my connected third-party apps? Every 90 days is a good baseline. If you work with sensitive data (financial, healthcare, customer PII), consider monthly audits. Remove any app you have not used since your last review.
Fazm is an open source macOS AI agent that starts with free built-in credits, so you can try it without worrying about extra usage. When you are ready, connect your personal Claude Pro or Max subscription and keep going. Open source on GitHub.