A central point in building a web application is authentication and authorization. The servlet specification provides already a mechanism for both, authentication and authorization: The authentication is done by specifying a authentication method and by defining URL spaces that require an authentication. A user can be in several roles and this role information can be used for authorization. The "real" authentication, how to query the used user database, is out of the scope of the specification. This is done by so called realms that are either provided by the used servlet engine or can be developed. Switching from a database to let's say a LDAP system requires no changes to your web application, you just have to change the used realm.
The authentication mechanism provided by Cocoon Auth is basically very similar but extends this mechanism in many ways. The mechanism described by the servlet specification has two major disadvantages for a Cocoon web application: the configuration of the protected areas is in the web.xml which is "outside" of Cocoon. If you look at the usual Cocoon configuration, the sitemaps, you will not see that your pipelines are only accessible for authenticated users. Furthermore, internal pipeline calls are not protected by the servlet engine as they happen inside Cocoon. In addition, the realms are proprietary, they tie your application to the used servlet engine/application server.
Cocoon Auth introduces the notion of an application: this is a web application built with Cocoon that shares the same user base. An application can have an own configuration etc. For authentication, so called security handlers are used (similar to realms). A security handler provides a flexible but decoupled way of authenticating users. For the application it doesn't matter if the users are stored in a database, in a LDAP system or in some obscure files in the file system.
Changing the user database can be done by just changing the used security handler. This allows to use a different authentication mechanism during development than in production. All you have to do is change the configuration and the application uses the different system.