Antes de explicar que es el OAuth 2.0, OpenID Connect y Json Web Tokens tenemos que entender la situación de las aplicaciones modernas (los siguientes son los escenarios más comunes, pero existen más).
- Las aplicaciones web se comunican con APIs web.
- Las aplicaciones nativas se comunican con APIs web
- Las APIs web se comunican con otras APIs web
Todos los escenarios tienen la necesidad de proteger sus recursos (los recursos pueden ser páginas web, archivos, alguna funcionalidad del sistema, etc.), de esta idea nacen varios estándares como OAuth2, WS-Fed, SAML 2.0, OpenID Connect etc. El estandar mas implementado es el SAML 2.0.
Normalmente el diseño de estas arquitecturas divide en dos los aspectos de seguridad Autenticación y Autorización.
Autenticación
La autenticación se puede deinir como la necesidad de saber la identidad del usuario, por lo regular estas aplicaciones administran los datos del usuario a su nombre(Nombre, Email, Teléfono, etc. ).
Autorización
La autorización se puede definir como identificar si alguna aplicación o usuario tiene permisos para el recurso que está solicitando.
Ahora que ya conocemos un poco de más de autenticación y autorización, hablamos sobre OAuth 2.0 y OpenID Connect, los dos son muy similares, de hecho, OpenID Connect es una extensión de OAuth 2.0 frecuentemente estos dos protocolos se combinan para obtener la información en un solo viaje al servicio de seguridad.
OAuth 2.0
Nace para facilitar el acceso seguro a APIs a través de HTTP, el estándar está enfocado en la autorización y no en la autentificación. El estándar define cuatro roles Resource Owner, Resource Server, Client (Cliente) y Authorization Server (servidor de autorización).
Resource Owner (propietario del recurso): Una entidad capaz de otorgar acceso a un recurso protegido. Cuando el propietario del recurso es una persona, se le denomina usuario final.
Resource Server (servidor de recursos): El servidor que aloja los recursos protegidos, capaz de aceptar y responder a solicitudes de recursos protegidos utilizando tokens de acceso.
Client (Cliente): Una aplicación que realiza solicitudes de recursos protegidos en nombre del propietario del recurso y con su autorización.
Authorization Server (servidor de autorización): El servidor que emite tokens de acceso al cliente después de autenticar al propietario del recurso y obtener la autorización.
La interacción de los roles se demuestra en la siguiente imagen.
- El cliente solicita autorización al propietario del recurso. La solicitud de autorización se puede realizar directamente al propietario del recurso, o preferentemente a través del servidor de autorización como intermediario.
- El cliente recibe una concesión de autorización, que es una credencial que representa la autorización del propietario del recurso. El tipo de concesión de autorización depende del método utilizado por el cliente para solicitar autorización y los tipos soportados por el servidor de autorización.
- El cliente solicita un token de acceso al autenticarse con el servidor de autorización y presentando la concesión de autorización.
- El servidor de autorización autentica al cliente, valida la concesión de autorización y si es válida, emite un token de acceso.
- El cliente solicita el recurso protegido y se autentica presentando el token de acceso.
- El servidor de recursos valida el token de acceso, si es válido, regresa el recurso solicitado.
OAuth 2.0 Flows
En la actualidad existen varios tipos de aplicaciones y necesidades para solventar estos escenarios OAuth 2.0 define los siguientes flujos (son los más comunes) para obtener el token de acceso.
Authorization Code (Authorization Code Grant Type)
El código de autorización se obtiene utilizando un servidor de autorización como intermediario entre el cliente y el propietario del recurso, es el flujo más seguro ya que el cliente tiene que guardar un secreto.
Implicit (Implicit Flow Grant Type)
Este flujo es menos seguro que el anterior está enfocada para los clientes que no pueden guardar secretos.
Resource Owner Password Credentials (Password Grant Type)
Se envían las credenciales de usuario y contraseña directamente al servidor de autorización, este tipo de flujo está pensado más para aplicaciones legacy y se debería de evitar usar en aplicaciones modernas que soportan otros flujos.
Client Credentials Flow (Client Credentials Grant Type)
Este flujo está pensado en un escenario no hay usuarios involucrados en la operación. Es una comunicación máquina a máquina, la aplicación se identifica ante el servidor de autorización proporcionando su Id de Aplicación y su Clave Secreta.
OpenID Connect
Es una extensión de OAuth pensado para la autenticación, en el token de acceso se le agrega el id_token. Este token proporciona información sobre el usuario autentificado, con el podemos obtener la información del usuario autentificado.
Json Web Tokens (JWT)
Es un estándar abierto que define una forma compacta y autónoma de transmitir información de forma segura entre las partes como un objeto JSON. Esta información se puede verificar y confiar porque está firmada digitalmente.
El token esta codificado en Base64Url y su estructura se compone de tres partes separadas por un punto.
La Cabecera (Header) : El encabezado generalmente consta de dos partes: el tipo de token, que es JWT, y el algoritmo de firma que se utiliza, como HMAC SHA256 o RSA.
El Cuerpo (Payload): La segunda parte del token es la carga útil, que contiene los claims. Los Claims son declaraciones sobre una entidad (normalmente, el usuario) y datos adicionales.
La firma (Signature): Esta parte se utiliza para verificar que el mensaje no ha sido modificado durante el envío y, en el caso de los tokens que han sido firmados con una clave privada, se puede verificar además que el emisor del token es quien dice ser.
Enlaces
Commentarios