Introducción

1

Creación de APIs en Ruby on Rails: Pruebas y Autenticación

2

Verificación de Entorno para Desarrollo en Ruby y Rails

Proyecto

3

Creación de APIs con Rails: Proyecto Blog API paso a paso

4

Configuración de Gemas para Pruebas en Proyectos Rails

5

Configuración de Gemas en Proyectos Rails: Arspec, Factory Bot y Database Cleaner

6

Implementación de un Health Check Endpoint en API con RSpec

7

Diseño de Casos de Uso y Diagramas de Entidad para Aplicaciones

8

Diagrama de Entidad Relación para Modelos de Aplicación

9

Modelado de Aplicaciones con TDD en Rails

10

Validaciones y Pruebas TDD en Rails: Modelos USR y Post

11

Implementación de Endpoints para Listar y Mostrar Posts con TDD

12

Implementación de Pruebas y Controladores en Rails

13

Creación y Actualización de Posts con Pruebas TDD

14

Implementación de Métodos y Manejo de Excepciones en Rails API

15

Serialización de Modelos en Rails con ActiveModelSerializer

16

Búsqueda y Filtrado de Posts por Título con TDD

17

Implementación de Búsqueda de Posts con Servicios en Rails

18

Problema N+1 en Rails: Detección y Solución Eficaz

19

Identificación y solución del problema N+1 en Rails

20

Flujo de Autenticación en APIs con Tokens y Proveedores

21

Pruebas de Autenticación en API con Test Driven Development

22

Autenticación con Tokens: Implementación en Rails API

23

Autenticación de Usuarios en Controladores Rails

24

Autenticación y Seguridad en CRUD de Posts en Rails

25

Pruebas de Creación y Actualización con Autenticación en Rails

26

Pruebas de API con Postman: Ejecución y Verificación de Respuestas

27

Caching en Aplicaciones Web: Funciones y Niveles

28

Aceleración de Búsquedas en Rails con Caching

29

Background Jobs en Rails: Conceptos y Funcionalidades

30

Procesamiento en Background y Envío de Correos con Rails

31

Envío de Correos en Rails con ActionMailer y Background Jobs

32

Autenticación y Autorización con JWT y Auth0 en Aplicaciones Web

Cierre

33

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

Flujo de Autenticación en APIs con Tokens y Proveedores

20/33
Recursos

¿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:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Excelente explicación.

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