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:
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.
Buego is inquiring about the availability of a platform-issued workload identity for Supabase Edge Functions to securely authenticate with AWS services without storing long-lived credentials. They seek confirmation on the existence, production readiness, and documentation of such a mechanism, as it is crucial for a production architecture decision involving financial data.
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.