Entendiendo o auth
Upcoming SlideShare
Loading in...5
×
 

Entendiendo o auth

on

  • 2,682 views

Breve descripción de oAuth 1.0a

Breve descripción de oAuth 1.0a

Statistics

Views

Total Views
2,682
Views on SlideShare
2,679
Embed Views
3

Actions

Likes
0
Downloads
82
Comments
0

1 Embed 3

https://twitter.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Entendiendo o auth Entendiendo o auth Document Transcript

  • Entendiendo oAuth Una breve explicación sobre oAuth 1.0 Eduard Tomàs (@eiximenis en twitter) 4/28/2012Este documento es una breve introducción a oAuth, comentando brevemente como funcionael procolo en su versión 1.0a y mencionando los distintos flujos de oAuth existentes
  • Entendiendo OAuthContenido¿Qué es OAuth? ........................................................................................................................ 2 La necesidad de OAuth .......................................................................................................... 2Tokens, tokens, tokens.............................................................................................................. 3 Criptografía para dummies.................................................................................................... 3 Dos amigos... ..................................................................................................................... 4 ...y el novio celoso. ............................................................................................................ 5 Firmas digitales ................................................................................................................. 6 Firma de peticiones en OAuth ............................................................................................... 8 Tipo de tokens OAuth ........................................................................................................ 9 Normalización de peticiones ........................................................................................... 11 Creación de la cadena base de firma ............................................................................... 12 El método de codificación percent encoding .................................................................... 12Elementos de una petición OAuth ........................................................................................... 13 Parámetros OAuth .............................................................................................................. 13 Localización de los parámetros OAuth ................................................................................. 14 Cabecera Authorization ................................................................................................... 14Flujos de OAuth ...................................................................................................................... 15 3-legged OAuth ................................................................................................................... 15 Cliente escritorio – Autenticación por PIN ........................................................................... 16 Cliente escritorio – autenticación por password .................................................................. 17 2-legged OAuth ................................................................................................................... 17 Pseudo-autenticación con OAuth ........................................................................................ 17Desde ya hace un tiempo se oye hablar mucho de OAuth. Casi cualquier red social o aplicaciónweb que exponga una API pública para desarrolladores expone sus servicios usando esteprotocolo. ¿Quieres integrarte con Twitter, Linkedin, Facebook o Google+, entre muchasotras? Todas ellas requieren usar OAuth para poder utilizar sus servicios.El objetivo de este documento no es que puedas aprender a crear un cliente que use OAuth,para ello no hay mejores tutoriales que los propios que desarrollan los creadores de servicios(créeme: ellos son los primeros interesados en que uses sus servicios). Tampoco es objetivo deeste documento explicar todos los pormenores de OAuth (para ello hay una especificación
  • oficial). Entonces... ¿cuál es el objetivo? Pues simple y llanamente: que entiendas OAuth. Queentiendas qué es OAuth, cuál es su motivación, que problemas permite solucionar y que otrospuede llegar a plantear. Por supuesto vamos a entrar en detalles sobre el funcionamiento deOAuth, aunque para descripciones detalladas referenciaremos a la RFC. Y sí, también veremoscómo crear un cliente OAuth y por encima de todo un proveedor de OAuth y cómo integrarloen nuestras aplicaciones web usando, en este caso, ASP.NET MVC.Si te interesa el tema, y quieres conocer OAuth en lugar de simplemente usarlo... estedocumento es para ti.¿Qué es OAuth?Resumiendo, OAuth es un protocolo de autorización (su nombre proviene de OpenAuthorization), que permite a un usuario (propietario de ciertos recursos) autorizar a untercero a que acceda a dichos recursos en su nombre pero sin darle en ningún momento a estetercero sus credenciales de autenticación (es decir, sin darle a este tercero su nombre deusuario ni contraseña).Actualmente está en su versión 1.0a y se está desarrollando la versión 2.0 que va a serincompatible con la versión anterior. Dicha versión 2.0 debería haberse finalizado a finales del2011, pero sigue estando todavía en desarrollo y sin fecha prevista de finalización. La principalmejoras de OAuth 2.0 respecto a 1.0a son que es más fácil de usar para el usuario. Estedocumento se basa en OAuth 1.0.Aun cuando OAuth es un protocolo de autorización es posible conseguir una pseudoautenticación con él, y de hecho uno de usos más extendidos es el de entrar en una aplicaciónweb usando el usuario y contraseña de otra aplicación. De esta manera grandes proveedoresde OAuth, como Facebook, se convierten a su vez en proveedores de autenticación de otraswebs. Así, paradójicamente, OAuth está teniendo éxito donde otros protocolos más orientadosa autenticación como OpenID o anteriormente Passport (actual Live ID) no han terminado detenerlo. Esto nos demuestra una vez más, que el éxito de un producto (un protocolo en estecaso) viene muchas veces marcado por quien lo adopta, y el momento en que lo adopta, másque en las características técnicas de éste. Esta es una lección que solemos olvidar demasiadoa menudo.La necesidad de OAuthLa necesidad de un protocolo de autorización como es OAuth suele ser la confianza. O mejordicho, la falta de ella. El hecho de que yo como usuario no confíe en una aplicación losuficiente como para darle mis datos de autenticación pero por otro lado quiera permitir quedicha aplicación realice algo en mi nombre. Y no es lo mismo realizar algo en el nombre dealguien, que suplantar a este alguien. Esto es precisamente lo que permite OAuth: que alguienrealice tareas en nombre de otro, pero sin poder suplantarlo: en todo momento se sabe quiénes realmente el que está realizando las tareas. Al tener la autorización separada de laautenticación, yo puedo en cualquier momento desautorizar a quien yo haya autorizadopreviamente. Es decir, impedir que siga realizando tareas en mi nombre. Y puedo hacer estosin necesidad de modificar mi usuario o contraseña.
  • Y desde el punto de un proveedor de servicios... ¿Qué le ofrece OAuth que motive el usarlo?Pues precisamente el hecho de querer generar un ecosistema de terceros que usen susservicios. Pongamos como ejemplo a Facebook. Facebook no expone su API para su propiaaplicación móvil, la expone básicamente para permitir todo un desarrollo de un ecosistema deaplicaciones integradas en Facebook, pero realizadas por otros. Es una relación win-win entreFacebook y el creador de la aplicación. El segundo puede aprovechar todo el potencial socialque Facebook puede generar, y el primero obtiene más interacciones que es lo que másnecesita una red social. Por supuesto que todo esto se podría conseguir sin OAuth, pero enunos tiempos donde se están mandando tantos (acertados) mensajes contra el phising ycontinuamente se nos dice que vigilemos nuestras credenciales y que no nos fiemos, noquedaría muy bien que cualquier web o aplicación nos pidiese el usuario y contraseña deFacebook... ¿Qué hará con ellos? ¿Cómo tengo yo la seguridad, como usuario, de que laaplicación es bienintencionada? Además, incluso en el caso de que la aplicación fuesebienintencionada, el que todas mis aplicaciones conectadas a Facebook tengan mi usuario ycontraseña implica que si alguna vez, por cualquier razón, los modifico deba informar a todasesas aplicaciones de nuevo. Como veremos más adelante OAuth me permite obviar todo esto.Así pues, OAuth expone claras ventajas tanto para usuarios como para desarrolladores deservicios. Ha llegado el momento de ver, someramente, como funciona.Tokens, tokens, tokensLa verdad es que OAuth va, básicamente, sobre intercambiar tokens. Hay tres roles quedebemos considerar:  El cliente, que quiere acceder a un servicio en nombre de un usuario. Este cliente puede ser una aplicación web, móvil o de escritorio.  El proveedor de servicios, que provee el servicio al cual quiere acceder el cliente  El autenticador que autentica los usuariosLo que OAuth define es como esos tres roles deben comunicarse entre ellos para que al final elcliente pueda acceder al servicio. Lo que no define OAuth es como el autenticador realiza sutrabajo (es decir, como se autentica el usuario).El objetivo final es que el cliente consiga lo que desde siempre se ha llamado Access token(aunque en la RFC decidieron modificar todos los nombres y lo llamaron Token Credentials).Enviando este token el cliente puede acceder a un recurso protegido en nombre del usuarioque haya autenticado el autenticador.Criptografía para dummiesAntes de meternos de lleno en OAuth, dado que vamos a hablar de firma digital y métodoscriptográficos de clave simétrica o asimétrica déjame que te hable un poco sobre conceptoselementales de criptografía. Si conoces que son los métodos de clave simétrica, asimétrica y lafirma digital, eres libre de saltarte este apartado :) Y por supuesto, si encuentras todo el temade la criptografía aburrido y falto de interés te lo puedes saltar también, en el fondo no esnecesario conocerlo para poder usar OAuth... Aunque sí para entenderlo realmente, y como deeso se trata, si te apetece… ¡allá vamos!
  • Dos amigos...Imaginemos a dos amigos, Alice y Bob que quieren enviarse un mensaje codificado sin quenadie más pueda descifrarlo. Hay muchos mecanismos de encriptación que pueden utilizar,pero los podemos dividir en dos grupos: de clave simétrica y de clave asimétrica.Los de clave simétrica son los primeros que nos vienen a la cabeza cuando pensamos enmecanismos de codificación. Tenemos una función (f) que dada una clave (K) y un texto acodificar (t) devuelve el texto codificado (t’). Entonces se cumple que:  ( , )=  ( , )=Es decir, para cifrar y descifrar se usa la misma clave.Ahora supongamos que Alice y Bob quieren mantener una conversación privada y para ellodeciden cifrarla. Lo primero que tienen que hacer es quedar de acuerdo en la clave a usar.Bastaría con un correo de Alice proponiendo la clave y uno de Bob aceptándola. A partir deeste punto ambos usan la misma clave y la conversación puede tener lugar.Si has arrugado la nariz cuando he mencionado que Alice envíe un correo con la clave es quehas visto el punto débil de los métodos de clave simétrica: el intercambio de la clave. Es unpunto muy delicado, ya que si alguien (un tal Mallory que os presentaré luego) descubre laclave, toda la conversación entre Alice y Bob está comprometida.Es aquí donde entran en juego los mecanismos de clave asimétrica.Dichos mecanismos se basan en algo muy simple (pero a la vez muy potente): la capacidad degenerar dos pares de claves, ligadas de algún modo entre sí, de forma que al codificar algo conuna de las claves se pueda decodificar con la otra y viceversa. Así pues si tenemos un par declaves, llamémoslas A y B, un texto (t) a codificar y una función (f) que dado una clave y untexto devuelve un texto codificado, se cumple que:  , ( , ) = , ( , ) =Y no sólo eso, si no que la relación NO es reflexiva:  , ( , ) <>  , ( , ) <>Cada uno de ellos por separado y sin comunicárselo a nadie genera un par de claves (A,B). Eneste momento Alice tiene su par de claves y Bob las suyas. Posteriormente ambos se envíanpor mail una sola de esas claves (pongamos la A), a la que llamaremos la clave pública. La otraclave del par de claves, se la guardan para ellos mismos y no la dicen a nadie así que lallamaremos la clave privada. De hecho, cualquiera que más adelante quisiera enviar mensajesa Bob, como su amigo del instituto Charlie, debe pedirle a Bob que le dé la clave pública. Tansolo esa.En este momento, Bob pondría enviar un mensaje a Alice, encriptado con la clave pública deella. El resultado es un mensaje que solo puede decodificar quien posea la otra clave del parde claves. Y dado que Bob ha usado la clave pública de Alice, quien posee la otra clave del parde claves es la propia Alice: se trata de su clave privada. De este modo Bob ha conseguido
  • enviar un mensaje que solo Alice puede entender. ¿Y si ahora Alice quiere responder elmensaje? Pues muy simple: tan solo debe cifrarlo usando la clave pública de Bob, para queeste al recibirlo use su clave privada y pueda descifrarlo.Resumiendo, la idea es muy simple: se cifra el mensaje con la clave pública del receptor, el cualdebe usar su clave privada (que solo conoce él) para descifrarlo.Este sistema asegura cifrado y descifrado seguro de los mensajes (tan seguro como sea elalgoritmo de encriptación que se use, pero eso es otra historia). Pero existe un riesgo quedebemos tener presente....y el novio celoso.¿Recordáis que antes mencionamos a Mallory? Dejadme que os lo presente: es el novio deAlice. Aunque es un buen tipo, es extremadamente celoso y como cree que Bob tieneintenciones poco honestas con Alice hace tiempo que está espiando lo que ella hace. En elfondo Mallory no le tiene manía a Bob: cree que todo el mundo quiere algo con Alice más alláde la amistad.A priori puede parecer que el mecanismo de encriptación basado en clave asimétrica lesprotege del todo: la única clave que circula al principio de la conversación entre Alice y Bob esla clave pública de cada uno de ellos que solo sirve para cifrar, nunca para descifrar, así queaunque Mallory supiese la clave pública no podría hacer nada (a diferencia de un mecanismode clave simétrica, ya que en este caso si Mallory descubre la clave puede descifrar toda laconversación). En efecto, es cierto que si Mallory tan solo conoce las claves públicas de ambosno puede comprometer la seguridad de la comunicación de los dos amigos... Pero esta certezano es garantía de una seguridad absoluta.Y es que Mallory instaló un proxy conectado a su propio ordenador que le permite teneracceso e interceptar todo lo que su novia envía y recibe desde internet (sí, los celos son muymalos). Gracias a esto Mallory intercepta el correo en el que Alice le pedía a Bob su clavepública y deja que llegue a Bob. Bob recibe el mensaje que proviene de Alice y le contesta consu clave pública. Dicho mensaje es interceptado de nuevo por Mallory, quien cambia la clavepública de Bob por la suya, se guarda la clave pública de Bob y reenvía el mensaje a Alice. Eneste punto Alice cree tener la clave pública de Bob, pero realmente tiene la de su novio.Así cuando Alice quiere decirle algo a Bob, lo encripta con la clave pública de este... o con loque ella cree que es la clave pública de Bob. Porque realmente es la de Mallory, el cual puededescifrarlo (usando su clave privada), modificarlo, cifrarlo de nuevo (usando la clave pública deBob que se ha guardado antes) y reenviar el mensaje a Bob, quien creerá que el mensajeproviene de Alice.Este tipo de ataques, en el cual un tercero (Mallory) puede interceptar, leer y modificarmensajes que se envían un par de actores (Alice y Bob) sin que ninguno de ellos pueda saberque su seguridad ha sido comprometida se llaman ataques Man-in-the-Middle.El error de Bob y Alice ha sido permitir que Mallory interceptara un único mensaje: el queusaron para intercambiar sus claves. Este es el punto débil de todo sistema de criptografía: elintercambio de claves (sí, incluso en los asimétricos donde podríamos creer que evitaban esteproblema).
  • Amigo lector, por si lo has pensado, una solución muy rápida que evitaría los trapicheos deMallory, sería evitar que hubiese intercambio de claves públicas al inicio de la conversaciónentre Bob y Alice. Si ambos publicasen su clave pública en una web, a la vista del todo elmundo, Mallory no podría interceptar ningún mensaje y sustituir las claves porque estemensaje no existiría: cuando Alice quisiera ver la clave pública de Bob la miraría en esta web yviceversa. Claro que en este caso tanto Alice como Bob deben tener estar seguros de que laweb donde publican sus claves públicas es de confianza. No vaya a ser que le encarguen hacerla web a Chuck, un antiguo compañero de fiestas de Mallory, con lo que estarían igual queantes. Pero si la web es de una empresa que ofrece este servicio (hospedar claves públicas), yque ofrece absolutas garantías de seguridad, entonces sí que Mallory no tiene nada que hacery Alice y Bob pueden estar tranquilos... Y aunque pueda parecer muy tonto, esto de publicarlas claves públicas de todos en un sitio común, es más o menos lo que hacemos actualmentecon los certificados digitales y las infrastructuras de clave pública (PKI).Firmas digitalesSi has entendido como funciona la encriptación, ya estás listo para comprender como funcionala firma digital. El concepto de firma digital es extremadamente sencillo: se trata de aplicar unafunción de hash al documento y cifrar tan solo el hash. El hash cifrado constituye la firmadigital.Funciones de hashSi Bob quiere enviar un documento firmado digitalmente, debe calcular el hash de estedocumento. El hash no es más que aplicar una función que devuelva un valor resumen quedependa de los datos del documento. Lo de resumen viene porque generalmente el tamañoen bytes del documento suele ser superior al tamaño en bytes del hash.Así una posible función de hash sería sumar los códigos ASCII de todos los caracteres deldocumento y realizar el módulo 256. Con esto obtendríamos un número de 0 a 255. Fijaos queconvertimos textos de cualquier número de byes a valores de un solo byte, de ahí lo deresumen. Dada esa función de hash, el hash del texto Hola seria 132.Por supuesto esta es una función de hash horrorosa, seguro que no te cuesta nada encontrarotro texto distinto que dé el mismo valor de hash. Es evidente que, por norma general,siempre habrá más documentos que hash posibles (en nuestro caso hay infinitos documentosposibles y tan solo 256 hash), por lo que habrá colisiones (es decir dos documentos distintosque generen el mismo hash). Lo que distingue una buena función de hash de una de mala es loque cueste encontrar dos documentos distintos que generen un mismo hash (lo que encriptografía se conoce como resistencia a las colisiones y que mide cuan resistente es unafunción de hash frente a lo que se conoce como un ataque de cumpleaños).Suponiendo una función de hash con alta resistencia a las colisiones (es decir que sea inviableencontrar dos elementos que den el mismo hash) entonces Bob puede firmar un documentode la siguiente manera: 1. Calcula el hash del documento 2. Cifra el hash y obtiene la firma digital. 3. Envía el documento junto con la firma digital.
  • Lo importante aquí es que el documento no tiene por qué estar encriptado (puede estarlo perono es obligatorio). Lo que está cifrado usando la clave privada de Bob es el hash y esoconstituye la firma digital. Cuando el receptor reciba el documento debe: 1. Descifrar la firma digital para obtener el hash 2. Calcular por su parte el hash del documento (usando la misma función de hash) 3. Comparar ambos valores (el hash descifrado y el hash calculado)Si ambos valores coinciden la firma digital del documento es válida… ¿y qué significaexactamente esto? Pues depende del mecanismo de cifrado que se use para cifrar el hash.Firmas con mecanismos asimétricos vs firmas con mecanismos simétricosA grandes rasgos: una firma digital correcta indica que el documento no ha sido modificadopor nadie a excepción de un remitente válido y que ha sido enviado por un remitente válido. Loque significa exactamente “remitente válido” varía en función de si para cifrar el hash se usóun mecanismo con claves simétricas o asimétricas.Si se ha usado un mecanismo con claves asimétricas, remitente válido es aquel que ha enviadoel documento. Nadie más. Debe notarse que decimos aquel que ha enviado el documento, noaquel que legítimamente puede leerlo. Si en el ejemplo anterior Bob hubiese usado unmecanismo de cifrado asimétrico podemos afirmar que el documento no ha sido alterado (loque se ha recibido es lo que se ha enviado) por nadie más. No solo eso, si no que además sepuede asegurar que ha sido Bob quien lo ha enviado (o dicho a la inversa, Bob no puede negarhaber enviado el documento, lo que se conoce como no repudio). Si alguien intercepta eldocumento y lo modifica, dado que no puede modificar la firma digital (ya que está cifrada conla clave privada de Bob que tan solo tiene él), cuando el receptor reciba el mensaje el hash queél calcule diferirá del que venía con el documento, con lo que se sabrá que ha sidointerceptado y modificado.Si se ha usado un mecanismo de clave pública, entonces “remitente válido” significa cualquieraque conozca la clave. Es decir cualquiera que pueda recibir un mensaje y calcular la firmadigital. Si Bob calcula su firma digital cifrando el hash con un mecanismo de clave simétrica, esevidente que Alice debe conocer la clave para poder descifrar el hash y compararlo con el queobtenga ella para validar la firma digital. Pero dado que la clave que se usa para descifrar es lamisma para cifrar y que Alice también la tiene, nada impide que Alice modifique el documento,vuelva a calcular el hash y lo cifre de nuevo usando la misma clave. En este caso no podemospues asegurar unívocamente como antes que lo ha enviado Bob. Puede haberlo enviado Alice.No hay manera de saberlo. La firma digital sigue asegurando, eso sí, que si el mensaje esmodificado por alguien que no conoce la clave de cifrado, el resto de participantes que sí latienen se darán cuenta de que el mensaje ha sido modificado. Digamos que, usando unmecanismo cifrado de clave simétrica, todos los participantes válidos son tratados como unamisma persona.Seguridad de la firma digitalFíjate que la asunción principal que se realiza de la firma digital (se puede asegurar que eldocumento no ha sido modificado), depende directamente de que la función de hash tengauna alta resistencia a las colisiones. De hecho lo que debe evitarse es que sea factible paraalguien generar un par de documentos (uno auténtico y otro fraudulento) que tengan el
  • mismo hash1. Si eso es factible (a nivel computacional) de realizar, alguien, llamémosla Carol,podría presentar el documento auténtico a Bob, quien lo firmaría y luego podría añadir lafirma digital de Bob al documento fraudulento, con lo que a todos los efectos sería como siBob hubiese firmado dicho documento falso.El propósito de la firma digital no es evitar que alguien intercepte el mensaje, si no asegurarque éste no ha sido alterado en tránsito y que es enviado realmente por el remitente. Si sequiere evitar que el mensaje sea visible a terceros, este debe además cifrarse. Eso sí, quequede claro: La firma digital no evita que pueda existir un Man-in-the-middle si el intercambiode claves ha sido comprometido.OAuth permite usar tanto mecanismos de clave simétrica como mecanismos de clave simétricapara cifrar el hash y obtener la firma digital. A la práctica la mayoría de proveedores soportantan solo un mecanismo de clave simétrico (HMAC) para evitar todo el proceso de negociaciónde claves públicas. Aunque es un poco menos seguro (cualquiera que robe la clave que se usepara cifrar los mensajes podrá enviar mensajes OAuth válidos) evita todo el trasiego deintercambio de claves públicas.Firma de peticiones en OAuthEn OAuth todas las peticiones que realiza el cliente van firmadas digitalmente. Laespecificación habla explícitamente de tres métodos de firmado: 1. HMAC-SHA1: Que es un método de firma electrónica basado en la función de hash SHA1 y el método de cifrado simétrico HMAC 2. RSA-SHA1: Que es un método de firma electrónica basado en la función de hash SHA1 y el método de cifrado asimétrico RSA. La especificación no dice nada sobre como el cliente y el proveedor de servicios intercambian sus claves públicas. 3. PLAINTEXT: No existe firma digital. El valor de la firma digital se sustituye por el valor de los tokens secretos (Consumer Secret, Request Secret y Access Secre) que se usen en cada momento. Este método es altamente inseguro y de hecho la propia especificación ya indica que debe usarse sobre un canal de comunicación seguro (SSL o TLS) y tiene su razón de existir en que si se usa uno de esos canales, no es necesario añadir un método adicional como la firma electrónica para garantizar que la petición no ha sido modificada, dado que el propio canal seguro te lo asegura.Honestamente, en la especificación no queda muy claro si debe darse soporte a esos tresmétodos o bien puede darse soporte a solo algunos de ellos. Lo que sí dice es que puedenañadirse métodos adicionales. En la vida real, hay muchos proveedores de OAuth que nosoportan RSA-SHA1 supongo que para evitar el problema de intercambio de claves públicas,algo que se evita en HMAC-SHA1 al ser este un método asimétrico donde hay una sola clavecompartida y conocida por todos. Personalmente creo que implementar solo HMAC-SHA1 esuna solución más que válida-1 Esto es importante: no es peligroso que varios documentos tengan el mismo hash (esto es inevitable,de hecho). Lo que es peligroso es que sea factible computacionalmente para alguien generar pares dedocumentos con el mismo hash.
  • La necesidad de que en OAuth cada petición vaya firmada es, evidentemente, por seguridad: sino fuese así, alguien podría interceptar la petición del cliente al proveedor de servicios,modificarla y reenviarla de nuevo. Precisamente para evitar esto y asegurar que el proveedorde servicios solo responde a peticiones legítimamente enviadas por un cliente, estas deben irfirmadas. Esto no evita que alguien pueda ver los datos que se envían entre cliente yproveedor pero sí evita que puedan ser modificados.Es importante destacar que la respuesta del proveedor de servicios no va firmada (esto es asídebido a la naturaleza síncrona de http): tan solo se firman las peticiones del cliente. Exacto:alguien con un sniffer podría modificar las respuestas del proveedor de servicios y el cliente nose daría cuenta, pero para evitar este escenario ya hay otras alternativas de seguridadadicionales a OAuth (SSL o TLS sin ir más lejos). Este no es un escenario que intente resolverOAuth. Quede claro pues que OAuth no es un protocolo de seguridad, ni quiere, ni puede,garantizar la seguridad o integridad de los datos enviados o recibidos.Cuando empieces a leer sobre OAuth, verás que continuamente se habla de pares de tokens:el token público y el secreto (key y secret en inglés). No te confundas: esos pares de tokens,¡no son pares de claves asimétricas! Realmente uno de ellos (el público) actúa comoidentificador y el otro (el secreto) es el que se usa para firmar digitalmente.Tipo de tokens OAuthConsumer Key y Consumer SecretPor lo tanto todo cliente que quiera usar OAuth deberá tener su par de tokens. Quien otorgaestos tokens y como estas son transferidas al cliente está fuera de la especificación de OAuth.Es decir, OAuth no define ningún mecanismo para que el cliente obtenga su par de tokens.Simplemente se asume que las tiene, y que ambos tanto cliente como proveedor de servicioslas conocen.En terminología OAuth llamamos Consumer Key al token que identifica un cliente y ConsumerSecret al token privado que este cliente usará para firmar sus peticiones OAuth. Aunque desdesiempre se han llamado así, en la RFC decidieron modificar el nombre y llamarlos ClientCredentials (credenciales de cliente) nombre que realmente es más acertado.La especificación no dice nada acerca de como el cliente obtiene sus credenciales, pero en lapráctica lo más normal es tener que registrar el cliente manualmente, en el proveedor deservicios.
  • Ilustración 1: Registro de una aplicación cliente en TwitterLa Ilustración 1 muestra el proceso de registro de un cliente en Twitter. Una vez registrado elcliente Twitter nos informará de nuestras credenciales de cliente, que son las que deberemosusar. Este método es sencillo y eficaz aunque obliga a registrar cada posible cliente de formamanual. Tanto Facebook, como LinkedIn como cualquiera de los proveedores de OAuthofrecen un mecanismo similar para el registro de clientes.Request Token y Request SecretEl objetivo final de OAuth es permitir acceder a recursos protegidos en nombre de un usuarioen concreto. Para ello, el cliente debe a partir de sus credenciales de cliente, obtener unostokens finales que representen que el usuario ha dado permisos para acceder a esos recursos.Para ello el primer paso es obtener un par de tokens temporales, que servirán para irenlazando toda la serie de peticiones OAuth que son necesarias para obtener los tokensdefinitivas (mucha gente se refiere a esa serie de peticiones con el nombre de OAuth Tokensdance).
  • El Request Token identifica a una petición de permisos para un usuario en concreto. Cuando elcliente quiere obtener un token de acceso definitivo, lo que obtiene primero es el RequestToken. Luego manda este Request Token al autenticador, quien (si el usuario acepta lospermisos) le devuelve un código de verificación que luego el cliente puede usar para obtenerlos tokens finales (no te preocupes si eso te parece muy lioso ahora, luego aclararemoscompletamente el flujo OAuth). Lo importante es que te quedes con la idea de que el RequestToken y el Request Secret son tokens temporales, que son descartados una vez se obtienen losdefinitivos.A lo mejor te estás preguntando por que es necesario un Request Secret. ¿No se supone quelas peticiones van firmadas usando el Consumer Secret como clave para generar la firmadigital? La respuesta es que una vez tenemos Request Token, las peticiones OAuth quehagamos irán firmadas usando el Consumer Secret y el Request Secret (ambos a la vez).¡Ah sí! Se me olvidaba: He usado los nombres Request Token y Request Secret que son los quese usan comúnmente, pero la RFC usa otros nombres que son (de nuevo) mucho másacertados: Temporary Credentials.Access Token y Access SecretEl Access Token y el Access Secret (llamados en la RFC Token Credentials) son el objetivo final:los tokens que se obtienen una vez el usuario se ha validado y ha aceptado los permisosdemandados por el cliente. Una vez el cliente obtiene esos tokens, el flujo de OAuth termina yel cliente puede empezar a realizar llamadas al proveedor de servicios en nombre del usuario.El Access Secret se usa para firmar todas las peticiones OAuth que haga el cliente una veztenga el Access Token (se usa conjuntamente con el Consumer Secret).Ahora que ya conoces los tres pares de tokens de OAuth... viene la pregunta clave: ¿qué datosde la petición se firman?Normalización de peticionesLa firma digital de un documento (en nuestro caso de una petición http) depende de los datosque esta contenga. Debemos preguntarnos pues ¿qué define a una petición http?El primer elemento es la URL, dos peticiones serán distintas si su URL es distinta. Eso significaque peticiones que solo difieren en la URL (incluso si van a URLs sinónimas como pueden serhttp://www.krasis.com y http://217.130.23.249) van a generar firmas digitales distintas.Otro elemento son los parámetros de la petición. HTTP permite que las peticiones llevenparámetros en varios sitios (query string, cuerpo, headers varios), así que OAuth define cualesson los posibles orígenes de los parámetros. En concreto se tomarán: 1. Los parámetros de la query string 2. Los parámetros en el cuerpo de la petición si esta viene como application/x-www- form-urlencoded 3. El valor del header Authorization, si este define que es de tipo OAuth, excluyendo el valor de realm si lo hubiese.
  • Nos queda un tercer elemento. Podemos tener dos peticiones exactamente con la misma URL,con los mismos parámetros (en el mismo orden y situación si se quiere) pero que sean dospeticiones distintas si usan un verbo http distinto.Esos tres elementos se combinan en una cadena, que es la que se llama cadena base de firma(signature base string) y será esta cadena la que se firme digitalmente. Así pues la cadena basede firma incluye todo lo que es relevante de una petición http: su verbo, su URL y susparámetros.El proceso de conseguir la cadena base de firma a partir de una petición de http se conocecomo normalización de peticiones. Y es que, como veremos ahora, peticiones distintas, peroque signifiquen lo mismo, van a generar la misma cadena base de firma. ¿A que me refiero conpeticiones no idénticas pero que signifiquen lo mismo? Pues que tengan los mismosparámetros pero en orden distinto, o que la URL sea igual pero difiera en mayúsculas ominúsculas.Creación de la cadena base de firmaPara obtener esta cadena a partir de una petición http, debemos realizar unos pasos sencillos,pero de vital importancia (si nos equivocamos en esto, nuestra cadena base diferirá de la quecalcule el proveedor de servicios y por lo tanto la firma digital será distinta, generando unapetición inválida): 1. Obtener el verbo http usado, en mayúsculas (p.ej. POST o GET). 2. Obtener la URL normalizada. Esto significa que la URL se pasa toda a minúsculas. El valor del host y del port debe coincidir con el valor de la cabecera “Host”. La ruta hasta la query string se añade tal cual. El puerto se incluye solo si no es el estándar (80 para http o 443 para https). 3. Obtener una cadena con todos los parámetros de la petición. Para ello con independencia de donde estén (query string, cuerpo de la petición o cabecera Authorization) se ordenan por orden alfabético y se concatenan uno tras otro (nombre=valor). Si dos parámetros tienen el mismo nombre, se ordenan por su valor. Si un parámetro está vacío, aparece igualmente sin valor. 4. Se codifica la URL normalizada, siguiendo un procedimiento propio, llamado percent encoding. 5. Se codifica la cadena con todos los parámetros de la URL, siguiendo el mismo procedimiento anterior 6. Se crea una cadena con el valor de 1, el símbolo &, el valor de 4, el símbolo & y el valor de 5.Esta cadena obtenida en el punto 6 es la cadena base de firma, y de la cual se calculará el hashpara obtener la firma digital de la petición.El método de codificación percent encodingEste método se usa solo para el cálculo de la cadena base de firma. Es un método muyparecido y basado en el método de codificación de URIs (definido por la RFC 3986 en suapartado 2.1). La RFC de OAuth 1.0, en su sección 3.6 define claramente como es estacodificación: 1. Se codifica la cadena en UTF8
  • 2. Los siguientes caracteres: letras, números, “-“,”.”,”_” y “~” no son codificados y se ponen tal cual. 3. Cualquier otro carácter debe ser codificado usando %xx, donde xx es el código hexadecimal, en mayúsculas, del byte.Aunque el método parece idéntico al definido por el RFC 3986 en su apartado 2.1 no lo es. Hayuna sutil diferencia: en OAuth se codifican todos los caracteres excepto los indicados en elpunto 2. Mientras que en el RFC 3986 algunos caracteres no se codifican si actúan comoseparadores. Es un detalle importante. P.ej. la URL http://www.krasis.com codificada según laRFC 3986 es: http://www.krasis.com, mientras que usando el percent encoding de OAuth, loscaracteres “:” y “/” se codifican igualmente, aun cuando forman parte del separador :// quesepara protocolo de host. Así pues la URL queda como http%3ª%2F%2Fkrasis.comAsí pues cuidado con usar métodos que codifiquen URLs, incluso aunque sean conformes alRFC 3986, ya que puede ser que no generen exactamente la misma cadena.Elementos de una petición OAuthToda petición que llamemos petición OAuth deberá contener algunos elementos obligatoriosque son los parámetros OAuth y la firma digital. No todos los parámetros son obligatorios entodo momento.El protocolo define un conjunto de elementos que toda petición OAuth debe tener, y quesirven para garantizar el buen funcionamiento de éste. Los que deben existir en toda peticiónOAuth son: 1. El identificador del cliente (Consumer Key). 2. Un timestamp: Usualmente el número de segundos desde el 01 de Enero de 1970. 3. Un número único (nonce) 4. El método de firma digital usado 5. La firma digitalLuego, en algunas peticiones OAuth puede existir: 6. El identificador temporal (Request Token) 7. El identificador de acceso (OAuth Token)De todos estos elementos el punto 3 merece especial atención, por lo ambiguo de sudefinición. Realmente la especificación no dice mucho acerca de él, salvo que no tiene niporque ser un número y que su uso está recomendado para poder discernir entre dospeticiones distintas dado un mismo timestamp. O sea que dos peticiones con el mismotimestamp y del mismo cliente, deben tener un valor de nonce. La especificación no dice sideben ser secuenciales o no, ¡de hecho ya hemos comentado que no tiene ni porque ser unnúmero! Cada proveedor puede establecer sus reglas y los clientes deben adaptarse a ellas. Dehecho su uso no es obligatorio, depende de cada proveedor de servicios.Parámetros OAuthEl nombre de los distintos parámetros OAuth está definido por el protocolo y son lossiguientes:
  • 1. oauth_consumer_key: Identificador del cliente (Consumer Key) 2. oauth_timestamp: Timestamp de la petición 3. oauth_nonce: Valor del número único 4. oauth_signature_method: Contiene el tipo de método de firma digital que se usa. 5. oauth_signature: Contiene la firma digital de la petición 6. oauth_token: Contiene o bien el Request Token o bien el Access Token (en función del paso del flujo en el que nos encontremos).Adicionalmente a estos parámetros existen otros que se usan en momentos puntuales y queson los siguientes: 7. oauth_callback: URL que debe llamar el autenticador con el código de verificación en el flujo 3-legged OAuth. 8. oauth_token_secret: Credencial temporal privada / Access token privado (en función del paso del flujo en el que estemos) que nos devuelve el proveedor de servicios. 9. oauth_verifier: Código de verificación que devuelve el autenticadorAl margen de esos se pueden definer parámetros adicionales y esos pueden empezar poroauth_ si así se desea (la especificación no lo prohíbe).Localización de los parámetros OAuthEstos elementos se pueden incluir en distintas partes de la petición: 1. En el querystring 2. En el cuerpo de la petición (si el content type es application/form-www-urlencoded) 3. En la cabecera Authorization, si esa indica que contiene datos OAuth. Esa es la manera recomendada por la especificación.La especificación señala que un proveedor OAuth debe soportar los parámetros OAuth encualquier de esas partes de la petición y que debe vigilar que no haya elementos duplicados(p.ej. un parámetro oauth_nonce en query string y otro en la cabecera Authorization). Si seencuentran elementos duplicados debe devolverse un error, en lugar de usar uno de los dos enfunción de cualquier posible criterio de prioridad.Cabecera AuthorizationComo se ha mencionado, la manera preferida es en la cabecera Authorization, según muestraeste ejemplo sacado de la propia RFC:Authorization: OAuth realm="Photos",oauth_consumer_key="dpf43f3p2l4k3l03",oauth_signature_method="HMAC-SHA1", oauth_timestamp="137131200",oauth_nonce="wIjqoS",oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"La cabecera Authorization debe indicar que es de tipo OAuth y el parámetro realm de aparecerse ignora a efectos de OAuth.
  • Como se puede ver el formato es nombre=”valor” (el valor está entrecomillado). Si unparámetro tiene un valor vacío debe aparecer nombre=”” (dos comillas dobles seguidas).Estríctamente hablando entre el nombre del parámetro y el signo de igual no se admitenespacios. Al igual que entre el signo de igual y la primera de las dos comillas dobles. Losparámetros van separados por una coma y un salto de línea opcional. Lo que es importante esque el valor del parámetro está codificado usando Percent Encoding (ver el valor delparámetro oauth_callback para un ejemplo).En la RFC (apartado 3.5.1) se especifica con todo lujo de detalles el formato de la cabeceraAuthorization.Flujos de OAuthVamos a explorar los diversos flujos de OAuth que existen. La especificación en sí define unsolo flujo, el conocido como 3-legged OAuth, pero vamos a explorar algunos flujos más que sepueden encontrar en distintos proveedores (como linkedin o twitter). Dos de ellos estánpensados para aplicaciones de escritorio (o móviles) otro es para el caso de que queramosejecutar servicios pero en nombre de ningún usuario en concreto y finalmente hablaremossobre la pseudo-autenticación usando OAuth (el famoso “sign with Facebook” que se ve ennumerosas web).Esos flujos se diferencian tan solo por la forma en que el cliente (ya sea otra web o unaaplicación de escritorio) consigue los tokens OAuth definitivos). Empecemos por el flujodefinido por la propia especificación3-legged OAuthEste es el flujo más conocido de OAuth y por el cual realmente fue creado. En este caso seasume que el cliente es capaz de tener un endpoint accesible para que el autenticador lepueda enviar el código de verificación. Evidentemente esto solo es posible si el cliente es unaaplicación web. Pero vayamos paso a paso...El primer paso es que el cliente realice una petición OAuth para pedir un par de tokenstemporales. Esos tokens temporales (conocidos comúnmente como request token and secret)son los que usarán en todo el flujo hasta terminar obteniendo los tokens definitivos (conocidoscomo access token and secret). Para obtener estos tokens el cliente básicamente se identificaa si mismo (usando su consumer key) y envía un parámetro llamado oauth_callback que es adonde debe recibir el código de validación que le servirá para obtener los tokens definitivos.El proveedor de servicios responde a dicha petición con los tokens temporales contenidos enlos parámetros oauth_token y oauth_token_secret. ¡Todo el proceso ya se ha puesto enmarcha!Ahora el cliente debe llamar al autenticador pasándole el Request Token que ha recibido. Estapetición, como va contra el autenticador y no contra el proveedor de servicios no es unapetición OAuth. Es decir, el cliente no se identifica a sí mismo, ni la petición va firmada. Elautenticador comprueba que el token temporal es válido, mira cual fue el cliente que losolicitó (el proveedor de servicios debe haber guardado esta información en algún sitioaccesible para el autenticador) y entonces pueden suceder varias cosas:
  • 1. Que el token temporal pasado no sea válido: Se muestra un mensaje de error al usuario. 2. Que el token temporal sea válido y que el usuario NO esté autenticado contra el autenticador. El usuario recibirá el formulario de login del autenticador donde se le pedirán sus credenciales y que acepte dar permisos a la aplicación indicada. Si el usuario se autentica y da los permisos se sigue al punto 4. 3. Que el token temporal sea válido y el usuario esté autenticado. Si el usuario NO había dado permisos a la aplicación indicada se le pedirá que le de esos permisos. Si el usuario ya los había dado se seguirá al punto 4. 4. El autenticador redirige al usuario a la dirección de callback que especificó el cliente en la primera petición. La dirección de callback recibirá dos parámetros: el token temporal y un código de verificación.¡Ya casi estamos! Una vez el cliente recibe en su dirección de callback una petición, junto conun token temporal y un código de verificación debe: 1. Asegurarse que el token temporal es el mismo que él ha generado 2. Realizar una petición OAuth al proveedor de servicios mandándole el token temporal (Request Token) y el código de verificación. La respuesta a esta petición OAuth serán los tokens finales (Access token and secret) que se usan para identificar llamadas OAuth en nombre del cliente autenticado.Cliente escritorio – Autenticación por PINCuando el cliente es una aplicación de escritorio el proceso es un poco más pesado para elusuario, ya que el cliente no puede especificar una dirección de callback. En este caso se usa loque se llama out-of-band configuration. El tema está en que la especificación lo mencionaexplícitamente, pero luego no dice nada más acerca de este modo de configuración. Así queeste apartado está basado en cómo se ha implementado en Twitter. Este método es válidopara aplicaciones que pueden abrir una ventana de navegador (aunque no puedaninteraccionar con ella).La primera petición es idéntica al flujo tradicional, salvo que el valor de oauth_callback debeser oob. Este valor está reconocido por la especificación para indicar que el cliente quiere usarel método de configuración out-of-band. La respuesta del proveedor será, igual que antes, elpar de tokens temporales (Request Token y Request Secret).La segunda petición del cliente será contra el autenticador. Puede ser que se use el mismoendpoint que el caso anterior, o puede que no. Dependerá de cada implementación, aunque lonormal es que se usen endpoints distintos del autenticador para poder personalizar elcomportamiento de éste en cada caso. El comportamiento del autenticador debe ser el mismoque en el flujo anterior, aunque son posibles algunas variantes. P.ej. Twitter obliga a aceptarde nuevo los permisos incluso aunque se hubiesen aceptado previamente para el mismocliente.La principal diferencia con el flujo 3-legged es que una vez el usuario se autentica y da lospermisos a la aplicación, al no haber dirección de callback a la que redirigir el usuario, elautenticador mostrará una página especial con un código (PIN) que el usuario deberá entrar ala aplicación.
  • El usuario entra el código PIN a la aplicación, y la aplicación usa este código PIN como si fueseel código de verificación: es decir, realiza una llamada OAuth al proveedor de servicios con elRequest Token, el PIN entrado por el usuario y obtiene los tokens OAuth definitivos.Cliente escritorio – autenticación por passwordOtro flujo posible para aplicaciones cliente que no pueden mostrar ni una ventana denavegador, es mandarle al autenticador el login y password del usuario. Claro que eso implicaviolar uno de los principios de OAuth: que el cliente nunca tiene acceso al login y password delusuario. En este caso el usuario debe introducir su login y su password, pero solo una vez,después la aplicación cliente no los usa nunca más, ya que el resto de peticiones son OAuth.Por supuesto estamos ante un tema de confianza de la aplicación. Si yo me descargo laaplicación oficial de Facebook, pongamos por caso, no tendré problemas en introducir mi loginy password en ella. Si me descargo una aplicación realizada por Hackers. Inc. Puesseguramente no la entraré si me la pida (aunque la aplicación pueda ser legítima, yo no tengomanera de saberlo).Como siempre el primer paso del flujo es idéntico: una petición OAuth del cliente para obtenerlos tokens temporales, mandando “oob” como valor de Oauth_callback.Una vez tiene los tokens temporales, el cliente debe puede llamar al autenticador, pasándoleel Request Token junto con el login y el password del usuario. El autenticador comprueba lascredenciales y en caso de que sean correctas, responde con el código de verificación (debenotarse que el autenticador asume que el usuario da permisos a la aplicación, cosa lógicateniendo en cuenta que ha entrado su login y password en ella).La aplicación una vez tiene el código de verificación, reanuda el flujo normal: manda el códigode verificación junto el token temporal al proveedor de servicios para obtener los tokensdefinitivos. A partir de este punto todas las llamadas pueden ser OAuth y el login y passworddel usuario se pueden descartar.2-legged OAuthHay mucha confusión sobre que es 2-legged OAuth y existe básicamente porque es una formade usar OAuth que no se menciona nunca en la especificación, donde una aplicación autoriza aotra aplicación a utilizar recursos protegidos, pero en este caso no se está involucrando aningún usuario. Todo el flujo de adquisición de tokens desaparece: si el cliente está registradoen el proveedor (es decir tiene su par de claves) en lugar de usar el flujo normal y solicitar unpar de tokens temporales, lo que hace es: 1. Realizar una llamada OAuth, usando su clave pública como Access Token (y firmando con el Client Secret).El proveedor de servicios puede verificar que la clave pública pertenece a un cliente registradoy conocido, puede verificar la firma y si esa es correcta ejecuta la petición. En este caso lapetición no se realiza en nombre de ningún usuario.Pseudo-autenticación con OAuthEl flujo final que nos queda por ver es el de pseudo-autenticación, es decir cuando una webpermite autenticar a sus usuarios con las credenciales de un proveedor OAuth. Lo llamamospseudo-autenticación, porque a diferencia de un sistema de autenticación puro, como puede
  • ser OpenID, en el cual se pide la identidad del usuario, en el caso de OAuth se intenta accedera un recurso protegido en nombre de un usuario y el propio flujo de OAuth hará que el usuariose autentique contra el proveedor de servicios. El cliente en este caso no sabe cuál es laidentidad del usuario, pero tiene un token OAuth a través del cual puede acceder a una API ypreguntar por su nombre.Ilustración 2: Autenticación OpenID y pseudo-autenticación OAuth (fuente: Wikipedia)Míralo de este modo: Si yo quiero saber quién eres tú, tengo dos modos de hacerlo: 1. Pedirte que me muestres un documento que te autentique. Por supuesto ambos debemos acordar que tipos de documentos son válidos para autenticarte (el DNI es válido pero la tarjeta de la biblioteca, no). 2. Pedirte las llaves de tu casa, entrar en ella contigo, abrir tu cartera y mirar tu DNI.La primera sería una autenticación pura basada en un protocolo como OpenID. La segundasería pseudo-autenticación basada en OAuth. En el ejemplo del segundo punto, he puestocontigo adrede, para que quede claro de que no puedo hacer lo que quiera cuando esté en tucasa: tan solo puedo hacer lo que tú me hayas autorizado a hacer.Realmente este flujo es idéntico a cualquiera de los tres flujos anteriores que hemos visto.Todos los pasos son idénticos y la experiencia del usuario es la misma. La única diferencia estáen el cliente: antes el cliente solo quiere realizar una llamada a un servicio, mientras que ahorasi la llamada OAuth es exitosa, el cliente autentica al usuario dentro de su propio sistema. Deesta manera el usuario obtiene acceso a una determinada aplicación web usando sus
  • credenciales de otro proveedor OAuth (como pueda ser Facebook o Twitter). Paradesarrolladores de aplicaciones es muy interesante, porque no solo evitan que el usuario debadarse de alta en su sistema, si no que además tienen acceso a los datos que el proveedor deOAuth exponga de ellos (p.ej. podrían acceder al perfil de Facebook).