De-Provisioning Users
Heya,
Let's talk about deprovisioning users; that is removing them from your identity store.
In an IAM system, with an employee focus, you typically de-provision users when an employee leaves. You don't want them to have access to the systems and software they used while they are an employee. Whether they are on long term leave, retired or depart to another employer, continued access to work systems doesn't make sense.
CIAM systems are different, especially when they allow for self-service registration. In that context, users create their own accounts to gain access to applications or their data.
You rarely, if ever, want to delete these accounts. They don't cost much to maintain, they only have access to their own data and allowed functionality (assuming you've set up permissions correctly), and their owners might pay you money, or otherwise be valuable.
You can possibly even "shake the tree" by reminding people they have an account with you and might want to login to access whatever value you are providing. (Test this with a subset of users, as such messages may or may not be welcome.)
This difference from IAM systems has ramifications.
The first is that while you don't want to delete the account, you must be able to disallow access. That could be temporary, such as if someone is past due on their account. Or it might be permanent, such as if they have cancelled the service but you want to maintain their data for a while.
Make sure your CIAM solution can let you lock and unlock user accounts. Additional nice related features are the ability to lock an account for a fixed period of time and to manage these by API. The latter lets you drive account locking via business logic.
However, you need to allow full, permanent account deletion if the user requests it. While the business using the CIAM system may want to maintain user data forever, there are legal requirements to allow users totally delete their account. The GDPR is chief among these, but the right to be forgotten is becoming more and more prevalent.
Another consideration is that long lived customer accounts mean that you must allow users to change their login credentials. Not just their password, but their login identifier. Even if an account lasts for years, people may change their phone number or email address and want to be able to access their data and your app functionality. If you use a username that doesn't have communication ability, you probably have secondary attributes which do.
You need to make sure you do this securely. The most scalable and cost-effective way to do that is to send a message to both accounts about the identifier change. The original account should have to take some action to enable the change (entering a code, clicking a link).
If the change has significant impact, such as controlling access to money, you should require real-world interaction, such as sending a letter with a code to a known address that is provided before the identifier change can occur.
You also need to consider the use case of a forgotten or inaccessible login identifier. These can be handled in different ways:
Forgotten identifiers can be retrieved by asking the user to provide additional information.
Inaccessible identifiers, such as when a user registers with a work email account that is no longer available, are more complicated and may require a customer service interaction. Make sure you have a process which verifies the customer’s identity.
Also, think about removing bogus accounts. If you allow users to sign up, some will enter the wrong information, either by accident or with malicious intent. While you can require verification (though you should watch out for email signup attacks), you then will want to clean up unverified accounts to allow others to sign up with that same identifier and to keep your user database to a reasonable size. This is especially important if you’ve been registration-bombed.
In the end, when you let users create their own accounts, you still have de-provisioning considerations, but they are radically different than that of typical IAM systems.
Cheers,
Dan