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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.