1. Introduction (Introduzione)
1. Introduction (Introduzione)
Diversi anni di distribuzione ed esperienza di implementazione con il framework di autorizzazione OAuth 2.0 [RFC6749] hanno messo in luce un'esigenza (in alcune circostanze, ad esempio quando un server di autorizzazione serve un numero significativo di risorse diverse) perché il client segnali esplicitamente al server di autorizzazione dove intende utilizzare l'access token (token di accesso) che sta richiedendo.
Conoscere la risorsa protetta (nota anche come resource server, applicazione, API, ecc.) che elaborerà l'access token consente al server di autorizzazione di costruire il token come necessario per quell'entità. Cifrare correttamente il token (o il contenuto nel token) per una risorsa particolare richiede ad esempio di sapere quale risorsa riceverà e decifrerà il token. Inoltre, varie risorse spesso hanno requisiti diversi riguardo ai dati contenuti nel token (o a cui il token fa riferimento), e conoscere la risorsa in cui il client intende usare il token consente al server di autorizzazione di emettere il token di conseguenza.
La conoscenza specifica dei destinatari previsti dell'access token facilita anche il miglioramento delle caratteristiche di sicurezza del token stesso. I bearer token, attualmente il tipo di access token OAuth più comunemente utilizzato, consentono a qualsiasi parte in possesso di un token di ottenere l'accesso alle risorse associate. Per prevenire abusi, devono valere diverse importanti assunzioni di sicurezza, tra cui che un access token debba essere valido solo per una specifica risorsa protetta e per uno specifico scope di accesso. La sezione 5.2 di [RFC6750], ad esempio, prescrive di includere nel token i destinatari previsti per prevenire il reindirizzamento del token. Quando il server di autorizzazione è informato della risorsa che elaborerà l'access token, può limitare l'audience prevista di quel token alla risorsa data in modo che il token non possa essere usato con successo su altre risorse.
Lo scope OAuth, dalla sezione 3.3 di [RFC6749], è talvolta sovraccaricato per veicolare la posizione o l'identità della risorsa protetta; tuttavia ciò non è sempre fattibile o desiderabile. Lo scope riguarda tipicamente quale accesso viene richiesto piuttosto che dove tale accesso sarà riscattato (ad esempio "email", "admin:org", "user_photos", "channels:read" e "channels:write" sono un piccolo campione di valori di scope in uso che veicolano solo il tipo di accesso e non la posizione o l'identità).
In alcune circostanze e per alcune distribuzioni, un mezzo per il client di segnalare al server di autorizzazione dove intende usare l'access token che sta richiedendo è importante e utile. Numerose implementazioni e distribuzioni di OAuth 2.0 hanno già impiegato parametri proprietari a tal fine. In avanti, questa specifica aspira a fornire un'alternativa standardizzata e interoperabile agli approcci proprietari.