Skip to main content
A Volunteer partner integration holds the keys to a customer’s entire volunteer dataset. The customer’s Bearer token grants full read access to their org’s Users, Projects, Groups, Forms, and Form Completions — and write access to the limited set of endpoints. Lose the token, and a third party can read every volunteer record (and modify Users, Projects, and Groups). The security patterns on this page aren’t optional bureaucracy — they’re the foundation of customer trust. This page covers the security practices that matter: how to handle tokens, where to store them, how to minimize blast radius when something goes wrong, and the audit and operational patterns that surround them. If you haven’t yet, skim Authentication for the basic token model.

Principle 1: tokens are credentials, not configuration

A common mistake: treating VOMO tokens like ordinary configuration values — environment variables, config files, deployment manifests. They’re not. They’re secrets that should be handled with the same care as database passwords or API keys.

What this means in practice

The “secrets in env vars” trap

It’s tempting to dismiss the env-var concern — “we control the production environment, only admins can see env vars.” But:
  • Container orchestrators often dump env vars in logs during debugging
  • Crash reports may include process memory
  • Sidecar containers and observability tools sometimes capture env state
  • A developer with prod access becomes a single point of compromise
For low-stakes integrations, env vars are acceptable risk. For partner integrations holding many customers’ tokens, secrets managers are essential.

Principle 2: defense in depth — multiple layers

No single layer of protection is enough. Layer them: Each layer is independent. If one fails (e.g., a misconfigured IAM rule), the others provide backstops (the secrets manager logs the unusual access; rotation limits how long the exposure lasts).

Layer by layer


Principle 3: per-customer credential isolation

For multi-tenant partner integrations, each customer’s token must be isolated from other customers’ tokens. A bug or compromise affecting one customer’s credentials shouldn’t cascade.

Storage pattern

JavaScript
The customer-derived key means even if the secrets manager’s master key is compromised, decrypting each customer’s token requires the per-customer derivation step.

Why “every access requires a reason”

Forcing a reason parameter is a code-organization tactic: it makes it visible in code review when token access is happening. A grep for getToken( shows every site that pulls a token; the reason string explains why. Common reasons:
  • 'polling_cycle'
  • 'manual_backfill'
  • 'reconciliation'
  • 'customer_dashboard'
  • 'health_check'
Anything else is suspicious and worth scrutinizing during review.

Principle 4: minimize token exposure in memory

Once decrypted, the token lives in memory. Minimize how long and where:

Pattern: short-lived decrypted handles

JavaScript
The decrypted token is scoped to the function that needs it. After the function returns, the reference is released; the runtime’s garbage collector eventually reclaims the memory.

Don’t put tokens in long-lived caches

A common anti-pattern: caching decrypted tokens for performance. This trades a tiny performance benefit for substantial security risk.
JavaScript
The “cached” token is now exposed for the lifetime of the worker process — and visible in heap dumps, error reports, and debugging tools. Better: cache only metadata (token expiry, partial fingerprint for logging), not the token itself.

Principle 5: scope minimization

Customers issue tokens via the VOMO admin portal. The token grants access to the customer’s organization — there’s no fine-grained scoping by resource type in the API itself. But the partner integration can choose to use the token more or less broadly. Principle: use the token for the narrowest set of operations needed for the workflow.

Pattern: per-workflow token use

JavaScript
Even though usersToken and writeToken are the same token (VOMO doesn’t issue separate read/write tokens), the audit log separates the two uses. If a compromise is detected, the log shows whether the integration was reading or writing at the moment.

Future-proofing for finer-grained scoping

If VOMO ever introduces fine-grained scopes, integrations that have been careful about declaring operation intent will be ready. Integrations that treat the token monolithically will need refactoring.
The path from customer → partner is where most token compromises happen:

Pattern: secure-form-based handoff

The right pattern: customer-facing form on the partner’s web UI, TLS-encrypted, that captures the token and immediately encrypts it for storage:
JavaScript

Customer-side guidance to include in onboarding

Document for the customer:
  • The token grants full access to their VOMO data — treat it like a password
  • Don’t share via email, chat, or unencrypted channels
  • The form-based handoff is the only secure path
  • After submission, the partner stores it encrypted
  • Notify the partner immediately if the customer suspects the token was exposed
  • Use the customer’s VOMO admin portal to revoke/rotate the token
Build a one-page security FAQ for customers. It’s a foundation of customer trust.

Principle 7: rotation

Even with perfect storage, tokens should rotate periodically. Rotation:
  • Limits the exposure window if a token is leaked
  • Forces audit of which integrations are actually using which tokens
  • Aligns with security best practices for compliance audits

Rotation patterns

Customer-initiated rotation: The customer generates a new token in the VOMO admin portal; updates the partner integration; the old token is revoked. The integration uses the new token for verification (test query); only after verification does it commit to the new token; then the customer revokes the old. Scheduled rotation reminder: Partner sends customers an email every N months reminding them to rotate.
JavaScript
For most B2B integrations, 180 days (6 months) is a reasonable cadence — frequent enough to limit exposure, infrequent enough to avoid rotation fatigue.

Principle 8: audit everything

Comprehensive audit logging is a security primitive. Every meaningful event should be logged:

Audit log integrity

The audit log itself can be a target — an attacker may try to delete or modify entries to cover tracks. Mitigations:
  • Append-only design (no UPDATE or DELETE statements supported)
  • Separate access control — the application can write but only ops can read
  • Off-system replication — entries also sent to a separate log aggregation system
  • Tamper-evident chaining — each entry includes a hash of the previous (blockchain-style)
For most partner integrations, append-only + separate access control + log aggregation is sufficient.

Retention

How long to keep audit logs: Longer retention provides better forensics but costs more storage. Tier by importance.

Principle 9: secure handling of PII

Volunteer data is PII (personally identifiable information). Names, emails, phone numbers, addresses, birthdays — all of it is regulated under various privacy laws (GDPR in EU, CCPA in California, etc.).

Practices that matter

The data minimization pattern

For partner integrations, don’t store PII you don’t need. If you only need to know “Bruce participated in 5 projects last month,” you don’t need to store his birthday, gender, address. Trimming the data you persist limits exposure:
JavaScript
For some integrations this is dramatic — moving from “mirror everything” to “store only what we use” cuts PII exposure to 20% of what it would have been.

Customer-initiated deletion

For GDPR Article 17 (right to erasure) compliance, support customer-initiated deletion of specific persons:
JavaScript
Anonymization (rather than full deletion) preserves the structural integrity of historical reports while removing PII. Aggregate stats remain correct; the person can no longer be identified.

Principle 10: customer offboarding

When a customer cancels the integration, secure handling of their credentials and data is essential.

Offboarding checklist

JavaScript

Why a retention period

Customers sometimes cancel and then re-enable (changed their mind, business needs evolved). A retention period (30-90 days) lets them resume without full re-onboarding. But: communicate the retention period clearly during offboarding, including the final-deletion date. For privacy-sensitive customers, offer immediate deletion as an opt-in.

Principle 11: respond to compromise quickly

When you suspect a credential has been compromised — leaked in a log, exposed in a code review, accessed without authorization — the response should be immediate:

Incident response sequence

Speed matters

The window between detection and containment is the highest-risk period. Build tooling that makes containment fast:
JavaScript
One command, executable by operators on-call. Containment within seconds.

Security review checklist

Periodically (quarterly is reasonable), walk through this checklist:
  • All tokens are stored encrypted at rest
  • All tokens are in a secrets manager, not application code or config
  • Token access is logged with reason in every code path
  • No tokens appear in logs, error traces, or monitoring dashboards
  • Per-customer encryption keys are used (not just a single master key)
  • Token rotation reminders are sent every 6 months
  • HTTPS-only enforced (no HTTP fallback)
  • PII storage minimized to what workflows actually use
  • Customer-initiated data deletion is supported and tested
  • Offboarding deletes credentials immediately; data on a documented retention
  • Audit logs cannot be modified or deleted by application code
  • Incident response runbook exists and has been rehearsed
  • Compliance requirements (GDPR, CCPA, etc.) are documented and met
A pass on this checklist means the integration meets basic security hygiene for B2B partner work. Going beyond — penetration testing, SOC 2 audits, etc. — depends on customer requirements.

Where to go next

Versioning and Backward Compatibility

The patterns for surviving API changes without breaking integrations.

Sync Architecture Patterns

The architectural patterns this security model fits into.

Build a Volunteer Self-Service Portal

The recipe that puts these security patterns to work in a customer-facing product.

Authentication

The reference page for VOMO’s auth model.
Last modified on May 22, 2026