Protezione di Java REST Api per il caso d'uso di Saas

0

Sto costruendo un'API Java RESTFul con Jersey2. L'API verrà utilizzata dagli sviluppatori. Gli sviluppatori dovrebbero avere accesso agli endpoint tramite un access_token (preferibilmente non in scadenza).

Ho dato un'occhiata a Kong e ad altre implementazioni di oauth2 ma ho la sensazione che questo potrebbe essere sopraffatto.

Quindi penso che un'autenticazione RBA basata su token dovrebbe andare bene per l'inizio. Il problema è che questo approccio si basa sulle date di scadenza dei token. Ma come ho detto - questo non è quello che voglio. Quindi è ok avere token senza scadenza?

Inoltre - cosa ne pensi? Oauth2 è essenziale per il mio caso? E quanto sarebbe difficile continuare a migrare da un semplice concetto di sicurezza (RBAC con token di accesso) a Oauth2?

    
posta Fabian Lurz 19.11.2015 - 11:00
fonte

1 risposta

1

Inizierò rispondendo con altre due domande:

  • Se sviluppi la tua soluzione, quanto tempo ti ci vuole?
  • Se la tua API è di pubblico dominio, quanto velocemente il tuo sviluppatore può comprendere un meccanismo di autorizzazione non standard?

OAuth 2.0 ha il vantaggio di essere molto popolare, quindi puoi aspettarti che i tuoi clienti (sviluppatori) lo sappiano già. Non è necessario documentare tutti i dettagli del gore, puoi semplicemente indirizzare i principianti alle specifiche e ai tutorial esistenti.

Inoltre, se stai utilizzando Java, distribuisci il tuo server di autorizzazione con Spring Security + Spring Boot o Spring Cloud sarà questione di giorni, anche se inizi da zero. Anche la protezione dei server delle risorse (API HTTP) con Spring Security è facile.

Da un punto di vista molto pragmatico, OAuth 2.0 è meno efficace della creazione della propria soluzione.

    
risposta data 27.11.2015 - 10:08
fonte

Leggi altre domande sui tag