Introducción al protocolo OAuth
¿ Autentica-qué?
Ahora que la información sensible de muchas personas se encuentra en Internet ya sea dentro de aplicaciones web o móviles y se vuelve de suma importancia tener un control absoluto de a quién y por qué se le da acceso a las mismas.
Tener un set de usuario y contraseña ya no aplica para todo el tipo de datos que se consumen y ni siquiera para la velocidad en lo que eso ocurre.
Para cubrir esa necesidad se han creado protocolos de seguridad y de autenticación, cada día más robustos, seguros y difíciles de romper.
Podemos encontrar varios ejemplos de uso de está herramienta en lugares como:
Integración del login de Facebook
Uso de APIs de Google
Integración de pagos con Paypal
y hoy toca aprender un poco más al respecto.
Definiciones:
Basado en “Oauth — The big picture” de apigee:
OAuth 1.0: En la primer versión que existió el protocolo sufrió varias modificaciones en su proceso de delegación de la autenticación.Actualmente no es tan utilizado.
OAuth 1.0a: No pertenece al estándar IETF pero es bastante estable y bien entendido. Usa un hash criptográfico para firmar cada request de la API e intercambiar las credenciales entre cliente y servidor. Esto quiere decir que se puede obtener seguridad de la API sin el uso SSL (no sólo no se intercambia información, ni siquiera se intercambia un token, todo esta encriptado en la firma). Su implementación suele ser engañosa.
OAuth 2.0: Es la evolución del protocolo, se enfoca en proveer un flujo especifico de autorización para cada plataforma sin dejar de buscar simplicidad para implementarlo. Sigue siendo un protocolo en desarrollo que ya cuenta con una versión estable y será difícil que cambie demasiado.
Ésta especificación ya cumple con la especificación el IEFT .
Roles
Vamos a encontrar 3 roles principales en la implementación de OAuth:
#1 Como lo vemos en la vida diaria
#2 Terminología general
#3 Terminología oficial del protocolo OAuth
Legs
Un termino común en el protocolo es “n-legged”. Entiéndase como leg = pierna/parte/entidad involucrada, y cada paso para lograr el proceso cuenta como un leg (pierna) involucrada.
La implementación más común es la de “2-legged”, donde el cliente y el dueño del recurso trabajan en conjunto como una pierna para el otro servicio.
Una implementación “n-legged” sucede cuando es un recurso al que tienen acceso los clientes de un cliente.
Credenciales
Para lograr ser autenticado se deben pasar por diferentes etapas de la creación de los token. Son 3 las principales credenciales con las que se va a trabajar:
#1 Terminología general.
#2 Terminología oficial del protocolo OAuth.
#3 Como se escucha en la vida real.
Todas las partes involucradas cuentan con un “Symmetric shared secret” que es utilizado para decodificar la información del token y validar la identidad e integridad del mismo.
Componentes de la firma
Sender: Usa un algoritmo matemático para calcular la firma de la petición .
Receptor: Usa el mismo flujo que quien envía para comparar y evaluar lo recibido como firma.
Hash algorithm: “Hashing” es el proceso de tomar una porción de datos y condensarla en un valor mucho mas pequeño de una manera reproducible.
Shared secret: Ambas partes comparten una porción de datos, como un string, que sólo ellos conocen y les sirve para validar el contenido de los tokens. Ayuda a prevenir que la comunicación sea interceptada o ataques en general.
Nonce: Significa ‘número que se usa una sola vez’ (number used once) y es un string random y único que ayuda a firmar los las peticiones.
Flujo
Una imagen vale más que mil palabras. A continuación se representa el flujo de una implementación de OAuth:
A primera vista se ve muy sencillo, sin embargo dependiendo del lenguaje y los propósitos de la implementación será la complejidad añadida al proceso de autenticación.
- Se han de tener al menos dos partes que participan en el proceso, un cliente y un servidor. El cliente es quien solicita permiso para acceder a la información y el servidor quien ha de decidir si puede o no hacerlo y por cuanto tiempo.
- El cliente debe conocer la dirección ( URL ) de donde se encuentran los servicios de autenticación así como los requisitos para solicitarlo. ( un client_id, una contraseña etc. ).
- El servidor reconoce está información y envía al cliente un token temporal para iniciar el proceso de autenticación.
- El cliente debe envía el token temporal de regreso al servidor junto con otra información requerida ( según el servicio ) en un request seguro (uso de SSL ).
- El servidor enviará el token definitivo al cliente para empezar a hacer uso de sus recursos. Dependiendo de la información intercambiada será el nivel de acceso que se obtiene y si es un acceso temporal o definitivo.
Todo este ir y venir de información hace que la identidad de cliente y servidor este siempre clara y definida. Esto reduce la posibilidad de que nuestra comunicación o acceso sea ‘capturado’ y usado con malas intenciones.
Hay muchas variaciones y actualizaciones de este protocolo, aquí pueden encontrar algunas fuentes interesantes de información.
Sources:
