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

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?

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"

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).

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.

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

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.

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.

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.