sssd is probably the more "forward thinking" option to go with. To that extent, the other answers are correct. That said, sssd does not completely supersede the features of nslcd, contrary to popular opinion.
The primary (situational) advantage of nslcd over sssd is that you can write a custom authz query with parameter substitution:
This option allows flexible fine tuning of the authorisation check that should be performed. The search filter specified is executed and if any entries
match, access is granted, otherwise access is denied.
The search filter can contain the following variable references: $username, $service, $ruser, $rhost, $tty, $hostname, $dn, and $uid. These references
are substituted in the search filter using the same syntax as described in the section on attribute mapping expressions below.
For example, to check that the user has a proper authorizedService value if the attribute is present: (&(objectClass=posixAccount)(uid=$username)
The default behaviour is not to do this extra search and always grant access.
The last time I checked the sssd docs (within the last six months), there was still no replacement for this capability. So it really depends on whether this feature is important enough to put aside the benefits of sssd's consolidated solution.