33 messaggi dal 10 maggio 2015
Ciao a tutti,
sto progettando un'applicazione Angular5 che si appoggia sulle WebApi; in questi giorni, stiamo decidendo quale tipo di autenticazione inserire nel progetto.

Nelle applicazioni MVC5 utilizziamo Asp.Net identity, con autenticazione basata su cookie; non credo però che il cookie sia la miglior soluzione per applicazioni basate su WebApi.

Stavo allora pensando ad OAuth2 con bearer token, tipologia di autenticazione che solitamente integriamo nelle applicazioni che espongono servizi all'esterno. Nel caso di un'applicazione con servizi "chiusi", tipo quella che sto progettando, mi chiedevo però se OAuth2 fosse la soluzione migliore; nello specifico, mi stavo chiedendo dove memorizzare le informazioni dell'utente autenticato (token, nome, cognome, ecc..). In rete molti forniscono esempi appoggiandosi sulla local storage del client, ma non mi sembra il posto più sicuro in cui memorizzare informazioni di questo tipo.

Volevo quindi confrontarmi con qualcuno della community per trovare la soluzione più consona.
Grazie in anticipo e buon lavoro.
11.097 messaggi dal 09 febbraio 2002
Contributi
Ciao,


Nelle applicazioni MVC5 utilizziamo Asp.Net identity, con autenticazione basata su cookie; non credo però che il cookie sia la miglior soluzione per applicazioni basate su WebApi.

Il cookie non è la migliore soluzione quando hai dei client non-browser che consumano la tua webapi da altro tipo di applicazioni (es. console, desktop, dispositivo IoT, ecc...). In questi casi il cookie è scomodo da usare perché il client deve comprenderne la struttura: il server infatti non invia solo il contenuto del cookie, ma anche alcune informazioni accessorie sul suo utilizzo (es. la scandeza, per quale percorso è stato emesso, se è HttpOnly, e così via). Queste informazioni devono essere rimosse in modo che il client reinvii al server solo il contenuto del cookie nella successiva richiesta.

Tuttavia, se la tua WebAPI è ad unico uso e consumo di un frontend Angular, allora puoi anche usare un cookie perché tutto il lavoro di interpretazione e mantenimento del cookie lo fa il browser automaticamente. Nulla ti vieterebbe di aggiungere un secondo meccanismo di autenticazione in seguito.


Stavo allora pensando ad OAuth2 con bearer token

Come mai OAuth2? Hai detto che l'autenticazione la fai su ASP.NET Identity, probabilmente con utenti locali alla stessa applicazione WebAPI. Dato che non hai un authorization server esterno all'applicazione WebAPI, potresti usare dei JWT Token.
Al login dell'utente, crea un JWT Token in cui inserisci la sua ClaimsIdentity che poi verrà cifrata da ASP.NET e inviata al client. Lato client, puoi raccogliere il JWT Token dalla risposta della login e salvarne il contenuto nel local storage o, se il browser non lo supporta, in un cookie.
Reinvia il JWT Token ad ogni richiesta, nell'instazione Authorization: Bearer ....

Qui c'è un esempio su come configurare ASP.NET Web API per usare token JWT.
http://blogs.quovantis.com/json-web-token-jwt-with-web-api/
Qui c'è una mia demo
https://github.com/BrightSoul/DemoLoginWebAPI

Questo è per ASP.NET Core e ASP.NET Identity
https://blogs.msdn.microsoft.com/webdev/2017/04/06/jwt-validation-and-authorization-in-asp-net-core/

ciao,
Moreno

Enjoy learning and just keep making
33 messaggi dal 10 maggio 2015
Ciao Moreno,
ti ringrazio per la risposta. In effetti le mie WebApi, per ora, verranno consumate solo da un client Angular, quindi potrei proseguire con l'autenticazione tramite cookie.

Per quanto riguarda OAuth2, l'avevo preso in considerazione proprio come possibile alternativa alle identity tramite cookie, ma direi che per il momento non mi serve.

I JWT non li ho mai utilizzati, guarderò certamente con molto interesse i link che mi hai segnalato.

Grazie ancora per la disponibilità e buon weekend.
11.097 messaggi dal 09 febbraio 2002
Contributi
Qui ho messo una demo di autenticazione con JWT Token:
https://github.com/BrightSoul/AspNetCoreWebApiJwtTokenDemo

Non usa angular ma serve solo a dimostrare il principio di creazione e reinvio di token JWT short-lived (cioè a scadenza molto breve). La scadenza del token può ovviamente essere modificata secondo necessità.

ciao,
Moreno

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.