Excelente explicación.
Introducción
Creación de APIs en Ruby on Rails: Pruebas y Autenticación
Verificación de Entorno para Desarrollo en Ruby y Rails
Proyecto
Creación de APIs con Rails: Proyecto Blog API paso a paso
Configuración de Gemas para Pruebas en Proyectos Rails
Configuración de Gemas en Proyectos Rails: Arspec, Factory Bot y Database Cleaner
Implementación de un Health Check Endpoint en API con RSpec
Diseño de Casos de Uso y Diagramas de Entidad para Aplicaciones
Diagrama de Entidad Relación para Modelos de Aplicación
Modelado de Aplicaciones con TDD en Rails
Validaciones y Pruebas TDD en Rails: Modelos USR y Post
Implementación de Endpoints para Listar y Mostrar Posts con TDD
Implementación de Pruebas y Controladores en Rails
Creación y Actualización de Posts con Pruebas TDD
Implementación de Métodos y Manejo de Excepciones en Rails API
Serialización de Modelos en Rails con ActiveModelSerializer
Búsqueda y Filtrado de Posts por Título con TDD
Implementación de Búsqueda de Posts con Servicios en Rails
Problema N+1 en Rails: Detección y Solución Eficaz
Identificación y solución del problema N+1 en Rails
Flujo de Autenticación en APIs con Tokens y Proveedores
Pruebas de Autenticación en API con Test Driven Development
Autenticación con Tokens: Implementación en Rails API
Autenticación de Usuarios en Controladores Rails
Autenticación y Seguridad en CRUD de Posts en Rails
Pruebas de Creación y Actualización con Autenticación en Rails
Pruebas de API con Postman: Ejecución y Verificación de Respuestas
Caching en Aplicaciones Web: Funciones y Niveles
Aceleración de Búsquedas en Rails con Caching
Background Jobs en Rails: Conceptos y Funcionalidades
Procesamiento en Background y Envío de Correos con Rails
Envío de Correos en Rails con ActionMailer y Background Jobs
Autenticación y Autorización con JWT y Auth0 en Aplicaciones Web
Cierre
Creación de APIs con Rails: Buenas Prácticas y Features Avanzados
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Flujo de Autenticación en APIs con Tokens y Proveedores
20/33Recursos
¿Cómo funciona el flujo de autenticación en aplicaciones API?
Iniciar sesión en una aplicación web es un proceso que involucra varios componentes clave para garantizar la protección y autenticación adecuada del usuario. Tanto si estás desarrollando una aplicación de página única (SPA) como un sistema más tradicional, comprender el flujo de autenticación es esencial para el diseño seguro de cualquier aplicación.
¿Cuál es el papel del frontend en la autenticación?
Inicialmente, todo comienza en el navegador, donde el usuario interactúa con el frontend de la aplicación, usualmente una Single Page Application (SPA) implementada con JavaScript. Este frontend es el encargado de inicializar el proceso de autenticación enviando una petición al backend de la aplicación.
- Inicio de sesión: Durante esta petición inicial, el SPA envía las credenciales del usuario —nombre de usuario y contraseña— al backend.
- Verificación de credenciales: El backend verifica estas credenciales contra una base de datos para determinar su validez.
¿Cómo maneja el backend las credenciales del usuario?
Al recibir las credenciales del usuario, el backend busca en su base de datos para validar si el usuario existe y si las credenciales proporcionadas son correctas. De ser así, el backend generará un token de autenticación.
- Generación de token: El token actúa como un identificador único para la sesión del usuario. Es un string que el cliente utilizará para autenticarse en futuras solicitudes.
- Retorno del token: Este token se envía de regreso al cliente (navegador), habilitando futuras interacciones sin repetida autenticación.
¿Cómo se manejan las solicitudes futuras con autenticación?
Una vez el token de autenticación es recibido por el cliente, este se utiliza en todas las peticiones futuras a la aplicación.
- Uso del token: En operaciones posteriores, como editar un blog post, el cliente envía el token al backend para verificar la sesión activa.
- Verificación del token: El backend utiliza el token para validar la autenticación y decidir si otorga acceso a los recursos solicitados.
¿Qué alternativas existen para la autenticación y autorización?
Además de implementar tu propio sistema de autenticación, puedes optar por proveedores externos, como Auth0, para manejar este proceso.
- Confiabilidad: Los proveedores de autenticación son reconocidos por sus altos estándares de seguridad, brindando a los usuarios más confianza en la protección de sus datos.
- Procesamiento de login por proveedores: Con un proveedor, las peticiones de autenticación van directamente al servicio externo, el cual maneja el proceso de verificación y generación de tokens de autenticación.
¿Qué tipos de tokens se utilizan?
La autenticación puede manejarse con diferentes tipos de tokens, cada uno con sus características propias en gestión de sesiones y seguridad.
- Tokens auto-contenidos: Contienen toda la información necesaria internamente, evitando consultas adicionales.
- Tokens referenciales: Necesitan validar la información con el proveedor externo para confirmar su validez.
Con la comprensión de este flujo, los desarrolladores pueden asegurar que las aplicaciones gestionen de manera efectiva la autenticación y autorización, protegiendo así tanto los datos del usuario como los recursos del sistema. Implementar soluciones modernas y seguras, como el uso de proveedores de autenticación, es particularmente útil para fortalecer la confianza y la seguridad de las operaciones de una aplicación.
Aportes 4
Preguntas 1
Ordenar por:
En el minuto 7:00 cuando se usa byebug he encontrado que no es necesario realizar el require 'byebug' para su uso.
Para quienes como yo quedaron con la duda sobre rails dev:cache. Este comando crea un archivo llamado tmp/caching-dev.txt, que luego es verificado sí existe por el archivo de configuración config/environments/development.rb de la siguiente manera:
...
# Enable/disable caching. By default caching is disabled.
# Run rails dev:cache to toggle caching.
if Rails.root.join('tmp', 'caching-dev.txt').exist?
config.action_controller.perform_caching = true
config.cache_store = :memory_store
config.public_file_server.headers = {
'Cache-Control' => "public, max-age=#{2.days.to_i}"
}
else
config.action_controller.perform_caching = false
config.cache_store = :null_store
end
....
Como se puede apreciar, al no existir el archivo tmp/caching-dev.txt, la cache estaba desactivada (config.cache_store = :null_store) por default.
El usar un autentificador es bueno pero no limitaría a los usuarios únicamente a usar ese servicio en espesifco? seria bueno que esa fuera una de varias formas de hacer login y usar un manejado de sesiones como CASino
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?