Spring Security: quién sos y qué podés hacer

Autenticación y autorización sobre el mismo contenedor didáctico de Spring Boot: UserDetailsService, @PreAuthorize, 401 contra 403, y por qué OAuth2/JWT se enseñan por lectura.

14 aulas · 9 horas de práctica · en el navegador, sin instalar nada

Temario

  1. Autenticación y autorización: dos preguntas distintas — Todo lo que ya sabés de spring-boot (@RestController, @GetMapping, @Service) responde igual sin importar quién pregunta. Este curso agrega exactamente dos preguntas nuevas: ¿quién sos? (autenticación) y ¿qué podés hacer? (autorización) — y por qué son preguntas DISTINTAS.
  2. UserDetailsService simulado: usuario encontrado o no encontrado — UserDetailsService y UsuarioSimulado los declara el motor, igual que CrudRepository — el alumno implementa la interfaz con un @Component: típicamente un mapa en memoria usuario -> UsuarioSimulado, con sus roles.
  3. Verificar contraseña (y por qué nunca en texto plano) — verificarContrasena compara texto plano a propósito, para poder ejecutar de verdad en este motor — y es EXACTAMENTE la mala práctica que evitar en un backend real, donde se guarda un hash (BCrypt) y se compara el hash, nunca la contraseña.
  4. @PreAuthorize y el primer 403 — @PreAuthorize("hasRole('X')") sobre un método de ruta corre ANTES que el método mismo: si el usuario autenticado no tiene ese rol, ni siquiera llega a ejecutarse — responde 403 directamente.
  5. 401 contra 403: dos códigos, dos preguntas distintas — 401 significa "no sé quién sos" (sin usuario, o con un usuario que no existe: dos motivos, el mismo código). 403 significa "sé quién sos, y no podés". Confundirlos en una API real es un error de diseño, no un detalle.
  6. hasAnyRole: varios roles válidos para el mismo endpoint — @PreAuthorize("hasAnyRole('ADMIN','SOPORTE')") deja pasar a un usuario que tenga CUALQUIERA de los roles listados — no hace falta tener los dos. Un error muy común es usar hasRole con uno solo cuando en realidad varios roles deberían calificar.
  7. Taller — API de una tienda — Un UserDetailsService con tres usuarios reales (dueña, vendedor, clienta) y una API con los 4 niveles de acceso del curso: público, cualquier autenticado, hasAnyRole y hasRole específico — de punta a punta, con un despachador REST real.
  8. Diseño de roles: qué endpoint necesita qué — Sobre una API con 5 endpoints reales, decidir qué debería ser público, qué requiere cualquier usuario autenticado, y qué requiere un rol específico — la habilidad de diseño detrás de cada @PreAuthorize que ya escribiste.
  9. Límites reales de @PreAuthorize en este motor — hasRole/hasAnyRole es TODO el subconjunto de SpEL soportado: cualquier otra expresión (hasAuthority, permitAll, combinaciones con and/or) es un error claro. Y solo se puede asegurar un método de ruta de un @RestController — un @Service no, porque haría falta AOP, que este motor no soporta.
  10. Taller — BancoDigital: dos errores reales y dos endpoints por diseñar — Une las aulas 7 y 8 en un solo proyecto: primero arreglar los dos errores de compilación reales de este motor (hasAuthority, y @PreAuthorize sobre un método de un @Service), y recién con todo compilando, diseñar el nivel de acceso de dos endpoints nuevos. Después el banco crece: un VAR de diseño, un Service nuevo y un módulo de tesorería completo.
  11. OAuth2 (conceptual): delegar el login a un tercero de confianza — Qué problema resuelve OAuth2 (no gestionar contraseñas de terceros), el flujo Authorization Code paso a paso, y cómo se ve la configuración real en Spring Boot — 100% lectura: este motor no puede simular un servidor de autorización externo ni redirects HTTP reales.
  12. JWT (conceptual): identidad sin estado en el servidor — Qué es un token, sus tres partes (header.payload.signature), por qué es "stateless" comparado con una sesión tradicional, y cómo se ve un filtro real que lo valida — 100% lectura: verificar una firma criptográfica real no es simulable de forma honesta en este motor.
  13. Cierre: auditoría final y checklist de seguridad básica — Repaso de punta a punta: autenticación (UserDetailsService, contraseñas), autorización (@PreAuthorize, hasRole/hasAnyRole), la distinción 401/403, los límites honestos de este motor, y un checklist de seguridad básica para cualquier API real.
  14. Taller — Arquitectura de seguridad de punta a punta — Un caso de estudio completo: qué mecanismo de autenticación (login propio, OAuth2, JWT) conviene para cada tipo de usuario o sistema de una app real, y la construcción ejecutable de la parte que SÍ corre acá — los roles locales con @PreAuthorize.

Es parte de