La autorización en React te permite decidir qué puede hacer cada usuario dentro de tu aplicación según su rol o relación con el contenido. Aquí aprendes a diferenciarla de la autenticación, asignar permisos de administrador y permitir que cada autor controle su propio contenido.

Cuál es la diferencia entre autenticación y autorización

Aunque suenan parecidas, no son lo mismo y conviene tenerlo claro antes de tocar código.

La autenticación identifica personas: responde a la pregunta de quién es quién dentro de tu app. La autorización, en cambio, define qué permisos tiene cada persona ya autenticada [01:00]. Las dos van de la mano, pero la magia ocurre cuando combinas ambas para modificar comportamientos según el usuario.

¿Qué es autorización en una app? Es el sistema que define qué acciones puede ejecutar un usuario autenticado, por ejemplo, eliminar un blog post si es administrador o autor del contenido.

Cómo crear una lista de administradores en el archivo auth

La idea es simular lo que normalmente haría un backend: devolver información sobre el rol del usuario al momento de hacer login.

Dentro de auth.js, se crea una constante adminList con un arreglo de usernames que tendrán superpoderes, por ejemplo Iris y Freddier [03:00]. En un entorno real, esa lista vendría de una base de datos junto con la respuesta de autenticación, pero para fines de aprendizaje se mantiene como arreglo manual.

Después, al construir el objeto user, se evalúa si el username del usuario actual está dentro de adminList usando el método some, que recorre el arreglo y devuelve true si encuentra coincidencia. Ese resultado se guarda en una variable isAdmin y se asigna como propiedad al usuario autenticado [04:30].

javascript const adminList = ['Iris', 'Freddier']; const isAdmin = adminList.some(admin => admin === username); const user = { username, isAdmin };

Cómo mostrar botones según el rol del usuario

Con la propiedad isAdmin lista, el siguiente paso es usarla en los componentes que dependen del permiso.

En blogPost.js se importa el hook useAuth y se evalúa si existe auth.user y si su propiedad isAdmin es true. Solo en ese caso se renderiza el botón de eliminar el blog post [06:30]. Esto significa que cualquier visitante o usuario común jamás verá ese botón, mientras que Iris o Freddier sí podrán hacerlo en cualquier publicación.

javascript {auth.user?.isAdmin && ( <button>Eliminar blog post</button> )}

Al iniciar sesión con Iris y entrar al blog, el botón aparece en todos los posts. Sin sesión o con un usuario común, no se muestra nada distinto.

Cómo permitir que cada autor edite su propio contenido

Un administrador puede borrar todo, pero también el autor original debería poder controlar lo que él mismo creó.

Para resolverlo se crea una variable canDelete que combina dos condiciones con un operador OR. Por un lado, que el usuario sea administrador. Por otro, que el author del blog post coincida con el username autenticado [09:30]. Si cualquiera se cumple, el botón aparece.

javascript const canDelete = auth.user?.isAdmin || blogPost.author === auth.user?.username;

El símbolo ?. es optional chaining, una característica reciente de ECMAScript que evita errores cuando una propiedad anidada no existe. En lugar de validar manualmente que auth.user exista antes de leer username, el operador devuelve undefined sin romper la app [11:00].

¿Para qué sirve el optional chaining en JavaScript? Permite acceder a propiedades anidadas sin verificar manualmente cada nivel. Si algo es null o undefined, devuelve undefined en lugar de lanzar un error.

Qué pasa al probar con distintos usuarios

La prueba final confirma que la lógica funciona en todos los escenarios.

• Un usuario aleatorio sin rol: no ve el botón en ningún post.
• Freddier, administrador: ve el botón en todos los posts.
• Juan DC, autor de un post sobre React: ve el botón solo en su propio contenido, no en los de Diana ni en otros temas que no escribió.

Esa combinación de rol + autoría es la base de los sistemas de permisos en aplicaciones reales, desde un blog hasta un CMS o un dashboard corporativo.

Qué reto debes resolver antes de la siguiente clase

La propuesta es ampliar la lógica con más de una lista de roles para practicar el patrón.

No te quedes solo con administradores. Crea listas adicionales como editores, content creators, beta testers o revisores, y asigna a cada una un comportamiento distinto. Por ejemplo:

• Administradores que puedan hacer todo.
• Beta testers con acceso a una página secreta.
• Editores que puedan borrar comentarios.

No necesitas implementar la acción real, basta con que el botón o la sección aparezca según el rol [14:00]. Cuéntame en los comentarios cómo lo resolviste.