man i love ur vids very clear and to the point, keep up
@highdynamic Жыл бұрын
nice and straightforward overview! (for origins though - while I know it was just an example in the video - avoid "startsWith" because evil can make a matching subdomain easily : )
@IvanRandomDude2 жыл бұрын
I use cookies for SPAs when I have simple system API + one SPA client. I just make sure to use the same domain in deployment. Something like app(dot)io and app(dot)io/api. Usually using reverse proxy of some kind to direct traffic from app(dot)io to front end ip address and app(dot)io/api to back end ip address. Both front end and back end are not accessible directly (hidden inside security group). It is some form of simplified BFF but without oauth2 and token relaying. You don't even need this if you are serving SPA directly from back end. Most frameworks allow you to serve SPA as simple static content, although I don't like this approach.
@GabrielBartolazzi2 жыл бұрын
How would this scale if your API would also have to be accessed by a mobile app? Would you implement an identity server or some other methodology?
@IvanRandomDude2 жыл бұрын
@@GabrielBartolazzi I would cry and then go home. I don't know, I don't make mobile apps. Still not sure about Identity Server because I don't know if it can be used for free now. They say if your company make less than million a year which is not much for a company. Even small companies can make that money. Maybe pick some other solution like Keycloak or nodejs service based on oidc-provider. But Keycloak is pain in the a** for customization. Not saying it's hard but there are not many great online resources about SPI implementations. Documentation has one simple code sample. Maybe I would create simple identity based on Spring Authorization Server instead of Identity server. But SAS is new and not sure if it is still production ready. They say it is but I would bet not many people use it yet. In the end, what about identity providers like Okta? Never used it but I heard it can get really pricey.
@GabrielBartolazzi2 жыл бұрын
@@IvanRandomDude I'm not the only one running into these frustrating issues... There's also OpenIddict, which I haven't tried yet.
@RawCoding2 жыл бұрын
Check my authentication playlist
@GabrielBartolazzi2 жыл бұрын
Your videos are excellent! You explain complicated concepts in a simple and easy to understand way. A video showing a shared API between SPA and Xamarin would be great. Or someone who explains why IdentityServer? or any introduction to OpenID Connect and OAuth 2.0
@RawCoding2 жыл бұрын
Cheers, for ids4 got a kzbin.info/www/bejne/a36kiql3Z8t0mqM I’ll see what to do about OAuth flow etc
@vinnbrock2 жыл бұрын
@@RawCoding that would be awesome (the OAuth 2.0)! Just found your channel and I really appreciate your content!
@EzequielRegaldo Жыл бұрын
Excelent video, for 2° attack we can use cors instead or not ?
@andreasaa25632 жыл бұрын
Keep these type of videos coming!
@whitebudgie5 ай бұрын
dude! thank you so much.
@1dfe-4e68-bd9f2 жыл бұрын
as always advanced topics! 👌
@christiandemienculanag23202 жыл бұрын
Informative!
@piercejohnstevens20382 жыл бұрын
Hi, A bit out of topic but how would a SPA access claims in the frontend from a Cookie?
@RawCoding2 жыл бұрын
Good question! It doesn’t and it shouldn’t, make an api call.
@recepgultekin2455 Жыл бұрын
I just don't understand why I can't post json from another origin, because CORS is for reads and not writes. I would expect that with posting json data from a different domain, I am gonna receive a cookie and save it in my browser. When the user goes to that website he/she is authenticated with my account. Could you explain this please?
@RawCoding Жыл бұрын
You can’t post from different domain because it’s a browser security feature. You don’t want faceboook.com (malicious site) to post credentials to real Facebook. Auth cookies should never work cross domain.
@ataadevs2 жыл бұрын
Why cors doesn't work when submitting form from different origin and even when attacker request data from different origin after login
@RawCoding2 жыл бұрын
Because I disable it for that case
@denisivanov48882 жыл бұрын
Nice video! But I didn't understand why this simple form login replaced the cookie for the 'company.local' domain just like that and suddenly became 'logged in' from 'foo' to 'evil'.
@RawCoding2 жыл бұрын
That’s the vaulnerability to be able to post data from 1 domain to the other and browser automatically attaching cookies
@pjank Жыл бұрын
Love this video! Great, practical explanation of a tricky subject. And I want to belive that in apps like this we can safely rely on SameSite cookie only, but... what are your thoughts on the fact that both OWASP and RFC 6265 still insist that this shouldn't be our only protection?
@pjank Жыл бұрын
The above is a fragment of a longer comment I made weeks ago, only now realizing nobody else could see it. Let me try how much I can add and clarify before YT blocks this again... OWASP - i.e. CSRF Prevention Cheat Sheet RFC 6265 - the section on Strict and Lax enforcement
@nullentrophy2 жыл бұрын
Maybe unrelated but can you secure your api that only your spa can access it? I guess you can do that with CORS but attacker may use modified client or smth like that to exfil your data
@RawCoding2 жыл бұрын
That’s impossible, only via vpn
@nullentrophy2 жыл бұрын
@@RawCoding so someone with malicious intent could easly drain your api quota
@RawCoding2 жыл бұрын
Yea if you embed the token in the client. But if you own the api that’s called ddos
@nullentrophy2 жыл бұрын
@@RawCoding So to make it clear, the token is always public. There is no security mechanism to hide token. I have never realised this, this is low key shocked me. Thanks for info, I appreciate your taking time to answer my silly question
@RawCoding2 жыл бұрын
It depends what kind of token you are talking about. But don’t keep secrets on the client. If it’s an authentication token it’s kinda same thing, you want a backend that will securely store the token.