CIAM
Challenges of CIAM
By Brian Pontarelli
Authentication, authorization and customer identity and access management are a complex mix of use cases and security issues that touch every aspect of your business. Below are a selection of authentication and CIAM challenges that developers and businesses face when they are building applications.
One-Way Password Hashing
Level of risk
Development time
One-way hashing ensures that even if someone gets access to your raw customer data through external hacks or internal theft it is not possible to determine the plaintext user password from the saved encryption.
Complete JWT Support
Level of risk
Development time
Understanding the details of JSON web tokens (JWTs) is critical to support OAuth2 and OpenID Connect. Off-the-shelf libraries can reduce the implementation effort, but developers still must understand how to use the tokens securely beyond the initial login. Properly building, passing and validating JWTs is essential to your application security.
User-Friendly Web UI
Level of risk
Development time
When an application acquires thousands of users and requires active user management, the best login and authentication APIs are little use without an intuitive user interface. Developing a UI that is effective for non-technical moderators and administrators can be one of the most costly and time-consuming aspects of an in-house identity management system.
Prevent Account Theft by Email Change
Level of risk
Development time
A common hack technique for account theft is to wait for a person walk away from their logged in computer, and then quickly change the email address on any open accounts. An effective email change strategy will prevent this type of account takeover and eliminate a high-probability threat.
Regular Security Audits
Level of risk
Development time
Any system that is storing user information, including account credentials, should have regular security audits. These should include network scanning, API fuzzing, professional penetration tests, code reviews, static analysis, and OWASP best practices review.
Server Security
Level of risk
Development time
The servers hosting your identity and management system are always the first target for hackers. As such they should have the highest level of protection. You need to ensure that your servers are locked down. All services that aren't public should not be world-accessible, you'll need secure remote access, you'll want intrusion detection, and many other measures must be taken to ensure your servers are secure. Read our <a href='/articles/security/guide-to-user-data-security'>Guide to User Data Security</a> to learn how to secure your servers.
Registration Verification
Level of risk
Development time
Experienced app developers reduce user on-ramping barriers by allowing customers to start using the app in a provisionary mode until their account is fully verified. Make sure that your registration workflow is tuned to minimize the amount of effort required for a user to sign up.
RSA Key-Pairs
Level of risk
Development time
For additional application security, RSA key-pairs used for signing and verifying JWTs are changed over time. This is sometimes referred to as rolling keys. You'll want to ensure that your systems are capable of rolling keys and have an automated way of notifying other services of these changes. Events and Webhooks are a good way to handle this.
Legal Regulations and Requirements
Level of risk
Development time
GDPR, HIPAA, PCI, COPPA, PIPEDA, etc. There are a plethora of laws and regulations that define how user data should be collected, stored, and managed depending on specific use cases and geographic locations. It is difficult for developers to stay abreast of the most recent changes and best practices.
Granular API Key Permissions
Level of risk
Development time
In less secure applications, API keys for a specific user are given carte blanche access across an entire system. This can provide unrestricted access to all aspects of the system if the API is utilized beyond a private service in a secure network. Security-conscious applications follow the computer security principle of least privilege to reduce and isolate access points and minimize risk. Make sure that your application has fine-grained access controls for its APIs.
Re-establish Mistyped Emails
Level of risk
Development time
Users can easily mistype their email address when updating information, making it very difficult to re-connect their account and correct the email address without direct administrator or support effort. You'll want to ensure your application allows user's to login with old credentials in the event that they changed their email to something invalid.
Account Locking
Level of risk
Development time
When questionable activity appears on an account, security-conscious systems intervene to prevent any further access. You'll want to implement account locking capabilities as well as detection of anomalous login activity.
Configurable Password Strength
Level of risk
Development time
Applications are built with the level of password security that matches current needs. As threats and exploits evolve, apps should be able to change their password strength and schema. You'll want to ensure your applications are using the best password hashing and have a way to upgrade hashes in the event that an exploit for the current hash is discovered.
Brute-Force Login Protection
Level of risk
Development time
One of the most common attack vectors is to repeat login attempts using a variety of password combinations. This is commonly called a "brute-force attack". You'll want to ensure that your login system protects against these types of attacks by locking the login for a user after there have been too many incorrect attempts.
Application Authentication Tokens
Level of risk
Development time
Single sign-on allows customers to login with the same email and password combination across multiple applications, but sometimes you need to provide additional security. Application authentication tokens allow customers to have a unique password that can be used to authenticate one specific situation. This is essential for cases when developers need to hard code authentication into configuration files where they are at more risk of being stolen by hackers.
Role Based Access Control (RBAC)
Level of risk
Development time
Applications require different levels of functionality depending on the user's needs and role: basic user, moderator, administrator, etc. Users often shift between roles as their engagement expands. The most flexible solution is to allow user's to have zero or more roles for each application they have access to.
Full Unicode Character Support
Level of risk
Development time
Limited character sets for usernames and passwords can cause frustration for international users and provide hackers with an easier target for their attacks. You'll want to ensure you allow full unicode support for usernames and passwords. Not only does this provide the most flexibility for users, it also increases the security of the system.
Session Revocation
Level of risk
Development time
Long-lived refresh tokens are commonly used to authenticate a user on frequently used devices without repeatedly requiring their credentials. To stay secure, applications need to track active user sessions across multiple devices, and be able to revoke them when requested either by the user (i.e. Forget My Devices) or the administrator (i.e. user is deleted, disciplined, or other reason account needs to be locked).
Multi-Factor Authentication (MFA)
Level of risk
Development time
MFA is a way to confirm a user's identity with two or more pieces of information, substantially increasing the security of the application. Many MFA strategies take advantage of mobile devices with either SMS messages or an application as the second form of identification.
Full Entropy Password Constraints
Level of risk
Development time
Requiring specific types of characters in a password can make a password stronger, or it can give hackers a template to hack your system. You'll want to allow users to use any combination of characters for their passwords. Just ensure that they aren't using easy to guess passwords or passwords that are too short.
Group Role Based Access Control (gRBAC)
Level of risk
Development time
As applications scale beyond hundreds and thousands of users, managing the roles and access of individuals becomes difficult to manage. Instead of managing roles on individual users, you might consider using groups. Users are added to groups and then the group can be granted a set of roles. This allows all of the users in the group to be granted roles quickly and easily.
Upgradeable Password Hashing
Level of risk
Development time
As computers get faster, brute force hash attacks become easier. Additionally, password hashing algorithms that are secure in 2020 might be cracked in 2023. Upgrading the hash complexity over time is critical to ensure password security stays on top of computational efficiencies and security research.
Enterprise Identity Unification (EIU)
Level of risk
Development time
Consolidating multiple disparate identity databases into one efficient system is a complicated data merge challenge. You'll want to ensure your system provides a way to manage complex merges in the event you acquire users from other sources (such as their a corporate acquisition or new applications with separate user databases).
CORS Support
Level of risk
Development time
Cross-Origin Resource Sharing (CORS) controls access to APIs and resources running in a browser when the resource is not in the same domain. This is a common practice used to increase the security of web-based applications. Developers need to understand and configure CORS to avoid the hack-vulnerable technique of sending all authentication API requests from a domain directly to the domain's backend webservice.
Configurable Password Reuse Policies
Level of risk
Development time
Depending on the data collected and its purpose, information security best practices and many government regulations require that applications be able to prevent a user from re-using previously used passwords. Easy to set up, this is challenging to maintain as password security levels increase to meet evolving threats.
One-Time-Use Tokens with Timeouts
Level of risk
Development time
During short-term interaction and validation processes like registration, forgot password, and email changes, user accounts are extremely vulnerable. Secure applications take advantage of one-time-use tokens with specific timeout values to limit access during these times and protect against the most common account high-jacking techniques.
User Email Verification
Level of risk
Development time
Email verification is a common way to validate new users, limit spam, comply with GDPR rules, and automate registrations. It proves an individual has a valid email address and is able to read and respond to that address. It also provides a security mechanism to ensure the user registering intended to do so, and is not being registered for an application without their knowledge.
User Data Profanity Filtering
Level of risk
Development time
There is a segment of users who take joy in finding new and interesting ways to make your application look bad by using simple or obfuscated profanity in user names and other saved data. You'll want use an advanced profanity filter and moderation tool such as <a href='https://cleanspeak.com'>CleanSpeak</a> to ensure that usernames and profile data are clean.
Scalability and Performance
Level of risk
Development time
As applications gain more users, it takes an increasing amount of system resources to manage registrations, logins, and user activity. This is the worst time to negatively impact a user's impression of your application. You'll need to ensure that your systems can handle growth as well as unexpected load spikes.
Email Templates
Level of risk
Development time
Every CIAM needs to be able to communicate with users to establish, manage and maintain their account and identity. Security features such as setup password, forgot password, and email verification require additional security to ensure new credentials aren't provided in easily captured plaintext format. You'll need an email system that uses templates to personalize messages to users.
Device Trust
Level of risk
Development time
For the best user experience and least login friction, successful applications take advantage of Trust Device capability. This improves adoption of two-factor authentication (2FA) increasing system-wide identity security. Without Trust Device capability, 2FA is often considered too cumbersome because the user needs to provide the 2FA challenge during every login.
Federated Login (Active Directory)
Level of risk
Development time
In many cases, users are required to use their corporate login credentials to access external services. To support this model of authentication, applications need to coordinate a user's identity with an external identity provider such as active directory or GSuite. If you have this requirement, you'll need to correctly implement SAML or OpenID Connect in order to allow these users to login to your applications.
Password Safe Data Import Tools for Migration
Level of risk
Development time
Importing users from a legacy system is challenging and can trigger a poor experience for your users. Successful migrations don't force users to change their passwords, but instead implement a workflow that supports existing passwords and any hashing techniques used by the legacy system. You'll want to ensure that if you are migrating users between systems that you maintain the password hash so that users won't be forced to reset their password.
Social Login
Level of risk
Development time
Many customers prefer to use their existing social accounts to login to applications they use across the web. You'll want to determine if your users will want to login with a social provider such as Google. If that is a core part of your authentication, you'll need to properly implement that social providers login mechanism. In nearly all cases, each social provider has a custom way of handling authentication that you'll have to learn and implement by hand.
Support for Millions of Users
Level of risk
Development time
Web-scale capability is critical to manage the growth of an application and a large influx of users. Registration and user management needs to be able to horizontally scale quickly to maintain a positive user experience and uninterrupted access. Depending on your needs, you'll want to ensure that your authentication solution can quickly and easily scale horizontally with little impact to end-users.
User Search and Segmentation Tools
Level of risk
Development time
A database full of user actions and history is a valuable customer behavior library that can help your application succeed, but only if you have tools to access it. You'll want to ensure that you can search your users in real-time using any attribute on their profile. Elastic search is a great tool for this.
COPPA/Parent Relationship Support
Level of risk
Development time
Applications with users under the age of 13 are required to comply with Children's Online Privacy Protection Act (COPPA). While the security risk is low, monetary fines are high if the application is found in violation. If you have younger users, make sure that you are in compliance with COPPA and that your user backend properly models the relationships between children and parents.
Customizable User Data
Level of risk
Development time
Every application has its own unique data points that are part of the "secret sauce" that drives revenue, but not every CIAM is able to collect and manage this information. You'll want to ensure your application makes it easy to manage global and application-specific custom user data. Avoid complex database migrations when a developer wants to add a new field. You'll also want to index custom data so that it can be used in search queries.
Single Sign-On (SSO) for Multiple Applications
Level of risk
Development time
SSO is a must-have for any CIAM to provide the best user experience for users logging in across multiple applications. You'll want to ensure that you leverage industry standards such as OpenID Connect to implement SSO in your applications.
White-Labeled Identity
Level of risk
Development time
To maintain trust with your customers, your registration and login system should have the same look and feel of your brand across all touch points. Depending on your login system, you might need to write custom themes that capture your brand.
User Reports
Level of risk
Development time
User reports have been required to track the progress of applications since the first bit of software hit the Internet. You'll want to ensure that you have access to common reports such as daily active users, monthly active users, registrations, logins and totals.
User Moderation Tools
Level of risk
Development time
Users don't always follow the rules, and system administrators need to be prepared to deal with any issues that arise. You'll want to ensure that your systems are able to discipline users as needed. This might range from actions such as account locking all the way down to granular actions such as preventing them from commenting.
Email Localization
Level of risk
Development time
With a global internet, your customers can come from any region or country. Communicating with your customers now requires that you are able to send messages in their preferred languages. You'll need to ensure that your email system is able to send localized versions of emails to users based on the language the user specified as their preferred language.
OAuth 2 and OpenID Connect
Level of risk
Development time
OAuth 2 and OpenID Connect are modern authentication delegation patterns that provide a standard way to authenticate and request user information. Even though they are standardized, they are not always simple. Failure to implement these patterns correctly can lead to catastrophic security breaches.