L'identità di ASP.NET è disponibile in due versioni:
- Puoi utilizzare il tuo codice di accesso, che diventerà essenzialmente un 'IDP privato' per te.
- Usi IDP esterni (Facebook, Twitter, LinkedIn, ecc. .) tramite ASP.NET Identity, che gestirà tutta la complessità.
Non sono sicuro quale opzione sia "nulla per la produzione" secondo te. Se riesci a spiegare le preoccupazioni, la risposta qui può essere migliore.
Anche quando si utilizzano IDP esterni, ASP.NET Identity può / crea un database con l'utente in modo che l'applicazione possa memorizzare ulteriori attributi.
In ogni caso, gli utenti 100K + con 30-50 attributi sembrano qualcosa che un singolo server dovrebbe essere in grado di gestire facilmente (con o senza identità ASP.NET).
IDP personalizzati
Il problema generale con gli IDP personalizzati è che è necessario un ingegnere (o una squadra) dedicato per garantire che tutto sia a posto.
- C'è un costo per l'implementazione iniziale, esp. assicurando che tutti i requisiti di sicurezza siano soddisfatti.
- Sono previsti costi di supporto associati a password dimenticate, account compromessi, ecc.
- Sono necessari miglioramenti tecnici per le nuove funzionalità (autenticazione a due fattori, SMS, e-mail, quindi qualcos'altro), miglioramenti della sicurezza (ad esempio un algoritmo crittografico considerato improvvisamente vulnerabile) e problemi di produzione.
- Se il sistema viene compromesso o mostrato debole da qualcun altro, si tratta di un problema significativo di pubbliche relazioni per l'azienda.
Uso di IDP esterni
Puoi ottenerlo utilizzando diverse tecnologie o provider: Identità ASP.NET , Servizio di controllo degli accessi di Azure , OpenID , Auth0 per citarne alcuni. Tutto ciò fornirà un'unica interfaccia per la tua applicazione, oppure puoi scrivere direttamente su Google, Facebook, Twitter, Account Microsoft.
Una volta che un utente effettua l'accesso, indipendentemente dal servizio che utilizzi, ti fornirà le attestazioni che puoi utilizzare nella tua applicazione per trovare l'indirizzo email, il nome, il cognome, ecc. di un utente.
- Il vantaggio dell'utilizzo di un servizio unificante (come Access Control Service) è che utilizzerà un solo protocollo e invierà token in un formato token fisso indipendentemente da ciò che è stato usato per l'autenticazione, e quindi l'applicazione deve comunicare usando solo un'interfaccia
- Se gli IDP esterni vengono utilizzati direttamente (ad es. Google, Facebook, Twitter, ecc.) l'applicazione deve analizzare e comprendere ciascun token, che può variare nelle attestazioni in essi contenute per lo stesso attributo utente (ad esempio un token potrebbe avere first_name, un altro potrebbe aver dato Name, ecc.)
- L'applicazione potrebbe anche dover gestire più protocolli (come OAUTH, SAML) a meno che non sia limitato a un singolo protocollo, che sarebbe OAUTH per la maggior parte degli IDP social, inclusi account Microsoft, Facebook, Google, Twitter, LinkedIn, ecc. .
Effetto sulla struttura dell'API
L'autenticazione non dovrebbe influire sull'API rivolta al pubblico generata da un'app. Di fatto, l'autenticazione viene gestita nel modo in cui è oggi (ovvero tramite gli IDP), quindi può essere scollegata dall'applicazione effettiva, che può variare indipendentemente da come gli utenti si autenticano.