• Generate a session token upon login.
• Store that session token in the database.
• Check for valid session tokens when authenticating.

Pretty much what you have. Just consider if you want to have more than one valid session at once and how you'll go about expiring sessions.

• Generate a session token upon login.
• Store that session token in the database.
• Check for valid session tokens when authenticating.

Pretty much what you have. Just consider if you want to have more than one valid session at once and how you'll go about expiring sessions.

EDIT for crazy comment thread below

While one can provide tokens to the client that are verified by the 2nd server without communicating with the 1st server, that's ugly and involves a lot of work. Such a scenario does not permit one to invalidate sessions unless the client takes care of it. It also requires a certain time window when tokens are passed, timestamping of tokens, tracking of tokens by the 2nd system, signing or HMACs in the token passing, etc. Unless these two systems can't see each other on the Internet, just avoid that mess entirely.

I gather that both systems can access the same database, but if for some reason they couldn't, having a API exposed to the second system that can remotely verify would be appropriate as well (secret.page?checkUser=token... or such).

Without SSL, there is nothing you can do to prevent session hijacking by means Firesheep / MITM attacks.