3. Mutual-TLS Client Certificate-Bound Access Tokens (Token vincolati al certificato)

3. Mutual-TLS Client Certificate-Bound Access Tokens (Access token vincolati al certificato client mutual-TLS)

Quando il client usa mutual TLS sulla connessione al token endpoint, l'authorization server può vincolare l'access token rilasciato al client certificate. Tale vincolo si ottiene associando il certificato al token in modo accessibile alla protected resource, ad esempio incorporando l'hash del certificato direttamente nell'access token rilasciato, usando la sintassi descritta nella sezione 3.1, o tramite token introspection come descritto nella sezione 3.2. Vincolare l'access token al client certificate in questo modo ha il vantaggio di disaccoppiare tale vincolo dall'autenticazione del client presso l'authorization server, consentendo che mutual TLS durante l'accesso alla risorsa protetta serva unicamente come meccanismo di proof-of-possession. Altri metodi di associazione di un certificato a un access token sono possibili, per accordo tra authorization server e protected resource, ma esulano dall'ambito di questa specifica.

Affinché un resource server usi access token vincolati al certificato, deve sapere in anticipo che mutual TLS sarà usato per parte o tutti gli accessi alle risorse. In particolare, l'access token stesso non può essere usato come input alla decisione se richiedere o meno mutual TLS perché (dal punto di vista TLS) è « Application Data », scambiato solo dopo il completamento del TLS handshake, e la CertificateRequest iniziale avviene durante l'handshake, prima che le Application Data siano disponibili. Sebbene possano esistere occasioni successive per un client TLS di presentare un certificato, ad es. tramite TLS 1.2 renegotiation [RFC5246] o TLS 1.3 post-handshake authentication [RFC8446], questo documento non prevede il loro uso. È prevedibile che sia comune che un resource server che usa mutual TLS richieda mutual TLS per tutte le risorse ospitate, oppure serva risorse protette da mutual TLS e risorse ordinarie su combinazioni separate di hostname e porta, sebbene siano possibili altri flussi. Come la policy del resource server sia sincronizzata con l'authorization server (AS) è fuori dall'ambito di questo documento.

Nell'ambito di un flusso di accesso a risorsa protetta da mutual-TLS, il client effettua richieste alla protected resource, come descritto in [RFC6750], tuttavia tali richieste DEVONO essere effettuate su una connessione TLS reciprocamente autenticata usando lo stesso certificato usato per mutual TLS al token endpoint.

La protected resource DEVE ottenere, dal proprio livello di implementazione TLS, il client certificate usato per mutual TLS e DEVE verificare che il certificato corrisponda al certificato associato all'access token. Se non corrispondono, il tentativo di accesso alla risorsa DEVE essere respinto con un errore, secondo [RFC6750], usando lo status HTTP 401 e il codice di errore invalid_token.

I metadati per comunicare le capacità di server e client per gli access token vincolati al client certificate mutual-TLS sono definiti rispettivamente nelle sezioni 3.3 e 3.4.