Servicios Web – II

Fuente original: http://jordisan.net/proyectos/Autent_y_auth-J_Sanchez.pdf

Con la proliferación de los servicios web en Internet, surgió un problema de relevancia, la autenticación. Los servicios disponibles han crecido enormemente, y la mayoría de usuarios utilizan  múltiples aplicaciones de terceros: por ejemplo, un usuario consulta su correo en un sistema de webmail, desde el teléfono o desde su cliente de correo. También es habitual la participación en redes sociales como facebook, linkedin, tuenti o twitter, etc. La mayoría de esas aplicaciones requieren que el usuario se autentique; es decir, que demuestre de algún modo (habitualmente usando un identificador de usuario único y una contraseña asociada) que es quien dice ser.

Al tratarse de aplicaciones independientes entre sí, en principio cada una de ellas utilizaría  su propio sistema de autenticación y de gestión de datos personales, lo cual implica inconvenientes al usuario cada vez más graves a medida que el número de sistemas que utiliza crece.

Surge la necesidad de conocer cuales son las tendencias actuales respecto a la autenticación y autorización en Internet.

Autenticación vs. autorización

Antes de seguir, es necesario hacer una distinción clara entre dos tipos de servicios ofrecidos por las tecnologías que vamos a describir.

  • Autenticación: consiste en un sistema para certificar que el usuario es quien dice ser; lo más común es utilizar una combinación de identificador de usuario único y contraseña.
  • Autorización: consiste en dar acceso a una serie de recursos a un usuario o sistema (para ello, el usuario o el sistema previamente tendrán que haberse autenticado).

Protocolos y estándares ampliamente adoptados

Una primera solución evidente al problema de la autenticación sería el uso  de algún tipo de certificado personal (basado, por ejemplo, en el estándar X.509) emitido y validado por alguna autoridad central  de confianza. Si bien este tipo de certificados son útiles para gestiones  con determinadas entidades,  no son prácticos en general para el acceso a servicios de Internet. Por este motivo han surgido varios protocolos de autenticación y autorización en Internet.

OpenID

image
El protocolo abierto OpenID, cuya primera versión fue definida en 2005 para su uso en el sitio web LiveJournal, es un protocolo de autenticación federada, y consiste básicamente en que el usuario selecciona un servidor externo (el “proveedor” de OpenID) que va a ser el que va a validar su identidad en un sistema determinado (el “consumidor” de OpenID).

Problemas de OpenID:

  • Complejidad: no se implementa fácilmente.
  • Seguridad: es un protocolo muy vulnerable al  phishing.
  • Privacidad: los proveedores de OpenID tendrán mucha información del usuario.
  • Confianza: ¿quién es realmente el usuario?.
  • Usabilidad: puede ser incómodo  y/o complejo  para el usuario.
  • Adopción: los proveedores de servicios tienen pocos motivos para aceptarlo como autenticación.
  • Disponibilidad: se incrementa la dependencia de servidores.
  • Patentes: no es un protocolo “tan” abierto.
OAuth

image

El protocolo abierto OAuth, a diferencia de OpenID, es un protocolo de autorización; más exactamente, de delegación de acceso; es decir, permite definir cómo un tercero va a acceder a los  recursos propios. Empezó a definirse en 2006 y en 2007 se publicó la primera versión oficial.  El propósito de este protocolo es, pues, que un usuario que tiene determinados recursos en un servidor (el “proveedor” de OAuth) pueda dar acceso a un tercero (el “consumidor”, usualmente un sitio web) a parte o todos esos recursos, sin necesidad de que ese tercero conozca su usuario y contraseña, ya que con esos datos tendría el control total de la cuenta.

Problemas de OAuth:

  • Complejidad.
  • Orientado a navegadores.
  • Seguridad.
OAuth 2.0

imageOAuth 2.0  pretende ser una versión revisada y simplificada de OAuth. Aventaja a la versión anterior en una mayor simplicidad de implementación, y en una arquitectura más robusta y que da soporte a mayor número de plataformas.

Existe cierta confusión sobre si OAuth es o no un protocolo de autenticación de usuario. Estrictamente hablando  no lo es, ya que no define ningún mecanismo  explícito destinado a autenticar la identidad del usuario. Por tanto, cuando se habla del  “mecanismo de autenticación de OAuth”, en realidad  se están refiriendo al mecanismo de autenticación propio del sitio web proveedor de OAuth, que puede ser cualquiera: autenticación http básica, OpenID, etc.

 

Nuevos Protocolos y estándares

OpenID OAuth Hybrid Protocol

Como hemos visto, OpenID y OAuth son protocolos con objetivos distintos aunque complementarios: autenticación de usuario (federada) y autorización, respectivamente. El protocolo híbrido OpenID OAuth  combina ambos sistemas, integrándolos en una interfaz única.

Facebook Connect

Debido al enorme incremento de usuarios y, en consecuencia, de datos personales que ha experimentado Facebook en los últimos años, la compañía lanzó en 2008 su propio sistema conocido como Facebook Connect.  Con ese movimiento, Facebook pretendía posicionarse como repositorio central de identidad de los usuarios en Internet. En la actualidad Facebook parece haber  abandonado Facebook Connect para adoptar el protocolo 2.0 de OAuth.

OpenID Connect

El protocolo OpenID Connect es la última propuesta para reactivar OpenID. Su propósito es redefinir y simplificar el protocolo construyéndolo sobre el protocolo OAuth; de ese modo se aprovecha el trabajo desarrollado para OAuth, que parece  estar  extendiéndose rápidamente, dotándolo de una funcionalidad estándar de autenticación que, como hemos visto anteriormente, no posee.

 

Otros sistemas

Algunos de los grandes proveedores de servicios en Internet han definido, en algún momento, su sistema propio  de autenticación y/o autorización. Sin embargo, la mayoría de ellos están adoptando  estándares  como OpenID y, especialmente, OAuth; es el caso, por ejemplo, de MySpace, Twitter o Yahoo!.

Otro estándar abierto para el intercambio de recursos de identidad es Security Assertion Markup  Language (SAML). Está basado en XML, y su principal propósito es servir de marco para protocolos de autenticación federada. Este protocolo sirve de base para algunos sistemas propietarios de single-sign-on, pero no es utilizado por los grandes proveedores de servicios en Internet.

 

Resumiendo

image

Descargar en formato PDFDescargar en PDF
1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (4 votes, average: 3,50 out of 5)
Loading...

Seguir Jorge Hontoria Jiménez:

Gerente de TipeSoft

Dirección de proyectos de integración de software y aplicaciones orientadas a servicios. Implantación de soluciones de integración basadas en SharePoint Portal.

Últimas publicaciones de

3 Respuestas

  1. Mario Valdés

    Estos días he conectado V7 con oAuth2 y funciona bastante bien. El único problema es que lo hace por SSL con todo lo que ello conlleva.

  2. Desde V7 (con la introducción de QML y JavaScript) se podrán usar todos los protocolos estándares y abiertos de autenticación y autorización sin demasiada dificultad.

    En el próximo artículo de la serie os explicaremos un ejemplo sobre QML y javascript que usa OAuth para realizar la autenticación sobre twitter.

  3. Mario Valdés

    Si, pero quería ir probando otras cosas sin utilizar QML y JS.
    -Solicitud de autorización
    -Puerto a la escucha pasado en la solicitud de autorización
    -Recepción de código

Dejar una opinión