1. Introduzione
Un token di sicurezza è un insieme di informazioni che facilita la condivisione di identità e informazioni di sicurezza in ambienti eterogenei o tra domini di sicurezza. Esempi di token di sicurezza includono JSON Web Token (JWT) [JWT] e asserzioni Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os]. I token di sicurezza sono tipicamente firmati per garantire l'integrità e talvolta anche crittografati per garantire la riservatezza. I token di sicurezza sono talvolta descritti anche come asserzioni, come in [RFC7521].
Un Security Token Service (STS) è un servizio in grado di convalidare i token di sicurezza fornitigli ed emettere nuovi token di sicurezza in risposta, il che consente ai client di ottenere credenziali di accesso appropriate per le risorse in ambienti eterogenei o tra domini di sicurezza. I client Web Service hanno utilizzato WS-Trust [WS-Trust] come protocollo per interagire con un STS per lo scambio di token. Mentre WS-Trust utilizza XML e SOAP, la tendenza nello sviluppo Web moderno è stata verso pattern RESTful (Representational State Transfer) e JSON. L'OAuth 2.0 Authorization Framework [RFC6749] e gli OAuth 2.0 Bearer Token [RFC6750] sono emersi come standard popolari per autorizzare l'accesso di applicazioni di terze parti a risorse HTTP e RESTful. L'interazione OAuth 2.0 convenzionale prevede lo scambio di una rappresentazione dell'autorizzazione del proprietario della risorsa per un token di accesso, che si è rivelato un modello estremamente utile nella pratica. Tuttavia, il suo input e output sono in qualche modo troppo vincolati così come sono per accogliere pienamente un framework di scambio di token di sicurezza.
Questa specifica definisce un protocollo che estende OAuth 2.0 che consente ai client di richiedere e ottenere token di sicurezza dai server di autorizzazione che agiscono nel ruolo di un STS. Simile a OAuth 2.0, questa specifica si concentra sulla semplicità per lo sviluppatore client e richiede solo un client HTTP e un parser JSON, che sono quasi universalmente disponibili negli ambienti di sviluppo moderni. Il protocollo STS definito in questa specifica non è di per sé RESTful (un STS non si presta particolarmente bene a un approccio REST) ma utilizza pattern di comunicazione e formati di dati che dovrebbero essere familiari agli sviluppatori abituati a lavorare con sistemi RESTful.
Un nuovo tipo di concessione (grant type) per una richiesta di scambio di token e i parametri specifici associati per tale richiesta all'endpoint del token sono definiti da questa specifica. Una risposta di scambio di token è una normale risposta OAuth 2.0 dall'endpoint del token con alcuni parametri aggiuntivi qui definiti per fornire informazioni al client.
L'entità che effettua la richiesta di scambiare token è considerata il client nel contesto dell'interazione di scambio di token. Tuttavia, ciò non limita l'utilizzo di questo profilo ai client OAuth tradizionali. Un server di risorse OAuth, ad esempio, potrebbe assumere il ruolo del client durante lo scambio di token per scambiare un token di accesso ricevuto in una richiesta di risorsa protetta con un nuovo token appropriato da includere in una chiamata a un servizio backend. Il nuovo token potrebbe essere un token di accesso con ambito più ristretto per il servizio a valle o potrebbe essere un tipo di token completamente diverso.
L'ambito di questa specifica è limitato alla definizione di un protocollo di richiesta e risposta di base per uno scambio di token in stile STS utilizzando OAuth 2.0. Sebbene siano state definite alcune nuove claim JWT che consentono di esprimere la semantica di delega, la sintassi specifica, la semantica e le caratteristiche di sicurezza dei token stessi (sia quelli presentati al server di autorizzazione che quelli ottenuti dal client) sono esplicitamente fuori ambito e non vengono posti requisiti sul modello di fiducia in cui un'implementazione potrebbe essere distribuita. Profili aggiuntivi possono fornire requisiti più dettagliati sulla natura specifica delle parti e sulla fiducia coinvolta, come ad esempio se è necessaria la firma e/o la crittografia dei token o se saranno richiesti o emessi token in stile proof-of-possession. Tuttavia, tali dettagli saranno spesso decisioni politiche prese rispetto alle esigenze specifiche delle singole distribuzioni e saranno configurati o implementati di conseguenza.
I token di sicurezza ottenuti possono essere utilizzati in una serie di contesti, le cui specifiche vanno anche oltre l'ambito di questa specifica.
1.1. Semantica di delega vs. impersonificazione
Un caso d'uso comune per un STS (come accennato nella sezione precedente) è consentire a un server di risorse A di effettuare chiamate a un servizio backend C per conto dell'utente richiedente B. A seconda della politica del sito locale e dell'infrastruttura di autorizzazione, potrebbe essere desiderabile che A utilizzi le proprie credenziali per accedere a C insieme a un'annotazione di qualche forma che indichi che A sta agendo per conto di B ("delega") o che ad A venga concessa una credenziale di accesso limitata a C ma che continui a identificare B come l'entità autorizzata ("impersonificazione"). La delega e l'impersonificazione possono essere concetti utili anche in altri scenari che coinvolgono più partecipanti.
Quando il principal A impersona il principal B, ad A vengono concessi tutti i diritti che B ha all'interno di un contesto di diritti definito ed è indistinguibile da B in quel contesto. Pertanto, quando il principal A impersona il principal B, per quanto riguarda qualsiasi entità che riceve tale token, essa ha effettivamente a che fare con B. È vero che alcuni membri del sistema di identità potrebbero essere consapevoli che è in corso un'impersonificazione, ma non è un requisito. A tutti gli effetti, quando A impersona B, A è B nel contesto dei diritti autorizzati dal token. La capacità di A di impersonare B potrebbe essere limitata nell'ambito o nel tempo, o anche con una restrizione di utilizzo una tantum, sia tramite il contenuto del token che tramite un meccanismo fuori banda.
La semantica di delega è diversa dalla semantica di impersonificazione, sebbene le due siano strettamente correlate. Con la semantica di delega, il principal A ha ancora la propria identità separata da B, ed è esplicitamente inteso che mentre B potrebbe aver delegato alcuni dei suoi diritti ad A, qualsiasi azione intrapresa viene intrapresa da A che rappresenta B. In un certo senso, A è un agente per B.
La delega e l'impersonificazione non comprendono tutte le situazioni. Quando un principal agisce direttamente per proprio conto, ad esempio, non sono in gioco né la delega né l'impersonificazione. Sono, tuttavia, le semantiche più comuni che operano per lo scambio di token e, come tali, ricevono un trattamento più diretto in questa specifica.
La semantica di delega è tipicamente espressa in un token includendo informazioni sia sul soggetto primario del token che sull'attore a cui tale soggetto ha delegato alcuni dei suoi diritti. Tale token è talvolta indicato come token composito perché è composto da informazioni su più soggetti. Tipicamente, nella richiesta, il "subject_token" rappresenta l'identità della parte per conto della quale viene richiesto il token mentre l'"actor_token" rappresenta l'identità della parte a cui vengono delegati i diritti di accesso del token emesso. Un token composito emesso dal server di autorizzazione conterrà informazioni su entrambe le parti. Quando e se viene emesso un token composito è a discrezione del server di autorizzazione e della politica e configurazione applicabili.
Le specifiche della rappresentazione di un token composito e persino se tale token verrà emesso dipendono dai dettagli dell'implementazione e dal tipo di token. Le rappresentazioni di token compositi che non sono JWT esulano dall'ambito di questa specifica. Il parametro di richiesta "actor_token", tuttavia, fornisce un mezzo per fornire informazioni sull'attore desiderato e la claim JWT "act" può fornire una rappresentazione di una catena di delega.
1.2. Notazione dei requisiti e convenzioni
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in lettere maiuscole, come mostrato qui.
1.3. Terminologia
Questa specifica utilizza i termini "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request" e "token response" definiti da OAuth 2.0 [RFC6749], e i termini "Base64url Encoding", "Claim" e "JWT Claims Set" definiti da JSON Web Token (JWT) [JWT].