The two aren't exclusive alternatives.
CVCS tools provides strong authorization features.
Some have their own built-in authentication mechanism (SVN with svnserve, RTC and its user registry, Perforce and its P4Admin): they can have their own internal user database, dedicated for their tools.
DVCS tools don't. See "Can we finally move to DVCS in Corporate Software?".
No built-in authentication and authorization mechanism.
DVCS: No authentication:
While CVCS can interface themselves with external authentication sources (like an LDAP), DVCS have no choice but to interface themselves to external authentication sources, using only external processes (
httpd, ... since they own internal lightweight server has no authentication contrary to a SVN
DVCS: No authorization:
If you have access to the repo path (through file, ssh or http), then you have all privileges on it (read, write, delete, ... on any branch).
If you need a finer-grained access control, you need to add an extra layer to the tool (RhodeCode for Mercurial or Gitolite for Git).
Those constraints mean that a DVCS has usually different use cases than a CVCS within a large company.
For instance, I have put in place both, with DVCS used to allow third-party enterprises to collaborate on a restricted shared code-base with the company.
Considering a DVCS allows for cloning a all repo with its complete history, that meant we had to come up with an import-export mechanism allowing us to export and publish in the DVCS only certain part of the CVCS (large) repo, in order for said third-parties to access only what they need to work on.