Appendix B. Relationship to Token Binding (Rapporto con Token Binding)

Appendix B. Relationship to Token Binding (Rapporto con Token Binding)

OAuth 2.0 Token Binding [TOKEN] consente di applicare Token Binding ai vari artefatti e token impiegati in OAuth. Ciò include il vincolo di un token di accesso a una chiave Token Binding, che presenta alcune somiglianze nella motivazione e nella progettazione rispetto ai token di accesso vincolati al certificato client mutual-TLS definiti nel presente documento. Entrambi i documenti definiscono ciò che è spesso chiamato meccanismo di sicurezza di prova di possesso (proof-of-possession) per i token di accesso, in base al quale un client deve dimostrare il possesso di materiale crittografico di chiave quando accede a una risorsa protetta. I dettagli differiscono in parte tra i due documenti, ma in entrambi i casi il server di autorizzazione vincola il token di accesso che emette a una coppia di chiavi asimmetriche detenuta dal client. Il client dimostra quindi il possesso della chiave privata di tale coppia rispetto alla connessione TLS sulla quale si accede alla risorsa protetta.

Token Binding utilizza chiavi «nude» generate sul client, evitando molte delle difficoltà legate alla creazione, distribuzione e gestione dei certificati usati in questa specifica. Tuttavia, al momento della stesura, Token Binding è relativamente nuovo e il supporto nelle piattaforme di sviluppo applicativo e negli strumenti disponibili è piuttosto limitato. Finché non esisterà un supporto migliore per le specifiche di base di Token Binding, le implementazioni pratiche di OAuth 2.0 Token Binding restano poco fattibili. Mutual TLS, al contrario, è presente da tempo e gode di ampio supporto nei server web e nelle piattaforme di sviluppo. Di conseguenza, l'autenticazione client OAuth 2.0 Mutual-TLS e i token di accesso vincolati al certificato possono essere realizzati e distribuiti subito usando piattaforme e strumenti esistenti. In futuro è probabile che le due specifiche vengano distribuite in parallelo per affrontare problemi simili in ambienti diversi. I server di autorizzazione possono persino supportare entrambe le specifiche contemporaneamente, usando meccanismi di prova di possesso (proof-of-possession) diversi per i token rilasciati a client diversi.