AWS Glue adds OAuth to the Iceberg REST catalog and gives third-party engines an alternative to AWS keys
On October 26, 2026, AWS Glue Data Catalog began accepting OAuth 2.0 bearer tokens on its Iceberg REST endpoint, alongside SigV4, using RFC 8693 token exchange. Data teams federating Iceberg tables to Spark, Trino, or a third-party platform should switch to these short-lived tokens.
October 26, 2026. AWS announces that Glue Data Catalog now accepts OAuth 2.0 bearer tokens on its Iceberg REST endpoint, alongside SigV4 signing. October 26, 2026, same day. The documentation spells out the mechanism: an OIDC identity token is exchanged for a short-lived, Glue-scoped token under RFC 8693. Before this announcement. Only SigV4 was accepted, which forced every third-party engine to hold long-lived AWS keys. The part that matters: a data team can now expose its Iceberg tables to Snowflake, Starburst, or a remote DuckDB without ever handing over an IAM key.
What changes: OAuth becomes the standard authentication path
The Apache Iceberg REST Catalog specification defines OAuth 2.0 as its reference authentication mechanism. Query engines that implement the catalog natively — Apache Spark, Trino, Apache Flink — already speak the protocol. Until now, AWS was the outlier: its Iceberg REST endpoint only accepted SigV4, an AWS-specific signature these engines do not generate natively.
The fix from AWS opens a second path. Using RFC 8693 token exchange, a client swaps an OpenID Connect (OIDC) identity token for a short-lived bearer token scoped to Glue. That token is then presented on IRC requests exactly as any other Iceberg client would. The result is a single, consistent authentication pattern across engines.
The capability ships in every region where AWS Glue and Lake Formation are available. Nothing is removed: SigV4 remains accepted for internal clients that already use it.
Why SigV4 was the blocker for third-party engines
SigV4 is a signature computed from an access key and a secret, carried in request headers. It is robust, but it imposes two burdens on an outside engine.
First, the implementation. Trino, Spark, and Flink speak OAuth for the Iceberg catalog because that is the ecosystem standard; asking them to sign with SigV4 requires an AWS-specific connector or a homegrown translation layer. Second, the secret itself. To sign, the engine must hold an AWS access key — a static pair that, once shared with Snowflake or an integration partner, lives on a machine you do not control, on a rotation cycle you no longer own.
This is precisely the scenario the announcement targets. AWS says it plainly: you can now “grant partners federated access to your Iceberg tables without distributing AWS credentials”. The OAuth token is short-lived, scoped to the Glue catalog, and revocable through normal IAM channels.
The security model: short-lived tokens, still governed by IAM and Lake Formation
It would be tempting to read this as a loosening of control. It is the opposite. The bearer token issued by the RFC 8693 exchange is not a permission by itself: authorization remains entirely decided by IAM and Lake Formation.
The flow runs in three steps. The client presents its OIDC token to the exchange endpoint, which verifies the identity and issues a Glue token with a short lifetime. That token carries a narrow scope — read catalog metadata, query specific tables — and nothing more. Finally, every call to the Iceberg catalog is checked against the IAM policies and Lake Formation permissions attached to the underlying identity, not against the token itself.
The consequence for a data leader is measurable. A shared IAM key handed to a partner is a secret that can leak and stay silent for months. A short-lived bearer token limits the exposure window to minutes, and its revocation follows the normal IAM paths. It is the same logic STS brought to EC2 fifteen years ago, applied to the data catalog.
What to do, concretely
The announcement forces no one to migrate. SigV4 keeps working, and for internal access — Athena, EMR, a Glue job — it remains the default and the simplest choice. Switching to OAuth only pays off when the Iceberg catalog crosses an organizational boundary.
Here are the moves that matter.
Inventory who accesses the Iceberg catalog today. Look for IAM keys that were handed to a partner, a SaaS connector, or a self-hosted engine. Those are the ones carrying the risk: a static key distributed outside your perimeter.
Switch third-party access to OAuth token exchange. For engines that speak Iceberg REST, configure the catalog to authenticate with OAuth 2.0 rather than SigV4, using AWS Sign-In as the identity provider.
Delete the static keys that become redundant. Once OAuth access is live and verified, revoke the corresponding access keys. A key that no longer exists cannot leak.
Keep Lake Formation as the decision point. The bearer token does not replace fine-grained policy. Keep limiting access table by table and column by column in Lake Formation.
Verdict
If you federate Iceberg tables to third-party engines — a SaaS platform like Snowflake or Starburst, a self-hosted Trino, a remote DuckDB — enable OAuth token exchange now and retire the IAM keys you gave them: the payoff is a secret surface reduced to minutes of validity, with no change to your governance model. If all your access stays inside AWS — Athena, EMR, Glue jobs — SigV4 remains the right tool and there is no reason to move. The decision fits in one sentence: OAuth is for the boundary of your organization, not for its interior.