FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login
    1. Home
    2. contact 0
    C
    • Profile
    • Following 0
    • Followers 0
    • Topics 1
    • Posts 2
    • Best 2
    • Controversial 0
    • Groups 0

    contact 0

    @contact 0

    2
    Reputation
    2
    Profile views
    2
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    contact 0 Unfollow Follow

    Best posts made by contact 0

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

      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!

      posted in Q&A
      C
      contact 0
    • RE: Why does FusionAuth store the encoded access_token as an HTTP Only session cookie when logging in?

      @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!

      posted in Q&A
      C
      contact 0

    Latest posts made by contact 0

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

      @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!

      posted in Q&A
      C
      contact 0
    • Why does FusionAuth store the encoded access_token as an HTTP Only session cookie when logging in?

      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!

      posted in Q&A
      C
      contact 0