Protege tu API de Fiber con control de acceso basado en roles (RBAC) y validación de JWT
Esta guía te ayudará a implementar autorización para asegurar tus APIs de Fiber utilizando el control de acceso basado en roles (RBAC) y JSON Web Tokens (JWTs) emitidos por Logto.
Antes de comenzar
Tus aplicaciones cliente necesitan obtener tokens de acceso (Access tokens) de Logto. Si aún no has configurado la integración del cliente, consulta nuestras Guías rápidas para React, Vue, Angular u otros frameworks de cliente, o revisa nuestra Guía de máquina a máquina para el acceso de servidor a servidor.
Esta guía se centra en la validación del lado del servidor de esos tokens en tu aplicación Fiber.

Lo que aprenderás
- Validación de JWT: Aprende a validar tokens de acceso (Access tokens) y extraer información de autenticación (Authentication)
- Implementación de middleware: Crea middleware reutilizable para la protección de API
- Modelos de permisos: Comprende e implementa diferentes patrones de autorización (Authorization):
- Recursos de API globales para endpoints a nivel de aplicación
- Permisos de organización para el control de funciones específicas de inquilinos
- Recursos de API a nivel de organización para el acceso a datos multi-inquilino
- Integración de RBAC: Aplica permisos y alcances (Scopes) basados en roles (Roles) en tus endpoints de API
Requisitos previos
- Última versión estable de Go instalada
- Conocimientos básicos de Fiber y desarrollo de API web
- Una aplicación Logto configurada (consulta las Guías rápidas si es necesario)
Resumen de modelos de permisos
Antes de implementar la protección, elige el modelo de permisos que se adapte a la arquitectura de tu aplicación. Esto se alinea con los tres principales escenarios de autorización de Logto:
- Recursos de API globales
- Permisos de organización (no API)
- Recursos de API a nivel de organización

- Caso de uso: Proteger recursos de API compartidos en toda tu aplicación (no específicos de una organización)
- Tipo de token: Token de acceso (Access token) con audiencia global
- Ejemplos: APIs públicas, servicios principales del producto, endpoints de administración
- Ideal para: Productos SaaS con APIs utilizadas por todos los clientes, microservicios sin aislamiento de inquilinos
- Más información: Proteger recursos de API globales

- Caso de uso: Controlar acciones específicas de la organización, características de la interfaz de usuario o lógica de negocio (no APIs)
- Tipo de token: Token de organización (Organization token) con audiencia específica de la organización
- Ejemplos: Control de características, permisos de panel de control, controles de invitación de miembros
- Ideal para: SaaS multi-inquilino con características y flujos de trabajo específicos de la organización
- Más información: Proteger permisos de organización (no API)

- Caso de uso: Proteger recursos de API accesibles dentro de un contexto de organización específico
- Tipo de token: Token de organización (Organization token) con audiencia de recurso de API + contexto de organización
- Ejemplos: APIs multi-inquilino, endpoints de datos con alcance organizacional, microservicios específicos de inquilino
- Ideal para: SaaS multi-inquilino donde los datos de la API tienen alcance organizacional
- Más información: Proteger recursos de API a nivel de organización
💡 Elige tu modelo antes de continuar: la implementación hará referencia a tu enfoque elegido a lo largo de esta guía.
Pasos rápidos de preparación
Configura recursos y permisos de Logto
- Recursos de API globales
- Permisos de organización (no API)
- Recursos de API a nivel de organización
- Crea un recurso de API: Ve a Consola → Recursos de API y registra tu API (por ejemplo,
https://api.yourapp.com
) - Define permisos: Añade alcances como
read:products
,write:orders
– consulta Definir recursos de API con permisos - Crea roles globales: Ve a Consola → Roles y crea roles que incluyan los permisos de tu API – consulta Configurar roles globales
- Asigna roles: Asigna roles a usuarios o aplicaciones M2M que necesiten acceso a la API
- Define permisos de organización: Crea permisos de organización que no sean de API como
invite:member
,manage:billing
en la plantilla de organización - Configura roles de organización: Configura la plantilla de organización con roles específicos de la organización y asígnales permisos
- Asigna roles de organización: Asigna usuarios a roles de organización dentro de cada contexto de organización
- Crea un recurso de API: Registra tu recurso de API como antes, pero se usará en el contexto de organización
- Define permisos: Añade alcances como
read:data
,write:settings
que estén limitados al contexto de organización - Configura la plantilla de organización: Configura roles de organización que incluyan los permisos de tu recurso de API
- Asigna roles de organización: Asigna usuarios o aplicaciones M2M a roles de organización que incluyan permisos de API
- Configuración multi-tenant: Asegúrate de que tu API pueda manejar datos y validaciones con alcance de organización
Comienza con nuestra Guía de control de acceso basado en roles (RBAC) para instrucciones paso a paso.
Actualiza tu aplicación cliente
Solicita los alcances apropiados en tu cliente:
- Autenticación de usuario: Actualiza tu app → para solicitar los alcances de tu API y/o el contexto de organización
- Máquina a máquina: Configura alcances M2M → para acceso de servidor a servidor
El proceso normalmente implica actualizar la configuración de tu cliente para incluir uno o más de los siguientes:
- Parámetro
scope
en los flujos OAuth - Parámetro
resource
para acceso a recursos de API organization_id
para el contexto de organización
Asegúrate de que el usuario o la aplicación M2M que estás probando tenga asignados los roles o roles de organización adecuados que incluyan los permisos necesarios para tu API.
Inicializa tu proyecto de API
Para inicializar un nuevo proyecto Go con Fiber, puedes seguir estos pasos:
go mod init your-api-name
go get github.com/gofiber/fiber/v2
Luego, crea una configuración básica de un servidor Fiber:
package main
import (
"log"
"github.com/gofiber/fiber/v2"
)
func main() {
app := fiber.New()
log.Fatal(app.Listen(":3000"))
}
Consulta la documentación de Fiber para más detalles sobre cómo configurar rutas, middleware y otras funcionalidades.
Inicializa constantes y utilidades
Define las constantes y utilidades necesarias en tu código para manejar la extracción y validación de tokens. Una solicitud válida debe incluir un encabezado Authorization
en la forma Bearer <token de acceso (access token)>
.
package main
import (
"fmt"
"net/http"
"strings"
)
const (
JWKS_URI = "https://your-tenant.logto.app/oidc/jwks"
ISSUER = "https://your-tenant.logto.app/oidc"
)
type AuthorizationError struct {
Message string
Status int
}
func (e *AuthorizationError) Error() string {
return e.Message
}
func NewAuthorizationError(message string, status ...int) *AuthorizationError {
statusCode := http.StatusForbidden // Por defecto 403 Prohibido
if len(status) > 0 {
statusCode = status[0]
}
return &AuthorizationError{
Message: message,
Status: statusCode,
}
}
func extractBearerTokenFromHeaders(r *http.Request) (string, error) {
const bearerPrefix = "Bearer "
authorization := r.Header.Get("Authorization")
if authorization == "" {
return "", NewAuthorizationError("El encabezado Authorization (Authorization header) falta", http.StatusUnauthorized)
}
if !strings.HasPrefix(authorization, bearerPrefix) {
return "", NewAuthorizationError(fmt.Sprintf("El encabezado Authorization (Authorization header) debe comenzar con \"%s\"", bearerPrefix), http.StatusUnauthorized)
}
return strings.TrimPrefix(authorization, bearerPrefix), nil
}
Recupera información sobre tu tenant de Logto
Necesitarás los siguientes valores para validar los tokens emitidos por Logto:
- URI de JSON Web Key Set (JWKS): La URL a las claves públicas de Logto, utilizada para verificar las firmas de JWT.
- Emisor (Issuer): El valor esperado del emisor (la URL OIDC de Logto).
Primero, encuentra el endpoint de tu tenant de Logto. Puedes encontrarlo en varios lugares:
- En la Consola de Logto, en Configuración → Dominios.
- En cualquier configuración de aplicación que hayas configurado en Logto, Configuración → Endpoints y Credenciales.
Obtener desde el endpoint de descubrimiento de OpenID Connect
Estos valores pueden obtenerse desde el endpoint de descubrimiento de OpenID Connect de Logto:
https://<your-logto-endpoint>/oidc/.well-known/openid-configuration
Aquí tienes un ejemplo de respuesta (otros campos omitidos por brevedad):
{
"jwks_uri": "https://your-tenant.logto.app/oidc/jwks",
"issuer": "https://your-tenant.logto.app/oidc"
}
Codificar directamente en tu código (no recomendado)
Dado que Logto no permite personalizar la URI de JWKS ni el emisor, puedes codificar estos valores directamente en tu código. Sin embargo, esto no se recomienda para aplicaciones en producción, ya que puede aumentar la carga de mantenimiento si alguna configuración cambia en el futuro.
- URI de JWKS:
https://<your-logto-endpoint>/oidc/jwks
- Emisor:
https://<your-logto-endpoint>/oidc
Valida el token y los permisos
Después de extraer el token y obtener la configuración OIDC, valida lo siguiente:
- Firma: El JWT debe ser válido y estar firmado por Logto (a través de JWKS).
- Emisor (Issuer): Debe coincidir con el emisor de tu tenant de Logto.
- Audiencia (Audience): Debe coincidir con el indicador de recurso de la API registrado en Logto, o el contexto de la organización si corresponde.
- Expiración: El token no debe estar expirado.
- Permisos (Alcances / scopes): El token debe incluir los alcances requeridos para tu API / acción. Los alcances son cadenas separadas por espacios en el reclamo
scope
. - Contexto de organización: Si proteges recursos de API a nivel de organización, valida el reclamo
organization_id
.
Consulta JSON Web Token para aprender más sobre la estructura y los reclamos de JWT.
Qué verificar para cada modelo de permisos
- Recursos de API globales
- Permisos de organización (no API)
- Recursos de API a nivel de organización
- Reclamo de audiencia (
aud
): Indicador de recurso de API - Reclamo de organización (
organization_id
): No presente - Alcances (permisos) a verificar (
scope
): Permisos de recurso de API
- Reclamo de audiencia (
aud
):urn:logto:organization:<id>
(el contexto de organización está en el reclamoaud
) - Reclamo de organización (
organization_id
): No presente - Alcances (permisos) a verificar (
scope
): Permisos de organización
- Reclamo de audiencia (
aud
): Indicador de recurso de API - Reclamo de organización (
organization_id
): ID de la organización (debe coincidir con la solicitud) - Alcances (permisos) a verificar (
scope
): Permisos de recurso de API
Para los permisos de organización que no son de API, el contexto de la organización está
representado por el reclamo aud
(por ejemplo, urn:logto:organization:abc123
). El reclamo
organization_id
solo está presente para tokens de recursos de API a nivel de organización.
Valida siempre tanto los permisos (alcances) como el contexto (audiencia, organización) para APIs multi-tenant seguras.
Añade la lógica de validación
Usamos github.com/lestrrat-go/jwx para validar JWTs. Instálalo si aún no lo has hecho:
go mod init your-project
go get github.com/lestrrat-go/jwx/v3
Primero, añade estos componentes compartidos a tu archivo auth_middleware.go
:
import (
"context"
"strings"
"time"
"github.com/lestrrat-go/jwx/v3/jwk"
"github.com/lestrrat-go/jwx/v3/jwt"
)
var jwkSet jwk.Set
func init() {
// Inicializar la caché de JWKS
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
var err error
jwkSet, err = jwk.Fetch(ctx, JWKS_URI)
if err != nil {
panic("No se pudo obtener JWKS: " + err.Error())
}
}
// validateJWT valida el JWT y devuelve el token analizado
func validateJWT(tokenString string) (jwt.Token, error) {
token, err := jwt.Parse([]byte(tokenString), jwt.WithKeySet(jwkSet))
if err != nil {
return nil, NewAuthorizationError("Token inválido: "+err.Error(), http.StatusUnauthorized)
}
// Verificar emisor
if token.Issuer() != ISSUER {
return nil, NewAuthorizationError("Emisor inválido", http.StatusUnauthorized)
}
if err := verifyPayload(token); err != nil {
return nil, err
}
return token, nil
}
// Funciones auxiliares para extraer datos del token
func getStringClaim(token jwt.Token, key string) string {
if val, ok := token.Get(key); ok {
if str, ok := val.(string); ok {
return str
}
}
return ""
}
func getScopesFromToken(token jwt.Token) []string {
if val, ok := token.Get("scope"); ok {
if scope, ok := val.(string); ok && scope != "" {
return strings.Split(scope, " ")
}
}
return []string{}
}
func getAudienceFromToken(token jwt.Token) []string {
return token.Audience()
}
Luego, implementa el middleware para verificar el token de acceso (access token):
import (
"net/http"
"github.com/gofiber/fiber/v2"
)
func VerifyAccessToken(c *fiber.Ctx) error {
// Convertir la solicitud de fiber a http.Request para compatibilidad
req := &http.Request{
Header: make(http.Header),
}
req.Header.Set("Authorization", c.Get("Authorization"))
tokenString, err := extractBearerTokenFromHeaders(req)
if err != nil {
authErr := err.(*AuthorizationError)
return c.Status(authErr.Status).JSON(fiber.Map{"error": authErr.Message})
}
token, err := validateJWT(tokenString)
if err != nil {
authErr := err.(*AuthorizationError)
return c.Status(authErr.Status).JSON(fiber.Map{"error": authErr.Message})
}
// Almacenar el token en locals para uso genérico
c.Locals("auth", token)
return c.Next()
}
Según tu modelo de permisos, puede que necesites adoptar una lógica diferente para verifyPayload
:
- Recursos de API globales
- Permisos de organización (no API)
- Recursos de API a nivel de organización
func verifyPayload(token jwt.Token) error {
// Verificar que el claim de audiencia coincida con tu indicador de recurso de API
if !hasAudience(token, "https://your-api-resource-indicator") {
return NewAuthorizationError("Audiencia inválida")
}
// Verificar los alcances requeridos para recursos de API globales
requiredScopes := []string{"api:read", "api:write"} // Reemplaza con tus alcances requeridos
if !hasRequiredScopes(token, requiredScopes) {
return NewAuthorizationError("Alcance insuficiente")
}
return nil
}
func verifyPayload(token jwt.Token) error {
// Verificar que el claim de audiencia coincida con el formato de organización
if !hasOrganizationAudience(token) {
return NewAuthorizationError("Audiencia inválida para permisos de organización")
}
// Verificar que el ID de la organización coincida con el contexto (puede que necesites extraerlo del contexto de la solicitud)
expectedOrgID := "your-organization-id" // Extraer del contexto de la solicitud
if !hasMatchingOrganization(token, expectedOrgID) {
return NewAuthorizationError("ID de organización no coincide")
}
// Verificar los alcances requeridos de la organización
requiredScopes := []string{"invite:users", "manage:settings"} // Reemplaza con tus alcances requeridos
if !hasRequiredScopes(token, requiredScopes) {
return NewAuthorizationError("Alcance de organización insuficiente")
}
return nil
}
func verifyPayload(token jwt.Token) error {
// Verificar que el claim de audiencia coincida con tu indicador de recurso de API
if !hasAudience(token, "https://your-api-resource-indicator") {
return NewAuthorizationError("Audiencia inválida para recursos de API a nivel de organización")
}
// Verificar que el ID de la organización coincida con el contexto (puede que necesites extraerlo del contexto de la solicitud)
expectedOrgID := "your-organization-id" // Extraer del contexto de la solicitud
if !hasMatchingOrganizationID(token, expectedOrgID) {
return NewAuthorizationError("ID de organización no coincide")
}
// Verificar los alcances requeridos para recursos de API a nivel de organización
requiredScopes := []string{"api:read", "api:write"} // Reemplaza con tus alcances requeridos
if !hasRequiredScopes(token, requiredScopes) {
return NewAuthorizationError("Alcances insuficientes para recursos de API a nivel de organización")
}
return nil
}
Agrega estas funciones auxiliares para la verificación del payload:
// hasAudience verifica si el token tiene la audiencia especificada
func hasAudience(token jwt.Token, expectedAud string) bool {
audiences := token.Audience()
for _, aud := range audiences {
if aud == expectedAud {
return true
}
}
return false
}
// hasOrganizationAudience verifica si el token tiene formato de audiencia de organización
func hasOrganizationAudience(token jwt.Token) bool {
audiences := token.Audience()
for _, aud := range audiences {
if strings.HasPrefix(aud, "urn:logto:organization:") {
return true
}
}
return false
}
// hasRequiredScopes verifica si el token tiene todos los alcances requeridos
func hasRequiredScopes(token jwt.Token, requiredScopes []string) bool {
scopes := getScopesFromToken(token)
for _, required := range requiredScopes {
found := false
for _, scope := range scopes {
if scope == required {
found = true
break
}
}
if !found {
return false
}
}
return true
}
// hasMatchingOrganization verifica si la audiencia del token coincide con la organización esperada
func hasMatchingOrganization(token jwt.Token, expectedOrgID string) bool {
expectedAud := fmt.Sprintf("urn:logto:organization:%s", expectedOrgID)
return hasAudience(token, expectedAud)
}
// hasMatchingOrganizationID verifica si el organization_id del token coincide con el esperado
func hasMatchingOrganizationID(token jwt.Token, expectedOrgID string) bool {
orgID := getStringClaim(token, "organization_id")
return orgID == expectedOrgID
}
Aplica el middleware a tu API
Ahora, aplica el middleware a tus rutas de API protegidas.
package main
import (
"github.com/gofiber/fiber/v2"
"github.com/lestrrat-go/jwx/v3/jwt"
)
func main() {
app := fiber.New()
// Aplica el middleware a las rutas protegidas
app.Get("/api/protected", VerifyAccessToken, func(c *fiber.Ctx) error {
// Información del token de acceso directamente desde locals
tokenInterface := c.Locals("auth")
if tokenInterface == nil {
return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "Token not found"})
}
token := tokenInterface.(jwt.Token)
return c.JSON(fiber.Map{
"sub": token.Subject(),
"client_id": getStringClaim(token, "client_id"),
"organization_id": getStringClaim(token, "organization_id"),
"scopes": getScopesFromToken(token),
"audience": getAudienceFromToken(token),
})
})
app.Listen(":8080")
}
O usando grupos de rutas:
package main
import (
"github.com/gofiber/fiber/v2"
"github.com/lestrrat-go/jwx/v3/jwt"
)
func main() {
app := fiber.New()
// Crea un grupo de rutas protegidas
api := app.Group("/api", VerifyAccessToken)
api.Get("/protected", func(c *fiber.Ctx) error {
// Información del token de acceso directamente desde locals
token := c.Locals("auth").(jwt.Token)
return c.JSON(fiber.Map{
"sub": token.Subject(),
"client_id": getStringClaim(token, "client_id"),
"organization_id": getStringClaim(token, "organization_id"),
"scopes": getScopesFromToken(token),
"audience": getAudienceFromToken(token),
"message": "Datos protegidos accedidos correctamente",
})
})
app.Listen(":8080")
}
Prueba tu API protegida
Obtener tokens de acceso (Access tokens)
Desde tu aplicación cliente: Si has configurado una integración de cliente, tu aplicación puede obtener tokens automáticamente. Extrae el token de acceso y úsalo en las solicitudes a la API.
Para pruebas con curl / Postman:
-
Tokens de usuario: Usa las herramientas de desarrollador de tu aplicación cliente para copiar el token de acceso desde localStorage o la pestaña de red.
-
Tokens máquina a máquina: Utiliza el flujo de credenciales de cliente. Aquí tienes un ejemplo no normativo usando curl:
curl -X POST https://your-tenant.logto.app/oidc/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=your-m2m-client-id" \
-d "client_secret=your-m2m-client-secret" \
-d "resource=https://your-api-resource-indicator" \
-d "scope=api:read api:write"Puede que necesites ajustar los parámetros
resource
yscope
según tu recurso de API y permisos; también puede ser necesario un parámetroorganization_id
si tu API está asociada a una organización.
¿Necesitas inspeccionar el contenido del token? Usa nuestro decodificador de JWT para decodificar y verificar tus JWTs.
Probar endpoints protegidos
Solicitud con token válido
curl -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." \
http://localhost:3000/api/protected
Respuesta esperada:
{
"auth": {
"sub": "user123",
"clientId": "app456",
"organizationId": "org789",
"scopes": ["api:read", "api:write"],
"audience": ["https://your-api-resource-indicator"]
}
}
Token ausente
curl http://localhost:3000/api/protected
Respuesta esperada (401):
{
"error": "Authorization header is missing"
}
Token inválido
curl -H "Authorization: Bearer invalid-token" \
http://localhost:3000/api/protected
Respuesta esperada (401):
{
"error": "Invalid token"
}
Pruebas específicas del modelo de permisos
- Recursos de API globales
- Permisos de organización (no API)
- Recursos de API a nivel de organización
Escenarios de prueba para APIs protegidas con alcances globales:
- Alcances válidos: Prueba con tokens que incluyan los alcances de API requeridos (por ejemplo,
api:read
,api:write
) - Alcances ausentes: Espera 403 Prohibido cuando el token no tenga los alcances requeridos
- Audiencia incorrecta: Espera 403 Prohibido cuando la audiencia no coincida con el recurso de API
# Token sin los alcances requeridos - espera 403
curl -H "Authorization: Bearer token-without-required-scopes" \
http://localhost:3000/api/protected
Escenarios de prueba para control de acceso específico de organización:
- Token de organización válido: Prueba con tokens que incluyan el contexto correcto de organización (ID de organización y alcances)
- Alcances ausentes: Espera 403 Prohibido cuando el usuario no tenga permisos para la acción solicitada
- Organización incorrecta: Espera 403 Prohibido cuando la audiencia no coincida con el contexto de la organización (
urn:logto:organization:<organization_id>
)
# Token para organización incorrecta - espera 403
curl -H "Authorization: Bearer token-for-different-organization" \
http://localhost:3000/api/protected
Escenarios de prueba combinando validación de recursos de API con contexto de organización:
- Organización válida + alcances de API: Prueba con tokens que tengan tanto el contexto de organización como los alcances de API requeridos
- Alcances de API ausentes: Espera 403 Prohibido cuando el token de organización no tenga los permisos de API requeridos
- Organización incorrecta: Espera 403 Prohibido al acceder a la API con un token de otra organización
- Audiencia incorrecta: Espera 403 Prohibido cuando la audiencia no coincida con el recurso de API a nivel de organización
# Token de organización sin alcances de API - espera 403
curl -H "Authorization: Bearer organization-token-without-api-scopes" \
http://localhost:3000/api/protected
Lecturas adicionales
RBAC en la práctica: Implementando autorización segura para tu aplicación
Crea una aplicación SaaS multi-inquilino: Una guía completa desde el diseño hasta la implementación