Drupal

Implementazione di un sistema di autenticazione personalizzato in Drupal con OAuth 2.0

Implementazione di un sistema di autenticazione personalizzato in Drupal con OAuth 2.0
LT
Luca Terribili
Autore

Una delle opzioni più diffuse per gestire l’autenticazione moderna è l’adozione di OAuth 2.0, uno standard aperto che permette di delegare l’autorizzazione a provider esterni come Google, Facebook o Microsoft, senza che gli utenti debbano condividere le proprie credenziali con il sito. Questo approccio riduce drasticamente la superficie di attacco legata alla gestione delle password, semplifica l’esperienza di accesso e migliora la sicurezza complessiva grazie all’uso di token a durata limitata.

In ambito Drupal, OAuth 2.0 viene utilizzato sia per consentire il login tramite provider esterni sia per esporre API sicure verso applicazioni terze. Il CMS non si limita a fungere da semplice consumer del protocollo, ma offre strumenti per integrare flussi di autenticazione avanzati, mappare permessi e controllare l’accesso alle risorse in modo granulare.

In questo articolo vedremo come implementare un sistema di autenticazione basato su OAuth 2.0 in Drupal, analizzando il funzionamento del protocollo, i vantaggi pratici, la configurazione dei provider esterni, la gestione dei token e le principali best practice di sicurezza. L’obiettivo non è solo “far funzionare il login”, ma costruire un’integrazione solida, manutenibile e coerente con l’architettura di Drupal 10.

Cos’è OAuth 2.0 e come funziona

OAuth 2.0 è un protocollo di autorizzazione che consente a un’applicazione client di accedere a risorse protette su un server per conto di un utente, senza che le credenziali dell’utente vengano mai condivise con il client stesso. Il concetto chiave è la separazione netta tra autenticazione dell’utente e autorizzazione all’accesso alle risorse.

Il flusso più utilizzato nelle applicazioni web è l’Authorization Code Grant. In questo scenario l’utente viene reindirizzato dal sito Drupal al server di autorizzazione del provider scelto, dove effettua il login. Se l’autenticazione va a buon fine, il provider restituisce al client un codice temporaneo. Questo codice viene poi scambiato dal server Drupal con un access token tramite una richiesta server‑to‑server.

Un esempio ridotto del flusso, usando cURL per lo scambio del codice, può essere così rappresentato:

# Scambio del codice di autorizzazione per un access token
curl -X POST https://oauth2.googleapis.com/token \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET \
  -d code=AUTHORIZATION_CODE \
  -d grant_type=authorization_code \
  -d redirect_uri=https://your-drupal-site.it/oauth2/callback

L’access token consente al client di effettuare chiamate alle API protette finché rimane valido. Alla scadenza, se previsto, può essere utilizzato un refresh token per ottenere un nuovo access token senza richiedere un ulteriore login all’utente. Questo meccanismo riduce il numero di autenticazioni esplicite e migliora l’esperienza utente senza compromettere la sicurezza.

Dal punto di vista di Drupal, OAuth 2.0 non sostituisce il sistema di utenti e ruoli, ma si integra con esso. Il token serve a dimostrare che l’utente è stato autenticato da un provider affidabile, mentre la gestione dei permessi resta sotto il controllo del CMS.

Vantaggi dell’utilizzo di OAuth 2.0 in Drupal

L’adozione di OAuth 2.0 in Drupal offre benefici concreti sia in termini di sicurezza sia di usabilità. Il primo vantaggio è la drastica riduzione della responsabilità nella gestione delle credenziali. Le password non transitano mai su Drupal, né vengono memorizzate nel database, eliminando una delle principali fonti di vulnerabilità.

Dal punto di vista dell’utente, il login risulta più rapido e familiare. Utilizzare un account già esistente presso un provider affidabile riduce l’attrito e aumenta le probabilità di completare la registrazione o l’accesso. Questo aspetto è particolarmente rilevante nei siti ad alto tasso di abbandono o nelle piattaforme con utenti occasionali.

OAuth 2.0 è inoltre estremamente flessibile. Supporta diversi grant type e può essere esteso facilmente con OpenID Connect quando è necessario ottenere informazioni di identità strutturate. In un contesto Drupal questo significa poter integrare sistemi esterni, microservizi o applicazioni mobile senza dover reinventare meccanismi di autenticazione proprietari.

Un ulteriore vantaggio è la maggiore resistenza agli attacchi automatizzati. I token sono revocabili, hanno una durata limitata e possono essere monitorati. Questo rende molto più complesso effettuare attacchi di forza bruta o sfruttare credenziali compromesse su larga scala.

Implementazione di un sistema di autenticazione OAuth 2.0 in Drupal

In Drupal 10 l’implementazione di OAuth 2.0 si basa su moduli contrib consolidati. Per il ruolo di client verso provider esterni si utilizza il modulo OAuth2 Client. Per esporre un server OAuth conforme allo standard, il riferimento attuale è Simple OAuth, che ha sostituito i vecchi moduli OAuth 2.0 Server ormai deprecati.

Installazione del modulo OAuth2 Client

# Aggiungere il modulo OAuth2 Client tramite Composer
composer require drupal/oauth2_client
# Abilitare il modulo
drush en oauth2_client -y

Una volta installato, è possibile configurare uno o più provider esterni dal pannello di amministrazione (/admin/config/services/oauth2-client). La configurazione richiede:

  • Client ID e Client Secret forniti dal provider.
  • Endpoint di autorizzazione e endpoint di token.
  • Gli scope necessari.

Esempio di configurazione YAML per Google (in oauth2_client.settings.yml)

google:
  client_id: 'YOUR_GOOGLE_CLIENT_ID'
  client_secret: 'YOUR_GOOGLE_CLIENT_SECRET'
  authorize_url: 'https://accounts.google.com/o/oauth2/v2/auth'
  token_url: 'https://oauth2.googleapis.com/token'
  redirect_uri: 'https://your-drupal-site.it/oauth2/callback'
  scopes:
    - email
    - profile

Integrazione nella pagina di login

Drupal permette di aggiungere un pulsante di login esterno tramite il blocco fornito dal modulo. Nel file di tema (yourtheme/templates/block--oauth2-client.html.twig) è possibile personalizzare l’aspetto:

Il flusso di autenticazione rimane completamente trasparente per l’utente, mentre il CMS si occupa di creare o associare l’account locale in base alle informazioni ricevute.

Nota: Prima di andare in produzione è fondamentale testare l’intero flusso, verificando che i token vengano correttamente ricevuti, salvati e utilizzati, e che l’utente venga mappato correttamente ai ruoli Drupal previsti.

Configurazione dei provider esterni

Ogni provider OAuth 2.0 richiede una configurazione dedicata. È necessario registrare l’applicazione presso il portale di sviluppo del provider, definire uno o più redirect URI validi e ottenere le credenziali client. Questi dati devono combaciare esattamente con quelli configurati in Drupal, in particolare per quanto riguarda il redirect URI, che è uno dei punti più sensibili dal punto di vista della sicurezza.

Gli scope richiesti devono essere limitati allo stretto necessario. Richiedere più permessi del dovuto non solo aumenta i rischi, ma può anche ridurre la fiducia dell’utente e impedire il completamento del flusso di autorizzazione.

Una volta salvata e attivata la configurazione, il provider diventa immediatamente disponibile come metodo di autenticazione. Drupal gestisce internamente la logica di associazione tra identità esterna e account locale, evitando duplicazioni e incongruenze.

Gestione dei token e delle autorizzazioni

La gestione corretta dei token è un aspetto cruciale di qualsiasi implementazione OAuth 2.0. Gli access token dovrebbero avere una durata breve, idealmente dell’ordine di un’ora, mentre i refresh token devono essere trattati come credenziali sensibili.

Salvataggio cifrato dei refresh token in Drupal

use Drupal\Core\Encryption\EncryptionServiceInterface;
use Drupal\user\Entity\User;

/**
 * Salva un refresh token cifrato per un utente.
 *
 * @param \Drupal\user\Entity\User $user
 *   L'utente Drupal.
 * @param string $refresh_token
 *   Il refresh token da salvare.
 */
function mymodule_store_refresh_token(User $user, $refresh_token) {
  /** @var \Drupal\Core\Encryption\EncryptionServiceInterface $encryption */
  $encryption = \Drupal::service('encryption');
  $encrypted = $encryption->encrypt($refresh_token);
  $user->set('field_refresh_token', $encrypted);
  $user->save();
}

Dal punto di vista delle autorizzazioni, OAuth 2.0 non sostituisce il sistema di permessi di Drupal. Gli scope ricevuti dal provider possono essere mappati a ruoli o permessi specifici, consentendo un controllo granulare sull’accesso alle funzionalità del sito. Questo approccio permette di mantenere una separazione chiara tra identità esterna e logica applicativa interna.

È buona norma limitare il numero di token attivi per utente e monitorare le richieste per individuare comportamenti anomali. Token inutilizzati o sospetti dovrebbero essere revocati tempestivamente.

Sicurezza e best practice

Un’implementazione OAuth 2.0 efficace richiede attenzione costante alla sicurezza. I moduli devono essere mantenuti aggiornati e le dipendenze verificate regolarmente. Gli URI di redirect devono essere validati in modo rigoroso per prevenire attacchi di tipo open redirect.

Tutta la comunicazione tra Drupal e i provider deve avvenire esclusivamente tramite HTTPS, senza eccezioni. I log di accesso e gli eventi legati all’emissione dei token dovrebbero essere monitorati, soprattutto in contesti ad alto traffico o con dati sensibili.

L’uso di access token a breve termine, combinato con refresh token ben protetti, rappresenta il miglior compromesso tra sicurezza e usabilità. Qualsiasi deviazione da questo modello dovrebbe essere attentamente valutata e giustificata da esigenze specifiche.

Conclusioni

L’integrazione di OAuth 2.0 in Drupal permette di costruire sistemi di autenticazione moderni, sicuri e scalabili, riducendo il carico legato alla gestione delle credenziali e migliorando l’esperienza utente. Drupal offre gli strumenti necessari per implementare questi flussi in modo pulito, mantenendo il controllo sui permessi e sul ciclo di vita degli utenti.

La configurazione iniziale richiede una buona comprensione sia del protocollo sia dell’architettura del CMS, ma i benefici nel medio e lungo periodo sono evidenti. Con una gestione attenta dei token, un uso corretto degli scope e un monitoraggio costante, OAuth 2.0 diventa un alleato solido nella costruzione di piattaforme affidabili.

Guardando al futuro, l’integrazione con OpenID Connect e l’adozione di meccanismi di autenticazione più avanzati continueranno a rafforzare il ruolo di Drupal come hub centrale per la gestione dell’identità in ecosistemi digitali complessi.

Articoli correlati

Vedi tutti →