OAUTH introducción y entretenida explicación

OAUTH

Esteban Moreno Arias

Entendiendo OAUTH

• Creado por una pequeña comunidad de desarrolladores de variados sitios y servicios web.

• Buscaban solucionar el problema de delegar el acceso a recursos protegidos.

• El resultado del protocolo fue estabilizado en la versión 1.0 en Octubre del 2007.

• En Junio del 2009 fue revisado y publicado en http://oauth.net.core/1.0a origen.

ORIGEN

Esteban Moreno Arias - @estebanzeus

http://oauth.net.core/1.0a

• La autenticación básica es un protocolo estándar definido en HTTP 1.0.

• El cliente debe autenticarse con un ID de usuario y una contraseña.

LO BÁSICO

• Si el cliente intenta ingresar a un recurso protegido, el servidor devolverá un 401:

• “No autorizado”


• Si el cliente se autentica, se genera agrega una cabecera a la solicitud llamada Authorization.

• El cliente al realizar la solicitud y estar autenticado, el servidor devuelve

LO BÁSICO

un HTTP/1.1 200 OK


Un momento, el sitio tenia mis datos personales???

LO BÁSICO

O sea ellos tendrían el

mismo control sobre mi

cuenta que yo???????


PERO, VOLVAMOS A OAUTH¿QUÉ ES?

Un protocolo abierto, que permite la autorización segura de un API, de modo estándar y simple, para aplicaciones de

escritorio, móviles, y web.


¿QUIÉN LO USA?


¿CÓMO FUNCIONA? Mi abuela va a un spa lujoso, donde tienen una

persona encargada de estacionar su automóvil


¿CÓMO FUNCIONA? En ese momento ella estaría autorizando a conducir

su auto. Pero tiene miedo de que se lleven el auto.


¿CÓMO FUNCIONA? Pero como mi abuela es inteligente

Obviamente no le darás la llave así de fácil, ella le pasará una llave especial, solo durará un tiempo y que puede desactivar cuando quiera.


¿CÓMO FUNCIONA? Y como su auto es lujoso, puede permitir que con esa

llave solo se pueda andar 5 KM a la redonda y no se pueda utilizar no la radio ni el mini bar.


¿CÓMO FUNCIONA? Mi abuela tiene todo bajo control y se va a

relajar al spa.


¿CÓMO FUNCIONA? OAuth funciona de manera similar, un

usuario da acceso a una aplicación para realizar acciones en nombre del usuario y la aplicación sólo puede realizar las acciones autorizadas.


ROLES 1 - Servidor de Recursos.

Por ejemplo Twitter es quien tiene nuestros datos, como posts, seguidores, a quienes seguimos, fotos, etc.

El servidor que aloja los datos protegidos del usuario.


ROLES 2 – Propietario de los recursos.

El usuario de aplicaciones, tiene la capacidad de otorgar acceso a sus propios datos alojados en el servidor de recursos

Es el usuario de una aplicación y el propietario de los recursos.


ROLES 3 – Cliente (aplicación).Es una aplicación que realiza solicitudes a la API, para realizar acciones en recursos protegidos, en nombre del usuario y SIEMPRE con su previa autorización.

Por ejemplo Tweetdeck, según ellos: “Es un excelente cliente para utilizar twitter de forma cómoda y darle el mejor aspecto a tu perfil de twitter “


ROLES 4 – Servidor de autorización. (Grandes APIs )

El servidor de autorización recibe el consentimiento del propietario del recurso y el acceso a recursos protegidos están alojadas en un servidor de recursos.

Los pequeños proveedores de API puede utilizar la misma aplicación y espacio de direcciones URL, para el servidor de autorización y los recursos del servidor..


¿QUÉ VEMOS AHORA?

Registrando la aplicación

Perfiles de clientes

Tokens de acceso



REGISTRANDO LA APLICACIÓN

OAuth requiere que las aplicaciones que consumirán de la API (clientes), estén registradas en el servidor de recursos (o en su caso en el servidor de autorización).

Mientras que el protocolo permite el registro a través de medios automatizados, la mayoría de los proveedores de API requieren registro manual, a través de rellenar un formulario en las páginas web de sus desarrolladores.


¿POR QUÉ ES NECESARIO REGISTRARSE?

Es la forma en que las aplicaciones obtiene las credenciales de cliente, que se utilizan para autenticar las peticiones echas al servidor de autenticación

Estas credenciales son fundamentales en la protección de la autenticidad de las solicitudes cuando se realizan operaciones delicadas tales como el intercambio de códigos de autorización para los tokens de acceso.


PERFILES DE CLIENTES1- App web del lado del servidor

Es un cliente de OAuth que se ejecuta en un servidor web. La aplicación web accede por un propietario del recurso (usuario) y la aplicación hace las llamadas adecuadas a la API, usando un lenguaje de programación del lado del servidor.

El usuario no tiene acceso al secreto del cliente o cualquier OAuth tokens de acceso emitidos por el servidor de autorización.


PERFILES DE CLIENTES2- Apps se ejecutan en un Browser del lado del cliente

Un cliente de OAuth corriendo en el navegador web de un usuario, donde el cliente tiene acceso al código de la aplicación y/o solicitudes de la API.

La aplicación puede ser distribuida como JavaScript incluido en una página web, como una extensión del navegador, o un plug-in de una tecnología como Flash, etc.

Las credenciales de OAuth no son de confianza, debe mantenerse la confidencialidad del propietario del recurso, por lo que algunos proveedores de API no emitirá secretos para clientes de aplicaciones con este perfil.


PERFILES DE CLIENTESAplicación nativa

Un cliente de OAuth, que es muy similar a la aplicación del lado del cliente, como los de Credenciales no se confía en que se mantengan confidenciales. Sin embargo, dado que se trata de una instalación aplicación, no pueden tener acceso a todas las capacidades de un navegador web.


TOKENS DE ACCESOSon un tipo de token de acceso, que la simple

tenencia de los valores simbólicos, proporciona acceso a recursos protegidos. No se necesita información adicional, como una clave criptográfica, para hacer llamadas a la API.

Después de obtener un token de acceso, este puede ser enviada junto con su solicitud de varias maneras.

El método preferido de las solicitudes de autorización es mediante el envío de la señal de acceso en un encabezado HTTP de autorización:

Authorization Oauth XxXXxXHeader Name Header Value


Hasta acá llegaremos por ahora, dependiendo de la acogida se continuara con la siguiente parte

Documents

OAUTH introducción y entretenida explicación