Every Snowflake pipeline that calls an external API has the same dirty secret: somewhere in a secret object, a UDF, or an integration, there is a long-lived credential that someone has to rotate. On July 1, 2026, Snowflake shipped workload identity federation for Snowflake workloads that access external services into general availability, and it removes that credential from the picture entirely. Snowflake now acts as the OpenID Connect provider, issuing short-lived ID tokens that a Snowflake workload can present to an external service for authentication. No static key. No rotation calendar. No key accidentally expiring on a Friday night and breaking the pipeline. If you own the Snowflake bill or the security posture around it, this is the most consequential governance change of the quarter, and it costs you zero additional credits to use.
The mechanics are straightforward. You create a secret of type WORKLOAD_IDENTITY_FEDERATION, which makes Snowflake an OIDC provider with an issuer URL and registers the workload as an OIDC client with a subject identifier. You hand those two values to the external service so it can verify tokens. When the workload needs to authenticate, it calls SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN, receives an encoded ID token, and sends it to the service. The service verifies the token's signature against Snowflake's published public keys, checks the iss and sub and aud claims, and grants access. The whole trust flow is four steps, shown in the chart below. The key number is zero: zero static credentials to rotate, zero additional compute cost, zero new integration objects to license.
What exactly did Snowflake ship?
Snowflake's release notes for July 1, 2026 confirm that workload identity federation for Snowflake workloads accessing external services is now generally available. The feature lets Snowflake act as the OIDC provider when a Snowflake workload authenticates to an external service, which is a role reversal worth pausing on. In most federation setups, the external service or a dedicated identity provider plays the OIDC provider role. Here, Snowflake itself holds that role, which means the trust anchor lives inside your Snowflake account and follows your account's replication and failover behaviour.
The core objects and functions are minimal. A secret of type WORKLOAD_IDENTITY_FEDERATION is a schema-level object that stores the issuer URL and subject identifier. The system function SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN takes two arguments: the secret identifier and a JSON payload specifying the audience, and returns an encoded ID token conforming to the OIDC specification. There is a 1:1 relationship between the Snowflake workload and Snowflake as the OIDC provider, but the same secret can authenticate to multiple services, which means you do not proliferate secrets for every downstream API.
The DDL to create the secret is a single statement:
CREATE SECRET my_db.auth.my_workload
TYPE = WORKLOAD_IDENTITY_FEDERATION;Once the secret exists, you describe it to extract the two values the external service needs:
DESC SECRET my_db.auth.my_workload;The output includes two columns you hand to the external service administrator: workload_identity_federation_issuer, which is the issuer URL of Snowflake as the OIDC provider and maps to the iss claim, and workload_identity_federation_subject, which is the workload's OIDC client identifier and maps to the sub claim. The external service compares those values against the incoming token. If they match, the token is authentic.
How do you issue a token and use it?
The token issuance function is callable from any context where a Snowflake workload runs: a stored procedure, a UDF, a Snowpark Container Services workload, or a task. The call takes the secret and an audience identifier in JSON format:
SELECT SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN(
'my_db.auth.my_workload',
'{"aud": "example-cloud-service.com"}');The audience value becomes the aud claim of the returned ID token. You send that encoded token to the external service as a bearer credential. The service validates it by fetching Snowflake's public keys from the issuer URL's well-known endpoint, verifying the signature, and checking that the iss, sub, and aud claims match what you pre-registered. This is standard OIDC token verification on the service side, so any service that already supports OIDC identity federation, such as GitHub Actions, Google Cloud Workload Identity Federation, or HashiCorp Vault, can be configured to trust Snowflake-issued tokens without custom code.
A before-and-after makes the difference concrete:
| Step | Before (static credentials) | After (workload identity federation) |
|---|---|---|
| Credential storage | API key stored in a PASSWORD or OAUTH secret |
No stored credential. WIF secret holds issuer and subject only |
| Rotation | Manual or scheduled rotation every 60 to 90 days | No rotation. Tokens are short-lived and issued on demand |
| Blast radius if leaked | Static key works until revoked | Stolen token expires within minutes |
| Cross-service reuse | One secret per service | One WIF secret authenticates to multiple services via audience |
| Replication behaviour | Secret replicates but external trust may break on failover | Issuer and subject replicate unchanged. Trust survives failover |
The chart above shows the operational difference: two credentials to rotate with a 90-day burden in the static model, versus zero static credentials and a token lifetime measured in minutes under federation.
How does this behave under replication and failover?
This is where Snowflake's design choice to be the OIDC provider pays off. The docs are explicit about three replication properties. First, the federated identity is preserved across failover: the secret's issuer URL and subject identifier replicate unchanged, so after a failover the external service continues to recognise the same iss and sub claims. Second, ID tokens can only be issued from the primary account. Calling SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN in an account that is a read-only secondary fails. Third, token verification continues to work after failover because the issuer URL automatically resolves to the current primary account, which publishes the public keys the service uses to verify the token signature. You do not need to update the external service's configuration after a failover.
For teams running business continuity drills, this matters. A common failure mode with static credentials in a replicated setup is that the credential works in the primary but the external service's allow-list is pinned to a specific endpoint or account identifier that changes after failover. With workload identity federation, the trust relationship is defined by the issuer URL and subject, both of which follow the primary, so the failover is transparent to the external service as long as it can reach the issuer URL.
The one constraint to plan for is that token issuance is primary-only. If you have a workload running in a secondary account that calls external services, it cannot mint tokens until it becomes the primary. Design those workloads to either tolerate token issuance failure during a failover window or defer external calls until promotion completes.
What privileges and limits apply?
The secret is a schema-level object, so the standard CREATE SECRET privilege and USAGE on the containing database and schema apply. To issue tokens, the executing role needs USAGE on the secret. The relevant grants look like this:
GRANT USAGE ON SECRET my_db.auth.my_workload
TO ROLE my_pipeline_role;That is the only privilege the workload role needs. It does not need access to any external credential, and it does not need a stored key. From a governance standpoint, this tightens the blast radius considerably. If you pair this with the approach in our Snowflake RBAC and masking guide, you can isolate external-service access to a single role that holds nothing but USAGE on the WIF secret, which is about as narrow as a privilege model gets.
The docs do not publish a hard rate limit on SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN, but the design is clearly built for on-demand issuance per call to an external service, not for caching tokens at high frequency. Tokens are short-lived by OIDC convention, so a workload that calls an external API hundreds of times per minute should cache the token for its lifetime and reuse it, then request a new one when it expires. Caching logic belongs in your UDF or stored procedure, not in the secret.
How is it billed?
This is the question that usually has a catch, and here it does not. Workload identity federation introduces no additional credit charge. The secret is a metadata object. The token issuance function runs in the cloud services layer, not in a virtual warehouse, so it does not consume compute credits. The only cost surface is the warehouse that your UDF, stored procedure, or task runs in, and that is cost you were already paying before you switched from a static credential to a federated token.
If you want to confirm this in your own account, query the ACCESS_HISTORY view in SNOWFLAKE.ACCOUNT_USAGE to see which objects called the token function and whether any warehouse was involved:
SELECT query_id, query_text, user_name, role_name,
warehouse_name, start_time
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE query_text ILIKE '%SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN%'
AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;If warehouse_name is null for those rows, the function executed in the cloud services layer and consumed no compute credits. That is the expected result.
When is it the wrong choice?
This feature is not universal. The external service must support OIDC token verification, and specifically must let you configure a custom issuer URL and expected subject. Many SaaS APIs do. Some older or internal services do not, and for those you are stuck with API keys or OAuth refresh tokens for now. Before you invest in migrating a pipeline, confirm the external service's documentation supports configuring a custom OIDC issuer and audience validation.
The primary-only token issuance constraint also makes this a poor fit for active-active architectures where both accounts in a replication pair need to call external services simultaneously. You can only issue from the current primary, so a workload in a secondary account that needs to authenticate externally will fail until promotion. If your DR strategy requires the secondary to be continuously operational against external APIs, you need a static credential fallback or a different architecture.
Finally, if your external service cannot reach Snowflake's issuer URL over the public internet to fetch public keys, token verification will fail. This is not a feature for air-gapped or fully private endpoint scenarios unless the external service supports fetching keys from a Snowflake internal endpoint, which the current GA docs do not describe.
What should you do with it now?
Start with the highest-risk pipeline you have: the one where a static API key is stored in a secret and used by a task or UDF to call an external service. That is your first migration candidate because it has the most to lose from credential theft and the most to gain from elimination of rotation. Audit those secrets first:
SELECT name, secret_type, created_on, last_altered
FROM SNOWFLAKE.ACCOUNT_USAGE.SECRETS
WHERE secret_type IN ('PASSWORD', 'OAUTH')
ORDER BY created_on;For each secret, check whether the downstream service supports OIDC. If it does, create a WORKLOAD_IDENTITY_FEDERATION secret, register the issuer and subject with the service, swap the token issuance call into your UDF or procedure, and drop the static secret. Test in a non-production account first, and specifically test a failover drill to confirm the external service still authenticates after promotion.
Do not try to migrate every integration at once. Pick one, get the trust flow working end to end, and document the external service's configuration steps for your team. The external-side setup is the part that varies the most and the part that will eat your time.
The real shift
Workload identity federation is a quiet change with an outsized payoff. Snowflake is making a claim about where trust should live in a data platform: not in a vault of static keys that engineers have to babysit, but in the platform itself, issuing ephemeral credentials that expire before anyone can abuse them. For a data engineer, that is one fewer rotation ticket, one fewer 2 a.m. page, and one fewer entry in the secret-scanning audit. For a security team, it is a measurable reduction in standing credential risk. The cost is zero. The migration is incremental. The reason not to start is shrinking.
