Token di accesso personale, autenticazione machine-to-machine e definizione delle chiavi API e i loro scenari nel mondo reale

Se stai sviluppando un prodotto software o SaaS, ti imbatterai spesso in un'ampia serie di casi d'uso o richieste di funzionalità: richieste API. Soprattutto i clienti enterprise più grandi possono volere l'accesso programmatico alle risorse, sia a livello personale che organizzativo.

In questi casi, le chiavi API, i Token di Accesso Personale (PAT) e l'autenticazione Machine-to-Machine (M2M) sono spesso necessari. In questo articolo, esploreremo le differenze tra questi metodi e come possono essere utilizzati nella creazione di prodotti B2B per gli sviluppatori.

Le somiglianze#

Diamo prima un'occhiata alle somiglianze tra questi tre.

1. Scopo di sicurezza: Tutti e tre i metodi sono usati per proteggere e controllare l'accesso alle API, ai servizi o alle risorse. Servono tutti come mezzo di autenticazione e/o autorizzazione.
2. Approccio basato su token: Ogni metodo prevede tipicamente l'uso di una stringa o di un token unici per l'identificazione. Questi token sono solitamente inviati con le richieste API, spesso negli header o come parametri di query.
3. Revocabile: I token o le chiavi in tutti e tre i metodi possono essere revocati o invalidati se compromessi o non più necessari. Questo permette risposte rapide di sicurezza senza cambiare il sistema sottostante.
4. Accesso programmabile: Tutti e tre i metodi facilitano l'accesso programmatico alle API o ai servizi. Permettono l'automazione e l'integrazione tra sistemi o applicazioni diverse.
5. Auditabile: L'uso di questi metodi di autenticazione può essere registrato e verificato. Questo permette il monitoraggio degli accessi alle API, il monitoraggio di attività sospette e la redazione di rapporti di conformità.
6. Adattabile al controllo degli accessi: Tutti e tre i metodi possono essere implementati con vari livelli di controllo degli accessi e permessi. Possono essere adattati a diversi modelli di sicurezza e requisiti architettonici.
7. Indipendenza dal protocollo: Sebbene siano spesso usati con REST API, questi metodi possono essere applicati a diversi tipi di API e protocolli.

Comprendere queste somiglianze aiuta a riconoscere le basi comuni di questi metodi di autenticazione. Le loro differenze ti permettono di scegliere la soluzione più appropriata per i casi d'uso specifici e i requisiti di sicurezza.

Ora, discutiamo delle loro differenze, concentrandoci sui loro casi d'uso e quando utilizzare ciascun metodo.

Le differenze#

Chiavi API#

Le chiavi API sono usate per identificare e autorizzare l'applicazione o il servizio chiamante. Sono tipicamente a lunga durata e statiche fino alla loro rotazione e spesso hanno un set fisso di permessi. Sono principalmente utilizzate per comunicazioni server-to-server o per accedere a dati pubblici, questi token generalmente non rappresentano un utente specifico.

Come funzionano le chiavi API?#

Una chiave API viene emessa da un provider API e fornita a un consumatore API registrato [1], il quale la include con ogni richiesta. Il server API controlla quindi la chiave API per convalidare l'identità del consumatore prima di restituire i dati richiesti.

Le chiavi API non sono efficaci quanto altre forme di autenticazione API come OAuth e JWT, ma hanno comunque un ruolo importante nell'aiutare i produttori di API a monitorare l'uso mantenendo i dati sensibili sicuri.

[1]: Un consumatore API è qualsiasi applicazione, servizio o utente che interagisce con un'API per accedere alla sua funzionalità o ai suoi dati. Invia richieste all'API per eseguire operazioni come il recupero, la creazione, l'aggiornamento o l'eliminazione di risorse. I consumatori API possono essere applicazioni web, app mobili, altri server o persino singoli sviluppatori che utilizzano l'API per integrarsi con altri servizi o per costruire nuove funzionalità sulla base di piattaforme esistenti.

Postman: Che cos'è una chiave API?

Casi d'uso#

Quando si parla di casi d'uso delle chiavi API, spesso si menzionano automazione, condivisione dei dati, test, sviluppo e controllo della sicurezza. Tuttavia, questi sono piuttosto tecnici. Nella realtà, lo scopo più comune nella creazione di prodotti è l'integrazione.

Esempio 1: Integrazione con Zapier#

Zapier: Aggiungi autenticazione con Chiave API

Zapier è uno strumento di automazione popolare che collega diverse applicazioni web. Quando si integra un'applicazione con Zapier, vengono utilizzate chiavi API per autenticare e autorizzare l'accesso all'API dell'applicazione. Ad esempio, se vuoi automatizzare le attività tra un sistema CRM e uno strumento di marketing via email, genereresti una chiave API dal sistema CRM e la forniresti a Zapier. Questa chiave viene poi usata per autenticare le richieste da Zapier all'API del CRM, permettendo il flusso sicuro dei dati tra i due sistemi.

Esempio 2: Integrazione con Stripe#

Stripe utilizza le chiavi API per un'integrazione sicura con varie piattaforme e applicazioni. Usa la Dashboard per sviluppatori per creare, rivelare, eliminare e ruotare le chiavi API.

Token di Accesso Personale (PAT)#

Un token di accesso personale è un altro concetto simile ma rappresenta l'identità e i permessi di un utente specifico, viene generato dinamicamente dopo un'autenticazione o accesso riusciti, e ha tipicamente una durata limitata ma può essere rinfrescato. Forniscono un controllo degli accessi fine-tuned ai dati e alle capacità specifiche dell'utente e sono comunemente usati per strumenti CLI, script, o accesso API personale.

Come funzionano i PAT#

1. Creazione e gestione: Gli utenti generano i PAT attraverso le impostazioni del proprio account sulla rispettiva piattaforma.
   • Ad esempio, su GitHub, gli utenti possono creare PAT specifici o classici con permessi specifici e date di scadenza.
   • Nei prodotti Atlassian come Jira e Confluence, gli utenti possono creare PAT dalle impostazioni del loro profilo, assegnando al token un nome e una scadenza opzionale.
2. Utilizzo: I PAT vengono usati come token bearer nell'header Authorization delle richieste API. Questo significa che sono inclusi negli header HTTP per autenticare la richiesta.
   • Permettono un accesso sicuro alle risorse dell'API, permettendo agli utenti di svolgere azioni come creare, leggere, aggiornare e cancellare risorse basate sui permessi concessi al token.
   • I PAT possono essere usati in più applicazioni all'interno di una piattaforma, fornendo un modo unificato per gestire accessi e permessi.
3. Revoca e impostazione della scadenza:
   • I PAT offrono maggiore sicurezza permettendo agli utenti di revocarli se vengono compromessi, senza la necessità di cambiare la password dell'account.
   • Le piattaforme spesso raccomandano di impostare date di scadenza per i PAT al fine di ridurre il rischio che token a lunga durata possano essere sfruttati.

Casi d'uso#

Ci sono due scenari tipici,

Automazione e scripting

Questo significa quando uno sviluppatore usa un PAT per automatizzare il deployment di codice da un repository a un ambiente di produzione, riducendo l'intervento manuale e garantendo la consistenza.

Ad esempio, gli utenti di GitHub possono creare PAT per autenticare le operazioni Git su HTTPS e interagire con l'API REST di GitHub. Questo è utile per gli sviluppatori che hanno bisogno di automatizzare compiti come clonare repository, spingere commit o gestire issue e pull request.

Integrazione con applicazioni esterne

Questo significa, permettendo una comunicazione sicura tra sistemi e applicazioni differenti. Questo appare simile allo scenario in cui si integrano chiavi API ma il PAT rappresenta l'utente, non il cliente o l'applicazione.

Ad esempio, un project manager usa un PAT per integrare uno strumento di gestione progetto con un sistema esterno di tracciamento issue, permettendo uno scambio di dati e una sincronizzazione fluidi, come Atlassian (Jira e Confluence).

Gli scenari sopra sono più simili a strumenti per sviluppatori. I PAT sono utili solo per questo tipo di prodotti? No. Ecco due esempi aggiuntivi: uno è un sistema CMS e uno è uno strumento di produttività.

Esempio 1: Contentful#

Contentful: Token di Accesso Personale

Contentful è una piattaforma CMS headless, che offre PAT come alternativa ai token OAuth per l'accesso alla loro Content Management API (CMA).

Caratteristiche chiave includono:

• Gli utenti possono creare più token con scope e permessi differenti.
• I token sono legati all'account dell'utente, ereditandone i permessi.
• I PAT sono particolarmente utili per scopi di sviluppo e automazione.

Esempio 2: Airtable#

Creazione dei Token di Accesso Personale | Supporto Airtable

Airtable - una piattaforma di collaborazione cloud, implementa PAT per l'accesso API.

Il loro sistema permette:

• Creazione di più token con scope e livelli di accesso variabili.
• I token possono essere limitati a basi o spazi di lavoro specifici.
• Gli amministratori enterprise possono creare token con accesso più ampio attraverso l'organizzazione.

Autenticazione Machine-to-Machine (M2M)#

M2M è progettato per la comunicazione service-to-service senza intervento umano. Deriva dall'idea che username e password non siano sufficienti per proteggere i servizi e non siano efficienti per un'automazione efficace.

Le applicazioni Machine-to-Machine (M2M) ora adottano il flusso delle Client Credentials, che è definito nel protocollo di autorizzazione OAuth 2.0 RFC 6749. Può anche supportare protocolli standard simili. Sì, l'autenticazione M2M è più rigorosa rispetto agli standard aperti se paragonata a PAT e chiavi API.

Autentica l'applicazione o il servizio stesso, non un utente, e spesso implementa JWT (JSON Web Tokens) per l'autenticazione stateless. Questo fornisce un modo sicuro per i servizi di interagire tra loro nei sistemi distribuiti.

Come funziona l'autenticazione machine-to-machine#

Segue un processo simile:

1. Client Credentials: Ogni macchina (o servizio) ha un client ID e un secret unici.
2. Richiesta token: Il servizio invia queste credenziali al server di autorizzazione.
3. Token di accesso: Dopo la validazione, il server di autorizzazione emette un token di accesso, spesso un JWT (JSON Web Token).
4. Richieste API: Il servizio utilizza questo token per autenticare e autorizzare le richieste API a un altro servizio.
5. Validazione: Il servizio ricevente valida il token prima di concedere l'accesso alle sue risorse.

Casi d'uso#

Ecco un esempio conciso di utilizzo dell'autenticazione machine-to-machine (M2M) per la comunicazione back-end-to-back-end:

Scenario: Il Servizio A ha bisogno di accedere ai dati dall'API del Servizio B.

1. Configurazione:

   • Il Servizio A è registrato come cliente presso un server di autorizzazione.
   • Al Servizio A viene assegnato un client ID e un client secret.

2. Autenticazione:

   • Il Servizio A richiede un token di accesso dal server di autorizzazione:

3. Emissione del Token:

   • Il server di autorizzazione verifica le credenziali e rilascia un token di accesso JWT.

4. Richiesta API:

   • Il Servizio A usa il token per richiedere dati al Servizio B:

5. Validazione:

   • Il Servizio B valida il token con il server di autorizzazione.

6. Risposta:

   • Se valido, il Servizio B restituisce i dati richiesti al Servizio A.

Questo processo permette una comunicazione sicura e automatizzata tra il Servizio A e il Servizio B senza l'intervento dell'utente, utilizzando il flusso delle client credentials OAuth 2.0.

Comunicazione device-to-device

La comunicazione device-to-device, in particolare nel contesto dell'IoT (Internet of Things), si basa pesantemente sull'autenticazione machine-to-machine (M2M) per garantire uno scambio sicuro ed efficiente dei dati.

Ad esempio, come nei dispositivi smart home, un termostato intelligente comunica con un hub di automazione domestica centrale per regolare le impostazioni di temperatura in base alle preferenze dell'utente. Il termostato utilizza l'autenticazione M2M per inviare dati in modo sicuro all'hub e ricevere comandi, garantendo che solo i dispositivi autorizzati possano interagire con il sistema di riscaldamento della casa.

Riepilogo chiave#

Ok, sei arrivato alla fine di questo articolo. Posso avere un breve riepilogo? Certo! Ecco uno sguardo ai punti chiave:

1. Portata: Le chiavi API sono generali, i PAT (Token di Accesso Personale) sono specifici per l'utente, e i token M2M (Machine-to-Machine) sono specifici per il servizio.
2. Durata: Le chiavi API sono a lunga durata, i PAT hanno una durata più breve, e i token M2M possono variare.
3. Rappresentazione: Le chiavi API sono stringhe opache, i PAT possono essere opachi o strutturati, e i token M2M utilizzano spesso i JWT.
4. Casi d'uso: Le chiavi API sono per un accesso API semplice, i PAT sono per operazioni centrate sull'utente, e i token M2M sono per la comunicazione service-to-service.