That is, is it possible with a Single-Sign-On tool to give employee "Joe Smith" access to app "SocialMedia App1" for him to do this job. But when Joe leaves the company, can I have complete confidence he does not have the password and there is no need to change it?
Generally, when a user departs, you can never have complete confidence they don't have passwords or other confidential information saved. As a result, your offboarding process needs to have controls for all the contingencies.
There are various systems (e.g. the proprietary OneLogin) that allow you to integrate a corporate identity management service (e.g. Active Directory) with logins to social media sites/other web applications. However, this works similar to LastPass in that it stores a randomly-generated password in a vault; and this password can be intercepted.
The issue is that it is always technically possible, if the user is an administrator to the computer and has access to some technical savvy, to obtain the password.
There are ways to mitigate this: e.g. enable login notifications on Facebook and two-factor authentication. Only setup a non-rooted phone with the correct 2FA token. Still, the user might take steps to migrate the 2FA token to another device, so you can't be 100% confident this system will work.
In the end, the best practice will always be to reset passwords for any and all accounts that the former employee had access to. If the app is directly integrated with a directory service you can be certain that when the directory account is disabled access is denied (e.g. Google+ using OAuth) -- but, if there's separate logins to external sites those will always need to be changed. Even if you're 99% confident that they don't have the password or they won't be logging in, the 1% exception is surely motivation enough to lock things down.
Management of shared identities (like enterprise account on facebook, twitter) would typically fall in the purview of Privileged Identity Management processes. Due to the shared nature of these identity, regular user management process are not applicable and additional processes/scenarios must be considered.
The privileged identity management processes have additional checks and balances to ensure that nobody besides the person working on system knows the applicable password. Typically this involves the authorized person to "checkout" the password, perform the work he needs to do and then "checkin" the password.
If this feels like an overkill from your requirement perspective, I would suggest that
- Identify the facebook (or corresponding shared account) as a service account so that it is not deleted and ownership is transferred to appropriate new owner automatically as part of offboarding process.
- As part of ownership transfer process, you may change the password and update the new owner about the password.
If you have a correct user management process (which includes revocation of access to a centralized authentication database upon leave) then using an SSO for your "SocialMedia App1" which is bound to that centralized authentication mechanism will ensure that he will not be able to connect to that service once his account is disabled.
You could also directly authenticate "SocialMedia App1" against this service (though I guess that it is not under your control and offers SSO)
One option is to use LastPass with Shared Folders. I think this feature requires enterprise license.
Say, you as an administrator create the Shared folder and share it with Joe Smith, then in the settings, you can choose to hide the passwords in the shared folder from Joe.
LastPass has browser Plugins for all major browsers, so when Joe opens the "SocialMedia App1", the username and password are automatically filled in for Joe(The LastPass Plugin can also automatically sign the user in too if setup correctly). In the entire process Joe never sees the password.
(This is just one way to do it)