Configurar la autenticación en Spring Security empieza por algo muy concreto: tener una tabla de usuarios en tu propia base de datos. Aquí verás cómo modelar esa tabla con JPA, generar usuarios con contraseñas encriptadas en bcrypt y dejar todo listo para conectar con un UserDetailsService personalizado.

¿Qué estructura debe tener la tabla user en Spring Security?

La tabla user funciona como el punto de partida para autenticar a tus usuarios desde la base de datos. En lugar de mantenerlos en memoria, los persistes con campos clave que Spring Security puede leer después.

La tabla que se trabaja en la clase contiene:

• Nombre de usuario como primary key.
• Contraseña con un máximo de 200 caracteres y no nula.
• Correo electrónico del usuario.
• Indicador disabled para saber si la cuenta está desactivada.
• Indicador locked para saber si la cuenta está bloqueada.

Estos dos últimos se mapean como booleanos con column definition de tipo tinyint, lo que permite a MySQL almacenarlos como 0 o 1 sin perder el sentido lógico de verdadero o falso [0:38].

¿Cómo crear la entidad UserEntity en la capa de persistencia?

Dentro de la capa de persistencia, en el paquete entity, defines una clase llamada UserEntity. Esta clase es el análogo en código de la tabla user y sigue las mismas convenciones que ya viste en el curso de Spring Data JPA [1:00].

La entidad declara su primary key y las columnas que reflejan cada campo de la tabla. La contraseña queda marcada como no nula con longitud máxima de 200, mientras que locked y disabled se modelan con el tipo tinyint para alinearse con la base de datos.

¿Para qué sirve column definition tinyint en JPA? Le indica al motor de base de datos cómo crear físicamente la columna. En este caso, almacena valores 0 o 1 que representan estados booleanos como cuenta bloqueada o desactivada.

¿Cómo dejar que JPA genere la tabla automáticamente?

Si dentro de tu application.properties tienes la instrucción que permite a la aplicación validar y completar el esquema, no necesitas crear la tabla a mano. Al lanzar la aplicación, JPA detecta que falta UserEntity en la base de datos y la genera por ti [1:35].

Para confirmarlo, abres MySQL Workbench y revisas las tablas existentes. Junto a customer, order_item, pizza y pizza_order, aparece la nueva tabla de usuarios después de actualizar la vista [2:00].

¿Cómo insertar usuarios con contraseñas encriptadas en bcrypt?

La tabla recién creada está vacía, así que toca poblarla con al menos dos usuarios de prueba: uno con rol administrativo y otro con rol de cliente. Aquí entra un detalle importante: nunca guardes contraseñas en texto plano.

Spring Security utiliza bcrypt como algoritmo de codificación, así que el valor que persistes en la columna password debe estar ya encriptado. El flujo manual es directo:

1. Definir el texto plano, por ejemplo admin123 o customer123.
2. Entrar a bcrypt.online y pegar la contraseña.
3. Hacer clic en generate hash para obtener el valor codificado.
4. Copiar ese hash y guardarlo en la columna password desde MySQL Workbench.

Para el primer usuario, defines admin como nombre, admin@platzi.com como correo, y los flags disabled y locked en 0. Repites el mismo proceso para el cliente con customer@platzi.com [2:30].

¿Por qué usar bcrypt en lugar de guardar la contraseña tal cual? Porque bcrypt aplica un hash unidireccional con sal, lo que impide que alguien con acceso a la base de datos recupere la contraseña original. Spring Security espera ese formato para validar el login.

¿Existe otra forma de crear la tabla sin depender de JPA?

Sí. Si prefieres no apoyarte en la generación automática de JPA, puedes ejecutar directamente un script SQL que cree la tabla user con sus columnas y restricciones. Ese script queda disponible en la sección de recursos para que lo apliques tal cual sobre tu base de datos [4:30].

¿Por qué Spring Security todavía no usa estos usuarios?

Aunque ya tienes a admin y customer guardados con sus contraseñas en bcrypt, la configuración de seguridad sigue apuntando a los usuarios definidos en memoria. Spring Security no consulta tu base de datos hasta que se lo indiques de forma explícita.

El siguiente paso será construir tu propia implementación de UserDetailsService, una pieza clave que le dice a Spring Security dónde y cómo buscar a los usuarios al momento de autenticar. Con esa implementación conectada al repositorio de UserEntity, la autenticación dejará de depender de la memoria y empezará a leer directamente de MySQL.

¿Ya tienes lista tu tabla y tus usuarios encriptados? Cuéntame en los comentarios qué nombre le pusiste a tu entidad y si decidiste crear la tabla con JPA o con SQL puro.