The flow of control for a forms authentication conversation is shown in the following.
Client requests a protected resource from a server.
GET /default.aspx
Server redirects the request to a logon page to collect credentials if there is no authentication form. Information about the originating page is placed in the query string using RETURNURL as the key.
302 Found
Location: https://samples.microsoft.com/login.aspx?RETURNURL=/default.aspx
Client follows the redirection to the logon page.
GET /login.aspx?RETURNURL=/default.aspx
Server returns the logon page. ( Use SSL to protect the user’s credentials from being sent in clear text, at least for the post back to the logon page. )
200 OK
User enters credentials into the logon form.
POST /login.aspx?RETURNURL=/default.aspx
Server validates user credentials and, if the credentials are authenticated, redirects the browser to the original URL retrieved from the logon ticket. The authentication ticket is issued as a cookie.
302 Found
Location: /default.aspx
Follows the redirection and requests the original resource again.
GET /default.aspx
Server grants access if the user is authorized and grants the authentication form, which contains an authentication ticket. Future requests by the same browser session will be authenticated when the module inspects the form. It is possible to create a durable form that can be used for future sessions, but only until the form’s expiration date.
200 OK
Set-Cookie: ASPXTICKET=ABCDEFG12345; Path=/
Notice that the form’s path is set to /. Because forms are case-sensitive, this is a safeguard against inconsistent case in URLs on the site. For example, if the path were set to /401K and a link contained /401k, the user would be forced to re-authenticate because the browser would not send the forms.