I think the answer is ‘no’ or ‘only under special circumstances’ (see Exceptions below) but would be interested in your comments.
By ‘own credential management’ I mean have own store of user names AND passwords and code to challenge users for the credentials, create them, reset passwords, etc. The alternative I am recommending is for the application to use an out-of-the-box secure token server (STS) like AD/ADFS, Azure AD or one of a plethora of 3rd party solutions and standard protocols like WS-Fed, SAML-P or OAuth to obtain user identity.
Benefits
Implementing and managing your own credential store obviously involves development, maintenance and operational costs. Furthermore, handling passwords in your own code also increases the security risk of the application. It also increases the user’s own risk by preventing single sign on and requiring the user to keep separate credentials for each application. At the same time there are a number of other reasons why delegating authentication to an STS is a better solution:
1. Enables single-sign on for all applications sharing the STS (and even those who can federate to it indirectly via another STS).
2. Makes the application more portable to other environments already using an STS.
3. For multi-tenant applications, makes it easier to add new tenants or partners and integrate their existing identity infrastructure.
3. Management of authentication process is done in one place rather than in each application, making it easier to for example define new policies for when multi-factor authentication should be used.
4. Tenants and partners can do their own user management, possibly integrated with their human resources systems; their own password resets.
Myths
In working with customers in this area I have encountered a number of myths, which hamper adoption of standards based authentication. (Some of these are general, some specific to Azure AD or ADFS).
1. “My application makes authorization decisions based on some custom data I keep in a database so I can keep the passwords there as well” – rather delegate authentication to an STS and then augment the incoming claim set with what you have in the database to enable authorization. You can then remove just the password and related credential handling from your application.
2. “My SQL is already paid for. Why should I pay for Azure AD or ADFS?” – actually, Basic services in Azure AD (which includes authentication) are free. ADFS is a role enablement in Windows Server 2012. Also see some of the costs of own solution mentioned above.
3. “I don’t have AD on premises, therefore I can’t use Azure AD” – not true: you can use Azure AD as a stand-alone STS.
4. “I don’t have ADFS on premises, therefore I can’t use Azure AD” – not true: you can enable data sync from AD to Azure AD an use the latter as an STS.
5. “My application is not running in Azure therefore I can’t use Azure AD” – not true: Azure AD is an STS, exposing standard, publicly accessible authentication protocols.
Exceptions
Here are some situations where outsourcing authentication to an STS may not work:
1. Application is using SQL with windows authentication using the user’s (rather applications) token (well, the application is still NOT handling the user credentials)
2. Application/organization has some unusual, special requirements for user name or passwords format that is not supported by out-of-the-box STS’.
3. Application is deployed to some locked down environment with no access to other servers or public internet (an therefore local or public STS’).
4. Application does not involve human interaction and simple symmetric key solution is adequate.