Accept Supabase OAuth token

[dobrac]

Allow using Supabase OAuth token instead of Team API Keys or user Access Tokens as authentication method.

Usage requires following headers for Team API endpoints:

X-Supabase-Token: ${Supabase JWT}
X-Supabase-Team: ${Team ID}

And following for Access Token endpoints:

X-Supabase-Token: ${Supabase JWT}

This change requires also infrastructure update and setting up supabase_jwt_secret in Google Secret Manager.

Note: The naming securitySchemes with 1 and 2 is there for having the verification in correct order.

[linear]

E2B-1563 Accept Supabase OAuth token

[0div]

LGTM, mostly nits, some questions tho:

• possible to write a test since this is now abstracted as an interface?
• if not, how to test this manually?
• what is the mitigation plan if secret key leaks? (and how to better store it?)
• how will we handle secret key rotation?

[dobrac]

• possible to write a test since this is now abstracted as an interface?

There could be some tests for sure now, especially if we merge the integration ones.

• if not, how to test this manually?

You can get the JWT secret from Supabase prod & get the Supabase token from the dashboard (or you can get the JWT secret from your Supabase instance and generate your own token, you just need to set "subject" to your user uuid).

Then just start the API locally and try to call http endpoints with the headers.

• what is the mitigation plan if secret key leaks? (and how to better store it?)
• how will we handle secret key rotation?

If you mean the tokens themselves, that would follow the same as if user token leaks (those supabase tokens are directly generated for the user). If the JWT secret leaks, we would have to manually rotate it. For secret saving, I agree that using Hashicorp Vault might be better, but we don't have it set up rn afaik.
To rotate JWT token, this is a good point, when we need to do it, we might need to temporarily accept more than one version of it. Do you have any better idea how to handle it?