Skip to content
TrustPlane

OAuth and backend compatibility

Some upstreams want to verify a standard JWT themselves, and some third-party SaaS APIs simply require OAuth. TrustPlane Auth supports backend compatibility as tiers around the same proof-bound authorization model, so you can meet those backends where they are without weakening what callers must prove.

Tier Status Scope
trusted_boundary Current, supported Adapter verifies the TrustPlane passport and transcript-v1 proof, applies local bundle policy, consumes replay state on acceptance, and forwards verified context headers inside a trusted boundary.
backend_jwt Future, scoped After TrustPlane verification, provide a backend-facing JWT/JWKS assertion for selected upstreams that want direct verification of a TrustPlane-issued assertion.
oauth_compat_egress Future, scoped after target/provider selection After TrustPlane verification, bridge to a third-party provider’s OAuth/token-exchange/introspection flow when that provider requires OAuth.

OAuth egress is a bridge, not the TrustPlane core security model. The caller-to-TrustPlane side remains proof-bound, request-bound, route-scoped, replay-consumed, freshness-aware, signer-class-aware, and auditable.

Choose an adoption path

Section titled “Choose an adoption path”

New APIs can start TrustPlane-native with the adapter in front of the service:

caller -> trustplane-adapter -> new API

Existing provider-owned APIs can adopt today through trusted-boundary adapter ingress:

caller -> trustplane-adapter -> existing API

Some brownfield APIs will eventually want direct verification:

caller -> TrustPlane verifier -> backend JWT -> upstream

That is the future backend_jwt tier. It is useful when an upstream wants a standard signed assertion and JWKS verification boundary of its own. It should be treated as hardening or compatibility for selected upstreams, not as a public bearer-token replacement for passport-v1 plus transcript-v1.

Some third-party SaaS APIs require their own OAuth tokens:

caller -> TrustPlane proof verification -> OAuth bridge -> third-party SaaS API

That is the future oauth_compat_egress tier. The OAuth token is a downstream compatibility artifact. It is not the TrustPlane caller credential and does not weaken the caller-to-TrustPlane verification contract.

Security invariants

Section titled “Security invariants”

All future backend compatibility tiers must preserve the TrustPlane caller-side invariants:

  • Acceptance requires a valid proof tied to configured key material, not just possession of a bearer artifact.
  • transcript-v1 remains canonical until an equivalent or stronger proof profile is accepted.
  • Route identity, method/path policy, audience, issuer, trust domain, subject, and allowed_sources still gate acceptance.
  • Replay state is consumed only after an otherwise accepted presentation.
  • Signed trust and policy bundles, proof windows, and downstream assertions keep bounded validity and fail closed where route freshness policy requires it.
  • Compatibility tokens must not erase signer-class policy.
  • Allow and deny decisions must preserve stable reason codes and enough context to explain which TrustPlane decision produced any downstream backend assertion or OAuth request.

Keep OAuth on the egress side

Section titled “Keep OAuth on the egress side”

OAuth compatibility belongs on the egress side when the target backend requires OAuth. It must not create a new TrustPlane ingress mode where callers can skip proof-bound verification by presenting plain bearer OAuth tokens.

An acceptable future OAuth bridge starts with a verified TrustPlane decision, then derives the narrowest downstream OAuth request needed by the provider. Any future implementation should scope provider, audience, resource, tenant, route, subject, session, claims, token lifetime, and audit fields explicitly.

Non-goals

Section titled “Non-goals”

This page does not add runtime code, OAuth compatibility code, token endpoints, introspection endpoints, discovery endpoints, backend assertion endpoints, SDKs, Control behavior, deployment changes, cloud changes, or signed-bundle behavior changes.

Next steps

Section titled “Next steps”