Implementazione dell'autenticazione del server di identità nello scenario del mondo reale

Question

Sto esaminando il modo in cui IdentityServer 3 funziona e ho ancora problemi a comprendere appieno.

In generale è chiaro per me, ma ancora non sono sicuro di come implementarlo sul progetto reale.

Questo è esempio di base che sto cercando di implementare nel mio caso: link

Ho progetto Web API e voglio chiamare i miei metodi di API da qualsiasi client (MVC, WPF, telefono ...) Così ho bisogno di implementazione adatta a tutti i clienti.

Se ho capito bene (e probabilmente io non sto a capire del tutto), dovrei avere 3 progetti:

• client
• Api
• progetto che ospitano IdentityServer

E tutto i progetti dovrebbero aver richiesto cose come in foto: Passi sull'immagine:

1. Diventa gettone
2. ritorno gettone
3. chiamata API
4. Controllare se provvisoria è OK
5. Se provvisoria va bene che i dati di ritorno altro spettacolo errore

Le mie domande sono:

• Il mio pensiero su come funziona s ok?
• Dove faccio errori?
• Questo esempio è abbastanza buono per il mio caso? Mi manca qualcosa importante ?
• Devo creare il progetto che ospita IdentityServer, o questo è necessario solo per esempio il codice?
• Il progetto host di IdentityServer deve essere un'applicazione console che comunica con API e client (come nell'esempio) o nel mondo reale ciò avviene in modo diverso?
• È necessario che il server di identità host sia a conoscenza dei client e degli utenti ?
• Eventuali altri progetti, ad eccezione del progetto di server di identità host, devono essere a conoscenza di client e utenti?
• Qual è la differenza tra flusso implicito e ibrido, cosa ho bisogno nel mio caso e perché?
• Come si crea la mia vista di accesso? Voglio avere una pagina html per l'accesso se uso il client web, ma per avere una vista di login wpf se uso wpf, anche una vista diversa per il client mobile.

EDIT: Penso che ho bisogno Resource Owner flow. Suppongo che risorsa visualizzo dove user user user name e password.

Answer 1

Il flusso di base è corretto, con Identity Server che funge da server di autorizzazione e il client e l'API Web separati.

È necessario ospitare Identity Server nel proprio progetto per assicurarsi che sia separato da qualsiasi altra logica potenzialmente in grado di introdurre problemi di sicurezza. Come lo ospiterai dipende da te e dal tuo caso d'uso. In genere lo vedresti ospitato all'interno di un progetto ASP.NET su un server IIS.

Identity Server deve essere a conoscenza dei client e degli utenti per poterli autenticare. Gli unici altri progetti che dovrebbero essere a conoscenza del tuo archivio identità (utenti) sono tutte le applicazioni che riguardano cose come admin, registrazione utente, ecc. L'archivio client verrà sempre utilizzato da Identity Server.

Le viste possono essere modificate utilizzando i modelli di Identity Server o introducendo il proprio ViewService. Vedere i documenti per maggiori informazioni: https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html

Per quanto riguarda i flussi, il flusso del proprietario risorse è solo OAuth, quindi non ci sarà autenticazione (pagina di accesso), solo autorizzazione (da server a server).