Hosted Login (Universal Login)

Ogni applicazione che autentica gli utenti deve decidere dove vive il form di login. Ci sono tre approcci fondamentali e la scelta ha profonde implicazioni di sicurezza.

L’applicazione rende il proprio form di login e raccoglie le credenziali direttamente. Il problema: il codice JavaScript della tua applicazione può leggere il form di login, intercettare i tasti premuti e accedere alle credenziali.

Le credenziali vengono inserite su una origin diversa — quella controllata dall’identity provider. Il JavaScript della tua applicazione non può leggere i campi del form, intercettare i tasti premuti o accedere alle credenziali in alcun modo. La policy same-origin del browser applica questo confine automaticamente.

Rischio	Login Incorporato	Login Hosted
XSS ruba le credenziali	Sì — il tuo JS può leggere il campo password	No — origin diversa, il tuo JS non può accedervi
Script di terze parti legge le credenziali	Sì	No — gli script di terze parti sulla tua origin non possono raggiungere la pagina auth
Phishing delle credenziali tramite manipolazione DOM	Sì	No — la pagina di login è sul dominio dell’IdP
Enforcement MFA	Devi implementarlo	L’IdP lo gestisce in modo trasparente
Ambito dell’audit di conformità	L’intera tua applicazione	Solo le pagine di login dell’IdP

Il Hosted Login è l’approccio raccomandato dall’OAuth 2.0 Security Best Current Practice (RFC 6819). Auth0 lo chiama “Universal Login,” Okta lo chiama “Okta-hosted Sign-In,” e Auris lo chiama “Hosted Login.” Il principio di sicurezza è lo stesso: non lasciare mai che la tua applicazione tocchi le credenziali grezze.

Come Funziona: Il Flusso Completo

Auris Hosted Login implementa il flusso OAuth2 Authorization Code con PKCE (RFC 7636). Il flusso:

La tua app genera un code verifier e un code challenge PKCE
Il browser viene reindirizzato all’endpoint /api/oauth/authorize di Auris con il code challenge
Auris crea una OAuthSession per tracciare il progresso
L’utente viene reindirizzato alla pagina di login hosted di Auris
L’utente inserisce le credenziali (email/password, magic link, social, ecc.)
Se richiesto, viene presentata la schermata MFA
Auris emette un authorization code monouso (5 minuti)
Il browser viene reindirizzato al redirect_uri della tua app con il codice
La tua app valida lo state (protezione CSRF) e scambia il codice per token
Auris verifica il code challenge PKCE ed emette i token

PKCE S256: Perché È Importante

PKCE (Proof Key for Code Exchange) previene gli attacchi di intercettazione dell’authorization code.

Se un attaccante intercetta l’authorization code nell’URL di redirect, non può scambiarlo. Per scambiare il codice, ha bisogno del code_verifier — che non è mai stato trasmesso attraverso la barra URL del browser. Era archiviato nella memoria del client e inviato direttamente all’endpoint token tramite HTTPS.

Auris applica PKCE S256 a tutti i flussi authorization code. Il metodo di challenge plain viene rifiutato. Non esiste configurazione per disabilitare PKCE — è sempre richiesto.

Gestione delle Sessioni

Auris usa due modelli lato server per gestire il flusso hosted login:

OAuthSession

Creata quando l’utente arriva all’endpoint authorize. Archiviata nel database e identificata da un cookie httpOnly.

Campo	Descrizione
`sessionToken`	Identificatore univoco (impostato come cookie httpOnly, Secure, SameSite=Lax)
`clientId`	L’applicazione che richiede l’autenticazione
`redirectUri`	Dove reindirizzare dopo l’autenticazione
`codeChallenge`	Code challenge PKCE (S256)
`state`	Valore state CSRF dal client
`scope`	Scope OAuth richiesti
`TTL`	30 minuti (la sessione scade se l’utente non completa il login)

AuthorizationCode

Creato dopo l’autenticazione riuscita.

Campo	Descrizione
`code`	Authorization code univoco
`clientId`	Deve corrispondere al `client_id` della richiesta token
`redirectUri`	Deve corrispondere esattamente al `redirect_uri` della richiesta token
`codeChallenge`	Archiviato per la verifica PKCE allo scambio token
`TTL`	5 minuti
`usedAt`	Impostato atomicamente al primo utilizzo (enforcement monouso)

Ogni tentativo di login passa attraverso una pipeline di controlli di sicurezza in questa sequenza:

Rate limiting: Limite di 10 tentativi per IP ogni 15 minuti
Account bloccato: Se l’account è bloccato, rifiuta immediatamente
Verifica credenziali: Email + password controllata in Keycloak
Rilevamento accessi sospetti: IP/paese sconosciuto, nuovo dispositivo, ora insolita
Risk scoring adattivo: Punteggio da 0 a 100 basato su segnali comportamentali
Valutazione policy MFA: Trigger MFA se richiesto dalla policy o dallo score di rischio
Actions Engine: Hook personalizzati pre_login e post_login
Emissione token: Generazione access token, refresh token e ID token

Protezione Brute Force

Metrica	Soglia	Azione
Tentativi di login	10 in 15 min (per IP)	Blocco temporaneo 15 min
Tentativi falliti	5 consecutivi (per utente)	Blocco account, email di notifica
Traffico anomalo	Rilevato dall’analisi IP	Rate limiting adattivo

Domini Personalizzati

Quando è configurato un dominio personalizzato, la pagina di login hosted viene servita da quel dominio. La pipeline di sicurezza è identica. I certificati SSL vengono gestiti automaticamente tramite Let’s Encrypt.

La pagina di login hosted riflette automaticamente:

Il logo caricato nelle impostazioni branding
Il colore primario del brand
Il nome dell’organizzazione
I provider di login social configurati

Implementazione con l’SDK


import { AurisClient } from '@auris/js'
 
const auris = new AurisClient({
  domain: 'api.altovar.net',
  clientId: 'il-tuo-client-id',
  redirectUri: 'https://app.tuodominio.com/callback',
})
 
// Avvia il login
await auris.loginWithRedirect()
 
// Gestisci il callback
const { user } = await auris.handleRedirectCallback()

L’SDK gestisce automaticamente la generazione PKCE, l’archiviazione, la validazione dello state e lo scambio del codice.

Concetti Correlati

OAuth 2.0 & OIDC — I protocolli sottostanti
Flusso PKCE — Guida tecnica dettagliata del flusso PKCE
Sessioni — Come le sessioni vengono create e gestite dopo il login
Guida Hosted Login — Integra il login hosted nella tua applicazione
Branding — Personalizza l’aspetto della pagina di login

Hosted Login (Universal Login)

Il Problema: Dove Deve Vivere il Form di Login?

Login Incorporato (l’approccio rischioso)

Login Hosted (l’approccio sicuro)