There are three methods to maintain state on the web:

1. Cookies
2. Hidden tags
3. Mangled url

Essentially 1 and 2 are the same, pretty much sending some kind of token that you later get back and verify that everything is ok.

Point 3 can be split into two sub categories:

1. Creating a token as part of the URI
2. Adding the token to a parameter

If you're doing the 1st option its a little more work getting the url back, parsing it and extracting the token. the 2nd point is pretty much the same as the top lot of methods. (you can reference it by $q->param('token') with CGI.

In terms of building the token, the most accepted and secure way is to generate a unique string that has no direct relevance to the user in question. The token will be stored server side along with the user associated with it (you can also store other stuff like expiry).

Mechanically, acutally building the token is pretty damn easy. I've rolled my own using MD5 that pretty much will give a unique token every time: md5_hex('s3cr37 s7r1n6'.$userid.$$.localtime().rand());

How you store the association is pretty much up to you, i personally use a postgres database, but you can go with a flatfile, encrypted file, storable, a tied hash, some kind of caching module (gives you expiry by the length of the cache timeout) or whatever floats your boat.

For added security, you can rotate the token each page view. So you get the cookie, (read the token) look it up in your db, if it matches, generate a new token, update the cookie, then update your database.

Maintaining state with HTTP is not hard, however may be a little bit of work depending on whatever implementation path you choose. There are plenty of resouces out there, and its not hard to get it right and (relatively) secure the 1st time.

Update: I forgot authorisation. Its all server side, your user will log in with a username and password, this should be hashed using something like crypt, md5, sha1 or "Your fav hashing algo (tm)". Its then a simple matter of doing an encrypt and compare server side. Each time an existing user logs in, you get the password supplied, hash it, and compare it to the password you already have server side. If there is a match, you issue the token, if not, you kick them out.. (or whatever your procedure is).