Aangezien je (ASP).NET Core is het handig om Microsoft: Overview of ASP.NET Core Security door te nemen. Daar staat beschreven hoe je het kunt combineren met een SPA en hoe je external logins (zoals Google, Microsoft, Facebook, e.d.) toevoegt.:
[...]
Ja, angular heeft ook mijn voorkeur inderdaad, omdat ik dan het meest nieuw leer.
OAuth laat ik nu inloggen, door de gebruiker na een klik op de button, een popup te geven die via de server naar Google redirect. Dan log je in, waarna de server jouw oauth gegevens ontvangt. Op basis van die gegevens verstrek ik een jwt token aan de client, waarna de client daarbij kan blijven authenticeren
Api bouwen met .Net Core is heel erg gemakkelijk, het lastigste blijft de authenticatie. Dat moet gelijk goed gebeuren
/u/12668/hydra.png?f=community)
Nee, een refresh kan prima met je huidige token. Je wisselt dus je huidige token in voor een nieuw token.
Ik had in deze opzet geen JWT gebruikt voor een 'echte' productie service omdat mijn doel vooral is shit zo simpel mogelijk te houden. Maar je bent stagair dus jouw doel is vooral om zoveel mogelijk te leren. Dus ik zou het lekker met JWTs laten
https://niels.nu
Die security overview en de api authorization heb ik gebruikt inderdaad, echter is de pagina voor external logins uitsluitend gericht op MVC Core, zonder SPA dus. Dat is dan ook het lastigste stukje
Duidelijk. Bedankt voor je adviezen!:
[...]
Nee, een refresh kan prima met je huidige token. Je wisselt dus je huidige token in voor een nieuw token.
[...]
Ik had in deze opzet geen JWT gebruikt voor een 'echte' productie service omdat mijn doel vooral is shit zo simpel mogelijk te houden. Maar je bent stagair dus jouw doel is vooral om zoveel mogelijk te leren. Dus ik zou het lekker met JWTs laten
[ Voor 23% gewijzigd door Jantje2000 op 30-09-2019 16:11 ]
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
/u/715027/crop6047c50ae8d4c.png?f=community)
Zegt degeen die in eerste instantie Oath in de mond nam waarop ik reageer met dat ik me niet daarin vergis want ... en ik zie het gebruik van JWT in de volgende context. Ja, mijzelf zuidelijk maken is niet mijn sterkste punt, dat weet ik
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
@Jantje2000 @Hydra Het is mij gelukt om een Angular SPA te laten inloggen op een .NET Core API met simpelweg cookie authentication
Het .NET Core framework beheert dan de sessie voor mij. Ik moest met de volgende zaken rekening houden:
Het .NET Core framework beheert dan de sessie voor mij. Ik moest met de volgende zaken rekening houden:
- De Angular app doet zijn requests met de withCredentials optie. Authenticeren gaat gewoon door een POST te doen op een /api/auth/authenticate met credentials.
- Nadat ik de credentials heb gecontroleerd, laat ik het .NET Core framework een cookie maken door HttpContext.SignInAsync aan te roepen ( https://docs.microsoft.co...ookie?view=aspnetcore-3.0 ).
- In mijn Angular router module gebruik ik een guard die een GET request doet op /api/auth/check. Krijg ik een 401 terug, dan navigeer ik naar het LoginComponent:
code:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
@Injectable({ providedIn: 'root' }) export class AuthGuardService implements CanActivate { constructor(private backend: BackendService, private router: Router) { } canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean | UrlTree | Observable<boolean | UrlTree> | Promise<boolean | UrlTree> { return this.backend.authCheck().pipe( map(result => { if (result) return true; this.router.navigate(['/login']); }) ); } }
En de code in de BackendService:
code:1 2 3 4 5 6 7 8
authCheck(): Observable<boolean> { let url = `${this.backendUrl}/api/auth/check`; return this.http.get(url, { withCredentials: true }).pipe( map(data => true), catchError(err => of(false)) ); }
Hier zou ik nog wat meer error handling kunnen doen, dat ik echt naar een 401 kijk, zodat de sessie niet verbroken wordt door andere communicatiefouten. - Ik moest .NET Core wel even vertellen dat hij een 401 moet geven en niet moet proberen naar een eigen login pagina te redirecten.
code:1 2 3 4 5 6 7 8 9 10
services .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) .AddCookie(options => { options.Events.OnRedirectToLogin = (context) => { context.Response.StatusCode = 401; return Task.CompletedTask; }; }); - Uiteraard gaat alles via HTTPS.
- Ik moest de Cookie policy nog aanpassen, zodat de cookie HttpOnly, SameSite en ook Secure zijn:
code:1 2 3 4 5 6 7
var cookiePolicyOptions = new CookiePolicyOptions { MinimumSameSitePolicy = SameSiteMode.Strict, HttpOnly = HttpOnlyPolicy.Always, Secure = CookieSecurePolicy.SameAsRequest // Voor development }; app.UseCookiePolicy(cookiePolicyOptions); - ASP.NET Core versleutelt automatisch de cookie voor mij (ASP.NET Core Data Protection). Mocht ik in de toekomst ooit moeten load balancen, dan is het mogelijk om meerdere instanties dezelfde key ring te laten gebruiken, zodat alles blijft werken (al ga ik er niet vanuit dat dit ooit nodig is voor dit project).
- Schaalbaarheid is geen issue voor dit project. Het vervangt een oude management console die al 10 jaar lang op 1 server gehost werd. Het project wordt nieuw leven ingeblazen, maar zal naar alle waarschijnlijkheid zelfs minder users hebben dan de oude console ooit had (50 tot 100 geprojecteerd).
- Het is veel simpeler in te bouwen dan een JWT based auth met IdentityServer etc.
- Het is mogelijk een sessie te killen.
Ask yourself if you are happy and then you cease to be.
/u/122874/crop5e26d7a209cd1_cropped.png?f=community)
Cookie != Session:
@Jantje2000 @Hydra Het is mij gelukt om een Angular SPA te laten inloggen op een .NET Core API met simpelweg cookie authentication
Het .NET Core framework beheert dan de sessie voor mij. Ik moest met de volgende zaken rekening houden:Overwegingen om voor cookie auth te kiezen:
- De Angular app doet zijn requests met de withCredentials optie. Authenticeren gaat gewoon door een POST te doen op een /api/auth/authenticate met credentials.
- Nadat ik de credentials heb gecontroleerd, laat ik het .NET Core framework een cookie maken door HttpContext.SignInAsync aan te roepen ( https://docs.microsoft.co...ookie?view=aspnetcore-3.0 ).
- In mijn Angular router module gebruik ik een guard die een GET request doet op /api/auth/check. Krijg ik een 401 terug, dan navigeer ik naar het LoginComponent:
code:
@Injectable({ providedIn: 'root' }) export class AuthGuardService implements CanActivate { constructor(private backend: BackendService, private router: Router) { } canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean | UrlTree | Observable<boolean | UrlTree> | Promise<boolean | UrlTree> { return this.backend.authCheck().pipe( map(result => { if (result) return true; this.router.navigate(['/login']); }) ); } }
En de code in de BackendService:
code:
authCheck(): Observable<boolean> { let url = `${this.backendUrl}/api/auth/check`; return this.http.get(url, { withCredentials: true }).pipe( map(data => true), catchError(err => of(false)) ); }
Hier zou ik nog wat meer error handling kunnen doen, dat ik echt naar een 401 kijk, zodat de sessie niet verbroken wordt door andere communicatiefouten.- Ik moest .NET Core wel even vertellen dat hij een 401 moet geven en niet moet proberen naar een eigen login pagina te redirecten.
code:
services .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) .AddCookie(options => { options.Events.OnRedirectToLogin = (context) => { context.Response.StatusCode = 401; return Task.CompletedTask; }; });- Uiteraard gaat alles via HTTPS.
- Ik moest de Cookie policy nog aanpassen, zodat de cookie HttpOnly, SameSite en ook Secure zijn:
code:
var cookiePolicyOptions = new CookiePolicyOptions { MinimumSameSitePolicy = SameSiteMode.Strict, HttpOnly = HttpOnlyPolicy.Always, Secure = CookieSecurePolicy.SameAsRequest // Voor development }; app.UseCookiePolicy(cookiePolicyOptions);- ASP.NET Core versleutelt automatisch de cookie voor mij (ASP.NET Core Data Protection). Mocht ik in de toekomst ooit moeten load balancen, dan is het mogelijk om meerdere instanties dezelfde key ring te laten gebruiken, zodat alles blijft werken (al ga ik er niet vanuit dat dit ooit nodig is voor dit project).
Mochten jullie nog op- en aanmerkingen hebben, graag
- Schaalbaarheid is geen issue voor dit project. Het vervangt een oude management console die al 10 jaar lang op 1 server gehost werd. Het project wordt nieuw leven ingeblazen, maar zal naar alle waarschijnlijkheid zelfs minder users hebben dan de oude console ooit had (50 tot 100 geprojecteerd).
- Het is veel simpeler in te bouwen dan een JWT based auth met IdentityServer etc.
- Het is mogelijk een sessie te killen.
Hier staat nog wat meer op de MS site, mocht je ook Authorization willen toevoegen: https://docs.microsoft.co...ookie?view=aspnetcore-3.0. Die link had je al gevonden
Ook moet je wel de Session aan hebben staan en het Cookie laten verlopen anders heb je het zelfde als met JWT
Verder opletten dat je geen redirect doet na het uitloggen omdat dat anders niet werkt en denk wel aan CSRF
Ik neem aan dat je bedoelt dat ik de SessionMiddleware moet gebruiken en dat dit iets anders is dan een cookie? (dat 1 van de mogelijkheden is om als session identifier te gebruiken):
[...]
Cookie != Session
Ook moet je wel de Session aan hebben staan en het Cookie laten verlopen anders heb je het zelfde als met JWT
Verder opletten dat je geen redirect doet na het uitloggen omdat dat anders niet werkt en denk wel aan CSRF
code:
1
2
3
4
5
6
7
8
| services.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(10);
options.Cookie.HttpOnly = true;
options.Cookie.IsEssential = true;
});
app.UseSession(); |
Voor de rest gebruik ik de volgende AuthenticationProperties bij het aanmelden:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| var claimsIdentity = new ClaimsIdentity(logon.GetClaims(), CookieAuthenticationDefaults.AuthenticationScheme);
var authProperties = new AuthenticationProperties
{
AllowRefresh = true,
ExpiresUtc = DateTimeOffset.UtcNow.AddMinutes(10),
RedirectUri = null
};
HttpContext.SignInAsync(
CookieAuthenticationDefaults.AuthenticationScheme,
new ClaimsPrincipal(claimsIdentity),
authProperties);
} |
Het idee is dat authentication tickets na 10 minuten verlopen, maar omdat AllowRefresh aan staat, zou je een nieuwe moeten krijgen als je binnen die 10 minuten actief op de applicatie bent.
Wat CSRF betreft, zet ik de cookies met SameSite (Strict) en HttpOnly en ook Secure.
Ask yourself if you are happy and then you cease to be.
Netjes gemaakt! Ik blijf zelf gewoon JWT gebruiken (omdat ik lui ben en het er nu toch al best goed werkend in zit
), maar dit is inderdaad best een nette oplossing. Over het horizontale scalen, krijg je met zo'n cookie oplossing niet alsnog het probleem dat de sessie er op de ene server wel is en op de andere niet. Dus dat je dan met loadbalancing bij een uitlog de sessie van alle servers moet gaan laten verwijderen?
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
@Hydra @Jantje2000
Er is een probleem met de gekozen oplossing... althans daar lijkt het erg op momenteel. Op het moment dat de API op een ander domein staat dan de SPA, dan wordt de cookie gezien als een third party cookie en zullen veel moderne browsers weigeren de cookie op te slaan (in een poging privacy schendende tracking cookies tegen te gaan).
En dan werkt het dus simpelweg niet meer.
Tegen de JWT stroming inzwemmen heeft dus ook zo zijn nadelen als je met SPA's werkt en gewend bent een scheiding tussen SPA en API aan te brengen (ook qua deployment).
Plaats ik de API in hetzelfde domein, dan werkt het weer. Dus ik weet helaas vrij zeker dat het hieraan ligt.
Nu kan ik met een reverse proxy er wel voor zorgen dat de API altijd van hetzelfde domein lijkt te komen, maar dat maakt het qua deployment wel weer complexer.
Als jij Pietje bent en je hebt 10 users, dan kunnen die bij ons vaak inloggen op een eigen (sub)domein om het makkelijker voor ze te maken de URL te onthouden.
Wat zijn jullie gedachten hierover?
PS
Een andere oplossing zou zijn het inlogscherm volledig server side te doen met MVC. Dan navigeer je echt naar de URL toe. Maar ik vind dat eigenlijk niet zo mooi...
@Hydra
Hoe deploy jij SPA's die met sessions van een server side framework werken? Laat je de SPA dan ook hosten door de server side applicatie? (in het geval van .NET Core zou dat betekenen dat ik de SPA in de wwwroot map plaats bijvoorbeeld)
Er is een probleem met de gekozen oplossing... althans daar lijkt het erg op momenteel. Op het moment dat de API op een ander domein staat dan de SPA, dan wordt de cookie gezien als een third party cookie en zullen veel moderne browsers weigeren de cookie op te slaan (in een poging privacy schendende tracking cookies tegen te gaan).
En dan werkt het dus simpelweg niet meer.
Tegen de JWT stroming inzwemmen heeft dus ook zo zijn nadelen als je met SPA's werkt en gewend bent een scheiding tussen SPA en API aan te brengen (ook qua deployment).
Plaats ik de API in hetzelfde domein, dan werkt het weer. Dus ik weet helaas vrij zeker dat het hieraan ligt.
Nu kan ik met een reverse proxy er wel voor zorgen dat de API altijd van hetzelfde domein lijkt te komen, maar dat maakt het qua deployment wel weer complexer.
Als jij Pietje bent en je hebt 10 users, dan kunnen die bij ons vaak inloggen op een eigen (sub)domein om het makkelijker voor ze te maken de URL te onthouden.
Wat zijn jullie gedachten hierover?
PS
Een andere oplossing zou zijn het inlogscherm volledig server side te doen met MVC. Dan navigeer je echt naar de URL toe. Maar ik vind dat eigenlijk niet zo mooi...
@Hydra
Hoe deploy jij SPA's die met sessions van een server side framework werken? Laat je de SPA dan ook hosten door de server side applicatie? (in het geval van .NET Core zou dat betekenen dat ik de SPA in de wwwroot map plaats bijvoorbeeld)
[ Voor 32% gewijzigd door Lethalis op 02-10-2019 16:39 ]
Ask yourself if you are happy and then you cease to be.
Wil je de applicatie per se op een ander domein draaien? Misschien niet het alleernetsts, maar in .NET Core gebruik je in de start file:
@Hydra @Jantje2000
Er is een probleem met de gekozen oplossing... althans daar lijkt het erg op momenteel. Op het moment dat de API op een ander domein staat dan de SPA, dan wordt de cookie gezien als een third party cookie en zullen veel moderne browsers weigeren de cookie op te slaan (in een poging privacy schendende tracking cookies tegen te gaan).
En dan werkt het dus simpelweg niet meer.
Tegen de JWT stroming inzwemmen heeft dus ook zo zijn nadelen als je met SPA's werkt en gewend bent een scheiding tussen SPA en API aan te brengen (ook qua deployment).
Plaats ik de API in hetzelfde domein, dan werkt het weer. Dus ik weet helaas vrij zeker dat het hieraan ligt.
Nu kan ik met een reverse proxy er wel voor zorgen dat de API altijd van hetzelfde domein lijkt te komen, maar dat maakt het qua deployment wel weer complexer.
Als jij Pietje bent en je hebt 10 users, dan kunnen die bij ons vaak inloggen op een eigen (sub)domein om het makkelijker voor ze te maken de URL te onthouden.
Wat zijn jullie gedachten hierover?
PS
Een andere oplossing zou zijn het inlogscherm volledig server side te doen met MVC. Dan navigeer je echt naar de URL toe. Maar ik vind dat eigenlijk niet zo mooi...
code:
. In plaats daarvan maak je dan gebruik van 1
| services.addMvc() |
code:
(of zoiets, maar hier lijkt het wel op), waarna dat probleem zou moeten zijn opgelost.1
| services.addSpa() |
Dan krijg je in je project in plaats van een views folder een clientapp folder, waarin de Angular app komt te staan. Deze runt dan dus echt op hetzelfde domein.
Dan heb je echter geen compleet gescheiden front en backend meer, dus misschien verlies je dan voordelen die de redenen waren dat jij in dit project voor SPA hebt gekozen?
[ Voor 4% gewijzigd door Jantje2000 op 02-10-2019 16:38 ]
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
:strip_icc():strip_exif()/u/1260378/crop5d94b711b031f_cropped.jpeg?f=community)
@robbens De discussie MVC vs SPA is eigenlijk al voorbij als je dit topic helemaal doorleest Eigenlijk zou ik een nieuw topic aan moeten maken voor waar ik nu mee bezig ben: het managen van sessies in SPA's.
Waarbij de discussie vooral is: gebruik je gesignde tokens zoals JWT, of laat je de sessie managen door een server side framework dat bijvoorbeeld een versleutelde cookie genereert met een sessie id.
Op het moment dat je voor die laatste oplossing kiest, kun je dus ook met andere zaken te maken krijgen, zoals de herkomst van de cookie (het mag geen third party cookie zijn) of bepaalde aspecten bij horizontale schaalbaarheid (sessies bewaren in centrale store bijv).
Het oorspronkelijke argument om niet voor JWT te kiezen, is met name dat voor kleine projecten de voordelen van JWT nauwelijks opwegen tegen de nadelen ervan.
Anyways... ik ben een beetje een web dinosaurus die up to speed probeert te komen Meeste ervaring heb ik ooit met ASP.NET Web Forms opgedaan 
Daarna jaren lang alleen maar Windows applicaties geprogrammeerd, dus vergeef me enige naïviteit op dit front.
Ik heb wel met Angular aan bestaande projecten gewerkt, alleen ik kom er gaandeweg wel achter dat mijn collega's ook niet altijd de meest weloverwogen beslissingen hebben genomen (zoals JWT tokens genereren die uren lang geldig blijven, omdat het refreshen ervan "lastig" is).
Uiteraard ben ik weer degene die tot op de bodem alles wil uitzoeken en begrijpen, zodat ik geen shit aflever. Maar ook omdat ik mezelf geen slechte gewoontes wil aanleren.
Eigenlijk zou ik een nieuw topic aan moeten maken voor waar ik nu mee bezig ben: het managen van sessies in SPA's.Waarbij de discussie vooral is: gebruik je gesignde tokens zoals JWT, of laat je de sessie managen door een server side framework dat bijvoorbeeld een versleutelde cookie genereert met een sessie id.
Op het moment dat je voor die laatste oplossing kiest, kun je dus ook met andere zaken te maken krijgen, zoals de herkomst van de cookie (het mag geen third party cookie zijn) of bepaalde aspecten bij horizontale schaalbaarheid (sessies bewaren in centrale store bijv).
Het oorspronkelijke argument om niet voor JWT te kiezen, is met name dat voor kleine projecten de voordelen van JWT nauwelijks opwegen tegen de nadelen ervan.
Anyways... ik ben een beetje een web dinosaurus die up to speed probeert te komen
Meeste ervaring heb ik ooit met ASP.NET Web Forms opgedaan Daarna jaren lang alleen maar Windows applicaties geprogrammeerd, dus vergeef me enige naïviteit op dit front.Ik heb wel met Angular aan bestaande projecten gewerkt, alleen ik kom er gaandeweg wel achter dat mijn collega's ook niet altijd de meest weloverwogen beslissingen hebben genomen (zoals JWT tokens genereren die uren lang geldig blijven, omdat het refreshen ervan "lastig" is).
Uiteraard ben ik weer degene die tot op de bodem alles wil uitzoeken en begrijpen, zodat ik geen shit aflever. Maar ook omdat ik mezelf geen slechte gewoontes wil aanleren.
Ask yourself if you are happy and then you cease to be.
Overigens met een SPA kan je wel heel goedkoop alles in Azure hosten, Static website in Azure Storage, API in Azure Functions, "DB" in Azure Table Storage.
Kost geen drol en je kan maximaal schalen, kan natuurlijk ook een afweging zijn
Kost geen drol en je kan maximaal schalen, kan natuurlijk ook een afweging zijn
/u/454206/crop562d2ccb2479a.png?f=community)
Dan sla ik de plank mis met de verkeerde gereedschap.
Ik vind mijn oplossing _redelijkerwijs_ genoeg voor de applicatie die ik bouw. Bovendien staat half internet, inclusief sommige grote gewaardeerde websites, vol met dezelfde voorbeelden (zelfs als je de zoekfilter instelt op 2019). Het enige is dat ik uit eigen initiatief zelf extra controle checks heb ingebouwd zowel als bij React als in mijn PHP backend.
Ik vind jouw reactie dat ik de verkeerde tool voor de job gebruikt dan ook een beetje raar maar ik snap je wel. Niet iedere developer werkt hetzelfde
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!