Chiavi API vs autenticazione HTTP vs OAuth in un'API RESTful


101

Sto lavorando alla creazione di un'API RESTful per una delle applicazioni che mantengo. Attualmente stiamo cercando di incorporare vari elementi che richiedono un accesso e una sicurezza più controllati. Durante la ricerca su come proteggere l'API, ho trovato alcune opinioni diverse su quale modulo utilizzare. Ho visto alcune risorse dire che HTTP-Auth è la strada da percorrere, mentre altri preferiscono le chiavi API e anche altri (comprese le domande che ho trovato qui su SO) giurano su OAuth.

Quindi, ovviamente, quelli che preferiscono, ad esempio, le chiavi API, affermano che OAuth è progettato per le applicazioni che ottengono l'accesso per conto di un utente (a quanto ho capito, come l'accesso a un sito non Facebook utilizzando il tuo account Facebook), e non per un utente che accede direttamente alle risorse su un sito a cui si è specificamente registrato (come il client Twitter ufficiale che accede ai server Twitter). Tuttavia, le raccomandazioni per OAuth sembrano essere anche per le esigenze di autenticazione più elementari.

La mia domanda, quindi, è: supponendo che sia tutto fatto tramite HTTPS, quali sono alcune delle differenze pratiche tra i tre? Quando uno dovrebbe essere considerato rispetto agli altri?


con cosa sei finito?
Irwin

@ Irwin - Ho posto questa domanda un po 'di tempo fa e da allora sono passato dal progetto che lo richiede, ma ho finito per utilizzare una combinazione di chiavi API e password generata (che gli utenti non vedono mai), che vengono inviate utilizzando l'autenticazione HTTP.
Shauna

Risposte:


67

Dipende dai tuoi bisogni. Hai bisogno:

  • Identità: chi afferma di fare una richiesta API?
  • Autenticazione: sono davvero chi dicono di essere?
  • Autorizzazione: possono fare ciò che stanno cercando di fare?

o tutti e tre?

Se devi solo identificare il chiamante per tenere traccia del volume o del numero di chiamate API, utilizza una semplice chiave API. Tieni presente che se l'utente a cui hai rilasciato la chiave API la condivide con qualcun altro, sarà in grado di chiamare anche la tua API.

Tuttavia, se è necessaria anche l'autorizzazione, è necessario fornire l'accesso solo a determinate risorse in base al chiamante dell'API, quindi utilizzare oAuth.

Ecco una buona descrizione: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/


con "determinate risorse" intendi "determinate chiamate API" o "determinati record di database", o entrambi?
Magne

Per lo più record DB (o qualsiasi cosa che riveli lo stato protetto o modifichi lo stato). Ma potrebbe anche essere qualcosa di simile a una funzionalità premium (come l'esecuzione di un algoritmo su un cloud) che non cambia nulla sul db ma utilizza le risorse di sistema e dovrebbe essere disponibile solo per le persone autorizzate.
Sid

@Sid sto lavorando a un'app che utilizza OAuth per registrare gli utenti che si registrano con Facebook o LinkedIn. Inoltre stiamo aprendo la nostra API per altri servizi per la gestione dei dati. In tal caso, consiglieresti OAuth per l'autenticazione dell'utente e una chiave API o una combinazione di nome utente e password (come nell'articolo a cui ti sei collegato) per i servizi che accedono all'API? OAuth e api key sono entrambe utilizzate per scopi diversi, giusto?
Tom Doe

@ TomDoe Ciao Tom - Sì, ha senso. Probabilmente vorrai usare OAuth2 adesso. Se il tuo server è in Python (Django o Flask) dai un'occhiata a github.com/omab/python-social-auth
Sid

Non capisco come una chiave API non possa fornire queste tre cose. Identità e autenticazione sono entrambe basate su "conosci un segreto particolare?" (a meno che tu non introduca 2FA, che è un argomento separato). Se fornisco la chiave API molto lunga dell'Utente 5, ciò afferma e dimostra che sono Utente 5, almeno così come farebbe un nome utente / password. E non c'è motivo per cui non si possano assegnare autorizzazioni diverse a chiavi API diverse. Destra? Cosa mi manca qui?
Nathan Long,

3

Le chiavi API o anche i token rientrano nella categoria dei meccanismi di autenticazione e autorizzazione diretti, poiché concedono l'accesso alle risorse esposte delle API REST. Tali meccanismi diretti possono essere utilizzati nei casi di utilizzo della delega.

Per ottenere l'accesso a una risorsa oa un insieme di risorse esposte dagli endpoint REST, è necessario controllare i privilegi del richiedente in base alla sua identità. Il primo passo del flusso di lavoro è quindi la verifica dell'identità mediante l' autenticazione della richiesta; Il passo successivo è il controllo dell'identità rispetto a un insieme di regole definite per autorizzare il livello di accesso (cioè lettura, scrittura o lettura / scrittura). Una volta completati i suddetti passaggi, un'ulteriore preoccupazione tipica è la velocità di richiesta consentita , ovvero quante richieste al secondo è consentito al richiedente di eseguire nei confronti delle risorse date.

OAuth (Open Authorization) è un protocollo standard per l' accesso delegato , spesso utilizzato dalle principali società Internet per concedere l'accesso senza fornire la password. Come è chiaro, OAuth è il protocollo che soddisfa le preoccupazioni sopra menzionate: autenticazione e autorizzazione fornendo un accesso delegato sicuro alle risorse del server per conto del proprietario della risorsa. Si basa sul meccanismo dei token di accesso che consente alla terza parte di accedere alla risorsa gestita dal server per conto del proprietario della risorsa. Ad esempio, ServiceX desidera accedere all'account Google di John Smith per conto di John, una volta che John ha autorizzato la delega; A ServiceX verrà quindi emesso un token basato sul tempo per accedere ai dettagli dell'account Google, molto probabilmente solo in lettura.

Il concetto di chiave API è molto simile al token OAuth descritto sopra. La differenza principale consiste nell'assenza di delega: l'Utente richiede direttamente la Chiave al fornitore del servizio per successive interazioni programmatiche. Anche il caso della chiave API è basato sul tempo: la chiave come token OAuth è soggetta a un leasing o periodo di scadenza. Come ulteriore aspetto, sia la chiave che il token possono essere soggetti a limitazione della velocità per contratto di servizio, ovvero può essere servito solo un determinato numero di richieste al secondo.

Per ricapitolare, in realtà non c'è una vera differenza tra i tradizionali meccanismi di autenticazione e autorizzazione e le versioni basate su chiave / token. Il paradigma è leggermente diverso però: invece di continuare a riutilizzare le credenziali ad ogni interazione tra client e server, viene utilizzato un Key / Token di supporto che rende l'esperienza di interazione complessiva più fluida e probabilmente più sicura (spesso, seguendo lo standard JWT , Chiavi e I token sono firmati digitalmente dal server per evitare la creazione).

  • Autenticazione e autorizzazione dirette : protocolli basati su chiave come variante delle versioni tradizionali basate su credenziali.
  • Autenticazione e autorizzazione delegate : come i protocolli basati su OAuth, che a loro volta utilizzano i token, ancora una volta come variante delle versioni basate sulle credenziali (l'obiettivo generale non è divulgare la password a terze parti).

Entrambe le categorie utilizzano un flusso di lavoro di verifica dell'identità tradizionale per la primissima interazione con il server che possiede le risorse interessate.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.