Conectando sitios de forma segura con OAuth

Cliente: Se omite por cuestiones de confidencialidad (Alemania)

La empresa cliente alemana que contrató este proyecto dispone de una web con un alto componente de red social que dispone a su vez de una aplicación móvil para iPhone y Android que permite registrar recorridos que hacemos a pie, en coche o en moto y luego compartirlos con otros usuarios de su propio sitio web o de otras webs gracias a sus herramientas de exportación. Se trata de una aplicación similar a Endomondo, pero más orientada a registrar recorridos turísticos y de ocio que al plano deportivo.

Mi trabajo en este proyecto consistió precisamente en mejorar la funcionalidad de exportación, de modo que fuera posible conectar de forma segura el sitio del cliente con otros sitios de partners o colaboradores suyos para que se pudieran integrar en ellos toda la funcionalidad de registro y compartición de recorridos, compartición de fotos, comentarios, likes, etc. La idea era poder distribuir la aplicación móvil de registro de tours y toda la funcionalidad de su portal como marca blanca para que otros sitios de clientes suyos y partners pudieran ofrecer a sus propios usuarios toda su funcionalidad pero bajo su propia marca y diseño corporativo.

Esto planteaba el reto de que los usuarios de las webs conectadas se pudieran registrar en dichas webs pero que al mismo tiempo lo estuvieran haciendo también en el sitio web de mi cliente, y además que los tours y toda la actividad pública que dichos usuarios generaran sólo estuvieran disponibles para los usuarios del sitio web del partner al que pertenecían, y no al resto.

Además, sólo los sitios web autorizados podrían conectarse al portal de mi cliente, y dicha conexión debía hacerse de forma lo más segura posible.

Para lograr todo esto optamos por emplear el protocolo OAuth ampliamente utilizado por grandes empresas como Google, Facebook o Yahoo para compartir sus usuarios y permitir que éstos sean utilizados por aplicaciones de terceros de forma segura.

Error: Your Requested widget " ai_widget-6" is not in the widget list.

• [do_widget_area above-nav-left]
• [do_widget_area above-nav-right]
• [do_widget_area footer-1]
  • [do_widget id="wpp-4"]
• [do_widget_area footer-2]
  • [do_widget id="recent-posts-4"]
• [do_widget_area footer-3]
  • [do_widget id="recent-comments-3"]
• [do_widget_area footer-4]
  • [do_widget id="archives-4"]
• [do_widget_area logo-bar]
  • [do_widget id="oxywidgetwpml-3"]
• [do_widget_area menu-bar]
  • [do_widget id="search-3"]
• [do_widget_area sidebar]
  • [do_widget id="search-4"]
  • [do_widget id="ai_widget-2"]
  • [do_widget id="categories-5"]
  • [do_widget id="ai_widget-3"]
  • [do_widget id="ai_widget-4"]
  • [do_widget id="ai_widget-5"]
• [do_widget_area sub-footer-1]
  • [do_widget id="text-4"]
• [do_widget_area sub-footer-2]
• [do_widget_area sub-footer-3]
• [do_widget_area sub-footer-4]
• [do_widget_area upper-footer-1]
  • [do_widget id="search-2"]
  • [do_widget id="recent-posts-2"]
  • [do_widget id="recent-comments-2"]
  • [do_widget id="archives-2"]
  • [do_widget id="categories-2"]
  • [do_widget id="meta-2"]
• [do_widget_area upper-footer-2]
• [do_widget_area upper-footer-3]
• [do_widget_area upper-footer-4]
• [do_widget_area widgets_for_shortcodes]
  • [do_widget id="search-5"]
  • [do_widget id="ai_widget-6"]
• [do_widget_area wp_inactive_widgets]
  • [do_widget id="wpp-2"]
  • [do_widget id="text-1"]
  • [do_widget id="recent-posts-3"]
  • [do_widget id="categories-3"]
  • [do_widget id="archives-3"]
  • [do_widget id="icl_lang_sel_widget-3"]

En nuestro caso concreto, OAuth permitía conectar no sólo los usuarios de mi cliente con los de otros sitios web, sino además autenticar los propios sitios entre sí para evitar que otros sitios no autorizados utilizaran los servicios de mi cliente.

OAuth background

OAuth es un protocolo estándar que puede ser implementado en varios lenguajes de programación. PHP era el lenguaje utilizado por el servidor de mi cliente, pero esto no significa que los sitios web de sus partners y colaboradores que se conecten a él deban estar desarrollados también en esa tecnología. Es por tanto otra de las ventajas de utilizar OAuth, pues hay al menos una librería de este protocolo disponible para cada uno de los principales lenguajes de programación, incluyendo Perl, Java, C#, Python, Ruby, etc. Puedes encontrar una lista completa de estas librerías en https://oauth.net/code/.

Toda comunicación basada en el protocolo OAuth requiere la implicación de dos partes: un servidor OAuth que almacena los recursos protegidos que queremos compartir (proveedor), y un cliente OAuth (consumidor) que solicita el acceso a dichos recursos protegidos compartidos por el proveedor en nombre del usuario al que pertenecen. Estas dos partes deben ser conectadas inicialmente para que los usuarios del sitio que quiere conectarse al servidor de OAuth puedan acceder a los recursos protegidos, en nuestro caso recorridos y tours, sin que sea necesario que aquellos tengan que iniciar sesión ni introducir usuarios o contraseñas en el portal de mi cliente cada vez que quieran hacerlo.

Resultado

El resultado final de este proyecto fue una librería en PHP de OAuth modificada y optimizada para el caso concreto de mi cliente, la cual permitía conectar un sitio genérico desarrollado en PHP con el servidor también PHP de mi cliente. Para las pruebas en el lado del cliente se utilizó la aplicación phpFox, que también es un motor de redes sociales similar pero no igual al de mi cliente, de forma que pudimos establecer la conexión entre uno y otro mediante OAuth de forma segura e integrar perfectamente sus usuarios.

A continuación muestro algunas capturas del resultado, pero omitiendo cualquier dato sensible debido al acuerdo de confidencialidad que mantengo con mi cliente. Fíjate que las partes en azul pertenecen al sitio phpFox que se conecta (consumidor OAuth), y las partes en verde pertenecen a información procedente del servidor de mi cliente (proveedor OAuth).