¿Qué es OAuth?

Supongamos que un usuario va a utilizar una app para llevar adelante una acción en el servidor A,
lo que significa que va a acceder a la API del servidor A mediante esta app.
Esta aplicación necesitará haber sido autorizada para
poder llevar adelante acciones en el servidor "A".

Dicha aplicación podría necesitar llevar a cabo acciones en nombre de un usuario especifico necesitando autenticarse como tal.

por lo tanto no solo el acceso a las APIs necesita control, también encontramos el inconveniente del intercambio de contraseñas.
Surge asi el problema de la delegación de la autorización para acceder a los datos.

OAuth es una herramienta que nos permite otorgar dicha autorización mediante la emisión de un Token JWT
sin tener que comunicar a la aplicación el nombre de usuario ni la contraseña.
En resumen, el usuario mantiene un control absoluto sobre sus datos.
Esto permite un acceso limitado (scopes) a las aplicaciones sobre los datos de los usuarios.

¿Qué es un token JWT?

En la práctica, se trata de una cadena de texto que tiene tres partes codificadas en Base64,
cada una de ellas separadas por un punto, como la que vemos en la imagen siguiente:

Ejemplo:

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Podemos utilizar un debugger online para decodificar ese token y visualizar su contenido.

Donde:

• Header
  Encabezado dónde se indica, al menos, el algoritmo y el tipo de token, que en el caso del ejemplo anterior era el algoritmo HS256 y un token JWT.

• Payload
  Donde aparecen los datos de usuario y privilegios, así como toda la información que queramos añadir, todos los datos que creamos convenientes.

• Signature
  Una firma que nos permite verificar si el token es válido,y aquí es donde radica el quid de la cuestión,ya que si estamos tratando de hacer una comunicación
  segura entre partes y hemos visto que podemos coger cualquier token y ver su contenido con una herramienta sencilla, ¿dónde reside entonces la potencia de todo esto?, respuesta "en la firma del token JWT".

Firma de un token JWT

La firma se construye de tal forma que vamos a poder verificar que el remitente es quien dice ser, y que el mensaje no se ha modificado por el camino.

Codificación en Base64 de header.
Codificación en Base64 de payload.
Un secreto, establecido por la aplicación cifrado junto con el header y el payload.

De esta forma, si alguien modifica el token por el camino, por ejemplo, inyectando alguna credencial o algún dato malicioso, entonces podríamos verificar que la comprobación de la firma no es correcta, por lo que no podemos confiar en el token recibido y deberíamos denegar la solicitud de recursos que nos haya realizado, ya sea para obtener datos o modificarlos.
Si lo que estamos requiriendo es que el usuario esté autenticado,
Deberíamos denegar esa petición, por lo que siempre que trabajemos con JWT deberíamos verificar con esa firma si el token es válido o no lo es.

Entidades que participan en el proceso

Dentro de OAuth 2.0 encontramos diferentes entidades que van a participar en el proceso:

• Dueño del recurso (Owner).
• Cliente (Client).
• Servidor de recursos protegidos (Resource Server).

• Servidor de autorización (Authorization Server).

• Dueño del recurso

  El propietario del recurso es el usuario que da autorización a una determinada aplicación para acceder a su cuenta y poder hacer algunas cosas en su nombre.
  El conjunto de cosas que puede hacer la aplicación en su nombre se denomina alcance, y podría ser, por ejemplo, solamente acceso de lectura y no poder crear ningún tipo de elemento de ningún nuevo recurso en su nombre.
  Un ejemplo de esto son los widgets que nos permiten integrar Twitter o Facebook dentro de una web, pero que no nos permiten generar nuevo contenido.
  Se le llama dueño del recurso porque, si bien la API no es suya, los datos que maneja sí lo son.

• Cliente

  El cliente sería la aplicación que desea acceder a esa cuenta de usuario.
  Antes de que pueda hacerlo debe ser autorizada por el usuario, y dicha autorización debe ser validada por la API.
  El cliente puede ser una aplicación web, una aplicación móvil, una aplicación de escritorio, una aplicación para smartTV, un dispositivo de IoT, otra API que consumiera de esta API, etcétera.

• Servidor de autorización

  El servidor de autorización es el responsable de gestionar las peticiones de autorización.
  Verifica la identidad de los usuarios y emite una serie de tokens de acceso a la aplicación cliente.
  En muchas ocasiones, podemos implementar el servidor de autorización nosotros mismos, o podemos delegar en un tercero (Facebook, Twitter, Github, Google, etcétera) y tener solamente un servidor de recursos. Incluso podemos desarrollar el cliente y delegar la autorización en un tercero.

• Servidor de recursos

  El servidor de recursos será la API propiamente, es decir, el servidor que aloja el recurso protegido al cual queremos acceder.
  Puede que también forme parte de la misma aplicación que el propio servidor de autenticación.

Tipos de otorgamiento de autorización segun casos de uso

• "Soy un usuario. Tengo una aplicacion y quiero poder interactuar con mis recursos a través de la API."
  Este caso corresponde el tipo client credential

• "Soy un partner del producto y quiero interactuar en nombre de distintas cuentas a través de la API".
  Este caso corresponde el tipo authorization code