Progettazione di un'API con token di accesso, come gestire le richieste GET?

7

Sto costruendo un'API che utilizzerà i token di accesso in modo da poter monitorare l'utilizzo tra i vari dipartimenti e il controllo degli accessi. Il mio piano è di utilizzare i verbi HTTP in modo appropriato - GET recupererà le informazioni, POST aggiungerà, DELETE eliminerà, ecc.

La mia domanda è, come devo gestire i token di accesso sulle chiamate GET?

Opzione 1:

Fornisce il token di accesso come parte della stringa di query: /api/users/?token=ACCESSTOKEN . Il problema che ho con questo è che ACCESSTOKEN appare nei log del server. Questo metodo sarà diverso dalle richieste POST o DELETE che hanno il token passato tramite il corpo.

Opzione due:

Fornisci un corpo alla richiesta (come fai in una richiesta POST ) e uno dei parametri è il token. Il mio problema qui è che altri sviluppatori della mia azienda mi stanno dicendo che questa non è una "vera richiesta GET" perché sto passando dei dati. L'url che chiamano appare semplicemente come /api/users/ e fornisce token=ACCESSTOKEN nel corpo.

Opzione tre:

Elimina utilizzando GET e imponi che tutto sia un POST . Non mi piace questa idea perché per molte di queste chiamate API, non sto creando nuove risorse. Sto semplicemente restituendo dati che si trovano solo dietro un'API che richiede l'autorizzazione.

C'è un'opzione che mi manca o che dovrei affinare? Mi piace l'opzione 2, ma sono sensibile alle preoccupazioni degli altri sviluppatori del dipartimento.

    
posta NewGuy 19.10.2014 - 20:11
fonte

2 risposte

7

Opzione 4: intestazioni di autorizzazione e RFC 6750 (token bearer)

La soluzione che stai cercando è già stata specificata come parte dello standard OAuth2, ma sta da sola e sarà utile nel tuo scenario.

link

Tutte le richieste del client passeranno in un token al portatore (il token di accesso) e assomigliano a qualsiasi altra intestazione di richiesta al server. La richiesta stessa si presenta così:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Poiché si tratta di uno standard pubblico ampiamente implementato, non devi preoccuparti di definire un comportamento, basta puntare gli sviluppatori lato client su RFC. Potresti anche prendere in considerazione l'implementazione del resto dello standard OAuth2 sia come server di risorse sia come < em> server di autorizzazione , ma c'è molto più lavoro.

    
risposta data 20.10.2014 - 00:56
fonte
2

Perché non usi le intestazioni delle richieste? Questo separa i dati di autenticazione / autorizzazione dai dati reali significativi della richiesta e può essere utilizzato per qualsiasi tipo di richiesta (l'utilizzo di un corpo di richiesta su un get è in genere qualcosa che non dovresti fare).

Avere l'autorizzazione nelle intestazioni consente di autenticare l'utente prima di analizzare il corpo della richiesta, il che è vantaggioso quando non si desidera che il sistema sprechi tempo nell'analisi dei dati da un utente non autorizzato.

    
risposta data 19.10.2014 - 23:29
fonte

Leggi altre domande sui tag