Este es un tema que suele causar bastante confusión en la gente que se enfrenta con este problema por primera vez… hay tantos usuarios/passwords/niveles de autenticación que si no se presta mucha atención es fácil perderse.
Lo principal es entender que la autenticación es un proceso de comunicación entre dos entidades:
- Un cliente
- Un servidor
El cliente es el que se identifica (generalmente utilizando un par «nombre de usuario» + «contraseña») y el servidor es quien valida esas credenciales y devuelve algún tipo de identificador de acceso.
Podríamos pensarlo como el guardián de una discoteca en una fiesta privada. Cualquiera puede pararse ante el grandote y decirle que es uno de los invitados, pero si tu nombre no figura en la lista… por más que patalees, te vas a quedar afuera (Y aún si tu nombre figura, si te olvidaste el DNI… más vale pegar la vuelta).
En el caso de una aplicación web, existen muchos clientes y servidores interviniendo (De hecho, como vas a ver en breve, varios de estos servidores son a la vez clientes… ¡como para no confundirse!).
En el clásico esquema de un request:
El primer cliente que aparece es el browser (FireFox, Chrome, IE, etc…) y el servidor (En este post me voy a referir a «cliente» y «servidor» en su sentido como procesos, no como computadoras) es el webserver (Apache, NginX, etc…).
Entonces, el primer nivel de autenticación que debe superarse es este: el cliente que se conectó al webserver ¿presentó credenciales válidas?
Hoy en día es extremadamente raro encontrarse con este tipo de autenticación (por lo general, los servidores web están configurados de modo de aceptar conexiones de cualquier cliente sin pedir demasiado, pero se puede configurar este tipo de autenticación).
Una vez que el webserver dió la bandera verde, dependiendo de cuál haya sido el pedido del cliente, se le enviará una respuesta (generalmente un texto HTML).
El siguiente nivel de autenticación es el del webserver contra el servidor de base de datos:
Desde el punto de vista del servidor de base de datos, quien hace la conexión es el cliente (Es indiferente si se trata de una acción iniciada por un humano o por una computadora… en última instancia, la comunicación siempre es computadora-a-computadora…).
Entonces acá tenemos:
- Un cliente del webserver (el navegador)
- Un cliente del servidor de bases de datos (el webserver)
Al igual que en el ejemplo anterior, el cliente (en este caso el webserver), debe proveer de credenciales para que el servidor de bases de datos le permita acceder a sus servicios.
Es importante notar que las credenciales que utiliza el navegador para autenticarse ante el servidor web no tienen por qué ser las mismas que usa el webserver para conectarse a la base de datos (De hecho, lo más probable es que sean completamente diferentes).
Hasta ahora te mostré los niveles más bajos de autenticación (Los que podríamos llamar de infraestructura), pero existe un tercer nivel de autenticación: el de la aplicación.
En este nivel es responsabilidad del propio sistema (es decir tuya :)) decidir quién puede ingresar y qué puede hacer una vez adentro.
Pueden usarse diversos mecanismos para lograr este tipo de autenticación: el más simple (y común) es el almacenamiento de nombres de usuario y contraseñas en una base de datos a la que la aplicación tiene acceso. Otro método más elaborado es el uso de servicios de terceros (Google, Facebook, Twitter, etc…).
Entonces, recapitulando…
Cuando te enfrentás a algo como esto:
Lo que estás viendo es el resultado de la interpretación de HTML por parte de tu navegador.
Los datos que ingreses ahí van a ser recibidos primero por algún webserver y luego, a través de algún script (PHP por ejemplo), contrastados contra alguna base de datos (A la cual el script accederá utilizando sus propias credenciales).
Es por eso que, por lo general, una aplicación php tenga su propio username definido en su servidor de base de datos, aunque tenga un gran número de usuarios propios (visitantes registrados).
¿Te quedó alguna duda? ¡Espero tus comentarios!
- Cómo enviarencabezados SOAP desde PHP - 09/12/2024
- Por qué PHP 8 no satisface el requisito ^7.3 de composer - 09/12/2024
- Cómo usar PHPUnit - 03/12/2024