For Ajax based authentication, it's not a whole lot different than providing a traditional web infrastructure. What we're aiming for is to guarantee our session is secure and there is an established and persistent authentication object for all requests. There are a number of ways to accomplish this.
First is to secure the wire. This means whatever we do, make sure the user can never get to the website via regular HTTP and always uses HTTPS. It's pretty simple to setup Apache to do this.
Next is the authentication mechanism. The objective here is to generate and cache a session object that is guaranteed to be correct between the web server and the web browser for the duration of that web browser's session or until a session timeout occurs. This can easily be provided in one of two ways: HTTP authentication or HTTP sessions.
The positives of HTTP authentication is that it's standards based and provides transparent authentication after an initial authentication is complete. We get headers for the username, password, and realm for every invocation to the web service after this is completed. This includes invocations with our embedded ajax components. The negatives is that it's not secure, so we absolutely need to push it over HTTPS if you're going to use it. In addition, there's no authorization mechanism built in, so we need to roll own for authorization levels. And finally, we can't log out if using HTTP authentication. Once a user is authenticated, there's no means to unauthenticate them other than closing the browser and starting over.
Session-based authentication provides similar functionality to HTTP authentication, but we need to manage the session information. It does not provide a means to do authorization levels either, requiring we to roll our authorization levels. The benefit of session-based authentication is that we can log out from a session by removing the session variable at the web server. The disadvantages of using session-based authentication is that we have to figure out a mechanism to store passwords in other than cleartext format. This is because we're not sent the username/password combo in the headers, but instead we get a sessionid for the established session.
A basic rule of thumb, provided we're not doing persistent cookie session information, is that until a user establishes a known authentication session with web server, there are no credentials available with which to guarantee their access. Typically the ONLY place I need to make absolutely certain that authentication has happened is on the server, since that's where all of the data will be housed. The browser is just a window into that data.
From a technical perspective, here's how a session-based authentication would work:
- User starts a brand new browser and connects to ajax-enabled app.
- Application then posts some type of dialog box requiring a login to the server
- The user enters their username/password into that dialog and clicks the login button
- Javascript should hook the login button and send an ajax request to whatever login script/service/servlet/whatever is running on the server side
- The server takes the parameters and passes them through whatever authentication system using on the server.
- If the credentials work, the server creates a sessionid storage area for this new sessionid and returns a positive response to the ajax client. Part of the http headers for this response is the sessionid for maintaining session information between the client and the server. In the sessionid storage area on the server, we can store whatever variables we want to store.
- The HTTP stack in the browser maintains the sessionid for each successive invocation to the web server that it's talking to and ONLY for that web server. As long as the browser is running, the sessionid is maintained. Once the browser goes away, the sessionid goes away with it. There are known session hijacking hacks out there, but they can be averted by providing a bit more information within the variables attached to the sessionid on the server.
- Each of the successive xmlhttprequest objects that ask for data from the server pass the sessionid with it. In our application on the server, the first thing we need do for EVERY invocation is validate that the sessionid is still valid. There are mechanisms in most server application frameworks to provide session expiration by a variety of means. We just need to validate their sessionid with whatever framework you're using.
