Skip to content

CONCEPT Cited by 1 source

Activation link credential bootstrap

Definition

An activation-link credential bootstrap is an onboarding pattern where a service provisions an external user (typically a partner / recipient / tenant) with a one-shot secure URL — the activation link — which the user visits to download a credential file containing the tokens / keys needed to authenticate against the service's API. The activation link is the secret-delivery channel; the downloaded file is the long-lived credential artefact.

Canonical instance on the wiki: Databricks Delta Sharing recipient activation — the provider creates a Recipient (patterns/recipient-per-partner-share-per-dataset-group), the system generates an activation URL, the partner visits the URL once, downloads a credential JSON (a profile file), and uses that file to authenticate every subsequent Delta Sharing API call.

Shape

[Provider]                                 [Partner]
   │
   ├── 1. Create Recipient "acme_corp"
   │
   ├── 2. Generate activation URL
   │   (unique + time-limited + one-time-use)
   │
   ├── 3. Send URL to partner
   │   (email / portal / secure channel)
   │                                          │
   │                                          ├── 4. Visit URL
   │                                          │
   │                                          ├── 5. Download profile file
   │                                          │   (JSON with token + endpoint)
   │                                          │
   │                                          └── 6. Store file locally,
   │                                              point Delta Sharing client
   │                                              at it for every API call

Why the two-step bootstrap

The design separates "how do I tell the partner their credential?" from "how does the partner use their credential every day?"

  • Activation URL properties: one-time-use + short-lived + can be sent over moderately-secure channels (email / portal) because revealing the URL after it's been redeemed is harmless.
  • Credential file properties: long-lived (until rotated or revoked) + carries the actual secret (token + endpoint).

Sending a long-lived credential file over email directly would be a security concern; sending a one-time-use URL that expires is tolerable because the window of exposure is short.

Operational properties

  • Self-service redemption. Partner decides when to activate; provider doesn't need to schedule a coordinated exchange.
  • Audit trail. Activation redemption is logged — provider knows exactly when the partner took control of the credential.
  • Per-recipient scoping. Each Recipient gets its own URL → its own credential file → its own API surface. Revoking one partner's access doesn't affect others.
  • Token revocation. Provider can revoke a Recipient's tokens at any time without coordination; partner's next API call fails and they re-bootstrap with a fresh activation link.

Manual-to-platform evolution

In pilot deployments, activation links are often distributed manually — Partner Tech contacts the partner, emails the link, confirms the credential file works. This does not scale.

Scaling this to many recipients forces two platform primitives:

  • Programmatic Recipient + activation URL API. No human step between "onboarding request received" and "activation URL ready".
  • Secure delivery channel. Activation URL delivery automated into the partner portal / partner email provisioning, not operator-sent.

The Zalando Partner Tech post names this explicitly as pilot-phase manual-ok, platform-phase automation-required. See systems/zalando-partner-data-sharing-platform.

Toward OIDC federation

The activation-link bootstrap assumes the provider issues the credentials. An architectural next step is OIDC federation: partners authenticate with their own identity provider, and the data-sharing service accepts their IdP-issued tokens directly. The activation-link + credential-file step is then skipped entirely — the partner never holds a provider-issued token, only their own.

Zalando documents this as roadmap for their Delta Sharing deployment: Databricks OIDC federation for recipients replaces the activation-link + profile-file path. The trade-off: OIDC federation requires the partner to have an IdP and the capability to issue tokens with the right claims, which not all partners have — so activation-link bootstrap remains the default path for low-sophistication partners even when federation is available.

Trade-offs vs alternatives

  • vs shared API key per partner: activation link is better — no exposure of the key in the delivery channel.
  • vs OAuth device-code flow: activation link is simpler for static-credential use cases; OAuth is better when the partner is a human in a browser with an IdP session.
  • vs mTLS client certificate: activation link is better for partners without PKI capability; mTLS is better for high-security machine-to-machine scenarios.
  • vs OIDC federation: activation link is simpler when the partner lacks their own IdP; OIDC is better at scale and avoids the provider-issued long-lived-token-sitting-on-partner-disk risk.

Seen in

  • sources/2025-07-07-zalando-direct-data-sharing-using-delta-sharing-introduction-our-journey-to-empower-partners — Zalando Partner Tech uses Databricks recipient activation tokens as the pilot-phase partner bootstrap: Recipient created in Unity Catalog → activation URL generated → URL delivered to partner → partner downloads credential file → credential file authenticates every Delta Sharing API call thereafter. Canonicalises the pattern as pilot-acceptable-manual vs platform-required-automated and names OIDC federation as the next step that removes the provider-issued-token window.
Last updated · 550 distilled / 1,221 read