Why does FusionAuth store the encoded access_token as an HTTP Only session cookie when logging in?

[contact 0]

Why is this behavior the default one and are there any security risks with using this method?
My understanding was that storing access_tokens in cookies is bad-practice since your app would be susceptible to CSRF attacks.
I understand that the cookie has the Domain attribute and is HttpOnly. This makes it more secure but, would it not be better to completely mitigate the risk of a CSRF attack by only storing the refresh_token in a cookie and the access_token in memory? Also, the SameSite attribute is present but why is it set to "Lax" as opposed to "Strict"?
Could you please provide more details about the reasoning behind this implementation?

Thank you!

[dan]

Are you using the OAuth grant or the login api? The OAuth grant expects you to have a server which can hold the access token, so maybe you are talking about the login API?

Storing access tokens in cookies is the least bad option, if you have a SPA to which you need to send an access token. They should be Secure and HttpOnly. The latter closes off a whole set of attacks if there is rogue javascript on the page. However, if you didn't want to do this, you could use a server proxy to send down the access token to javascript and have it stored in memory. Secured cookies are a middle ground, but if you are worried about CSRF, don't ever send the access token to the browser (nor the refresh token, which can be used to mint new access tokens).

This bug may be of interest to you too: https://github.com/FusionAuth/fusionauth-issues/issues/882

You can control the SameSite setting via FusionAuth configuration: https://fusionauth.io/docs/v1/tech/reference/configuration It looks like setting it to strict can, in certain ways, cause expected SSO type functionality to break. From https://blog.benpri.me/blog/2019/05/13/samesite-cookies-in-practice/

In Lax mode, the browser will still send the cookie when a cross-domain “top level” GET request is triggered. This is necessary because Strict mode breaks some functionality across the web. For example, if your session value for a given site is set with SameSite=Strict; when you click a link to go to that site from a different site, you’ll arrive without a session.

[contact 0]

@dan Yes, I am using the login API and the Identity Provided API. More specifically, the following routes: /api/login & /api/identity-provider/login. They both have similar response cookie functionality. Your explanation makes sense, however I do agree with the GitHub issue about this functionality being optional (or at least allow the developer to choose which response cookies they want to set). For the meantime, I suppose I'll just use the provided functionality as-is and look more into the mentioned alternatives if necessary.
Also, thanks for linking to the SameSite configuration. I'll take a look at it to see if it fits my needs.

Thank you for your reply!