Progettazione API - Gestione utenti

Innanzitutto, voglio chiarire che concettualmente non è l'applicazione client che richiede il token per sé stesso: è l'utente che richiede il token per se stesso e l'applicazione la gestisce solo.

Quindi, ad esempio, se si dispone di un'applicazione Web come client, il codice JavaScript si prenderà cura di ottenere le credenziali del client da un modulo di accesso, passandole all'API, ricevendo un token da esso e salvandolo. nei cookie o in altro tipo di archiviazione locale. Ma quel token avrà l'identità dell'utente scritto in esso, e apparterrà a quell'utente, non all'applicazione. Il fatto che altri 1000 utenti accedano contemporaneamente non ha importanza: ognuno di essi riceve un diverso token in base alle proprie credenziali e lo conserva nel proprio browser.

Quindi il tuo flusso di autenticazione sarebbe simile a questo:

• l'utente digita i propri login e password nel sito Web e fa clic su "Invia"
• il codice JavaScript in esecuzione nel browser li preleva e invia una richiesta POST a / login
• l'API restituisce un token per tali credenziali (o qualche tipo di errore se l'autenticazione fallisce)
• il codice JavaScript salva quel token in una variabile globale
• quando si richiede GET / users / 1 / orders, il codice JavaScript prende lo stesso token, lo inserisce nell'intestazione della richiesta e lo invia all'API
• l'API controlla il token per vedere quale utente lo possiede e restituisce i dati o un errore

Le cose diventano un po 'più complicate se non si utilizza JavaScript per interrogare l'API direttamente dal client, ma si tratta ad es. un'applicazione WebForms legacy che ha bisogno dei dati per elaborarla e visualizzare la vista. In questo caso hai due opzioni:

• condividi una chiave segreta tra l'applicazione WebForms e l'API e l'API accetta incondizionatamente tutte le richieste con quella chiave segreta. Il presupposto è che tu come utente hai già effettuato l'accesso all'app WebForms, quindi ora è responsabilità dell'app quella di non farti vedere i dati che non ti è permesso vedere
• far sì che l'applicazione WebForms agisca essenzialmente come l'applicazione JS precedente, inoltrando il token tuo all'API. Potrebbe essere semplice come copiare le intestazioni di autenticazione dalla tua richiesta e includerla nella richiesta all'API, oppure richiedere all'applicazione di autenticare l'API per tuo conto e conservare quel token in memoria sotto il tuo nome.

Inoltre, nella tua domanda tu menzioni JWT come una possibile soluzione - personalmente penso che sia un po 'eccessivo. Il vantaggio principale di JWT è di abilitare un servizio completamente separato per gestire l'autenticazione e l'autorizzazione e che la tua API convalidi che il token (che è solo un nome utente, un insieme di permessi e una firma) è stato effettivamente rilasciato da quel servizio.

Nel tuo caso questo sembra non necessario - non è necessario verificare la tua firma, puoi semplicemente ricordare che cosa hai firmato. Per questo, una semplice stringa casuale memorizzata nel database, associata all'utente e alle sue autorizzazioni e invalidata al logout dovrebbe funzionare perfettamente.

Inoltre, uno schema comune per le API disponibili pubblicamente consiste nel consentire agli utenti di creare chiavi API persistenti e gestirle, ad esempio, se scrivessi un bot per il monitoraggio degli ordini, potrei creare una chiave separata dal token che normalmente ottengo quando utilizzando l'applicazione web, assegna solo l'autorizzazione per leggere gli ordini e impostarla per non scadere mai. Quindi posso semplicemente effettuare richieste con quella chiave senza passare per l'endpoint di accesso, semplicemente salvandola nel file di configurazione per il mio bot.

How would authentication work for example, for an endpoint like /users/1/orders. The JWT token would handle actual access to the API (for the consumers, such as an app or third-party) but how do we make sure the actual end user has authenticated?

Perché l'utente finale ha dovuto passare attraverso un processo di autenticazione . Tale processo, tra le altre cose, ha dato un nuovo JWT al client (utente). Il token è la prova di cui hai bisogno. Fondamentalmente, perché ti fidi di ciò che ha emesso quel token. Di solito, è la tua API che lo fa. E anche chi lo controlla più tardi.

Pensa ai token come biglietti del cinema. Quando vai al cinema, acquisti un biglietto e in seguito il biglietto viene controllato prima di andare in sala. Il ticket (JWT) è la tua prova, è ciò che ti consente di accedere. Naturalmente, in questo esempio, la tua "autenticazione" non era un utente / password, era più simile a una carta di credito o denaro.

How should that information be passed into the main API?

Se usiamo HTTP come protocollo di comunicazione, è conveniente inviare JWT come intestazione HTTP. Più precisamente

Authorization: Bearer my_jwt_token_here

L'intestazione deve essere inviata in ogni singola richiesta che potrebbe richiedere autenticazione e / o identificazione .

Would there be a 'login' endpoint that takes the username/pass in plain text?

Lì sarà un endpoint che prende le credenziali in un formato. Possono essere utente / pass, email / pass, qualsiasi cosa tu abbia bisogno. Il formato può essere testo semplice, JSON, XML, ... Qualunque cosa ti serva.

Would there be another token at this point to determine the user who has authenticated?

Potrebbero esserci diversi token. Tante le esigenze della tua API. Di solito, JWT contiene tutte le informazioni (richieste) richieste per identificazione e autorizzazione . Ciò rende sufficiente una JWT.

I don't understand how you track the fact the end user has logged in, giving the API consumer access to their 'orders' endpoint, for example.

Perché in ogni richiesta invia un JWT valido