Autenticación y Autorización de GraphQL a Escala

Hola a todos, y bienvenidos a mi charla sobre Autenticación y Autorización de GraphQL a gran escala. Mi nombre es Jonny Green y soy un Ingeniero de Software Senior en Unity Technologies y también un desarrollador de código abierto.

Antes de comenzar, me gustaría discutir rápidamente la agenda. Esto nos ayudará a establecer el contexto para la solución y el diseño que discutiremos más adelante. Primero, hablaremos sobre GraphQL en Unity. Presentaré nuestro equipo y algunas de las cosas que hacemos, así como nuestra pila tecnológica para que tengan una idea de cómo trabajamos e implementamos GraphQL.

A continuación, discutiré el problema que queríamos resolver con la autenticación, especialmente a gran escala. Hablaré sobre los problemas que encontramos y los beneficios que buscamos obtener. Luego, hablaré sobre el diseño, los detalles del diseño y cómo resuelve nuestro problema original y nos brinda los beneficios que buscamos. Finalmente, les mostraré la solución, incluida la implementación y un breve ejemplo para que tengan una idea de cómo implementamos esto en Unity.

En cuanto a GraphQL en Unity, trabajo en el equipo de plataforma en vivo, donde nuestro objetivo principal es exponer la funcionalidad empresarial a los clientes a través de un esquema centralizado de GraphQL. Utilizamos GraphQL Federation, donde tenemos una puerta de enlace y varios servicios que exponen diferentes partes del negocio. Los clientes se comunican con el esquema centralizado, que consideran como los contratos principales, para acceder a la funcionalidad empresarial que necesitan.

También estamos trabajando activamente en mejorar nuestras opciones de autoservicio. A medida que recibimos más solicitudes de los clientes, queremos que ellos mismos puedan hacer el trabajo. Si desean exponer una nueva funcionalidad empresarial, les proporcionamos instrucciones para que puedan implementarla por sí mismos de manera compatible con GraphQL y aprovechar todos los beneficios y herramientas que hemos desarrollado. También estamos buscando automatizar gran parte de esto. Muchas de estas tareas son bastante genéricas y se estandarizan por convención, lo que nos permite generar todo este código y facilitar la vida de los nuevos desarrolladores. Les decimos que si desean crear un nuevo servicio, simplemente ejecuten este comando y listo. Tendrán todo el servicio configurado y listo para implementar.

En cuanto a nuestra pila tecnológica, utilizamos Node.js y TypeScript, que nos han funcionado muy bien. Además, utilizamos el servidor de GraphQL Mercurius tanto para nuestros servicios como para nuestra puerta de enlace.

La razón por la que elegimos Mercurius es su fantástica comunidad de código abierto, en la que realmente confiamos y nos gusta. Además, Mercurius proporciona toda la funcionalidad que necesitamos y más. Por lo tanto, pensamos que era una elección obvia y hasta ahora ha sido fantástico.

También utilizamos GraphQL Federation. Como mencioné antes, exponemos la funcionalidad empresarial a gran escala a través de una puerta de enlace central con muchos servicios. Muchos de estos servicios proporcionan funcionalidad que puede estar relacionada con otras partes de la funcionalidad. Por lo tanto, no solo federamos el gráfico y todos los gráficos individuales en un solo gráfico grande, sino que también aprovechamos las características de federación, como si tenemos un usuario con un cierto conjunto de detalles que proviene de otro servicio, podemos proporcionarlo a través de GraphQL Federation.

A continuación, me gustaría discutir un problema, y es el manejo de la autenticación a gran escala. Cuando comenzamos, todos nuestros servicios tenían autenticación. Esto significa que todos los servicios tenían que implementar el mecanismo de autenticación, definir su definición de política de autenticación y también definir todos los campos que deseaban proteger. Y eso es bastante trabajo para un servicio cuando realmente queremos escalar esto a largo plazo. Queremos quitarles mucha de esta responsabilidad a los servicios y asegurarnos de que la implementación sea realmente simple, y que solo se preocupen por la lógica empresarial que están exponiendo.

Además, tenemos múltiples servicios y también múltiples equipos. Tenemos muchos nuevos colaboradores fuera de nuestro equipo que están contribuyendo con nuevos servicios a nuestro sistema federado. Y esto conlleva sus propios problemas. Los diferentes equipos pueden utilizar diferentes pilas tecnológicas y diferentes modelos de autenticación. Y para los clientes, no necesariamente saben cómo se protegen los campos o qué campos están protegidos. También queremos resolver esto. Queremos asegurarnos de tener un modelo de autenticación consistente en todos los servicios a los que todos se adhieren. Y también queremos presentar toda esta información a los clientes. Si un servicio protege un cierto campo de cierta manera, queremos informar a los clientes al respecto para que sepan cómo manejar todos los errores y cómo integrarse con nuestro sistema. En cuanto a los beneficios que buscamos, también queremos estar más cerca de los mecanismos de autenticación que proporciona Unity. Actualmente, los servicios están bastante alejados del punto final de autenticación de Unity con el que interactúan. Queremos estar más cerca de eso, lo que nos dará un mejor rendimiento, pero también nos permitirá optimizar, por ejemplo, cuántas solicitudes hacemos a este punto final y cómo solicitamos este punto final. También queremos tener una política única. Básicamente, queremos controlar la política centralizada y decirle a los servicios cómo acceder a ella. Todos los servicios utilizan la misma definición de política y, siempre que se adhieran a ella, estamos listos para continuar.

Pueden proteger los campos de la misma manera, exactamente como deseen. Esto hace que la integración sea realmente simple porque solo necesitan preocuparse por la configuración y eso es todo. Luego pueden centrarse en las funcionalidades empresariales y no preocuparse por cómo interactuar con el punto final de autenticación. Ya ha sucedido.

Otro beneficio que queremos tener es que cualquier solicitud de la puerta de enlace a los servicios ya esté autenticada y suficientemente autorizada. Actualmente, con los servicios que se ejecutan a nivel de servicio, no tenemos esto. Por lo tanto, también queremos proporcionar esto.

El siguiente paso lógico es llevar esto al nivel de la puerta de enlace, lo cual tiene varios beneficios. Ahora pueden ver aquí que todo lo que los servicios necesitan hacer es simplemente definir las políticas que les interesan. Por ejemplo, si desean proteger un campo específico y hacer que solo sea autenticado, solo necesitan agregar una directiva de GraphQL a ese campo y listo. De manera similar, si desean autorización, solo necesitan una directiva de GraphQL con una configuración ligeramente diferente para decir que desean ciertos permisos. Y también estarán listos. Desde el punto de vista del servicio, es solo configuración.

Desde el punto de vista de la puerta de enlace, debemos decirle a la puerta de enlace cómo encontrar las políticas de servicio, cómo registrar las políticas y cómo aplicar las políticas a una solicitud de GraphQL. Ahora, con las directivas de GraphQL, podemos hacer esto. Por lo tanto, no solo es realmente simple para los servicios, sino que también es muy simple para la puerta de enlace, porque solo necesita buscar en el esquema federado que ha generado y, según la directiva de autenticación que encuentre, puede crear una política en consecuencia.

Entonces, ¿cómo resuelve el problema? Como pueden ver, hemos trasladado gran parte del trabajo al nivel de la puerta de enlace y desde el punto de vista del servicio, todo lo que necesitan hacer es preocuparse por la configuración. No solo eso, la configuración también está en el esquema de GraphQL. Esto significa que los servicios se pueden implementar con la pila de tecnología que elijan. Siempre que proporcionen un esquema de GraphQL, estarán listos para continuar. Y eso es realmente poderoso para nosotros, porque nos permite escalar verdaderamente con todos los servicios que queremos. Podrían escribirlo en Rust y no importaría. Siempre que apliquen la misma definición de política de autenticación a su servicio, a su servicio de GraphQL, eso es todo de lo que necesitan preocuparse.

Entonces, ¿qué necesitamos hacer? Antes de implementar esto, necesitábamos agregar algunas características a Mucurious para mantener el enfoque lo más simple posible y realmente hacer que este enfoque sea escalable.

Entonces, una de las primeras cosas que investigamos fue agregar los Hooks de Mucurious. Estos son eventos del ciclo de vida dentro de Mucurious que indican, bueno, indican los puntos en los que, los puntos importantes dentro de la solicitud de GraphQL, y también un sistema. Por ejemplo, cuando una puerta de enlace actualiza su esquema, queremos saber eso, queremos poder proporcionar funcionalidad en ese evento. Por lo tanto, necesitábamos implementar eso, pero también necesitábamos implementar un complemento Orth. Este sería un complemento opcional que utilizaría el sistema de complementos de Fastify para mejorar el servidor de Mucurious con la capacidad de agregar controladores de políticas Orth, buscar ciertas directivas Orth, y también agregar información de usuario al contexto para permitir el manejo de políticas Orth para obtener toda la información que necesiten. Y luego, desde el punto de vista de Unity, necesitamos definir nuestro propio controlador de políticas que interactúe con el punto final Orth de Unity. Y también necesitamos definir todas las políticas a nivel de servicio. Por lo tanto, necesitamos registrar estas configuraciones y básicamente proteger todos los campos que necesitamos proteger en los servicios. Y todos estos utilizarían una definición de política centralizada. Por lo tanto, todos utilizarían la misma directiva de GraphQL. Y siempre que se adhieran a esa directiva, como dije antes, estarán listos para continuar.

Entonces, la solución. Con Mercurius Orth, desde un nivel alto, básicamente lo que estamos haciendo es recorrer el esquema de GraphQL y esto se hace todo en la puerta de enlace. Recorremos el esquema de GraphQL y buscamos directivas Orth. Y dependiendo de los argumentos de la directiva que se le pasen, entonces definiríamos una política de acuerdo a esa posición dentro del esquema de GraphQL.

Y a partir de esto, simplemente seguimos recorriendo todo el esquema de GraphQL. Buscamos todos los campos protegidos, y protegemos campos y tipos. Y a partir de eso construimos un esquema Orth. Luego recorremos este esquema y envolvemos todos los resolvedores de campo relevantes con el controlador de políticas Orth. De manera que este controlador de políticas Orth se configure con la configuración que registramos a través de las directivas GraphQL.

Ahora, gran parte de este trabajo, obviamente no queremos recorrer el esquema de GraphQL en cada solicitud. Por lo tanto, gran parte de este trabajo se realiza en el momento del registro. Para cuando llega una solicitud de GraphQL, los resolvedores de campo ya están envueltos y todo lo que se ejecuta es solo la definición de políticas Orth con la configuración correcta que se le pasa. Puedes obtener más información sobre esto en GitHub, así que puedes ver mecuriousjs/Orth. Si quieres echar un vistazo al código o discutirlo más a fondo, puedes consultarlo allí.

A continuación, está el uso en Unity. Como mencioné antes, también necesitamos implementar algunas cosas específicas de Unity. Ya teníamos un punto final Unity Orth listo para usar. Entonces nuestro controlador de políticas Unity que escribimos básicamente interactuaba con ese punto final, y todo esto estaría a nivel de la puerta de enlace. También definimos una definición central de directiva Unity Orth, y eso estaría bajo nuestro control. Entonces, si necesitamos evolucionar el esquema, los servicios automáticamente adoptarían la directiva central Orth de una manera compatible con la evolución del esquema. Y siempre y cuando se adhieran a esta directiva central definición, estarán listos para continuar. Y luego, sí, como mencioné antes, solo necesitábamos definir las directivas Unity Orth de manera que protegiéramos los campos específicos de la manera correcta que necesitaban ser protegidos. Y eso es todo. En realidad, fue una implementación bastante sencilla al final, simplemente porque hicimos gran parte del trabajo dentro del complemento Mercurius Orth y también manejando los hooks de Mercurius. Entonces, como ejemplo simple, pensé en proporcionarte este enfoque que es muy similar a lo que hicimos en Unity, solo para darte una idea de cómo lo hicimos. Puedes encontrar esto en GitHub. Así que únete a green/Oracle galaxy demo. Y sí, si quieres ver el código, puedes consultarlo allí. Entonces, ¿qué tenemos? Tenemos un sistema federado. Tenemos una puerta de enlace y luego detrás de eso se encuentra un servicio de usuario y publicación.

Como parte de esta demostración, definiremos AuthPolicyHandler y también un AuthDirective, que ambos servicios de aguas abajo utilizan y luego la puerta de enlace recoge automáticamente estas definiciones de AuthDirective. Por lo tanto, una charla sobre GraphQL no estaría completa sin un esquema de GraphQL.

Aquí tenemos el esquema del servicio de usuario. Puedes ver aquí que tenemos la definición de AuthDirective y esto sería lo mismo en todos los servicios. Y esto es algo que controlamos nosotros. Por lo tanto, esto está completamente centralizado. Y cada vez que lo evolucionamos, lo hacemos de la manera correcta, de modo que cuando los servicios adoptan la evolución, lo tienen de inmediato y solo necesitan cumplir con esa definición de directiva. Sí, tenemos esa definición de directiva y tenemos el uso aquí. Estamos protegiendo la consulta 'me' con la política de autenticación que requiere un rol de usuario. Y eso es todo. Eso es todo lo que el servicio necesita hacer. Todo está en el mundo de GraphQL, en la configuración y no necesitan hacer más. De manera similar para el servicio de publicación, también tenemos la definición de autenticación y también tenemos los usos del servicio de publicación. Por lo tanto, podemos ver que estamos protegiendo el campo de autor con el rol de administrador. Y también tenemos el campo de publicación que también estamos protegiendo con el rol de administrador. Estos son campos más sensibles que queremos proteger con un rol diferente como los usuarios administradores. Por lo tanto, puedes ver aquí, estos son los que queremos proteger.

Y finalmente, tenemos el registro en la puerta de enlace. Por lo tanto, puedes ver que esto es lo más simple posible. He omitido toda la configuración adicional que es bastante estándar en Mercurius y la configuración de Fastify. Esto es específico de Mercurius auth. Como se mencionó antes, hay varias cosas que debemos hacer. Tenemos el contexto de autenticación que examina las cabeceras de la solicitud y simplemente aplica una identidad al contexto que indica que este es el usuario de las cabeceras. Y luego tenemos el controlador de políticas. Aquí verás que es muy similar a un resolvedor de GraphQL.

Entonces, los cuatro parámetros finales son simplemente la información del padre, la información del argumento, el contexto y la información. Así que tienes todo lo que necesitas desde ese punto de vista. Y también proporcionamos el AST de la directiva de autenticación para decir, esta es la configuración aplicada a este campo. Entonces, aquí es lo que estamos haciendo, estamos obteniendo los roles utilizando la identidad y nos aseguramos de que la directiva de autenticación coincida con los roles del usuario. Y sí, podemos hacer lo que queramos en esta política y depende completamente de ti. Lo hemos dejado completamente flexible. Por lo tanto, puedes llamar al mecanismo de autenticación que desees con toda la información que necesitas de las premisas.

Y aquí estamos diciendo, busquemos la directiva de autenticación dentro de la puerta de enlace. Ahora aquí, pensé en dar algunos ejemplos de solicitudes. Así que tenemos acceso completo a los campos. Una revisión de usuario y administrador, y podemos ver que tenemos los data como de costumbre. Y luego aquí tenemos acceso parcial. Entonces podemos ver que tenemos una solicitud con solo un rol de usuario y podemos ver que ya no tenemos acceso a las publicaciones y podemos ver aquí, está establecido en nulo con el error asociado. Y finalmente, tenemos una solución sin acceso a los campos. Así que esta es una solicitud autenticada. Podemos ver que no hay data. Tenemos ambos errores que nos indican qué hacer.

Entonces, en resumen, hablamos sobre el complemento de autenticación de Mercurius. Hablamos sobre cómo definimos la definición de autenticación central y básicamente, siempre que los servicios de aguas abajo se adhieran a un esquema reconocido, este es un enfoque escalable para la autenticación. Realmente creemos en esto y realmente hemos estado viendo los beneficios dentro de nuestro sistema. En cuanto a las mejoras, estamos agregando muchas características todo el tiempo al complemento de autenticación de Mercurius. Entonces, una de las cosas que está sucediendo en este momento es agregar soporte para un esquema de filtro. Entonces solo verás partes en el esquema a las que tienes autenticación. Y eso es todo. Muchas gracias por escuchar mi charla. Ha sido realmente genial hablar contigo y personalmente, estoy muy emocionado con este trabajo y solo espero que hayas sacado algo de él. Así que gracias por escuchar y espero verte en el resto de la conferencia. Muchas gracias.