Esposizione dell'API protetta senza credenziali di hardcoding nel client (JS)

Cerca di esporre l'API REST protetta senza esporre le credenziali nel client (codice JS).

Tutte le soluzioni che mi vengono in mente possono essere invertite e l'Attaccante può ricostruirli.

Esistono soluzioni provate? Best practice?

Idee, sono venuto ad esempio:

1. Offuscamento delle credenziali

2. Hashing lato client set di elementi e confronto lato server a assicurati che il Client sia intatto (non utilizzato dall'Attaccante)

può essere invertito.

Sfortunatamente, l'autenticazione HTTPS non entra in gioco, dal momento che il sito web che accede all'API REST (Client, codice JS) dovrebbe essere aperto al pubblico. Non posso richiedere a ciascun Cliente (visitatore del sito web) di richiedere un PKC (Public Key Certificate)

HTTPS Client Authentication

HTTPS Client Authentication requires the client to possess a Public Key 
Certificate (PKC). 
If you specify client authentication, the web server will authenticate the 
client using the client’s public key certificate.
HTTPS Client Authentication is a more secure method of authentication than 
either basic or form-based authentication. It uses HTTP over SSL (HTTPS), 
in which the server authenticates the client using the client’s Public Key 
Certificate (PKC). Secure Sockets Layer (SSL) technology provides data encryption,
server authentication, message integrity, and optional client authentication for a 
TCP/IP connection. You can think of a public key certificate as the digital 
equivalent of a passport. It is issued by a trusted organization, which 
is called a certificate authority (CA), and provides identification for 
the bearer.

Voglio impedire che le persone ottengano credenziali e raschino / eseguano molte richieste all'API REST.

Suppongo che la nostra unica soluzione sia la limitazione basata su IP? Per punire i clienti cattivi.

Grazie in anticipo!

Aggiornamento 1:

Dopo le discussioni con @ThoriumBR, è nata questa soluzione. Non ottimale ma dovrebbe essere meglio di niente.

Design:

Sito web cliente < - > Nuova API (Proxy) < - > Vecchia API

Portata:

Avvolgi le vecchie API (private) contro le nuove API (pubbliche, nel diagramma sopra il Proxy)

1) Il sito Web del client fa richiesta al proxy

2) Proxy Invia indietro CAPCHA

3) Sito web client completo CAPCHA

4) Il proxy crea JWT (assegna il valore di capcha intrval in JWT ad esempio 10 (capcha_int: 10), assegna deviceid: fingerprint (per conoscere gli utenti dallo stesso IP)) lo rimanda al sito Web del cliente. Il proxy controlla anche l'abuso, se il deviceid si comporta male, verrà bloccato.

5) Sito web Invia richiesta al proxy con JWT

6) Verifica proxy JWT, se l'intervallo di capcha (capcha_int) è uguale a 10 invia CAPCHA, lo ripristina, se non funziona correttamente, in caso contrario invia la richiesta alla vecchia API

7) la vecchia Api invia la risposta tramite Proxy al sito Web del cliente

Gli IP saranno basati su IP Throttled per abuso. (secondo livello per prevenire gli abusi)