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

GET /internal/private.html?pass=secret&sid=234234 HTTP/1.1
Host: www.company.com

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

POST /doLogin HTTP/1.1
Host: company.com
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows 10)
Referer: http://company.com/login
Content-Length: 34

username=john&password=supersecret

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).