WoW uses (a slightly modified version of) SRP6 (Secure Remote Password - Google it) for client authentication.
Basically what you want to do for login at least, is to store your players' accoutnames and passwords in a database. Assume they've already been created through a web interface. Then you simply send your password and accountname to the server, check against the database for validity, and reply with an OK or ERROR.
How you choose to transfer the password is obviously up to you, but I'd say that the easiest way is probably to hash your user's input before sending, and then check against either a hash of the correct password stored in the database or against a hash that the server generates internally.
I'd send you a link to the protocol documentation for WoW, but can't due to controversial reasons.

Edit: For the benefit of the topic, I'll post an outtake from the aforementioned protocol description describing in general terms how WoW handles lag and updating positions;

'Objects are the most important part of WoW World. Everything that "exists" there is an Object. Example: a bag is "an evolved" Item which is also "an evolved" Object. Same concept applies to almost everything in the game.

I will consider Object and it's inheritors as Classes in my overview. An inheritance tree can be found at: Update Fields.

What does such an architecture give us? Low bandwith usage and an unified method of reporting updates of the specified Objects to the Client. Let's consider a Player surrounded by N number of Objects. Let's now consider that in 300 msec 50% of them have changed some internal states and need to report those changes to Player. If all of them would have sent separate packets for all Updates, it would greatly increase bandwith usage. The concept used in WoW is to Cache all the updates in each object and send those updates once every N msec of time, constructing an SMSG_UPDATE_OBJECT that would contain updates for all Objects surrounding Player. Now, in case the size of the Update Packet is greater than 100 bytes, it would be compressed and encapsulated in SMSG_COMPRESSED_UPDATE_OBJECT. For example a Client can receive a 9Kb packed update packet which decompressed would be of 40Kb size. That is what I call bandwith saving.

Update Packets can also contain info about objects that "entered your cell". It would contain objects' X, Y, Z ... Speed and other similar info.
'

It's software architecture. If it concerns a single class (like RAII), your in idiom land, if it concerns the interaction of a few classes, you're talking about design patterns and if it's about the structure of the whole application, you've got an architectural pattern :)

I doubt you will find much information on this since many developers don't bother about laying down a complete architecture for their games first and those that do make their money with it and won't give away such informations (let alone refine them into an abstract for others to use).

If you're interested in the architecture of game servers for normal multiplayer games, there are several games that have their source code released. The Quake games, for example, uses a Client/Server architecture, even for single player games.

For MMOs, there's PlaneShift, an open source MMORPG.

You might also gain some informations from looking at networking libraries such as Game Networking Engine and RakNet. Both provide high level classes dealing with object synchronization between client and server and can give you some clue on how a game server would have to be designed to make use of them effectively.

There are some pointers in the Forum FAQ, although you have to hunt around for them (a lot is implied or or has to be derived from basic information).

In general, the operation is simply:

Foreach GameTick:  Poll Incoming Messages  Dispatch Messages to Targets  Evolve the World for One Tick  Enqueue Updates to Clients

Now, there are multiple ways of implementing each of those steps. Especially "Enqueue Updates to Clients" has to be handled with care to avoid buffering old data, avoid overloading the client, etc.