Autorizzazione sull'applicazione OAuth2 che è sia client che server di risorse

2

Sto cercando di capire in che modo un'applicazione che utilizza il server OAuth2 (OIDC) implementa il controllo dell'accesso sulle proprie risorse.
In questo caso, l'applicazione è sia "Client" che "Server di risorse" in termini di OAuth2.

Quindi, l'utente, dal browser, accede all'applicazione e viene reindirizzato al server OIDC dove viene autenticato, dopo di che il server OIDC invia access_token e id_token al applicazione (non al browser dell'utente, supponiamo che l'applicazione sia client "riservato" in termini di OAuth2).
Suppongo che questo access_token possa essere rilasciato con diritti di accesso all'applicazione (che ora funge da "server di risorse"), che potrebbe essere usato per controllare l'accesso alle risorse dell'applicazione all'utente. Ma come potrebbe l'utente inviare questo access_token all'applicazione (agendo come un "server di risorse") poiché l'utente non è entrato in possesso di questo token (viene condiviso solo con l'applicazione)?

È possibile che questo access_token sia usato per creare una sorta di sessione di "accesso" tra il browser dell'utente e l'applicazione, in modo simile a come id_token è usato per costruire sessione di autenticazione sotto forma di cookie? Oppure, la sessione di autenticazione utilizzata per ottenere access_token dal server OIDC ogni volta che un utente accede a una risorsa diversa nell'applicazione, essendo l'utente inconsapevole di questa comunicazione poiché non viene richiesto il consenso?

O sto ricevendo tutto questo completamente sbagliato?

Il mio caso: supponiamo di avere una sola applicazione web che abbia backend e frontend, ma che il frontend NON sia implementato come una SPA (nel qual caso agirà come un "client"). Il token è ancora condiviso tra back-end e AS (non passa attraverso il browser). In che modo la mia applicazione controlla l'accesso alle sue risorse? Ad esempio, l'utente è in grado di vedere la home page, ma non un portale di amministrazione?

Per favore non basare le tue risposte sul mio caso d'uso concreto, prova a rispondere in generale.

    
posta Mike 26.07.2018 - 17:57
fonte

1 risposta

2

Credo che la tua applicazione abbia un'architettura simile a quella che ho mostrato nell'immagine sottostante,

L'applicazionehaunfront-endchevieneeseguitonelbrowserehaunback-end.Ilserverdiautorizzazioneèesternalizzato(fuoridailimitidell'applicazione).Quindilatuaapphaunback-endperrenderel'applicazioneunclientconfidenziale.L'accessoall'applicazioneavvienetramiteilflussoOIDC.Browserreindirizzal'utenteallapaginadilogindelserverdiautorizzazione.Forniscecredenziali,ilserverinviauncodicediautorizzazioneequestovienepassatoalback-endcheconsentealback-enddieffettuarelarichiestadeltoken.

Un'opzionechevedoquièdicreareunasessioneautenticatatrabrowsereserverdellerisorse.Laconnessioneverdenelmiodiagrammarappresentaquestasessione.L'autenticazionedellasessionesignificacheèobbligataadaccederealtoken.Iltimeoutdellasessioneèdefinitodallascadenzadeltokendiaccesso.Ciòrichiederàunpo'dilogicadalfrontendedalfinedelserverdellerisorse.

Un'altraopzioneèpassareiltokendiaccessoalfront-end.Conquesto,nonènecessariomantenereunasessione,mailfrontendrichiedediproteggereiltokendiaccessoeinviarloconognirichiestafattaalback-end.Quindilalineadiconnessioneverdeorarappresentalaconnessioneditrusttokenbearer(consulta RFC6750 per vedere il modo standard per trasmettere il token di accesso sulle intestazioni )

Per quanto riguarda i diritti di accesso (consensi), ciò dipenderà esclusivamente dal contesto dell'applicazione. Se vuoi che OIDC esternalizzi gli accessi degli utenti, le directory degli utenti e i meccanismi di autenticazione, allora non vedo il bisogno di preoccuparmi molto di questo. Cosa ti serve un token di accesso (e token ID).

    
risposta data 27.07.2018 - 07:38
fonte

Leggi altre domande sui tag