Entendiendo oAuth

Una breve explicacin sobre oAuth 1.0

[Type the author name] 4/28/2012

Este documento es una breve introduccin a oAuth, comentando brevemente como funciona el procolo en su versin 1.0a y mencionando los distintos flujos de oAuth existentes

Entendiendo OAuth
Contenido
Qu es OAuth? ........................................................................................................................ 2 La necesidad de OAuth .......................................................................................................... 2 Tokens, tokens, tokens.............................................................................................................. 3 Criptografa 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 Normalizacin de peticiones ........................................................................................... 11 Creacin de la cadena base de firma ............................................................................... 12 El mtodo de codificacin percent encoding .................................................................... 12 Elementos de una peticin OAuth ........................................................................................... 13 Parmetros OAuth .............................................................................................................. 13 Localizacin de los parmetros OAuth ................................................................................. 14 Cabecera Authorization ................................................................................................... 14 Flujos de OAuth ...................................................................................................................... 15 3-legged OAuth ................................................................................................................... 15 Cliente escritorio Autenticacin por PIN ........................................................................... 16 Cliente escritorio autenticacin por password .................................................................. 17 2-legged OAuth ................................................................................................................... 17 Pseudo-autenticacin con OAuth ........................................................................................ 17

Desde ya hace un tiempo se oye hablar mucho de OAuth. Casi cualquier red social o aplicacin web que exponga una API pblica para desarrolladores expone sus servicios usando este protocolo. Quieres integrarte con Twitter, Linkedin, Facebook o Google+, entre muchas otras? 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 (creme: ellos son los primeros interesados en que uses sus servicios). Tampoco es objetivo de este documento explicar todos los pormenores de OAuth (para ello hay una especificacin

oficial). Entonces... cul es el objetivo? Pues simple y llanamente: que entiendas OAuth. Que entiendas qu es OAuth, cul es su motivacin, que problemas permite solucionar y que otros puede llegar a plantear. Por supuesto vamos a entrar en detalles sobre el funcionamiento de OAuth, aunque para descripciones detalladas referenciaremos a la RFC. Y s, tambin veremos cmo crear un cliente OAuth y por encima de todo un proveedor de OAuth y cmo integrarlo en nuestras aplicaciones web usando, en este caso, ASP.NET MVC. Si te interesa el tema, y quieres conocer OAuth en lugar de simplemente usarlo... este documento es para ti.

Qu es OAuth?
Resumiendo, OAuth es un protocolo de autorizacin (su nombre proviene de Open Authorization), que permite a un usuario (propietario de ciertos recursos) autorizar a un tercero a que acceda a dichos recursos en su nombre pero sin darle en ningn momento a este tercero sus credenciales de autenticacin (es decir, sin darle a este tercero su nombre de usuario ni contrasea). Actualmente est en su versin 1.0a y se est desarrollando la versin 2.0 que va a ser incompatible con la versin anterior. Dicha versin 2.0 debera haberse finalizado a finales del 2011, pero sigue estando todava en desarrollo y sin fecha prevista de finalizacin. La principal mejoras de OAuth 2.0 respecto a 1.0a son que es ms fcil de usar para el usuario. Este documento se basa en OAuth 1.0. Aun cuando OAuth es un protocolo de autorizacin es posible conseguir una pseudo autenticacin con l, y de hecho uno de usos ms extendidos es el de entrar en una aplicacin web usando el usuario y contrasea de otra aplicacin. De esta manera grandes proveedores de OAuth, como Facebook, se convierten a su vez en proveedores de autenticacin de otras webs. As, paradjicamente, OAuth est teniendo xito donde otros protocolos ms orientados a autenticacin como OpenID o anteriormente Passport (actual Live ID) no han terminado de tenerlo. Esto nos demuestra una vez ms, que el xito de un producto (un protocolo en este caso) viene muchas veces marcado por quien lo adopta, y el momento en que lo adopta, ms que en las caractersticas tcnicas de ste. Esta es una leccin que solemos olvidar demasiado a menudo.

La necesidad de OAuth
La necesidad de un protocolo de autorizacin como es OAuth suele ser la confianza. O mejor dicho, la falta de ella. El hecho de que yo como usuario no confe en una aplicacin lo suficiente como para darle mis datos de autenticacin pero por otro lado quiera permitir que dicha aplicacin realice algo en mi nombre. Y no es lo mismo realizar algo en el nombre de alguien, que suplantar a este alguien. Esto es precisamente lo que permite OAuth: que alguien realice tareas en nombre de otro, pero sin poder suplantarlo: en todo momento se sabe quin es realmente el que est realizando las tareas. Al tener la autorizacin separada de la autenticacin, yo puedo en cualquier momento desautorizar a quien yo haya autorizado previamente. Es decir, impedir que siga realizando tareas en mi nombre. Y puedo hacer esto sin necesidad de modificar mi usuario o contrasea.

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 sus servicios. Pongamos como ejemplo a Facebook. Facebook no expone su API para su propia aplicacin mvil, la expone bsicamente para permitir todo un desarrollo de un ecosistema de aplicaciones integradas en Facebook, pero realizadas por otros. Es una relacin win-win entre Facebook y el creador de la aplicacin. El segundo puede aprovechar todo el potencial social que Facebook puede generar, y el primero obtiene ms interacciones que es lo que ms necesita una red social. Por supuesto que todo esto se podra conseguir sin OAuth, pero en unos tiempos donde se estn mandando tantos (acertados) mensajes contra el phising y continuamente se nos dice que vigilemos nuestras credenciales y que no nos fiemos, no quedara muy bien que cualquier web o aplicacin nos pidiese el usuario y contrasea de Facebook... Qu har con ellos? Cmo tengo yo la seguridad, como usuario, de que la aplicacin es bienintencionada? Adems, incluso en el caso de que la aplicacin fuese bienintencionada, el que todas mis aplicaciones conectadas a Facebook tengan mi usuario y contrasea implica que si alguna vez, por cualquier razn, los modifico deba informar a todas esas aplicaciones de nuevo. Como veremos ms adelante OAuth me permite obviar todo esto. As pues, OAuth expone claras ventajas tanto para usuarios como para desarrolladores de servicios. Ha llegado el momento de ver, someramente, como funciona.

Tokens, tokens, tokens

La verdad es que OAuth va, bsicamente, sobre intercambiar tokens. Hay tres roles que debemos considerar: El cliente, que quiere acceder a un servicio en nombre de un usuario. Este cliente puede ser una aplicacin web, mvil o de escritorio. El proveedor de servicios, que provee el servicio al cual quiere acceder el cliente El autenticador que autentica los usuarios

Lo que OAuth define es como esos tres roles deben comunicarse entre ellos para que al final el cliente pueda acceder al servicio. Lo que no define OAuth es como el autenticador realiza su trabajo (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 usuario que haya autenticado el autenticador.

Criptografa para dummies

Antes de meternos de lleno en OAuth, dado que vamos a hablar de firma digital y mtodos criptogrficos de clave simtrica o asimtrica djame que te hable un poco sobre conceptos elementales de criptografa. Si conoces que son los mtodos de clave simtrica, asimtrica y la firma digital, eres libre de saltarte este apartado :) Y por supuesto, si encuentras todo el tema de la criptografa aburrido y falto de inters te lo puedes saltar tambin, en el fondo no es necesario conocerlo para poder usar OAuth... Aunque s para entenderlo realmente, y como de eso se trata, si te apetece all vamos!

Dos amigos... Imaginemos a dos amigos, Alice y Bob que quieren enviarse un mensaje codificado sin que nadie ms pueda descifrarlo. Hay muchos mecanismos de encriptacin que pueden utilizar, pero los podemos dividir en dos grupos: de clave simtrica y de clave asimtrica. Los de clave simtrica son los primeros que nos vienen a la cabeza cuando pensamos en mecanismos de codificacin. Tenemos una funcin (f) que dada una clave (K) y un texto a codificar (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 conversacin privada y para ello deciden cifrarla. Lo primero que tienen que hacer es quedar de acuerdo en la clave a usar. Bastara con un correo de Alice proponiendo la clave y uno de Bob aceptndola. A partir de este punto ambos usan la misma clave y la conversacin puede tener lugar. Si has arrugado la nariz cuando he mencionado que Alice enve un correo con la clave es que has visto el punto dbil de los mtodos de clave simtrica: el intercambio de la clave. Es un punto muy delicado, ya que si alguien (un tal Mallory que os presentar luego) descubre la clave, toda la conversacin entre Alice y Bob est comprometida. Es aqu donde entran en juego los mecanismos de clave asimtrica. Dichos mecanismos se basan en algo muy simple (pero a la vez muy potente): la capacidad de generar dos pares de claves, ligadas de algn modo entre s, de forma que al codificar algo con una de las claves se pueda decodificar con la otra y viceversa. As pues si tenemos un par de claves, llammoslas A y B, un texto (t) a codificar y una funcin (f) que dado una clave y un texto devuelve un texto codificado, se cumple que: , ( , ) = , ( , ) =

Y no slo eso, si no que la relacin NO es reflexiva: , ( , ) <> , ( , ) <>

Cada uno de ellos por separado y sin comunicrselo a nadie genera un par de claves (A,B). En este momento Alice tiene su par de claves y Bob las suyas. Posteriormente ambos se envan por mail una sola de esas claves (pongamos la A), a la que llamaremos la clave pblica. La otra clave del par de claves, se la guardan para ellos mismos y no la dicen a nadie as que la llamaremos la clave privada. De hecho, cualquiera que ms adelante quisiera enviar mensajes a Bob, como su amigo del instituto Charlie, debe pedirle a Bob que le d la clave pblica. Tan solo esa. En este momento, Bob pondra enviar un mensaje a Alice, encriptado con la clave pblica de ella. El resultado es un mensaje que solo puede decodificar quien posea la otra clave del par de claves. Y dado que Bob ha usado la clave pblica de Alice, quien posee la otra clave del par de 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 el mensaje? Pues muy simple: tan solo debe cifrarlo usando la clave pblica de Bob, para que este al recibirlo use su clave privada y pueda descifrarlo. Resumiendo, la idea es muy simple: se cifra el mensaje con la clave pblica del receptor, el cual debe usar su clave privada (que solo conoce l) para descifrarlo. Este sistema asegura cifrado y descifrado seguro de los mensajes (tan seguro como sea el algoritmo de encriptacin que se use, pero eso es otra historia). Pero existe un riesgo que debemos tener presente. ...y el novio celoso. Recordis que antes mencionamos a Mallory? Dejadme que os lo presente: es el novio de Alice. Aunque es un buen tipo, es extremadamente celoso y como cree que Bob tiene intenciones poco honestas con Alice hace tiempo que est espiando lo que ella hace. En el fondo Mallory no le tiene mana a Bob: cree que todo el mundo quiere algo con Alice ms all de la amistad. A priori puede parecer que el mecanismo de encriptacin basado en clave asimtrica les protege del todo: la nica clave que circula al principio de la conversacin entre Alice y Bob es la clave pblica de cada uno de ellos que solo sirve para cifrar, nunca para descifrar, as que aunque Mallory supiese la clave pblica no podra hacer nada (a diferencia de un mecanismo de clave simtrica, ya que en este caso si Mallory descubre la clave puede descifrar toda la conversacin). En efecto, es cierto que si Mallory tan solo conoce las claves pblicas de ambos no puede comprometer la seguridad de la comunicacin de los dos amigos... Pero esta certeza no es garanta de una seguridad absoluta. Y es que Mallory instal un proxy conectado a su propio ordenador que le permite tener acceso e interceptar todo lo que su novia enva y recibe desde internet (s, los celos son muy malos). Gracias a esto Mallory intercepta el correo en el que Alice le peda a Bob su clave pblica y deja que llegue a Bob. Bob recibe el mensaje que proviene de Alice y le contesta con su clave pblica. Dicho mensaje es interceptado de nuevo por Mallory, quien cambia la clave pblica de Bob por la suya, se guarda la clave pblica de Bob y reenva el mensaje a Alice. En este punto Alice cree tener la clave pblica de Bob, pero realmente tiene la de su novio. As cuando Alice quiere decirle algo a Bob, lo encripta con la clave pblica de este... o con lo que ella cree que es la clave pblica de Bob. Porque realmente es la de Mallory, el cual puede descifrarlo (usando su clave privada), modificarlo, cifrarlo de nuevo (usando la clave pblica de Bob que se ha guardado antes) y reenviar el mensaje a Bob, quien creer que el mensaje proviene de Alice. Este tipo de ataques, en el cual un tercero (Mallory) puede interceptar, leer y modificar mensajes que se envan un par de actores (Alice y Bob) sin que ninguno de ellos pueda saber que 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 que usaron para intercambiar sus claves. Este es el punto dbil de todo sistema de criptografa: el intercambio de claves (s, incluso en los asimtricos donde podramos creer que evitaban este problema).

Amigo lector, por si lo has pensado, una solucin muy rpida que evitara los trapicheos de Mallory, sera evitar que hubiese intercambio de claves pblicas al inicio de la conversacin entre Bob y Alice. Si ambos publicasen su clave pblica en una web, a la vista del todo el mundo, Mallory no podra interceptar ningn mensaje y sustituir las claves porque este mensaje no existira: cuando Alice quisiera ver la clave pblica de Bob la mirara en esta web y viceversa. Claro que en este caso tanto Alice como Bob deben tener estar seguros de que la web donde publican sus claves pblicas es de confianza. No vaya a ser que le encarguen hacer la web a Chuck, un antiguo compaero de fiestas de Mallory, con lo que estaran igual que antes. Pero si la web es de una empresa que ofrece este servicio (hospedar claves pblicas), y que ofrece absolutas garantas de seguridad, entonces s que Mallory no tiene nada que hacer y Alice y Bob pueden estar tranquilos... Y aunque pueda parecer muy tonto, esto de publicar las claves pblicas de todos en un sitio comn, es ms o menos lo que hacemos actualmente con los certificados digitales y las infrastructuras de clave pblica (PKI). Firmas digitales Si has entendido como funciona la encriptacin, ya ests listo para comprender como funciona la firma digital. El concepto de firma digital es extremadamente sencillo: se trata de aplicar una funcin de hash al documento y cifrar tan solo el hash. El hash cifrado constituye la firma digital. Funciones de hash Si Bob quiere enviar un documento firmado digitalmente, debe calcular el hash de este documento. El hash no es ms que aplicar una funcin que devuelva un valor resumen que dependa de los datos del documento. Lo de resumen viene porque generalmente el tamao en bytes del documento suele ser superior al tamao en bytes del hash. As una posible funcin de hash sera sumar los cdigos ASCII de todos los caracteres del documento y realizar el mdulo 256. Con esto obtendramos un nmero de 0 a 255. Fijaos que convertimos textos de cualquier nmero de byes a valores de un solo byte, de ah lo de resumen. Dada esa funcin de hash, el hash del texto Hola seria 132. Por supuesto esta es una funcin de hash horrorosa, seguro que no te cuesta nada encontrar otro texto distinto que d el mismo valor de hash. Es evidente que, por norma general, siempre habr ms documentos que hash posibles (en nuestro caso hay infinitos documentos posibles y tan solo 256 hash), por lo que habr colisiones (es decir dos documentos distintos que generen el mismo hash). Lo que distingue una buena funcin de hash de una de mala es lo que cueste encontrar dos documentos distintos que generen un mismo hash (lo que en criptografa se conoce como resistencia a las colisiones y que mide cuan resistente es una funcin de hash frente a lo que se conoce como un ataque de cumpleaos). Suponiendo una funcin de hash con alta resistencia a las colisiones (es decir que sea inviable encontrar dos elementos que den el mismo hash) entonces Bob puede firmar un documento de la siguiente manera: 1. Calcula el hash del documento 2. Cifra el hash y obtiene la firma digital. 3. Enva el documento junto con la firma digital.

Lo importante aqu es que el documento no tiene por qu estar encriptado (puede estarlo pero no es obligatorio). Lo que est cifrado usando la clave privada de Bob es el hash y eso constituye 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 funcin de hash) 3. Comparar ambos valores (el hash descifrado y el hash calculado) Si ambos valores coinciden la firma digital del documento es vlida y qu significa exactamente esto? Pues depende del mecanismo de cifrado que se use para cifrar el hash. Firmas con mecanismos asimtricos vs firmas con mecanismos simtricos A grandes rasgos: una firma digital correcta indica que el documento no ha sido modificado por nadie a excepcin de un remitente vlido y que ha sido enviado por un remitente vlido. Lo que significa exactamente remitente vlido vara en funcin de si para cifrar el hash se us un mecanismo con claves simtricas o asimtricas. Si se ha usado un mecanismo con claves asimtricas, remitente vlido es aquel que ha enviado el documento. Nadie ms. Debe notarse que decimos aquel que ha enviado el documento, no aquel que legtimamente puede leerlo. Si en el ejemplo anterior Bob hubiese usado un mecanismo de cifrado asimtrico podemos afirmar que el documento no ha sido alterado (lo que se ha recibido es lo que se ha enviado) por nadie ms. No solo eso, si no que adems se puede asegurar que ha sido Bob quien lo ha enviado (o dicho a la inversa, Bob no puede negar haber enviado el documento, lo que se conoce como no repudio). Si alguien intercepta el documento y lo modifica, dado que no puede modificar la firma digital (ya que est cifrada con la clave privada de Bob que tan solo tiene l), cuando el receptor reciba el mensaje el hash que l calcule diferir del que vena con el documento, con lo que se sabr que ha sido interceptado y modificado. Si se ha usado un mecanismo de clave pblica, entonces remitente vlido significa cualquiera que conozca la clave. Es decir cualquiera que pueda recibir un mensaje y calcular la firma digital. Si Bob calcula su firma digital cifrando el hash con un mecanismo de clave simtrica, es evidente que Alice debe conocer la clave para poder descifrar el hash y compararlo con el que obtenga ella para validar la firma digital. Pero dado que la clave que se usa para descifrar es la misma para cifrar y que Alice tambin 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 podemos pues asegurar unvocamente 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 es modificado por alguien que no conoce la clave de cifrado, el resto de participantes que s la tienen se darn cuenta de que el mensaje ha sido modificado. Digamos que, usando un mecanismo cifrado de clave simtrica, todos los participantes vlidos son tratados como una misma persona. Seguridad de la firma digital Fjate que la asuncin principal que se realiza de la firma digital (se puede asegurar que el documento no ha sido modificado), depende directamente de que la funcin de hash tenga una alta resistencia a las colisiones. De hecho lo que debe evitarse es que sea factible para alguien generar un par de documentos (uno autntico y otro fraudulento) que tengan el

mismo hash1. Si eso es factible (a nivel computacional) de realizar, alguien, llammosla Carol, podra presentar el documento autntico a Bob, quien lo firmara y luego podra aadir la firma digital de Bob al documento fraudulento, con lo que a todos los efectos sera como si Bob hubiese firmado dicho documento falso. El propsito de la firma digital no es evitar que alguien intercepte el mensaje, si no asegurar que ste no ha sido alterado en trnsito y que es enviado realmente por el remitente. Si se quiere evitar que el mensaje sea visible a terceros, este debe adems cifrarse. Eso s, que quede claro: La firma digital no evita que pueda existir un Man-in-the-middle si el intercambio de claves ha sido comprometido. OAuth permite usar tanto mecanismos de clave simtrica como mecanismos de clave simtrica para cifrar el hash y obtener la firma digital. A la prctica la mayora de proveedores soportan tan solo un mecanismo de clave simtrico (HMAC) para evitar todo el proceso de negociacin de claves pblicas. Aunque es un poco menos seguro (cualquiera que robe la clave que se use para cifrar los mensajes podr enviar mensajes OAuth vlidos) evita todo el trasiego de intercambio de claves pblicas.

Firma de peticiones en OAuth

En OAuth todas las peticiones que realiza el cliente van firmadas digitalmente. La especificacin habla explcitamente de tres mtodos de firmado: 1. HMAC-SHA1: Que es un mtodo de firma electrnica basado en la funcin de hash SHA1 y el mtodo de cifrado simtrico HMAC 2. RSA-SHA1: Que es un mtodo de firma electrnica basado en la funcin de hash SHA1 y el mtodo de cifrado asimtrico RSA. La especificacin no dice nada sobre como el cliente y el proveedor de servicios intercambian sus claves pblicas. 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 mtodo es altamente inseguro y de hecho la propia especificacin ya indica que debe usarse sobre un canal de comunicacin seguro (SSL o TLS) y tiene su razn de existir en que si se usa uno de esos canales, no es necesario aadir un mtodo adicional como la firma electrnica para garantizar que la peticin no ha sido modificada, dado que el propio canal seguro te lo asegura. Honestamente, en la especificacin no queda muy claro si debe darse soporte a esos tres mtodos o bien puede darse soporte a solo algunos de ellos. Lo que s dice es que pueden aadirse mtodos adicionales. En la vida real, hay muchos proveedores de OAuth que no soportan RSA-SHA1 supongo que para evitar el problema de intercambio de claves pblicas, algo que se evita en HMAC-SHA1 al ser este un mtodo asimtrico donde hay una sola clave compartida y conocida por todos. Personalmente creo que implementar solo HMAC-SHA1 es una solucin ms que vlida-

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 de documentos con el mismo hash.

La necesidad de que en OAuth cada peticin vaya firmada es, evidentemente, por seguridad: si no fuese as, alguien podra interceptar la peticin del cliente al proveedor de servicios, modificarla y reenviarla de nuevo. Precisamente para evitar esto y asegurar que el proveedor de servicios solo responde a peticiones legtimamente enviadas por un cliente, estas deben ir firmadas. Esto no evita que alguien pueda ver los datos que se envan entre cliente y proveedor 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 sncrona de http): tan solo se firman las peticiones del cliente. Exacto: alguien con un sniffer podra modificar las respuestas del proveedor de servicios y el cliente no se dara cuenta, pero para evitar este escenario ya hay otras alternativas de seguridad adicionales a OAuth (SSL o TLS sin ir ms lejos). Este no es un escenario que intente resolver OAuth. 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, vers que continuamente se habla de pares de tokens: el token pblico y el secreto (key y secret en ingls). No te confundas: esos pares de tokens, no son pares de claves asimtricas! Realmente uno de ellos (el pblico) acta como identificador y el otro (el secreto) es el que se usa para firmar digitalmente. Tipo de tokens OAuth Consumer Key y Consumer Secret Por lo tanto todo cliente que quiera usar OAuth deber tener su par de tokens. Quien otorga estos tokens y como estas son transferidas al cliente est fuera de la especificacin de OAuth. Es decir, OAuth no define ningn mecanismo para que el cliente obtenga su par de tokens. Simplemente se asume que las tiene, y que ambos tanto cliente como proveedor de servicios las conocen. En terminologa OAuth llamamos Consumer Key al token que identifica un cliente y Consumer Secret al token privado que este cliente usar para firmar sus peticiones OAuth. Aunque desde siempre se han llamado as, en la RFC decidieron modificar el nombre y llamarlos Client Credentials (credenciales de cliente) nombre que realmente es ms acertado. La especificacin no dice nada acerca de como el cliente obtiene sus credenciales, pero en la prctica lo ms normal es tener que registrar el cliente manualmente, en el proveedor de servicios.

Ilustracin 1: Registro de una aplicacin cliente en Twitter

La Ilustracin 1 muestra el proceso de registro de un cliente en Twitter. Una vez registrado el cliente Twitter nos informar de nuestras credenciales de cliente, que son las que deberemos usar. Este mtodo es sencillo y eficaz aunque obliga a registrar cada posible cliente de forma manual. Tanto Facebook, como LinkedIn como cualquiera de los proveedores de OAuth ofrecen un mecanismo similar para el registro de clientes. Request Token y Request Secret El objetivo final de OAuth es permitir acceder a recursos protegidos en nombre de un usuario en concreto. Para ello, el cliente debe a partir de sus credenciales de cliente, obtener unos tokens 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 servirn para ir enlazando toda la serie de peticiones OAuth que son necesarias para obtener los tokens definitivas (mucha gente se refiere a esa serie de peticiones con el nombre de OAuth Tokens dance).

El Request Token identifica a una peticin de permisos para un usuario en concreto. Cuando el cliente quiere obtener un token de acceso definitivo, lo que obtiene primero es el Request Token. Luego manda este Request Token al autenticador, quien (si el usuario acepta los permisos) le devuelve un cdigo de verificacin que luego el cliente puede usar para obtener los tokens finales (no te preocupes si eso te parece muy lioso ahora, luego aclararemos completamente el flujo OAuth). Lo importante es que te quedes con la idea de que el Request Token y el Request Secret son tokens temporales, que son descartados una vez se obtienen los definitivos. A lo mejor te ests preguntando por que es necesario un Request Secret. No se supone que las peticiones van firmadas usando el Consumer Secret como clave para generar la firma digital? La respuesta es que una vez tenemos Request Token, las peticiones OAuth que hagamos irn 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 que se usan comnmente, pero la RFC usa otros nombres que son (de nuevo) mucho ms acertados: Temporary Credentials. Access Token y Access Secret El 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 permisos demandados por el cliente. Una vez el cliente obtiene esos tokens, el flujo de OAuth termina y el 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 vez tenga 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 datos de la peticin se firman? Normalizacin de peticiones La firma digital de un documento (en nuestro caso de una peticin http) depende de los datos que esta contenga. Debemos preguntarnos pues qu define a una peticin http? El primer elemento es la URL, dos peticiones sern distintas si su URL es distinta. Eso significa que peticiones que solo difieren en la URL (incluso si van a URLs sinnimas como pueden ser http://www.krasis.com y http://217.130.23.249) van a generar firmas digitales distintas. Otro elemento son los parmetros de la peticin. HTTP permite que las peticiones lleven parmetros en varios sitios (query string, cuerpo, headers varios), as que OAuth define cuales son los posibles orgenes de los parmetros. En concreto se tomarn: 1. Los parmetros de la query string 2. Los parmetros en el cuerpo de la peticin si esta viene como application/x-wwwform-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 parmetros (en el mismo orden y situacin si se quiere) pero que sean dos peticiones 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 base de firma incluye todo lo que es relevante de una peticin http: su verbo, su URL y sus parmetros. El proceso de conseguir la cadena base de firma a partir de una peticin de http se conoce como normalizacin de peticiones. Y es que, como veremos ahora, peticiones distintas, pero que signifiquen lo mismo, van a generar la misma cadena base de firma. A que me refiero con peticiones no idnticas pero que signifiquen lo mismo? Pues que tengan los mismos parmetros pero en orden distinto, o que la URL sea igual pero difiera en maysculas o minsculas. Creacin de la cadena base de firma Para obtener esta cadena a partir de una peticin http, debemos realizar unos pasos sencillos, pero de vital importancia (si nos equivocamos en esto, nuestra cadena base diferir de la que calcule el proveedor de servicios y por lo tanto la firma digital ser distinta, generando una peticin invlida): 1. Obtener el verbo http usado, en maysculas (p.ej. POST o GET). 2. Obtener la URL normalizada. Esto significa que la URL se pasa toda a minsculas. El valor del host y del port debe coincidir con el valor de la cabecera Host. La ruta hasta la query string se aade tal cual. El puerto se incluye solo si no es el estndar (80 para http o 443 para https). 3. Obtener una cadena con todos los parmetros de la peticin. Para ello con independencia de donde estn (query string, cuerpo de la peticin o cabecera Authorization) se ordenan por orden alfabtico y se concatenan uno tras otro (nombre=valor). Si dos parmetros tienen el mismo nombre, se ordenan por su valor. Si un parmetro est vaco, 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 parmetros de la URL, siguiendo el mismo procedimiento anterior 6. Se crea una cadena con el valor de 1, el smbolo &, el valor de 4, el smbolo & 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 hash para obtener la firma digital de la peticin. El mtodo de codificacin percent encoding Este mtodo se usa solo para el clculo de la cadena base de firma. Es un mtodo muy parecido y basado en el mtodo de codificacin de URIs (definido por la RFC 3986 en su apartado 2.1). La RFC de OAuth 1.0, en su seccin 3.6 define claramente como es esta codificacin: 1. Se codifica la cadena en UTF8

2. Los siguientes caracteres: letras, nmeros, -,.,_ y ~ no son codificados y se ponen tal cual. 3. Cualquier otro carcter debe ser codificado usando %xx, donde xx es el cdigo hexadecimal, en maysculas, del byte. Aunque el mtodo parece idntico al definido por el RFC 3986 en su apartado 2.1 no lo es. Hay una sutil diferencia: en OAuth se codifican todos los caracteres excepto los indicados en el punto 2. Mientras que en el RFC 3986 algunos caracteres no se codifican si actan como separadores. Es un detalle importante. P.ej. la URL http://www.krasis.com codificada segn la RFC 3986 es: http://www.krasis.com, mientras que usando el percent encoding de OAuth, los caracteres : y / se codifican igualmente, aun cuando forman parte del separador :// que separa protocolo de host. As pues la URL queda como http%3%2F%2Fkrasis.com As pues cuidado con usar mtodos que codifiquen URLs, incluso aunque sean conformes al RFC 3986, ya que puede ser que no generen exactamente la misma cadena.

Elementos de una peticin OAuth

Toda peticin que llamemos peticin OAuth deber contener algunos elementos obligatorios que son los parmetros OAuth y la firma digital. No todos los parmetros son obligatorios en todo momento. El protocolo define un conjunto de elementos que toda peticin OAuth debe tener, y que sirven para garantizar el buen funcionamiento de ste. Los que deben existir en toda peticin OAuth son: 1. 2. 3. 4. 5. El identificador del cliente (Consumer Key). Un timestamp: Usualmente el nmero de segundos desde el 01 de Enero de 1970. Un nmero nico (nonce) El mtodo de firma digital usado La firma digital

Luego, 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 atencin, por lo ambiguo de su definicin. Realmente la especificacin no dice mucho acerca de l, salvo que no tiene ni porque ser un nmero y que su uso est recomendado para poder discernir entre dos peticiones distintas dado un mismo timestamp. O sea que dos peticiones con el mismo timestamp y del mismo cliente, deben tener un valor de nonce. La especificacin no dice si deben ser secuenciales o no, de hecho ya hemos comentado que no tiene ni porque ser un nmero! Cada proveedor puede establecer sus reglas y los clientes deben adaptarse a ellas. De hecho su uso no es obligatorio, depende de cada proveedor de servicios.

Parmetros OAuth
El nombre de los distintos parmetros OAuth est definido por el protocolo y son los siguientes:

1. 2. 3. 4. 5. 6.

oauth_consumer_key: Identificador del cliente (Consumer Key) oauth_timestamp: Timestamp de la peticin oauth_nonce: Valor del nmero nico oauth_signature_method: Contiene el tipo de mtodo de firma digital que se usa. oauth_signature: Contiene la firma digital de la peticin oauth_token: Contiene o bien el Request Token o bien el Access Token (en funcin del paso del flujo en el que nos encontremos).

Adicionalmente a estos parmetros existen otros que se usan en momentos puntuales y que son los siguientes: 7. oauth_callback: URL que debe llamar el autenticador con el cdigo de verificacin en el flujo 3-legged OAuth. 8. oauth_token_secret: Credencial temporal privada / Access token privado (en funcin del paso del flujo en el que estemos) que nos devuelve el proveedor de servicios. 9. oauth_verifier: Cdigo de verificacin que devuelve el autenticador Al margen de esos se pueden definer parmetros adicionales y esos pueden empezar por oauth_ si as se desea (la especificacin no lo prohbe).

Localizacin de los parmetros OAuth

Estos elementos se pueden incluir en distintas partes de la peticin: 1. En el querystring 2. En el cuerpo de la peticin (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 especificacin. La especificacin seala que un proveedor OAuth debe soportar los parmetros OAuth en cualquier de esas partes de la peticin y que debe vigilar que no haya elementos duplicados (p.ej. un parmetro oauth_nonce en query string y otro en la cabecera Authorization). Si se encuentran elementos duplicados debe devolverse un error, en lugar de usar uno de los dos en funcin de cualquier posible criterio de prioridad. Cabecera Authorization Como se ha mencionado, la manera preferida es en la cabecera Authorization, segn muestra este 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 parmetro realm de aparecer se ignora a efectos de OAuth.

Como se puede ver el formato es nombre=valor (el valor est entrecomillado). Si un parmetro tiene un valor vaco debe aparecer nombre= (dos comillas dobles seguidas). Estrctamente hablando entre el nombre del parmetro y el signo de igual no se admiten espacios. Al igual que entre el signo de igual y la primera de las dos comillas dobles. Los parmetros van separados por una coma y un salto de lnea opcional. Lo que es importante es que el valor del parmetro est codificado usando Percent Encoding (ver el valor del parmetro oauth_callback para un ejemplo). En la RFC (apartado 3.5.1) se especifica con todo lujo de detalles el formato de la cabecera Authorization.

Flujos de OAuth
Vamos a explorar los diversos flujos de OAuth que existen. La especificacin en s define un solo flujo, el conocido como 3-legged OAuth, pero vamos a explorar algunos flujos ms que se pueden encontrar en distintos proveedores (como linkedin o twitter). Dos de ellos estn pensados para aplicaciones de escritorio (o mviles) otro es para el caso de que queramos ejecutar servicios pero en nombre de ningn usuario en concreto y finalmente hablaremos sobre la pseudo-autenticacin usando OAuth (el famoso sign with Facebook que se ve en numerosas web). Esos flujos se diferencian tan solo por la forma en que el cliente (ya sea otra web o una aplicacin de escritorio) consigue los tokens OAuth definitivos). Empecemos por el flujo definido por la propia especificacin

3-legged OAuth
Este es el flujo ms conocido de OAuth y por el cual realmente fue creado. En este caso se asume que el cliente es capaz de tener un endpoint accesible para que el autenticador le pueda enviar el cdigo de verificacin. Evidentemente esto solo es posible si el cliente es una aplicacin web. Pero vayamos paso a paso... El primer paso es que el cliente realice una peticin OAuth para pedir un par de tokens temporales. Esos tokens temporales (conocidos comnmente como request token and secret) son los que usarn en todo el flujo hasta terminar obteniendo los tokens definitivos (conocidos como access token and secret). Para obtener estos tokens el cliente bsicamente se identifica a si mismo (usando su consumer key) y enva un parmetro llamado oauth_callback que es a donde debe recibir el cdigo de validacin que le servir para obtener los tokens definitivos. El proveedor de servicios responde a dicha peticin con los tokens temporales contenidos en los parmetros oauth_token y oauth_token_secret. Todo el proceso ya se ha puesto en marcha! Ahora el cliente debe llamar al autenticador pasndole el Request Token que ha recibido. Esta peticin, como va contra el autenticador y no contra el proveedor de servicios no es una peticin OAuth. Es decir, el cliente no se identifica a s mismo, ni la peticin va firmada. El autenticador comprueba que el token temporal es vlido, mira cual fue el cliente que lo solicit (el proveedor de servicios debe haber guardado esta informacin en algn sitio accesible para el autenticador) y entonces pueden suceder varias cosas:

1. Que el token temporal pasado no sea vlido: Se muestra un mensaje de error al usuario. 2. Que el token temporal sea vlido y que el usuario NO est autenticado contra el autenticador. El usuario recibir el formulario de login del autenticador donde se le pedirn sus credenciales y que acepte dar permisos a la aplicacin indicada. Si el usuario se autentica y da los permisos se sigue al punto 4. 3. Que el token temporal sea vlido y el usuario est autenticado. Si el usuario NO haba dado permisos a la aplicacin indicada se le pedir que le de esos permisos. Si el usuario ya los haba dado se seguir al punto 4. 4. El autenticador redirige al usuario a la direccin de callback que especific el cliente en la primera peticin. La direccin de callback recibir dos parmetros: el token temporal y un cdigo de verificacin. Ya casi estamos! Una vez el cliente recibe en su direccin de callback una peticin, junto con un token temporal y un cdigo de verificacin debe: 1. Asegurarse que el token temporal es el mismo que l ha generado 2. Realizar una peticin OAuth al proveedor de servicios mandndole el token temporal (Request Token) y el cdigo de verificacin. La respuesta a esta peticin OAuth sern los tokens finales (Access token and secret) que se usan para identificar llamadas OAuth en nombre del cliente autenticado.

Cliente escritorio Autenticacin por PIN

Cuando el cliente es una aplicacin de escritorio el proceso es un poco ms pesado para el usuario, ya que el cliente no puede especificar una direccin de callback. En este caso se usa lo que se llama out-of-band configuration. El tema est en que la especificacin lo menciona explcitamente, pero luego no dice nada ms acerca de este modo de configuracin. As que este apartado est basado en cmo se ha implementado en Twitter. Este mtodo es vlido para aplicaciones que pueden abrir una ventana de navegador (aunque no puedan interaccionar con ella). La primera peticin es idntica al flujo tradicional, salvo que el valor de oauth_callback debe ser oob. Este valor est reconocido por la especificacin para indicar que el cliente quiere usar el mtodo de configuracin out-of-band. La respuesta del proveedor ser, igual que antes, el par de tokens temporales (Request Token y Request Secret). La segunda peticin del cliente ser contra el autenticador. Puede ser que se use el mismo endpoint que el caso anterior, o puede que no. Depender de cada implementacin, aunque lo normal es que se usen endpoints distintos del autenticador para poder personalizar el comportamiento de ste en cada caso. El comportamiento del autenticador debe ser el mismo que en el flujo anterior, aunque son posibles algunas variantes. P.ej. Twitter obliga a aceptar de nuevo los permisos incluso aunque se hubiesen aceptado previamente para el mismo cliente. La principal diferencia con el flujo 3-legged es que una vez el usuario se autentica y da los permisos a la aplicacin, al no haber direccin de callback a la que redirigir el usuario, el autenticador mostrar una pgina especial con un cdigo (PIN) que el usuario deber entrar a la aplicacin.

El usuario entra el cdigo PIN a la aplicacin, y la aplicacin usa este cdigo PIN como si fuese el cdigo de verificacin: es decir, realiza una llamada OAuth al proveedor de servicios con el Request Token, el PIN entrado por el usuario y obtiene los tokens OAuth definitivos.

Cliente escritorio autenticacin por password

Otro flujo posible para aplicaciones cliente que no pueden mostrar ni una ventana de navegador, es mandarle al autenticador el login y password del usuario. Claro que eso implica violar uno de los principios de OAuth: que el cliente nunca tiene acceso al login y password del usuario. En este caso el usuario debe introducir su login y su password, pero solo una vez, despus la aplicacin cliente no los usa nunca ms, ya que el resto de peticiones son OAuth. Por supuesto estamos ante un tema de confianza de la aplicacin. Si yo me descargo la aplicacin oficial de Facebook, pongamos por caso, no tendr problemas en introducir mi login y password en ella. Si me descargo una aplicacin realizada por Hackers. Inc. Pues seguramente no la entrar si me la pida (aunque la aplicacin pueda ser legtima, yo no tengo manera de saberlo). Como siempre el primer paso del flujo es idntico: una peticin OAuth del cliente para obtener los tokens temporales, mandando oob como valor de Oauth_callback. Una vez tiene los tokens temporales, el cliente debe puede llamar al autenticador, pasndole el Request Token junto con el login y el password del usuario. El autenticador comprueba las credenciales y en caso de que sean correctas, responde con el cdigo de verificacin (debe notarse que el autenticador asume que el usuario da permisos a la aplicacin, cosa lgica teniendo en cuenta que ha entrado su login y password en ella). La aplicacin una vez tiene el cdigo de verificacin, reanuda el flujo normal: manda el cdigo de verificacin junto el token temporal al proveedor de servicios para obtener los tokens definitivos. A partir de este punto todas las llamadas pueden ser OAuth y el login y password del usuario se pueden descartar.

2-legged OAuth
Hay mucha confusin sobre que es 2-legged OAuth y existe bsicamente porque es una forma de usar OAuth que no se menciona nunca en la especificacin, donde una aplicacin autoriza a otra aplicacin a utilizar recursos protegidos, pero en este caso no se est involucrando a ningn usuario. Todo el flujo de adquisicin de tokens desaparece: si el cliente est registrado en el proveedor (es decir tiene su par de claves) en lugar de usar el flujo normal y solicitar un par de tokens temporales, lo que hace es: 1. Realizar una llamada OAuth, usando su clave pblica como Access Token (y firmando con el Client Secret). El proveedor de servicios puede verificar que la clave pblica pertenece a un cliente registrado y conocido, puede verificar la firma y si esa es correcta ejecuta la peticin. En este caso la peticin no se realiza en nombre de ningn usuario.

Pseudo-autenticacin con OAuth

El flujo final que nos queda por ver es el de pseudo-autenticacin, es decir cuando una web permite autenticar a sus usuarios con las credenciales de un proveedor OAuth. Lo llamamos pseudo-autenticacin, porque a diferencia de un sistema de autenticacin puro, como puede

ser OpenID, en el cual se pide la identidad del usuario, en el caso de OAuth se intenta acceder a un recurso protegido en nombre de un usuario y el propio flujo de OAuth har que el usuario se autentique contra el proveedor de servicios. El cliente en este caso no sabe cul es la identidad del usuario, pero tiene un token OAuth a travs del cual puede acceder a una API y preguntar por su nombre.

Ilustracin 2: Autenticacin OpenID y pseudo-autenticacin OAuth (fuente: Wikipedia)

Mralo de este modo: Si yo quiero saber quin 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 vlidos para autenticarte (el DNI es vlido 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 sera una autenticacin pura basada en un protocolo como OpenID. La segunda sera pseudo-autenticacin basada en OAuth. En el ejemplo del segundo punto, he puesto contigo adrede, para que quede claro de que no puedo hacer lo que quiera cuando est en tu casa: tan solo puedo hacer lo que t me hayas autorizado a hacer. Realmente este flujo es idntico a cualquiera de los tres flujos anteriores que hemos visto. Todos los pasos son idnticos 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 ahora si la llamada OAuth es exitosa, el cliente autentica al usuario dentro de su propio sistema. De esta manera el usuario obtiene acceso a una determinada aplicacin web usando sus

credenciales de otro proveedor OAuth (como pueda ser Facebook o Twitter). Para desarrolladores de aplicaciones es muy interesante, porque no solo evitan que el usuario deba darse de alta en su sistema, si no que adems tienen acceso a los datos que el proveedor de OAuth exponga de ellos (p.ej. podran acceder al perfil de Facebook).