If a user visits a web page (makes a request) and the server detects a session cookie, it will check if it currently has a session stored with the ID from the cookie, and if that object is still valid (whatever that means: not expired, not revoked, not blacklisted, etc.).
If the session is still valid, it will respond with the requested web page (or data). If it finds a session object, that object can contain data in it and with that, the server can "remember" who you are and what you were doing (e.g., if this is an ecommerce store, what products you've added to our shopping cart).
If the session is not valid (or no session cookie was detected) it will respond with some sort of error message saying that the request is "unauthorized".
New sessions can typically be created by sending a username/password combination to a specific endpoint from a login page. If the server can match a user with that username and password, it will generate a new session object on the server and set a cookie on the client with the session's ID for any future requests.
If a user turns off their computer and comes back to the website some time in the future, s/he can either automatically login again (if there is still a cookie in the browser that hasn't expired) or login again through the login page. Once logged in, the user's session can be retrieved again from the data stored on the server, and the user can go on with their business (e.g., continuing to shop after reloading your shopping cart).
This type of setup has worked pretty well for us since the web came out and since we've been visiting web sites that do most of their "thinking" on the server side. Typically this has been a conversation between the user's frontend browser and a corresponding backend server in a one-to-one relationship.
Multi-server Cookie Auth Flow is Broken
This setup still works, but these days we have many different situations that require different setups (e.g., multiple mobile native apps alongside large single-page web apps contacting multiple backend services, that may be nothing more than json data without a webpage at all). In these types of scenarios, the cookie you get from one server, won't correspond (or even be sent) to another server (let alone the problems that get created with CORS).
Multiple Backends: What if your app needs to talk to a database backend as well as a separate image processing backend? more and more, our digital world is being split up into separate micro-services; when authenticating with more than one backend, things can get complicated (e.g., you could either proxy all requests through a central app server which would then need to know all the logic of each secondary service, or each service could implement complex inter-server communication (and CORS) to verify incoming session IDs with a central auth server... in either case extra load on the app server is required and more complex interconnects need to be maintained).
Sessions: need to be stored somewhere, either in memory, in a database, or keyvalue store like Redis; and they need to be managed so that they are removed when they expire or are otherwise invalidated.
Poor Scalability: The session store needs to be scaled when scaling the server. The store uses up resources, and adds complexity.
Performance Issues: When the session needs to be stored on the server, a lot of database/store lookups need to happen on every request which can bog down the server.
Native Apps (or non-browser apps): Browsers handle cookies, but custom apps don't (at least not easily), so a different kind of session mechanism is needed.
CSRF: If cookies are being used, extra security is needed to prevent cross-site request forgergy attacks since the cookie will be automatically sent to the server with any request made from that site.
CORS: Cookies + CORS don't play well across different domains (actually, real cross-domain doesn't work at all).
Cookie-based Auth Flow
If a user visits a web page (makes a request) and the server detects a session cookie, it will check if it currently has a session stored with the ID from the cookie, and if that object is still valid (whatever that means: not expired, not revoked, not blacklisted, etc.).
If the session is still valid, it will respond with the requested web page (or data). If it finds a session object, that object can contain data in it and with that, the server can "remember" who you are and what you were doing (e.g., if this is an ecommerce store, what products you've added to our shopping cart).
If the session is not valid (or no session cookie was detected) it will respond with some sort of error message saying that the request is "unauthorized".
New sessions can typically be created by sending a username/password combination to a specific endpoint from a login page. If the server can match a user with that username and password, it will generate a new session object on the server and set a cookie on the client with the session's ID for any future requests.
If a user turns off their computer and comes back to the website some time in the future, s/he can either automatically login again (if there is still a cookie in the browser that hasn't expired) or login again through the login page. Once logged in, the user's session can be retrieved again from the data stored on the server, and the user can go on with their business (e.g., continuing to shop after reloading your shopping cart).
This type of setup has worked pretty well for us since the web came out and since we've been visiting web sites that do most of their "thinking" on the server side. Typically this has been a conversation between the user's frontend browser and a corresponding backend server in a one-to-one relationship.
Multi-server Cookie Auth Flow is Broken
This setup still works, but these days we have many different situations that require different setups (e.g., multiple mobile native apps alongside large single-page web apps contacting multiple backend services, that may be nothing more than json data without a webpage at all). In these types of scenarios, the cookie you get from one server, won't correspond (or even be sent) to another server (let alone the problems that get created with CORS).
在Session会话认证模型中，在用户登录并授权后，服务器将创建客户端唯一的Session。服务器将Session ID返回给客户端，然后客户端将其存储在浏览器的cookie中。在随后的HTTP调用中，cookie将自动包含在HTTP请求头中，服务器将通过cookie中记录的Session ID得知客户端的身份。尽管cookie存储在客户端，但是由于验证是在服务器上完成的，因此该认证模型属于服务器端会话。
链接：https://juejin.im/post/6844904061439836167
Session认证的优点
Session认证的缺点
Drawbacks With Cookie-based Auth
Complex Multi-server Cookie Auth Flow
Multiple Backends: What if your app needs to talk to a database backend as well as a separate image processing backend? more and more, our digital world is being split up into separate micro-services; when authenticating with more than one backend, things can get complicated (e.g., you could either proxy all requests through a central app server which would then need to know all the logic of each secondary service, or each service could implement complex inter-server communication (and CORS) to verify incoming session IDs with a central auth server... in either case extra load on the app server is required and more complex interconnects need to be maintained).Sessions: need to be stored somewhere, either in memory, in a database, or keyvalue store like Redis; and they need to be managed so that they are removed when they expire or are otherwise invalidated.Poor Scalability: The session store needs to be scaled when scaling the server. The store uses up resources, and adds complexity.Performance Issues: When the session needs to be stored on the server, a lot of database/store lookups need to happen on every request which can bog down the server.Native Apps(or non-browser apps): Browsers handle cookies, but custom apps don't (at least not easily), so a different kind of session mechanism is needed.CSRF: If cookies are being used, extra security is needed to prevent cross-site request forgergy attacks since the cookie will be automatically sent to the server with any request made from that site.CORS: Cookies + CORS don't play well across different domains (actually, real cross-domain doesn't work at all).Reference