Impostazioni OAuth2 Avanzate
Auris supporta quattro funzionalità OAuth2 avanzate oltre al flusso standard Authorization Code + PKCE: Device Authorization Flow, Client-Initiated Backchannel Authentication (CIBA), DPoP (Demonstration of Proof-of-Possession) e Token Exchange. Ogni funzionalità è configurata per applicazione e può essere abilitata indipendentemente.
Queste funzionalità affrontano scenari enterprise come l’autenticazione su dispositivi con input limitato (smart TV, strumenti CLI), l’autenticazione avviata dal server (call center, approvazioni kiosk), la crittografia sender-constraining dei token e la delega controllata dell’identità.
Accedi tramite Console → Applicazioni → seleziona un’applicazione → scheda Impostazioni.
Device Authorization Flow (RFC 8628)
Il Device Authorization Flow consente agli utenti di autenticarsi su dispositivi privi di browser o con capacità di input limitate. Il dispositivo mostra un codice breve che l’utente inserisce su un dispositivo separato (telefono o computer) per autorizzare la sessione.
Abilitare il Device Flow
Apri le impostazioni dell’applicazione
Vai su Console → Applicazioni e clicca sull’applicazione che vuoi configurare. Naviga sulla scheda Impostazioni.
Abilita il Device Flow
Attiva Abilita Device Flow.
Configura le impostazioni
| Impostazione | Default | Descrizione |
|---|---|---|
| Intervallo Polling | 5 secondi | Con quale frequenza il dispositivo deve interrogare l’endpoint token per lo stato dell’autorizzazione. Impostare troppo basso aumenta il carico del server. |
| Durata Codice | 600 secondi (10 min) | Per quanto tempo il codice utente rimane valido. Dopo la scadenza, il dispositivo deve richiedere un nuovo codice. |
| Lunghezza Codice Utente | 8 caratteri | Lunghezza del codice mostrato all’utente. I codici più lunghi sono più sicuri ma più difficili da digitare. |
Salva
Clicca su Salva per applicare la configurazione.
URI di Verifica
Dopo aver abilitato il Device Flow, Auris fornisce un URI di Verifica per la tua applicazione. Questo è l’URL che mostri agli utenti insieme al codice del dispositivo:
https://auth.tuo-dominio.com/hosted/deviceLa tua applicazione per dispositivi dovrebbe mostrare sia l’URI di verifica che il codice utente, per esempio:
Per accedere, visita: https://auth.tuo-dominio.com/hosted/device
Inserisci il codice: ABCD-EFGHL’URI di verifica è lo stesso per tutte le applicazioni nel tuo tenant. Il codice utente identifica univocamente la sessione di autorizzazione del dispositivo, quindi non è necessario un URL specifico per l’applicazione.
Come Funziona
- Il dispositivo richiede un device code da
POST /api/oauth/device/authorize - L’utente visita l’URI di verifica e inserisce il codice
- L’utente si autentica normalmente (password, MFA, SSO — qualunque cosa richieda il tuo tenant)
- Il dispositivo interroga
POST /api/auth/tokencongrant_type=urn:ietf:params:oauth:grant-type:device_codefino a quando l’utente completa l’autenticazione - Una volta autorizzato, il dispositivo riceve access e refresh token
/api/oauth/device/authorize/api/auth/tokenClient-Initiated Backchannel Authentication (CIBA)
CIBA abilita l’autenticazione server-to-server in cui la relying party avvia l’autenticazione senza che l’utente sia presente nell’applicazione. L’utente riceve una notifica (SMS o email) e approva il login sul proprio dispositivo.
I casi d’uso tipici includono l’autenticazione nei call center (“abbiamo inviato una notifica al tuo telefono — approvala per verificare la tua identità”) e la ri-autenticazione in background per sessioni di lunga durata.
Abilitare CIBA
Apri le impostazioni dell’applicazione
Vai su Console → Applicazioni e seleziona l’applicazione. Naviga sulla scheda Impostazioni.
Abilita CIBA
Attiva Abilita CIBA.
Configura le impostazioni di notifica
| Impostazione | Default | Descrizione |
|---|---|---|
| Modalità Notifica | Poll | Come la relying party riceve il risultato dell’autenticazione. Vedi Modalità di Notifica di seguito. |
| Canale Notifica | Come l’utente viene notificato dell’autenticazione in attesa: SMS o Email. | |
| Durata Richiesta | 300 secondi (5 min) | Per quanto tempo la richiesta di autenticazione è valida prima della scadenza. |
| Modalità Consegna Token | Poll | Come il client riceve i token finali. Opzioni: poll, ping, push. |
Configura l’URL callback (solo modalità ping/push)
Se usi la modalità di notifica ping o push, inserisci l’URL Callback dove Auris dovrebbe inviare il risultato dell’autenticazione.
Salva
Clicca su Salva per applicare la configurazione.
Modalità di Notifica
| Modalità | Comportamento |
|---|---|
| Poll | La relying party interroga l’endpoint token a intervalli fino a quando l’utente risponde. Il più semplice da implementare. |
| Ping | Auris invia una notifica all’URL callback quando l’utente risponde, poi la relying party chiama l’endpoint token per recuperare i token. |
| Push | Auris invia i token direttamente all’URL callback quando l’utente approva. La relying party non ha bisogno di effettuare polling. |
La modalità Push consegna i token direttamente al tuo URL callback. Assicurati che questo endpoint sia protetto con TLS e validi la firma della richiesta in arrivo. Se l’URL callback viene compromesso, un attaccante potrebbe intercettare i token.
/api/oauth/backchannel/authorizeDPoP (Demonstration of Proof-of-Possession) — RFC 9449
DPoP lega gli access token a un client specifico richiedendo al client di dimostrare il possesso di una chiave privata ad ogni richiesta. Questo previene il furto di token e gli attacchi di replay — anche se un access token viene intercettato, non può essere usato senza la chiave privata corrispondente.
Abilitare DPoP
Apri le impostazioni dell’applicazione
Naviga su Console → Applicazioni → seleziona l’applicazione → scheda Impostazioni.
Abilita DPoP
Attiva Abilita DPoP.
Configura le impostazioni DPoP
| Impostazione | Default | Descrizione |
|---|---|---|
| Abilita DPoP | Off | Consente ai client di usare prove DPoP quando richiedono token. |
| Richiedi DPoP | Off | Quando abilitato, Auris rifiuta le richieste di token che non includono una prova DPoP valida. Abilita solo dopo aver confermato che tutti i client supportano DPoP. |
| Richiedi Nonce | Off | Aggiunge nonce emessi dal server al flusso DPoP per la protezione dal replay. Aumenta la sicurezza ma aggiunge un round-trip extra. |
Salva
Clicca su Salva per applicare.
Come Funziona DPoP
- Il client genera una coppia di chiavi asimmetriche (tipicamente ECDSA P-256)
- Ad ogni richiesta di token, il client crea un proof JWT DPoP firmato con la sua chiave privata, contenente il metodo HTTP, l’URL e un identificatore unico
- Auris verifica la prova e lega il token emesso alla chiave pubblica del client (JWK thumbprint)
- Nelle successive chiamate API, il client include sia l’access token che un nuovo header di prova DPoP
- I resource server verificano che la claim
jkt(JWK Thumbprint) del token corrisponda alla prova DPoP
La configurazione DPoP appare anche nella pagina di dettaglio dell’applicazione sotto la sezione Sicurezza, fornendo un accesso rapido alle stesse impostazioni da più percorsi di navigazione.
Token Exchange (RFC 8693)
Il Token Exchange consente a un servizio di scambiare un access token per un nuovo token con scope, soggetto o audience diversi. Supporta due pattern: impersonation (agire come un altro utente) e delegation (agire per conto di un altro utente mantenendo l’identità originale).
Abilitare il Token Exchange
Apri le impostazioni dell’applicazione
Naviga su Console → Applicazioni → seleziona l’applicazione → scheda Impostazioni.
Abilita il Token Exchange
Attiva Abilita Token Exchange.
Seleziona i tipi di scambio consentiti
| Tipo | Permesso Richiesto | Descrizione |
|---|---|---|
| Impersonation | impersonate:users | Il token risultante ha l’utente target come soggetto. L’identità originale non viene preservata. Usato per scenari di supporto admin. |
| Delegation | delegate:tokens | Il token risultante include una claim act (actor) che preserva l’identità originale del chiamante. Il soggetto è l’utente target. Usato per catene di delega service-to-service. |
Salva
Clicca su Salva per applicare.
L’impersonation è una funzionalità potente. Concedi il permesso impersonate:users
solo ad applicazioni e ruoli altamente fidati. Tutti i token exchange vengono registrati nel log
di audit con le identità originale e target.
/api/auth/tokenMonitoraggio
La Console fornisce pagine di monitoraggio dedicate per ciascuna funzionalità OAuth2 avanzata. Accedici dalla sezione OAuth Avanzato nella barra laterale.
Codici Dispositivo
Vai su Console → OAuth Avanzato → Codici Dispositivo per visualizzare tutte le sessioni di autorizzazione dispositivo attive e scadute.
| Colonna | Descrizione |
|---|---|
| Codice Utente | Il codice mostrato all’utente |
| Client | L’applicazione che ha richiesto il codice dispositivo |
| Stato | In Attesa, Autorizzato, Scaduto o Negato |
| Creato Il | Quando è stato emesso il codice dispositivo |
| Scade Il | Quando scade il codice dispositivo |
| Utente | L’utente che ha autorizzato la sessione (se autorizzata) |
Richieste CIBA
Vai su Console → OAuth Avanzato → Richieste CIBA per visualizzare le richieste di autenticazione backchannel.
| Colonna | Descrizione |
|---|---|
| ID Richiesta | Identificatore unico per la richiesta CIBA |
| Utente | L’utente in fase di autenticazione |
| Client | L’applicazione che ha avviato la richiesta |
| Stato | In Attesa, Completato, Scaduto o Negato |
| Modalità Notifica | Poll, Ping o Push |
| Creato Il | Quando è stata avviata la richiesta |
Token Exchange
Vai su Console → OAuth Avanzato → Token Exchange per visualizzare il log di audit di tutte le operazioni di token exchange.
| Colonna | Descrizione |
|---|---|
| Timestamp | Quando è avvenuto lo scambio |
| Tipo | Impersonation o Delegation |
| Identità Sorgente | L’identità autenticata originale |
| Identità Target | L’identità utente target |
| Client | L’applicazione che ha eseguito lo scambio |
| Scope | Gli scope concessi sul token scambiato |
Risk Scoring
Le funzionalità OAuth2 avanzate si integrano con il motore di risk scoring di Auris. Quando il risk scoring è abilitato, ogni autenticazione tramite Device Flow, CIBA o Token Exchange viene valutata per il rischio proprio come un login standard. Le autenticazioni ad alto rischio possono attivare requisiti MFA step-up.
Per la configurazione dettagliata del motore di rischio, dei pesi dei fattori, delle soglie e delle regole personalizzate, vedi la pagina dedicata Risk Scoring & MFA Adattivo.
Permessi
I seguenti permessi controllano l’accesso alle funzionalità OAuth2 avanzate:
| Permesso | Descrizione |
|---|---|
view:device_codes | Visualizza le sessioni di autorizzazione dispositivo attive |
manage:device_codes | Revoca codici dispositivo |
view:token_exchanges | Visualizza il log di audit del token exchange |
impersonate:users | Esegui token exchange di impersonation |
delegate:tokens | Esegui token exchange di delegation |
manage:dpop_config | Configura le impostazioni DPoP sulle applicazioni |
view:ciba_requests | Visualizza le richieste di autenticazione backchannel |
manage:ciba_config | Configura le impostazioni CIBA sulle applicazioni |
view:risk_assessments | Visualizza i dati di valutazione del rischio |
manage:risk_rules | Crea e modifica le regole di risk scoring |
manage:advanced_oauth | Accesso completo a tutte le impostazioni OAuth2 avanzate |
Guide Correlate
- Risk Scoring & MFA Adattivo — Configura il motore di rischio che protegge tutti i flussi OAuth2
- Device Authorization Flow — Guida per sviluppatori per implementare il Device Flow
- Integrazione CIBA — Guida per sviluppatori per l’autenticazione backchannel
- DPoP per la Sicurezza dei Token — Come implementare DPoP nella tua applicazione client
- Token Exchange — Guida per sviluppatori per impersonation e delegation
- Applicazioni — Gestione delle impostazioni delle applicazioni nella Console