A consequence of which to be aware when using an AuthUserFile is the difference between that AuthUserFile's mapping of system IDs to names, and the mapping in /etc/passwd. This may catch some system administrators unawares when they go to check the ownership of files uploaded by some user whose account is defined in an AuthUserFile, and find those files being reported as being owned by different users and/or groups by /bin/ls. Keep in mind that /bin/ls is using /etc/passwd, not the AuthUserFile. This issue crops up with any alternative account information source, not just AuthUserFiles.
If you are using the same UID/GID for your users, e.g. in a mass hosting environment, one trick you might like to do is make all of the files, as listed by the server, appear to be owned by the logged in user. This is done using the DirFakeUser and DirFakeGroup directives, like this:
# make listed files appear to be owned by the logged-in user DirFakeUser on ~ DirFakeGroup on ~
These directives are purely cosmetic, and in no way change the real ownership of files. This may cause some confusion on the client side in some cases, if the user sees a file that is reported to be owned by them, and the permissions on the file show user access is allowed, and yet the client is unable to access the file. HideNoAccess can help in situations like this.