Why AI Platforms Must Never Store Provider OAuth Credentials
TL;DR — AI platforms that store provider OAuth credentials (Slack, Google, GitHub tokens) in plaintext create a single point of failure. A database breach exposes access to every connected service. The fix: encrypt tokens at the application layer (Fernet or AES-256-GCM), use per-user OAuth so each user authorizes their own access, store tokens in a dedicated vault, use short-lived access tokens with automatic refresh, and never log credentials. Nango manages the full OAuth lifecycle for 250+ APIs. Per-user OAuth ensures agents can only access what the user is authorized to see.
AI platforms integrate with external services — Slack, Google Drive, Gmail, GitHub, Jira, Notion. Each integration requires OAuth credentials: access tokens and refresh tokens that grant the platform permission to read and act on the user's data.
The common mistake: storing these tokens in plaintext in the database. A single database breach exposes access to every connected service for every user. The attacker doesn't need to hack Slack, Google, or GitHub — they just read your oauth_tokens table.
This post covers why plaintext credential storage is a critical vulnerability, how to store OAuth tokens securely, and the architectural patterns for per-user OAuth in AI platforms. For BYOK security, OAuth credential management is the integration layer.
The Plaintext Credential Problem
When an AI platform stores OAuth tokens in plaintext:
| Risk | What happens |
|---|---|
| Database breach | Attacker reads all tokens — access to every connected service |
| DBA access | Database administrators can read and misuse tokens |
| Log exposure | Tokens accidentally logged in error messages or debug output |
| Backup theft | Database backups contain plaintext tokens |
| Memory dump | Tokens persist in application memory between requests |
The 2026 Verizon DBIR found that stolen credentials were the top initial access vector, involved in 44% of breaches (Verizon 2026). For AI platforms, OAuth tokens are credentials — and they grant access to some of the most sensitive systems in the enterprise.
Secure OAuth Token Storage Architecture
| Storage layer | What it does | Security level |
|---|---|---|
| Plaintext in database | No encryption | None — critical vulnerability |
| Database-level encryption (TDE) | Encrypts database files | Protects at rest, not from DBA |
| Application-layer encryption (Fernet) | Encrypts tokens before storage | Protects from DBA and database breach |
| Dedicated token vault | Separate secrets management system | Strongest — isolated from application database |
| HSM-backed vault | Keys in hardware security module | Enterprise-grade — keys never leave hardware |
For Fernet encryption of OAuth tokens, the application encrypts tokens before INSERT and decrypts after SELECT. The database stores only ciphertext.
Per-User OAuth: The Right Model for AI Agents
AI agents that act on behalf of users should use per-user OAuth, not shared platform credentials.
| Model | How it works | Risk |
|---|---|---|
| Shared platform credential | One OAuth token for all users | Breach exposes all users' data |
| Per-user OAuth | Each user authorizes separately | Breach exposes only one user's data |
| Per-agent OAuth | Each agent gets its own credential | Limits blast radius per agent |
With per-user OAuth, the AI agent uses the user's OAuth token to access external services. The agent can only access what the user is authorized to see — no more, no less. This is the document-level ACLs principle applied to integrations.
OAuth flows for AI agents
| Flow | When to use | Token lifetime |
|---|---|---|
| Authorization Code (RFC 6749) | User-present interaction — user authorizes in browser | Short-lived access + long-lived refresh |
| Client Credentials (RFC 6749) | Service-to-service — no user context | Short-lived, auto-refreshed |
| Token Exchange (RFC 8693) | Agent acting on behalf of user — delegation | Short-lived, scoped to agent's purpose |
AI agents that continue operating after the user session ends need refresh tokens with appropriate scopes. The platform refreshes access tokens automatically before they expire (ScaleKit 2026).
Token Lifecycle Management
| Phase | What happens | Security requirement |
|---|---|---|
| Authorization | User grants access via OAuth flow | Use PKCE, redirect URI validation |
| Token storage | Access and refresh tokens stored | Encrypt at application layer |
| Token refresh | Access token expires, refresh token gets new one | Automatic, transparent to user |
| Token revocation | User or admin revokes access | Call provider's revocation endpoint |
| Token rotation | Refresh token rotates on each use | Store new refresh token, invalidate old |
| Token deletion | User disconnects integration | Delete encrypted tokens from vault |
Nango: Managed OAuth for AI Platforms
Nango is an open-source integration platform that manages OAuth flows, token storage, and automatic refresh for 250+ APIs. It eliminates the need for AI platforms to build and maintain credential storage.
| Feature | What Nango provides |
|---|---|
| OAuth flow management | Handles authorization code flow with PKCE |
| Token storage | Encrypted vault — tokens never in plaintext |
| Automatic refresh | Refreshes access tokens before expiry |
| 250+ API support | Pre-configured OAuth for Slack, Google, GitHub, etc. |
| Token revocation | Clean disconnect with provider revocation endpoint |
| Self-hosted | Run on your infrastructure — tokens never leave your perimeter |
For self-hosted AI platforms, Nango provides the integration layer without the credential storage burden. The platform's code calls Nango's API to get fresh access tokens — it never touches refresh tokens directly (Nango 2026).
Best Practices for OAuth Credential Security
| Practice | Why it matters |
|---|---|
| Never store tokens in plaintext | Database breach = total credential compromise |
| Use application-layer encryption | Protects from DBA and database-level access |
| Store access and refresh tokens separately | Different sensitivity levels, different controls |
| Use short-lived access tokens (15 min) | Limits window of opportunity if stolen |
| Never log tokens or credentials | Logs are a common breach vector |
| Implement token revocation | Users must be able to disconnect instantly |
| Monitor for unusual API activity | Detect token misuse early |
| Use per-user OAuth, not shared credentials | Limits blast radius to one user |
| Rotate refresh tokens on each use | Prevents replay attacks |
| Use PKCE for authorization code flow | Prevents authorization code interception |
Compliance Mapping
| Regulation | Requirement | How secure OAuth storage helps |
|---|---|---|
| GDPR Article 32 | Security of processing | Encrypted credential storage |
| SOC 2 CC6.1 | Logical access controls | Per-user OAuth limits access |
| HIPAA | Access controls for PHI | Per-user OAuth ensures agent sees only user's data |
| ISO 27001 A.9.2 | User access management | OAuth tokens scoped to user permissions |
FAQ
Why should AI platforms never store provider OAuth credentials?
Storing provider OAuth credentials (like Slack, Google, or GitHub tokens) in plaintext creates a single point of failure. A database breach exposes access to every connected service. Use encrypted token vaults, per-user OAuth flows, and short-lived tokens with automatic refresh instead.
How should AI platforms store OAuth tokens securely?
Encrypt tokens at the application layer using Fernet or AES-256-GCM before storing in the database. Use a dedicated token vault or secrets manager. Never log tokens. Decrypt only at the moment of use. Store refresh tokens separately from access tokens with stricter access controls.
What is per-user OAuth for AI agents?
Per-user OAuth means each user authorizes the AI agent to access external services on their behalf. The agent uses the user's OAuth token, not a shared platform credential. This ensures the agent can only access what the user is authorized to see.
How does Nango handle OAuth for AI platforms?
Nango is an open-source integration platform that manages OAuth flows, token storage, and automatic refresh for 250+ APIs. It stores tokens encrypted in its vault and handles the full OAuth lifecycle, eliminating the need for AI platforms to build and maintain credential storage.
What happens if an AI platform's OAuth tokens are stolen?
Stolen OAuth tokens grant access to the connected service as long as the token is valid. Mitigation: use short-lived access tokens (15 minutes), store refresh tokens separately, implement token revocation, monitor for unusual API activity, and use per-user OAuth so a stolen token affects only one user.
Want a self-hosted AI company brain that does all of this out of the box?
Book a demo →