Authentication Flow State
Sessions
HTTP is stateless and provides no way of keeping state.
Besides WebSockets in HTML5.
Most applications over HTTP need a state for good purposes.
User preferences.
Navigation history.
Authentication state.
Some use it for less noble purposes, usually compromising privacy.
Track users across multiple sites for advertising purposes.
Profile user behavior.
Keeping Mechanisms
Referer header.
SESSION_ID, or SID, or other custom headers.
Cookie.
JSON Web Token
Use of the URL
Input encoded as part of the URL as Request Arguments.
GET request is expected to have side effects.
Arguments control language, authentication, and authorization.
Should be avoided at all costs to transport state
Arguments are visible in the browser.
A use problem if your browser is visible: public presentation, remote lecture, over-the-shoulder eavesdropping.
Arguments may be logged by the web server.
Enable compromise if logs are accessed by an attacker.
SEO is broken: different users will have different URLs for the same resource.
The cache may be impacted: unique URLs limit the use of caches.
Use of a POST request
GET vs POST
GET is used to REQUEST information.
Can be resent by browsers.
May be logged, cached, bookmarked, or kept in the browser history.
Should not change server-side state (no side effects).
Frequently it will change state, or create logs.
POST is used to UPDATE information.
Will not be cached, bookmarked, or kept in browser history.
May not be logged §Is not visible to users.
Is expected to change the server-side state (has side effects).
Last updated