Autenticación

La pestaña Autenticación indica cómo demuestra una solicitud quién es. Elige un Tipo, rellena sus campos y Echolot añade las credenciales cada vez que se envía la solicitud. Define la autenticación una vez en una carpeta o en el espacio de trabajo y todas las solicitudes que contiene podrán usarla.

Mantén las credenciales fuera de los archivosCopy Anchor Link

Todos los campos admiten {{variables}}. Guarda contraseñas, tokens y claves en variables secretas, que viven en el llavero, y escribe {{password}} en el campo. Así el archivo de la solicitud no contiene ningún secreto y puedes subirlo al repositorio.

Cuando escribes un valor literal en un campo de credenciales, aparece un aviso debajo: Se guarda como texto sin cifrar en el archivo del espacio de trabajo. Haz clic en Trasladar al llavero y Echolot guarda el valor como variable secreta del espacio de trabajo y escribe {{name}} en su lugar.

Las credenciales que añade Echolot aparecen enmascaradas donde la página de la solicitud las muestra: en las cabeceras GENERADAS AUTOMÁTICAMENTE y en la vista previa de la URL bajo la barra de la URL.

Heredar de carpetas y del espacio de trabajoCopy Anchor Link

Heredar es la opción predeterminada. Una solicitud que hereda usa la autenticación de la carpeta más cercana por encima de ella que defina una y, si no hay ninguna, la del espacio de trabajo. Bajo Usa, la pestaña indica cuál se aplica, por ejemplo Folder “Orders”: Bearer Token, con un botón que la abre: Editar autenticación de la carpeta… o Editar autenticación del espacio de trabajo…. Si ningún nivel superior define autenticación, la solicitud no envía ninguna.

Una solicitud con autenticación propia la conserva, y su pestaña Autenticación muestra además una fila Autenticación del espacio de trabajo con la del espacio de trabajo y un botón para abrirla: Autenticación del espacio de trabajo…, o Configurar autenticación del espacio de trabajo… cuando el espacio de trabajo aún no tiene ninguna. Autenticación del espacio de trabajo… también está en la paleta de comandos (⌘K).

Para definir la autenticación de muchas solicitudes a la vez:

1. En la barra lateral, haz clic con el botón derecho en una carpeta y elige Ajustes de la carpeta…. Para el espacio de trabajo, usa Autenticación del espacio de trabajo… desde la pestaña Autenticación de una solicitud o desde la paleta de comandos, o haz clic en el selector de espacio de trabajo al pie de la barra lateral y elige Ajustes del espacio de trabajo….
2. Abre la pestaña Autenticación y elige un tipo. Una carpeta también puede heredar; el espacio de trabajo no. Bajo los ajustes, la pestaña indica cuántas solicitudes en Heredar usan esta autenticación.
3. Para OAuth 2.0, inicia sesión ahí mismo: la barra del token de la parte inferior funciona como en una solicitud (consulta OAuth 2.0), y todas las solicitudes que heredan la autenticación usan ese token. Obtener token guarda antes la autenticación. La barra solo muestra el token propio de la carpeta o del espacio de trabajo una vez guardada su autenticación, de modo que nunca muestra ni olvida un token que pertenece a la autenticación de un nivel superior.
4. Haz clic en OK.

En el ejemplo Alpenglow, la carpeta Orders define Token Bearer con {{token}}, y todas las solicitudes de pedidos lo heredan. Auth › Sign in rellena {{token}} a partir de su respuesta con una captura.

Elige un tipoCopy Anchor Link

Una cabecera Authorization que añades tú mismo en la pestaña Cabeceras se envía en lugar de la que añadiría la pestaña Autenticación.

BasicCopy Anchor Link

Rellena Nombre de usuario y Contraseña. Echolot los envía codificados en Base64 en la cabecera Authorization. Pruébalo con Echo › Basic auth en Alpenglow.

DigestCopy Anchor Link

Rellena Nombre de usuario y Contraseña. El primer envío va sin credenciales; cuando el servidor responde 401 con un desafío Digest, Echolot lo contesta una vez con una segunda solicitud. Ambas aparecen en el intercambio como saltos.

Token BearerCopy Anchor Link

Rellena Token, normalmente {{token}}. Prefijo es Bearer de forma predeterminada; cámbialo si el servidor espera otra palabra, o bórralo para enviar solo el token.

Clave de APICopy Anchor Link

Rellena Clave (el nombre de la cabecera o del parámetro, X-API-Key por defecto) y Valor, y elige dónde va en Añadir en: Cabecera o Consulta.

OAuth 2.0Copy Anchor Link

Echolot obtiene el token de acceso por ti y lo añade como Authorization: Bearer <token>.

En la parte inferior de la pestaña, la barra del token indica si hay un token. Haz clic en Obtener token:

• Código de autorización abre el navegador en la URL de autorización. Inicia sesión allí; Echolot recoge la redirección y muestra Termina de iniciar sesión en el navegador… hasta que lo haces.
• Código de dispositivo muestra Iniciar sesión en otro dispositivo con un código. Haz clic en Abrir (con el nombre de host de la página), introduce allí el código y apruébalo; Echolot espera con Esperando aprobación….
• Credenciales de cliente consulta directamente la URL del token. Con esta concesión no necesitas hacer clic en Obtener token: el primer envío obtiene un token por sí solo.
• Contraseña (obsoleta) envía el nombre de usuario y la contraseña a la URL del token, y tampoco necesita clic: el primer envío obtiene un token. Úsala solo con API antiguas que la exigen. La concesión está obsoleta porque la contraseña misma sale de tu Mac, así que prefiere Código de autorización cuando el servidor lo ofrezca.

Echolot no ofrece la concesión implícita, que también está obsoleta. La mayoría de los servidores que aún la ofrecen también ofrecen Código de autorización, en lo que se convierte una concesión implícita importada; comprueba que el servidor lo acepta.

Cuando hay un token, la barra indica Token de acceso en el llavero, con su tipo, cuándo caduca, si se renueva automáticamente y su ámbito. Obtener token nuevo lo sustituye; Olvidar lo elimina.

Cómo se guardan y se usan los tokens:

• Los tokens se guardan en el llavero, nunca en los archivos del espacio de trabajo.
• Un token pertenece a la solicitud, carpeta o espacio de trabajo que define la autenticación, y al entorno y los ajustes para los que se emitió: si cambias de entorno, o cambias la URL del token, el ID de cliente, el ámbito u otro ajuste que decide para quién es el token, se usa u obtiene un token propio y nunca se envía uno emitido para otra cosa. Las solicitudes que heredan OAuth de una carpeta comparten sus tokens. Olvidar elimina los tokens de todos los entornos.
• Cuando un token ha caducado, el siguiente envío lo renueva con su token de renovación. Un token de Credenciales de cliente o de Contraseña se obtiene de nuevo. Si no, el envío se detiene con Esta solicitud necesita un token OAuth: obtén uno antes en la pestaña Autenticación. o El token OAuth ha caducado y no se pudo renovar: obtén uno nuevo en la pestaña Autenticación.

Para probarlo, envía Auth › Orders with OAuth 2 en Alpenglow: usa Credenciales de cliente contra la API de demostración.

AvanzadoCopy Anchor Link

La mayoría de los servidores no necesitan nada de esto, así que está plegado bajo Avanzado. Se abre solo cuando algo de su interior está definido.

• Renovar automáticamente está activado de forma predeterminada. Desactívalo para enviar un token caducado tal cual y ver cómo responde la API. Para Credenciales de cliente y Contraseña se sigue obteniendo un primer token.
• URL de renovación es para los servidores cuyo punto de renovación no es la URL del token. Vacía significa la URL del token.
• Solicitud de autorización, Solicitud de token y Solicitud de renovación añaden parámetros para los servidores que quieren más que los campos estándar: access_type = offline de Google (para que entregue un token de renovación), resource para Azure AD, un tenant o una versión de la API. Cada fila tiene una clave, un valor (las variables funcionan, así que los secretos pueden quedarse en el llavero) y, en las solicitudes de token y de renovación, el lugar al que va: Cuerpo, Cabecera o URL. Un parámetro con el mismo nombre que uno estándar lo sustituye. Los parámetros de la solicitud de autorización van en la dirección de inicio de sesión, o en la solicitud de autorización del dispositivo para Código de dispositivo. Nunca sustituyen el state ni el desafío PKCE.

OAuth 1.0Copy Anchor Link

Para las API que aún usan OAuth 1.0: NetSuite, Magento y Adobe Commerce, los endpoints v1.1 de X y los enlaces de aplicación de Jira o Confluence Server, entre otras. Echolot firma cada solicitud con un token que ya tienes. No ejecuta el flujo de tres pasos que lo obtiene, y Postman tampoco.

1. Elige el Método de firma: HMAC-SHA1 (el más habitual), HMAC-SHA256, HMAC-SHA512, RSA-SHA1, RSA-SHA256, RSA-SHA512 o PLAINTEXT.
2. Rellena Clave de consumidor y Secreto de consumidor o, para RSA, una Clave privada (pégala, o haz clic en Elegir archivo PEM… para llevarla directamente al llavero).
3. Rellena Token de acceso y, salvo con RSA, Secreto del token. Déjalos vacíos para una solicitud que se hace antes de tener un token.
4. En Añadir en, elige Cabecera (Authorization: OAuth …, el valor predeterminado), URL o Cuerpo. Cuerpo firma dentro de un cuerpo de formulario, o en la dirección si la solicitud no tiene cuerpo.
5. Avanzado incluye Realm, URL de retorno y Verificador (para los pasos del flujo de tres pasos que haces a mano), Añadir oauth_version="1.0" (activado de forma predeterminada) e Incluir el hash del cuerpo en la firma (oauth_body_hash, para cuerpos que no son formularios).

Cada solicitud se firma al enviarla, con una marca de tiempo y un nonce nuevos, sobre el método, la dirección, su consulta y los campos de un cuerpo de formulario.

AWS SignatureCopy Anchor Link

Rellena ID de clave de acceso, Clave de acceso secreta, Región (us-east-1 por defecto) y Servicio (execute-api por defecto; s3, lambda, es y así sucesivamente). Token de sesión es solo para credenciales temporales. Cada solicitud se firma al enviarla, con la hora, el host y el cuerpo con los que sale.

JWT BearerCopy Anchor Link

Echolot firma un token nuevo en cada envío.

1. Elige el Algoritmo: HS256, HS384 o HS512 (HMAC con un secreto), RS256, RS384, RS512, PS256, PS384 o PS512 (clave privada RSA), o ES256 o ES384 (clave privada de curva elíptica).
2. Para HMAC, rellena Secreto; marca El secreto está en Base64 cuando el proveedor te lo dio así. Para una clave privada, pégala en Clave privada, o haz clic en Elegir archivo PEM…: la clave va directamente al llavero y el campo se refiere a ella por su nombre. Las claves pueden ser PEM PKCS #8, PKCS #1 o SEC 1.
3. Escribe los Claims como JSON. Pueden contener variables: {"sub": "{{userID}}"}.
4. Añade Campos de cabecera como kid si el servidor los necesita. alg y typ los define Echolot.
5. Añadir “iat” (fecha de emisión) está activado de forma predeterminada. Caduca tras añade exp con esos segundos de adelanto (300 por defecto); 0 no añade ninguno. Los claims que defines tú mismo en el JSON se conservan tal como los escribes.
6. En Añadir en, elige Cabecera (con un Prefijo, Bearer por defecto) o Consulta (con un nombre de Parámetro, token por defecto).

HawkCopy Anchor Link

Rellena ID y Clave, elige el Algoritmo (SHA-256 o SHA-1) y añade Datos de la app (ext) si el servidor los pide. Marca Incluir el hash del cuerpo en la firma para incluir el hash del contenido. Cada solicitud se firma con la hora, un nonce, el método, la ruta, el host y el puerto.

Akamai EdgeGridCopy Anchor Link

Rellena Token de cliente, Secreto de cliente y Token de acceso. Cabeceras que firmar es una lista separada por comas, normalmente vacía. Bytes del cuerpo firmados limita cuánto de un cuerpo POST se calcula en el hash (131072 por defecto).

NTLMCopy Anchor Link

Rellena Nombre de usuario y Contraseña, y Dominio y Estación de trabajo si tu servidor los necesita. Echolot habla NTLMv2: responde al desafío del servidor en la misma conexión, y los 401 permanecen en el intercambio como saltos.

NTLM autentica una conexión, no una solicitud, así que necesita HTTP/1.1. Con la versión de HTTP en Automático, Echolot usa HTTP/1.1 para las solicitudes NTLM; si eliges HTTP/2 o HTTP/3, el envío se rechaza. Consulta Ajustes de la solicitud.

Las credenciales se quedan con su origenCopy Anchor Link

Cuando una redirección lleva a otro origen (otro esquema, host o puerto), Echolot no lleva allí tus credenciales. Descarta:

• las cabeceras Authorization, Proxy-Authorization y Cookie,
• las cabeceras habituales de clave de API (X-API-Key, Api-Key, Apikey, X-Auth-Token, X-Access-Token, Private-Token, X-Functions-Key), la cabecera que usa tu autenticación Clave de API y cualquier cabecera cuyo valor contenga una variable secreta,
• la firma de Digest, AWS Signature, OAuth 1.0, Hawk, EdgeGrid y NTLM, y el certificado de cliente elegido para el primer host.

Los certificados y el proxy del nuevo host se aplican al salto que va hacia allí. Consulta Ajustes de la solicitud.

Entornos protegidosCopy Anchor Link

Obtener token también envía una solicitud. Cuando el entorno de la ventana está protegido, pide confirmación antes, igual que Enviar. Consulta Entornos protegidos.