POST/api/auth/sso/exchange
Último passo de um login SSO (SAML/OIDC): troca o código de utilização única emitido pelo callback por um Session JWT normal.
A página «POST /api/auth/sso/exchange — Referência API» cobre a área funcional indicada pela URL. O conteúdo existente é ampliado com o fluxo real, requisitos e limites conhecidos. A Zentor não possui sistema de Developer API Key. Para o dashboard são usados Session JWTs com duração de doze horas e Refresh Tokens de sete dias; TOTP e SSO são opcionais. Widget Embed Tokens são mostrados uma vez em texto simples e associados a Origins autorizadas. A documentação de `POST /api/auth/sso/exchange` deve ser lida como descrição técnica vinculativa deste endpoint concreto. São determinantes método, caminho, autenticação, campos obrigatórios, erros possíveis e se uma nova chamada produz o mesmo efeito. Esta secção https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange deve, portanto, conter apenas passos de integração rastreáveis e exemplos de resposta comprovados. Para chamar `/api/auth/sso/exchange`, o pedido é construído segundo a Registry. Rotas públicas não exigem Developer API Key geral, porque a Zentor não tem esse sistema. Rotas protegidas do widget utilizam o Embed Token mostrado uma vez e verificação de Origin. O estado HTTP e o conteúdo JSON devem ser avaliados em conjunto; um campo `ok` sozinho não substitui tratamento de erros. Nos testes de `POST /api/auth/sso/exchange` devem ser usados valores anonimizados. Dados reais de clientes, UUIDs produtivos, Session Tokens e timestamps concretos não pertencem a exemplos públicos. O limite conhecido da plataforma é 2.000 pedidos em 15 minutos; não existe limite individual diferente comprovado. Chamadas POST não idempotentes não devem ser repetidas cegamente após interrupção de rede ambígua. Erros típicos surgem por parâmetros obrigatórios em falta, tipos de dados errados, códigos de utilização única expirados, Origins não autorizadas ou registos inexistentes. A aplicação deve tratar estes casos separadamente e registar a mensagem de erro devolvida sem incluir segredos. Um pedido bem-sucedido confirma apenas este passo, não automaticamente sucesso posterior de e-mail, pagamento ou SSO. Isto é diretamente relevante para `POST /api/auth/sso/exchange`. A verificação técnica desta página deve basear-se na Registry em `app/frontend/src/content/api-reference/` e nas rotas backend correspondentes. Notas de teste live só podem afirmar o que foi realmente verificado. Um teste negativo ou analogia de código não é prova completa de sucesso. Deve distinguir-se claramente estrutura documentada, teste automatizado e comportamento live observado com segurança.
Autenticação e segurança
Não é necessária autenticação
Idempotente: Não
Parâmetros
code(body, string, obrigatório)— Código de troca de utilização única proveniente do redirect SSOPedido de exemplo
{"code":"<código de utilização única do redirect de callback SSO>"}Resposta de exemplo
{"ok":true,"token":"<JWT>","refreshToken":"<Refresh-Token>"}Códigos de erro
400 SSO_EXCHANGE_INVALID — Código de troca inválido, já utilizado ou expirado.Evidência de teste live
Caso negativo (400) com código inventado verificado live; o caso de sucesso exigiria um fluxo completo de redirect SAML/OIDC com Identity Provider real, não reproduzido neste ambiente de teste.