API Key/Secret per comunicazione machine2machine

Buongiorno,

chiedo il vostro parare per capire che cosa indicano le linee guida di AGID nel caso in cui mi trovo.
L’azienda per cui lavoro ha il proprio software in uso presso una PA, per esigenze particolari della PA si sta intraprendendo un progetto che riguarda una seconda softwarehouse per fare si che i nostri software lavorino “in sinergia”, uso questo termine per far intendere che si parla di qualcosa di un po’ più di uno scambio dati generico. Per intenderci, il codice sviluppato nell’ambito di questo progetto difficilmente sarà riutilizzabile nella sua interezza anche per altre PA in cui siano presenti sia il nostro software che quello dell’altra azienda, proprio perché si andrebbe a risolvere un’esigenza specifica.
Il progetto prevede, da parte nostra, la realizzazione di API Rest che verrebbero utilizzate dall’altro software per inviarci e mantenere aggiornate una serie di informazioni. In un secondo momento verrà ritrasmesso (a distanza di mesi e con modalità da definire) l’esito di una elaborazione basata anche su questi dati scambiati.
La mia domanda è la seguente: quale sarebbe la modalità più corretta per mettere in sicurezza le API che andremo a creare ?
Solitamente quando si parla di scambio m2m una pratica molto diffusa è quella di generare una coppia di API Key/Secret ed utilizzarle per autenticare ed autorizzare ogni singola chiamata, diciamo senza la necessità di effettuare una pre-autorizzazione.
Nelle linee guida AGID per l’interoperabilità, invece, viene esposto come unico metodo l’utilizzo dei JWT, che comporta quindi una fase di ottenimento del token (iniziale o ogni qualvolta il token in uso scada).
Sto male interpretando le linee guida o veramente l’unica strada da percorre prevista è quella dei JWT?
Ovviamente le API verranno sviluppate in OpenAPI 3.x scambiando dati in formato JSON, e rigorosamente su https.

Grazie a tutti.

Ciao @Kroot

è possibile, una volta stabilito un meccanismo fiduciario, ad esempio basato su chiavi asimmetriche, generare dei JWS che non richiedono il ricorso ad un authorization server. Il client può quindi con la sua chiave privata generare in autonomia dei JWS e il server può validarli utilizzando la chiave pubblica eventualmente contenuta in un certificato, anch’esso in autonomia.

Per ulteriori info unisciti al canale #api di https://slack.developers.italia.it