4. Considerazioni sulla sicurezza

Poiché esistono molti modi diversi e validi per implementare un sistema OAuth 2.0, ci sono di conseguenza molti modi per un server di autorizzazione per determinare se un token è attualmente "active" (attivo) o meno. Tuttavia, poiché i server di risorse che utilizzano l'introspezione del token si affidano al server di autorizzazione per determinare lo stato di un token, il server di autorizzazione DEVE (MUST) eseguire tutti i controlli applicabili sullo stato di un token. Ad esempio, questi test includono quanto segue:

Se il token può scadere, il server di autorizzazione DEVE (MUST) determinare se il token è scaduto.
Se il token può essere emesso prima di poter essere utilizzato, il server di autorizzazione DEVE (MUST) determinare se il periodo di validità di un token è già iniziato.
Se il token può essere revocato dopo essere stato emesso, il server di autorizzazione DEVE (MUST) determinare se tale revoca ha avuto luogo.
Se il token è stato firmato, il server di autorizzazione DEVE (MUST) convalidare la firma.
Se il token può essere utilizzato solo presso determinati server di risorse, il server di autorizzazione DEVE (MUST) determinare se il token può essere utilizzato presso il server di risorse che effettua la chiamata di introspezione.

Se un server di autorizzazione non riesce a eseguire alcun controllo applicabile, il server di risorse potrebbe prendere una decisione di sicurezza errata basata su tale risposta. Si noti che non tutti questi controlli saranno applicabili a tutte le distribuzioni OAuth 2.0 e spetta al server di autorizzazione determinare quali di questi controlli (e qualsiasi altro controllo) si applicano.

Se lasciato non protetto e non limitato, l'endpoint di introspezione potrebbe rappresentare un mezzo per un attaccante per sondare una serie di possibili valori di token, alla ricerca di un token valido. Per prevenire ciò, il server di autorizzazione DEVE (MUST) richiedere l'autenticazione delle risorse protette che necessitano di accedere all'endpoint di introspezione e DOVREBBE (SHOULD) richiedere che le risorse protette siano specificamente autorizzate a chiamare l'endpoint di introspezione. Le specifiche di tali credenziali di autenticazione non rientrano nell'ambito di questa specifica, ma comunemente queste credenziali potrebbero assumere la forma di qualsiasi meccanismo di autenticazione client valido utilizzato con l'endpoint del token, un token di accesso OAuth 2.0 o un altro meccanismo di autorizzazione o autenticazione HTTP. Un singolo software che agisce sia come client che come risorsa protetta PUÒ (MAY) riutilizzare le stesse credenziali tra l'endpoint del token e l'endpoint di introspezione, sebbene ciò confluisca potenzialmente le attività delle porzioni client e risorsa protetta del software e il server di autorizzazione POTREBBE (MAY) richiedere credenziali separate per ciascuna modalità.

Poiché l'endpoint di introspezione accetta token OAuth 2.0 come parametri e risponde con informazioni utilizzate per prendere decisioni di autorizzazione, il server DEVE (MUST) supportare Transport Layer Security (TLS) 1.2 [RFC5246] e PUÒ (MAY) supportare meccanismi aggiuntivi del livello di trasporto che soddisfano i suoi requisiti di sicurezza. Quando si utilizza TLS, il client o la risorsa protetta DEVONO (MUST) eseguire un controllo del certificato server TLS/SSL, come specificato in [RFC6125]. Le considerazioni sulla sicurezza dell'implementazione possono essere trovate in Recommendations for Secure Use of TLS and DTLS [BCP195].

Per impedire che i valori dei token di accesso vengano divulgati nei log lato server tramite parametri di query, un server di autorizzazione che offre l'introspezione del token PUÒ (MAY) vietare l'uso di HTTP GET sull'endpoint di introspezione e richiedere invece che il metodo HTTP POST venga utilizzato sull'endpoint di introspezione.

Per evitare di rivelare lo stato interno del server di autorizzazione, una risposta di introspezione per un token inattivo NON DOVREBBE (SHOULD NOT) contenere ulteriori claim oltre al claim "active" richiesto (con il suo valore impostato su "false").

Poiché una risorsa protetta PUÒ (MAY) memorizzare nella cache la risposta dell'endpoint di introspezione, i progettisti di un sistema OAuth 2.0 che utilizzano questo protocollo DEVONO (MUST) considerare i compromessi in termini di prestazioni e sicurezza intrinseci nella memorizzazione nella cache di informazioni di sicurezza come queste. Una cache meno aggressiva con un timeout breve fornirà alla risorsa protetta informazioni più aggiornate (dovendo interrogare l'endpoint di introspezione più spesso) a costo di un aumento del traffico di rete e del carico sull'endpoint di introspezione. Una cache più aggressiva con una durata più lunga ridurrà al minimo il traffico di rete e il carico sull'endpoint di introspezione, ma a rischio di informazioni obsolete sul token. Ad esempio, il token potrebbe essere revocato mentre la risorsa protetta si affida al valore della risposta memorizzata nella cache per prendere decisioni di autorizzazione. Ciò crea una finestra durante la quale un token revocato potrebbe essere utilizzato presso la risorsa protetta. Di conseguenza, una durata di validità della cache accettabile deve essere attentamente considerata date le preoccupazioni e le sensibilità della risorsa protetta a cui si accede e la probabilità che un token venga revocato o invalidato nel periodo intermedio. Gli ambienti altamente sensibili possono scegliere di disabilitare completamente la memorizzazione nella cache sulla risorsa protetta per eliminare completamente il rischio di informazioni memorizzate nella cache obsolete, sempre a costo di un aumento del traffico di rete e del carico del server. Se la risposta contiene il parametro "exp" (scadenza), la risposta NON DEVE (MUST NOT) essere memorizzata nella cache oltre il tempo ivi indicato.

Un server di autorizzazione che offre l'introspezione del token deve essere in grado di comprendere i valori del token presentati ad esso durante questa chiamata. Il mezzo esatto con cui ciò accade è un dettaglio di implementazione e non rientra nell'ambito di questa specifica. Per i token non strutturati, ciò potrebbe assumere la forma di una semplice query di database lato server su un archivio dati contenente le informazioni di contesto per il token. Per i token strutturati, ciò potrebbe assumere la forma del server che analizza il token, convalida la sua firma o altri meccanismi di protezione e restituisce le informazioni contenute nel token alla risorsa protetta (consentendo alla risorsa protetta di non essere a conoscenza del contenuto del token, proprio come il client). Si noti che per i token che trasportano informazioni crittografate necessarie durante il processo di introspezione, il server di autorizzazione deve essere in grado di decrittografare e convalidare il token per accedere a queste informazioni. Si noti inoltre che nei casi in cui il server di autorizzazione non memorizza informazioni sul token e non ha modo di accedere alle informazioni sul token analizzando il token stesso, probabilmente non può offrire un servizio di introspezione.