Pular para o conteúdo principal

Sessões e autenticação multifator

O COBRES mantém sessões de equipe e sessões Audience separadas. A escolha do fluxo depende da pessoa e da superfície acessada.

Equipe: console e backoffice​

O login humano recebe e-mail, senha e plano de acesso. A API emite um token de acesso; a renovação usa cookie HttpOnly pela rota POST /api/v1/auth/refresh. O token de acesso não é uma chave de integração.

Políticas da organização podem exigir MFA, limitar métodos e definir modo de sessão. Uma credencial marcada como troca obrigatória precisa concluir a mudança de senha antes das operações protegidas. O backend responde com códigos específicos, como password_change_required, mfa_enrollment_required e mfa_challenge_required.

A pessoa pode consultar suas sessões em /api/v1/me/sessions. A administração de sessões de outro membro exige a permissão prevista para a organização. Revogar uma sessão ou bloquear a pessoa deve ser feito pelo fluxo próprio, não pela limpeza apenas do armazenamento local do navegador.

Portal do credor​

O plano Audience usa EndUser, chave de assinatura própria e cookie de refresh sg_refresh_audience. O prefixo HTTP é /api/audience/v1.

O acesso é sem senha, por portas habilitadas como link de e-mail, código de e-mail e provedores sociais. Login por telefone e pré-cadastros dependem de capacidades e configuração; não presuma que estejam habilitados em toda organização.

Um identity JWT ou uma chave sgk_ não autentica no Audience. Da mesma forma, o token Audience não autentica nas rotas da equipe.

MFA e ações sensíveis no portal​

O segundo fator opcional do Audience é TOTP. SMS, quando habilitado, é um método primário de entrada, e não o segundo fator.

Ações sensíveis, como exclusão da conta, configuração de MFA e determinadas mudanças de contatos, podem exigir autenticação recente. 403 recent_login_required pede reautenticação na mesma sessão. O cliente deve concluir essa etapa e repetir a intenção original; não deve executar envios automáticos de códigos ao montar uma tela.

Tratamento correto de falhas​

Uma indisponibilidade de banco responde 503 unavailable, preservando a distinção de uma sessão recusada. Não encerre a sessão ao receber qualquer erro HTTP. Respeite Retry-After e acompanhe o código de erro.

As instruções operacionais de identidade do portal estão em RUNBOOK-AUDIENCE-IDENTITY.md, na raiz de application/.