Sounds very complicated but really interesting. What I’ve got from this video is that we should use our backend API to work with all of this authentication and authorisation stuff and that we should not use our frontend for this purposes.
In the OIDC authorization code flow with pkce, which would be taken care of here through the bff, the user will be redirected to a signin page on the Idp. How can the spa redirect the user to the idp without getting the redirect url from the bff? Wouldn't the spa have to get the redirect url from the bff, including any clientId and codeChallenge?
From what I understand, the login button points to the BFF, which redirects the browser to the AuthZ Server. The browser receives back the AuthZ Code via a redirect which passes it to the BFF. The BFF then exchanges the AuthZ code for the tokens, and passes the access token back to the User in a cookie (set with HTTPOnly so that malicious JS cannot read it). The User then calls the API via the BFF who extracts the token from the cookie and forwards the request to the API. At least that's what I think is happening !
@@ryandsouza2962 no it's so defiantly not. BFF is when you have two application workflows depending on platform commonly used for authentication. SSR is when you have a very lightweight frontend which calls a backend that renders the UI & retrieves it's data together.
If an attacker has access to your client-application, he can make api calls regardles of using auth with session-tokens or http-only cookies. BFf just seems to add unnecessary complexity.
@@Ry4nWTF true, also the attack will be constrained by the time and context of the client-session. However its important to note, that using http-only cookies, will not protect you from xss attacks. Its just another layer of security. If someone manages to gain access through xss, you already fucked up. Also, using cookies opens you up to CSRF/CORF, which token-based auth doesn't. It all depends whether the added layer of security is worth the added complexity. I am still not sure how much security the added layer from bff actually brings, and if its worth it.
@@tombalabomba3084 yeah I know, you're fucked either way with xss. However, CSRF/CORF shouldn't be an issue with same-site lax/strict, a simple static x-csrf-secure token and proper cors rules. Just login to your bank and see what you are returned: most likely a cookie. I have two banks and none of them store tokens in the browser. So I guess it depends on your security policies. The most important thing you can do regardless of cookies/tokens is to do the token exchange on the server with a client secret. But I agree, in my view it seems to be only a small added benefit, however worth it if security is important, eg finance/health.
@@tombalabomba3084 in the talk the speaker mentions that when using cookie based auth for the frontend layer in BFF, you HAVE to use the CSRF token and by default cookie based system uses the same origin policy - a big advantage in comparison to access tokens. That is the only way to NOT expose the access token - because access token is NOT protected by all the protections that are available to Cookie based models e.g. same origin checks and so on.
The world does come full circle. This so called "BFF" is exactly the same old traditional way how application handles oauth login before so many misinformed incompetent developers bindly doing things just because they could. Now these people reinvent the wheel with a new fancy name for a decade old technique like they imvented it. Yay!
With the advent of things like distributed redis, server sessions are actually a viable, scalable (perhaps not to google scale) solution to the problem for the other 99% of us.
Great talk! I understand things with respect to a SPA.. But not sure how things work with openid connect and a mobile app.
Can you please share the source code that you used in the demo?
So, we back again to cookie, so we need store them to identificate user on BFF layer, is not?
Sounds very complicated but really interesting. What I’ve got from this video is that we should use our backend API to work with all of this authentication and authorisation stuff and that we should not use our frontend for this purposes.
In the OIDC authorization code flow with pkce, which would be taken care of here through the bff, the user will be redirected to a signin page on the Idp. How can the spa redirect the user to the idp without getting the redirect url from the bff? Wouldn't the spa have to get the redirect url from the bff, including any clientId and codeChallenge?
From what I understand, the login button points to the BFF, which redirects the browser to the AuthZ Server. The browser receives back the AuthZ Code via a redirect which passes it to the BFF. The BFF then exchanges the AuthZ code for the tokens, and passes the access token back to the User in a cookie (set with HTTPOnly so that malicious JS cannot read it). The User then calls the API via the BFF who extracts the token from the cookie and forwards the request to the API. At least that's what I think is happening !
How do we secure mobile apps? Can this pattern work with mobile as well?
mobile platforms have a secure storage so storing tokens is not an issue in the mobile platform unlike browsers.
@@surensingh123 oh great. Do you have any sample repo that I can take a look at for an example?
Could this be used on SSR applications?
SSR is basically backend for frontend
@@ryandsouza2962 no it's so defiantly not. BFF is when you have two application workflows depending on platform commonly used for authentication. SSR is when you have a very lightweight frontend which calls a backend that renders the UI & retrieves it's data together.
If an attacker has access to your client-application, he can make api calls regardles of using auth with session-tokens or http-only cookies. BFf just seems to add unnecessary complexity.
yes but the calls will have to be done from a browser, you can't extract the http only cookies
@@Ry4nWTF true, also the attack will be constrained by the time and context of the client-session. However its important to note, that using http-only cookies, will not protect you from xss attacks. Its just another layer of security. If someone manages to gain access through xss, you already fucked up. Also, using cookies opens you up to CSRF/CORF, which token-based auth doesn't. It all depends whether the added layer of security is worth the added complexity. I am still not sure how much security the added layer from bff actually brings, and if its worth it.
@@tombalabomba3084 yeah I know, you're fucked either way with xss. However, CSRF/CORF shouldn't be an issue with same-site lax/strict, a simple static x-csrf-secure token and proper cors rules.
Just login to your bank and see what you are returned: most likely a cookie. I have two banks and none of them store tokens in the browser. So I guess it depends on your security policies.
The most important thing you can do regardless of cookies/tokens is to do the token exchange on the server with a client secret. But I agree, in my view it seems to be only a small added benefit, however worth it if security is important, eg finance/health.
@@tombalabomba3084 in the talk the speaker mentions that when using cookie based auth for the frontend layer in BFF, you HAVE to use the CSRF token and by default cookie based system uses the same origin policy - a big advantage in comparison to access tokens. That is the only way to NOT expose the access token - because access token is NOT protected by all the protections that are available to Cookie based models e.g. same origin checks and so on.
So all in all this is just an advertising for Deunde server product?
The world does come full circle. This so called "BFF" is exactly the same old traditional way how application handles oauth login before so many misinformed incompetent developers bindly doing things just because they could. Now these people reinvent the wheel with a new fancy name for a decade old technique like they imvented it. Yay!
The laughing is so annoying
going back to 20y ago is a waste of time …
With the advent of things like distributed redis, server sessions are actually a viable, scalable (perhaps not to google scale) solution to the problem for the other 99% of us.