In che modo un'API dovrebbe utilizzare l'autenticazione di base http


17

Quando un'API richiede che un client esegua l'autenticazione, ho visto due diversi scenari utilizzati e mi chiedo quale caso dovrei usare per la mia situazione.

Esempio 1. Un'API viene offerta da una società per consentire a terzi di autenticarsi con un token e un segreto usando HTTP Basic.

Esempio 2. Un'API accetta un nome utente e una password tramite HTTP Basic per autenticare un utente finale. Generalmente ricevono un token per richieste future.

La mia configurazione: avrò un'API JSON che utilizzo come backend per un'app mobile e web. Sembra una buona pratica sia per l'app mobile che per quella Web inviare un token e un segreto in modo che solo queste due app possano accedere all'API bloccando qualsiasi altra terza parte.

Ma l'app mobile e web consente agli utenti di accedere e inviare post, visualizzare i loro dati, ecc. Quindi vorrei che accedessero anche tramite HTTP Basic su ogni richiesta.

Posso in qualche modo utilizzare una combinazione di entrambi questi metodi o inviare solo le credenziali dell'utente finale (nome utente e token) su ogni richiesta? Se invio solo le credenziali dell'utente finale, le memorizzo in un cookie sul client?


Si noti che i cookie non fanno parte del protocollo HTTP e sono semplicemente una funzionalità del browser comune. Quindi, se non stai implementando per il web, dimenticati di loro.
Yam Marcovic,

Se i cookie non sono consigliati, come / dove archiviate i crediti per passare all'API?
Paul Sylling,

I cookie sono solo un modo per gli utenti del browser di archiviare senza problemi i token di sessione. Se stai interagendo con uno sviluppatore, questo non deve essere perfetto. È possibile impostare un servizio di connessione pubblica che garantisca "ticket" e gli sviluppatori possono conservare i loro biglietti in memoria o dove desiderano. Si noti che non ho esperienza pratica di servizi Web e probabilmente ci sono soluzioni standard per questo tipo di cose.
Yam Marcovic,

Quali sono i tuoi pensieri da parte della mia domanda su auth user finale e api auth. Non ne sono ancora sicuro
Paul Sylling,

Risposte:


7

L'autenticazione di base HTTP richiede l'invio di nome utente e password ad ogni richiesta di risorse. Nome utente: la password viene passata nell'intestazione della richiesta "Autorizzazione" stringa codificata base64 con il prefisso "Base". Se tutte le tue comunicazioni http sono crittografate (tramite ssl), le informazioni dell'intestazione dell'autorizzazione non dovrebbero essere facilmente utilizzabili dagli aggressori poiché è improbabile che possano ottenerle.

HTTP con crittografia SSL con autenticazione di base dovrebbe essere sufficiente.


2
puoi fornire un esempio di questo? È quello di cui ho bisogno, proprio MOLTO bloccato in questo momento ...
Gander

0

OAuth / OpenID può funzionare insieme a token / secret?

Di recente ho contemplato il seguente scenario:

  • Front End dell'applicazione Web
  • API REST sottostante
  • Applicazioni per dispositivi mobili, accesso all'API REST

Come semplice test, sono stato in grado di:

  • Autenticare gli utenti tramite l'applicazione Web utilizzando OAuth
  • L'API REST è stata autorizzata tramite OAuth, generando un segreto che è stato generato e restituito al client
  • Il dispositivo mobile verrebbe quindi autenticato tramite OAuth e quindi autorizzato dall'API REST tramite il segreto

Ciò consentirebbe all'applicazione per dispositivi mobili di autenticarsi con le stesse credenziali del Web Front End (lo stesso account) e di autorizzare anche l'accesso all'API.


1
Quindi nel tuo esempio solo l'utente sta eseguendo l'autenticazione. I client in cui effettuano le chiamate all'API (app Web, app mobile) non stanno autenticando chi sono. Teoricamente, l'API è pubblica e qualsiasi applicazione potrebbe pubblicare un nome utente e una password e potenzialmente ottenere un token
Paul Sylling,

L'utente si sta autenticando tramite l'app e l'app sta effettuando le chiamate per conto dell'utente. Il processo di autenticazione deriva il token, che quindi l'app passa.
Brendan Green,
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.