• chiavi-api
  • token di accesso personale
  • macchina-a-macchina
  • servizio-a-servizio
  • backend-to-backend
  • autenticazione
  • autorizzazione
  • sicurezza
  • jwt
  • oauth2
  • rbac

Autenticazione programmatica: chiave API, token di accesso personale e flusso di credenziali cliente OAuth

Scopri i concetti chiave e i casi d'uso comuni per chiave API, Token di Accesso Personale (PAT) e credenziali Logto Machine-to-Machine (M2M).

Charles
Charles
Developer

Contesto

Nello sviluppo software, quando abbiamo bisogno di accedere programmaticamente a una risorsa API tramite comandi CLI o stabilire la comunicazione tra servizi backend, ci sono di solito tre meccanismi di autenticazione ampiamente utilizzati da noi sviluppatori: chiave API, Token di Accesso Personale (PAT) e flusso di credenziali cliente OAuth (nominato come Machine-to-Machine in Logto). Ma quali sono le differenze tra di loro? Qual è il miglior scenario per ognuno di questi metodi? In questo post del blog, approfondiremo le somiglianze, le differenze e forniremo approfondimenti su quando utilizzare ciascuno in diversi scenari.

Definizioni

  • Chiave API: Una semplice stringa che può autenticare la tua richiesta a una risorsa API.
  • Token di Accesso Personale (PAT): Anche una semplice stringa ma rappresenta un utente quando viene utilizzata per autenticarsi su una risorsa API. È una delega di un utente.
  • Logto Machine-to-Machine (Logto M2M): Un flusso standard di credenziali cliente OAuth, che richiede che un cliente sia registrato in precedenza, e richiede l'uso dell'ID cliente e del segreto per scambiare un token di accesso. Pertanto, la credenziale Logto M2M rappresenta un cliente fidato e la natura del flusso di credenziali cliente OAuth lo rende relativamente complicato quando viene utilizzato.

Somiglianze

1. Scopo dell'autenticazione

  • Tutti e tre, chiave API, PAT e Logto M2M, servono allo scopo principale di autenticare un utente o un'applicazione per accedere a un servizio o risorsa specifica. Agiscono come credenziali per dimostrare l'identità del richiedente e sono solitamente utilizzati in comandi CLI o scenari di comunicazione backend-to-backend.

2. Misure di sicurezza

  • Tutti e tre questi metodi di autenticazione devono essere gestiti con la sicurezza in mente. Gli sviluppatori devono garantire l'archiviazione e la trasmissione sicura per prevenire accessi non autorizzati.

Differenze

1. Contesto utente

  • La chiave API non identifica un principale, né fornisce alcuna informazione di autorizzazione. Pertanto, le chiavi API sono spesso utilizzate per accedere a dati o risorse pubbliche in modo anonimo. Tutti i servizi NON sono supportati dall'uso delle chiavi API.
  • PAT rappresenta identità utente e ti rappresenterà quando viene utilizzato per richiedere una risorsa API. In alcuni sistemi, i PAT non sono ammessi per accedere a determinati servizi. Ad esempio la pubblicazione di pacchetti NuGet sul feed Azure Artifacts.
  • Le credenziali Logto M2M possono essere utilizzate solo da clienti fidati. Il cliente deve essere registrato in precedenza per essere autenticato. Quando si usano le credenziali Logto M2M, rappresentano il cliente fidato invece dell'utente che lo sta utilizzando.

2. Granularità dei permessi

  • PAT e credenziali Logto M2M solitamente offrono un controllo più granulare sui permessi rispetto alla chiave API, consentendo un controllo fine su quali azioni possono essere eseguite.

3. Formato del token

  • Chiave API e PAT sono di solito tipi di stringhe opache, semplici e piane.
  • I token di accesso emessi tramite il meccanismo Logto M2M sono di solito in formato JWT.

4. Flusso di autorizzazione

  • Chiave API e PAT sono stringhe opache generate dal sistema, nessun flusso di autenticazione coinvolto durante il processo. Ad esempio, puoi chiamare l'API di linguaggio naturale di Google Cloud così:
  • Logto M2M utilizza lo standard OAuth 2.0 client credential flow. Ogni cliente deve ottenere una coppia di ID cliente e segreto del cliente in precedenza, con cui il cliente può poi scambiare un token di accesso. Il cliente quindi utilizza il token di accesso per accedere alla risorsa API.

Quando usare ciascuno

Chiave API

  • Comunicazione servizio-a-servizio: le chiavi API sono adatte per scenari in cui le applicazioni devono comunicare con le API direttamente tramite CLI. Ad esempio, chiamare le API di OpenAI.
  • API pubbliche: quando si espongono API al pubblico, le chiavi API forniscono un metodo di controllo dell'accesso diretto.
  • Configurazione semplificata: per esigenze di autenticazione rapide e semplici, specialmente nella fase di sviluppo. A differenza di Logto M2M, le chiavi API non richiedono registrazione del cliente in precedenza, e non devono scambiare per un token di accesso, nemmeno. Basta passare la tua chiave API come parametro nella tua richiesta e semplicemente funziona.

Token di Accesso Personale (PAT)

  • Azioni specifiche dell'utente: quando un'applicazione deve eseguire azioni per conto di un utente.
  • Controllo di accesso fine-grana (utente): quando è richiesto un controllo preciso delle azioni che un utente può eseguire.

Logto Machine-to-Machine (Logto M2M)

  • Sicurezza: Logto M2M è ideale per scenari in cui solo clienti fidati sono ammessi ad accedere ai servizi backend.
  • Controllo di accesso fine-grana (cliente): quando è richiesto un controllo preciso delle azioni che un'applicazione può eseguire.

Conclusione

In sintesi, la scelta tra chiavi API, PAT e Logto M2M dipende dai requisiti specifici della tua applicazione, che coinvolga azioni specifiche dell'utente, comunicazione macchina-a-macchina, o una combinazione di entrambi. Valuta le esigenze di sicurezza e funzionalità per determinare il metodo di autenticazione più appropriato per il tuo caso d'uso.

Il meccanismo Logto M2M consente agli utenti di impostare controlli di accesso granulari sulla funzione RBAC (Role-based Access Control). Stiamo anche pianificando di supportare chiave API e PAT nel prossimo futuro. Resta sintonizzato per i nostri aggiornamenti di funzionalità!