http://www.flickr.

com/photos/kosmar/62381076

Tema 3: Javascript

Parte IIIb:
Seguridad en
APIs REST
Texto
Autentificacin y
autorizacin

Autentificacin
basada en
tokens

Seguridad en APIs REST

Token de autentificacin

JS parte IIIb: Seguridad en REST

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 aplicacin

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

JS parte IIIb: Seguridad en REST

4

Algunos detalles

JS parte IIIb: Seguridad en REST

Cmo 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

5

OAuth

JS parte IIIb: Seguridad en REST

Para que una app pueda acceder a servicios de terceros sin que el
usuario tenga que darle a la app sus credenciales del servicio

6

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

Autentificacin
basada en
cookies
(sesiones)

Seguridad en APIs REST

Sesiones

JS parte IIIb: Seguridad en REST

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

8

Cookies

JS parte IIIb: Seguridad en REST

9

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

Mantenimiento de sesiones

JS parte IIIb: Seguridad en REST 10

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

Autentificacin con sesiones

JS parte IIIb: Seguridad en REST 11

Tras hacer login, guardamos en la sesin 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 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]}"
end
end

get '/salir' do
session.clear
"adios"
end

Cookies vs. tokens

JS parte IIIb: Seguridad en REST 12

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

Autentificacin
HTTP estndar

Seguridad en APIs REST

Pero esto no es RESTful!

JS parte IIIb: Seguridad en REST 14

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