OAuth

  • Posted on: 26 April 2017
  • By: ReYDeS

OAuth fue construido para resolver el problema de conexión para aplicaciones de terceros hacia proveedores de servicios en nuestros nombre, pero sin dar nuestras credenciales hacia el proveedor del servicio. OAuth es utilizado mucho en aplicaciones móviles y aplicaciones de escritorio, pero también es utilizado en aplicaciones. OAuth realmente no autentica usuarios, delega el acceso hacia terceros. Esta diseñado para evitar proporcionar la contraseña a terceros. Siendo frecuentemente utilizado por clientes de medios sociales para acceder hacia Twitter, Facebook, etc.

Existen tres partes en la transacción OAuth, el usuario, el consumidor, y el proveedor del servicio.

¿Cómo funciona OAuth?

“Juan” requiere utilizar un aplicación ficticia en Twitter de nombre “TweetRuta” para publicar en Twitter. Él utiliza la aplicación “TweetRuta” y le indica requiere interactué en su nombre con Twitter.

“TweetRuta” consulta a Twitter por un token de petición. Twitter devuelve un token de petición y un secreto para sea utilizado por “TweetRuta”. “TweetRuta” utiliza este secreto para registrar cada petición enviada hacia Twitter, de tal manera Twitter pueda verificar la validez de la petición, y esta no ha sido falsificada por alguien mas.

“TweetRuta” envía un token de petición hacia “Juan” indicándole lo lleve a Twitter y apruebe el acceso para “TweetRuta”. “TweetRuta” luego redirecciona a “Juan” hacia Twitter para aprobar el acceso.

“Juan” le indica a Twitter el requerimiento de aprobar el acceso para “TweetRuta”. Twitter confirma “Juan” requiere “TweetRuta” realice diversa cantidad de acciones en su nombre. Cuando “Juan” confirma la autorización para acceder a su cuenta, Twitter le indica a “Juan” la necesidad de informar a “TweetRuta” de su posibilidad de utilizar el token de petición.

“Juan le indica a “TweetRuta” el token de petición está listo.

“TweetRuta” luego consulta a Twitter para cambiar el token de petición por un token de acceso. Twitter verifica para asegurarse el token de petición ha sido autorizado por “Juan”. Si es así, Twitter devuelve un token de acceso y un secreto para “TweetRuta” lo utilice cuando publique en el Twitter de “Juan”.

“TweetRuta” envía luego una petición hacia Twitter para publicar en la cuenta de “Juan”, enviando el token de acceso y registrándose con el secreto. Twitter verifica la firma sobre el token de acceso sea valida y publica los datos solicitados en el Twitter de “Juan”.

OAuth 1.0

OAuth 1.0 depende de la integridad de una llave secreta para asegurarse el mensaje no ha sido falsificado. No hay requerimientos para encriptar el transporte, además los tokens no expiran. Así el proteger la llave secreta es la principal prioridad.

OAuth 2.0

OAuth 2.0 añade expiración de token y requiere una comunicación SSL para proteger el token. Incluso si un token es interceptado, tendría un lapso limitado de vida antes de ser automáticamente reemplazado. Sin embargo, el proceso de renovación debe ser implementado adecuadamente o la seguridad de esta versión se caerá a pedazos.

Desde la perspectiva del atacante, así como la autenticación basada en formularios, los desarrolladores son los responsables de implementar adecuadamente la seguridad con un despliegue OAuth. Malas configuraciones, implementación pobre, y fuga de información, podrían dar información valiosa en las pruebas de pentración.

Fuentes:

https://oauth.net/
https://oauth.net/2/

Sobre el Autor


Alonso Eduardo Caballero Quezada - ReYDeS
Instructor y Consultor Independiente en Ciberseguridad
Correo Electrónico: ReYDeS@gmail.com
Twitter: https://twitter.com/Alonso_ReYDeS
LinkedIn: https://pe.linkedin.com/in/alonsocaballeroquezada/
Facebook: https://www.facebook.com/alonsoreydes
Youtube: https://www.youtube.com/c/AlonsoCaballero


Curso de Informática Forense