node.js - tutorial - Autenticación con React Native y API backend

react express api (1)

Estoy tratando de entender mi oauth con una aplicación React Native y un backend NodeJS / Express API separado. Entiendo que https://github.com/adamjmcgrath/react-native-simple-auth ofrece autenticación para una aplicación React Native y http://passportjs.org/ ofrece autenticación para un backend NodeJS. No estoy seguro de cómo conectar estos dos para la autenticación para el inicio de sesión y el acceso a la API.

Me gustaría que los usuarios inicien sesión en la aplicación React Native ya sea por correo electrónico y contraseña o por Facebook / Twitter / Google. Una vez que inicie sesión en la aplicación, ¿qué envío a la API para asegurarme de que estén autenticados y tengan acceso a una ruta específica?

Aquí hay un ejemplo de flujo para iniciar sesión y ver la configuración del usuario conectado:

El usuario inicia sesión en la aplicación React Native por correo electrónico / contraseña o Facebook / Twitter / Google.
El usuario esta autenticado
La aplicación solicita GET / api / settings
La API verifica que el usuario esté autenticado y devuelve la configuración de ese usuario o la API verifica que el usuario no está autenticado y devuelve un 403.

Hay muchas cosas en esta pregunta, tanto que no encajaría en una sola respuesta SO, pero aquí hay algunos consejos y un resumen general que debe encajar ampliamente en lo que desea lograr.

Autorización OAuth2

Por lo que parece, le interesa utilizar OAuth 2 para proporcionar autorización de inicio de sesión social, y le gustaría realizar una autenticación de primera parte como alternativa con un correo electrónico y una contraseña. Para los inicios de sesión sociales, terminará usando el flujo implícito de OAuth 2 para recuperar un token de acceso, que es un patrón ampliamente reconocido. Debido a que también está buscando autenticar a los usuarios con un correo electrónico y una contraseña, es posible que desee familiarizarse con OpenID Connect, que es una extensión de OAuth 2 y que admite explícitamente la autenticación además de la autorización.

En cualquier caso, una vez que su usuario haya enviado un combo de correo electrónico / contraseña u otorgado permiso a través de los proveedores de identidad social, recibirá en respuesta un token de acceso y (opcionalmente) un token de identificación . Los tokens, probablemente un JWT (JSON Web Token, vea jwt.io ) aparecerán como una cadena codificada en base64 que puede decodificar para inspeccionar los resultados del JWT, que incluirá cosas como la ID del usuario y otros detalles como dirección de correo electrónico, nombre, etc.

Para obtener más información sobre los diferentes tipos de flujos, consulte este excelente resumen sobre Digital Ocean .

Uso de tokens para la autenticación de API

Ahora que tiene un token de acceso, puede pasarlo junto con todas las solicitudes a su API para demostrar que se ha autenticado correctamente. Para ello, pasará el token de acceso en sus encabezados HTTP, específicamente el encabezado de Authorization , antes del token de acceso codificado en base64 (lo que recibió originalmente en respuesta a su solicitud de autorización) con Bearer . Entonces el encabezado se ve así:

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJh...

En el lado de su API, recibirá ese token, lo decodificará y luego verificará la ID y las reclamaciones en él. Pasado como parte del token en la propiedad sub será el sujeto o ID del usuario que realiza la solicitud. Así es como identifica el acceso y comienza a hacer cosas en su lado API con los derechos, permisos, etc. del usuario respectivo. También es importante que valide el token de acceso una vez que lo reciba en su lado API, para asegurarse de que no falsificado o hecho a mano.

Cómo se ve en RN para flujos implícitos

Así es como se ve el proceso general en React Native para flujos implícitos de OAuth 2, que es lo que usará para los proveedores de identidad social:

El usuario toca uno de sus botones de inicio de sesión social en React Native UI
Su código que responde a los botones creará una URL de solicitud para esos proveedores, dependiendo de lo que cada uno quiera (porque difiere ligeramente).
Usando la API de enlace en RN, abrirá esa URL en un navegador en el dispositivo que envía al usuario al proveedor social para que haga el baile de inicio de sesión / autorización.
Una vez completado, el proveedor social redirigirá al usuario a una URL que su proveedor. En un dispositivo móvil, usará su propio esquema de URL personalizado para mover al usuario de la vista web a su aplicación. Este esquema es algo que registra como parte de su aplicación, como my-awesome-app:// , y la URL de redireccionamiento que pasa al proveedor social podría verse como my-awesome-app://auth_complete/ . Consulte los documentos de API de enlace para ver cómo configurar estos esquemas de URL y enlaces profundos.
En el controlador para ese nuevo esquema de URL / enlace profundo, obtendrá los tokens pasados como parte de la URL. Ya sea a mano o usando una biblioteca, analice los tokens de la URL y guárdelos en su aplicación. Es en este punto que puede comenzar a inspeccionarlos como JWT y pasarlos en los encabezados HTTP para el acceso a la API.

Cómo se ve en RN para los flujos de concesión de contraseña del propietario del recurso

Tiene la opción de su combinación de correo electrónico / contraseña para sus propias cuentas, ya sea para seguir con el flujo implícito o cambiar al flujo de concesión de contraseña del propietario del recurso si su API y su aplicación son confiables, lo que significa que está haciendo la aplicación y la API. Prefiero el flujo de ROPG en las aplicaciones móviles siempre que sea posible porque la experiencia de usuario es mucho mejor: no tiene que abrir una vista web separada, solo tiene que escribir su correo electrónico y contraseña en los elementos de la interfaz de usuario directamente en la aplicación. Dicho esto, así es como se ve:

El usuario toca el botón de inicio de sesión combinado de correo electrónico / contraseña, y RN responde con una interfaz de usuario que incluye entradas de texto para el correo electrónico y la contraseña
Cree una solicitud POST a su servidor de autorización (que puede ser su API, o puede ser un servidor separado) que incluya la URL y los detalles del cuerpo correctamente diseñados que pasan junto con el correo electrónico y la contraseña. Dispara esta solicitud.
El servidor de autenticación responderá con los tokens asociados en el cuerpo de la respuesta. En este punto, puede hacer lo mismo que se hizo anteriormente en el paso 5 anterior, donde almacena los tokens para su uso posterior en las solicitudes de API e inspecciona la información relevante del usuario.

Como puede ver, el ROPG es más sencillo, pero solo debe usarse en escenarios altamente confiables.

En la API

En el lado de la API, inspecciona el token en el encabezado de Autorización y, como se mencionó anteriormente, y si lo encuentra, asume que el usuario ha sido autenticado. Todavía es una buena práctica de seguridad validar y verificar el token y los permisos de usuario. Si no hay token enviado con la solicitud, o si el token enviado ha expirado, entonces rechaza la solicitud.

¡Espero que ayude! Ciertamente hay mucho, pero eso proporciona un esquema general.