Repository navigation
Field to include temporary bearer token or object storage credentials? #43
Description
Context
For secure asset hrefs returned by openEO API, we currently use presigned urls, which allows exchanging STAC metadata and the data it points to between systems.
For the ZARR format, this does not work, because ZARR is a directory rather than a file, and presigned urls point to files rather than directories.
Request
Can a (secured) API that returns STAC metadata, include a (temporarily valid) token in the metadata, via this extension?
More specifically:
- a bearer token for schemes with type 'http'
- temporary object storage crecentials , for 's3' scheme
Activity
jamesfisher-geo commentedon Dec 31, 2025
In terms of configuring bearer auth with authentication extension I think it would be as simple as including key for the following
auth:schemein theauth:refsof the ZARR asset.{ "bearer_auth": { "type": "http", "description": "Requires bearer token authentication", "scheme": "bearer", "bearerFormat": "JWT", } }Or you can include the authorization link for login
{ "bearer_auth": { "type": "http", "description": "Requires bearer token authentication", "scheme": "bearer", "bearerFormat": "JWT", "flows": { "authorizationUrl": "https://example.authorization.endpoint/authorize", "scopes": { "read:asset": "scope for permission to read asset" } }, } }Accessing the data is another challenge and would require implementation on the client or server side. The idea was put out in stac-auth-proxy #11 to automatically generate signed URLs. But for multi-file data it would need to authenticate to whatever server is being used
jdries commentedon Jun 11, 2026
bearer token would indeed be an option, is it also possible to add an optional 'token' property in which a temporarily valid token can be provided by the API providing the STAC metadata? (openEO in our case.)
m-mohr commentedon Jul 7, 2026
Might be related to #44 as well.
jdries commentedon Jul 22, 2026
I don't think token exchange (worked on in #44) solves the problem, because it still implies that some token needs to be obtained, so it's not equivalent to signed url's which allow anonymous access.