Aller au contenu principal

Protégez votre API Echo avec le contrôle d’accès basé sur les rôles (RBAC) et la validation JWT

Ce guide vous aidera à mettre en œuvre l'autorisation pour sécuriser vos API Echo en utilisant le contrôle d’accès basé sur les rôles (RBAC) et les JSON Web Tokens (JWTs) émis par Logto.

Avant de commencer​

Vos applications clientes doivent obtenir des jetons d’accès (Access tokens) auprès de Logto. Si vous n'avez pas encore configuré l'intégration côté client, consultez nos Démarrages rapides pour React, Vue, Angular ou d'autres frameworks clients, ou consultez notre Guide machine à machine pour l'accès serveur à serveur.

Ce guide se concentre sur la validation côté serveur de ces jetons dans votre application Echo.

Une illustration montrant le focus de ce guide

Ce que vous allez apprendre​

  • Validation JWT : Apprenez à valider les jetons d’accès (Access tokens) et à extraire les informations d’authentification (Authentication)
  • Implémentation de middleware : Créez un middleware réutilisable pour la protection de votre API
  • Modèles de permissions : Comprenez et implémentez différents schémas d’autorisation (Authorization) :
    • Ressources API globales pour les points de terminaison à l’échelle de l’application
    • Permissions d’organisation pour le contrôle des fonctionnalités spécifiques à un locataire
    • Ressources API au niveau de l’organisation pour l’accès aux données multi-locataires
  • Intégration RBAC : Appliquez des permissions et des portées (Scopes) basées sur les rôles (Roles) dans vos points de terminaison API

Prérequis​

  • Dernière version stable de Go installée
  • Compréhension de base de Echo et du développement d’API web
  • Une application Logto configurée (voir Démarrages rapides si besoin)

Aperçu des modèles de permission​

Avant de mettre en place une protection, choisissez le modèle de permission qui correspond à l’architecture de votre application. Cela s’aligne avec les trois principaux scénarios d’autorisation de Logto :

RBAC des ressources API globales
  • Cas d’utilisation : Protéger les ressources API partagées à travers toute votre application (non spécifiques à une organisation)
  • Type de jeton : Jeton d’accès (Access token) avec audience globale
  • Exemples : APIs publiques, services principaux du produit, points de terminaison d’administration
  • Idéal pour : Produits SaaS avec des APIs utilisées par tous les clients, microservices sans isolation de locataire
  • En savoir plus : Protéger les ressources API globales

💡 Choisissez votre modèle avant de continuer – la mise en œuvre fera référence à l’approche choisie tout au long de ce guide.

Étapes de préparation rapide​

Configurer les ressources & permissions Logto​

  1. Créer une ressource API : Rendez-vous sur Console → Ressources API et enregistrez votre API (par exemple, https://api.votreapp.com)
  2. Définir les permissions : Ajoutez des portées comme read:products, write:orders – voir Définir des ressources API avec des permissions
  3. Créer des rôles globaux : Rendez-vous sur Console → Rôles et créez des rôles qui incluent vos permissions API – voir Configurer des rôles globaux
  4. Attribuer des rôles : Attribuez des rôles aux utilisateurs ou applications M2M qui ont besoin d'accéder à l'API
Nouveau sur le RBAC ?:

Commencez avec notre guide du contrôle d’accès basé sur les rôles (RBAC) pour des instructions d'installation étape par étape.

Mettez à jour votre application cliente​

Demandez les portées appropriées dans votre client :

Le processus consiste généralement à mettre à jour la configuration de votre client pour inclure un ou plusieurs des éléments suivants :

  • Paramètre scope dans les flux OAuth
  • Paramètre resource pour l'accès à la ressource API
  • organization_id pour le contexte d'organisation
Avant de coder:

Assurez-vous que l'utilisateur ou l'application M2M que vous testez s'est vu attribuer les rôles ou rôles d'organisation appropriés incluant les permissions nécessaires pour votre API.

Initialiser votre projet API​

Pour initialiser un nouveau projet Go avec Echo, vous pouvez suivre ces étapes :

go mod init your-api-name
go get github.com/labstack/echo/v4

Ensuite, créez une configuration de serveur Echo basique :

main.go
package main

import (
    "github.com/labstack/echo/v4"
)

func main() {
    e := echo.New()

    e.Logger.Fatal(e.Start(":3000"))
}
remarque:

Consultez la documentation Echo pour plus de détails sur la configuration des routes, des middlewares et d'autres fonctionnalités.

Initialiser les constantes et utilitaires​

Définissez les constantes et utilitaires nécessaires dans votre code pour gérer l’extraction et la validation du jeton. Une requête valide doit inclure un en-tête Authorization sous la forme Bearer <jeton d’accès (access token)>.

auth_middleware.go
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 // Par défaut à 403 Interdit
    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("L'en-tête Authorization est manquant", http.StatusUnauthorized)
    }

    if !strings.HasPrefix(authorization, bearerPrefix) {
        return "", NewAuthorizationError(fmt.Sprintf("L'en-tête Authorization doit commencer par \"%s\"", bearerPrefix), http.StatusUnauthorized)
    }

    return strings.TrimPrefix(authorization, bearerPrefix), nil
}

Récupérer les informations sur votre tenant Logto​

Vous aurez besoin des valeurs suivantes pour valider les jetons émis par Logto :

  • URI JSON Web Key Set (JWKS) : L’URL vers les clés publiques de Logto, utilisée pour vérifier les signatures JWT.
  • Émetteur (Issuer) : La valeur attendue de l’émetteur (l’URL OIDC de Logto).

Commencez par trouver l’endpoint de votre tenant Logto. Vous pouvez le trouver à différents endroits :

  • Dans la Console Logto, sous Paramètres → Domaines.
  • Dans les paramètres de toute application que vous avez configurée dans Logto, Paramètres → Endpoints & Credentials.

Récupérer depuis l’endpoint de découverte OpenID Connect​

Ces valeurs peuvent être récupérées depuis l’endpoint de découverte OpenID Connect de Logto :

https://<your-logto-endpoint>/oidc/.well-known/openid-configuration

Voici un exemple de réponse (autres champs omis pour plus de clarté) :

{
  "jwks_uri": "https://your-tenant.logto.app/oidc/jwks",
  "issuer": "https://your-tenant.logto.app/oidc"
}

Puisque Logto ne permet pas de personnaliser l’URI JWKS ou l’émetteur (Issuer), vous pouvez coder ces valeurs en dur dans votre code. Cependant, cela n’est pas recommandé pour les applications en production, car cela peut augmenter la charge de maintenance si une configuration change à l’avenir.

  • URI JWKS : https://<your-logto-endpoint>/oidc/jwks
  • Émetteur (Issuer) : https://<your-logto-endpoint>/oidc

Valider le jeton et les permissions​

Après avoir extrait le jeton et récupéré la configuration OIDC, validez les éléments suivants :

  • Signature : Le JWT doit être valide et signé par Logto (via JWKS).
  • Émetteur (Issuer) : Doit correspondre à l’émetteur de votre tenant Logto.
  • Audience (Audience) : Doit correspondre à l’indicateur de ressource de l’API enregistré dans Logto, ou au contexte d’organisation si applicable.
  • Expiration : Le jeton ne doit pas être expiré.
  • Permissions (Portées / scopes) : Le jeton doit inclure les portées requises pour votre API / action. Les portées sont des chaînes séparées par des espaces dans la revendication scope.
  • Contexte d’organisation : Si vous protégez des ressources API au niveau organisation, validez la revendication organization_id.

Consultez JSON Web Token pour en savoir plus sur la structure et les revendications des JWT.

À vérifier selon chaque modèle de permission​

  • Revendication Audience (aud) : Indicateur de ressource API
  • Revendication Organisation (organization_id) : Non présent
  • Portées (permissions) à vérifier (scope) : Permissions de ressource API

Pour les permissions d’organisation hors API, le contexte d’organisation est représenté par la revendication aud (par exemple, urn:logto:organization:abc123). La revendication organization_id n’est présente que pour les jetons de ressource API au niveau organisation.
astuce:

Validez toujours à la fois les permissions (portées / scopes) et le contexte (audience, organisation) pour sécuriser les API multi-tenant.

Ajouter la logique de validation​

Nous utilisons github.com/lestrrat-go/jwx pour valider les JWT. Installez-le si ce n'est pas déjà fait :

go mod init your-project
go get github.com/lestrrat-go/jwx/v3

Commencez par ajouter ces composants partagés à votre fichier auth_middleware.go :

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() {
    // Initialiser le cache 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("Échec de la récupération du JWKS : " + err.Error())
    }
}

// validateJWT valide le JWT et retourne le jeton analysé
func validateJWT(tokenString string) (jwt.Token, error) {
    token, err := jwt.Parse([]byte(tokenString), jwt.WithKeySet(jwkSet))
    if err != nil {
        return nil, NewAuthorizationError("Jeton invalide : "+err.Error(), http.StatusUnauthorized)
    }

    // Vérifier l'émetteur
    if token.Issuer() != ISSUER {
        return nil, NewAuthorizationError("Émetteur invalide", http.StatusUnauthorized)
    }

    if err := verifyPayload(token); err != nil {
        return nil, err
    }

    return token, nil
}

// Fonctions utilitaires pour extraire les données du jeton
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()
}

Ensuite, implémentez le middleware pour vérifier le jeton d’accès (access token) :

auth_middleware.go
import "github.com/labstack/echo/v4"

func VerifyAccessToken(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        tokenString, err := extractBearerTokenFromHeaders(c.Request())
        if err != nil {
            authErr := err.(*AuthorizationError)
            return c.JSON(authErr.Status, echo.Map{"error": authErr.Message})
        }

        token, err := validateJWT(tokenString)
        if err != nil {
            authErr := err.(*AuthorizationError)
            return c.JSON(authErr.Status, echo.Map{"error": authErr.Message})
        }

        // Stocker le jeton dans le contexte pour une utilisation générique (Store token in context for generic use)
        c.Set("auth", token)
        return next(c)
    }
}

Selon votre modèle de permissions, vous devrez peut-être adopter une logique différente pour verifyPayload :

auth_middleware.go
func verifyPayload(token jwt.Token) error {
    // Vérifier que la revendication d'audience correspond à votre indicateur de ressource API
    if !hasAudience(token, "https://your-api-resource-indicator") {
        return NewAuthorizationError("Audience invalide")
    }

    // Vérifier les portées requises pour les ressources API globales
    requiredScopes := []string{"api:read", "api:write"} // Remplacez par vos portées requises
    if !hasRequiredScopes(token, requiredScopes) {
        return NewAuthorizationError("Portée insuffisante")
    }

    return nil
}

Ajoutez ces fonctions utilitaires pour la vérification du payload :

auth_middleware.go
// hasAudience vérifie si le jeton possède l'audience spécifiée
func hasAudience(token jwt.Token, expectedAud string) bool {
    audiences := token.Audience()
    for _, aud := range audiences {
        if aud == expectedAud {
            return true
        }
    }
    return false
}

// hasOrganizationAudience vérifie si le jeton possède une audience au format organisation
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 vérifie si le jeton possède toutes les portées requises
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 vérifie si l'audience du jeton correspond à l'organisation attendue
func hasMatchingOrganization(token jwt.Token, expectedOrgID string) bool {
    expectedAud := fmt.Sprintf("urn:logto:organization:%s", expectedOrgID)
    return hasAudience(token, expectedAud)
}

// hasMatchingOrganizationID vérifie si organization_id du jeton correspond à celui attendu
func hasMatchingOrganizationID(token jwt.Token, expectedOrgID string) bool {
    orgID := getStringClaim(token, "organization_id")
    return orgID == expectedOrgID
}

Appliquer le middleware à votre API​

Appliquez maintenant le middleware à vos routes API protégées.

main.go
package main

import (
    "net/http"

    "github.com/labstack/echo/v4"
    "github.com/lestrrat-go/jwx/v3/jwt"
)

func main() {
    e := echo.New()

    // Appliquer le middleware aux routes protégées
    e.GET("/api/protected", func(c echo.Context) error {
        // Informations du jeton d’accès (Access token) accessibles directement depuis le contexte
        tokenInterface := c.Get("auth")
        if tokenInterface == nil {
            return c.JSON(http.StatusInternalServerError, echo.Map{"error": "Token not found"})
        }

        token := tokenInterface.(jwt.Token)

        return c.JSON(http.StatusOK, echo.Map{
            "sub":             token.Subject(),
            "client_id":       getStringClaim(token, "client_id"),
            "organization_id": getStringClaim(token, "organization_id"),
            "scopes":          getScopesFromToken(token),
            "audience":        getAudienceFromToken(token),
        })
    }, VerifyAccessToken)

    e.Start(":8080")
}

Ou en utilisant des groupes de routes :

main.go
package main

import (
    "github.com/labstack/echo/v4"
    "github.com/lestrrat-go/jwx/v3/jwt"
)

func main() {
    e := echo.New()

    // Créer un groupe de routes protégées
    api := e.Group("/api", VerifyAccessToken)
    api.GET("/protected", func(c echo.Context) error {
        // Informations du jeton d’accès (Access token) accessibles directement depuis le contexte
        token := c.Get("auth").(jwt.Token)

        return c.JSON(200, echo.Map{
            "sub":             token.Subject(),
            "client_id":       getStringClaim(token, "client_id"),
            "organization_id": getStringClaim(token, "organization_id"),
            "scopes":          getScopesFromToken(token),
            "audience":        getAudienceFromToken(token),
            "message":         "Données protégées accessibles avec succès",
        })
    })

    e.Start(":8080")
}

Tester votre API protégée​

Obtenir des jetons d’accès (Access tokens)​

Depuis votre application cliente :
Si vous avez configuré une intégration client, votre application peut obtenir automatiquement les jetons. Extrayez le jeton d’accès (access token) et utilisez-le dans les requêtes API.

Pour tester avec curl / Postman :

  1. Jetons utilisateur : Utilisez les outils développeur de votre application cliente pour copier le jeton d’accès depuis le localStorage ou l’onglet réseau.

  2. Jetons machine à machine : Utilisez le flux d’identifiants client (client credentials flow). Voici un exemple non normatif utilisant 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"

    Vous devrez peut-être ajuster les paramètres resource et scope selon votre ressource API (API resource) et vos permissions ; un paramètre organization_id peut également être requis si votre API est liée à une organisation.

astuce:

Besoin d’inspecter le contenu du jeton ? Utilisez notre décodificateur JWT pour décoder et vérifier vos JWT.

Tester les points de terminaison protégés​

Requête avec jeton valide
curl -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." \
  http://localhost:3000/api/protected

Réponse attendue :

{
  "auth": {
    "sub": "user123",
    "clientId": "app456",
    "organizationId": "org789",
    "scopes": ["api:read", "api:write"],
    "audience": ["https://your-api-resource-indicator"]
  }
}
Jeton manquant
curl http://localhost:3000/api/protected

Réponse attendue (401) :

{
  "error": "Authorization header is missing"
}
Jeton invalide
curl -H "Authorization: Bearer invalid-token" \
  http://localhost:3000/api/protected

Réponse attendue (401) :

{
  "error": "Invalid token"
}

Tests spécifiques au modèle de permission​

Scénarios de test pour les API protégées par des portées globales :

  • Portées valides : Testez avec des jetons qui incluent les portées API requises (par exemple, api:read, api:write)
  • Portées manquantes : Attendez-vous à une réponse 403 Interdit si le jeton ne contient pas les portées requises
  • Audience incorrecte : Attendez-vous à une réponse 403 Interdit si l’audience ne correspond pas à la ressource API
# Jeton sans les portées requises - attendre 403
curl -H "Authorization: Bearer token-without-required-scopes" \
  http://localhost:3000/api/protected

Pour aller plus loin​

RBAC en pratique : Mettre en œuvre une autorisation sécurisée pour votre application

Construire une application SaaS multi-locataires : Guide complet de la conception à la mise en œuvre