APIs and Common Features

APIs are the heart of the Cloud reactor. They are used to integrate with the logic of Cloud providers, and are ubiquitous in the software development kits of all computing languages. Beyond that, Cloud providers seem to have common characteristics that enable the existence of a solution like Flashback:

• APIs

• Common Features

---

APIs

At the heart of cloud storage lies the object storage API, which provides CRUD-like operations for managing buckets and objects (files). Most APIs expose endpoints for:

• Creating and managing buckets (logical containers for data)

• Uploading, downloading, and deleting objects

• Managing object metadata and permissions

Popular API Documentation Links:

• AWS S3 API Reference

• Google Cloud Storage JSON API

• Azure Blob Storage REST API

• Storj Uplink and S3-Compatible Gateway Docs

• Lotus API and other Filecoin Client Libraries

Most centralized providers also support SDKs in multiple programming languages, while decentralized options often offer command-line tools and API gateways for compatibility.

Common Ways to Access Cloud Storage APIs

Whether using centralized or decentralized cloud storage, secure access to APIs is essential. Here are the most common methods used by developers and applications to authenticate and interact with object storage systems:

1. API Key and Secret (Access Keys)

This is the default and most common method for programmatic access in centralized systems:

• Consists of a public access key ID and a secret access key.

• Used to sign requests, often via HMAC or similar algorithms (e.g., AWS Signature v4).

• These keys should be kept secret, rotated regularly, and scoped to the least privilege necessary.

Used by: ✅ AWS S3, GCP, Azure, Storj (Uplink), MinIO, and other S3-compatible APIs.

Tip: Avoid hardcoding credentials. Use environment variables or cloud-native credential providers (like AWS IAM roles or Google Service Accounts).

2. Delegated Access to External Users

This enables controlled and temporary access to objects or buckets by third parties, without exposing your main credentials.

• Pre-signed URLs / Signed URLs Allow secure, time-limited access to specific objects. Can be generated with custom permissions (read, write, delete).

  ✅ Supported by AWS S3, Google Cloud Storage, Azure Blob (via SAS tokens), and Storj.

• Access Control Lists (ACLs) & Bucket Policies Define read/write permissions at the bucket or object level, including granting access to specific users, roles, or anonymous users.

• Federated Identity / Temporary Credentials Integrates with identity providers (e.g., Cognito, Google Identity, Active Directory) to generate scoped temporary tokens (STS) for users or applications.

  ✅ Ideal for mobile apps, short-lived tasks, or public-facing apps.

3. OAuth 2.0 and Service Accounts

Some providers, especially Google Cloud and Azure, support OAuth 2.0:

• Used to authorize applications or users to access storage on behalf of someone else.

• Service accounts (for back-end applications) or user accounts (for delegated access) can request tokens from OAuth providers.

Used by: ✅ Google Cloud Storage, Azure Blob, and some third-party tools integrating with cloud storage.

4. Web3 / Decentralized Identity Access (DePIN solutions)

Decentralized storage systems use blockchain-native authentication methods:

• Public-Private Key Signing Wallet-based authentication where users sign requests using their crypto wallets (e.g., Ethereum, Filecoin, Arweave wallets).

• Token-based access Filecoin and others use network tokens to pay for storage and authorize uploads/downloads.

  ✅ Storj uses a custom identity system based on cryptographic keys and satellite nodes. ✅ Filecoin requires interaction with smart contracts and storage miners.

5. SDKs and CLI Tools

Most platforms offer language-specific SDKs and command-line tools that abstract away the low-level signing and access mechanics:

• Examples: aws-cli, gsutil, azcopy, uplink (Storj), and IPFS/Filecoin clients.

• Useful for scripting, debugging, and batch uploads/downloads.

These tools often handle credentials securely via local configuration files or integration with cloud-native identity systems.

Security Best Practices

• Use roles and policies instead of assigning full-access keys to all services.

• Enable MFA and logging for access management.

• Scope permissions tightly to resources, actions, and durations.

---

Common Features

Despite different providers and underlying architectures, most object storage platforms offer a common set of features:

Feature	Description
Object Versioning	Automatically stores multiple versions of the same object.
Encryption	Data-at-rest and in-transit encryption, often with customer-managed keys.
Access Control	IAM roles, bucket policies, signed URLs for controlled access.
Multi-region Replication	Redundancy across regions for availability and compliance.
Lifecycle Management	Auto-transitioning objects between tiers (hot/warm/cold) or scheduled deletion.
Storage Classes	Different pricing tiers for hot (frequent), cold (infrequent), and archive.
Event Notification	Trigger events (e.g., Lambda, Pub/Sub) on object creation or deletion.
API Compatibility	S3 API has become a de facto standard; many services offer S3-compatible APIs.

Understanding these shared features helps in evaluating and switching between providers, especially for multi-cloud strategies or hybrid architectures.