Skip to content

CONCEPT Cited by 1 source

M2M OAuth vs PAT

Machine-to-machine (M2M) OAuth versus Personal Access Tokens (PATs) is the auth-substrate choice for service-to-service authentication: which credential class does a non-human workload use to authenticate to a service?

The 2026-05-14 Expanded interoperability with Unity Catalog Open APIs post canonicalises the architectural argument for M2M OAuth as the GA-quality auth substrate, naming the structural failure modes of PATs that drove the migration:

"External engines can now authenticate to UC using machine-to-machine (M2M) OAuth, meeting enterprise security requirements without relying on personalized access tokens (PATs), which are per-user, long-lived, and hard to rotate." (sources/2026-05-14-databricks-expanded-interoperability-with-unity-catalog-open-apis)

The three structural failure modes of PATs

The 2026-05-14 disclosure explicitly names three:

  1. Per-user. A PAT binds the service identity to a specific human's identity. When the human leaves the organisation, the service breaks — even though the underlying workload has nothing to do with that person. The organisational coupling between service and human is structurally unnecessary.

  2. Long-lived. PATs are typically issued with year-scale (or no-expiry) lifetimes by default. Compromise yields an indefinite attack window. Mitigations (manual rotation, inventory tracking) are operational disciplines, not architectural guarantees.

  3. Hard to rotate. Rotation requires per-engine reconfiguration: every consumer of the PAT must be updated. Discovery of "where is this PAT in use?" is itself difficult. The result is that rotation in practice happens rarely and under duress (after a known compromise), not on a routine cadence.

How M2M OAuth dissolves all three

Failure mode M2M OAuth resolution
Per-user Service identity — a registered OAuth client (with client_id + client_secret or signed JWT assertion) owned by the service team, not bound to a human. The human-identity-vs-service-identity collapse is undone.
Long-lived Short-lived tokens — the client_id + client_secret exchange yields a minutes-scale access token. Compromise of the access token bounds attack to that window. The longer-lived client_secret can be rotated, and is itself protected (typically vaulted), reducing exposure.
Hard to rotate Automatic rotation — engine SDKs and OAuth libraries handle re-mint transparently when the access token approaches expiry. No per-engine config update is required. The client_secret rotation is also more tractable because there is one client_id to find, not many endpoints to update.

Why this matters for [UC Credential

Vending](<../systems/uc-credential-vending.md>)

UC Credential Vending is the catalog-mediated credential-issuance primitive — the catalog mints short-lived, scoped credentials on demand for external engines. The auth substrate that gates the "who's allowed to call the vending API" question is M2M OAuth (post-GA) instead of PATs (pre-GA preview).

The architectural composition the 2026-05-14 post discloses:

External engine
    │
    │ (1) M2M OAuth client-credentials grant → UC
    │     (yields short-lived access token)
    │
    │ (2) Authenticated call to credential vending API
    │     with access token
    │
    │ (3) UC mints scoped, short-lived credentials
    │     for the requested resource
    │
    │ (4) Engine reads/writes object store with the
    │     scoped credential
    │
    │ (5) Engine SDK detects approaching expiry
    │     and re-invokes both the access-token mint
    │     (if needed) and the credential vending API

The unification: two layers of short-lived credentials — the M2M OAuth access token (engine ↔ catalog) and the vended storage credential (catalog → cloud-storage), both auto-refreshing. The PAT-era shape collapsed both into one long-lived credential the engine held statically.

Composition with the broader OAuth-JWT family

M2M OAuth tokens are an instance of the broader OAuth-JWT short-lived-credential family canonicalised on the 2026-04-30 Backstage-with-Lakebase ingest. The shared properties:

  • Bounded TTL (minutes to hours, not days to forever)
  • Issued for a specific scope
  • Re-minted periodically rather than stored long-lived

The M2M variant is specifically the OAuth 2.0 client_credentials grant — designed for machine-to-machine flows where there is no human end-user (and no consent UI).

When PATs are still acceptable

The 2026-05-14 post does not call out cases — it frames M2M OAuth as the strict upgrade. Inferred edge cases where PATs may still be chosen:

  • Throwaway local-development workflows where a developer generates a PAT for curl-based exploration and discards it promptly. Operationally cheaper than registering an OAuth client.
  • Short-lifetime project bootstraps where the integration surface will be replaced before the PAT's natural expiry.
  • Vendor systems that don't support M2M OAuth — a forced fallback, not a preferred shape.

In all three, the key property is that the PAT is transient and operator-managed, not a long-lived production substrate.

Seen in

Last updated · 542 distilled / 1,571 read