La administración de roles en Auth0 te permite controlar qué puede hacer cada usuario dentro de tu aplicación sin asignar permisos uno por uno. Aprenderás a configurar permisos en tu API, activar el Role Based Access Control y crear roles que agrupen accesos de forma escalable.

Esto es clave si construyes aplicaciones con distintos tipos de usuarios y necesitas un control granular sobre lo que cada uno puede consultar o modificar.

¿Cómo defino los permisos en una API de Auth0?

Antes de crear roles, necesitas declarar los permisos que tu API expone. Los permisos describen acciones puntuales: leer, escribir, editar, eliminar.

En el ejemplo del proxy server API, ya existía un permiso llamado Read Images. A ese listado puedes sumar más acciones según la lógica de tu producto [01:00]:

• Read Horror Movies, con su descripción correspondiente.
• Read Thriller Movies, también con su descripción.
• Read Images, que ya estaba creado previamente.

La idea es que cada permiso represente una operación específica que tu API puede autorizar. Mientras más granular, más control tienes después al combinarlos en roles.

¿Qué es un permiso en Auth0? Es una acción concreta que una API puede autorizar, como leer, escribir o editar un recurso. Se define dentro de la configuración de la API y luego se asigna a roles o usuarios.

¿Cómo activo el Role Based Access Control en Auth0?

Dentro de la pestaña Settings de tu API encontrarás la sección RBAC Settings. Ahí debes activar dos opciones que cambian por completo cómo se validan los accesos [01:55].

¿Qué hacen los flags de RBAC y Add Permissions in the Access Token?

Al encender Enable Role Based Access Control, cada vez que tu API reciba una petición, Auth0 verificará automáticamente que el usuario tenga los permisos requeridos. Ya no necesitas cargarlos manualmente desde el cliente porque se extraen del usuario autenticado.

El segundo flag, Add Permissions in the Access Token, incluye los permisos como un claim dentro del token. Sin esta opción, los permisos viven dentro del scope y solo Auth0 los consulta. Con ella activada, puedes leerlos desde tu cliente o desde otros servicios que consuman ese token.

Guarda los cambios y ya tienes la base para administrar roles desde User Management > Roles.

¿Cómo creo roles y los conecto con permisos?

Un rol es simplemente una agrupación de permisos. En vez de asignar permisos sueltos a cada usuario, defines un rol y lo aplicas a quien corresponda. Es más práctico y escalable [03:25].

En el ejemplo se crearon tres roles dentro de la API de películas:

• Horror Lover: persona a la que le gustan las películas de terror. Recibe los permisos Read Horror Movies y Read Images.
• Thriller Lover: persona a la que le gustan los thrillers. Recibe Read Thriller Movies y Read Images.
• Movies Lover: persona que disfruta ambos géneros. Recibe los cuatro permisos combinados.

Fíjate en un detalle importante: si solo das Read Horror Movies sin Read Images, el usuario podrá listar películas pero no ver sus imágenes, porque la API externa exige ese permiso adicional. Los roles funcionan bien cuando piensas en el flujo completo de la experiencia.

También existe el concepto de grupos, que son conjuntos de roles, aunque esa función está reservada para las versiones Enterprise de Auth0.

¿Cuál es la diferencia entre roles y permisos en Auth0? El permiso es la acción individual sobre la API. El rol es un paquete de permisos que se asigna al usuario para simplificar la administración.

¿Cómo asigno roles a los usuarios?

Puedes hacerlo desde dos lugares: dentro del rol, agregando usuarios, o desde el perfil del usuario, agregando roles. Si manejas muchos usuarios, suele ser más cómodo trabajar desde la ficha del usuario [05:30].

En la prueba se asignó:

1. Usuario de GitHub con el rol Movies Lover, para que tenga acceso a ambos géneros.
2. Usuario de prueba con el rol Horror Lover.
3. Usuario thriller con el rol Thriller Lover.

Así puedes validar el comportamiento de la aplicación según el rol que tenga cada cuenta.

¿Cómo se nota el RBAC en la experiencia del usuario?

Al hacer login con el usuario thriller@gmail.com, la app pide consentimiento para leer perfil, email e imágenes, y todo carga sin problema porque ese usuario tiene los permisos necesarios [07:00].

En cambio, si entras con un usuario sin roles asignados, como el new user creado desde el Management API, las imágenes no cargan. Le falta el permiso Read Images y la API lo bloquea automáticamente. Aquí se ve la fuerza del RBAC: aunque el cliente envíe el scope, Auth0 valida contra los permisos reales del usuario.

Si un usuario no puede acceder porque olvidó la contraseña, desde la sección de usuarios tienes la opción Change Password para resetearla manualmente.

¿Por qué un usuario no ve datos aunque tenga el scope correcto? Porque al activar RBAC, Auth0 ignora los scopes declarados en el cliente y valida solo los permisos asociados al rol del usuario.

Reto: diseña roles para un blog

Piensa en cómo organizarías roles y permisos para un blog tipo WordPress. ¿Qué podría hacer un editor? ¿Y un autor? ¿Cómo se reparten acciones como leer posts, crear posts, publicar o eliminar? Comparte tu propuesta en los comentarios y compara con la de otros estudiantes.