>
>
>
>
>
>
>
>
>
Integración de Autenticación Firebase en ASP.NET Core API: Una Guía del Grupo EBIM
Firebase, una robusta infraestructura y plataforma de desarrollo de aplicaciones de Google, se ha establecido como una herramienta esencial en el arsenal de los desarrolladores. Con una gama de servicios que incluyen almacenamiento, análisis, notificaciones y alojamiento, está especialmente diseñada para potenciar tanto aplicaciones móviles como web.
En este artículo, exploraremos cómo Firebase se integra con ASP.NET Core para la autenticación de APIs, desentrañando los detalles técnicos y las mejores prácticas para implementar esta poderosa combinación. Si buscas expertos en el desarrollo y gestión de proyectos web, te invitamos a visitar Grupo Ebim Proyectos Web.
Autenticación
Admite múltiples proveedores de autenticación, puede usar una combinación personalizada de correo electrónico / contraseña, puede conectarse a su propia tienda de usuario o puede usar proveedores de terceros, como cuentas de Google, Facebook o Twitter. Luego, en tu aplicación puedes manejar la autenticación con todos estos proveedores de manera unificada.
Un escenario típico es una aplicación web de una sola página, o una aplicación móvil, en la que el inicio de sesión ya está implementado con Firebase, por lo que la aplicación ya recibió un token de acceso JWT (llamado token de ID). Este token se puede verificar en nuestro servicio mediante una biblioteca JWT estándar, que afortunadamente ya está disponible en ASP.NET Core.
Configuración de ASP.NET
Podemos usar el paquete Microsoft.AspNetCore.Authentication.JwtBearer para asegurar la api con Firebase. Este paquete incluye un middleware para verificar automáticamente los tokens JWT que vienen en el Authorization encabezado del cliente en cada solicitud.
Solo para verificar un token de identificación, solo se tiene que conocer la parte pública de la clave asimétrica que se usa para firmar el token. Y dado que la clave pública no es un secreto, no necesitaremos una configuración segura, la clave se publica a través de un punto final público de nuestro servicio Firebase.
Configurar el middleware
Para verificar el token en el Authorization encabezado en cada solicitud, necesitamos agregar algún código a nuestra Startup clase para conectar el middleware de autenticación.
La forma de hacer esto cambió con la versión 2.0 de ASP.NET Core, en las siguientes secciones veremos un ejemplo de la configuración para ambas versiones.
.NET 2.0
En ConfigureServices método, se tiene que registrar los servicios necesarios para manejar la autenticación y especificar los parámetros de nuestro proyecto Firebase.
Luego, en nuestro Configure método, tenemos que hacer una simple llamada para registrar el middleware real que manejará la autenticación.
.NET 1.X
En .NET 1.X, toda la configuración ocurre en el Configure método, se tiene que llamar al UseJwtBearerAuthentication método de extensión para conectar el middleware y pasar los parámetros de nuestro proyecto Firebase.
Puede interesarte: Conoce las principales herramientas de desarrollo web
¿Qué hace?
En los ejemplos de código, my-firebase-project es su ID de proyecto en Firebase. El middleware verificará el Authorization encabezado en cada solicitud, verificará si está firmado con la clave privada correcta y verificará si contiene el emisor y la audiencia especificados, de modo que fue emitido específicamente por el proyecto de Firebase.
Si la verificación es exitosa, almacenará la información del usuario junto con todas sus afirmaciones HttpContext.Usery HttpContext.User.Identity.IsAuthenticated será verdadera.
Cómo proceder después de esto: puede usar el Authorize encabezado incorporado en sus controladores. Si coloca [Authorize] sobre un controlador o una acción, ASP.NET devolverá una respuesta 401 si la solicitud no tiene un token válido en el Authorization encabezado.
O puede implementar su propio código que realiza una verificación personalizada basada en HttpContext.User.
Entendido
Se debe asegurar de agregar el middleware de autenticación Jwt a la canalización antes que la canalización de enrutamiento MVC, así que tenga la línea app.UseAuthentication (o app.UseJwtBearerAuthentication(…) en el caso de .NET 1.X) antes app.UseMvc(). O si usa cualquier otro tipo de middleware que se base en la autorización HttpContext.User, eso tiene que venir en la canalización después del middleware de autenticación. Esto es importante porque lo que hace el middleware de autenticación es verificar el valor del Authorization encabezado y, en función de eso, lo completa HttpContext.User. Y eso es lo que Authorize está usando el filtro, por lo que completar estos datos debe realizarse antes de que se ejecute el middleware de enrutamiento Mvc; de lo contrario, la autorización siempre fallará.
¿Cómo funciona la firma de tokens?
El siguiente diagrama ilustra la arquitectura (simplificada) y el flujo de uso de Firebase para la autenticación desde una aplicación ASP.NET.
Durante el inicio de sesión y el acceso a un punto final seguro, están involucrados los siguientes pasos.
1. Con la aplicación se inicia (y luego también periódicamente) las JwtBearerMiddleware llamadas https://securetoken.google.com/my-firebase-project/.well-known/openid-configuration (puedes ver más detalles en el código fuente ). Desde allí, navega hacia https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com, donde se puede acceder a las claves públicas actuales de Google. Es importante que cuando se usa un criptosistema asimétrico de clave pública, la clave pública no se mantenga en secreto , sino que se publique a simple vista. Eso es lo que todos los clientes podrán usar para verificar si algo fue firmado por la clave privada (que es realmente un secreto, y solo el propietario puede tener acceso a él).
2. Un cliente inicia sesión con su credencial a través de Firebase. Firebase admite una variedad de proveedores de identidad, no importa cuál esté usando el usuario (Facebook, Google, Twitter, etc.).
3. Si el inicio de sesión fue exitoso, Firebase construye un token JWT para el cliente. Una parte crucial de este token es que está firmado con la clave privada del par de claves. A diferencia de la clave pública, la clave privada nunca se expone públicamente, se mantiene como un secreto dentro de la infraestructura de Google. Si una clave privada se ve comprometida, eso significa que cualquier atacante que tenga acceso a ella puede crear tokens JWT válidos.
4. El cliente recibe el token JWT.
5. El cliente llama a un punto final seguro en nuestra Api y coloca el token en el Authorization encabezado. En este punto, JwtBearerMiddleware en la canalización verifica este token y verifica si es válido (si se firmó con la clave privada de Google). Lo importante a tener en cuenta aquí es que, para hacer la verificación, nuestra Api no necesita tener acceso a la clave privada. Solo la clave pública es necesaria para hacer eso. Después de la verificación, el middleware se completa HttpContext.User y, en HttpContext.User.Identity.IsAuthenticated consecuencia.
En GRUPO EBIM desarrollamos soluciones TI a la medida de las necesidades de tu empresa. Somos expertos en consultoría TI y desarrollo de plataformas para SAP y Oracle; además, contamos con un equipo de profesionales dispuestos a brindar soluciones de gestión y manejo de datos. ¡Llena nuestro formulario de contacto y obtén más información sobre los servicios que ofrecemos!
