4. Public Clients and Certificate-Bound Tokens (Client pubblici)

4. Public Clients and Certificate-Bound Tokens (Client pubblici e token vincolati)

L'autenticazione client OAuth mutual-TLS e gli access token vincolati al certificato possono essere usati indipendentemente l'uno dall'altro. L'uso di access token vincolati al certificato senza autenticazione client OAuth mutual-TLS è ad esempio possibile per vincolare gli access token a un TLS client certificate per i client pubblici (quelli senza credenziali di autenticazione associate al client_id). L'authorization server configurerebbe lo stack TLS allo stesso modo del metodo Self-Signed Certificate in modo da non verificare che il certificato presentato dal client durante l'handshake sia firmato da una CA attendibile. Singole istanze di un client creerebbero un certificato self-signed per mutual TLS sia con l'authorization server sia con il resource server. L'authorization server non userebbe il certificato mutual-TLS per autenticare il client a livello OAuth ma vincolerebbe l'access token rilasciato al certificato per cui il client ha dimostrato il possesso della corrispondente chiave privata. L'access token è quindi vincolato al certificato e può essere usato solo dal client che possiede il certificato e la chiave privata corrispondente e li usa per negoziare mutual TLS sulle connessioni al resource server. Quando l'authorization server rilascia un refresh token a tale client, DOVREBBE anche vincolare il refresh token al rispettivo certificato e verificare il vincolo quando il refresh token viene presentato per ottenere nuovi access token. I dettagli implementativi del vincolo del refresh token sono a discrezione dell'authorization server.