Texto

http

://w

ww

.flic

kr.c

om/p

hoto

s/ko

smar

/623

8107

6

Tema 3: Javascript

Autentificacin y autorizacin

Parte IIIb: Seguridad en APIs REST

Seguridad en APIs REST

Autentificacin basada en tokens

JS parte IIIb: Seguridad en REST

Token de autentificacin

Un valor que nos autentifica frente al servidor

Normalmente se consigue tras hacer login con un usuario/contrasea tradicionales

A diferencia de una contrasea, se puede anular o hacer caducar sin causar excesivas molestias al usuario

3

Flujo de aplicacin4

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token

JS parte IIIb: Seguridad en REST

Algunos detallesCmo se genera el token?

Normalmente un hash calculado con algn dato (p.ej. login del usuario) + clave secreta. Hay algoritmos estndar (HMAC, )

El token completo podra ser el login + Hash (ejemplo: http://blog.earaya.com/blog/2012/08/14/hmac-user-authentication/)

!Cmo comprueba el servidor que es vlido?

a) Generando de nuevo el Hash y comprobando si es igual que el que enva el usuario

b) O bien habiendo almacenado el Hash en una B.D. asociado al usuario y simplemente comprobando que coincide

5JS parte IIIb: Seguridad en REST

OAuth

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 confas lo suficiente como para meter tu login y password de FB

Es el estndar en APIs REST abiertos a terceros

Se basa en el uso de un token de sesin

6JS parte IIIb: Seguridad en REST

Seguridad en APIs REST

Autentificacin basada en cookies (sesiones)

Sesiones

Recordemos que HTTP es un protocolo sin estado

De un ciclo peticin/respuesta al siguiente ni cliente ni servidor recuerdan nada (Hi, Im a server!!)

!Pero en la mayora de aplicaciones web del MundoReal existe el concepto de sesin de trabajo

S se recuerdan ciertos datos mientras vamos navegando entre pginas (usuario autentificado, carro de la compra, )

Los frameworks de programacin web proporcionan al desarrollador la abstraccin de sesin: almacn de datos propio de cada usuario

8JS parte IIIb: Seguridad en REST

Cookies

Pares nombre=valor. A partir del momento en que se crean, el navegador las enva con cada peticin HTTP al servidor desde el que se crearon

9

JS parte IIIb: Seguridad en REST

Mantenimiento de sesiones

La mayor parte de frameworks de programacin en el lado del servidor generan automticamente cookies pseudoaleatorias lo suficientemente largas para ser usadas como id de sesin

Esto permite almacenar datos en el servidor exclusivos de cada usuario

El id de sesin sirve como clave para recuperar los datos

10JS parte IIIb: Seguridad en REST

Autentificacin con sesiones

Tras hacer login, guardamos en la sesin un flag indicando que el cliente se ha autentificado correctamente

11

use Rack::Session::Pool, :expire_after => 60*60!get '/entrar' do if (params[:login] ... #aqu habra 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]}" endend !get '/salir' do session.clear "adios"end

JS parte IIIb: Seguridad en REST

Cookies vs. tokens

Ventajas de las cookies

Las sesiones estndar de PHP, JavaEE, .NET, Rails, etc. usan cookies por defecto. Los tokens hay que gestionarlos manualmente

!!Ventajas de los tokens

Se pueden usar tambin en aplicaciones nativas (p.ej. mviles)

El dominio del servicio de autenticacin puede ser distinto al del API

12JS parte IIIb: Seguridad en REST

Seguridad en APIs REST

Autentificacin HTTP estndar

Pero esto no es RESTful!

Segn REST no debe haber estado Otra posibilidad: enviar las credenciales en cada peticin restringida

Precisamente eso hace HTTP Basic, dentro del estndar HTTP.

Si el cliente sabe que un recurso est protegido puede enviar en la cabecera Authorization el login y el password con codificacin Base64

No es un mecanismo de cifrado, es solo para poder enviar correctamente cualquier carcter 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 respondera con un cdigo de estado 401. Si no es AJAX el navegador mostrara el tpico cuadro de dilogo de login

14JS parte IIIb: Seguridad en REST