I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio 1 2 3 4 5
E' un commento allo script #1288
BrightSoul
BrightSoul
il 26 settembre 2018 alle 16:25
11.886 messaggi dal 09 febbraio 2002
Contributi
Sì, puoi farlo autenticare sulla SPA. Dopo il login, reindirizza l'utente verso l'app MVC passando il token in querystring (o via post). L'app MVC lo recupera, lo verifica ed emette il cookie di autenticazione. Per poter fare la verifica deve essere in possesso della chiave segreta posseduta anche dalla web api.
Enjoy learning and just keep making
RispondiQuoting
teo prome
teo prome
il 26 settembre 2018 alle 19:48
710 messaggi dal 13 novembre 2008
Contributi
MVC lo recupera, lo verifica ed emette il cookie di autenticazione

bene si può fare! scusa lo stress, ma è proprio questo passaggio a livello di codice che non so bene come implementare.... supponiamo che imposto in startup della webapp il middlewear di auth con schema JWT e supponiamo che la chiave sia la stessa, come d'altronde già faccio allo stesso modo per l'altro client, la WebApi che fornisce dei dati ; al login faccio il redirect con il token verso una action di MVC, come avviene lì la verifica del token passato? eppoi se viene verificato emetto il cookie, per esempio creando un claimPrincipal con i dati dal token e facendo un signIn con lo schema 'cookies' ? ma allora devo impostare in startup anche uno schema di autenticazione con cookie? Grazie!
RispondiQuoting
teo prome
teo prome
il 27 settembre 2018 alle 12:43
710 messaggi dal 13 novembre 2008
Contributi
argghhh! forse ho capito qualcosa... non imposto in startup il middlewear JWT, ma nell'action recupero il token così:

          var validationParameters = new TokenValidationParameters
            {
                ValidateIssuer = true,
                ValidateAudience = true,
                ValidateIssuerSigningKey = true,
...ecc...
            };

            try
            {
                var claimsPrincipal = new JwtSecurityTokenHandler().ValidateToken(jwt, validationParameters, out var rawValidatedToken);


a questo punto posso restituire il Principal

Imposto quindi su startup il middlewear di auth con schema cookie, e faccio il signIn con quello schema...
Dovrebbe essere corretto giusto?
Per il cookie posso impostare una scadenza a scelta, o è meglio la stessa scadenza del token?
A cosa devo prestare attenzione a livello di sicurezza (prevenzione di vari attacchi)?
Eppoi in generale è consigliabile passare un token con i claim strettamente necessari ed eventualmente alla verifica dell'auth fare delle chiamate per recuperare altri dati utente?

ciao e grazie!
Modificato da teo prome il 27 settembre 2018 11.45 -
RispondiQuoting
BrightSoul
BrightSoul
il 27 settembre 2018 alle 20:54
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


Dovrebbe essere corretto giusto?

Sì, esatto.


Per il cookie posso impostare una scadenza a scelta, o è meglio la stessa scadenza del token?

A tua scelta, tanto se il token non è valido puoi invalidare prematuramente il cookie con await signManager.SignOutAsync();


A cosa devo prestare attenzione a livello di sicurezza (prevenzione di vari attacchi)?


Potresti tenere la chiave segreta al sicuro con Data Protection API e usando uno storage condiviso per le chiavi (es. una cartella condivisa in rete).
Ogni tanto puoi rinnovare la chiave automaticamente. Se hai il libro su ASP.NET Core 2 lo trovi a pagina 384.


Eppoi in generale è consigliabile passare un token con i claim strettamente necessari ed eventualmente alla verifica dell'auth fare delle chiamate per recuperare altri dati utente?

Metterei sicuramente quelli che ti servono ad autorizzare l'accesso alle action e poi, a tua discrezione, qualche altro claim tipo il nome dell'utente se lo devi visualizzare nel sito e il percorso alla sua immagine, se non puoi inferirla dal nome utente.

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
teo prome
teo prome
il 10 ottobre 2018 alle 11:29
710 messaggi dal 13 novembre 2008
Contributi
ciao,
chiedo alcune altre info approfittando della tua pazienza, poi ti offrirò una birra...
Il progetto attualmente implementato che ha come client l'app MVC di cui abbiamo parlato funziona

ora ho bisogno di implementare da zero un altro client, una SPADati

SPA di login --> credenziali --> WebApiAuth --> auth ok, emette accessToken --> SPA login --> direziona alla SPADati inviando accessToken (potrebbe essere come parametro o impostando un cookie, cosa è meglio, più sicuro, secondo te?) --> SPA Dati legge accessToken ....

la SPADati, in angular, legge l'accessToken e fa la prima chiamata ad una WebApiDati (che nello startup ha configurato l'auth con JWT e issuer audience chiave nel modo corretto); l'api chiamata è sotto [Authorize] quindi se l'accessToken è valido dovrebbe restituire i dati e la SPADati dovrebbe visualizzarli.

Supponiamo che l'accessToken sia valido per 20 minuti

Implementazione 1: fornisco solo una sorta di sliding expiration
ad ogni chiamata dalla SPADati verso la WebApiDati chiamo anche un'api di WebApiAuth che riceve il token vecchio e se ancora valido ne genera un altro e lo ripassa;
se così con la tua implementazione nell'articolo è facile farlo, ricavo un Principal dal token, lo metto in HttpContext.User poi il middlewear fa il resto, dovrebbe funzionare..?

Implementazione 2: refresh del token
qui dovrei fare in modo che l'utente dopo ogni azione rimanga loggato e anche che possa rimanere loggato per qualche giorno; da quel che ho capito ho bisogno di un refreshToken che abbia lunga durata...
questo caso è più complesso...
come posso implementare un flusso corretto?
il refreshToken potrebbe essere una stringa random abbastanza lunga o deve essere un Jwt?
quali altri dati conviene mettere e verificare nella tabella dei refreshTokens (pensavo ovviamente data fine, username, ...)?
c'è qualco'altro che devo considerare a livello di sicurezza?



Grazie mille!!!!
Modificato da teo prome il 16 ottobre 2018 12.01 -
RispondiQuoting
gianx10
gianx10
il 14 dicembre 2018 alle 13:51
19 messaggi dal 14 gennaio 2008
Ciao. Anzitutto complimenti per il bellissimo articolo. Avrei un paio di domande: posso come in Oauth avere anche un Refresh_Token oltre al Token? Se io espongo dei WS con questa tecnica, dopo 20 minuti mi scade il token, come fa il client a sapere se il token sta scadendo, non avendo di ritorno questo dato?
Grazie
RispondiQuoting
BrightSoul
BrightSoul
il 15 dicembre 2018 alle 19:41
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,

come fa il client a sapere se il token sta scadendo, non avendo di ritorno questo dato?

Non è necessario che il client sappia quando scade il token, infatti può disinteressarsene completamente. Semplicemente, quando fa una richiesta alla API invia il token di cui è in possesso. Se il token è ancora valido, il server emetterà un nuovo token con scadenza rinnovata nell'intestazione X-Token della risposta. Il client dovrà quindi leggerlo, salvarselo e buttar via quello precedente.
Se l'utente resta inattivo, il token scadrà e la successiva richiesta alla API produrrà un 401 Unauthorized. A questo punto il client dovrà mostrare la maschera di login all'utente.

Se proprio vuoi sapere quando scade il token, lo puoi leggere dal token stesso dato che è una stringa JSON codificata in base64. Quindi, lo spezzi secondo le istruzioni che trovi su jwt.io, lo decodifichi da base64 e leggi la sua proprietà "exp".

Se vuoi emettere token con durata più lunga, leggi quest'altro articolo.
http://www.aspitalia.com/script/1308/Invalidare-Token-JWT-Scadenza-ASP.NET-Core-Identity.aspx

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
FiliBen
FiliBen
il 20 novembre 2019 alle 12:22
27 messaggi dal 28 agosto 2019
Ciao,

avrei due domande :

1 ) le proprietà ValidIssuer e ValidAudience a cosa servono?
2) A ogni richiesta come faccio a capire se l'utente è validato? Se ne occupa il middleware nel ConfigureServices?

Ti ringrazio
Saluti
RispondiQuoting
1 2 3 4 5

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.