Si algo hemos notado a lo largo de estos últimos años es que las aplicaciones en internet se han ido diversificando mas y mas, con el tiempo hemos pasado de aquellas arquitecturas monolíticas a otro tipo de arquitecturas más flexibles como las arquitecturas de servicios que nos propone SaaS.

Y en el mundo de la identidad, la cosa, no es muy diferente desde hace unos años un nuevo modelo ha ido cobrando fuerza y no es más que las IDaaS (Identity as a Service).

Este nuevo modelo propone una solución a nuestro clásico sistema de autenticación de usuarios, haciendo que el proceso sea mucho más seguro y protegiéndonos de posible ataques o hackeos en nuestra aplicación o sitio web.

¿Cómo funciona?

El concepto de este servicio es extremadamente sencillo, pero aun asi propone una cantidad de posibilidades que hace muy atractivo el uso de este nuevo método, veamos la siguiente imagen:

service idaas

Vamos a imaginar que tenemos un sitio-web/app que para acceder a un contenido o a toda la aplicación necesitamos tener al usuario autenticado.

Como vemos en la imagen superior tenemos un espacio bloqueado, en el cual, creamos un botón/enlace que nos va redirigir a la página de nuestro proveedor IDaaS.

En esa pagina nuestro proveedor nos va a dar una serie de funcionalidades, como logear, registrar…y este se va a encargar de verificar que el usuario es quien dice ser o registrarlo en su base de datos.

Una vez confirmado y autenticado el proveedor nos redirigirá a nuestro sitio web donde permitiremos al usuario registrado acceder al contenido.   

Bien, esto es lo que básicamente vería un usuario, ya que el proceso, es prácticamente transparente para el usuario. Pero que ha pasado realmente por detrás?

Protocolos

Aunque es cierto que cada proveedor funciona de forma y con protocolos diferentes lo cierto es que hay un cierto estándar en el modo de uso.

Por lo general los proveedores IDaaS proponen los siguientes protocolos para su uso, OpenId, SAML, Oauth, LDAP, JWTs y WS-Fed.

Cada uno tiene un propósito según el uso y la aplicación que queréis usar, pero por lo general yo os recomiendo el OpenID por muchas razones, pero las principales son, que es gratis, que es muy fácil de usar y prácticamente todos los CMS tops tienen un módulo que lo integra de forma simple.

Protocolo OpenID

Si usamos OpenId, lo único que vamos a necesitar es, configurar el protocolo en nuestro proveedor, el cual nos proveerá de dos valores importante, el clientId y el clientSecret que son fundamentales para hacer funcionar este protocolo y que nos permita hacer las peticiones correctamente.

Aparte de estos dos valores vamos a necesitar también definir un «RedirectURL» el cual, básicamente, es la url a la que queremos redirigir al usuario, una vez ha completado el formulario en nuestro proveedor.

Ojo, porque esta redirección no es trivial, el proveedor no solo nos va a redirigir a esa página, si no que además nos va a enviar los datos del usuario que relleno en el formulario amén de información extra que nos será útil para utilizarlo en nuestra aplicación.

Así que esa landing donde redirigimos al usuario la hemos de usar a modo de tratamiento de datos , donde podremos crear el usuario en nuestra base de datos, crear una cookie o lo que necesitemos para hacer funcionar nuestra app.

Otros valores que nos tendrá que dar nuestro proveedor, son los endpoint que hacen que funcionen con el protocolo OpenId, como cada proveedor puede ser que lo llame de forma diferente os recomiendo que busquéis estas palabras o parecidas. OJO que son tres valores diferentes: «Authorization«, «Token«, «UserInfo«.

Cada uno tiene una función diferente dentro de las llamadas en el protocolo de OpenId, podéis aprender mas de este protocolo aquí.

Es probable que segun lo que necesiteis os pidan un «cookieSecret«, esto es solamente un texto propio vuestro para poder garantizar la integridad de las interacciones y comprobar que nadie ha modificado nada por el camino.

Pero aquí no termina todo, si queréis obtener información de los usuarios con este protocolo, vamos a tener que definir scopes y que son los scopes?

Scopes y Claims

Los scopes, en realidad, son todo un mundo complejo, pero vamos a tratar de verlo desde un punto de vista sencillo.

En esencia un scope es una «simple» agrupación de «claims» (Pensemos en claims como «atributos» de una entidad, pero es más complejo que eso.), por lo general los nombre de los scopes ya nos dicen que va a contener, así que podríamos entenderlos como accesos a porciones de información del usuarios.

OpenId especifica por defecto una serie de scopes y claims que todos los proveedores de este protocolo han de cumplir, aun así deberemos mirar su documentación puede ser que añaden algunos extras.

Scope Claims
email email, email_verified
address address
profile name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at
phone phone_number, phone_number_verified
openid sub, auth_time, acr

Como veis en la tabla de arriba cada scope nos va a devolver una serie de claims, veamos esto con el scope «profile», en el cual vemos una cantidad de claims, que recibiremos solamente con añadir ese scope a la petición.

Aunque puede ser muy abrumador esto de los scopes y los claims, lo cierto, es que lo podríamos comparar con una consulta a la base de datos, en la cual, en lugar de hacer una petición pidiendo columna por columna, lo que hacemos es hacer una especie de petición «atajo» el cual nos devuelve múltiples columnas pero solo usando una petición simple.

Ventajas

Después de ver un poco más en profundidad cómo funciona OpenId veamos cuales son las ventajas de usar un proveedor IDaaS.

  1. Dejamos toda la complejidad de las conexiones a nuestro proveedor.
  2. Nos añade una capa de seguridad a nuestro sistema de registro.
  3. En caso de que hackeen el formulario, en ningún caso estarán accediendo a nuestro sitio web/app por lo que nuestros datos estarán seguros.
  4. Permite añadir funcionalidades con un solo golpe de click como, SSO, PassKey, PasswordLess o One Time Login, FingerPrint, validación por código…
  5. Posibilidad de anonimizar los usuarios en la base de datos de nuestro sitio-web/app.
  6. Posibilidad de centralizar la información de nuestros usuarios durante el uso de varias app.

Conclusión

Sin duda alguna, esto es una gran solución para aquellas aplicaciones las cuales tengan un gran tráfico de usuarios y/o quieran compartir usuarios en diferentes app.

Aunque es bastante fácil instalarlo y hacerlo andar lo cierto es que si requieres customizar la experiencia o modificar algo del comportamiento estándar que propone tu proveedor, si que es cierto que la cosa se complica.

Por lo general, os aconsejo que lo utiliceis en algún proyecto y veais las mejoras que traerán a tu proyecto y vosotros mismo decidáis si queréis usarlo o no.

Os dejo el video de nuestra presentación en la comunidad de drupaleros.