Los sistemas de autenticación son la columna vertebral de muchos sitios web. Permiten a los usuarios iniciar sesión en su sitio y preservar los datos entre las visitas. Es crucial para ofrecer una experiencia de usuario sólida que recompense a sus usuarios por proporcionar sus datos. Las autenticaciones suelen dar acceso a datos personales privados que, de hacerse públicos, podrían perjudicar a su usuario. Para evitar esto, los protocolos de autenticación fueron creados para asegurar las solicitudes mientras se permite a los usuarios iniciar sesión de forma segura en su sistema desde cualquier entorno.

Autentificación SSL básica

La autentificación básica es la forma más simple de autenticación web. Utiliza cabeceras HTTP estándar en lugar de soluciones más complicadas que dependen de cookies, identificadores de sesión y páginas de acceso. Hay muy poca seguridad en el sistema de autenticación básica. Las credenciales se transmiten sólo con la codificación Base64 y no se cifran ni se hacen hash. Debido a las inseguridades arraigadas en el sistema, estas solicitudes se realizan con mayor frecuencia a través de HTTPS.

La información de autorización debe compilarse en el siguiente formato e incluirse en la cabecera:

Formato:

<!--Authorization: Basic -->

Los detalles completos sobre el protocolo de autenticación básica pueden encontrarse aquí: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth funciona de forma similar a la autenticación básica SSL con la excepción de que la contraseña se cifra utilizando un hash unidireccional. Utiliza el hash criptográfico MD5 con un nonce (un valor generado por el servidor que evita los ataques de repetición).

El flujo típico de una solicitud de Digest Auth es :

1. Un usuario navega a una página que requiere que el usuario se autentique.
2. El servidor responde con un mensaje 401 que significa que un usuario no está actualmente autorizado a acceder al contenido. En la respuesta también incluye el nonce que se utilizará durante la autorización para evitar ataques de repetición,
3. El sitio muestra entonces una interfaz de autenticación con el fin de recoger los detalles requeridos( nombre de usuario y contraseña )
4. Los detalles proporcionados se reenvían al servidor con una cabecera de autenticación incluida en la solicitud que tiene un código de respuesta.
5. El servidor verificará las credenciales proporcionadas y aceptará la autenticación o devolverá un mensaje 401 si las credenciales son incorrectas, lo que hará que el usuario tenga que volver a acceder a la interfaz de autenticación.

Puede encontrar todos los detalles sobre el protocolo Digest Auth aquí: https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

El protocolo OAuth 1.0 se basa en tener un secreto compartido entre el servidor y el sitio. Este secreto compartido se utiliza para generar una firma que se incluye en la solicitud. La firma generada se utiliza para verificar en el lado del servidor la validez de la solicitud de autenticación. El proceso para autorizar al usuario se maneja generalmente en tres pasos ( OAuth de 3 patas):

1. El sitio obtiene el Token de Solicitud.
2. El usuario autoriza el Token de Solicitud.
3. El sitio intercambia el Token de Solicitud por el Token de Acceso.

El proceso de completar una solicitud OAuth de 3 patas se manejará generalmente como sigue:

1. El sitio enviará una solicitud firmada para el Request Token. Esta solicitud debe contener los siguientes parámetros:

   1. oauth_consumer_key
   2. oauth_timestamp
   3. oauth_nonce
   4. oauth_signature
   5. oauth_signature_method
   6. oauth_version
   7. oauth_callback

Esta petición será validada en el servidor y si es validada devolverá el token de la petición en el siguiente formato:

1. oauth_token
2. oauth_token_secret
3. y cualquier otro parámetro adicional devuelto por su servidor.
4. El siguiente paso después de recuperar el token de solicitud es pedir al usuario que introduzca sus credenciales de acceso. Estas se formatean en una firma con el token de solicitud oauth_token y se envían con una solicitud de vuelta al servidor para su validación. Tras la validación exitosa de esta solicitud, el servidor devolverá lo siguiente:
5. oauth_token
6. oauth_verifier

Estos se utilizarán en el siguiente paso para recuperar un token de acceso.

1. El paso final es el intercambio de los detalles recuperados del paso 2 por un token de acceso, que se utilizará para acceder a los recursos del servidor. Para intercambiar su token de solicitud por un token de acceso, puedes hacer una petición al servidor con la siguiente solicitud firmada
2. oauth_token -retornada del paso 2
3. oauth_consumer_key
4. oauth_nonce
5. oauth_signature
6. oauth_signature_method
7. oauth_version
8. oauth_verifier -devuelto desde el paso 2

Esto te devolverá un token de acceso que deberás utilizar junto con tu secreto para poder realizar peticiones de información al servidor.

Puedes encontrar todos los detalles sobre el protocolo OAuth 1.0 aquí: https://tools.ietf.org/html/rfc5849

OAuth 2.0

Es similar al protocolo OAuth 1.0, se basa en un id de cliente y un secreto para poder formatear la petición, pero simplifica gran parte del complicado proceso de firma que es inherente al sistema OAuth 1.0. El proceso para autorizar a un usuario utilizando el protocolo OAuth 2.0 es el siguiente:

1. El usuario es dirigido al servicio para su autorización con los siguientes detalles incluidos en la URL de autorización:

   1. client_id
   2. redirect_uri
   3. response_type
   4. scope

2. El usuario se autentifica con el servicio y concede a la aplicación acceso a sus datos. Si la autenticación es satisfactoria, el usuario es redirigido de nuevo a la redirect_uri con los siguientes parámetros:

   1. código
   2. estado

3. El código devuelto en el paso 2 es utilizado por la aplicación para hacer una solicitud de un token de acceso. En esta solicitud debe incluirse:

   1. client_id
   2. client_secret
   3. code
   4. redirect_uri
   5. grant_type – Debe establecerse como «authorization_code»

El servidor verificará estos detalles y luego devolverá un token de acceso con un tiempo de expiración si son válidos. Generalmente se devuelven en el siguiente formato:

1. access_token
2. expires_in
3. refresh_token

Puedes encontrar todos los detalles sobre el protocolo OAuth 2.0 aquí: http://oauth.net/2/

Los protocolos de autenticación te permiten asegurar tus datos con distintos niveles de seguridad. Dependiendo de los datos a los que se acceda y del nivel de seguridad que desee, la implementación de uno de los protocolos anteriores le permite estar seguro de que sus datos están seguros y que sólo acceden a ellos los usuarios que tienen permiso para acceder a su sistema.