Le specifiche OAuth 2 mi portano a credere che il "server delle risorse" e il "server delle autorizzazioni" non debbano necessariamente essere la stessa applicazione, ma sto cercando di capire come è effettivamente implementato nella pratica.OAuth 2: separazione del server delle risorse e del server delle autorizzazioni
Per fare un esempio, supponiamo che esistono le seguenti applicazioni:
- server di risorsa
- server di autorizzazione
- web frontend
- di terze parti client App
Scenario # 1: Accesso al frontend web
- utente invia form di login
- web app Messaggi credenziali per Auth del server (grant_type = password) e riceve un access_token
- i negozi web app del access_token in una sessione
- ad ogni successiva richiesta:
- OTTENERE risorse dal server delle risorse (w/access_token nell'intestazione Autorizzazione) e renderlo nel frontend Web
- se si ottiene un 401 quindi disconnettere l'utente (rimuovere access_token dalla sessione)
Scenario # 2: L'app di terze parti
- le richieste degli utenti l'autorizzazione dal servizio di autenticazione
- permettere/negare modulo viene visualizzato
- utente viene reindirizzato al client app con l'autorizzazione codice presente
- client app codice POST al servizio auth (grant_type = codice_autorizzazione) e riceve un token_accesso
- cliente riceve risorse dal server di risorse che passa (w/intestazione Auth)
La parte che mi riesco a capire è come autenticare l'utente prima di mostrare il modulo di consentire/negare in 2 Scenario n. L'utente può essere connesso all'app Web principale ma il servizio di autenticazione non ne ha idea e in qualche modo ha bisogno di autenticare nuovamente l'utente. Anche il servizio auth deve supportare login/sessioni?
Mi chiedo se potrebbe avere più senso per il web app di essere responsabile per mostrare la forma consentire/negare per due motivi:
- mantiene tutto l'interfaccia utente in una singola applicazione
- non costringerebbe l'utente a ripresentare le proprie credenziali se sono già effettuato l'accesso al web app
Ecco una possibile alternativa allo scenario # 2:
- richieste degli utenti l'autorizzazione dal web app
- permettere/negare modulo viene visualizzato
- POST Web App per Auth server di creazione di una nuova borsa di studio, codice di autorizzazione viene restituito
- web app reindirizza al cliente app con codice di autorizzazione presente
- cliente codice POST app per il servizio di autenticazione e riceve access_token
Qual è il modo migliore per gestire questa situazione? Qualsiasi commento generale, consiglio, ecc. Sarebbe fantastico!
Grazie
Grazie! Questo è un approccio interessante. Ancora incerto se vale la complessità aggiunta. – scttnlsn
Sì, c'è una domanda lì: se hai molte diverse app Web che utilizzano lo stesso back-end di autenticazione (come Google), è probabile che tu voglia un server di autenticazione dedicato con tutte le schermate di login associate. Per una singola app probabilmente non ne vale la pena. – Femi
Il tipo di concessione password deve essere utilizzato solo per le applicazioni di proprietà e controllate dall'entità proprietaria del servizio di autorizzazione. Altrimenti apre gravi buchi di sicurezza. Un utente deve solo fornire le proprie credenziali all'applicazione che le ha emesse. – user2268788