On the simplest level, the server received a username and password and asks the database 'do you have a username and password hash that matches this'. The database then says either yay or nay. That is quick and doesn't require much of a queue. For user experience reasons, this is done with priority, as you don't want a user to wait 5 minutes to find out they mistyped their password.
But, there is often more work that needs to be done before one is actually 'in' the system. For example, are you a first time user. Is your subscription paid. Do you have any new notifications awaiting you. What security access should you be given. What about running any logic that is supposed to run on user log in. All that requires resources before you can be given the welcome screen. As I've mentioned, the 'is the password correct' is done with far higher priority for reasons of user experience, but the rest of this requires sitting in the queue.
For most applications, this is so small a demand that you don't see a queue until you go use a far more demanding part of the application. For many business systems, logging in doesn't require a queue, but running a report does. But it is possible for a system to be under such demand that it doesn't have the resources to immediately display a welcome screen and thus has to put you in a queue until enough resources are ready to handle your request.
One should note that complex systems can require login queue to different parts, even if you don't actually have to re-authenticate. For example, you login to a system, you get put in a queue until enough resources are available to judge your access level, determine notifications, and run background business logic. Then you click on a report button, and get stuck in a short queue until enough resources are available to authenticate you in the report system (using information passed in from the previous system) and return the list of reports you are able to run. Then you click a report, enter the data, and are put into a much longer report queue while you wait for enough resources to run your report.
For online games in particular, there is both a queue to get into the main interface and a queue to get into the game, as the user interface/account management is often separated from the actual game for various reasons (for example, having all your account servers in one location, even if it gives some users greater latency, isn't a problem as 75ms vs. 300ms latency while handling account interactions isn't a big deal, but you want your game servers closer to give the least latency possible because 75ms vs. 300ms is a big deal during game play).