auth rest¶

fonte

faz login em uma api externa e guarda o token retornado no contexto do pipeline, para que qualquer nó seguinte (tipicamente um api rest) o use como credencial de acesso.

quando usar¶

a api de destino separa autenticação da consulta de dados: primeiro você faz POST /login com usuário/senha, depois usa o token retornado em Authorization: Bearer <token> nas chamadas seguintes
integrações corporativas (erp, middleware interno) que expõem um endpoint de token próprio em vez de oauth2 padrão
apis que emitem tokens de curta duração e precisam de reautenticação periódica dentro de um mesmo pipeline (ex: dentro de um iterador de longa duração)

se a api já usa oauth2 client-credentials padrão, normalmente não é preciso este nó — configure auth_type = oauth2 diretamente no nó api rest.

configuração¶

endpoint de autenticação¶

campo	tipo	obrigatório	descrição
`url`	string	sim	endpoint de login. suporta `{{ pipeline.variavel }}`
`method`	enum	sim	`GET`, `POST`, `PUT` · padrão: `POST`
`timeout`	number	não	timeout em segundos · padrão: `30`
`headers`	lista	não	headers adicionais enviados na requisição de autenticação

credenciais¶

as credenciais (usuário/senha) são resolvidas exclusivamente pelo credential vault — não é possível digitar usuário/senha em texto puro na configuração do nó.

campo	tipo	obrigatório	descrição
`credential_id`	uuid	sim	credencial do tipo `basic` ou `form_data` selecionada no vault
`username_field`	string	não	nome do campo enviado com o usuário · padrão: `username`
`password_field`	string	não	nome do campo enviado com a senha · padrão: `password`
`credential_location`	enum	não	onde as credenciais são enviadas — ver abaixo · padrão: `body_json`

credential_location aceita:

valor	efeito
`body_json`	`{"username": "...", "password": "..."}` no corpo json
`body_form`	`application/x-www-form-urlencoded`
`query_params`	`?username=...&password=...` na url
`headers`	`X-Username` / `X-Password` como headers http

extração do token¶

campo	tipo	obrigatório	descrição
`token_path`	string	sim	caminho pontilhado até o token na resposta json · ex: `data.access_token` ou `token`
`token_prefix`	string	não	prefixo aplicado ao usar o token · padrão: `"Bearer "`
`store_as`	string	sim	nome da variável de pipeline · o token fica disponível como `{{ pipeline.<store_as> }}`

controle de expiração (reautenticação automática)¶

campo	tipo	descrição
`expires_in_field`	string	campo numérico (segundos) no response indicando validade do token · ex: `expires_in`
`token_expiry_field`	string	alternativa: campo com timestamp absoluto de expiração · ex: `expires_at`

quando um desses campos é configurado, a plataforma rastreia o instante de expiração do token. dentro de um iterador de longa duração, um nó auth rest colocado no início do loop é reexecutado automaticamente apenas quando o token expira — não a cada iteração.

exemplo¶

{
  "url": "https://api.parceiro.com/v1/auth/login",
  "method": "POST",
  "credential_id": "uuid-da-credencial-basic",
  "credential_location": "body_json",
  "username_field": "usuario",
  "password_field": "senha",
  "token_path": "data.access_token",
  "token_prefix": "Bearer ",
  "store_as": "token_parceiro",
  "expires_in_field": "expires_in"
}

o nó seguinte (api rest) referencia o token gerado:

{
  "auth_type": "pipeline_var",
  "bearer_token": "{{ pipeline.token_parceiro }}"
}

fluxo típico¶

[auth rest] → login, extrai token → {{ pipeline.token }}
      ↓
[api rest] → usa {{ pipeline.token }} como bearer_token
      ↓
[fábrica / quality gate / lakehouse writer]

reautenticação dentro de loops longos

ao processar milhares de itens em um iterador contra uma api com token de curta duração, coloque o nó auth rest dentro do corpo do loop e configure expires_in_field ou token_expiry_field — a plataforma só refaz o login quando necessário, evitando autenticar a cada iteração.

credenciais sempre no vault

não é possível configurar usuário/senha em texto puro neste nó. crie a credencial em configurações → credenciais antes de montar o pipeline.