Protocolo oauth2

Análisis de protocolo protocolo OAuth2 Trabajo Práctico Final Criptografía y Seguridad Informática (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 Pablo Alba Albanes nese. e. Padró Padrón: n: 8780 87803 3 Eliana Eliana Ven Ventur tura. a. Padró Padrón: n: 9337 93376 6 Pedro Pedro Mayord Mayordomo omo Molina. Molina. Padró Padrón: n: 9992 99920 0 Jules Jules Lambe Lambert. rt. Pad Padrón rón:: 99886 99886

Facultad de Ingeniería, Universidad de Buenos Aires Criptografía y Seguridad Informática (66.69) Trabajo Práctico Final - Análisis de OAuth2

Indice 1. Introducción 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. Obtención de token de sesión y token de refresco b. Utilización del token de sesión c. Expiración del token de sesión d. Expiración del token de refresco 3. Ventajas y desventajas de OAuth2 a. Ventajas b. Desventajas 4. Implementación a. Introducción b. Registración de nuestra aplicación en MercadoLibre c. Caso 1: Obtención de token de sesión y token de refresco d. Caso 2: Utilización del token de sesión e. Caso 3: Expiración del token de sesión f. Caso 4: Expiración del token de refresco g. Algunas vulnerabilid vulnerabilidades ades detectadas detectadas durante la implementación implementación 5. Conclusiones 6. Referencias

1


1.Introducción a OAuth2 1.a. ¿Qué es OAuth2? OAuth2 es un protocolo abierto que nos permite la autorización 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 información del sitio A con el sitio B, sin compartir toda su identidad o recursos almacenados en el sitio A(el usuario puede seleccionar la información compartida). Para ello será necesario una autorización, para permitir el acceso a los datos, además de una autenticación, para demostrar ser quien dices ser. Por lo tanto con este protocolo podremos lograr la integración entre aplicaciones, sin compartir las contraseñas. Es un estándar abierto, puesto que detrás de OAuth encontramos varias compañías interesadas como Twitter ,Pownce , Ma.gnolia. La idea fue unificar todos los protocolos cerrados , para conseguir un estándar que ayude a la integración de aplicaciones Web .

1.b. Funcionalidades OAuth es necesario para que el usuario se sienta seguro al entregar sus credenciales a la aplicación cliente. Este protocolo es muy importante puesto que el usuario autoriza a que dicha aplicación realice algo con el nombre del usuario. La autorización está separada de la autenticación, además en cualquier momento el usuario podrá quitarle al cliente la autorización para poder acceder a los recursos. El proveedor primero autenticara si es el usuario quien dice ser y después comprobará a qué recursos está autorizada el cliente a acceder, esta decisión la tomará el usuario. Posteriormente se explicará más detalladamente el proceso.

1.c. Versiones anteriores Su antecesor fue Oauth 1.0, aunque la introducción de OAuth 2.0 lo ha dejado de lado además son totalmente incompatibles.

2


El primer borrador de OAuth se publicó el 3 de Octubre de 2007.Todo comenzó con la necesidad de diferentes empresas de encontrar un estándar 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 además de proporcionar una autorización específica, ambos protocolos son incompatibles. Uno de los participantes de este grupo de discusión era Blaine Cook, desarrollaba la implementación 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 páginas 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 más importantes son Facebook, Twitter o Google.

3


En el siguiente link de Wikipedia encontramos todos los proveedores que existen además del protocolo con el cual es compatible.

4


2. Casos de uso En esta sección 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: Aplicación Servidor: Es la aplicación web que contiene usuarios que operan sobre ciertos recursos que la aplicación provee. Esta aplicación desea que otras aplicaciones puedan administrar esos recursos con autorización del usuario. Aplicación Cliente: Es la aplicación web que desea hacer uso de recursos del usuario con la debida autorización del mismo. Esta aplicación previamente a los escenarios planteados se ha registrado en la aplicación Servidor como aplicación autorizada para hacer uso de determinados recursos de los usuarios y la aplicación Servidor le ha concedido la autorización para brindar ese servicio para lo cual le informó su ID de cliente y su código secreto. Usuario: Es la persona que desea darle acceso a los recursos que posee en la Aplicación Servidor a una Aplicación Cliente. El acceso a recursos puede ser total ó parcial según las políticas de uso de la aplicación Servidor. Recurso: Se refiere a cualquier tipo de información que administre el usuario como suya en la Aplicación Servidor. Ejemplos: Datos personales, documentos, imágenes, información de transacciones como publicaciones, emails, etc.

a.Obtención de token de sesión y token de refresco Actores involucrados: Usuario, Aplicación Servidor, Aplicación Cliente Descripción: Un Usuario quiere que una Aplicación Cliente pueda hacer uso de determinados recursos que posee en la aplicación Servidor. Contexto: La aplicación cliente no posee autorización por parte del usuario y este mismo quiere dárselos. 1. Usuario accede a aplicación cliente y decide darle acceso a determinados recursos, presionando el botón de Inicio de sesión. 2. La aplicación cliente redirecciona al usuario a una página determinada de antemano por la aplicación servidor, en la URL pasa por parámetros: a. Código de cliente b. Código secreto c. URL de notificación d. Recursos solicitados

5


3. La aplicación 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 aplicación Cliente. 4. El usuario acepta la solicitud 5. La aplicación servidor realiza un GET HTML a la URL de notificación enviada por la aplicación cliente pasándole por parámetro un código de transacción. 6. La aplicación cliente utiliza este código haciendo un POST HTML a una dirección previamente pactada solicitando token de sesión y token de refresco. 7. La aplicación servidor retorna el token de sesión y token de refresco para que sea utilizado por la aplicación cliente. 8. La aplicación cliente notifica al usuario el resultado de la operación. La imagen 1 muestra el proceso de obtención de token de sesión y refresco en forma gráfica:

Imagen 1. Obtención 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 aplicación cliente, la aplicación servidor en el paso 5 notificará la negativa del usuario a tal permiso. Nota: Dependiendo de las políticas de uso de la aplicación servidor el código de transacción obtenido en el paso 5 tiene un período de expiración determinado.

b.Utilización del token de sesión Actores involucrados: Aplicación servidor, aplicación cliente Descripción: La aplicación cliente solicita un recurso a la aplicación servidor. 6


Contexto: La aplicación cliente ya tiene los permisos para acceder al recurso protegido de la aplicación servidor (con un token de sesión válido). 1. La aplicación cliente solicita el recurso a la aplicación servidor pasándole los parámetros: a. Recurso solicitado b. String con el token de sesión 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 parámetro access_token. 2. La aplicación servidor verifica que el token recibido sea válido y que se tengan los permisos de acceder al recurso. 3. La aplicación servidor envía el recurso solicitado a la aplicación cliente

c.Expiración del token de sesión Actores involucrados: Aplicación servidor, aplicación cliente. Descripción: El token de sesión expira por el tiempo y se debe solicitar uno nuevo. Contexto: La aplicación cliente ya se había autenticado y recibido el token de sesión y de refresco, y sigue teniendo los mismos permisos que al principio. 1. La aplicación cliente solicita un nuevo recurso a la aplicación servidor, como se describió en el caso de uso anterior. 2. La aplicación servidor verifica que el token recibido sea válido y que se tengan los permisos de acceder al recurso. 3. La aplicación servidor responde con un error de token inválido, ya que este expiró. 4. La aplicación cliente entonces envía el token de refresco para solicitar un nuevo token de sesión. 5. La aplicación servidor envía el nuevo token de sesión y opcionalmente un nuevo token de refresco. 7


d.Revocación del token de refresco Actores involucrados: Usuario, aplicación cliente, aplicación servidor. Descripción: La aplicación cliente debe autenticarse de nuevo porque ya no tiene los mismos permisos que al principio. Contexto: La aplicación cliente se había autenticado anteriormente con la aplicación 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 habían obtenido pasan a ser inválidos. 1. El usuario revoca permisos a la aplicación cliente 2. La aplicación cliente solicita un nuevo recurso a la aplicación servidor, como se describió anteriormente. 3. La aplicación servidor verifica que el token recibido sea válido y que se tengan los permisos de acceder al recurso. 4. La aplicación servidor responde con un error de token inválido, ya que este expiró. 5. La aplicación cliente entonces envía el token de refresco para solicitar un nuevo token de sesión. 6. La aplicación servidor responde nuevamente con un error de token inválido.

8


9


3. Ventajas y desventajas de OAuth2 En esta sección, 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 más fácilmente 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 inscripción y evitando la creación de una cuenta que probablemente habría usado pocas veces. ○ Ampliación 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 momentáneamente la parte de los datos que quiere de la aplicación servidor, según 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 criptografía conocidos más 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 añade un aspecto temporal, el usuario puede decidir del tiempo de expiración del acceso a sus datos. Para las aplicaciones cliente: ○ Reducción de los costos : ■ Para una aplicación, usar OAuth2 permite ahorrar los esfuerzos necesarios para poner en marcha un sistema robusto de autenticación y de comentarios. Además, en varios casos, como OAuth es un open standard, no necesita pagar licencia. 10


○

●

Aumento de popularidad : ■ Usar OAuth permite de simplificar el acceso a la comunidad, lo que permite de agrandar el tráfico. Para las aplicaciones servidor : ○ La ventaja principal por las aplicaciones servidor es también un aumento de popularidad. Efectivamente, con OAuth, las cuentas de datos de la aplicación servidor ganan poder, es decir que con ellos se puede acceder a más 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 información sobre una aplicación servidor que posea los datos. Además, 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 querría. Limitar todo lo que no puede acceder el cliente puede tardar más tiempo que de creer una nueva cuenta en el sitio cliente, con los datos queridos. El desarrollo de OAuth podría hacer desaparecer otras alternativas que le permitía 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 aplicación 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 aplicación 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. Más sencillamente, si el usuario quiere cerrar esa cuenta, el mismo problema se presenta

11


4. Implementación 4.a. Introducción Para la implementación de este trabajo práctico elegimos utilizar las siguientes herramientas: ●

Aplicación Web en ASP.NET ○ Lenguaje C# ○ Librería 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 además MercadoLibre brinda un código C# base open source con el que se puede ver claramente la interacción entre nuestra aplicación y la API de MercadoLibre. En nuestra implementación vamos a simular ser una empresa de nombre “facturale.com” que brinda un servicio de facturación online, de forma tal de consumir las ventas de un usuario por MercadoLibre y realizar su facturación. 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 aplicación el acceso a sus ventas. Nuestra aplicación 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 interacción entre nuestra aplicación, MercadoLibre y el usuario, a modo de ejemplificar los casos de uso vistos en la sección 2.

4.b. Registración de nuestra aplicación en MercadoLibre Para poder consumir los servicios de una API OAuth2 2.0 lo primero que hay que hacer es registrarse como aplicación cliente en la aplicación que brinda el servicio, en este caso MercadoLibre. En este proceso se caracteriza por lo siguiente: 1. Obtendremos un código de cliente 2. Obtendremos una clave secreta (que no la tenemos que divulgar) 3. Registraremos una URL de nuestra aplicación que MercadoLibre utilizará para enviarnos la confirmación de que un usuario nos ha dado acceso a determinados recursos.

12


4.c. Caso de uso 1: Obtención de token de sesión y token de refresco Enumeraremos la implementación de los pasos de gráfico 2.a. 1. Usuario desea que facturales.com pueda acceder a la información de sus ventas en MercadoLibre, entonces hace click en el botón Logearse utilizando cuenta de Mercado Libre. 13


2. Facturales.com redirecciona a MercadoLibre, utilizando su codigo de cliente y dirección de redireccionamieto como parámetros, 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 identificación el usuario deberá aceptar ó declinar si desea brindarle acceso a facturales.com:

14


5. Si el usuario cliquea en Permitir entonces MercadoLibre redirecciona a la URL de notificación de permisos otorgados de nuestra aplicación 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 notificación con un parámetro de error: http://localhost:7001/Account/ExternalLoginCallback ?error=access-denied 6. Facturales.com toma ese código 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 notificación URL Completa: https://api.mercadolibre.com/oauth/token?grant_type=authorization_code&client_id=213294094 8296219&client_secret=WeyCT5o3QLUOzJsen2WnL5narj523cEf&code=TG-573a2ec6e4b0cd9

15


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 información:

4.d. Caso de uso 2:Utilización del token de sesión Enumeraremos los pasos de la sección 2.b. Utilizaremos de ejemplo el acceso a la información 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 información de perfil del usuario logeado, para eso ejecuta la siguiente url:

16


https://api.mercadolibre.com/users/me? access_token=APP_USR-2132940948296219-051616b1a81b0e1b132474bacf2faa3ef2f24a__N_K__-206849955 2. MercadoLibre verifica que el access_token enviado por parámetro sea válido, es decir que tenga acceso al perfil de ese usuario y que además 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":"[email protected]" ,"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. Expiración del token de sesión 1. Facturales.com puede utilizar su token de acceso para acceder a la información 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 sesión enviado en el parámetro access_token sea válido. 3. MercadoLibre retorna el mensaje de que el access_token es inválido: { "message":"Malformed access_token: null" ,"error":"bad_request" ,"status":400 ,"cause":[] } 17


4. Facturales.com realiza un POST sobre MercadoLibre, utilizando su id de cliente, código 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. Revocación 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


2. Facturales.com puede utilizar su token de acceso para acceder a la información 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 sesión enviado en el parámetro access_token sea válido. 3. MercadoLibre retorna el mensaje de que el access_token es inválido: { "message":"Malformed access_token: null" ,"error":"bad_request" ,"status":400 ,"cause":[] } 4. Facturales.com realiza un POST sobre MercadoLibre, utilizando su id de cliente, código 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 información de ese usuario: { "message":"User has no grant for application" ,"error":"unauthorized" ,"status":401 ,"cause":[] 19


}

4.g. Algunas vulnerabilidades detectadas durante la implementación 1. Cuando el usuario revoca elimina los permisos para que la aplicación facturales.com acceda a sus datos, existe un período ventana en el cual si ya tenía un token de sesión, el mismo no se invalida sino que dura hasta su expiración, en donde ahí si ya no se puede volver a obtenerlo. a. Esto podría ser utilizado maliciosamente en caso de que el usuario haya otorgado permisos a una aplicación maliciosa y cuando se de cuenta no pueda impedir que esta aplicación realice cambios por más rápido que le quite el permiso. 2. La implementación OAuth 2.0 de MercadoLibre retorna el refresh_token innecesariamente cuando se refresca un token de sessión ó si la aplicación facturales.com vuelve a pedirselo. a. Por lo tanto, en caso de que la comunicación sea vulnerada, se podría llegar a obtener a demás de un token de sesión, un token de refresco lo que sería de más gravedad.

20


5. Conclusiones El protocolo OAuth2 es un protocolo abierto que nos permite la autorización 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 aceptación entre las distintas API de hoy en día, su facilidad de uso y la transparencia que le brinda al usuario al hacer que las aplicaciones cliente no almacenen su contraseña. Sus desventajas desde el punto de vista funcional son, en su mayoría, puntos de vista sobre la consecuencia que la popularización de OAuth 2 puede traer en materia de privacidad de uso, concentración de información en la aplicación servidor y falta de anonimato ya que muchos sitios que no tienen porque pedir este tipo de login, lo hacen hoy en día. Hemos explicado los 4 casos de uso típicos del protocolo y los hemos desarrollado sin mayores inconveniente en una aplicación ficticia llamada facturales.com como aplicación cliente con MercadoLibre como aplicación servidor. En nuestra implementación pudimos corroborar que MercadoLibre utiliza un OAuth 2.0 puro, como así también detectar algunos puntos que el estándar no especifica puntualmente y que MercadoLibre los resuelve de una forma que podría llegar a ser vulnerable, como es el caso del período ventana entre la revocación de access_token, donde el token de sesión sigue siendo válido ó el caso de retornar más veces de la necesaria el token de refresco.

21


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 http://developers.mercadolibre.com/

22

Protocolo oauth2

Recommend Documents