Usando PKCE para comunicarse entre React y SDKs móviles nativos

Hola a todos. Mi nombre es Itay Hansky. Soy de la empresa Scope. Y vine a hablar un poco sobre la comunicación entre aplicaciones React o aplicaciones web en general y aplicaciones nativas o SDKs. Quiero comenzar con una pregunta para que entiendan hacia dónde voy con esto. ¿Alguna vez has creado algo para la web que fuera realmente genial, pero has querido usarlo dentro de una aplicación nativa? Bueno, eso es exactamente lo que nos pasó en Scope, donde ofrecemos autenticación y gestión de usuarios como servicio. Y una de nuestras características más geniales es que puedes personalizar tu propia autenticación en nuestro editor sin código, incluyendo la interfaz de usuario y todo, y con unas pocas líneas de integración, tener una pantalla de inicio de sesión muy bonita y autenticación en tus aplicaciones web, lo cual es realmente genial, pero no queríamos dejar atrás a nuestros desarrolladores de aplicaciones nativas, así que pensamos, ¿cómo podemos llevar esta gran capacidad a nuestros desarrolladores nativos? Lo primero que consideramos fue construirlo desde cero, ¿verdad? El problema es que requiere mucho esfuerzo, tiempo y recursos, y pensamos que podríamos usarlos mejor en otro lugar.

Sé que algunos de ustedes se identificarán. Entonces, lo siguiente que consideramos fue, ¿qué tal si simplemente lo tomamos e incrustamos dentro de nuestra interfaz de usuario utilizando un WebView? Para aquellos que no lo saben, un WebView es básicamente un widget de interfaz de usuario que ejecuta una versión en miniatura del navegador, por lo que podemos hacer que el código web se ejecute allí. El problema es que los WebViews se consideran inseguros y, de hecho, algunos de nuestros métodos de autenticación simplemente no se ejecutarán si se ejecutan dentro de un WebView.

Entonces nos quedamos con el navegador, pero afortunadamente para nosotros, podemos ejecutar el navegador en un modo incrustado, lo que se siente un poco mejor para el usuario. No parece que estés saliendo de la aplicación cuando realmente cambias al navegador. Parece que es parte de la aplicación, aunque técnicamente se está ejecutando en un proceso diferente.

Bien, genial. Entonces tenemos nuestras soluciones listas, así que supongo que todo lo que tenemos que hacer es lanzar nuestro navegador incrustado, Safari o Chrome, y ejecutar nuestro flujo, y luego obtener la devolución de llamada de alguna manera en nuestro código nativo o ejecutar algún JavaScript o hackearlo. Bueno, desafortunadamente, los procesos móviles están completamente aislados. Eso significa en términos simples que no puedes acceder realmente a los datos entre procesos, y eso es una buena noticia para nosotros, los usuarios del teléfono móvil, porque de lo contrario las cosas serían un desastre.

Entonces, ¿qué podemos hacer? Podemos iniciar el navegador, podemos lanzarlo, ¿verdad? Entonces, ¿cómo obtendríamos algo de vuelta en la capa nativa? Podemos utilizar deep links. Los deep links son una forma para que las aplicaciones móviles declaren que pueden manejar ciertas URL en lugar de abrirlas en el navegador. Piensa en la última vez que recibiste un mensaje de texto con un enlace de YouTube y cuando hiciste clic en él, se abrió la aplicación, ¿verdad? No el navegador. Es el mismo concepto aquí.

Bien, genial. Ahora tenemos una forma de volver a nuestro código nativo, pero no podemos simplemente enviar la sesión en la URL de redireccionamiento porque eso es completamente inseguro. Deberíamos tener algún tipo de protocolo de intercambio en su lugar, y ahí es donde entra Pixie. Pixie o PKCE es un protocolo interesante. Significa Proof-of-Key Code Exchange (Intercambio de Código de Prueba de Clave), y puedes implementarlo en cualquier momento que lo necesites. Está orientado hacia dispositivos móviles, pero no necesariamente. Voy a explicar los principios de Pixie en general para que lo entendamos, y luego te mostraré cómo lo usamos para ejecutar flujos en nuestras aplicaciones nativas. Entonces, Pixie funciona así. El cliente genera el código. Esto se considera una clave. Es solo una matriz aleatoria de bytes y se realiza un hash de esta clave. Este hash es donde todo comienza. Esto se considera el desafío. Este desafío se envía al servidor. La comunicación es base64. Pero no quiero centrarme en eso, porque es solo una capa de cifrado y no es interesante.

Pero no quiero centrarme en eso, porque es solo una capa de cifrado y no es interesante. El desafío es recibido por el servidor, se guarda y el servidor responde con su propio código generado. Así que genera una cadena aleatoria. Se llama código de autorización y eso es lo que responde el cliente. Para completar el protocolo, el intercambio, el cliente toma el código de autorización recién recibido y envía la clave original, la versión no hasheada. Ahora el backend puede comparar los códigos y hashear el verificador, la clave original, y compararlo con el desafío que había guardado. Si todo coincide, tenemos un intercambio exitoso y todos están contentos. Pero si algo está desalineado, todo se borra y hay que empezar de nuevo. Y lo bueno de este protocolo, si te das cuenta, es que el cliente nunca envía lo mismo en el canal de comunicación. No puedes deducir realmente el verificador del desafío, ¿verdad? Así es como funcionan las funciones de hash, de lo contrario estaríamos en grandes problemas. Por lo tanto, obtenerlo en medio de este protocolo es bastante difícil y hace que las cosas sean muy seguras. Entonces, ¿cómo lo usamos? Porque en realidad no tenemos un cliente, ¿verdad? Tenemos esta cosa híbrida de código nativo y React. La parte nativa inicia el proceso, como vimos en Pixie. Lo mismo crea el verificador, esa clave, y lo hashea, el desafío. Pero ahora, en lugar de enviarlo directamente al servidor, lanzamos nuestro navegador y colocamos el desafío en los parámetros de la URL. Y también agregamos un deep link, el que mencioné anteriormente, para que el servidor sepa cómo comunicarse de vuelta con el código nativo. Lo colocamos en los parámetros de la URL. Nuestra aplicación React, todo lo que tiene que saber es qué parámetros de URL tomar y enviarlos al backend, al servidor. Más allá de eso, no importa realmente, la aplicación React puede ejecutarse como lo haría normalmente, ejecutar el flujo con todas sus configuraciones. Y una vez que el usuario se autentica correctamente, luego reanudamos el protocolo. Luego, el servidor puede generar su código de autorización. Pero en lugar de enviarlo a la aplicación React en nuestro navegador, puede utilizar el deep link que tiene para llegar hasta el código nativo, que toma el código de autorización y ahora puede enviar el verificador y el código de autorización directamente de vuelta al servidor para un intercambio exitoso y ahora tenemos flujos web ejecutándose en nuestro código nativo. Si alguien tiene más preguntas sobre esto o sobre PKC en general, estaré encantado de responder. Estamos en un stand justo afuera. Muchas gracias a todos.