Come può un cliente headless conoscere a fondo la versione API di un backend multi-istanza?

one instance of the client, supporting many API versions

Secondo me, il problema è che il tuo client non supporta una singola versione dell'API che richiede ad ogni chiamata.

Guarda alcune API popolari e vedrai che supportano un parametro di versione specificato nella stringa di query o in un'intestazione, ad esempio:

?api-version={version}

Accept: application/vnd.github.v3+json

Il client dovrebbe essere costruito per funzionare con una sola versione e chiedere quella versione quando usa l'API, invece di essere uno strumento dell'esercito svizzero in grado di gestire più versioni.

Quando la versione del client non è più supportata sul back-end, è ora di aggiornare il client.

Dimentica la "chiave API" come la descrivi.

Se si seppellisce un segreto nel codice lato client, di solito posso premere F12 e trovarlo.

Una regola importante da ricordare è che qualsiasi computer al di fuori del controllo completo è per definizione insicuro. Ciò significa che tutti i software lato client (ad esempio, tutti i JavaScript) sono a rischio per il reverse engineering, il disassemblaggio, ecc.

Se hai un server web, non c'è modo di garantire che il codice all'altro capo della connessione provenga o meno da te.

Tuttavia, non tutto è perduto. Dal momento che i tuoi utenti devono già accedere alle caselle di back-end, puoi implementare in modo sicuro una funzione GetVersion() che non fa pubblicità a tutti quanti. È disponibile solo per le persone e il codice che si sono già autenticati utilizzando un ID utente / password.

My question is: How can the client securely know the API version of the backend?

Come già accennato da @Dan Pichelman, una web app è facile da decodificare, ma dalla tua domanda non mi è chiaro se la tua API sta servendo un'app Web, un'app mobile o entrambe.

Nel caso in cui un'app mobile sia utilizzata come client, non sarà così banale come utilizzare F12 nell'app Web, ma strumenti come Xposed renderà possibile la decodificazione.

Quindi una soluzione a prova di proiettile non è possibile, ma per le app mobili puoi renderlo più sicuro e difficile da decodificare utilizzando alcuni Tecniche di API per dispositivi mobili per proteggere la chiave API e altri miglioramenti per rafforzare la sicurezza della tua API quando viene pubblicata un'app mobile, ad esempio:

• Blocco del certificato per proteggere il canale di comunicazione tra l'app mobile e l'API.
• HMAC di messaggi firmati / crittografati.
• Token JWT firmati con contenuto crittografato.
• OAUTH2 come alternativa più sicura per autenticare i tuoi utenti.
• Servizi di attestazione di app mobili

So is there another approach I've failed to hit upon yet?

L'approccio migliore secondo me è di non avere un client che supporti diverse versioni di Api, ma di avere un client che sia agonostico della versione dell'API back-end e un back-end API che è agnostico del client che usa esso.

Come posso ottenere questo, potrebbe essere la domanda nella tua mente ora?

Per me andrei con GraphpQL per realizzarlo. Basta posizionare un server GraphQL tra la tua API esistente e il tuo client, quindi l'onere di gestire le modifiche API passerà nel server GraphQL, non nella tua app.

Se non hai ancora progettato la tua API tradizionale, puoi utilizzare GraphQL per esporre i tuoi dati ai clienti.

Un buon articolo recente che ti guida attraverso GraphQL può essere questo , dove puoi vedere un confronto tra l'uso tradizionale delle API REST e un'API GraphQL. Intorno all'inizio del secondo terzo della pagina hai una sezione su "Wrapping di un'API REST con GraphQL in 3 semplici passaggi" che può aiutarti a capire meglio come utilizzare GraphQL rispetto a un'API tradizionale.

Token JWT

Token Based Authentication

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

Blocco dei certificati

Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.

OAUTH2

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

GraphQL

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

HMAC

Hash-based message authentication codes (or HMACs) are a tool for calculating message authentication codes using a cryptographic hash function coupled with a secret key. You can use an HMAC to verify both the integrity and authenticity of a message.

Dichiarazione di non responsabilità: non lavoro o ho alcuna relazione con Prisma, ma lavoro ad Approov.