La necesidad de ofrecer servicios digitales ha obligado a las empresas a diseñar cuidadosamente la experiencia de sus usuarios, considerando aspectos como la facilidad de uso, la personalización, la privacidad y también la seguridad. Desde el punto de vista de seguridad, uno de los retos mas importantes está asociado a la capacidad de gestionar la identidad de los usuarios. En este documento comentaremos como se da este proceso en las aplicaciones actuales dominadas por la telefonía móvil, y cómo estándares como OAuth y Open ID Connect son de utilidad para las empresas.
Uno de los primeros pasos que se realizan en los procesos digitales consiste en la autenticación, por medio de la cual el usuario del servicio demuestra que es quien dice ser, y una vez se aprueba este proceso, el servicio le ofrecerá al usuario acceso a información específica y a ciertas opciones personalizadas. Si bien este servicio de autenticación es bien conocido por los usuarios de internet, donde es común usar un nombre de usuario y una contraseña, no deja de ser tedioso y en algunas ocasiones puede arruinar completamente la experiencia de usuario.
Adicionalmente, los servicios digitales actuales están en capacidad de interactuar con múltiples servicios donde reposa información de los usuarios. Por ejemplo, es común que las redes sociales permitan el intercambio de información de un mismo usuario de tal manera que sus publicaciones aparezcan en diferentes plataformas. Este proceso podría ser muy tedioso para el usuario si quisiera entrar a cada red social para compartir su publicación. Una solución sería que el usuario le diera a una red social específica su contraseña para que pudiera acceder al resto de redes sociales, y así esta primera se encargaría de hacer la publicación en su nombre. Sin embargo esto sería muy inseguro, pues esa red social estaría en capacidad de acceder a toda la información del usuario, y el usuario no estaría en capacidad de controlar el acceso a sus cuentas. Aún así, este método se usaba hace algunos años, donde los usuarios compartían sus credenciales de acceso con terceros para que estos pudieran acceder a información de sus cuentas. Otro elemento problemático en este tipo de interacción es que le generaría a la primera red social la responsabilidad de gestionar la contraseña del usuario en el servicio de un tercero, lo cual no es su objetivo.
Este tipo de modelos que permiten que la información de un usuario se pueda acceder sin necesidad de obligarlo a compartir su contraseña con terceros ha ido evolucionando al ritmo de internet, a tal punto que hoy en día hay estándares bien establecidos que permiten a diferentes aplicaciones acceder a información de un usuario de manera organizada, con procesos de autenticación organizados.
A continuación, hablaremos de dos estándares bien establecidos y vigentes para el proceso de delegación de autorización y el proceso de delegación de autenticación.
OAuth 2.0
El estándar Oauth 2.0 fue propuesto en 2012 y aparece publicado por la IETF [RFC6749]. En este documento se propone “un marco para permitir a una tercera parte acceder a un servicio HTTP ya sea en nombre del dueño del recurso orquestando una interacción de aprobación entre el dueño del recurso y el servicio http, o permitiéndole a la aplicación de la tercera parte acceder por su parte.” Por ejemplo, en el caso de un usuario que tenga cuentas en las redes sociales A y B, y desee que la red social A acceda a contenidos de la red social B, puede realizarlo siguiendo los procedimiento establecidos por OAUTH 2.0. En este caso el dueño del recurso es el usuario que posee las dos cuentas en las redes sociales, por lo cual para que la red social A pueda acceder a la información que reposa en la red social B es necesario que se de una autorización. El proceso mediante el cual las partes se ponen de acuerdo para permitir que la red social A acceda a la información que reposa en la red social B viene especificada en este documento. Adicionalmente, es posible que como parte del servicio que ofrece la red social A, necesite acceder a información de otra fuente, como podría ser la publicación de noticias de un periódico. En este caso, la autorización para acceder a dicha información no vendría del usuario, sino directamente de la red social A. Este tipo de procedimiento también viene especificado en OAuth 2.0.
OAuth 2.0. define los siguientes roles: dueño del recurso, servidor de recursos, cliente y servidor de autorización. El dueño del recurso se define como “una entidad que tiene la capacidad de ofrecer acceso a un recurso protegido”. Este puede ser un usuario final, o una entidad, como en el caso explicado anteriormente donde una red social quería publicar en su plataforma noticias de un periódico. El servidor de recursos es “donde reposan los recursos protegidos”. Este servidor debe estar en capacidad de responder a peticiones por medio de tokens, siguiendo los lineamientos del estándar. El cliente es una aplicación que solicita acceder a un recurso protegido en nombre del dueño del recurso. Finalmente, el servidor de autorización “genera tokens al cliente después de haber autenticado de manera exitosa al dueño del recurso y de haber obtenido una autorización”.
En la Fig. 1. se muestra un esquema general del funcionamiento de OAuth 2.0. que puede ser útil para comprender los elementos planteados en el párrafo anterior y su funcionalidad. En este ejemplo, el usuario (dueño del recurso) accede a una página web de su banco para solicitar un crédito. Como parte de este procedimiento, el banco debe acceder a un buró de crédito, donde reposa información del usuario, lo cual le servirá para decidir si aprueba o no dicho crédito. Asumamos que la información que reposa en el buró de crédito (servidor de recursos) le pertenece al usuario. Por lo tanto, el banco solo puede acceder a dicha información si el usuario (dueño del recurso) da su autorización. Una vez el banco busca acceder a esta información por parte del usuario se convierte en el cliente, según la definición de OAuth 2.0.
Figura 1. Esquema general de OAuth 2.0
Siguiendo el esquema presentado en la Fig.1, es posible entender cómo funciona OAuth 2.0. Como lo mencionamos antes, el usuario desea acceder a un crédito desde su teléfono móvil, y asumimos que su puntaje crediticio reposa en un buró de crédito al cual no es posible acceder sin su autorización. Adicionalmente, el usuario no quiere darle al banco las credenciales de su cuenta del buró de crédito. Por lo tanto, el banco debe acceder a esa información usando otro medio. En el paso 1, el banco le solicita al usuario la autorización por medio de una solicitud de autorización. Esta solicitud puede darse de manera directa como aparece en el diagrama, o por medio del servidor de autorización. En el paso 2, el cliente recibe una autorización. Posteriormente, en el paso 3, el cliente le solicita al servidor de autorización un token usando la información que recibió del cliente. En el paso 4, el servidor de autorización valida la información que recibió del cliente, y le entrega al cliente un token. Este token es el que en el paso 5 el banco le presentará al buró de crédito de tal manera que se le permita el acceso al recurso protegido. Finalmente, en el paso 6 el buró de crédito le entrega la información al banco, y este puede decidir si le acepta o no el crédito al usuario. Por lo tanto, el banco no accede a los recursos usando las credenciales del usuario para el buró de crédito, sino por medio de un token que además tiene una validez temporal.
Si bien el diagrama presentado antes sirve para entender de manera general como funciona OAuth 2.0, existen diferentes métodos mediante los cuales las aplicaciones (en nuestro ejemplo el banco) pueden acceder a los recursos protegidos (en nuestro ejemplo el puntaje crediticio que reposa en el buró). Por ejemplo, en el método llamado “Authorization Code Grant”, que es el más usado, la aplicación redirige al usuario para que presente sus credenciales directamente con el servidor de autorización. Es importante resaltar que de esta forma la aplicación del banco podría acceder a otras cuentas del usuario, sin necesidad de que el usuario comparta las claves de sus cuentas.
Open ID Connect
En [OID2014] se define a Open ID Connect como “una capa de identidad encima de OAuth 2.0”. Por lo tanto, Open ID Connect desarrolla la arquitectura y elementos definidos por OAuth 2.0, si bien algunos elementos tienen nombres diferentes. El objetivo de Open ID Connect es permitir la autenticación del usuario de manera estándar, algo que no venía especificado por OAuth 2.0, por lo cual se habían desarrollado en su momento soluciones propietarias que limitaban su interoperabilidad. Por lo tanto, al ser Open ID Connect un estándar adoptado por la industria, permite que la autenticación se pueda delegar de una manera más sencilla.
Dado que Open ID Connect funciona en conjunto con OAuth 2.0. y su función es la de permitir una autenticación delegada, en la figura 2 mostramos el proceso de autenticación, y los elementos que lo componen. En primer lugar, el estándar define un usuario final, que es el usuario humano. Adicionalmente define un Proveedor de Open ID, el cual debe cumplir con el estándar OAuth 2.0, y tiene la capacidad de autenticar a un usuario final. Adicionalmente, este servidor debe tener la capacidad de dar información acerca de los eventos de autenticación y del usuario final a una parte de confianza o “relying party”. Esta parte de confianza es una aplicación que cumple con el estándar OAuth 2.0, y que requiere autenticar al usuario final. Por lo tanto, siguiendo el mismo ejemplo de la sección anterior que aparece ahora en la figura 2, la parte de confianza sería la página web del banco. Por otro lado, el Proveedor de Open ID podría estar localizado en conjunto con el servidor de autorización de OAuth 2.0. Recordemos que los servicios de autorización y autenticación son diferentes, ya que el primero indica que se puede acceder a un recurso y el segundo se encarga de validar que las credenciales presentadas corresponden a una identidad.
Volviendo a la figura 2, en el primer paso la parte de confianza solicita al proveedor de Open ID que autentique al usuario. El servidor de Open ID envía la solicitud de autenticación al usuario, que provee las credenciales correspondientes para autenticarse. En este intercambio de información también es posible intercambiar información acerca del alcance de la autorización que se le va a dar al banco. Esto es importante ya que si bien el banco puede estar en capacidad de acceder al puntaje crediticio del usuario, no debería estar en capacidad de modificarlo o de cambiar los datos personales del usuario, por ejemplo. Si la información que se intercambió es satisfactoria, el proveedor de Open ID le envía a la parte de confianza un ID token, y generalmente un token de acceso. La diferencia entre estos es que el ID token provee el servicio de autenticación, mientras que el token de acceso provee el servicio de autorización. Los pasos 4 y 5 hacen referencia a solicitudes que puede hacer la aplicación al proveedor de Open ID respecto al usuario final, o al proceso de autenticación. Estas solicitudes pueden estar asociadas a datos personales como nombres y apellidos, correo electrónico, fecha de nacimiento, entre otros.
Como se puede ver, por medio de Open ID se pueden implementar diferentes mecanismos de autenticación que pueden ir asociados al nivel de seguridad de la transacción, y que separan también la necesidad de que el usuario final comparta sus credenciales con diferentes actores.
Conclusiones
La interacción entre diferentes fuentes de datos para el funcionamiento exitoso de servicios digitales trae nuevos retos asociados no solo a la experiencia de usuario, sino a la manera en que se gestiona la identidad de los usuarios. Procesos como el de autorización, autenticación y seguimiento de políticas de acceso se simplifican considerablemente en estos escenarios por medio de herramientas estándar como OAuth 2.0 y Open ID Connect. En este documento hicimos una revisión básica para entender los objetivos de estos dos estándares y su interacción.
Diego Pacheco-Páramo
Bibliografía
[RFC6749] Request For Comments 6749. The OAuth 2.0 Authorization Framework. Internet Engineering Task Force. October 2012. ISSN : 2070-1721.
[OID2014] OpenID Connect Core 1.0. https://openid.net/specs/openid-connect-core-1_0.html. 2014
