Link cloud accounts

Delegated storage discovery takes two steps. An admin registers an OAuth app per organisation, then each user links their own Azure or Google account so Eddytor can enumerate that user's storage accounts/buckets and discover tables - without anyone hand-entering credentials.

Register the provider app

The client id/secret are stored encrypted in the database (not env vars), so each org brings its own app, and an unconfigured deployment returns provider_not_configured rather than crashing.

eddytor set provider-app azure \
  --client-id "<application-client-id>" \
  --client-secret "<client-secret>" \
  --tenant "<directory-tenant-id-or-domain>"   # omit for multi-tenant apps
# or: POST /v1/organisations/<org_id>/provider-apps/azure  (scope provider_apps:write)

Check what's configured (secrets are never returned):

eddytor get provider-app          # all configured providers
eddytor get provider-app azure    # one provider
# or: GET /v1/organisations/<org_id>/provider-apps  (scope provider_apps:read)

Microsoft Entra ID (Azure AD)

1. App registrations → New registration. Name it Eddytor. Single-tenant for org-only, multi-tenant for shared.
2. Redirect URI (Web): ${public_url}/api/v1/auth/providers/azure/callback (replace ${public_url} with your server.public_url).
3. Copy the Application (client) ID (and Directory (tenant) ID for single-tenant).
4. Certificates & secrets → New client secret → copy the value.
5. API permissions → add openid, email, profile, offline_access, User.Read, https://storage.azure.com/user_impersonation, and https://management.azure.com/user_impersonation. Grant admin consent.
6. Store it: eddytor set provider-app azure ….

Google Workspace

1. Google Cloud Console → APIs & Services → Credentials → Create Credentials → OAuth client ID → Web application.
2. Authorized redirect URI: ${public_url}/api/v1/auth/providers/google/callback.
3. Store it: eddytor set provider-app google … (no tenant).
4. OAuth consent screen → publish (or keep in testing for a closed list). Add the devstorage.full_control + cloud-platform.read-only scopes.

Link an account

eddytor link provider azure     # opens the browser for consent, waits for the link
eddytor link provider google

For Azure, add blob data access (not just discovery) with:

eddytor link provider azure --azure-storage-access

Inspect and remove links:

eddytor get providers                 # list your linked identities
eddytor unlink provider azure         # remove one

Linking vs registering storage

Two paths to give Eddytor storage access:

• Link a provider (this page) - delegated, per-user, great for discovery (browse subscriptions/accounts/buckets visually, find tables).
• Register a storage connection directly - with an access key, SAS token, service principal, or managed identity. Best for unattended / server-side access that isn't tied to a person's login.