A simpler flow proposal

[el1s7]

After taking a look at this, it seems it's overly-complex and not clear, for something that should only serve a simple purpose: "proving the user requests are coming from his browser where he initially logged in".

I think maybe instead of the current approach (which I'm not sure I understood very well) this could be done with just some extra security headers. Here's my proposal:

---

1. When the server initially sets the cookies for the first time on the client, such as when it's starting a user login session or identifying the visitor, it can additionally ask the browser to start a secure session by returning a special header on the response alongside the "Set-Cookie". Also, it can return a header for specifying when the browser should return the secure session public/symmetric key information, for example:

Set-Cookie: user_session_id_bla_bla=... Sec-Secure-Session-Start: 1 Sec-Secure-Session-Start-Url: /example/user/logged_in/welcome

2. The browser then creates a new secure session. And on the next client request that matches the provided URL, the browser adds the headers for informing the server that a secure session has started and "this is the public/symmetric key" (the key is only sent once when a session starts). No additional API requests made, all communication is done easily through headers.

Example headers returned only once on the initial session start at the specified URL:

Sec-Secure-Session-Key: xxxxx...

This key is then saved by the server and tied to the current user session internally on the server.

3. After session is started, an encrypted token/jwt with an expiry time is generated securely by the browser on a configured interval that doesn't impact performance, and this is used for verification/proof-of-possession, and it's added on all next, future requests.

Example header returned on every request after session stars:

Sec-Secure-Verification: xxxx...

The server then verifies this token, and checks that is not expired. The browser keeps the secure session until the cookies for that website are cleared, so the session is closed when the cookies are deleted.

---

Using headers instead of communicating with additional HTTP requests seems more simpler to me, and more fit for a browser protocol, historically new protocols have been introduced using headers. Doesn't seem necessary to do all the other complex extra work, such as the refreshing mechanism. Keep it simple, easy to adapt by websites.

And, in the end, it's all up to the servers to decide if they will implement and respect this security protocol or not.

P.S. Thanks to the team for your work on this and the idea 👍

Edit: Look at my comment below for seeing the updated proposal which makes use of the server challenge mechanism.