alert‘OAuth 2 0’; // The impact of XSS on OAuth 2 0 in SPAs

In this webinar, we take an honest look at the dangers of XSS in SPAs. We discuss the impact on OAuth 2.0 along with current security best practices.

[iiilllii]

I rarely comment, but this here is the most indepth security analysis about different OAuth security implementations, currently available. I highly appreciate your examples, to understand the specific attack surfaces. I already did implement the BFF pattern a while ago, and your talking just proves the point in doing so. This video deserves a bigger audience! Thank you so much.

[errorist]

at 34:25 it is mentioned that the clientid used at BFF has to use clientsecret while exchanging authorization code or while fetching new token from refresh_token. does it also need to follow additional PKCE if we are using client secret here from back channel? the "OAuth 2.0 for Browser-Based Apps" ietf document says "The Application Server SHOULD be considered a confidential client, and issued its own client secret. The Application Server SHOULD use the OAuth 2.0 Authorization Code grant with PKCE to initiate a request for an access token." I was under the impression that whenever we create a PKCE client there won't be any client_secret assigned to it.

[geovajonnathacorreia]

what's the difference in sending this httponly cookie directly to my main api with some midleware for validation instead of having to have a BFF?

[lawdwinter]

Something I noticed is that if you use the access token directly in the cookie, I know is no problem since as you said it will be encrypted and signed but the problem is that the refresh token is not persisted so is better to use a cookie session to store both the access token and refresh token so we can perform refresh if necessary along with refresh token rotation. I would appreciate a response on this.

[philsmart]

So the BFF is just the authentication context part of a standard client-server architecture using server-side session?

[rustandgasoline]

Great video! One question: at around 35:50, there is mention of putting the tokens in an encrypted format in the cookie. Would this mean just that the cookie is HttpOnly or also encrypted on top of that?

[Lexaire]

Is there any benefit in rotating the HttpOnly cookie? Or just expire after say 1-30 days?

[ranesh]

DPoP with Crypto keys seems to work if you make the crypto key not extractable. (Extractable = false). The CrytpoKey object is stored in IndexedDB.
However, I wonder if XSS can simply create a new CryptoKey (a malicious one) and replace the old one?

[Xenizs]

should the BFF be part of the process of authorizing other resource APIs? let's me explain, say you want the user to able to authorize another resource API after the user have been authenticated, in such case we would do client authentication when exchanging the tokens in the API not the proxy BFF API, since this process would apply to others clients as well (web, mobile, etc).

[robbinhasseltof]

Haha holy shit you destroyed tokbind! Normally I don't watch webinars till the end because I get bored quick but this was very interesting!

You must make the session cookie between the frontend and BFF httpOnly, right? To prevent it from being accessible by javascript? Otherwise it will be vulnerable to the same XSS attacks as you described earlier.

[notramiras]

I'm sorry to say but all these "localStorage is just fine" reasonings are dumb... I don't have a better word. Secure cookies obviously _do matter_. It does matter that in case of an XSS breach, you have to revoke the secrets or not. Security is layered, it's like 101... It also matters if someone can exploit an overprivileged token off-site, or they can only use the web UI's API.