Supported workload identity for hosted Edge Functions calling AWS

[buego-ai]

Hi Everyone,

Do hosted Supabase Edge Functions have any supported platform-issued workload identity, service identity, OIDC token or equivalent mechanism that can be used with AWS STS AssumeRoleWithWebIdentity or another AWS temporary-credential mechanism, without storing a long-lived AWS access key, private signing key, end-user JWT, or equivalent long-lived cross-cloud credential in the Edge runtime?

Please also confirm:

1. Is such a mechanism generally available today?
2. Is it supported for production use?
3. Does it provide a stable issuer / audience / subject contract suitable for AWS IAM trust policies?
4. Does any documentation exist that is not currently public?
5. Is there a recommended Supabase pattern for authenticating hosted Edge Functions to AWS using temporary credentials?

Context: an internal hosted Edge Function invokes a single AWS Lambda. No customer identity, end-user JWT or financial payload would form part of the authentication.

I have reviewed the public Edge Functions environment-variable reference and the OAuth 2.1 server documentation and found no such mechanism documented; I am not assuming that means none exists.

This is for a production architecture decision before any real customer financial data is processed through this boundary.

Appreciate your help.

[HIRATRA]

I think the key distinction here is between "can technically obtain temporary AWS credentials" and "Supabase provides a supported workload identity that AWS can trust."

If the hosted Edge Function does not expose a stable platform-issued OIDC identity with a documented issuer/audience/subject contract, I would avoid building an IAM trust policy around any internal or undocumented token format. That would make the authentication boundary dependent on an implementation detail that could change.

For a production setup, I'd expect the trust relationship to look roughly like:

Supabase Edge Function
→ platform-issued OIDC identity
→ AWS STS AssumeRoleWithWebIdentity
→ temporary IAM credentials
→ Lambda

The important part is that AWS should validate the issuer and claims directly, rather than relying on an end-user Supabase JWT.

If Supabase doesn't currently provide that workload identity for hosted Edge Functions, then I would consider an intermediary that owns the AWS trust boundary, or a narrowly scoped long-lived credential stored as a Supabase secret as a fallback. The latter obviously has a larger rotation/compromise surface, so I wouldn't treat it as equivalent to workload identity.

I'd also be interested in whether Supabase has an internal mechanism for this that isn't exposed as a public contract. If one exists, documenting the issuer/audience/subject semantics would be particularly important for IAM trust policies.

Given that you're making a production architecture decision involving financial data, I agree that "it works" isn't enough here — the supported identity contract and credential lifecycle matter just as much.