Parte IIIb: Seguridad en APIs REST

Transcripción

1 Tema 3: Javascript Parte IIIb: Seguridad en APIs REST Texto Autentificación y autorización

2 Autentificación basada en tokens Seguridad en APIs REST

3 Token de autentificación 3 Un valor que nos autentifica frente al servidor Normalmente se consigue tras hacer login con un usuario/contraseña tradicionales A diferencia de una contraseña, se puede anular o hacer caducar sin causar excesivas molestias al usuario

4 Flujo de aplicación 4

5 Algunos detalles 5 Cómo se genera el token? Normalmente un hash calculado con algún dato (p.ej. login del usuario) + clave secreta. Hay algoritmos estándar (HMAC, ) El token completo podría ser el login + Hash (ejemplo: blog.earaya.com/blog/2012/08/14/hmac-user-authentication/)! Cómo comprueba el servidor que es válido? a) Generando de nuevo el Hash y comprobando si es igual que el que envía el usuario b) O bien habiendo almacenado el Hash en una B.D. asociado al usuario y simplemente comprobando que coincide

6 OAuth 6 Para que una app pueda acceder a servicios de terceros sin que el usuario tenga que darle a la app sus credenciales del servicio Ejemplo: una app que permite publicar en tu muro de FB, pero en la que no confías lo suficiente como para meter tu login y password de FB Es el estándar en APIs REST abiertos a terceros Se basa en el uso de un token de sesión

7 Autentificación basada en cookies (sesiones) Seguridad en APIs REST

8 Sesiones 8 Recordemos que HTTP es un protocolo sin estado De un ciclo petición/respuesta al siguiente ni cliente ni servidor recuerdan nada (Hi, I m a server!!)! Pero en la mayoría de aplicaciones web del MundoReal existe el concepto de sesión de trabajo Sí se recuerdan ciertos datos mientras vamos navegando entre páginas (usuario autentificado, carro de la compra, ) Los frameworks de programación web proporcionan al desarrollador la abstracción de sesión : almacén de datos propio de cada usuario

9 Cookies 9 Pares nombre=valor. A partir del momento en que se crean, el navegador las envía con cada petición HTTP al servidor desde el que se crearon

10 Mantenimiento de sesiones 10 La mayor parte de frameworks de programación en el lado del servidor generan automáticamente cookies pseudoaleatorias lo suficientemente largas para ser usadas como id de sesión Esto permite almacenar datos en el servidor exclusivos de cada usuario El id de sesión sirve como clave para recuperar los datos

11 Autentificación con sesiones 11 Tras hacer login, guardamos en la sesión un flag indicando que el cliente se ha autentificado correctamente use Rack::Session::Pool, :expire_after => 60*60! get '/entrar' do if (params[:login]... #aquí habría que comprobar si el login es correcto session[:usuario] = params[:login] end! get '/ver' do if (session[:usuario].nil?) status 403 else "hola #{session[:usuario]}" end end! get '/salir' do session.clear "adios" end

12 Cookies vs. tokens 12 Ventajas de las cookies Las sesiones estándar de PHP, JavaEE,.NET, Rails, etc. usan cookies por defecto. Los tokens hay que gestionarlos manualmente!! Ventajas de los tokens Se pueden usar también en aplicaciones nativas (p.ej. móviles) El dominio del servicio de autenticación puede ser distinto al del API

13 Autentificación HTTP estándar Seguridad en APIs REST

14 Pero esto no es RESTful! 14 Según REST no debe haber estado Otra posibilidad: enviar las credenciales en cada petición restringida Precisamente eso hace HTTP Basic, dentro del estándar HTTP. Si el cliente sabe que un recurso está protegido puede enviar en la cabecera Authorization el login y el password con codificación Base64 No es un mecanismo de cifrado, es solo para poder enviar correctamente cualquier carácter por HTTP En HTTP Digest se hace un hash MD5 de login y password, lo que mejora bastante la seguridad Si el cliente intenta inadvertidamente acceder a un recurso protegido con HTTP Basic el servidor respondería con un código de estado 401. Si no es AJAX el navegador mostraría el típico cuadro de diálogo de login