Understanding AEM Login Behavior

The CRX Login Module confirms authentication using a login token. This token is stored as a node in the jcr named under a node named .tokens under the logged-in user’s node (/home/users/user). The name of the specific login token is the date/time of the login. For instance, for admin the path might be:

/home/users/admin/.tokens/2015–04–22T10.57.34.180–04.00
The value of the token is also stored in the browser as a cookie named login-token. Whenever a request comes in, the cookie value and the token in the repository are compared.

In more advanced setups with multiple authors or publishers, the login cookie and login token node are only created on the specific AEM install the user logs into. So, if you have a setup with two authors and two publish servers and the user logs into author 1, their login is only valid on author1. Loading author 2 or the two publishers (for paths that require login like crx/de lite) will require re-authentication.

See this page for more details: Token authentication and token management

If you enable sticky sessions on the dispatcher, all requests by a particular client are always directed to the same instance of author/publisher — whatever the dispatcher is in front of.

There is documentation on the Oak/crx3 website on Oak’s token module.

Here is documentation on the way Sling handles authentication.