Autenticação
O Restorm não tem uma lista pendente “tipo de autenticação”. Tem algo mais geral: o pedido de autenticação, um pedido de pleno direito cuja função é produzir cabeçalhos para os outros.
A vantagem: qualquer esquema pode ser modelado, incluindo os que nenhuma lista pendente prevê — uma troca em duas etapas, um token assinado, uma API caseira. O inconveniente: é preciso escrevê-lo uma vez.
Criar uma rota de autenticação
Section titled “Criar uma rota de autenticação”Clique com o botão direito numa pasta de variáveis ▸ Adicionar ▸ Pedido de autenticação.
Configure primeiro a chamada como qualquer pedido HTTP: método, URL, cabeçalhos, corpo. Depois abra o seu separador Configuração, que reúne as três definições próprias da autenticação.
Cabeçalhos produzidos
Section titled “Cabeçalhos produzidos”A lista dos cabeçalhos que esta rota irá injetar em qualquer pedido que a referencie. Cada valor é uma expressão avaliada sobre o corpo da resposta do pedido de autenticação.
| Cabeçalho | Valor |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Expiração (segundos)
Section titled “Expiração (segundos)”Uma expressão, igualmente avaliada sobre o corpo da resposta, que indica a
duração de validade em segundos — tipicamente {{expires_in}}. Deixada vazia, o
token nunca expira por si próprio.
Códigos de erro de autenticação
Section titled “Códigos de erro de autenticação”Os códigos de estado HTTP que, recebidos por um pedido que utiliza esta rota,
desencadeiam uma renovação do token seguida de uma nova tentativa automática.
Por predefinição: 401 e 403.
Dois termos, uma só coisa
Section titled “Dois termos, uma só coisa”Um pedido de autenticação é o elemento que cria na árvore. Uma rota de autenticação é esse mesmo elemento visto a partir de outro pedido, no seletor que o associa. Os dois termos designam a mesma entidade, em dois pontos da interface.
Associar uma rota a um pedido
Section titled “Associar uma rota a um pedido”No separador do pedido, na smartbar, um seletor Rota de autenticação lista as rotas da pasta de variáveis. O rótulo predefinido é Sem autenticação.
Uma vez associada, os cabeçalhos produzidos são injetados em cada envio, o token
fica em cache até expirar, e um 401 provoca uma renovação transparente.
Receitas correntes
Section titled “Receitas correntes”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Pedido: POST https://auth.exemple.test/oauth/token, corpo
x-www-form-urlencoded com grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(sendo o segredo um valor de tipo Segredo).
Cabeçalho produzido: Authorization = {{token_type}} {{access_token}}.
Expiração: {{expires_in}}.
Não é necessário nenhum pedido se já tiver as credenciais: basta colocar o cabeçalho no pedido (ou na pasta):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
Chave de API
Section titled “Chave de API”Basta um cabeçalho ou um parâmetro de consulta:
X-API-Key = {{apiKey}}, sendo a chave uma variável de tipo Segredo.
Token obtido em duas chamadas
Section titled “Token obtido em duas chamadas”Crie um cenário: primeira chamada, extração
do código intermédio, segunda chamada, e depois Definir variável para colocar
o token nas variáveis de execução. Os pedidos seguintes do cenário leem-no com
{{jeton}}.
O que a importação faz
Section titled “O que a importação faz”Ao importar uma especificação, os esquemas de segurança declarados são traduzidos em cabeçalhos ou parâmetros pré-configurados, com uma variável de ambiente criada para si:
| Esquema na especificação | O que o Restorm coloca |
|---|---|
apiKey (cabeçalho ou consulta) | Um par nomeado a partir do esquema, valor {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Resta-lhe apenas preencher a variável, ou substituí-la por uma rota de autenticação se quiser a renovação automática.
Credenciais nativas por protocolo
Section titled “Credenciais nativas por protocolo”Alguns protocolos não passam por cabeçalhos HTTP. As suas credenciais são campos do próprio pedido:
| Protocolo | Campos |
|---|---|
| MQTT | username, password, identificador do cliente |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | Mecanismo SASL (plain, scram-sha-256, scram-sha-512), identificador, palavra-passe, TLS |
| STOMP | Cabeçalhos login e passcode do CONNECT |
| gRPC | Metadados da chamada |
Cada uma destas palavras-passe aceita um valor de tipo Segredo.