Support for Cookie authentication

[Alevsk]

• Added support for cookie authentication (authorization header authentication still exists and will have priority)
• Removed local storage token management from UI
• Cookie hardening (sameSite, httpOnly, secure), leverage on browser existing protections
• Login endpoint sets cookie via header, logout endpoint expires cookie

Future improvements

• Look for all places in backend that returns 401 unauthorized, and destroy session there (not a priority since cookie its invalid anyway)
• Downloading objects in object browser can be simplified since is just a GET request and users will be authenticated via Cookies, no need to craft additional requests

[harshavardhana]

why are we doing cookie based?

[Alevsk]

why are we doing cookie based?

Console is a browser application, there's no need to the use localStorage (we still maintain the support for clients that doesn't support cookies), instead we can use browser cookies and leverage on the existing security protections, right now the session token it's too expose and any injected malicious JS code would be able to read that information

[Alevsk]

why are we doing cookie based?

Console is a browser application, there's no need to the use localStorage (we still maintain the support for clients that doesn't support cookies), instead we can use browser cookies and leverage on the existing security protections, right now the session token it's too expose and any injected malicious JS code would be able to read that information

cookie based auth expose us to other series of threats such as CSRF but we can also fix those if ever happen, we need to add layers of security

[harshavardhana]

Console is a browser application, there's no need to the use localStorage (we still maintain the support for clients that doesn't support cookies), instead we can use browser cookies and leverage on the existing security protections, right now the session token it's too expose and any injected malicious JS code would be able to read that information

Almost every browser supports localStorage - Cookies are unnecessarily complicated - unless we are fixing something real.

[harshavardhana]

Almost every browser supports localStorage - Cookies are unnecessarily complicated - unless we are fixing something real.

Also any injected JS cannot access localStorage because browsers make sure that new JS code is never able to read your application's localStorage.

[harshavardhana]

Ideally, we should be using https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage if we want to be paranoid about it.

[Alevsk]

Ideally, we should be using https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage if we want to be paranoid about it.

I'll take a look harsha

[Alevsk]

Ideally, we should be using https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage if we want to be paranoid about it.

But it's not only that, the fact that JS (our own code or a third-party library) can read our token its pretty scary, right now we are using cookies already because of websocket communication (websockets authentication works only via cookies as far as I know, @cesnietor can confirm that), so this PR will unify the session handling mechanism to use only cookies instead of cookies and authorization header.

[harshavardhana]

But it's not only that, the fact that JS (our own code or a third-party library) can read our token its pretty scary, right now we are using cookies already because of websocket communication (websockets authentication works only via cookies as far as I know, @cesnietor can confirm that), so this PR will unify the session handling mechanism to use only cookies instead of cookies and authorization header.

Understood