Quali sono i modi più comuni per progettare il processo di verifica dei token di accesso tra risorsa e server di autenticazione utilizzando OAUTH 2.0?

Question

Quali sono i modi più comuni per progettare il processo di verifica dei token di accesso tra risorsa e server di autenticazione utilizzando OAUTH 2.0?

#1 da (1 voti)

2

Sto provando a creare un'applicazione web suddivisa in un gruppo di micro servizi e ogni micro servizio è un server di risorse. Ho anche un server di autenticazione separato.

Mi chiedo quale dei seguenti approcci sia migliore o se pensi di avere un'idea migliore o ritieni che OAUTH non sia lo strumento giusto per questo.

Ecco i modi in cui ho provato:

Utente (proprietario della risorsa) accede alla pagina iniziale della mia app link
Questa pagina di destinazione ha un nome utente e un campo password, quindi una volta che l'utente ha inserito questi campi, effettuo una chiamata ajax al server di autenticazione che alla fine mi assegnerà un token di accesso dopo il FLUSSO DI OAUTH A DUE LEGGED.
Ora prendo il token di accesso oauth e vado al server delle risorse per accedere alla risorsa.
Il server delle risorse eseguirà ora un'altra chiamata http al server di autenticazione a livello di codice per verificare il token di accesso quando il server di autenticazione dice sì, quindi il server delle risorse servirà la richiesta verso il completamento (in questo modo il server delle risorse è completamente isolato con l'autenticazione processo)

L'altro modo sarebbe lasciare che il server delle risorse verifichi il token di accesso parlando al database condiviso.

Quale di questi è il più comune nel settore? Qualche altra idea su come verificare i token di accesso?

authentication oauth access-control web-application

posta user1870400 16.10.2015 - 22:29

fonte

1 risposta

Leggi altre domande sui tag authentication oauth access-control web-application

Il posizionamento di una macchina virtuale rinforzata in un VPS offre maggiore sicurezza? Tweaks relativi all'esecuzione di javascript nel browser

score 1 · Answer 1

OAuth2 è progettato per l'autorizzazione di client di terze parti ad accedere a risorse protette per conto del proprietario di tali risorse.

Non è progettato per l'autenticazione : ti accidi di utilizzare l'autenticazione a 2 vie nel tuo flusso, presumo tu intenda il credenziali del cliente flusso o Concessione di credenziali password del proprietario di risorse . Entrambi sono lo strumento sbagliato per il lavoro, e dal momento che hai già le credenziali dell'utente, non vedo perché non puoi autenticarli direttamente.
Non è per la comunicazione tra il fornitore di risorse e il server di autorizzazione : questo aspetto è volutamente fuori ambito nelle specifiche :

The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.

Questo sembra essere i due punti principali che stai cercando di risolvere, e nessuno si adatta al caso d'uso di OAuth.

Devi capire che l'obiettivo di OAuth è separare i ruoli del cliente e dell'utente. Questo non è il problema che stai cercando di risolvere.

Trova una buona conoscenza del problema che devi risolvere e utilizza gli strumenti giusti per ogni lavoro.

Per l'autenticazione è possibile utilizzare OpenID Connect, Kerberos, un servizio basato su SAML o configurare la propria autenticazione su un database con password hash pkbdf.

Per l'autorizzazione potrebbe esserci un posto per OAuth nella tua soluzione, ma potrebbero esserci altre opzioni che funzionano meglio su quell'ambiente. Non fissarti sullo strumento, concentrati sul problema in questione.