Patrones de Autorización en GraphQL

Todas las buenas charlas deben comenzar con una cita, ¿verdad? Entonces, ¿sabes cómo dicen que, en teoría, no hay diferencia entre la teoría y la práctica, pero en la práctica sí la hay? Bueno, de eso trata esta charla. Voy a hablarles sobre la teoría de la autorización en GraphQL, y luego si y cómo esto se corresponde con la práctica. Así que, soy Sam, soy cofundador y CTO de Oso, y construimos autorización para desarrolladores. Y como alguien que hizo un doctorado en criptografía y gradualmente se deslizó más y más hacia el mundo práctico, estoy bastante familiarizado con la distinción entre la teoría y la práctica.

Así que prepárense y aprendan un poco sobre patrones en GraphQL, tanto teóricos como prácticos. Sé que hay mucha confusión sobre la diferencia entre autenticación y autorización, así que comenzaré con algunas definiciones. Autenticación se trata de la identidad, ¿sabes, quién es el usuario? Puede ser que los identifiques a través de un nombre de usuario y contraseña, puedes hacer inicio de sesión único, puedes tener autenticación de dos factores, eso es todo autenticación. La autorización es la pieza que viene después. Ahora que sabes quién es el usuario, ¿qué pueden hacer? Y voy a hablar sobre la autorización de la aplicación. Entonces, específicamente, ¿qué pueden hacer dentro de tu aplicación?

Para darte algunos ejemplos, GitHub, este es un gran ejemplo. Tiene un sistema de autorización bastante robusto. Te permite hacer roles a nivel organizacional, como propietario y miembro, y cuáles de esos pueden crear repositorios. También puedes tener roles a un nivel más granular. Puedo invitarte como colaborador a mi repositorio y darte un rol que te otorgue diferentes accesos. Ahora, me gusta mucho GitHub como ejemplo, porque también tienen una API de GraphQL, por lo que podremos ver no solo la autorización genéricamente, sino también en el contexto de GraphQL. Para un ejemplo de autorización más complejo, toma AWS IAM. Y con AWS IAM, puedes escribir tu propia lógica y políticas de autorización para determinar quién tiene permitido hacer qué dentro de esta plataforma gigantesca. Es bastante complejo. Pero hay algunas autorizaciones de aplicaciones en las que quizás no pienses tanto. Toma algo como Google Docs o Notion, donde parte del flujo de trabajo principal es invitar a personas a colaborar en documentos, o tal vez invitarlos a una carpeta completa y decir dónde pueden ver, editar o comentar esos documentos. Eso es toda autorización. GitHub, AWS, Google Docs, Notion, todos estos son ejemplos fantásticos de autorización de aplicaciones.

Antes de comenzar a entrar en los detalles técnicos, ¿por qué es este un tema importante para hablar? Bueno, en primer lugar, si no tienes autorización en una aplicación, tu producto está completamente roto. Tienes una especie de anarquía. Cualquiera puede entrar y hacer cualquier cosa. Pueden eliminar a otros usuarios, pueden eliminar los datos de otras personas, pueden hacer cualquier cosa. Pero por otro lado, si tu autorización está rota, las personas no pueden acceder a nada. Tu aplicación no funciona. Si tu autorización tiene errores, los usuarios comienzan a frustrarse. Todos hemos estado en esa situación en la que la lógica de autorización en una aplicación está tan rota y frustrante que simplemente dices, sabes qué, voy a hacer que todos sean administradores.

No quiero lidiar con este sistema de permisos. Por lo tanto, eso puede ser lo que implican hacer mal la autorización o incluso hacerla de manera deficiente.

Bien, vamos a hablar de los patrones de autorización. El primer patrón del que quiero hablar es la autorización en la capa de lógica de negocios. Ahora, si eres como yo y estás abordando un nuevo tema, probablemente lo primero que hagas es buscarlo en Google. Ahora escribes 'autorización GraphQL' y el primer resultado que aparece es GraphQL.org. Tiene una hermosa descripción conceptual sobre la autorización en GraphQL. Y comienza con una especie de regla de oro que dice: delega la autorización a la capa de lógica de negocios. Ahora, hay potencialmente dos conceptos nuevos en esto que quizás no hayas pensado antes. Uno, ¿qué significa delegar la autorización? Y dos, ¿qué es esta capa de lógica de negocios? El término capa de lógica de negocios también proviene de otra página de GraphQL.org. Esta página trata sobre cómo pensar en gráficos y presenta un diagrama arquitectónico de capas que muestra cómo se integra GraphQL en tu aplicación. Tengo mi propia versión de este diagrama para poder garabatear y dibujar cosas. Y, bueno, cuando hablo de las capas de tu aplicación, me refiero a una aplicación backend, ¿verdad? Entonces, poniendo esta imagen en contexto, tal vez se vea más o menos así. En primer lugar, a la izquierda, tal vez tengas tu cliente. Esto podría ser un navegador web o una aplicación móvil. Y todas esas cosas estarán haciendo diversas solicitudes a tu backend, a tus APIs de backend. Esas solicitudes podrían ser solicitudes REST o consultas GraphQL. La capa de lógica de negocios se encarga de manejar eso, mapeando esas solicitudes a las cosas reales que ocurren dentro de tu aplicación. Por ejemplo, si quieres obtener una organización específica, la lógica de negocios se encargaría de recopilar todos los datos relevantes para devolverlos, calcular campos, realizar transformaciones, cosas así.

En la parte inferior, la capa de persistencia es la encargada de leer y escribir datos en la base de datos. Por ejemplo, volviendo a eso, si un usuario quiere revisar una organización específica, tal vez lo haga a través de una solicitud REST, y en el backend tal vez tengamos alguna lógica de aplicación que hayamos escrito para manejar eso, que busca la organización por ese ID en la base de datos. Autoriza, ¿tiene el usuario permiso para leer esa organización? Y si no, devuelve nulo. Eso podría ser nuestro punto final REST. De manera similar, en el lado de GraphQL, ahora tenemos una consulta para una organización por un ID específico. Pero nuevamente, escribimos nuestra lógica de resolución para buscar esa organización por ese ID en particular, autorizar, ¿tiene el usuario permiso para leer esa organización? y de manera similar devolver nulo. Hasta ahora, todo bien.

Tenemos nuestra API REST, tenemos nuestra API GraphQL, tenemos autorización. No parece tan malo. Volviendo a esa página original de documentación de GraphQL.org, lo que está diciendo es que el problema aquí es que has duplicado esta lógica de autorización en varios lugares. Y destacaron esto como algo malo porque, bueno, en este caso tenemos dos lecturas, dos métodos y no puedes actualizarlos demasiado mal. Pero a medida que creces, creces tus diferentes API y puntos finales, ahora necesitas mantener todas estas diferentes declaraciones de autorización sincronizadas entre estas dos API, la REST y GraphQL.

Ahora, por qué eso es problemático es si estas cosas se desincronizan, tal vez verifiques un permiso en un lugar, verifiques un permiso diferente en otro lugar, entonces tu aplicación comienza a comportarse de manera diferente según qué API esté utilizando alguien y eso puede crear una experiencia de usuario realmente pobre. Volviendo a ese diagrama, cuando esa Regla de Oro dice delegar la autorización a la capa de lógica de negocios, lo que está hablando es empujar esa autorización hacia abajo. No manejarlo en esos controladores de API, sino empujarlo hacia abajo, manejarlo dentro de la capa de lógica de negocios. Entonces, en mi ejemplo anterior, lo que eso podría significar es que en tu método para buscar la organización por ID, tal vez ahí es donde colocas esa lógica de autorización. Entonces, cuando vayas a buscar esa organización, luego verificas si el usuario puede leerla o no. Debido a que tanto la API REST como GraphQL están llamando al mismo método, tenemos una garantía de que estarán sincronizados. Bien. Ahí lo tienes. Esa es la teoría conceptual de la autorización en GraphQL. De hecho, no lo haces realmente en GraphQL. Lo empujas hacia abajo a la capa de lógica de negocios y lo manejas allí. Entonces no tienes que repetir esa lógica varias veces. En realidad, no es solo una teoría. Creo que en la práctica, este también es un consejo fantástico. Creo que para muchas personas, esta debería ser la opción predeterminada correcta, especialmente si tienes una aplicación en la que ya tienes autorización en muchos lugares. A medida que agregas esos puntos finales de GraphQL, no quieres copiar y pegar esa lógica de autorización. Es mejor que puedas tenerla definida en un solo lugar.

Quiero ampliar brevemente este tema con algo más que creo que puede ser muy útil hacer. Antes, estábamos obteniendo una organización específica, pero ¿qué pasa si en su lugar estamos obteniendo múltiples organizaciones? Supongamos que queremos obtener las primeras 10 organizaciones, ¿verdad? Lo ingenuo sería obtener esas organizaciones y luego autorizar cada una una por una. El problema de eso es, uno, puede ser un poco lento hacer esa autorización repetidamente. Pero dos, si una de ellas no está permitida, ¿qué haces? ¿Solo devuelves nueve organizaciones en lugar de 10? ¿Devuelves un nulo? ¿Requieres que el usuario vuelva y obtenga más y así sucesivamente? Esto puede ser realmente complicado de hacer correctamente. Pero nuevamente, esa teoría anterior se aplica muy bien. Debes hacer esta autorización en esa capa de lógica de negocios. Pero en la práctica, cómo lo logras es aplicando tu lógica de autorización como un filtro a nivel de consulta. Entonces, tal vez lo que necesitas hacer es filtrar esas organizaciones por todas las organizaciones a las que pertenece el usuario. Quiero decir, tal vez tengamos, como una lista de organizaciones en el usuario.

Ahora, a medida que esa lógica de autorización se vuelve más compleja, probablemente quieras separar esa lógica también detrás de una única interfaz. Digamos, algo que pueda listar todos los IDs de organizaciones autorizadas para ti, y luego puedes filtrar la base de datos. Ese es el tipo de cosa que realmente puedes obtener de soluciones de autorización modernas como OSO. Y por lo tanto, el patrón que quiero que entiendas aquí es que cuando estés haciendo tus resolutores de consultas, un gran patrón a seguir es realizar esa autorización como parte de, digamos, obtener los datos de la base de datos. No solo para una cosa, sino también para varias cosas. Y tal vez una versión alternativa del diagrama podría tener esa autorización antes de la capa de persistencia. No lo sé. Todo como parte de esa capa de lógica de negocios.

OK. Parece que hemos cubierto todo. Como hemos hecho, devuelvan su tiempo. Pueden, ya saben, dar un paseo o algo antes de la próxima charla. No del todo. No del todo. Entonces, lo anterior, ¿verdad? Es genial en teoría y en realidad, también. Cuando comenzamos a analizar la autorización en GraphQL hace unos años, esto simplemente tenía mucho sentido para mí. Esto es genial. Resolveremos la autorización para las personas con GraphQL y no tenemos nada más que hacer. En realidad, fue mi cofundador quien me preguntó repetidamente si podríamos hacer más por la autorización en GraphQL. Cada vez que pensábamos en ello, la lógica decía que debemos hacerlo en la capa de lógica de negocios y ahí es donde encajamos de todos modos. Y sin embargo, cada vez veíamos a personas que estaban haciendo cosas personalizadas de autorización con GraphQL, nos preguntaban sobre integraciones y queríamos saber qué estaba pasando allí. ¿Por qué era esto? Y había tres razones diferentes que vimos. Así que en primer lugar, honestamente, es más fácil. En realidad, es mucho más fácil no tener esa disciplina rigurosa donde tienes perfectamente separada y desacoplada tu autorización de la lógica de manejo de resolutores y tu capa de persistencia, y una tercera. Para muchas personas, simplemente están tratando de avanzar rápido, están adoptando GraphQL y colocan su autorización en el resolutor porque es la forma más fácil de hacerlo. Y no hay ningún juicio en eso, por cierto, porque durante años, las personas han estado haciendo esto para la autorización con puntos finales REST, ¿verdad? Simplemente lo colocan en su lógica de manejo de rutas. Pueden crear middleware, hay muchas cosas diferentes que la gente hace. Y a menudo, esa puede ser la razón. La segunda que vi es tal vez un poco más fundamentada que eso, que es para las personas que adoptan GraphQL primero como empresa. Están completamente comprometidos con GraphQL, por lo que esa idea de duplicarlo entre GraphQL y REST no tiene mucho sentido para ellos porque solo están usando GraphQL de todos modos. Y eso no tiene sentido. Y veremos en un segundo por qué puede ser muy poderoso hacer la autorización en la capa de GraphQL. Creo que simplemente desde ese punto de vista, para muchas personas, lo ven como una oportunidad para hacer la autorización de manera muy limpia. Y veremos que hay algunos beneficios realmente geniales al hacer la autorización en la capa de GraphQL. Y creo que las personas están aprovechando esa oportunidad. Pienso en eso como el enfoque de GraphQL primero, donde estás diciendo que quieres hacer la autorización en GraphQL intencionalmente. Creo que, finalmente, y esta siempre es una razón fantástica en la autorización, es la defensa en profundidad. ¿Verdad? Puede ser difícil saber si has realizado la autorización correctamente en todos los lugares correctos de todo el backend, todas las diferentes rutas que necesitas manejar.

Y tener un único lugar para colocarlo, ya sea en la API REST, la API GraphQL, puede brindarte esa comodidad de saber que al menos se ha realizado cierta cantidad de autorización en un solo lugar. Entonces, el próximo patrón del que quiero hablar es cómo se ve realizar la autorización directamente en la capa de GraphQL. Y eso significa que hay un par de formas diferentes en las que podríamos hacer esto. Voy a hablar sobre el lado del resolutor. Supongamos que tenemos algunas mutaciones. Tal vez se haya creado un repositorio, se haya abierto un problema, y así sucesivamente. Y hemos implementado resolutores para cada una de esas mutaciones, ¿verdad? Eso mira los datos. Y por una de esas razones que mencioné antes, hemos realizado la autorización aquí en la capa de resolutores.

OK, hay un par de cosas que quiero señalar sobre lo que tengo aquí. En primer lugar, creo que es absolutamente crucial que, si vas a realizar la autorización en algún lugar, la abstraigas detrás de una API como esta. Realmente no puedo recomendarlo lo suficiente. Te permite mantener toda tu lógica de autorización en un solo lugar, un lugar para realizar cambios, un lugar para debug, hacer registros, y así sucesivamente. A lo largo de esta charla, ni siquiera te mostraré ninguna lógica de autorización en sí misma. Como, ya sabes, puedes hacer esto porque tienes un rol, porque aquí en la capa de integración no necesitamos preocuparnos por eso.

OK, entonces número dos, incluso con esa API en su lugar, incluso con esta llamada autorizada de una sola línea, todavía puede ser realmente tedioso revisar cada resolutor y asegurarse de haber realizado la autorización correctamente. Probablemente copiarás y pegarás, y es posible que termines cometiendo un error.

Y así, un patrón que he visto surgir para reducir esa tediosidad, para hacer esto un poco más fácil y repetible, es utilizar una directiva personalizada. No voy a profundizar en la definición de las directivas y cómo funcionan, pero supongamos que tenemos esta directiva de verificación personalizada, y lo que te permite hacer es anotar tus mutaciones con los permisos que debes verificar. Entonces, nuevamente, cuando creas un repositorio, debes verificar que el usuario tenga el permiso de crear repositorio en la organización.

Lo realmente bueno de este enfoque, si sigues este camino, es que tu esquema de GraphQL se convierte en un lugar declarativo único para asignar tus APIs de GraphQL a los permisos que necesitas para acceder a ellas. Y así, la conclusión es que la autorización a nivel de resolutor puede funcionar bastante bien. Sin embargo, recuerda que cuando teníamos la capa de lógica de negocios, teníamos dos patrones, uno era la autorización única, eso era como el filtrado de consultas. Nunca te librarás completamente de esa pieza de filtrado de datos. Puedes hacerlo de otras formas, pero nunca te librarás completamente de ello. Y por lo tanto, este patrón de autorización a nivel de resolutor solo debe usarse realmente en combinación con, por ejemplo, el filtrado en la base de datos. Y en particular, veo que esta autorización a nivel de resolutor es realmente excelente para las mutaciones. Porque a menudo son formas de tener una amplia gama de cosas diferentes que puedes hacer y diferentes verificaciones de permisos.

De acuerdo. Tengo un último patrón adicional que quiero compartir contigo. Y se trata de cómo puedes construir interfaces de usuario que sean conscientes de los permisos sin necesidad de duplicar toda tu lógica de autorización entre tu backend y frontend. La idea principal es que puedes extender tus tipos de GraphQL con un campo de permisos. Y ese campo de permisos contendrá todos los permisos que el usuario actual tiene en ese recurso en particular. Puedes ver un ejemplo de esto en la práctica. Por ejemplo, si miras la API de GraphQL de GitHub, al crear un repositorio, puedes solicitar los permisos del espectador. Y lo que obtendrás es una cadena que representa el nivel de permiso que tiene el usuario. Y ahora la idea general es que lo que una interfaz de usuario puede hacer es tomar esa información, una expresión condicional simple para decidir si tal vez debes desactivar un botón, ocultar una opción de configuración, ocultar una pestaña, cosas así.

Encuentro que este es un patrón realmente... Siento que este es un patrón muy elegante. Y en particular, es muy, muy agradable y fácil de expresar esto para GraphQL. Porque para implementar esto, todo lo que estás haciendo es tal vez extender tu resolutor con un nuevo campo de permisos. Que vas a calcular de una manera completamente diferente. Debido a que GraphQL te permite extender tus tipos con otros tipos de datos de esta manera fácilmente, puede ser muy natural simplemente inyectar este campo adicional en tus tipos. Entonces, la forma en que podrías implementar esto, nuevamente, probablemente quieras esa interfaz abstracta. Entonces, algo como acciones de lista que pueden devolver todos los permisos que el usuario tiene en un recurso en particular.

Para tal vez un modelo de autorización simple, la forma en que podrías implementarlo es verificar qué rol tiene el usuario y luego devolver los permisos que tiene ese rol. A medida que la lógica de autorización se vuelve más compleja, esto puede volverse un poco más complicado, es donde las soluciones de autorización existentes como OSO pueden ser realmente, realmente útiles.

Entonces, lo que realmente me gustaría, me encantaría que todos adopten este patrón, porque creo que es uno increíblemente poderoso. Quieres que tu backend sea la fuente de verdad para la lógica de autorización y al exponer los permisos de esta manera, te ayuda a construir interfaces de usuario realmente, realmente geniales que utilizan esos datos de permisos y extienden ese esquema.

De acuerdo, en resumen, tres patrones. Uno, realizar un filtrado de datos para permisos de nivel de lectura en la capa de lógica de negocios es una excelente manera de centralizar esa lógica en un solo lugar. Pero cuando estás pensando en realizar muchas mutaciones y tratar de determinar qué permisos debe verificar una mutación, utilizar una directiva personalizada puede ser una forma realmente agradable de gestionar eso de manera declarativa en tu esquema de GraphQL. Y finalmente, el patrón que mencioné sobre, ya sabes, exponer los permisos como parte de tu esquema de GraphQL para que las interfaces de usuario puedan construir sobre eso, creo que puede ser realmente genial para construir aplicaciones que sean muy conscientes de la autorización.

Eso es todo de lo que quiero hablar. Gracias por escuchar. Si deseas obtener más información sobre alguno de estos temas, sabes, gran parte de este contenido se basó en una publicación de blog escrita por un colega mío, Patrick, y habla sobre estos diferentes patrones de autorización en GraphQL. Si solo estás interesado en aprender más sobre autorización, solo he tocado la superficie en diferentes tipos de autorización. También hay todo lo relacionado con cómo hacer cosas como, ya sabes, roles, relaciones, atributos en la modelización lógica, cómo estructurar esto en microservicios, cosas así. Básicamente, tomamos mucho del pensamiento que hemos hecho sobre autorización y los pusimos en este conjunto de guías técnicas independientes del proveedor sobre cómo construir autorización para tu aplicación. Y finalmente, si estás buscando una forma de que otra persona resuelva esto, ya sabes, si estás escuchando esta charla y piensas, oh, Sam, solo haz que este problema desaparezca para mí, bueno, tenemos un producto llamado Oso Cloud que te ayudará con eso. Así que muchas gracias por escuchar mi charla y estaré encantado de responder cualquier pregunta en la sesión de preguntas y respuestas.