Anlisis de protocolo OAuth2
Trabajo Prctico Final
Criptografa y Seguridad Informtica (66.69)
Fecha de entrega: / /2016
Profesores:
Ing. Juan Manuel Caracoche
Ing. Guillermo Wald
Ing. Leonardo Alabart
Grupo: 8
Integrantes:
1.
2.
3.
4.
Pablo Albanese. Padrn: 87803
Eliana Ventura. Padrn: 93376
Pedro Mayordomo Molina. Padrn: 99920
Jules Lambert. Padrn: 99886
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
Indice
1. Introduccin a OAuth2
a. Qu es OAuth2?
b. Funcionalidades
c. Versiones anteriores
d. Esquema de funcionamiento general
e. Empresas que actualmente utilizan OAuth2
2. Casos de uso
a. Obtencin de token de sesin y token de refresco
b. Utilizacin del token de sesin
c. Expiracin del token de sesin
d. Expiracin del token de refresco
3. Ventajas y desventajas de OAuth2
a. Ventajas
b. Desventajas
4. Implementacin
a. Introduccin
b. Registracin de nuestra aplicacin en MercadoLibre
c. Caso 1: Obtencin de token de sesin y token de refresco
d. Caso 2: Utilizacin del token de sesin
e. Caso 3: Expiracin del token de sesin
f. Caso 4: Expiracin del token de refresco
g. Algunas vulnerabilidades detectadas durante la implementacin
5. Conclusiones
6. Referencias
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
1.Introduccin a OAuth2
1.a. Qu es OAuth2?
OAuth2 es un protocolo abierto que nos permite la autorizacin segura de una API, este
protocolo permitir a terceros, estos ser el Cliente o consumidor, acceder a recursos
protegidos de un usuario, el Cliente es autorizado por el usuario.
Dicho de otro modo, se permitir que el usuario del sitio A comparta su informacin del sitio A
con el sitio B, sin compartir toda su identidad o recursos almacenados en el sitio A(el usuario
puede seleccionar la informacin compartida). Para ello ser necesario una autorizacin, para
permitir el acceso a los datos, adems de una autenticacin, para demostrar ser quien dices
ser.
Por lo tanto con este protocolo podremos lograr la integracin entre aplicaciones, sin compartir
las contraseas.
Es un estndar abierto, puesto que detrs de OAuth encontramos varias compaas
interesadas como Twitter ,Pownce , Ma.gnolia. La idea fue unificar todos los protocolos
cerrados , para conseguir un estndar que ayude a la integracin de aplicaciones Web .
1.b. Funcionalidades
OAuth es necesario para que el usuario se sienta seguro al entregar sus credenciales a la
aplicacin cliente.
Este protocolo es muy importante puesto que el usuario autoriza a que dicha aplicacin realice
algo con el nombre del usuario. La autorizacin est separada de la autenticacin, adems en
cualquier momento el usuario podr quitarle al cliente la autorizacin para poder acceder a los
recursos.
El proveedor primero autenticara si es el usuario quien dice ser y despus comprobar a qu
recursos est autorizada el cliente a acceder, esta decisin la tomar el usuario.
Posteriormente se explicar ms detalladamente el proceso.
1.c. Versiones anteriores
Su antecesor fue Oauth 1.0, aunque la introduccin de OAuth 2.0 lo ha dejado de lado adems
son totalmente incompatibles.
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
El primer borrador de OAuth se public el 3 de Octubre de 2007.Todo comenz con la
necesidad de diferentes empresas de encontrar un estndar abierto para delegar el acceso a
las API, varias personas con la misma necesidad se reunieron para discutir este tema.
OAuth 2.0 se centra en la simplicidad de desarrollo adems de proporcionar una autorizacin
especfica, ambos protocolos son incompatibles.
Uno de los participantes de este grupo de discusin era Blaine Cook, desarrollaba la
implementacin de OpenID para Twitter. Con el avance del proyecto varias empresas se fueron
interesando en Oauth como Google.
Finalmente fue publicado como RFC5849 , en abril de 2010.
1.d. Esquema de funcionamiento general
1.e. Empresas que actualmente utilizan OAuth2
Muchas empresas usan el protocolo OAuth , de parte del cliente muchas pginas web utilizan
este protocolo para cuando te loggeas , como es el ejemplo de Mercado Libre , Gmail , Twitter
Del lado del proveedor, se entiende como el sitio que ofrecer los recursos al cliente algunos
de los ms importantes son Facebook, Twitter o Google.
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
En el siguiente link de Wikipedia encontramos todos los proveedores que existen adems del
protocolo con el cual es compatible.
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
2. Casos de uso
En esta seccin vamos a ocuparnos de describir los casos de uso principales del protocolo
OAuth2. Previamente vamos a definir los actores que participan en los casos de uso:
Aplicacin Servidor: Es la aplicacin web que contiene usuarios que operan sobre ciertos
recursos que la aplicacin provee. Esta aplicacin desea que otras aplicaciones puedan
administrar esos recursos con autorizacin del usuario.
Aplicacin Cliente: Es la aplicacin web que desea hacer uso de recursos del usuario con la
debida autorizacin del mismo. Esta aplicacin previamente a los escenarios planteados se ha
registrado en la aplicacin Servidor como aplicacin autorizada para hacer uso de
determinados recursos de los usuarios y la aplicacin Servidor le ha concedido la autorizacin
para brindar ese servicio para lo cual le inform su ID de cliente y su cdigo secreto.
Usuario: Es la persona que desea darle acceso a los recursos que posee en la Aplicacin
Servidor a una Aplicacin Cliente. El acceso a recursos puede ser total parcial segn las
polticas de uso de la aplicacin Servidor.
Recurso: Se refiere a cualquier tipo de informacin que administre el usuario como suya en la
Aplicacin Servidor. Ejemplos: Datos personales, documentos, imgenes, informacin de
transacciones como publicaciones, emails, etc.
a.Obtencin de token de sesin y token de refresco
Actores involucrados: Usuario, Aplicacin Servidor, Aplicacin Cliente
Descripcin: Un Usuario quiere que una Aplicacin Cliente pueda hacer uso de determinados
recursos que posee en la aplicacin Servidor.
Contexto: La aplicacin cliente no posee autorizacin por parte del usuario y este mismo quiere
drselos.
1. Usuario accede a aplicacin cliente y decide darle acceso a determinados recursos,
presionando el botn de Inicio de sesin.
2. La aplicacin cliente redirecciona al usuario a una pgina determinada de antemano por
la aplicacin servidor, en la URL pasa por parmetros:
a. Cdigo de cliente
b. Cdigo secreto
c. URL de notificacin
d. Recursos solicitados
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
3. La aplicacin Servidor solicita al usuario que se identifique en caso de no estar
identificado y luego le pregunta si desea darle acceso los recursos solicitados por la
aplicacin Cliente.
4. El usuario acepta la solicitud
5. La aplicacin servidor realiza un GET HTML a la URL de notificacin enviada por la
aplicacin cliente pasndole por parmetro un cdigo de transaccin.
6. La aplicacin cliente utiliza este cdigo haciendo un POST HTML a una direccin
previamente pactada solicitando token de sesin y token de refresco.
7. La aplicacin servidor retorna el token de sesin y token de refresco para que sea
utilizado por la aplicacin cliente.
8. La aplicacin cliente notifica al usuario el resultado de la operacin.
La imagen 1 muestra el proceso de obtencin de token de sesin y refresco en forma grfica:
Imagen 1. Obtencin de token y refresh token inicial
En el caso de que en el paso 3. El usuario no acepte brindarle los permisos de acceso a los
recursos solicitados a la aplicacin cliente, la aplicacin servidor en el paso 5 notificar la
negativa del usuario a tal permiso.
Nota: Dependiendo de las polticas de uso de la aplicacin servidor el cdigo de transaccin
obtenido en el paso 5 tiene un perodo de expiracin determinado.
b.Utilizacin del token de sesin
Actores involucrados: Aplicacin servidor, aplicacin cliente
Descripcin: La aplicacin cliente solicita un recurso a la aplicacin servidor.
6
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
Contexto: La aplicacin cliente ya tiene los permisos para acceder al recurso protegido de la
aplicacin servidor (con un token de sesin vlido).
1. La aplicacin cliente solicita el recurso a la aplicacin servidor pasndole los
parmetros:
a. Recurso solicitado
b. String con el token de sesin
Se puede hacer con un GET HTTP con el string del token en el campo Authorization del
header HTTP, o directamente mediante URI agregando el parmetro access_token.
2. La aplicacin servidor verifica que el token recibido sea vlido y que se tengan los
permisos de acceder al recurso.
3. La aplicacin servidor enva el recurso solicitado a la aplicacin cliente
c.Expiracin del token de sesin
Actores involucrados: Aplicacin servidor, aplicacin cliente.
Descripcin: El token de sesin expira por el tiempo y se debe solicitar uno nuevo.
Contexto: La aplicacin cliente ya se haba autenticado y recibido el token de sesin y de
refresco, y sigue teniendo los mismos permisos que al principio.
1. La aplicacin cliente solicita un nuevo recurso a la aplicacin servidor, como se
describi en el caso de uso anterior.
2. La aplicacin servidor verifica que el token recibido sea vlido y que se tengan los
permisos de acceder al recurso.
3. La aplicacin servidor responde con un error de token invlido, ya que este expir.
4. La aplicacin cliente entonces enva el token de refresco para solicitar un nuevo token
de sesin.
5. La aplicacin servidor enva el nuevo token de sesin y opcionalmente un nuevo token
de refresco.
7
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
d.Revocacin del token de refresco
Actores involucrados: Usuario, aplicacin cliente, aplicacin servidor.
Descripcin: La aplicacin cliente debe autenticarse de nuevo porque ya no tiene los mismos
permisos que al principio.
Contexto: La aplicacin cliente se haba autenticado anteriormente con la aplicacin servidor,
con determinados permisos otorgados por el usuario, pero en determinado momento ste
revoca algunos de ellos y por lo tanto los tokens que se haban obtenido pasan a ser invlidos.
1. El usuario revoca permisos a la aplicacin cliente
2. La aplicacin cliente solicita un nuevo recurso a la aplicacin servidor, como se
describi anteriormente.
3. La aplicacin servidor verifica que el token recibido sea vlido y que se tengan los
permisos de acceder al recurso.
4. La aplicacin servidor responde con un error de token invlido, ya que este expir.
5. La aplicacin cliente entonces enva el token de refresco para solicitar un nuevo token
de sesin.
6. La aplicacin servidor responde nuevamente con un error de token invlido.
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
3. Ventajas y desventajas de OAuth2
En esta seccin, vamos a describir las ventajas y las desventajas de usar el protocolo OAuth2
que hemos analizado.
a. Ventajas
Para el usuario:
Facilidad de uso :
El hecho de usar OAuth permite de tener acceso mucho ms fcilmente
al contenido de los servidores clientes. Efectivamente, el usuario puede
usar una sola cuenta (Facebook por ejemplo) para acceder a un gran
conjunto de sitios, ganando as el tiempo de inscripcin y evitando la
creacin de una cuenta que probablemente habra usado pocas veces.
Ampliacin de la red de contactos :
Este protocolo permite al usuario que sus datos se transmitan de servidor
a otro servidor. As, otros usuarios pueden ver su actividad, por ejemplo
comentarios, en varios sitios.
Privacidad :
Con OAuth2, las aplicaciones clientes no disponen del recurso del
usuario: solo pueden usar momentneamente la parte de los datos que
quiere de la aplicacin servidor, segn las autorizaciones dados. Eso
asegura que el cliente, los recursos estando escondidos, no puede usar
sus datos personales contra su voluntad. Podemos pensar al caso de
una compra por ejemplo donde se conecta sobre el sitio de su banco via
OAuth para comprar en otro sitio, sin darle sus datos financieros.
Seguridad :
Desde OAuth2, todos los datos que se transfieren deben tener lugar en el
protocolo SSL, es decir cifrados con los protocolos de criptografa
conocidos ms eficientes.
Control del acceso a los datos :
OAuth permite al usuario de limitar como quiere la parte de sus recursos
a la cual el cliente puede acceder. Ademas, con OAuth2 y el uso de los
tokens que aade un aspecto temporal, el usuario puede decidir del
tiempo de expiracin del acceso a sus datos.
Para las aplicaciones cliente:
Reduccin de los costos :
Para una aplicacin, usar OAuth2 permite ahorrar los esfuerzos
necesarios para poner en marcha un sistema robusto de autenticacin y
de comentarios. Adems, en varios casos, como OAuth es un open
standard, no necesita pagar licencia.
10
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
Aumento de popularidad :
Usar OAuth permite de simplificar el acceso a la comunidad, lo que
permite de agrandar el trfico.
Para las aplicaciones servidor :
La ventaja principal por las aplicaciones servidor es tambin un aumento de
popularidad. Efectivamente, con OAuth, las cuentas de datos de la aplicacin
servidor ganan poder, es decir que con ellos se puede acceder a ms contenido.
A estas aplicaciones OAuth les permite de atraer nuevos usuarios y agrandar
sus bases de datos, que en caso de Google o Facebook por ejemplo son los
recursos de la empresa.
b. Desventajas
Falta de anonimato :
Usar OAuth es equivalente a tener una sola cuenta para varias
actividades diferentes. Asi, es imposible de esconder aspectos de su
identidad de alguna manera; el cliente buscando la informacin sobre una
aplicacin servidor que posea los datos. Adems, por ejemplo en un caso
de un comentario sobre un sitio con Facebook o Twitter, otros usuarios
pueden acceder a tu perfil, lo que posiblemente no querra. Limitar todo lo
que no puede acceder el cliente puede tardar ms tiempo que de creer
una nueva cuenta en el sitio cliente, con los datos queridos. El desarrollo
de OAuth podra hacer desaparecer otras alternativas que le permita
conservar un cierto anonimato.
Phishing :
Usar OAuth, y su seguridad perceptible con un uso correcto, puede traer
el usuario a pensar que conectarse al sitio es siempre seguro. Sin
embargo, OAuth no te asegura que este sitio es benevolente. Gente que
quiere robar sus datos puede aprovechar del sentimiento de confianza
que te da OAuth para elaborar nuevas ataques de phishing. De otra
manera, OAuth no te garantiza que la aplicacin servidor no puede hacer
un malo uso de sus datos, por ejemplo venderlas.
Concentration de los datos :
El hecho de tener todos sus datos en una sola aplicacin servidor que
sirven para muchas otras aplicaciones clientes puede ser peligroso. En
efecto, si esa cuenta viene a ser hackeada, las repercusiones tocan
varios lugares y no uno. Ms sencillamente, si el usuario quiere cerrar
esa cuenta, el mismo problema se presenta
11
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
4. Implementacin
4.a. Introduccin
Para la implementacin de este trabajo prctico elegimos utilizar las siguientes herramientas:
Aplicacin Web en ASP.NET
Lenguaje C#
Librera RestSharp para realizar los request.
La API Servidor que vamos a consumir es la de la empresa MercadoLibre. Elegimos esta
empresa ya que su API es OAuth 2.0 pura y adems MercadoLibre brinda un cdigo C# base
open source con el que se puede ver claramente la interaccin entre nuestra aplicacin y la API
de MercadoLibre.
En nuestra implementacin vamos a simular ser una empresa de nombre facturale.com que
brinda un servicio de facturacin online, de forma tal de consumir las ventas de un usuario por
MercadoLibre y realizar su facturacin. Para consumir las ventas de un determinado usuario se
debe conectar a la API de MercadoLibre utilizando OAuth2.0 donde el individuo deber
brindarle a nuestra aplicacin el acceso a sus ventas.
Nuestra aplicacin a modo de ejemplo mostrar como accede a estos recursos mostrando una
tabla con las ventas del usuario en MercadoLibre, donde explicaremos paso por paso la
interaccin entre nuestra aplicacin, MercadoLibre y el usuario, a modo de ejemplificar los
casos de uso vistos en la seccin 2.
4.b. Registracin de nuestra aplicacin en MercadoLibre
Para poder consumir los servicios de una API OAuth2 2.0 lo primero que hay que hacer es
registrarse como aplicacin cliente en la aplicacin que brinda el servicio, en este caso
MercadoLibre. En este proceso se caracteriza por lo siguiente:
1. Obtendremos un cdigo de cliente
2. Obtendremos una clave secreta (que no la tenemos que divulgar)
3. Registraremos una URL de nuestra aplicacin que MercadoLibre utilizar para
enviarnos la confirmacin de que un usuario nos ha dado acceso a determinados
recursos.
12
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
4.c. Caso de uso 1: Obtencin de token de sesin y token de refresco
Enumeraremos la implementacin de los pasos de grfico 2.a.
1. Usuario desea que facturales.com pueda acceder a la informacin de sus ventas en
MercadoLibre, entonces hace click en el botn Logearse utilizando cuenta de Mercado Libre.
13
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
2. Facturales.com redirecciona a MercadoLibre, utilizando su codigo de cliente y direccin de
redireccionamieto como parmetros, mediante la siguiente URL:
https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=21329409
48296219&redirect_uri=http://localhost:7001/Accoun/ExternalLoginCallback
Nota: MercadoLibre solo acepta direcciones http en los casos que sean localhost, para
direcciones definitivas tienen que ser https.
MercadoLibre solicita al usuario que se identifique en su sitio.
4. Luego de la identificacin el usuario deber aceptar declinar si desea brindarle acceso a
facturales.com:
14
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
5. Si el usuario cliquea en Permitir entonces MercadoLibre redirecciona a la URL de notificacin
de permisos otorgados de nuestra aplicacin pasandole un parametro code
http://localhost:7001/Account/ExternalLoginCallback?code=TG-573a2ec6e4b0cd95933598
78-93015838
Nota: si el usuario no Permite el acceso entonces se redirecciona a la URL de notificacin con
un parmetro de error:
http://localhost:7001/Account/ExternalLoginCallback?error=access-denied
6. Facturales.com toma ese cdigo y hace un POST a la URL de MercadoLibre con los
siguientes parametros:
https://api.mercadolibre.com/oauth/token?grant_type=authorization_code&client_id={client_id}&
client_secret={client_secret}&code={code}&redirect_uri={redirect_uri}
Notar que ademas del client_id y la clave secreta se le pasa el code recibido y la url de
notificacin
URL Completa:
https://api.mercadolibre.com/oauth/token?grant_type=authorization_code&client_id=213294094
8296219&client_secret=WeyCT5o3QLUOzJsen2WnL5narj523cEf&code=TG-573a2ec6e4b0cd9
15
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
593359878-93015838&redirect_uri=http:%2F%2Flocalhost:7001%2FAccount%2FExternalLogin
Callback
7. MercadoLibre devuelve como resultado del POST un JSON:
{
"access_token":"APP_USR-2132940948296219-051616-b1a81b0e1b132474b
acf2faa3ef2f24a__N_K__-206849955"
,"token_type":"bearer"
,"expires_in":21600
,"scope":"offline_access read"
,"user_id":206849955
,"refresh_token":"TG-573a3314e4b05f929b1e7e65-206849955"
}
Access_token: es el token de acceso que se podr utilizar por un tiempo determinado por el
campo expires_in.
Token_type: indica que es un token para aplicaciones externas a MercadoLibre
Expires_in: cantidad de milisegundos que dura el token
Scope: permisos concedidos
User_id: id del usuario que concedi los permisos
Refresh_token: token de refresco para obtener un nuevo access_token cuando el mismo expire
8. Facturales.com indica al usuario que ahora puede acceder a su informacin:
4.d. Caso de uso 2:Utilizacin del token de sesin
Enumeraremos los pasos de la seccin 2.b.
Utilizaremos de ejemplo el acceso a la informacin del perfil del usuario logeado, como por
ejemplo su nick en MercadoLibre.
1. Facturales.com puede utilizar su token de acceso para acceder a la informacin de perfil del
usuario logeado, para eso ejecuta la siguiente url:
16
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
https://api.mercadolibre.com/users/me?access_token=APP_USR-2132940948296219-051616b1a81b0e1b132474bacf2faa3ef2f24a__N_K__-206849955
2. MercadoLibre verifica que el access_token enviado por parmetro sea vlido, es decir que
tenga acceso al perfil de ese usuario y que adems no haya expirado.
3. En caso satisfactorio retorna un JSON con la respuesta solicitada:
{
"Id":206849955
,"nickname":"usuarioprueba"
,"registration_date":"2016-02-23T15:21:06.000-04:00"
,"first_name":"FIUBA"
,"last_name":"FIUBA"
,"country_id":"AR"
,"email":"palbanese@fi.uba.ar"
,"identification":{"type":null,"number":null}
,"address":{"state":"AR-C","city":null,"address":null,"zip_code":null}
,"phone":{"area_code":"","number":"1134487774","extension":"","verified":false}
,"alternative_phone":{"area_code":"","number":"","extension":""}
.
}
4.e. Caso 3. Expiracin del token de sesin
1. Facturales.com puede utilizar su token de acceso para acceder a la informacin de perfil del
usuario logeado, para eso ejecuta un GET sobre siguiente url:
https://api.mercadolibre.com/users/me?access_token=APP_USR-2132940948296219-051616b1a81b0e1b132474bacf2faa3ef2f24a__N_K__-206849955
2. MercadoLibre verifica que el token de sesin enviado en el parmetro access_token sea
vlido.
3. MercadoLibre retorna el mensaje de que el access_token es invlido:
{
"message":"Malformed access_token: null"
,"error":"bad_request"
,"status":400
,"cause":[]
}
17
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
4. Facturales.com realiza un POST sobre MercadoLibre, utilizando su id de cliente, cdigo
secreto y refresh_token en la siguiente URL:
https://api.mercadolibre.com/oauth/token?grant_type=refresh_token&client_id=2132940948
296219&client_secret=WeyCT5o3QLUOzJsen2WnL5narj523cEf&refresh_token=TG-573a6d7a
e4b08aeaee76b81b-206849955
5. MercadoLibre como retorna el siguiente JSON el cual contiene el nuevo access_token:
{
"access_token":"APP_USR-2132940948296219-051621-9ea65b0ffeb810a78034
d921e090150b__D_H__-206849955"
,"token_type":"bearer"
,"expires_in":21600
,"scope":"offline_accessread"
,"user_id":206849955
,"refresh_token":"TG-573a6d97e4b0cd95933c990e-206849955"
}
Luego facturales.com puede volver a ejecutar el paso 1 correctamente.
4.f. Caso 4. Revocacin del token de refresco
1. El usuario ingresa a MercadoLibre y selecciona que facturales.com no tenga mas permisos
para acceder a sus datos:
18
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
2. Facturales.com puede utilizar su token de acceso para acceder a la informacin de perfil del
usuario logeado, para eso ejecuta un GET sobre siguiente url:
https://api.mercadolibre.com/users/me?access_token=APP_USR-2132940948296219-051616b1a81b0e1b132474bacf2faa3ef2f24a__N_K__-206849955
2. MercadoLibre verifica que el token de sesin enviado en el parmetro access_token sea
vlido.
3. MercadoLibre retorna el mensaje de que el access_token es invlido:
{
"message":"Malformed access_token: null"
,"error":"bad_request"
,"status":400
,"cause":[]
}
4. Facturales.com realiza un POST sobre MercadoLibre, utilizando su id de cliente, cdigo
secreto y refresh_token en la siguiente URL:
https://api.mercadolibre.com/oauth/token?grant_type=refresh_token&client_id=2132940948
296219&client_secret=WeyCT5o3QLUOzJsen2WnL5narj523cEf&refresh_token=TG-573a6d7a
e4b08aeaee76b81b-206849955
5. MercadoLibre como retorna el siguiente JSON indica que facturales.com no tiene mas
permisos para acceder a la informacin de ese usuario:
{
"message":"User has no grant for application"
,"error":"unauthorized"
,"status":401
,"cause":[]
19
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
4.g. Algunas vulnerabilidades detectadas durante la implementacin
1. Cuando el usuario revoca elimina los permisos para que la aplicacin facturales.com
acceda a sus datos, existe un perodo ventana en el cual si ya tena un token de sesin,
el mismo no se invalida sino que dura hasta su expiracin, en donde ah si ya no se
puede volver a obtenerlo.
a. Esto podra ser utilizado maliciosamente en caso de que el usuario haya
otorgado permisos a una aplicacin maliciosa y cuando se de cuenta no pueda
impedir que esta aplicacin realice cambios por ms rpido que le quite el
permiso.
2. La implementacin OAuth 2.0 de MercadoLibre retorna el refresh_token
innecesariamente cuando se refresca un token de sessin si la aplicacin
facturales.com vuelve a pedirselo.
a. Por lo tanto, en caso de que la comunicacin sea vulnerada, se podra llegar a
obtener a dems de un token de sesin, un token de refresco lo que sera de
ms gravedad.
20
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
5. Conclusiones
El protocolo OAuth2 es un protocolo abierto que nos permite la autorizacin segura de una API,
este protocolo permitir a terceros, estos ser el Cliente o consumidor, acceder a recursos
protegidos de un usuario, el Cliente es autorizado por el usuario.
Sus principales ventajas son su amplia aceptacin entre las distintas API de hoy en da, su
facilidad de uso y la transparencia que le brinda al usuario al hacer que las aplicaciones cliente
no almacenen su contrasea. Sus desventajas desde el punto de vista funcional son, en su
mayora, puntos de vista sobre la consecuencia que la popularizacin de OAuth 2 puede traer
en materia de privacidad de uso, concentracin de informacin en la aplicacin servidor y falta
de anonimato ya que muchos sitios que no tienen porque pedir este tipo de login, lo hacen hoy
en da.
Hemos explicado los 4 casos de uso tpicos del protocolo y los hemos desarrollado sin mayores
inconveniente en una aplicacin ficticia llamada facturales.com como aplicacin cliente con
MercadoLibre como aplicacin servidor. En nuestra implementacin pudimos corroborar que
MercadoLibre utiliza un OAuth 2.0 puro, como as tambin detectar algunos puntos que el
estndar no especifica puntualmente y que MercadoLibre los resuelve de una forma que podra
llegar a ser vulnerable, como es el caso del perodo ventana entre la revocacin de
access_token, donde el token de sesin sigue siendo vlido el caso de retornar ms veces de
la necesaria el token de refresco.
21
Facultad de Ingeniera, Universidad de Buenos Aires
Criptografa y Seguridad Informtica (66.69)
Trabajo Prctico Final - Anlisis de OAuth2
6. Referencias
1. E. Hammer, Ed., The OAuth 2.0 Authorization Protocol,
http://tools.ietf.org/html/draft-ietf-oauth-v2-23#page-5
2. E. Hammer, Ed., The OAuth 2.0 Authorization Protocol,
https://tools.ietf.org/html/rfc6749#section-7.1
3. E. Hammer, Ed., The OAuth 2.0 Authorization Protocol,https://tools.ietf.org/html/rfc6750
4. Website MercadoLibre para desarrolladores h
ttp://developers.mercadolibre.com/
22
