Prodriguezchi TFM0123 Memoria
Prodriguezchi TFM0123 Memoria
Prodriguezchi TFM0123 Memoria
Abstract
i
Índice
1. Introducción 1
1.1. Contexto y justificación del Trabajo 1
1.2. Objetivos del Trabajo 2
1.3. Impacto en sostenibilidad, ético-social y de diversidad 2
1.4. Enfoque y método seguido 3
1.5. Planificación del Trabajo 4
1.6. Breve sumario de productos obtenidos 9
1.7. Breve descripción de los otros capítulos de la memoria 9
2. Marco teórico 10
2.1 Microservicios 10
2.1.1 Aplicaciones Monolíticas 10
2.1.2 Arquitectura de Microservicios 11
2.1.3 Aplicación Monolítica vs Arquitectura de Microservicios 13
2.2 Protocolo OAuth 14
2.2.1 OAuth 1.0 15
2.2.1.1 Flujo de autorización 16
2.2.2 OAuth 2.0 17
2.2.2.1 Componentes 17
2.2.2.2 Tipos de Concesión de Autorización 18
2.2.2.3 Tokens 19
2.2.3 Flujo de autorización abstracto 20
2.2.4 Ventajas del uso de OAuth 2.0 21
2.3 Documento RFC-6819 21
2.3.1 Concepto 21
2.3.2 Flujo de autorización OAuth 2.0 por códigos de autorización 21
2.3.3 Características de los despliegues 23
2.3.4 Supuestos de los ataques 23
2.3.5 Modelo de Amenazas y Recomendaciones 24
2.3.5.1 Dirigidas al Cliente 24
2.3.5.2 Endpoint de Autorización 27
2.3.5.3 Endpoint de Token 28
2.3.5.4 Flujo: Obteniendo Autorización 30
2.3.5.4.1 Concesión: Código de Autorización 30
2.3.5.4.2 Concesión: Implícita 33
2.3.5.4.3 Concesión: Credenciales de contraseña del propietario del recurso 35
2.3.5.4.4 Concesión: Credenciales del cliente 37
2.3.5.5 Flujo: Actualizando un token de acceso 38
2.3.5.6 Flujo: Accediendo a un recurso protegido 39
3. Desarrollo e Implementación 41
3.1 Patrones en Arquitecturas de Microservicios 41
3.2 Definiendo una arquitectura de microservicios 42
3.3 Diseño de la arquitectura de microservicios 44
ii
3.4 Desarrollo de la arquitectura de microservicios 46
3.4.1 Desarrollo del API Gateway 46
3.4.2 Desarrollo del Servidor de Autorización 47
3.4.3 Desarrollo de los Microservicios 49
3.5 Ejecución de la arquitectura de microservicios 50
4. Seguridad en el entorno de microservicios usando el protocolo OAuth 54
4.1 Conceptos básicos de Keycloak 54
4.2 Seguridad de los clientes 55
4.2.1 Entropía en los secretos del cliente 56
4.2.2 Clientes públicos y de baja confianza 57
4.2.3 Secretos específicos para despliegues específicos 60
4.3 Seguridad de los usuarios 61
4.3.1 Número de intentos de acceso permitidos 61
5. Conclusiones y trabajos futuros 63
6. Glosario 66
7. Bibliografía 67
8. Anexos 68
Anexo 1: Configuración básica del Servidor de Autorización usando Keycloak 68
iii
Lista de figuras
Figura 1: Cronograma de Actividades 8
Figura 2: Arquitectura monolítica 11
Figura 3: Arquitectura de Microservicios 11
Figura 4: Diferencia entre Arquitectura Monolítica y Microservicios. 14
Figura 5: Roles de delegación de identidad. 15
Figura 6: Flujo de Autorización de OAuth 1.0. 16
Figura 7: Componentes OAuth 2.0. 17
Figura 8: Flujo de código de Autorización OAuth 2.0 18
Figura 9: Flujo de Concesión Implícita. 18
Figura 10: Flujo de concesión por credenciales de contraseña del propietario del recurso. 19
Figura 11: Flujo de concesión por credenciales del cliente. 19
Figura 12: OAuth 2.0 - Flujo de Autorización básico 20
Figura 13: Flujo de Autorización Completo OAuth 2.0. 22
Figura 14: Flujo y datos usados por el cliente en un entorno OAuth 2.0. 25
Figura 15: Datos usados por el endpoint de autorización en un flujo OAuth 2.0. 27
Figura 16: Flujo y datos usados por el endpoint de token en un flujo OAuth 2.0. 29
Figura 17: Diagrama de concesión por código de Autorización. 31
Figura 18: Diagrama de concesión Implícita. 34
Figura 19: Diagrama de Concesión por Credenciales de contraseña del Propietario del Recurso. 36
Figura 20: Diagrama de concesión por credenciales del cliente. 37
Figura 21: Flujo de actualización de un token de acceso. 38
Figura 22: Flujo de acceso a un recurso protegido. 39
Figura 23: Lenguaje de patrones de arquitecturas de microservicios. 41
Figura 24: Puerta de enlace API (API Gateway). 42
Figura 25: API Gateway como un cliente OAuth 2.0. 43
Figura 26: API Gateway como un servidor de recursos OAuth 2.0. 43
Figura 27: Diagrama de secuencia de una arquitectura de microservicios con un API Gateway como un cliente
OAuth. 44
Figura 28: Funcionamiento de los componentes a desarrollar. 45
Figura 29: Servidor de Autorización con Keycloak. 51
Figura 30: Ejecución de la arquitectura de microservicios hacia el microservicio 1 52
Figura 31: Ejecución de la arquitectura de microservicios hacia el microservicio 2 52
Figura 32: Ejecución de la arquitectura de microservicios hacia el microservicio 3 52
Figura 33: Ejecución conjunta de toda la infraestructura de OAuth2.0 y microservicios 53
Figura 34: Registro de clientes en servidor Keycloak 55
Figura 35: Tipos de clientes en servidor Keycloak 56
Figura 36: Secretos del cliente de Keycloak 56
Figura 37: Nivel de entropía del secreto del cliente 57
Figura 38: API Gateway como un cliente público 57
Figura 39: Solicitud de acceso para el API Gateway como cliente público 58
Figura 40: Acceso a recursos protegidos por el microservicio 2 usando un token de acceso 59
Figura 41: Solicitud de acceso denegado por falta del secreto del cliente 59
Figura 42: Registro de un cliente para el API Gateway para Insomnia 60
Figura 43: Deshabilitado de un cliente específico 61
Figura 44: Solicitud de autorización rechaza por un cliente deshabilitado 61
Figura 45: Configuración de seguridad contra ataques de fuerza bruta 62
iv
Lista de tablas
Tabla 1: Cronograma de Actividades 8
Tabla 2: Beneficios de ambas Arquitecturas 13
Tabla 3: Inconvenientes de ambas Arquitecturas 14
Tabla 4: Modelo de amenazas y recomendaciones para el Cliente OAuth2.0 27
Tabla 5: Modelo de amenazas y recomendaciones para el endpoint de autorización OAuth2.0 28
Tabla 6: Modelo de amenazas y recomendaciones para el endpoint de token OAuth2.0 30
Tabla 7: Modelo de amenazas y recomendaciones para la concesión por código de autorización OAuth2.0. 33
Tabla 8: Modelo de amenazas y recomendaciones para la concesión Implícita OAuth2.0. 35
Tabla 9: Modelo de amenazas y recomendaciones para la concesión por contraseña del propietario del recurso
OAuth2.0. 37
Tabla 10: Modelo de amenazas y recomendaciones para el flujo de actualización de tokens de acceso
OAuth2.0. 39
Tabla 11: Modelo de amenazas y recomendaciones para el flujo de acceso a recursos protegidos OAuth2.0. 40
Tabla 12: Definición de componentes a desarrollar. 45
Tabla 13: Tecnologías usadas para el desarrollo del API Gateway 46
Tabla 14: Tecnologías usadas para el desarrollo del Servidor de Autorización 48
Tabla 15: Tecnologías usadas para el desarrollo de los Microservicios 49
Tabla 16: Compilación y ejecución de componentes. 50
Tabla 17: Características del despliegue de los componentes 51
Tabla 18: Consideraciones de seguridad implementadas acorde al RFC 6819 64
Tabla 19: Tabla de cobertura de objetivos 65
v
1. Introducción
Cuando se pretende desarrollar una aplicación de lado del servidor, tenemos dos
grandes paradigmas que últimamente han dominado el desarrollo moderno
actual: Las Arquitecturas Monolítica y las de Microservicios. Sin embargo, la
evolución de las arquitecturas de software ha sido impulsada por la necesidad
de lograr una mejor separación de funcionalidades (Blinowski, Ojdowska, &
Przybylek, 2022).
Por otra parte, el uso de OAuth nos permite obtener autorización para el acceso
a un recurso desde un servicio; por tal motivo, es un protocolo válido de
autenticación y autorización que se puede aplicar a microservicios (Triartono,
Muldina Negara, & Sussi, 2019). Mientras OAuth 1.0 es un protocolo
estandarizado que define el modelo teórico de autenticación y autorización,
OAuth 2.0 es un framework que nace a partir de la recopilación de buenas
prácticas en la aplicación del protocolo y que permite, a aplicaciones de terceros,
obtener acceso limitado a un recurso protegido de un servicio HTTP (OAuth
Working Group, 2012).
1
De la misma manera, la aplicación del protocolo de OAuth trae consigo retos de
seguridad a enfrentar debido a debilidades presentes en la propia naturaleza del
mismo. Sin embargo, gracias a un conjunto de consideraciones adicionales a
tener presentes el momento de implementar el protocolo, podemos mitigar las
dichas amenazas. Este conjunto de amenazas y consideraciones ha sido
recopilado en el documento RFC 6819 (RFC-6819, 2013).
2
Dimensión de diversidad de género y derechos humanos: el presente trabajo
no tiene ningún impacto referente a aspectos de diversidad de género y derechos
humanos ya que no viola ni mejora ninguno de sus lineamientos al ser
únicamente de carácter técnico.
Microservicios
Protocolo OAuth
3
base, sus ventajas y desventajas y en que nos aportan en cuanto a la
autenticación y autorización de microservicios. Una parte importante para
introducirnos en el mundo del protocolo.
Empezaremos por describir las tareas a realizar acorde a las fases descritas en
el apartado anterior:
• Definición de la temática:
Análisis previo de la documentación: en esta primera parte se analiza
brevemente el contexto del trabajo con el fin de focalizar el tema acorde
a las necesidades.
• Definición del plan de trabajo:
Introducción: se redacta una breve descripción inicial que introducirá al
tema.
4
Contexto y justificación del trabajo: se define un contexto del trabajo
procedente del estado del arte y se justifican los propósitos y razones del
presente trabajo.
Objetivos del trabajo: se define el objetivo principal del trabajo y, a su vez,
se enumeran los objetivos específicos que se deben satisfacer para
cumplir con el objetivo general.
Impacto en sostenibilidad, ético-social y diversidad: se describen los
recursos a utilizar, costes en ámbitos en el momento de despliegue y
durante la vida del producto y su impacto ético-social y ambiental.
Enfoque y método seguido: se describen el enfoque que va a seguir el
trabajo y el método a usar mediante las fases a seguir durante el trabajo.
Planificación del trabajo: se enumeran las tareas a realizar y se coloca un
cronograma a seguir para la ejecución de cada tarea mediante un
diagrama de Gantt.
Breve sumario de productos obtenidos: se enumeran los productos que
serán el resultado al final de cada fase.
Breve descripción de otros capítulos de la memoria: se enumeran y
definen los capítulos que contiene el trabajo de manera breve.
• Microservicios:
Aplicaciones monolíticas: se define el concepto y características de las
aplicaciones monolíticas.
Arquitectura de Microservicios: se define el concepto y las características
comunes de las arquitecturas de microservicios.
Aplicación monolítica vs Microservicios: se presentan las principales
diferencias entre ambos enfoques haciendo especial énfasis en las
ventajas y desventajas de cada uno.
• Protocolo OAuth:
OAuth 1.0: se define el protocolo OAuth 1.0, su funcionamiento y
principales características.
Flujo de Autorización: se define y explica el flujo de autorización que sigue
el protocolo para la concesión de acceso.
OAuth 2.0: se plantea una definición formal del framework OAuth 2.0 y
sus características.
Componentes: se identifica y enumera los actores y componentes
necesarios para la aplicación de un flujo de autorización con el protocolo.
Tipos de concesión de autorización: se identifica y enumera los distintos
tipos de flujos que los componentes pueden seguir en OAuth 2.0 para
interactuar entre sí.
Tokens: se define el concepto de token y se identifica y enumera los
distintos tipos de tokens que existen en OAuth 2.0.
Flujo de autorización abstracto: definición de todas las partes y pasos que
involucran un flujo de autorización con OAuth2.0.
Ventajas del uso de OAuth 2.0: se describen las ventajas del uso de este
protocolo de autorización en un ambiente de microservicios.
• Documento RFC-6819:
Concepto: se plantea una descripción del documento y sus puntos
principales.
Flujo de autorización OAuth2.0 por códigos de autorización: se explica y
describe un flujo completo de autorización OAuth 2.0 bajo el tipo de
concesión por códigos de autorización con el objetivo de identificar los
5
puntos clave donde se enfocan las amenazas y consideraciones de
seguridad.
Características de los despliegues: para describir los modelos de
amenazas y consideraciones de seguridad de OAuth 2.0, es necesario
definir las características que debe tener un despliegue OAuth 2.0 para
seguir estos modelos.
Supuestos de los ataques: se definen los supuestos a considerar para que
el despliegue del protocolo sea susceptible de sufrir dichas amenazas.
Modelos de amenazas y recomendaciones: se clasifica y describe las
amenazas que pueden afectar al protocolo OAuth; así como un conjunto
de consideraciones de seguridad para mitigarlas acorde a lo expuesto en
el documento RFC 6819.
• Desarrollo e implementación:
Patrones de arquitecturas de microservicios: se describe un conjunto de
patrones que incluyen los componentes y arquitecturas que puede tener
un entorno de microservicios.
Definiendo una arquitectura de microservicios: se definen los
requerimientos que debe tener la arquitectura de microservicios a
desarrollar y como se integran con OAuth 2.0.
Diseño de la arquitectura de microservicios: se describe el diseño y
modelado de cada uno de los componentes que contendrá el entorno, así
como su funcionamiento general.
Desarrollo de la arquitectura de microservicios: se desarrolla cada
componente del entorno de pruebas describiendo cada proceso realizado.
Ejecución de la arquitectura de microservicios: se describe y aplica el
proceso de implementación y montaje del entorno de microservicios
desarrollado.
• Seguridad en el entorno de microservicios con OAuth 2.0:
Conceptos básicos de Keycloak: se enumeran y definen un conjunto de
conceptos para entender el funcionamiento del servidor de autorización
implementado con Keycloak.
Seguridad de los clientes: se identifican y realizan las configuraciones
necesarias para mitigar las vulnerabilidades del protocolo acorde al
documento RFC-6819 referente a los clientes OAuth.
Seguridad de los usuarios: se identifican y realizan las configuraciones
necesarias para mitigar las vulnerabilidades del protocolo acorde al
documento RFC-6819 referente a los propietarios de los recursos
(usuarios) OAuth.
• Conclusiones y trabajos futuros:
Conclusiones: se enumeran las conclusiones resultado del trabajo y sus
planteamientos.
Trabajos futuros: se plantean los posibles complementos al trabajo que
ayudarán a reforzar el tema para ser propuestos como futuros trabajos.
• Video de presentación:
Planificación: se planifica el contenido, tiempos y estructura del video de
presentación del trabajo.
Producción: grabación y edición del video de presentación del trabajo.
Entrega: Entrega del video de presentación.
6
• Defensa del trabajo final de Máster
Defensa final: se defiende el trabajo final del Máster ante el jurado
seleccionado.
28 Flujo de autorización OAuth 2.0 por códigos de autorización 1 día 28/10/2022 28/10/2022
29 Características de los despliegues 1 día 29/10/2022 29/10/2022
7
35 Diseño de una arquitectura de microservicios 2 días 8/11/2022 9/11/2022
8
1.6. Breve sumario de productos obtenidos
9
2. Marco teórico
2.1 Microservicios
10
En una aplicación monolítica, muchos componentes se combinan en una sola
aplicación larga donde usualmente un cambio en un componente, demanda
rescribir otro componente y compilar todo el conjunto para ser ejecutado sin
tomar en cuenta que componente realmente usa el usuario (Awati & Wigmore,
2022).
La idea de un microservicio es aislar una funcionalidad del resto para que sea
tratada de manera independiente. Sin embargo, para abarcar con un negocio,
que usualmente contiene varias funcionalidades, es necesario de un conjunto de
microservicios operando entre sí.
11
servicios como componentes, esto nos permitirá desplegarlos
independientemente y mantenerlos como una interface explícita, es decir
mantener el principio de encapsulamiento a nivel de servicio.
• Organizado sobre capacidades del negocio: una tradicional
organización es la división de equipos de trabajo acorde a su tecnología
como: UI, server-side, especialistas en bases de datos, etc. Sin embargo,
esta organización tiene un problema descrito en estas simples palabras:
“lógica por todos lados”. En una arquitectura de microservicios, los
servicios se organizan acorde a su lógica de negocio como:
almacenamiento, usuarios, productos, etc.
• Productos, no proyectos: muchos esfuerzos en el desarrollo de
aplicaciones siguen el modelo de proyecto: donde el objetivo es entregar
una pieza de software que sea considerada completa. Sin embargo, en la
arquitectura de microservicios se prefiere la noción de que un equipo debe
ser el dueño de un producto durante su tiempo de vida.
• Puntos finales (endpoints) inteligentes y tuberías tontas: las
aplicaciones construidas mediante microservicios pretenden estar lo más
desacopladas y cohesionadas como sea posible, es decir son dueñas de
su propia lógica de dominio y actúan como filtros: reciben una petición,
aplican la lógica adecuada y producen una respuesta. Su comunicación
se basa en protocolos simples de red como peticiones HTTP o en
mensajería liviana y asíncrona como RabbitMQ o ZeroMQ.
• Gobierno descentralizado: uno de los clásicos problemas de las
aplicaciones monolíticas es la tendencia de estandarizar la tecnología de
las plataformas; es decir, usar un lenguaje de programación y una base
de datos común entre todas las funcionalidades del sistema. En la
arquitectura de microservicios, cada servicio puede construirse de manera
independiente, escogiendo la tecnología adecuada para cada
funcionalidad.
• Manejo de datos descentralizado: mientras que las aplicaciones
monolíticas tienden a unificar las decisiones de almacenamiento de datos;
es decir, persistir los datos en una única base de datos. En una
arquitectura de microservicios se descentraliza las decisiones del
almacenamiento de datos donde cada servicio tiene la capacidad de
administrar su propia base de datos, tanto en tecnología como en
esquema, pudiendo llegar a usar varias tecnologías de persistencia de
datos en un enfoque denominado “Persistencia políglota”.
• Automatización de infraestructuras: una de las características base en
arquitecturas de microservicios es la entrega continua y su precursor la
integración continua. Los equipos desarrollan varios servicios que hacen
uso de técnicas extensas de automatización de infraestructura. Uno de
los ejemplos es el uso de Amazon Web Services (AWS) que contienen un
conjunto de herramientas para automatizar y desplegar microservicios
con facilidad.
• Diseño para el fallo: una de las características más prominentes de la
arquitectura de microservicios es la capacidad y tolerancia al fallo.
Cualquier servicio puede fallar debido a una indisponibilidad; sin embargo,
el cliente debe responder a ello con la mayor gracia posible. A su vez, esta
característica introduce mayor complejidad de manejo debido a que los
12
equipos reflexionan constantemente sobre cómo los fallos de los servicios
afectan a la experiencia del usuario.
• Diseño evolutivo: los profesionales de los microservicios, por lo general,
provienen de un entorno de diseño evolutivo y ven la descomposición de
servicios como una herramienta más para permitir a los desarrolladores
de aplicaciones controlar los cambios en su aplicación, sin ralentizar el
cambio. Si se realiza el control de los cambios, con la actitud y las
herramientas adecuadas, éstos pueden ser frecuentes, rápidos y bien
controlados en el software.
13
El tamaño de la aplicación puede volver lento Probar microservicios en conjunto es mucho
el arranque de la misma más complejo
En este sentido, dependerá del equipo escoger el mejor enfoque para diseñar
la arquitectura de software que más se adapte a sus necesidades.
14
Imaginemos que eres el dueño de un API, pero no su directo consumidor; es
decir, puede haber un tercero que quiera consumir dichos recursos. Compartir
las credenciales no siempre es una buena práctica, ya que es otorgar un acceso
completo sin restricciones ni límites que será muy difícil controlar. Por ello, se
buscará usar un modelo de delegación de identidad; es decir, una forma de
delegar la identidad y su autorización de un servicio a otro.
En este contexto, se desarrolló el protocolo OAuth 1.0 como una buena base
para la delegación de identidad; sin embargo, dado que ha recibido múltiples
críticas acorde a su usabilidad y extensibilidad, el framework OAuth 2.0 fue
desarrollado en el año de 2012 (Siriwardena, 2014).
OAuth 1.0 empezó alrededor de noviembre de 2006; sin embargo, para abril de
2007 se conformó un grupo de Google con un pequeño conjunto de
implementadores con el propósito de escribir el protocolo abierto. Para Julio del
mismo año escribió el primer borrador de una especificación inicial y dicho grupo
fue abierto para que cualquiera pueda colaborar. Para el día 3 de octubre del
2007 el borrador final de OAuth Core 1.0 fue finalmente revelado (Hammer-
Lahav, 2007).
15
como una transición suave para que los servicios existentes soporten OAuth
(Hammer-Lahav, 2007).
El acceso se lo realiza mediante tokens en un flujo donde los mismos van siendo
compartidos entre las partes. Estos tokens son generados por el proveedor del
servicio y existen dos tipos distintos (OAuth Core, 2007):
16
2.2.2 OAuth 2.0
La mayor diferencia entre OAuth 1.0 y OAuth 2.0 es que OAuth 1.0 es un
protocolo estándar para la delegación de identidad, mientras que OAuth 2.0 es
un framework altamente extensible. OAuth es, de facto, un estándar para la
seguridad de API y es ampliamente usado por muchas plataformas en la web
(Siriwardena, 2014).
2.2.2.1 Componentes
17
2.2.2.2 Tipos de Concesión de Autorización
18
Credenciales de contraseña del propietario del recurso (resource owner
password credentials): las credenciales de contraseña del propietario de los
recursos (por ejemplo: usuario/contraseña) pueden ser usados directamente
como un método de autorización para obtener un token de acceso. Las
credenciales solo deben ser usadas si hay un alto grado de confianza entre el
propietario del recurso y el cliente. Exponer las credenciales sin un alto nivel de
confianza puede ocasionar que la cuenta quede expuesta en su totalidad, ya que
las credenciales otorgan acceso completo y carecen de límite o de control
estricto.
Figura 10: Flujo de concesión por credenciales de contraseña del propietario del recurso.
Fuente: RFC 6749
2.2.2.3 Tokens
Un token es una cadena de texto usada por OAuth para que el cliente realice
peticiones hacia otras partes. Sirve como una credencial que representa una
autorización. Un token usualmente tiene un alcance y un tiempo de expiración.
En OAuth 2.0 distinguimos dos tipos de tokens: de acceso (Access Token) y de
actualización (Refresh Token) definidos como:
19
representa una autorización concedida a un cliente. Un cliente sólo necesita un
token de acceso válido y vigente para realizar peticiones al servidor de recursos.
Así mismo, los tokens suelen tener uno o varios ámbitos (scope) que sirven
para limitar el acceso a la cuenta de un usuario. El ámbito define el alcance y el
límite que tiene un token sobre un nivel de acceso concedido (OAuth Working
Group, 2012).
Por otra parte, el flujo de autorización abstracto del protocolo OAuth 2.0 se
compone de los siguientes pasos (RFC-6749, 2012):
20
2.2.4 Ventajas del uso de OAuth 2.0
2.3.1 Concepto
21
Figura 13: Flujo de Autorización Completo OAuth 2.0.
Fuentes: https://docs.oracle.com/cd/E50612_01/doc.11122/oauth_guide/content/oauth_flows.html
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
22
18. Tiempo después de cierto periodo definido por la expiración del token, el
cliente nuevamente solicita acceder al recurso; sin embargo, su token de
acceso fue rechazado.
19. El cliente solicita un nuevo token de acceso al servidor de autorización,
mediante el endpoint de acceso, enviando una petición cuya cabecera
contenga el token de actualización.
20. El servidor de autorización, mediante el endpoint de token, devuelve un
nuevo token de acceso y uno de actualización.
Los siguientes supuestos son considerados fuera del rango (RFC-6819, 2013):
23
Los siguientes supuestos son relativos al atacante y los recursos disponibles por
el atacante (RFC-6819, 2013). Se asume que:
Las amenazas que enfrenta OAuth 2.0 están clasificadas por ataques dirigidos
a un componente de OAuth (Client, Authorization Server y Resource Server) y
agrupados por flujo (por ejemplo: obtener el token o el acceso a los recursos
protegidos) acorde al diagrama de secuencia de la Figura 13.
En su flujo habitual, un cliente tiene acceso y guarda los datos antes descritos.
Si nos fijamos en un flujo completo de OAuth como el presentado en la Figura
13, observaremos un conjunto de procesos que el cliente ejecuta, y en cada
proceso va capturando estos datos, resumidos en la siguiente figura:
24
Figura 14: Flujo y datos usados por el cliente en un entorno OAuth 2.0.
Fuente: Elaboración propia.
25
AMENAZA ATAQUE DESCRIPCIÓN CONSECUENCIAS RECOMENDACIONES
• No compartir secretos de
Un atacante puede intentar
clientes públicos o clientes con
obtener acceso al secreto de un
políticas inapropiadas.
Obtener el cliente para reproducir su token
• Solicitar consentimiento del
secreto del de autorización o para actuar en
usuario para clientes públicos.
código fuente o una instancia en nombre del
• Un atacante puede obtener • Usar secretos de cliente para
el binario cliente. Este secreto puede ser
la autenticación del cliente despliegues específicos.
obtenido del código fuente si es
open source o del binario. para acceder al servidor de • Revocar secretos de los
Obteniendo
autorización. clientes.
los secretos
del cliente Un atacante puede intentar • Los tokens de actualización
obtener acceso al secreto de un o los códigos de autorización • Aplicar medidas de protección
cliente para reproducir su token robados pueden ser de web server.
Obtener el
de autorización o para actuar en reproducidos. • Guardar secretos en
secreto de un
una instancia en nombre del almacenamiento local seguro en
despliegue
cliente. Este token puede ser aplicaciones nativas.
específico
obtenido de una instalación del • Revocar los secretos de los
cliente, de un sitio web o de un clientes
dispositivo móvil.
• El servidor de autorización debe
validar el identificador del cliente
asociado a un token de
actualización en cada solicitud
de actualización.
• Limitar el alcance del token.
Obtener el Un atacante puede obtener el
• Revocar los secretos del cliente.
token de token de actualización de una • Exposición de todos los
actualización aplicación web evadiendo los • Los tokens de actualización
tokens de actualización del
pueden ser reemplazados
de una controles de seguridad del sitio al atacante.
automáticamente para detectar
aplicación web servidor web.
aquellos que no estén
autorizados.
• Medidas estándar de seguridad
de servidores web.
• Usar medidas de autenticación
fuertes.
Obtener el
Obteniendo Un atacante puede tratar de • Guardar secretos guardados en
token de
los tokens de obtener el archivo del sistema • Exposición del token de almacenamientos seguros.
actualización
actualización de un dispositivo y leer su token actualización del dispositivo. • Utilizar bloqueos de seguridad
de clientes
de actualización. del dispositivo.
nativos
26
• El flujo de OAuth permite que las
aplicaciones del cliente nunca
necesiten contraseñas.
Una aplicación maliciosa puede
• Las aplicaciones cliente pueden
robar las contraseñas de los
Credenciales ser validadas antes de ser
usuarios finales usando un • Si la aplicación del cliente o
de usuario final publicadas en las tiendas para
Obtener las navegador embebido en el la comunicación está
robadas acceso de los usuarios.
Credenciales proceso de autorización del comprometida, las
de usuario
mediante un
usuario final, o presentando su • Los desarrolladores de los
credenciales de acceso
navegador web clientes no deben escribir
propia interfaz en lugar de pueden ser capturadas.
comprometido clientes que guarden
permitir un navegador
confiable. información directa de los
usuarios. En su lugar, debe
delegarse esta tarea a un
componente seguro.
Se expone un endpoint que usa • Un atacante puede obtener • Solicitar a los clientes el registro
Redirecciones Redirecciones
un parámetro para redirigir acceso a un token de acceso de una dirección URI completa
abiertas en abiertas en los
automáticamente una petición o a un código de que servirá para una
los clientes clientes
hacia una dirección no validada. autorización. autorización segura.
Tabla 4: Modelo de amenazas y recomendaciones para el Cliente OAuth2.0
Fuente: RFC 6819
Figura 15: Datos usados por el endpoint de autorización en un flujo OAuth 2.0.
Fuente: Elaboración propia.
27
En este contexto, los ataques y recomendaciones enfocados en el endpoint de
autorización del servidor de autorización de OAuth 2.0 se centran en los puntos
y datos antes descritos y son (RFC-6819, 2013):
28
• Valores para el proceso de autorización: redirect_uri, authorization code.
Figura 16: Flujo y datos usados por el endpoint de token en un flujo OAuth 2.0.
Fuente: Elaboración propia.
29
• Asegurarse que el servidor esté
usando el mínimo de privilegios de la
base de datos posible.
Obteniendo los • Evitar inputs que se concatenen con
• Revelación de todos los
secretos del Un atacante puede obtener un secreto código SQL de manera dinámica.
secretos del cliente que le
cliente de la de cliente válido de una base de datos • Si se usa SQL dinámico, parametrizar
permite a un atacante ejecutar
base de datos del Servidor de Autorización ejecutando las consultas a la base usando bind
consultas de clientes
del Servidor de ataques de inyección SQL. arguments.
legítimos.
Autorización • Sanear los datos en el momento del
ingreso.
• Asegurar un manejo apropiado del
acceso a la base de datos.
El flujo para obtener una autorización se caracteriza por ser una parte del flujo
completo de OAuth 2.0 que es utilizado para obtener los tokens de acceso. Cada
flujo es caracterizado por los tipos de respuesta, o los tipos de concesión de
autorización del usuario final y el endpoint del token, respectivamente (RFC-
6819, 2013).
Dado que existen varios tipos de concesión de autorización (ver 2.2.2.2), vamos
a dividir en los posibles ataques acorde a cada tipo.
30
Figura 17: Diagrama de concesión por código de Autorización.
Fuente: RFC-6749
31
• Usar una alta entropía en el secreto del cliente.
Por lo general el valor de un token debe ser
mayor o igual a 128 bits construido con una
fuerte generación aleatoria.
• Divulgación de un token de • Tokens deben ser firmados para detectar
acceso y probablemente
Adivinando el Un atacante puede adivinar el cualquier intento de modificación o
también su token de
código de código de autorización de un falsificación.
actualización. El atacante lo
autorización cliente. • Incluir el identificador del cliente con el código
usará para realizar peticiones
de autorización.
de un cliente legítimo.
• Incrustar el código de autorización en la URI de
redirección.
• Usar tiempos de expiración más cortos para los
tokens de acceso.
• Un servidor de autorización puede emitir por
separado los identificadores del cliente y los
secretos de cada instalación del cliente.
• El servidor de autorización debe validar el URI
Un cliente malicioso puede de redirección de cada cliente, comparándolo
pretender ser un cliente
con el URI de redirección pre registrado.
Clientes legítimo para obtener una • Un cliente malicioso que
• Después de la autenticación del usuario final,
maliciosos autorización de acceso. El consigue una autorización y
el servidor de autorización debe solicitar
obteniendo cliente malicioso puede ejecuta acciones como un
consentimiento.
autorización. intentar simular un cliente legítimo.
• El servidor de autorización no debería autorizar
consentimiento real del
o volver a autorizar automáticamente clientes
usuario.
que no puede validar.
• Uso de captchas o similares.
• El servidor de autorización debe limitar el
alcance de los tokens.
32
Con el ClickJacking, un sitio
malicioso puede cargar un • Para navegadores web más recientes, se
sitio objetivo dentro de un puede evitar el uso de iFrames durante la
iFrame transparente y autorización en el lado del servidor utilizando la
superpuesto a un conjunto de cabecera X-FRAME-OPTIONS. Esta cabecera
Ataque de botones falsos que se • Un atacante puede robar las tiene dos parámetros "DENY" y "SAME
ClickJacking construyen cuidadosamente credenciales de autenticación ORIGIN" que pueden bloquear el uso de
contra la para colocarlos justo debajo del usuario y acceder a sus iFrames.
autorización de los botones importantes recursos. • Para navegadores antiguos, existe una técnica
del sitio web destino. Cuando llamada JavaScript frame-busting que puede
un usuario da click en un ser usada para evitar el uso de iFrames, pero
botón visible, en realidad puede no ser compatible con todos los
puede estar autorizando a la navegadores.
página oculta.
Si un servidor de autorización
no limita el número de códigos • El servidor de autorización debe limitar el
de autorización o tokens de • Un atacante podría número de tokens de acceso concedidos por
Ataques DoS
acceso por usuario, un comprometer la accesibilidad usuario.
que agoten los
atacante podría agotar la pila del servidor de autenticación y • El servidor de autorización debe incluir una
recursos
de códigos de acceso acceder a recursos protegidos. cantidad no trivial de entropía en los códigos
redirigiendo repetidamente de autorización.
peticiones de autorización.
33
utiliza un lenguaje de script como JavaScript. Dado que es un flujo basado en
redirección, el cliente debe ser capaz de interactuar con el agente de usuario del
propietario del recurso (usualmente un navegador web) y recibir solicitudes (por
redirección) del servidor de autorización (RFC-6749, 2012). Diferenciando del
tipo de concesión por código de autorización, el método implícito realiza una sola
llamada para recibir el token de acceso, en lugar de recibir el código de
autorización.
34
• Un servidor de autorización puede
emitir por separado los
identificadores del cliente y los
secretos de cada instalación del
cliente.
• El servidor de autorización debe
validar el URI de redirección de cada
Un cliente malicioso puede cliente, comparándolo con el URI de
pretender ser un cliente legítimo • Un cliente malicioso que redirección pre registrado.
Clientes maliciosos
para obtener una autorización de consigue una autorización y • Después de la autenticación del
obteniendo
acceso. El cliente malicioso puede ejecuta acciones como un usuario final, el servidor de
autorización.
intentar simular un consentimiento cliente legítimo. autorización debe solicitar
real del usuario. consentimiento.
• El servidor de autorización no
debería autorizar o re autorizar
automáticamente clientes que no
puede validar.
• Uso de captchas o similares.
• El servidor de autorización debe
limitar el alcance de los tokens.
35
autorización para que retorne un token de acceso y (opcional) un token de
actualización (RFC-6749, 2012).
Figura 19: Diagrama de Concesión por Credenciales de contraseña del Propietario del Recurso.
Fuente: RFC-6749
36
• Utilizar otros flujos que no dependan de
la cooperación del cliente para la
interacción con el propietario de los
recursos.
Toda la interacción del propietario
El cliente obtiene el • Un atacante puede obtener un • El servidor de autorización puede
del recurso es realizada por el
token de token de actualización que le generalmente negarse a emitir tokens
cliente. Podría pasar que un
autorización a través permitirá obtener tokens de acceso de actualización en este flujo. Si el
cliente obtiene, intencional o
de la autorización para realizar operaciones como un cliente es confiable, puede
inintencionalmente, un token de
automática. usuario legítimo. autenticarse de manera confiable.
actualización de larga duración.
• El servidor de autorización debería
notificar al propietario del recurso el
token de actualización concedido. Para
ello debe usar un medio apropiado.
• Asegurar la confidencialidad de las
solicitudes usando mecanismos TLS,
Obtención de
Un atacante puede hacerse de las VPN, etc.
contraseñas de • Divulgación de una contraseña de
credenciales en la transmisión • Usar una autenticación alterna que no
usuario en el un usuario.
entre el cliente y el servidor. requiera el envío de contraseñas en
transporte
texto plano, como por ejemplo los
basados en códigos hash.
• Reducir los privilegios de acceso de la
base de datos al mínimo.
• Evitar los inputs concatenados con
Un atacante puede obtener una
SQL dinámico.
Obteniendo las combinación válida de • Divulgación de una combinación
• Parametrizar las consultas para
contraseñas de los usuario/contraseña de la base de válida de nombre de
inyectar los argumentos en lugar de
usuarios de la base datos del servidor de autorización usuario/contraseña. Un atacante
concatenarlos.
de datos del Servidor obteniendo acceso a la base de puede usar estas combinaciones
• Filtrar y limpiar todas las entradas de
de autorización. datos o ejecutando ataques de para acceder a varios servicios.
datos.
inyección SQL.
• No guardar credenciales en texto plano
en la base de datos. Usar encriptación.
• Usar criptografía asimétrica.
• Utilizar políticas para asegurar
contraseñas.
• Bloquear cuentas que cumplen un
Adivinando las límite de intentos de acceso fallidos.
Un atacante puede intentar
credenciales del • Revelación de una combinación • Usar CAPTCHAs en el proceso de
adivinar combinaciones válidas
usuario usuario/contraseña de un usuario. envío.
de usuario/contraseña.
(nombre/contraseña). • Considerar no usar el tipo de
autorización por envío de credenciales.
• Usar un segundo factor de
autenticación del lado del cliente.
Tabla 9: Modelo de amenazas y recomendaciones para la concesión por contraseña del propietario del recurso
OAuth2.0.
Fuente: RFC 6819
37
2.3.5.5 Flujo: Actualizando un token de acceso
Este flujo es susceptible de sufrir los siguientes ataques con sus respectivas
recomendaciones (RFC-6819, 2013):
38
Un atacante podría obtener
los tokens de actualización
válidos enviando solicitudes al
Phishing del token • El URI de redirección del cliente debe apuntar
servidor de autorización. Dada
de actualización por • Exposición de tokens de a un endpoint protegido con el protocolo
la circunstancia que el
un Servidor de actualización válidos que HTTPS, y el navegador web debe ser usado
atacante conozca una
Autorización deriva en los tokens de acceso. para validar esta URI de redirección mediante
dirección de un servidor de
falsificado. el dominio registrado en el cliente.
autorización, éste intentará
suplantar la identidad para
tener éxito.
Tabla 10: Modelo de amenazas y recomendaciones para el flujo de actualización de tokens de acceso OAuth2.0.
Fuente: RFC 6819
Una vez que un cliente consiga un token de acceso, lo utilizará para acceder a
un recurso protegido. Los pasos 15, 16 y 17 de la Figura 13 reflejan claramente
este flujo.
Este flujo es susceptible de sufrir los siguientes ataques con sus respectivas
recomendaciones (RFC-6819, 2013):
39
• Usar secretos de alta entropía para
causar mayor dificultad de adivinanza.
Por lo general un token debe ser mayor o
Donde el token es manejado, un
igual a 128 bits.
atacante puede intentar adivinar el
Adivinando • Acceso a los datos de un • Tokens deben ser firmados con el
token de acceso basado en el
tokens de acceso. usuario. objetivo de verificar su validez.
conocimiento que tengan de los tokens
• Incrustar el token al identificador del
de acceso.
cliente también de modo que se añade
otro elemento a adivinar.
• Emitir tokens de corta duración.
40
3. Desarrollo e Implementación
Cuando se habla de arquitecturas de microservicios, existen distintos enfoques
donde cada uno de ellos integra varios componentes que varían acorde a los
múltiples retos a enfrentar cuando se implementa este tipo de arquitecturas. En
este sentido, existen varias guías a tomar en cuenta cuando de arquitecturas de
microservicios se implementa; sin embargo, tomamos como referencia el
lenguaje de patrones de arquitecturas de microservicios (Richardson, 2022).
41
3.2 Definiendo una arquitectura de microservicios
Una puerta de enlace API o API Gateway es una herramienta de gestión de APIs
que se encuentra entre el cliente y un conjunto de servicios de backend
encargados de las tareas habituales que se utilizan en los sistemas de servicios
de API como la autenticación de los usuarios, la limitación de la frecuencia,
estadísticas, etc. En general, una puerta de enlace API varía de una
implementación a otra, pero su objetivo principal es interceptar todas las
solicitudes que ingresan, y las envían a través de un sistema de gestión de API
para obtener los recursos de varios servicios (RedHat, 2019).
En el API Gateway como cliente OAuth 2.0, el flujo queda determinado por los
siguientes pasos:
1. El usuario inicia una petición de recursos al API Gateway.
2. El API Gateway verifica si posee un token de acceso válido, caso contrario
inicia una redirección hacia el Servidor de Autorización para solicitar
acceso al usuario.
3. El usuario ingresa sus credenciales.
4. El Servidor de Autorización envía al API Gateway un token de acceso y
un token de actualización.
5. El API Gateway solicita a un microservicio (Servidor de recursos) un
recurso protegido enviando el token de acceso.
6. El microservicio verifica la validez del token con el Servidor de
Autorización.
7. En caso de ser un token de acceso válido, retorna el recurso protegido.
42
Figura 25: API Gateway como un cliente OAuth 2.0.
Fuente: Elaboración propia
43
3.3 Diseño de la arquitectura de microservicios
Figura 27: Diagrama de secuencia de una arquitectura de microservicios con un API Gateway como un cliente OAuth.
Fuente: https://www.baeldung.com/spring-cloud-gateway-oauth2
44
Servidor de Autorización
Servidor de Autorización Un Servidor de Autorización, acorde a OAuth 2.0.
(Authorization Server)
Microservicio 1
Un microservicio que expone un endpoint protegido Servidor de Recursos (Resource
Microservicio 2 que nos devolverá los valores protegidos. Server)
Microservicio 3
Tabla 12: Definición de componentes a desarrollar.
Fuente: Elaboración propia.
45
3.4 Desarrollo de la arquitectura de microservicios
Característica Valor
Lenguaje de programación Kotlin 1.6.21
Framework Spring Boot 2.7.7. RELEASE
Gestor de construcción Gradle 7.5.1
Versión de lenguaje java-1.8.0-openjdk
• spring-boot-starter-oauth2-client V. 2.7.7
Librerías usadas
• spring-cloud-starter-gateway V. 2021.0.5
Tabla 13: Tecnologías usadas para el desarrollo del API Gateway
Fuente: Elaboración propia.
Endpoints expuestos:
• /microservice1 -> enrutará al microservicio 1
• /microservice2 -> enrutará al microservicio 2
• /microservice3 -> enrutará al microservicio 3
Configuraciones principales:
1. server:
2. port: 8090
1. spring:
2. security:
3. oauth2:
4. client:
5. provider:
6. keycloak:
7. issuer-uri: http://localhost:9000/auth/realms/security
8. registration:
9. gateway:
10. provider: keycloak
11. client-id: gateway
12. client-secret: ePEArOxZNZN0AvFig8BN0wSHHCs7eBen
13. scope:
14. - email
15. - profile
16. - roles
46
Como podemos observar, el Gateway posee un identificador de cliente y un
secreto. Este parde valores deberán ser pre registrados en el Servidor de
Autorización OAuth 2.0 con el fin de verificar la confianza en el cliente. En el
siguiente capítulo se analiza a detalle estos valores.
1. main:
2. allow-bean-definition-overriding: true
3. web-application-type: reactive
4. cloud:
5. gateway:
6. redis:
7. enabled: false
8. routes:
9. - id: microservice1
10. uri: http://localhost:8081
11. predicates:
12. - Path=/microservice1
13. filters:
14. - TokenRelay=
15. - id: microservice2
16. uri: http://localhost:8082
17. predicates:
18. - Path=/microservice2
19. filters:
20. - TokenRelay=
21. - id: microservice3
22. uri: http://localhost:8083
23. predicates:
24. - Path=/microservice3
25. filters:
26. - TokenRelay=
NOTA: los secretos compartidos en los archivos de configuración YAML han sido
incluidos por motivos académicos. En ambientes de producción, estos secretos,
no deberían ser compartidos en los repositorios del software ni ampliamente
difundidos; sino más bien, deben ser manejados con mucha confidencialidad por
el equipo encargado de los despliegues.
47
múltiples protocolos; entre ellos OAuth 2.0 junto a OpenID-Connect, SAML, entre
otros.
Característica Valor
https://github.com/thomasdarimont/embedded-spring-
Código fuente original
boot-keycloak-server
Lenguaje de
Java 13 (11 compatible)
programación
Framework Spring Boot 2.6.7
Gestor de construcción Apache Maven 3.6.3
Versión de lenguaje java-13-openjdk
• h2database Versión latest
Librerías usadas
• Keycloak 18.0.0
Tabla 14: Tecnologías usadas para el desarrollo del Servidor de Autorización
Fuente: Elaboración propia.
Configuraciones principales:
1. server:
2. port: 9000
1. keycloak:
2. server:
3. customRealm: security
4. contextPath: /auth
5. adminUser:
6. username: admin
7. password: password
8. customUser:
9. username: security-admin
10. password: password
11. realmImportFile: realm-export.json
Dado que no se configura una base de datos, el servidor necesita ser configurado
cada vez que se inicie (ver Anexo 1) para lo cual se exporta un archivo de
48
configuración y éste será importado cada vez que se inicie el servidor de
autorización.
Para desarrollar los microservicios, se desarrolló una base similar para todos, y
se cambió el archivo de configuración para distinguirlos entre sí. A continuación,
se describen los detalles del módulo en común.
Característica Valor
Lenguaje de programación Kotlin 1.6.21
Framework Spring Boot 2.7.7. RELEASE
Gestor de construcción Gradle 7.5.1
Versión de lenguaje java-1.8.0-openjdk
• spring-boot-starter-oauth2-resource-server V. 2.7.7
Librerías usadas • spring-boot-starter-web V. 2021.0.5
• io.projectreactor:reactor-core V. 3.4.24
Tabla 15: Tecnologías usadas para el desarrollo de los Microservicios
Fuente: Elaboración propia.
Endpoints expuestos:
• /microservice1 -> microservicio 1
• /microservice2 -> microservicio 2
• /microservice3 -> microservicio 3
Configuraciones principales:
1. security:
2. oauth2:
3. resourceserver:
4. opaquetoken:
5. introspection-uri: http://localhost:9000/auth/realms/security/protocol/openid-connect/token/introspect
6. client-id: microservice1
7. client-secret: 5FlyzwdNmF68kQFfYzifqAeMmqXOnfoJ
49
1. security:
2. oauth2:
3. resourceserver:
4. opaquetoken:
5. introspection-uri: http://localhost:9000/auth/realms/security/protocol/openid-connect/token/introspect
6. client-id: microservice2
7. client-secret: rISR8jYh6xagFI7eBAXDpwUPNgyj9Ljx
1. security:
2. oauth2:
3. resourceserver:
4. opaquetoken:
5. introspection-uri: http://localhost:9000/auth/realms/security/protocol/openid-connect/token/introspect
6. client-id: microservice3
7. client-secret: hSMTHZllY5PGeIHSRcIIICteG7imTVJ1
NOTA: los secretos compartidos en los archivos de configuración YAML han sido
incluidos por motivos académicos. En ambientes de producción, estos secretos,
no deberían ser compartidos en los repositorios del software ni ampliamente
difundidos; sino más bien, deben ser manejados con mucha confidencialidad por
el equipo encargado de los despliegues.
50
Una vez levantado el servicio, esta interfaz es accesible mediante el siguiente
enlace http://localhost:9000/auth/admin/master/console/#/realms/master
donde podemos observar la siguiente interfaz:
Con este entorno, se procede a ejecutar los microservicios que forman parte de
esta arquitectura y verlos operando en conjunto con el protocolo OAuth2.0. En
este sentido, se ejecuta la siguiente lista de pasos:
51
Figura 30: Ejecución de la arquitectura de microservicios hacia el microservicio 1
Fuente: Elaboración propia.
En ella se resalta:
52
De forma conjunta, en la Figura 33 se muestran los registros de ejecución de
todos los componentes al mismo tiempo.
53
4. Seguridad en el entorno de microservicios
usando el protocolo OAuth
En este apartado se analiza la configuración del servidor de autorización
construido con Keycloak para verificar que las recomendaciones de seguridad
expuestas en el documento RFC-6819 y en el apartado 2.3.5 del presente
trabajo sean tomadas en cuenta.
Users: son entidades capaces de iniciar sesión en el sistema. Cada usuario tiene
atributos y alcances, pueden ser asignados a grupos y roles.
Groups: los grupos manejan conjuntos de usuarios y para cada grupo se pueden
definir atributos y límites. Se pueden mapear un conjunto de roles para un grupo
de la misma manera.
Client scope: cuando un cliente se registra, se debe definir los ámbitos (scope).
Éstos son útiles para definir accesos y límites que tendrá el cliente.
54
En este sentido, se utilizará el entorno desarrollado que se compone de los
clientes, servidor de Autorización Keycloak y los proveedores de recursos para
verificar algunas amenazas y consideraciones de seguridad expuestas en el
documento RFC 6819.
55
Figura 35: Tipos de clientes en servidor Keycloak
Fuente: Elaboración propia.
56
Figura 37: Nivel de entropía del secreto del cliente
Fuente: https://timecutting.co.uk/tools/password-entropy,
El documento RFC 6819 nos indica que no se puede compartir secretos con
clientes que no los puedan proteger; es decir, clientes públicos cuyo código
pertenezca a fuentes desconocidas o sea públicamente distribuido. A estos
clientes se los considera de políticas inapropiadas o públicas.
En este contexto, una de las amenazas expuestas por el documento RFC 6819
nos indica que, si un cliente es público, hay que tratarlo como tal. En Keycloak
se lo debe configurar como un cliente público de la siguiente manera.
57
Donde se destaca:
1. El Protocolo de identidad del cliente, en este caso OpenID Connect, es
una capa adicional que se monta sobre OAuth con el fin de dotar de
identidad al protocolo (su análisis y prueba no se incluyen en este
apartado).
2. Tipo de acceso público que define al cliente Keycloak como cliente
público. Al definirlo de esta manera, automáticamente Keycloak evita
crear secretos para este tipo de cliente.
3. El flujo estándar habilitado hace referencia a permitir que, dentro del flujo
de autorización, se ocupe el tipo de concesión por código de autorización
del apartado 2.2.2.2 (este parámetro es necesario para el funcionamiento
del entorno definido en el apartado 3.3).
4. El flujo de acceso directo sirve para que el servidor de autorización
permita el tipo de concesión por credenciales de contraseñas del usuario
definido en el apartado 2.2.2.2. En este caso, se lo habilita para las
pruebas realizadas directamente mediante el cliente API de la Figura 39
y similares.
5. Registro de las URI de redirección permitidas para este cliente. Este paso
es obligatorio en Keycloak y cumple con las consideraciones expuestas
en el documento, específicamente la amenaza denominada Redirección
Abierta en la Tabla 5 (su análisis y prueba no se incluyen en este
apartado).
Una vez configurado el API Gateway como cliente público y, una vez permitido
el punto 4 de la Figura 38, vamos a usar un cliente API (en nuestro caso
Insomnia) para probar el flujo actual. Para lo cual se definió la siguiente
configuración de variables para de entorno:
1. {
2. "auth_server": "http://localhost:9000",
3. "server": "http://locahost:8090",
4. "resource_server_1": "http://localhost:8081",
5. "resource_server_2": "http://localhost:8082",
6. "resource_server_3": "http://localhost:8083",
7. "realm": "security",
8. "client_id": "gateway",
9. "client-secret": "bD8ABWRzWn2MpGxtfrNSzIp7rIwdEfQC",
10. "user": "security-admin"
11. "password": "password"
12. }
Figura 39: Solicitud de acceso para el API Gateway como cliente público
Fuente: Elaboración propia.
58
En la solicitud de acceso que realiza un cliente público al servidor de autorización
de la Figura 39, se destaca:
Si se toma el valor del token de acceso, podemos realizar una petición de acceso
a los recursos protegidos por uno de los proveedores de recursos
(microservicios) enviándolo en el HEADER de la petición anteponiendo el
término Bearer antes del token de la siguiente manera:
Figura 40: Acceso a recursos protegidos por el microservicio 2 usando un token de acceso
Fuente: Elaboración propia.
Figura 41: Solicitud de acceso denegado por falta del secreto del cliente
Fuente: Elaboración propia.
59
4.2.3 Secretos específicos para despliegues específicos
Continuando con las amenazas de los clientes, una pregunta surge inherente a
la arquitectura de OAuth y presentada en el protocolo: ¿Qué pasa si un cliente
engaña al Servidor de Autorización?
Por ejemplo, se crea un cliente que sea destinado para el acceso del Gateway
mediante el cliente de Insomnia, de la siguiente manera:
Ahora, suponemos que este cliente venía operando con normalidad. Tiempo
después su integridad ha sido expuesta debido a un problema de seguridad,
donde se determinó que su acceso ya no es confiable. El siguiente paso será
60
deshabilitar el cliente específico desde nuestro servidor de Keycloak de la
siguiente manera:
Cabe recalcar que esta acción también dará como resultado que cualquier token
de acceso o de autorización previamente generados, queden automáticamente
inválidos.
Los usuarios son los dueños de los recursos dentro de la arquitectura de OAuth.
El documento RFC 6819 también aborda amenazas y consideraciones de
seguridad relativas a estos usuarios.
Una amenaza presente en los usuarios son los ataques de fuerza bruta. En el
documento la amenaza es denominada como “Adivinando las credenciales de
los usuarios” que se expone en la Tabla 9. Esta amenaza se mitiga mediante la
limitante del número de intentos permitidos de acceso fallido, cuyo exceso
genera el bloqueo de la cuenta por cierto número de intentos. Esta consideración
de seguridad es expuesta bajo el apartado 5.1.4.2.3 del documento RFC 6819.
Para ello, Keycloak nos otorga una pantalla de administración donde podemos
habilitar este comportamiento usando los parámetros:
61
Figura 45: Configuración de seguridad contra ataques de fuerza bruta
Fuente: Elaboración propia.
62
5. Conclusiones y trabajos futuros
Durante el desarrollo del presente trabajo, se han planteado sus objetivos y se
han abordado un conjunto de capítulos acorde a los mismos. De igual forma, se
ha desarrollado un conjunto de microservicios que hacen uso del protocolo
OAuth2.0 para autenticarse y conseguir autorización. Finalmente se procedió a
configurarlos acorde a las consideraciones de seguridad del documento RFC
6819.
Durante todo este proceso, podemos concluir con los siguientes enunciados:
63
• La sola implementación de Keycloak no brinda un entorno seguro de
autenticación. Se requiere configuración adicional y políticas que permitan
asegurar el mismo.
APARTADO IDENTIFICADOR
AMENAZA DESCRIPCION
DEL TFM EN RFC
64
futuro, la implementación del protocolo OAuth en arquitecturas de
microservicios donde el API GATEWAY sea tratado como un proveedor
de recursos al igual que los microservicios, siguiendo el flujo de la Figura
26 y haciendo énfasis en las diferencias entre las mismas.
OBJETIVO COBERTURA
Identificar el concepto de microservicios, CUBIERTO
su utilidad e importancia en los entornos
Cloud en la actualidad.
Conocer el protocolo OAuth2.0 en tanto a
su funcionamiento, operación e
importancia como un sistema de CUBIERTO
autenticación y autorización de
microservicios.
Identificar las distintas debilidades y
consideraciones de seguridad del
protocolo OAuth2.0 expuestos en el CUBIERTO
documento RFC 6819.
Desarrollar un entorno basado en una
arquitectura de microservicios que hagan
uso del protocolo OAuth2.0 para CUBIERTO
autenticación y acceso a recursos
protegidos.
Configurar el entorno para tener en
consideración las recomendaciones de
PARCIALMENTE CUBIERTO
seguridad expuestas en el documento RFC
6819.
Exponer las conclusiones del trabajo
realizado y estudios futuros que sean CUBIERTO
necesarios para complementar el tema.
Tabla 19: Tabla de cobertura de objetivos
Fuente: Elaboración propia.
Por tal motivo, como trabajo futuro, se propone la configuración del resto
de consideraciones de seguridad expuestas en el documento RFC 6819
que no han sido parte del presente TFM por temas de extensibilidad.
65
6. Glosario
API (Application Programming Interfaces): es un conjunto de definiciones y
protocolos que se utilizan para desarrollar e integrar el software de aplicaciones,
permitiendo las comunicaciones entre dos aplicaciones mediante un conjunto de
reglas.
Header: es la cabecera que forma parte de una petición y está destinada a añadir
información necesaria para el procesamiento de una petición.
66
7. Bibliografía
Awati, R., & Wigmore, I. (May de 2022). Whatls.com. Obtenido de Whatls.com:
https://www.techtarget.com/whatis/definition/monolithic-architecture
Blinowski, G., Ojdowska, A., & Przybylek, A. (2022). Monolithic vs. Microservice Architecture: A
Performance and Scalability Evaluation. IEEEAcess, 20357 - 20374.
Fowler, M., & Lewis, J. (25 de March de 2014). martinfowler.com. Obtenido de martinfowler.com:
https://martinfowler.com/articles/microservices.html
Hammer-Lahav, E. (05 de September de 2007). OAuth. Obtenido de oauth.net:
https://oauth.net/about/introduction/
Hannousse, A., & Yahiouche, S. (2020). Securing microservices and microservice architectures:
A systematic mapping study.
Hunter II, T. (2017). Advanced Microservices: A Hands-on Approach to Microservice
Infrastructure and Tooling. San Francisco: Springer Science+Business Media.
Keycloak. (01 de 01 de 2023). Keycloak. Obtenido de
https://www.keycloak.org/docs/latest/server_admin/#:~:text=that%20group%20defines.-
,realms,the%20users%20that%20they%20control
Kharenko, A. (9 de Octubre de 2015). Monolithic vs. Microservices Architecture. Obtenido de
articles.microservices.com: https://articles.microservices.com/monolithic-vs-
microservices-architecture-5c4848858f59
Mayer, B., & Weinreich, R. (2017). A Dashboard for Microservice Monitoring and Management.
2017 IEEE International Conference on Software Architecture (págs. 66-69).
Gothenburg, Sweden: CPS.
Newman, S. (2015). Building Microservices. Sebastopol: O´Really Media, Inc.
OAuth Core, 1. (4 de December de 2007). OAuth. Obtenido de OAuth:
https://oauth.net/core/1.0/#anchor3
OAuth Working Group, I. (Octubre de 2012). OAuth. Obtenido de OAuth: https://oauth.net/2/
RedHat. (08 de Enero de 2019). https://www.redhat.com/. Obtenido de https://www.redhat.com/:
https://www.redhat.com/es/topics/api/what-does-an-api-gateway-do
RFC-6749. (October de 2012). rfc-editor. Obtenido de rfc-editor: https://www.rfc-
editor.org/rfc/rfc6749
RFC-6819. (Enero de 2013). rfc-editor.org. Obtenido de rfc-editor: https://www.rfc-
editor.org/rfc/rfc6819
Richardson, C. (2022). https://microservices.io/. Obtenido de https://microservices.io/:
https://microservices.io/patterns/index.html
Sevestre, P. (13 de Julio de 2022). Baeldung. Obtenido de Baeldung:
https://www.baeldung.com/spring-cloud-gateway-oauth2
Siriwardena, P. (2014). Advanced API Security: Securing APIs with OAuth 2.0, OpenID Connect,
JWS, and JWT. New York: Springer Science+Business Media.
Spasovski, M. (2013). OAuth 2.0 Identity and Access Management Patterns: A practical hands-
on guide to implementing secure API authorization flow scenarios with OAuth 2.0.
Birmingham: Packt Publishing Ltd.
TheExpressWire. (26 de Julio de 2022). Digital Journal. Obtenido de Digital Journa:
https://www.digitaljournal.com/pr/cloud-microservices-market-growth-statistics-2022-
size-global-share-regional-developments-demand-status-and-cagr-value-forecast-by-
top-key-players-till-2028
Triartono, Z., Muldina Negara, R., & Sussi. (2019). Implementation of Role-Based Access Control
on OAuth 2.0 as Authentication and Authorization System. Proc. EECSI, 259 - 263.
Yang, J., Huo, H., Li, H., & Zhu, Q. (2021). User Fast Authentication Method Based on
Microservices. 2021 IEEE International Conference on Power Electronics, Computer
Applications (ICPECA), 93-98.
67
8. Anexos
Anexo 1: Configuración básica del Servidor de Autorización usando
Keycloak
68
69