La necesidad de ofrecer más y mejores servicios dentro de una misma aplicación lleva a las empresas a integrar sus plataformas con otras que puedan cumplir con este objetivo. Para lograr este objetivo de una manera segura es necesario realizar una integración entre distintos software y ese puente suele construirse a partir de una interfaz de programación de aplicaciones o API. Pero además, es necesario realizar procesos de autenticación durante este proceso y es allí donde entra en juego el Oauth 2.0.
Este estándar también conocido como Open Authorization es utilizado con la finalidad de acceder de manera limitada a la información privada de una determinada aplicación web o móvil. Así, no es necesario para las personas propietarias entregar credenciales de identificación, una acción que puede generar desajustes y perjudicar el funcionamiento normal del sistema.
Por otro lado, el Oauth 2.0 no ingresa directamente a la información, por lo que es de gran ayuda para la protección de datos. Se ha vuelto popular en el mercado y cada vez más compañías lo utilizan durante la integración de sus aplicaciones. Por lo tanto, conocer sus características y beneficios se vuelve de suma importancia a la hora de generar mejores experiencias para los usuarios sin poner en riesgo sus datos e información privada.
Índice de temas
Oauth 2.0: explicación, conceptos básicos y características
El Oauth 2.0 es un estándar abierto cuya utilización es relativamente simple a la hora de generar autenticaciones seguras de APIs e iniciar sesión en una app. De esta manera, el propietario de un sitio o aplicación, a quien se lo denomina Proveedor de Servicio, le puede permitir a otro sitio, llamado Consumidor, la posibilidad de acceder a sus recursos privados sin preocuparse por la seguridad interna de sus datos.
Si bien no es un estándar nuevo en el mercado y es similar a otras que existen, se ha vuelto popular durante los últimos años. Esto se debe a que agrupa las mejores prácticas de protocolos en un solo espacio bien definido y abierto, lo que brinda beneficios a las empresas que lo utilizan. En la actualidad, compañías como Twitter y Flickr se han volcado a esta opción debido a los beneficios que genera.
El crecimiento de Oauth 2.0 fue tan grande en los últimos tiempos que los profesionales esperan que su utilización termine siendo por default. Es decir, que sea el estándar de uso internacional cada vez que dos servicios en Internet busquen compartir información o recursos de sus propias plataformas o de los usuarios.
Cómo nace OAuth 2.0
El estándar Oauth comenzó a ser utilizado en 2006 gracias a Blaine Cook, quien se desempeñaba como desarrollador en el sector OpenID de Twitter. Acompañado por un equipo conformado por Chris Messina y Larry Halff, desarrollaron una solución para una empresa llamada Ma.gnolia, compañía que necesitaba que sus miembros pudieran acceder a su servicio a partir de un framework de autorización en su dashboard.
Para lograr esto, se realizó un trabajo en conjunto con Twitter para delegar la autenticación a la hora del uso de las APIs. Luego de varias reuniones y debates, se llegó a la conclusión de que la mejor manera de hacerlo era a través de un estándar abierto que, hasta ese momento, no había sido desarrollado por nadie.
Para abril del 2007 se propuso que un grupo de profesionales comiencen a trabajar en la creación de este proceso. DeWitt Clinton, quien en ese momento trabajaba para Google, se sumó al notar las posibilidades que podía generar un desarrollo de estas características. Con su ayuda, el equipo logró un borrador para mediados del 2007 y para octubre de ese año el primer Oauth Core 1.0 fue publicado de forma oficial.
De todas formas, este primer intento necesitaba evolucionar y fue así como se trabajó hasta llegar al Oauth 2.0, lanzado oficialmente en 2012. Este se caracteriza por promocionar los flujos de autorización entre aplicaciones y otros sitios de Internet. En la actualidad, plataformas como Facebook o Twitter solo admiten este estándar, lo que demuestra la gran relevancia que supo obtener durante la última década.
Elementos que intervienen en Oauth 2.0
Una forma de entender mejor el funcionamiento de Oauth 2.0 y sus características es definir los elementos que forman parte del proceso. Si bien son acciones que se llevan a cabo en pocos segundos, son varios los componentes necesarios para que esto ocurra. Cada uno de ellos tiene un trabajo específico para realizar y, de no hacerlo correctamente, puede perjudicar a todo el flujo de trabajo.
Propietario
En Oauth 2.0 el propietario es quien tiene los recursos y da autorización a una aplicación web o móvil preestablecida para que acceda a su cuenta. Si bien la API no es de su propiedad, sí lo son los datos que se van a utilizar y por eso se lo denomina de esta manera. Gracias a esto, la app que realiza la solicitud de acceso puede llevar a cabo acciones en su nombre sin la necesidad de realizar procesos extensos de autentificación.
Sin embargo, las acciones que puede realizar dentro de la aplicación del propietario son limitadas y a ellas se las denomina alcance. Así, podría permitirse desde un acceso de lectura hasta la implementación de distintos procesos según se considere necesario. Un ejemplo de esta situación ocurre con Twitter y Facebook, plataformas que permiten la integración de widgets, pero no la generación de contenido novedoso.
Servidor de recursos
Cuando se habla del servidor de recursos en el estándar Oauth 2.0 se hace referencia a la API propiamente dicha. Es decir, al servidor donde se alojan aquellos recursos a los cuales se quiere acceder. Al estar protegidos, solo se puede acceder a la parte que el propietario dio consentimiento para utilizar y que es justamente Oauth 2.0 el encargado de controlar ese acceso a través de la autentificación.
Cliente
En Oauth 2.0, el cliente es la app o sitio web que busca acceso a los recursos de la aplicación que los tiene y cuyo dueño está dispuesto a compartir. Precisamente es este estándar el que le brinda el solicitado de acceso a una determinada parte de la app con el objetivo de que pueda utilizar esas funcionalidades sin la necesidad de autentificar cada paso. En este caso, el cliente puede ser desde otra aplicación, tanto web como móvil, como una API o un dispositivo IoT, entre otros.
Servidor de autorización
Cada vez que se realiza un pedido para ingresar a la aplicación que brinda los recursos, en Oauth 2.0 hay un servidor de autorización que gestiona ese proceso. Su trabajo es verificar la Client ID o identidad del usuario que busca entrar al sistema y corroborar que tiene el aval del propietario para hacerlo. De encontrarse todo en regla, se emiten una serie de tokens, que son “las llaves” para acceder al sector que previamente se estableció como abierto para ese usuario. Este proceso se puede llevar a cabo de forma interna o puede derivarse a un tercero para que lo lleve a cabo.
Tokens
Cuando el servidor de autorización en un estándar Oauth 2.0 habilita el ingreso a un usuario, genera una serie de tokens. En este sistema no se utilizan credenciales, sino estos elementos que son los que “abren las puertas” a los recursos de la aplicación del propietario que se pueden utilizar. Estos tokens son cadenas alfanuméricas aleatorias difíciles de adivinar que se crean de forma única cada vez que se da ingreso al sitio. Por lo general, se usan a la par del Consumer Secret con el objetivo de prevenir el abuso de la utilización de tokens. Además, existen dos tipos: el de petición y el de acceso.
Tokens de actualización
Cuando en Oauth 2.0 es necesario obtener un nuevo token de acceso a la aplicación del propietario, se requiere un token de actualización. De esta manera, el sistema se conecta con el token original para corroborar que el usuario es el mismo. Una vez realizado ese paso, se solicita un nuevo token y el mismo es enviado para poder continuar con los procesos permitidos.
Un ejemplo que muestra cómo funciona este procedimiento es el cambio de contraseña de un usuario en Google. “Con el objetivo de aumentar la seguridad, se revocan automáticamente los tokens de OAuth 2.0 emitidos para acceder a determinados productos”, señalan en la empresa. Y agregan: “Al cambiar la contraseña de las aplicaciones de correo de terceros, como Apple Mail y Mozilla Thunderbird, así como de otras aplicaciones que utilicen alcances de correo para acceder a uno, estas dejan de sincronizar datos hasta que se asigne un nuevo token de OAuth 2.0”.
Alcance o Scope
Dentro del estándar Oauth 2.0 se denomina alcance o scope a todas aquellas acciones que un usuario o cliente puede realizar dentro de la aplicación del propietario. Una vez establecido que se le dará accesos a los recursos, también se predetermina qué se podrá y qué no se podrá llevar a cabo. De esta manera, se limita el acceso a aquellas funciones que quieren prestarse, pero el resto continúa protegido y no es posible utilizarlo.
“Es un mecanismo para limitar el acceso de una aplicación a la cuenta de un usuario. Una aplicación puede solicitar uno o más alcances, esta información luego se presenta al usuario en la pantalla de consentimiento y el token de acceso emitido a la aplicación se limitará a los alcances otorgados”, explican los expertos en Oauth 2.0. Y suman: “El estándar no define ningún valor particular para los ámbitos, ya que depende en gran medida de la arquitectura interna y las necesidades del servicio”.
Qué son los flujos en Oauth
Una vez que el estándar Oauth es aplicado y se permite el acceso limitado a los recursos de la aplicación del propietario, hay varios flujos de acceso, o dinámicas de utilización, que se pueden utilizar. De todas formas, hay un protocolo genérico que explica cómo es el acceso en la mayoría de los casos.
“Los flujos de autorización Oauth dan acceso restringido a una aplicación cliente a recursos protegidos en un servidor de recursos. Cada flujo de OAuth ofrece un proceso diferente para aprobar el acceso a una aplicación cliente, pero en general los flujos constan de tres pasos principales”, comentan los especialistas de SalesForce, empresa dedicada al software bajo demanda. “Para iniciar un flujo de autorización, una aplicación cliente solicita acceso a un recurso protegido. En respuesta, un servidor que autoriza otorga tokens de acceso a la aplicación cliente. Un servidor de recursos valida a continuación estos tokens de acceso y aprueba el acceso al recurso protegido”, concluyen al respecto.
Por lo tanto, cuando un cliente, que puede ser otra aplicación, un dispositivo IoT, otra API, etc, busca ingresar a la aplicación del propietario se pide una autorización. En caso de estar habilitado el ingreso, se le concede el acceso y el usuario pasa a un servidor de autorización. Es en ese momento que obtiene el token requerido para ingresar y recién ahí puede trabajar con los recursos que le fueron brindados.
Siempre y cuando los pedidos coincidan con los parámetros preestablecidos, el usuario podrá trabajar sin preocupaciones dentro de la aplicación del propietario. En ese sentido, es importante remarcar que solo se podrá tener autorización para acceder a los recursos que le fueron brindados, mientras que el resto permanecerá fuera de su alcance.
Diferencias entre Oauth 2.0 y JWT
Mientras que Oauth 2.0 es un estándar que habilita el acceso a una aplicación mediante tokens, JWT es una notación de objeto de Java Script. Es decir, una herramienta que también es abierta y que tiene como objetivo transmitir información entre dos campos pero sin estar estandarizada. Además, está conformada por demandas o claims, los elementos encargados de realizar la transmisión de información de un lugar a otro. Los mismos pueden estar relacionados con el acceso a la información, el tiempo que se tarda en validar el ingreso, los permisos o cualquier otro concepto que esté involucrado con los datos a los que se quiere llegar.
En esa línea, la mayor diferencia entre Oauth 2.0 y JWT es que el segundo no tiene la capacidad de definir cómo el usuario obtiene el token, ya que solo es un formato y no un protocolo. Si bien es una diferencia que a simple vista puede parecer poco relevante, el proceso de emisión del token es fundamental para determinar quiénes pueden tener autorización para acceder a los recursos y cuál es su alcance.
Seguridad y Oauth
Como Oauth 2.0 otorga al cliente o usuario privilegios mínimos de acceso a los recursos, la seguridad de la aplicación del propietario es elevada. Todos aquellos aspectos que no quieran ser cedidos a otra aplicación o sitio, permanecen fuera de su alcance y resulta extremadamente difícil poder sortear el flujo de trabajo preestablecido. Además, el client secret, necesario para realizar cualquier consulta en una API se puede utilizar sin inconvenientes.
“OAuth es importante porque deja la gestión de la delegación web en manos del auténtico propietario de los recursos. El usuario establece las conexiones entre sus cuentas en distintas aplicaciones web sin la implicación directa de los administradores de seguridad de cada sitio”, indican los expertos de CA Technologies. “Además, tiene la capacidad de alargar esta relación en el tiempo cuanto desee, pero también de terminarla con facilidad. Una de las grandes mejoras que aporta OAuth a la comunidad web es la formalización del proceso por el que se delega la asignación de identidades a los usuarios”, continúan.
De todas formas, es necesario destacar que Oauth es solo un componente de seguridad dentro del sistema. Si bien es un proceso que resguarda los datos que están fuera de alcance, no reemplaza a otros elementos de seguridad que deben complementarse con su uso para garantizar la protección de la información.
Ejemplos de uso de Oauth 2.0
Desde su lanzamiento oficial en 2007, y sus respectivas actualizaciones desde entonces, Oauth 2.0 se convirtió en uno de los estándares más utilizados a la hora de compartir recursos a través de APIs. Empresas como Google, Twitter, Facebook y Microsoft Azure Active Directory encontraron en este protocolo un funcionamiento adecuado para poder realizar alianzas con otras compañías sin la preocupación de ceder información que no quieren compartir.
En ese contexto, si una plataforma como Facebook o Twitter quiere brindarle acceso a un usuario sin la necesidad de que este deba registrarse, encuentra en Oauth 2.0 un estándar sencillo y seguro de utilizar. Actualmente, ambas empresas tienen la opción de autentificarse a través de este sistema para alcanzar ciertos recursos dentro de ellas. No todos están disponibles, pero sí varios que pueden servir para vincular a otra solicitud que la aplicación recibe con una API.
El mayor beneficio de esto es que como todo se trabaja a partir de los token de autenticación y no con credenciales, no es necesario contar con el nombre de usuario y la contraseña. Por lo tanto, estos datos no son almacenados y el proceso para alcanzar los recursos es mucho más ágil y seguro.
Tipos de clientes: confidenciales y públicos
En el estándar Oauth 2.0 existen varios tipos de clientes, aunque la mayor división entre ellos se da entre los confidenciales y los públicos. Dicha separación es importante porque según cada tipo de cliente se requerirá un estilo de flujo de trabajo distinto.
En el campo de clientes confidenciales ingresan todos aquellos que sí son capaces de guardar una contraseña dentro del sistema. La misma no es expuesta en ningún momento, por lo que esta información no corre riesgos. Por lo general, se trata de aplicaciones nativas compiladas que por algún motivo requieren utilizar algún recurso de la app del propietario.
Mientras tanto, los clientes públicos son aquellos que no tienen la capacidad de guardar una contraseña dentro del sistema. Sí pueden ingresar a través del flujo de trabajo de Oauth 2.0, pero no cuentan con esta posibilidad que sí está incluida para los confidenciales. Aplicaciones JavaScript y Angular son algunos de los ejemplos más comunes de este tipo de clientes.
Tipos de concesión: Grant types
Cuando se utiliza Oauth 2.0 hay un flujo de trabajo que abarca a la mayoría de los clientes que ingresan a la aplicación del propietario. Pero eso no quiere decir que no haya otros caminos y tipos de concesión dentro de este protocolo.
Algunos de los tipos de concesión que existen en este estándar son el código de autorización, el código implícito, la contraseña del propietario de los recursos, los códigos basados en dispositivos y aquellos que están basados en las credenciales de los clientes. Finalmente, también existen algunas concesiones que tienen como objetivo crear nuevas concesiones en caso de ser considerado necesario.
Qué tipo de concesión se utilizará depende del cliente que quiera ingresar a los recursos de la aplicación del propietario. En la mayoría de los casos se utilizan protocolos estandarizados, pero se puede optar por otras alternativas siempre y cuando sea considerado como un beneficio para ambas partes.
Códigos de autorización en Oauth 2.0
Cuando se brinda autorización para usar recursos de la aplicación del propietario, el tipo de otorgamiento más común en Oauth 2.0 es el código de autorización. El mismo se aplica al lado del servidor y funciona a partir de un código fuente que no está expuesto de forma pública. Por lo tanto, permanece confidencial y el cliente no puede verlo en ningún momento del proceso.
En este tipo de flujo de trabajo, se utiliza la reorientación para que la aplicación sea capaz de interactuar con el cliente o usuario al servicio. Si funciona de manera correcta, este último recibirá los códigos de autorización de la API para vincular los recursos disponibles con su propia aplicación o sitio web.
Prohibida su reproducción total o parcial.