asp.net mvc log in architecture options

System.Web.Security.FormsAuthentication uses cookies:

FormsAuthentication.SetAuthCookie(userName, rememberMe);

No session is used there. Of course, if you want more than a username and isAuthenticated, you'll need some other way to store that state. Your only real alternatives are cookies or the URL, neither one of which are generally acceptable for other reasons.

Session is not evil, especially given your options to host session data on a shared server or on a SQL Server instance.

Session can certainly be abused and your scalability will suffer, but I would not eschew session completely unless there were other overriding concerns.

If you must toss out session entirely, you will have to either recreate state on each call, an expensive proposition generally, or you will have to create your own state storage mechanism which brings us back to standard ASP.NET session storage alternatives.

You basically have 3 options, that I can think of, to authenticate HTTP requests.

1) Cookies only, where you set a cookie on the users machine with the necessary information you need to identify them on their next request

2) Sessions. Session will typically also use cookies (to store session information), but don't have to (see http://msdn.microsoft.com/en-us/library/aa479314.aspx)

3) Stateless authentication. This is really only used for non-browser HTTP clients calling webservices. This includes the client signing the http request with a public/private key combination that the server can then authenticate. An example of a stateless HTTP authentication protocol is OAuth (though OAuth as a spec is really geared towards authorization, but authorization by it's nature requires authentication).

See Web authentication state - Session vs Cookie vs? for additional discussion on Cookies and Sessions.

The common approach is to use cookies. See Securing and ASP.NET MVC Application.