Autenticación básica de token de portador y HTTP


115

Actualmente estoy desarrollando una REST-API que está protegida por HTTP-Basic para el entorno de desarrollo. Como la autenticación real se realiza a través de un token, todavía estoy tratando de averiguar cómo enviar dos encabezados de autorización.

He probado este:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

Podría, por ejemplo, deshabilitar la autenticación HTTP para mi IP, pero como suelo trabajar en diferentes entornos con IP dinámicas, esta no es una buena solución. Entonces, ¿me estoy perdiendo algo?


2
Necesito autenticarme a través de HTTP Basic ya que el servidor de desarrollo está protegido con él y necesito la autenticación basada en tokens para la API. Pero como uso curl para probar la API, necesito una forma de enviar ambos encabezados de autenticación. Entonces, el primero (básico) para pasar HTTP básico y el segundo (token) para autenticarse en mi aplicación. Y sí, es mi propia creación.
Azngeek

1
¿Alguna vez has descubierto esto? Estoy agregando una recompensa
Adam Waite

4
Hola Adam, lamentablemente no. Ahora he cambiado la forma en que funciona la autenticación cambiando mi encabezado de autorización para el token a "x-auth", que no es un encabezado estándar.
Azngeek

1
Mi servidor nginx ni siquiera acepta 2 encabezados de autorización. Devuelve un 400 Bad request. Tonto.
Rudie

1
¿Qué tiene de malo usar un encabezado personalizado para su token de API? No veo por qué la gente de aquí ha "descartado" el uso de HTTP Basic Auth para mantener sus servidores de desarrollo / preparación lejos de miradas indiscretas.
Sunil D.

Respuestas:


68

Pruebe este para impulsar la autenticación básica en la URL:

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

Si el anterior no funciona, entonces no tiene nada que ver con él. Así que prueba las siguientes alternativas.

Puede pasar el token con otro nombre. Porque estás manejando la autorización de tu Aplicación. De modo que puede utilizar fácilmente esta flexibilidad para este propósito especial.

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

Observe que he cambiado el encabezado a Application-Authorization. Entonces, desde su aplicación, capture el token debajo de ese encabezado y procese lo que necesita hacer.

Otra cosa que puede hacer es, para pasar el tokena través de los POSTparámetros y agarrar el valor del parámetro desde el lado del servidor. Por ejemplo, pasando el token con el parámetro de publicación curl:

-d "auth-token=mytoken123"

1
Hola Sabuj, el problema no es la forma en que se pasa el nombre de usuario y la contraseña, sino que varios encabezados de autorización simplemente no funcionan. Mirando las especificaciones ( ietf.org/rfc/rfc2617.txt ) puedo ver que esto debería ser posible. Pero como también se indicó "" El agente de usuario DEBE optar por utilizar uno de los desafíos con el esquema de autenticación más sólido que comprenda y solicitar credenciales del usuario en función de ese desafío ". Así que, como escribí hace 2 días, necesitaba aprobar el token a un encabezado no estándar que está absolutamente bien cuando se
trabaja con

5
@Azngeek Curl envía ambos encabezados de autorización cuando realiza la tarea. Necesitas manejarlo desde el final de tu servidor. Simplemente ejecute su comando curl con ambos encabezados con -vparam. Encontrará que se envía Authorization: Basic Ym9zY236Ym9zY28=, Authorization: Bearer mytoken123en el encabezado de la solicitud. Desde el extremo de su servidor, si marca, encontrará que tiene un encabezado de autorización de esta manera Authorization: Basic Ym9zY236Ym9zY28=, Bearer mytoken123separado por comas. Entonces, pensé que debería sugerirte alternativas.
Sabuj Hassan

34

Estándar ( https://tools.ietf.org/html/rfc6750 ) dice que puede usar:

  • Parámetro de cuerpo codificado en forma: Autorización: Portador mytoken123
  • Parámetro de consulta de URI: access_token = mytoken123

Por lo tanto, es posible pasar muchos Bearer Token con URI, pero no se recomienda hacer esto (consulte la sección 5 del estándar).


4

Si está utilizando un proxy inverso como nginx en el medio, puede definir un token personalizado, como X-API-Token.

En nginx, lo reescribiría para que el proxy ascendente (su api de descanso) sea solo de autenticación:

proxy_set_header Authorization $http_x_api_token;

... mientras que nginx puede usar el encabezado de autorización original para verificar HTTP AUth.


3

Tuve un problema similar: autenticar el dispositivo y el usuario en el dispositivo. Usé un Cookieencabezado junto a un Authorization: Bearer...encabezado.


No está claro por qué el voto negativo. Me encontré con esta pregunta en busca de una respuesta a un problema relacionado; así es como lo resolví. El Cookieencabezado ya se usa con frecuencia para la autenticación.
Iiridayn

2

rizo --anyauth

Le dice a curl que descubra el método de autenticación por sí mismo y utilice el más seguro que el sitio remoto afirma admitir. Esto se hace primero haciendo una solicitud y verificando los encabezados de respuesta, induciendo así posiblemente un viaje de ida y vuelta adicional a la red. Esto se usa en lugar de configurar un método de autenticación específico, que puede hacer con --basic, --digest, --ntlm y --negotiate.


1

Existe otra solución para probar API en el servidor de desarrollo.

  • Establecer HTTP Basic Authenticationsolo para rutas web
  • Deje todas las rutas API libres de autenticación

La configuración del servidor web para nginxy Laravelsería así:

    location /api {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;

        auth_basic "Enter password";
        auth_basic_user_file /path/to/.htpasswd;
    }

Authorization: Bearer hará el trabajo de defender el servidor de desarrollo contra los rastreadores web y otros visitantes no deseados.


0

Con nginx puede enviar ambos tokens como este (aunque va en contra del estándar):

Authorization: Basic basic-token,Bearer bearer-token

Esto funciona siempre que el token básico sea el primero: nginx lo reenvía con éxito al servidor de aplicaciones.

Y luego debe asegurarse de que su aplicación pueda extraer correctamente el Portador de la cadena anterior.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.