Architettura per OAuth2 - BackendServer - FrontendServer

Naviga le tue risposte
2

Sto sviluppando un intero ecosistema con un provider OAuth2, un server di backend e un server frontend.

  • Provider OAuth2: fornire solo l'autenticazione / l'autorizzazione per l'utente e alcuni altri servizi generici.
  • Server di backend: implementa tutta la logica e i modelli per un contesto specifico ed è un client OAuth2. È registrato sul provider e ha tutto il diritto di utilizzare le sue API.
  • Server frontend: esporre una GUI Web su Internet e ottenere tutti i dati dal server back-end.

A questo punto, il processo OAuth funziona correttamente e, dopo l'autorizzazione, il server Backend può ottenere dati utente dal provider.

Ma ho bisogno di mantenere la separazione dal frontend e dal backend e fornirò un servizio API RESTful accessibile solo dal frontend. Il mio problema è come farlo in modo corretto e sicuro.

Sto riscontrando qualche problema mentre sto cercando di rendere l'autenticazione dell'utente nel frontend utilizzando la sessione del provider OAuth e di fargli accedere ai suoi dati.

Questo è un requisito:

  • il frontend deve accedere ai dati utente OAuth2 tramite l'API back-end.
  • frontend e backend dovrebbero trovarsi su server diversi e potrebbero essere su host diversi.
  • in futuro introdurrò più server che utilizzano il servizio OAuth.

qual è la migliore architettura per questo bisogno?

AGGIORNAMENTO 12/10/2016

La parte HTTPS è chiara, la userò sicuramente.

Conosco il flusso di OAuth2, ma non sono sicuro che l'esempio soddisfi le mie esigenze. Ecco un flusso davvero semplice di un caso d'uso reale. Supponiamo che l'utente abbia già effettuato l'accesso e abbia già autorizzato il "Server back-end" (C). UnarichiestaaBnellapaginadelprofilohtml,BhabisognodirecuperareleinformazioniAdaCusandol'APIREST.CèilclientOAuthedeveessereautorizzatodaAperleggereisuoidati.QuindiCchiedeaD(ilproviderOAuth)leinformazionietuttiidativengonorestituitiaB,chegeneralapaginadelprofilohtml.

Ilmiograndedubbio(eilmotivodiquestadomanda)èilseguente:CèunserverRoRchecontrollaselasessioneconl'utenteautenticatoèattivaprimadigestirelarichiesta.Maquandolarichiestaprovienedaunservernonc'ènessunasessionesullarichiesta,eancheseBspostaleintestazionisuC,Crespondeconunerrore,perchépuòvederechelasessioneè"chiara".

Il mio dubbio è che mi manca il modo corretto di gestire le comunicazioni B-C.

    
posta RikyTres 05.12.2016 - 23:52
fonte

1 risposta

9

Innanzitutto, è necessario ** HTTPS **. 

HTTPS = HTTP + SSL/TLS.

Crea un livello di sicurezza sulla parte superiore del tuo HTTP e previene un sacco di attacchi. Perché quel livello funzioni è necessario trasmettere e ricevere credenziali sotto forma di certificato. vedi HTTPS

HTTPS può essere configurato in modalità unidirezionale o bidirezionale.

One-Way: nello scenario One-Way, solo si invia il certificato del server al client. Lo verificherà, e se è ok, inizierà subito la comunicazione.

Bidirezionale: succede dopo la sola andata, ma il client invia il suo certificato al tuo server in modo da avere la possibilità di verificarlo. Solo quando rispondi che ti fidi del certificato inizierà la comunicazione.

Questa è una configurazione che fai sui server. La tua applicazione / API utilizzerà HTTPS sul tuo server per inviare / ricevere informazioni.

Secondo, Ecco un flusso completo in OAuth2 con tutti i passaggi.

Nell'immaginesopra:

  • Utente:èl'host(utenteoserver)chetirichiedequalcosasultuoserverdelleapplicazioni.
  • Cliente:èunserverapplicazioniconnessoaltuoserverdiautenticazione.
  • Serverdiautenticazione:serversucuièinesecuzioneOAuthAuthenticationServer.
  • Serverdirisorse:èilserverAPIutilizzatoperaccederealleinformazionidell'utente.

Unavoltacompletatoilflusso,l'utentevieneautenticatoehauntoken.Per"utente" intendo utente in un'applicazione o an api .

L''utente' quindi usa il token in ogni richiesta fino allo scadere del token.

Nel tuo caso,

Il tuo Api di riposo riceverà il token, nell'intestazione Autorizzazione della richiesta HTTP collegamento rfc scpec sezione 14.8 autorizzazione . 

Authorization: Bearer mF_9.B5f-4.1JqM <- (token is here)

Quindi devi verificare il token nel tuo server OAuth per convalidarlo.

Questo sta accadendo sull'ultima richiesta tra Client e Server di risorse nella figura sopra. 

GET /resource(access_toke)
200: response <- (token is valid)

Se il token è valido, puoi concedere l'accesso alla risorsa richiesta. Se non si rifiuta la richiesta restituendo un codice di stato http di 401 (Non autorizzato) vedere discussione su stackOverflow .

Terzo, dovrai proteggere il tuo server dagli attacchi di replay.

vedi discussione su securityExchange .

    
risposta data 08.12.2016 - 15:45
fonte

Leggi altre domande sui tag

Quale di queste lingue è più facile da confezionare per altre lingue? Come mantenere le autorizzazioni degli utenti in un database?