En la entrada anterior del hilo vimos cuál es el proceso que sigue un usuario para autorizar a una aplicación cliente acceder a sus recursos. A partir de ese momento, todas las peticiones que la aplicación cliente realiza al servidor identifican tanto a ésta como al usuario pero ¿cómo hace para que el servidor sepa con qué usuario se corresponde y a través de qué aplicación está accediendo? Fácil, por medio de firma digital.
OAuth soporta tres tipos de "firma" digital: HMAC-SHA1, RSA-SHA1 y PLAINTEXT (aunque éste último no es un tipo de firma como ahora veremos, de ahí las comillas). El método de firma a utilizar en cada caso depende únicamente de la elección que haga el servidor, ya que son las aplicaciones cliente las que tienen que adaptarse a la implementación que se haya hecho de OAuth. De este modo los servidores, al publicar sus APIs, especifican el tipo o tipos de firma que soportan.
Aquellos que sepan algo de criptografía y conozcan los algoritmos de firma digital sabrán que para llevarse a cabo hace falta, por un lado, una cadena o un mensaje que será lo que se va a firmar y, por otro lado, una clave con la que realizar la firma. En el caso de utilizar un algoritmo de firma simétrica, será necesario que la clave la conozcan ambas partes de la comunicación para que una pueda verificar que la firma de la otra parte es correcta. Sin embargo, si se utiliza firma asimétrica, la parte firmante utilizará su clave privada (que es secreta) para que el destinatario pueda verificarla con la clave pública que recibió anteriormente.
En el caso de OAuth, el algoritmo simétrico soportado es HMAC-SHA1 mientras que el asimétrico es RSA-SHA1. En ambos casos, la cadena (el mensaje) que se firma se calcula de la misma forma, que viene a ser la concatenación (por medio de '&') del método HTTP utilizado en la petición (GET, POST, PUT, DELETE...), la URI base normalizada y un listado de todos los parámetros enviados en la petición ordenados y normalizados.
Entre los parámetros no sólo se incluyen aquellos que van por GET o POST, sino también partes de la cabecera HTTP Authorization, que es a través de la que se suelen enviar los parámetros de OAuth (aunque también se pueden añadir en la URL o en el cuerpo de la petición).
Vamos a verlo con un ejemplo. Imaginad la siguiente petición HTTP:
POST /recurso.html?param_GET=value1 HTTP/1.1 Host: example.com:443 Content-Length: 17 param_POST=value2
Antes de generar la cadena, tenemos que añadirle los parámetros OAuth que servirán para identificar esta petición. Dichos parámetros son:
- oauth_consumer_key: el consumer key asociado al cliente.
- oauth_nonce: un token de petición que será único (en combinación con el timestamp, consumer_key y token).
- oauth_signature_method: método de firma utilizado (HMAC-SHA1, RSA-SHA1 ó PLAINTEXT).
- oauth_timestamp: Unix timestamp del momento de la petición.
- oauth_token: access token del usuario (del resource owner).
- oauth_version: versión de OAuth. Lo más normal es que sea "1.0"
Ahora sí, la cadena resultante será (con valores de ejemplo para los parámetros anteriores):
POST&https%3A%2F%2Fexample.com%2Frecurso.html&oauth_consumer_key%3Dg1S1C08SXq2j%26oauth_nonce%3DT45y1iVuU56v%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1314969840%26oauth_token%3D1KbuMvTOPSA3%26oauth_version%3D1.0%26param_GET%3Dvalue1%26param_POST%3Dvalue2
Ahora aplicamos el algoritmo de firma que hayamos seleccionado (en el ejemplo HMAC-SHA1). En este caso, la clave se construye concatenando (&) el consumer secret y el access secret: Cj6mkF3ug1Ac&eAPJQ9g8xh2B. De manera que el resultado de la firma es (en base64):
N+T8THCg9CHknmt50UNTPZE3ZAk=
Al final, la petición quedaría de la siguiente manera:
POST /recurso.html?param_GET=value1 HTTP/1.1 Host: example.com:443 Authorization: OAuth realm="https://example.com/recurso.html", oauth_consumer_key="g1S1C08SXq2j", oauth_token="1KbuMvTOPSA3", oauth_nonce="T45y1iVuU56v", oauth_timestamp="1314969840", oauth_signature_method="HMAC-SHA1", oauth_version="1.0", oauth_signature="N%2BT8THCg9CHknmt50UNTPZE3ZAk%3D" Content-Length: 17 param_POST=value2
De este modo, en la petición se recoge desde qué aplicación se está accediendo (consumer key y consumer secret) y en nombre de qué usuario (access token y access secret). Además se provee de integridad en la petición por el simple hecho de ir firmada y de un mecanismo contra ataques de replay (reenvío de peticiones) por medio del nonce y el timestamp.
En el caso de RSA-SHA1, se utiliza el algoritmo RSASSA-PKCS1-v1_5:
oauth_signature = RSASSA-PKCS1-v1_5 (K, M)
siendo M la cadena que hemos creado antes y K la clave RSA privada del cliente.
El caso de PLAINTEXT es diferente debido a que no se llega a firmar ninguna cadena. En este caso, el valor del parámetros oauth_signature se construye como la concatencación (&) consumer secret y el access secret, que se envían en texto plano.
Como podréis imaginaros, este mecanismo sólo es recomendable en el caso de utilizar un canal seguro como pueden ser SSL o TLS. De no ser así (o si se llevara a cabo un ataque Man-in-the-Middle), se podrían suplantar las identidades del cliente y del usuario ante el servidor; es decir, se podría acceder a los recursos del usuario en nombre del cliente.
Si queréis ver cómo funciona todo esto de un modo más práctico, os recomiendo el siguiente enlace:
http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/
¡Hasta la próxima entrada!
