Skip to content

Add tokenExchange OAuth2 flow (OAuth 2.0 Token Exchange, RFC 8693)#44

Open
cayetanobv wants to merge 1 commit into
stac-extensions:mainfrom
cayetanobv:token-exchange-flow
Open

Add tokenExchange OAuth2 flow (OAuth 2.0 Token Exchange, RFC 8693)#44
cayetanobv wants to merge 1 commit into
stac-extensions:mainfrom
cayetanobv:token-exchange-flow

Conversation

@cayetanobv

Copy link
Copy Markdown

This adds tokenExchange to the pre-defined OAuth2 flow keys, mirroring the proposed OpenAPI addition OAI/OpenAPI-Specification#5428 as discussed with @m-mohr in portolan-sdi/portolan-cli#551: OpenAPI PR first, this extension mirrors it.

The flow corresponds to RFC 8693 (OAuth 2.0 Token Exchange): the client presents a token obtained elsewhere — e.g. an identity token from an openIdConnect scheme — at the tokenUrl and receives a different token back, typically short-lived scoped credentials for direct data access. This is the pattern behind cloud STS endpoints and credential vending in data platforms; the driving STAC use case is catalogs whose assets live in access-controlled object storage.

Changes (all mirroring how the existing flows are handled):

  • README: tokenExchange added to the pre-defined flow keys; tokenUrl REQUIRED for it; a short paragraph in the OAuth2 Flow Object section referencing RFC 8693 and the OpenAPI PR.
  • JSON Schema: tokenExchange added to the tokenUrl-required pattern.
  • examples/collection.json: a token_exchange scheme (exercises the schema rule in CI).
  • CHANGELOG entry under Unreleased.

npm test passes (remark + stac-node-validator, examples valid).

One design question deliberately not addressed here, for discussion: whether/how a tokenExchange scheme should declare which other scheme's token is the expected subject_token (e.g. a field referencing an auth:schemes key vs. leaving it to description prose). Kept out to stay a faithful mirror of the OpenAPI PR; happy to follow up in a separate issue/PR if there's interest.

Note on tooling: AI tooling was used for research and drafting; I reviewed and take responsibility for all content.

…fication#5428

Adds tokenExchange to the pre-defined OAuth2 flow keys: tokenUrl
required, scopes as for all flows. Includes the JSON Schema rule,
a collection example, and a CHANGELOG entry.
@m-mohr m-mohr self-requested a review July 7, 2026 15:41
cayetanobv added a commit to cayetanobv/portolan-cli that referenced this pull request Jul 7, 2026
…catalogs

Repurposes this proposal after the upstream agreement: the vending step
is standardized upstream (OAI/OpenAPI-Specification#5428 mirrored by
stac-extensions/authentication#44), so Portolan adopts the Authentication
extension wholesale instead of owning an access: namespace.

- spec/extensions/authentication.md: profile note — two-step gated read
  (openIdConnect identity + oauth2/tokenExchange vending), fields used,
  client algorithm, chaining convention (pending upstream), validation
  rules, security considerations.
- spec/examples/authentication-collection.json: gated collection with
  two schemes and two gated assets (GeoParquet + Iceberg metadata) on
  one exchange; validates against the v1.1.0 schema.
- access: extension files removed (shape preserved in history as the
  recorded fallback).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant