You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setting Both Access and Refresh Token as HTTPOnly Cookies From Should be Optional
JWT set as a Cookie is unnecessary for all clients and therefore an added vulnerability
I am using Fusion Auth along with a Hasura backend. For me to be able to communicate with the api, I need to pass in a JWT in the Header. Thanks to JWT populate I was able to pass in custom claims needed for making requests with Hasura! However, I am not able to make requests with an access token encoded in an HTTPOnly cookie, which I get back when making requests to login or idp endpoints like /api/login, /api/identity-provider/login, or /api/jwt/refresh, and nor would I do that as that increases the risk of CSRF attacks. For those who want to use such a cookie that's fine, however for my use-case and I'm sure others who use hasura, always getting back an access token stored in a cookie is nothing but an unnecessary risk (even if it is HTTPOnly and Same-Site Lax) especially since I have absolutely no need for it.
Make Setting Access and Refresh Token as HTTPOnly Cookies Optional
I think the best solution would be to be able to explicitly state in the request which tokens, if any, you would like set as HTTPOnly cookies. This way the developer is able to customize the great features FusionAuth has to offer to their needs without limiting the capabilities for anyone else as well as mitigate security risks such as those seen in my case. This would be great since then I can only have the refresh token set as an HTTPOnly Cookie and I can access the JWT from the response body to send as a header to my hasura api requests. When my JWT expires or the user refreshes or closes the tab, I am able to persist the session by utilizing the HTTPOnly Cookie by making a request to the /api/jwt/refresh endpoint and get back a new JWT while ONLY the tokens I specify, in this case refresh token, will get set as HTTPOnly Response Cookies.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
The text was updated successfully, but these errors were encountered:
Setting Both Access and Refresh Token as HTTPOnly Cookies From Should be Optional
JWT set as a Cookie is unnecessary for all clients and therefore an added vulnerability
I am using Fusion Auth along with a Hasura backend. For me to be able to communicate with the api, I need to pass in a JWT in the Header. Thanks to JWT populate I was able to pass in custom claims needed for making requests with Hasura! However, I am not able to make requests with an access token encoded in an HTTPOnly cookie, which I get back when making requests to login or idp endpoints like /api/login, /api/identity-provider/login, or /api/jwt/refresh, and nor would I do that as that increases the risk of CSRF attacks. For those who want to use such a cookie that's fine, however for my use-case and I'm sure others who use hasura, always getting back an access token stored in a cookie is nothing but an unnecessary risk (even if it is HTTPOnly and Same-Site Lax) especially since I have absolutely no need for it.
Make Setting Access and Refresh Token as HTTPOnly Cookies Optional
I think the best solution would be to be able to explicitly state in the request which tokens, if any, you would like set as HTTPOnly cookies. This way the developer is able to customize the great features FusionAuth has to offer to their needs without limiting the capabilities for anyone else as well as mitigate security risks such as those seen in my case. This would be great since then I can only have the refresh token set as an HTTPOnly Cookie and I can access the JWT from the response body to send as a header to my hasura api requests. When my JWT expires or the user refreshes or closes the tab, I am able to persist the session by utilizing the HTTPOnly Cookie by making a request to the /api/jwt/refresh endpoint and get back a new JWT while ONLY the tokens I specify, in this case refresh token, will get set as HTTPOnly Response Cookies.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
The text was updated successfully, but these errors were encountered: