Aller au contenu principal

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

Ce guide vous aidera à implémenter l'autorisation pour sécuriser vos APIs Ruby on Rails 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 Ruby on Rails.

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 Ruby installée
  • Compréhension de base de Ruby on Rails 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 API Rails, vous pouvez utiliser le générateur Rails :

rails new your-api-name --api
cd your-api-name

Démarrez le serveur de développement :

rails server

Créez un contrôleur API de base :

app/controllers/api/base_controller.rb
class Api::BaseController < ApplicationController
  def index
    render json: { message: 'Hello from Rails API' }
  end
end

Ajoutez les routes :

config/routes.rb
Rails.application.routes.draw do
  namespace :api do
    root 'base#index'
  end
end
remarque:

Consultez la documentation Rails pour plus de détails sur la configuration des contrôleurs, des modèles 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_constants.rb
module AuthConstants
  JWKS_URI = 'https://your-tenant.logto.app/oidc/jwks'
  ISSUER = 'https://your-tenant.logto.app/oidc'
end
auth_info.rb
class AuthInfo
  attr_accessor :sub, :client_id, :organization_id, :scopes, :audience

  def initialize(sub, client_id = nil, organization_id = nil, scopes = [], audience = [])
    @sub = sub
    @client_id = client_id
    @organization_id = organization_id
    @scopes = scopes
    @audience = audience
  end

  def to_h
    {
      sub: @sub,
      client_id: @client_id,
      organization_id: @organization_id,
      scopes: @scopes,
      audience: @audience
    }
  end
end
authorization_error.rb
class AuthorizationError < StandardError
  attr_reader :status

  def initialize(message, status = 403)
    super(message)
    @status = status
  end
end
auth_helpers.rb
module AuthHelpers
  def extract_bearer_token(request)
    authorization = request.headers['Authorization']

    raise AuthorizationError.new('Authorization header is missing', 401) unless authorization
    raise AuthorizationError.new('Authorization header must start with "Bearer "', 401) unless authorization.start_with?('Bearer ')

    authorization[7..-1] # Supprimer le préfixe 'Bearer '
  end
end

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 la gem jwt pour valider les JWT. Ajoutez-la à votre Gemfile :

Gemfile
gem 'jwt'
# net-http fait partie de la bibliothèque standard Ruby depuis Ruby 2.7, inutile de l’ajouter explicitement

Puis exécutez :

bundle install

Ajoutez d'abord ces utilitaires partagés pour gérer les JWKS et la validation des jetons :

jwt_validator.rb
require 'jwt'
require 'net/http'
require 'json'

class JwtValidator
  include AuthHelpers

  def self.fetch_jwks
    @jwks ||= begin
      uri = URI(AuthConstants::JWKS_URI)
      response = Net::HTTP.get_response(uri)
      raise AuthorizationError.new('Failed to fetch JWKS', 401) unless response.is_a?(Net::HTTPSuccess)

      jwks_data = JSON.parse(response.body)
      JWT::JWK::Set.new(jwks_data)
    end
  end

  def self.validate_jwt(token)
    jwks = fetch_jwks

    # Laissez la bibliothèque JWT gérer la détection de l’algorithme à partir du JWKS
    decoded_token = JWT.decode(token, nil, true, {
      iss: AuthConstants::ISSUER,
      verify_iss: true,
      verify_aud: false, # Nous vérifierons l’audience manuellement selon le modèle de permission
      jwks: jwks
    })[0]

    verify_payload(decoded_token)
    decoded_token
  end

  def self.create_auth_info(payload)
    scopes = payload['scope']&.split(' ') || []
    audience = payload['aud'] || []

    AuthInfo.new(
      payload['sub'],
      payload['client_id'],
      payload['organization_id'],
      scopes,
      audience
    )
  end

  def self.verify_payload(payload)
    # Implémentez ici votre logique de vérification selon le modèle de permission
    # Cela sera montré dans la section sur les modèles de permission ci-dessous
  end
end

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

app/controllers/concerns/jwt_authentication.rb
module JwtAuthentication
  extend ActiveSupport::Concern
  include AuthHelpers

  included do
    before_action :verify_access_token, only: [:protected_action] # Ajouter des actions spécifiques
  end

  private

  def verify_access_token
    begin
      token = extract_bearer_token(request)
      decoded_token = JwtValidator.validate_jwt(token)

      # Stocker les informations d'authentification pour une utilisation générique
      @auth = JwtValidator.create_auth_info(decoded_token)

    rescue AuthorizationError => e
      render json: { error: e.message }, status: e.status
    rescue JWT::DecodeError, JWT::VerificationError, JWT::ExpiredSignature => e
      render json: { error: 'Jeton invalide' }, status: 401
    end
  end
end

Selon votre modèle de permission, implémentez la logique de vérification appropriée dans JwtValidator :

jwt_validator.rb
def self.verify_payload(payload)
  # Vérifiez que la revendication d’audience correspond à votre indicateur de ressource API
  audiences = payload['aud'] || []
  unless audiences.include?('https://your-api-resource-indicator')
    raise AuthorizationError.new('Invalid audience')
  end

  # Vérifiez les portées requises pour les ressources API globales
  required_scopes = ['api:read', 'api:write'] # Remplacez par vos portées requises
  token_scopes = payload['scope']&.split(' ') || []

  unless required_scopes.all? { |scope| token_scopes.include?(scope) }
    raise AuthorizationError.new('Insufficient scope')
  end
end

Appliquer le middleware à votre API​

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

app/controllers/application_controller.rb
class ApplicationController < ActionController::API # Pour les applications API uniquement
# class ApplicationController < ActionController::Base # Pour les applications Rails complètes
  include JwtAuthentication
end
app/controllers/api/protected_controller.rb
class Api::ProtectedController < ApplicationController
  before_action :verify_access_token

  def index
    # Accéder aux informations d'authentification depuis @auth
    render json: { auth: @auth.to_h }
  end
end
config/routes.rb
Rails.application.routes.draw do
  namespace :api do
    resources :protected, only: [:index]
  end
end

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