Consumo de Servicios RESTful (III)

Transcripción

1 Departamento de Lenguajes y Sistemas Informáticos Consumo de Servicios RESTful (III) Práctica 7 Arquitectura e Integración del Software Curso 2012/2013 Índice Introducción OAuth 2 Enlaces 1

2 Introducción En la práctica, los servicios RESTful suelen requerir alguna forma de identificar al cliente/consumidor de los recursos. Esto principalmente se debe a 2 motivos: Por el coste que tiene la invocación del servicio para el proveedor se quiere limitar el ratio de peticiones por cliente (o incluso cobrar por el uso del servicio) La seguridad de los recursos (para que un usuario no pueda consultar o modificar recursos sobre los que no tiene permisos). Hay varios métodos de autenticación. En las aplicaciones actuales, el mecanismo más popular de autenticación es OAuth. En esta práctica Aprenderemos como hacer que nuestra aplicación GWT utilice para autenticarnos en diferentes aplicaciones (Google Drive y Facebook). Cliente: Interfaz gráfica de nuestro mashup (práctica 2) Introducción Visión general de la práctica 1. Autenticación 3. Token 2. Token Servicio RESTful de múltiples recursos con autenticación 4. Invocación + Token Servidor: Consumo de servicios RESTful (prácticas 5-7) 2

3 Índice Introducción OAuth 2 Enlaces OAuth 2 Descripción OAuth 2.0 es un protocolo para la autenticación de usuarios en servicios RESTful de terceros. Aparece para evitar la autenticación directa del usuario en nuestra aplicación con credenciales de otro servicio. En vez de autenticarse en nuestra aplicación, la ejecución se redirige al servicio de terceros a usar para hacer la autenticación directamente con el proveedor del servicio. Si la autenticación es correcta, el proveedor retorna la ejecución a nuestra aplicación, indicando una clave de acceso (token). Esta clave de acceso (Access Token) solo es válida para nuestra aplicación, es temporal (el tiempo de validez lo impone el proveedor) y siempre puede ser revocada por el usuario. Usando la clave de acceso como parámetro se pueden invocar los servicios RESTful del proveedor. 3

4 Autenticación directa (sin OAuth) Usuario Aplicación Servicio REST Acceso a mi panel de videos Consulta Vídeos de Usuario Tus credenciales de YouTube? Credenciales de Usuario? UsuarioPaco, *****3 Consulta Videos de UsuarioPaco, *****3 Panel con videos Videos de UsuarioPaco Nuestra aplicación tiene acceso a las credenciales del usuario Autenticación con OAuth Usuario Aplicación APP Servicio REST Acceso a mi panel de videos Consulta URL de Login en Youtube para APP URL de Login para APP Redirige a URL de Login en YouTube para APP UsuarioPaco, *****3 TOKEN temporal de UsuarioPaco para APP Consulta Videos con TOKEN Videos de UsuarioPaco Panel con videos Nuestra aplicación NO tiene acceso a las credenciales del usuario, pero tiene que estar registrada en el servicio 4

5 Pasos genéricos para usar PASO 1: Registrar nuestra aplicación para el recurso correspondiente indicando la Url decallback. El servicio nos proporcionará unclient ID. Pasos genéricos para usar PASO 2: Consultar la documentación del servicio para saber su URL de login así como los permisos quepermite. 5

6 Pasos genéricos para usar PASO 3: La primera vez que nuestra aplicación requiera acceder al servicio en nombre de un usuario (ej. subir un video a la cuenta del usuario en youtube) la aplicación redirigirá al usuario a la URL de login indicando el CLIENT ID (indentificador) y el SCOPE (permisos) que requerimos para el recurso. Pasos genéricos para usar PASO 4: El usuario se autenticará en la URL de login aceptando los permisos requeridos (en caso contrario, no se podrá hacer uso del recurso). 6

7 Pasos genéricos para usar PASO 5: El servicio invocará a la URL de callback de la aplicación enviándole un ACCESS TOKEN. El token está asociado con el usuario, nuestra aplicación y los permisos requeridos y es de carácter temporal). Notar que la aplicación nunca llegará a conocer el usuario/clave del usuario, en su lugar trabajará con el token. Access Token: ya29.ahes6zqenuwpfneh5a7tgwdqijvflqxbljcuknpwhupwptbux4eomw Pasos genéricos para usar PASO 6: La aplicación podrá invocar a cualquier Servicio correspondiente a los permisos requeridos pasando como parámetro el ACCESS TOKEN. 7

8 Consideraciones Actualmente existen dos versiones principales de Oauth: OAuth1 y. No son compatibles entre ellos. OAuth1 vs. Consideraciones Cuando untoken de acceso caduca hay querefrescar dicho token. 8

9 Consideraciones Para implementar el protocolo Oauth (en cualquier versión) es necesario que nuestra aplicación tenga una URL accesible en Internet para recibir el token desde el servicio de login usado (facebook, google, etc). Conclusión: Debemos desplegar la aplicación en el AppEngine para hacer uso de OAuth. No se puede probar en local. Consideraciones Los permisos asociados con un Token los define la aplicación. Por ejemplo, Facebook define una gran cantidad de permisos diferentes: Acceso a los datos básicos del usuario. Datos protegidos como el . Acceso al muro. Acceso a la lista de amigos. Acceso a las fan pages. Acceso a a las fotografías, etc. Incluso una aplicación puede definir sus propios permisos para permitir que otras aplicaciones hagan uso de ésta a través de Facebook (Open Graph). 9

10 Índice Introducción OAuth 2 Enlaces Cliente o Servidor? Recordemos que el consumo de servicios REST se hace en servidor debido al SOP (Same-Origin-Policy). En GWT, la gestión de la navegación se hace en cliente, con lo que tendremos que hacer el proceso de autenticación con en cliente. Una vez que tengamos el token de acceso habrá que enviarlo a servidor para consumir el servicio quenos interese. La gestión del protocolo OAuth es un poco compleja, pero vamos a utilizar una librería para simplificarla: 10

11 GWT- Para usar la librería en nuestro proyecto: 1. Descargamos el jar de la librería: 2. Añadimos el jar al build path de la aplicación. 3. Indicamos en el fichero del proyecto gwt que debemos utilizar dicha librería: Registrando nuestra aplicación en el servicio GWT- necesita 3 valores para realizar la autenticación: Client ID URL del Servicio de Consulta de URL de Login Scope (permiso que se solicita, en caso de que sea necesario). Con esos valores y un objeto Auth de GWT-, podemos iniciar el proceso de autenticación llamando al método Login: Objeto Auth Parámetros necesarios Operación de Login y resultado 11

12 Registrando los parámetros para nuestra aplicación Ejemplo: Aplicaciones de Google La URL de login es la misma para todos los servicios: El Scope depende del servicio (API) de Google que queramos usar. Google provee de una consola de control para todas sus APIs: En la consola indicamos el nombre del proyecto que va a utilizar los servicios (el proyecto es nuestra aplicación) y en la pestaña Services indicamos que APIs queremos que pueda usar nuestra aplicación (en el login de un usuario nuestra aplicación no podrá solicitar acceso al Scope de una API que previamente no se haya autorizado en la consola de control). Solo nos faltaría el Client ID. Para crear el identificador de nuestra aplicación, lo haremos en la pestaña API Access. Para crear el Client ID Google nos va a pedir la url de Callback de nuestra aplicación. Esta URL la genera automáticamente la librería GWT-, y será: Registrando nuestra aplicación en el servicio Ejemplo: Aplicaciones de Google (Pestaña Services) Nombre de nuestra aplicación Permisos 12

13 Registrando nuestra aplicación en el servicio Ejemplo: Aplicaciones de Google (Pestaña API Access) Datos de información de nuestra Aplicación URL de Aplicación y URL de Callback (o Redirect) Registrando nuestra aplicación en el servicio Ejemplo: Aplicaciones de Google (Pestaña API Access) Este es el Client ID que usaremos en nuestra aplicación RESUMEN: Client ID: El proporcionado por Google. Url de Servicio de URL de Login: Scope: Depende del servicio. Por ejemplo, de Youtube: OJO! El Scope es una cadena sin un formato específico. En el caso concreto de los servicios de Google, esas cadenas tienen formato de URL, pero, en general, el scope no tiene por qué tener formato URL. 13

14 Registrando los parámetros para nuestra aplicación Ejemplo 2: Facebook La URL de login es la misma para todos los servicios de Facebook: Los tipos de permiso pueden consultarse en la documentación: Solo nos faltaría el Client ID. Para crear el identificador, tendremos que registrar nuestra aplicación. Esto se puede hacer en: Registrando los parámetros para nuestra aplicación Ejemplo 2: Facebook Solo es obligatorio el App Name, que puede ser el que queramos (que no existe). 14

15 Registrando los parámetros para nuestra aplicación Ejemplo 2: Facebook Una vez creada la aplicación aparecerá el panel de control de la aplicación y habrá que marcar que nuestra aplicación Web usará Facebook Login: Este es el Client ID Aquí hay que indicar la URL de Callback (usando GWT- será la misma que para google) Índice Introducción OAuth 2 Enlaces 15

16 Enlaces Librería GWT- Documentación OAuth Documentación sobre autenticación en Google API de Facebook APIs de Google Disclaimer and Terms of Use All material displayed on this presentation is for teaching and personal use only. Many of the images that have been used in the presentation are Royalty Free images taken from Other images have been sourced directly from the Public domain, from where in most cases it is unclear whether copyright has been explicitly claimed. Our intention is not to infringe any artist s copyright, whether written or visual. We do not claim ownership of any image that has been freely obtained from the public domain. In the event that we have freely obtained an image or quotation that has been placed in the public domain and in doing so have inadvertently used a copyrighted image without the copyright holder s express permission we ask that the copyright holder writes to us directly, upon which we will contact the copyright holder to request full written permission to use the quote or images. 16