Authenticate an Iceberg REST catalog client via OAuth2 client-credentials against an external identity provider
domain: iceberg.apache.org · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Set the catalog's oauth2-server-uri property to your identity provider's token endpoint instead of relying on the catalog-hosted token endpoint.
Provide the credential property as client_id:client_secret and set scope to the scopes required by the catalog.
Configure the client (PyIceberg, Spark's Iceberg catalog, Trino, etc.) with catalog-type rest plus the uri, oauth2-server-uri, credential, and scope properties.
Confirm the client exchanges the client credentials for a bearer token before its first catalog call, rather than depending on the catalog itself to issue tokens.
Rotate the client secret and re-test authentication to confirm the catalog/IdP integration tolerates credential rotation without downtime.
Known gotchas
The legacy catalog-hosted /v1/oauth/tokens endpoint is deprecated for security reasons and scheduled for removal in a future major Iceberg release; use an external oauth2-server-uri instead.
Never hardcode the client_id:client_secret credential string in code or shared configs; inject it via a secrets manager or environment variable.
Some engines have had OAuth2 client-credentials bugs against specific identity providers, so validate against your exact engine version before relying on this in production.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?