Dove dovrebbe andare la logica di autorizzazione in un'applicazione basata su API?

Question

Dove dovrebbe andare la logica di autorizzazione in un'applicazione basata su API?

Naviga le tue risposte

#1 da (2 voti)

0

Ho una nuova applicazione basata su Rails api, in cui ho bisogno di implementare l'autorizzazione.

Architettura generale:

React frontend -> Rails API layer -> Rails model/server layer

Mentre esploro approcci diversi, ho una confusione.

Dovremmo inserire la logica di autorizzazione nel livello API o nel livello di servizio?
Approccio al livello dell'API: Creeremo un middleware di autorizzazione che si posizionerà tra il nostro livello front-end e API e tutte le nostre chiamate api verranno indirizzate al middleware di autorizzazione per verificare se l'utente è autorizzato a chiamare quel parituclar api.
Livello di servizio: tutto il controllo di autorizzazione passerà al livello di servizio e avremo il controllo prima di ogni operazione di db se l'utente è autorizzato a farlo. (Utilizzando cancancan / pundit ) e se l'utente non è autorizzato a inviare il messaggio di errore al livello API.

Sarebbe di grande aiuto, se qualcuno potesse suggerire in base alla loro esperienza.

api authentication authorization rails

posta Deepak Kumar Padhy 07.06.2017 - 05:36

fonte

1 risposta

Leggi altre domande sui tag api authentication authorization rails

Selezione del codice cloudflare basata sul supporto AES-NI Protocollo fuzzing di un'applicazione java

score 2 · Answer 1

Ovviamente l'autorizzazione deve essere verificata sul lato server, poiché basarsi esclusivamente sui controlli dei client consente di accedere a client dannosi. Non c'è un consenso generale su dove nel codice lato server dovresti fare questi controlli, ma cercherò di essere il più vicino possibile al limite.

Per uno, questo è spesso il più semplice. Hai accesso immediato ai dati della chiamata e puoi restituire direttamente il messaggio di errore appropriato invece di fare affidamento su un'eccezione che esplode attraverso diversi livelli.

In secondo luogo, l'autorizzazione è spesso più complessa di quanto si possa anticipare. Ad esempio, prendi GitHub: per eseguire determinate azioni sensibili, devi prima reinserire la tua password. Questo tipo di controllo tende ad essere molto più facile da gestire su base pagina per pagina, piuttosto che costruire condizionali complessi nel livello del modello.

Da un punto di vista della sicurezza, c'è sicuramente un argomento da fare per un approccio di autorizzazione profondo, ovvero che non ti affidi agli sviluppatori che ricordano di gestire l'autorizzazione in ogni nuovo endpoint. Tuttavia, la mia opinione è che la chiarezza e la semplicità ottenute da un approccio basato sui margini superano questi vantaggi.