Clase 20 - Autorización y Autenticación

Vista previa del material en texto

Clase 20 - Autorización y Autenticación
Autenticación y Autorización
Autenticación: ¡Identifícate! 
Ya habíamos trabajado con este concepto, en el cual el cliente debe primero identificarse para poder intentar acceder a un recurso.
La autenticación es el primer paso dentro de la vida de una sesión del cliente y el servidor. 
Para que un cliente pueda autenticarse, debe existir un registro previo almacenado en algún lado. El cliente envía un identificador (como un email) y el servidor lo buscará en su base de datos para saber si sí existe previamente. En caso de que sí, podrá responder con sus credenciales completas (no sensibles).
En caso de que un cliente intente autenticarse antes de haber generado un registro, el servidor no lo encontrará en la base y no habrá credenciales por devolverle.
Métodos de autenticación
· Usuario y contraseña: Es el método tradicional más utilizado, donde el usuario ingresa username o email y password para autenticarse.
· Sin contraseña (passwordless): Consiste en que, cada vez que queramos iniciar sesión a un recurso, se nos enviará al email un enlace que nos permitirá acceder sin necesidad de contraseña.
· Por redes sociales: Varias aplicaciones nos dan como opción iniciar sesión directamente con alguna red social. La ventaja principal es que se usan directamente los datos de esa cuenta social para hacer el inicio de sesión.
· Datos biométricos: Autentica usuarios mediante huellas dactilares.
· JWT(JSON Web Token): Este método open source permite la transmisión segura de datos entre las distintas partes. Comúnmente se utiliza para la autorización a partir de un par de claves que contiene una clave privada y una pública. 
· OAuth 2.0: Permite que mediante una API, el usuario se autentique y acceda a los recursos del sistema que necesita.
Autorización: definiendo el alcance de cada usuario
La autorización es el proceso por el cual el servidor decide si, a pesar de las credenciales que tienes, tienes permitido acceder a un recurso o no. Es decir, que autorizar no hace referencia a que el servidor no sepa quién eres. 
Debemos tener conjuntos de servicios jerarquizados para:
· Usuarios comunes.
· Usuarios premium (si trabajamos con un sistema de jerarquías)
· Administrador
O por ejemplo
· Un empleado.
· Un jefe
· Un administrador.
¡Importante!
Al ser procesos diferentes, no olvidemos que deben tener un código de status diferentes también:
· Para procesos fallidos de autenticación: 401
· Para usuarios rechazados por querer acceder a un recurso no autorizado: 403
Los status no son intercambiables. Nunca los uses a la ligera 
Tres posibles escenarios
1. El cliente quiere acceder a un recurso sin credenciales: El servidor lo rechazará con status 401 = Unauthorized. Obligándolo a primero autenticarse.
2. El cliente quiere acceder a un recurso con credenciales de una jerarquía no autorizada: El servidor lo rechazará con status 403 = Forbidden. Indicando que, si quiere acceder al recurso, necesitará credenciales con un rol superior.
3. El cliente quiere acceder a un recurso con credenciales de una jerarquía autorizada: El servidor corrobora que las credenciales son válidas y entrega el recurso solicitado.
Protegiendo las contraseñas: bcrypt
¿Te diste cuenta?
Si revisamos la base de datos que utilizamos en la clase anterior:
· Notarás que los usuarios se guardaron exactamente como se envió la información: incluyendo el password
· Por protección de datos, debemos guardar un password de manera que no pueda ser visualizado, ni siquiera por nosotros mismos. 
· Para ello, antes de guardar el password, se debe procesar éste con una operación conocida como hash
Usando bcrypt para poder hacer un hasheo
Debemos reconocer que no somos expertos en seguridad informática, por lo que trabajar con asuntos tan interiorizados a la seguridad nos puede complicar las cosas.
Para esto, bcrypt se encargará de realizar la operación de aseguración de nuestras contraseñas de una forma fácil y segura.
Para utilizarlo, sólo requeriremos instalarlo a partir de npm
A considerar:
Si una contraseña hasheada no puede ser revertida ni siquiera por nosotros mismos ¿Cómo sabremos si el cliente se loguea correctamente?
· No podemos hacer una comparación tan cruda como body.password == user.password. Se debe utilizar un recurso diferente.
· bcrypt tiene un proceso de comparación de passwords a partir de su función compare.
· Así, podremos saber si el cliente metió su password correctamente, sin tener que saber de cuál se trata
Estrategias de autenticación: Passport
¿Qué es Passport?
Passport es un generador de estrategias de autenticación y autorización, para mantener un código limpio, estructurado y altamente configurable.
Podemos utilizar y configurar múltiples estrategias de autenticación y autorización con passport. En esta ocasión crearemos una estrategia local. 
Reestructurando nuestro sistema de registro y login con Passport-local 
Configuración inicial
Passport debe instalarse en dos módulos:
· El primer módulo es el core de Passport.
· El segundo módulo es la estrategia a utilizar. 
Nuestra instalación se realizará entonces:
Seteamos el archivo de configuración
Crearemos un archivo passport.config.js en una carpeta de configuración:
Dicho archivo tendrá importados los elementos a utilizar. Nota que la lógica de hasheo y de usuarios se moverá de este lado, por ello importamos userService y las funciones de bcrypt.
Nociones importantes
· Passport local siempre requerirá dos cosas: username y password. Si passport no encuentra alguno de estos dos elementos, devolverá un error y no permitirá proceder con la estrategia
· Podemos cambiar el campo “username” para que tome el campo que nosotros queramos tomar como identificador, en este caso a nosotros no nos interesa nuestro username, realmente nos interesa el correo electrónico, así que podemos alterarlo con {usernameField: ‘valor’}
· Passport utiliza un callback “done”, el cual se resuelve de la siguiente manera:
· El primer parámetro de done es el error, si pasamos done(null) indicamos que no hay error.
· El segundo parámetro debe ser el usuario generado, por lo tanto, para devolver un usuario, hacemos done(null, user).
· Si pasamos done(null, false) indicamos que no hay error, pero el usuario no estará disponible.
· Cada estrategia que queramos configurar en passport es un middleware por sí solo, así que utilizaremos el elemento passport.use() para configurar diferentes middlewares/estrategias
Generación de estrategia de registro: Parte I
Generación de estrategia de registro: Parte II
Vamos a reestructurar app.js
Primero, vamos a importar el core de passport y la función de inicialización que hicimos en nuestro config, para utilizarlo en app.js
Ahora, en la sección donde declaramos todos nuestros middlewares, vamos a agregar la inicialización como se indica en las últimas líneas
Router también requerirá cambios
Ahora, para una implementación simple de passport, una estrategia suele tener dos rutas: una ruta del proceso principal, y otra ruta de “escape” por si el proceso falla en algún punto.
La ruta principal mandará a llamar el middleware de passport específicamente en la estrategia que solicitemos.
Reestructura de las rutas de registro
Serializar y deserializar
· Para restaurar el estado de autenticación a través de solicitudes HTTP, Passport necesita serializar usuarios y deserializarlos fuera de la sesión.
· Esto se hace de modo que cada solicitud subsiguiente no contenga las credenciales del usuario anterior.
· Se suele implementar proporcionando el ID de usuario al serializar y consultando el registro de usuario por ID de la base de datos al deserializar.
· Los métodos que proporciona Passport para esto son serializeUser y deserializeUser.
· El código ejemplo de ambos métodos se muestra a continuación.
· Se puede ver que el método serializeUser utiliza el ID del usuario y el deserializeUser 
Serializador y deserializador general (Aplica para todas las estrategias, se setea por fuera)
Creación de estrategiade login
Cambios de rutas de login
Y… ¿Cambió algo?
Si hicimos las cosas correctamente, no notaremos ningún cambio. El registro se habrá realizado exactamente igual a la primera implementación realizada. No hicimos esta reestructura para obtener algún resultado nuevo
La razón de implementar estas estrategias es dejar la lógica de autenticación y autorización a passport para que todo se encuentre controlado en una capa interna. 
En futuras aplicaciones tuyas o de tu empresa tendrás que autenticar a tus usuarios de MUCHAS formas, así que mejor controlar todas estas estrategias en un módulo específico para ello.