Autenticação e chaves de API

Implementação L1 em functions/src/api/. Cada pedido HTTP usa Authorization: Bearer <chave-ou-access-token>; não aceita ID tokens Firebase como credenciais da API/MCP. A Etapa 1 acrescenta access tokens OAuth opacos aed_atk_…, com consentimento Firebase separado; ver MCP/OAuth. O segredo é devolvido uma vez pela callable de criação/rotação e nunca deve aparecer em logs ou ficheiros versionados.

Formato: aed_live_<16 caracteres hex>_<43 caracteres base64url>; aed_test_… só funciona com o emulador Firestore configurado. Não há prefixo de exemplo utilizável nesta documentação.

Apenas SHA-256 do valor completo e prefixo ficam em organizations/{orgId}/apiKeys/{id}. apiKeyLookup/{prefix} resolve a organização/ID; não contém a chave. Não existe API_KEY_PEPPER. Comparação em tempo constante. Todas estas coleções são exclusivamente servidor; metadados seguros são devolvidos por callable.

Âmbitos explícitos: read permite GET; write permite POST. Uma chave só com write não pode ler. A organização vem da chave; um ID de outra organização não revela existência. Cada pedido revalida que o criador continua owner/admin e atualiza último uso, no máximo uma vez por minuto. Revogação e rotação têm efeito imediato; rotação revoga a anterior na mesma transação.

Gestão na app

Callables Firebase autenticadas, owner/admin, em europe-west1:

Nome	Entrada	Saída
listApiKeys	{}	{keys:[metadata]} (100 mais recentes)
createApiKey	{name,scopes:["read","write"],environment:"live"}	{key:metadata,secret}
rotateApiKey	{id}	{key:metadata,secret}
revokeApiKey	{id}	{id}

metadata: id, name, prefix, scopes, environment, createdAt, lastUsedAt, revokedAt. Não inclui hash. As mutações verificam o papel novamente dentro da transação. UI em Definições → API (settings/api); o gating de plano só se aplica com VITE_BILLING_ENABLED.

IAM HTTP fica com Walter/orquestrador. O código onRequest não declara invoker:'public'; a API exige a chave mesmo atrás do proxy autenticado. Nenhum deploy foi executado neste lote.