Esta página ha sido traducida del inglés por la comunidad.Aprende más y únete a la comunidad de MDN Web Docs.
Autenticación HTTP
HTTP nos brinda un marco general para el control de acceso y de autenticación. El esquema de autenticación HTTP más común es la autenticación "Basic". Esta página presenta el framework general de autenticación HTTP y muestra cómo restringir el acceso a tu servidor con la autenticación HTTPBasic.
El marco general de autenticación HTTP
RFC 7235 define el marco de autenticación HTTP que puede ser usado por un servidor para revisar la solicitud de un cliente y por un cliente para proveer información de autenticación. El flujo de la revisión y la respuesta funciona de la siguiente manera: El servidor responde al cliente con un estado de respuesta401 (Unauthorized) y devuelve al cliente información sobre cómo autorizarse con un encabezado de respuestaWWW-Authenticate que contiene al menos una revisión. Un cliente que quiera autenticarse con un servidor puede hacerlo incluyendo un encabezado de solicitudAuthorization con sus credenciales. Normalmente un cliente hará una solicitud de contraseña al usuario y luego enviará la solicitud incluyendo el encabezadoAuthorization correcto al servidor.
En el caso de una autenticación "Basic" como la mostrada en la figura, el intercambio sedebe realizar sobre una conexión HTTPS (TLS) para que sea seguro.
Autenticación Proxy (Proxy Authentication)
El mismo mecanismo de desafío y respuesta puede ser usada paraautenticación por proxy. En este caso, es el proxy el que hace de intermediario y requiere la autenticación. Ambas autenticaciones (autenticación del recurso y autenticación en el proxy) pueden coexistir juntas, pero entonces es necesario un conjunto de cabeceras y códigos de estado diferentes. En el caso de los proxys, el código de estado para requerir autenticación es407 (Proxy Authentication Required), la cabecera de respuestaProxy-Authenticate contiene al menos un requerimiento aplicable en el proxy, y la cabecera de peticiónProxy-Authorization es usada para proveer la credencial en el servidor proxy.
Prohibición de Acceso (Access Forbbiden)
Si el servidor proxy recibe unas credenciales válidas que no son adecuadas para acceder a un determinado recurso, el servidor respondera con el código de estado403Forbidden. Diferente al código de estado401Unauthorized o407Proxy Authentication Required, donde la autenticación es imposible para ese usuario.
CabecerasWWW-Authenticate yProxy-Authenticate
Las cabeceras de respuestaWWW-Authenticate yProxy-Authenticate definen el método de autenticación que debe ser usado para obtener acceso a un recurso. Ellas especifican que esquema de autenticación debe ser usado para que el cliente que quiera autenticarse sepa como hacerlo. La síntaxis para estas cabeceras es la siguiente:
WWW-Authenticate: <type> realm=<realm>Proxy-Authenticate: <type> realm=<realm>
En el ejemplo,<type> es el esquema de autenticación ("Basic" es el esquema de autenticación mas usado e introducido enesta página mas abajo). La palabrarealm es usada para describir el área que protegida o para indicar el alance de la protección. Puede ser un mensaje como "Access to the staging site" o algo similar, pero que sea explicativo para que el usuario sepa que espacio intenta acceder.
Cabeceras Authorization yProxy-Authorization
La cabecera de consultaAuthorization yProxy-Authorization contiene las credenciales para autenticar a un user agent con un servidor (proxy). Aquí, el tipo es necesario necesario siguiendo las credenciales que pueden estar codificadas o encriptadas dependiendo de que tipo de esquema de autenticación se esté usando:
Authorization: <type> <credentials>Proxy-Authorization: <type> <credentials>
Esquemas de autenticación
El marco general de autenticación HTTP es usado por varios esquemas de autenticación. Los esquemas pueden diferenciarse por la dureza en la seguridad y en su disponibilidad en software de clientes o servidores.
El esquema de autenticación mas común es "Basic", que es introducido con mas detalle abajo. IANA mantiene unalista de esquemas de autenticación, pero existen otros esquemas ofrecidos por proveedores de servicios, como Amazon AWS. Los esquemas de autenticación incluídas:
- Basic (verRFC 7617, credenciales codificadas en base64 . Ver mas abajo para mas información.),
- Bearer (verRFC 6750, bearer tokens de acceso en recursos protegidos mediante OAuth 2.0),
- Digest (verRFC 7616, hash MD5 solo soportado en Firefox, verError 472823 en Firefox para hash SHA-256),
- HOBA (verRFC 7486 (borrador),HTTPOrigin-BoundAuthentication, basado en firma digital),
- Mutual (verdraft-ietf-httpauth-mutual),
- AWS4-HMAC-SHA256 (verAWS docs).
Esquema de autenticación Basic
El esquema de autenticación HTTP "Basic" está definido enRFC 7617, que transmite las credenciales como un par usuario/contraseña codificado usando base64.
Seguridad de la autenticación básica
Como el usuario y la contraseña son pasados a través de la red como texto plano (éste es codificado en base64, pero base64 puede ser decodificado), el esquema de autenticación básico no es seguro. HTTPS / TLS debe ser usado junto a la autenticación básica. Sin éstas mejoras de seguridad, la autenticación básica no debe ser usada para proteger información sensible o valiosa.
Restringiendo acceso con Apache y autenticación básica
Para proteger por contraseña un directorio en un servidor Apache, necesitas usar los ficheros .htaccess y .htpasswd.
El fichero .htaccess normalmente tiene esta forma:
AuthType BasicAuthName "Access to the staging site"AuthUserFile /path/to/.htpasswdRequire valid-user
El fichero .htaccess hace una referencia al fichero .htpasswd, que contiene en cada línea un nombre de usuario y su respectiva contraseña separadas por dos puntos (":"). En este ejemplo no puedes ver la contraseña porque estáencriptada (utilizando md5 en este caso). Además, puedes nombrar el fichero .htpasswd de forma diferente si tu quieres, pero teniendo en cuenta que no debería ser accesible por nadie. (Apache está configurado normalmente para prevenir el acceso a ficheros .ht*).
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
Restringiendo acceso con nginx y autenticación básica
En el caso de nginx necesitarás especificar la localización a proteger y usar la directivaauth_basic, que provee el nombre del área protegida. La directivaauth_basic_user_file apunta al fichero .htpasswd que contiene las credenciales de usuario encriptadas, como en el ejemplo de Apache de mas arriba.
location /status { auth_basic "Access to the staging site"; auth_basic_user_file /etc/apache2/.htpasswd;}Acceso usando credenciales en la URL
Muchos clientes también le permiten evitar el mensaje de inicio de sesión enviando el usuario y la contraseña codificados por la URL.
https://username:password@www.example.com/
El uso de estas URLs está obsoleto. En Chrome, la cadena usuario:contraseña@ dentro de URLs incluso escortadapor razones de seguridad. En Firefox se comprueba si el sitio actualmente requiere una autenticación, y de no ser así, Firefox avisará al usuario con un mensaje "Está a punto de iniciar sesión en el sitiio "www.example.com" con el usuario "username", pero el sitiio web no requiere autenticación. Puede ser un intento de engañarlo.".