OAuth 2.0 ok per costruire un contenitore di applicazioni?

Question

OAuth 2.0 ok per costruire un contenitore di applicazioni?

#1 da (1 voti)

7

Ho bisogno di creare un'app contenitore che contenga diverse app (immagina qualcosa come iCloud): una volta effettuato l'accesso, posso visualizzare tutte le app tramite icone, fare clic su di esse e usarle (una nuova scheda / la pagina è aperta e non è richiesto il login).

L'app contenitore, così come le altre app, avrà una cartella dedicata sul server e sarà progettata per essere app front-end con il proprio back-end. Ogni back-end è dedicato alla singola app, ma tutti i back-end possono accedere alle API del server e / o al DB senza alcun problema (risiederanno sullo stesso server, al massimo su server virtuali diversi con porte differenti).

Vorrei consentire all'utente di effettuare l'accesso una sola volta (app contenitore) e quindi lasciarlo / a utilizzare l'app senza eseguire nuovamente l'accesso. Per farlo, stavo pensando a un token condiviso che ogni app front-end invierà ai loro rispettivi back-end. I back end controlleranno il token. Non voglio reinventare la ruota, quindi mi chiedevo se oauth potesse essere utile in qualche modo per raggiungere il mio obiettivo.

oauth oauth2

posta Bertuz 18.03.2016 - 17:00

fonte

1 risposta

Leggi altre domande sui tag oauth oauth2

Assicurarsi che la registrazione e l'attivazione dei callback non causino una ricorsione infinita Come minimizzare gli errori di digitazione durante la codifica? [chiuso]

score 1 · Answer 1

Un'opzione sarebbe quella di ospitare tutte le applicazioni in un singolo dominio e fare in modo che l'app di login scriva un cookie letto da ciascuna delle altre app. Se hai davvero bisogno di ospitare applicazioni su domini diversi allora questo non funzionerà per te (dato che non puoi leggere un cookie da un dominio diverso), tuttavia se puoi allora questo approccio ti farà risparmiare un lotto di mal di testa.

In alternativa puoi usare OpenID Connect . OpenID Connect è un'estensione di OAuth2 che specifica come devono essere rappresentate le informazioni relative a identità / utente. In questo caso potrebbe funzionare un po 'in questo modo:

Una delle tue app è un "OpenID Provider" (OP), che gestisce l'accesso agli utenti come è un OpenID Connect
Una o più altre app sono "Relying Parties" (RP), che dipendono dal provider OpenID per registrare gli utenti in
Quando un utente visita un'app e non è collegato a quell'app, reindirizza l'utente al provider OpenID utilizzando uno dei flussi supportati (ad es. Implicito). Il provider quindi autentica l'utente (ad esempio tramite nome utente / password) e memorizza un cookie per tracciare la sessione dell'utente.
Il provider OpenID reindirizza quindi l'utente all'app, che convalida il token ID fornito e memorizza anche un cookie
Se l'utente visita un'altra applicazione e non è connesso, quell'applicazione reindirizza l'utente al provider OpenID come prima, tuttavia questa volta il cookie memorizzato dal provider OpenID significa che l'utente non ha bisogno di autenticarsi di nuovo, e l'utente viene reindirizzato direttamente all'app con un altro id_token

In questo modo più applicazioni possono sapere chi è l'utente attualmente autenticato senza richiedere che l'utente effettui il login più volte.

Tutto questo è stato fatto usando OAuth2 (OpenID Connect è un'estensione di OAuth2) - Raccomando l'uso di OpenID Connect (al contrario del rollover della propria soluzione basata su OAuth2) poiché definisce un modo standard di gestire questo tipo di scenari, come beh ha come gestire cose come Gestione delle sessioni ed effettuare il logout.