I had heard that the problem with doing authentication (and authorization) client side was that an attacker could fiddle with that on the client and gain access where they shouldn't etc. And since I heard that statement I have simply defaulted to the "it must be Blazor server" decision for any application that requires such functionality. Am I down the wrong path?
You are thinking about this the right way. As you said, any pure SPA involves shipping code to the browser and therefore just expect that someone will decompile or unminify it and read it. Therefore, you have to approach your application a different way. All authentication and authorization ultimately has to happen at a server. So even if you used the templates to determine who is logged in, and what their authorization is, you will want to back your application with APIs that ALSO must carefully authenticate the caller. The show we did today was our first look at Client authentication (Interactive WebAssembly or InteractiveAuto) and how the templates differ: ruclips.net/video/8GGxSJ8Bv_o/видео.html As we continue the series, the intent is to tackle these problems and show practical implementation for Blazor, but also APIs or services you'd connect to and how they ultimately must defend themselves so they do not either give out or accept data from a device it can not trust. This does NOT answer the question of whether you ultimately want to support the "client" render modes such as InteractiveWebAssembly or InteractiveAuto. If you don't need them, you aren't required to support them. But there are some applications that might work well in a disconnected mode, gather data while disconnected, and then when reconnected verify the user and accept the data collected while "offline". Thank you for watching.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Greetings from Brazil!
thanks a lot for the video @ hi from tashkent :)
I had heard that the problem with doing authentication (and authorization) client side was that an attacker could fiddle with that on the client and gain access where they shouldn't etc. And since I heard that statement I have simply defaulted to the "it must be Blazor server" decision for any application that requires such functionality. Am I down the wrong path?
You are thinking about this the right way. As you said, any pure SPA involves shipping code to the browser and therefore just expect that someone will decompile or unminify it and read it. Therefore, you have to approach your application a different way.
All authentication and authorization ultimately has to happen at a server. So even if you used the templates to determine who is logged in, and what their authorization is, you will want to back your application with APIs that ALSO must carefully authenticate the caller. The show we did today was our first look at Client authentication (Interactive WebAssembly or InteractiveAuto) and how the templates differ:
ruclips.net/video/8GGxSJ8Bv_o/видео.html
As we continue the series, the intent is to tackle these problems and show practical implementation for Blazor, but also APIs or services you'd connect to and how they ultimately must defend themselves so they do not either give out or accept data from a device it can not trust.
This does NOT answer the question of whether you ultimately want to support the "client" render modes such as InteractiveWebAssembly or InteractiveAuto. If you don't need them, you aren't required to support them. But there are some applications that might work well in a disconnected mode, gather data while disconnected, and then when reconnected verify the user and accept the data collected while "offline".
Thank you for watching.
Didn't know David Gilmour was into Software Development
thank you, really informative, i love the new blazor stuff in .net 8
Thanks for the comment! We are having fun with all the new blazor capabilities too!