Creating great authentication experiences with Amazon Cognito and Authsignal

By: David MacDonald, Solutions Architect – AWS
By: Justin Soong, Founder & CEO – Authsignal
By: Ashutosh Bhadauriya, Developer Experience Engineer – Authsignal 

Authsignal

Authentication needs to be both secure and user-friendly. Users expect smooth, seamless experiences while businesses require strong security controls to protect accounts and transactions from fraud. In this post, we’ll explore how Amazon Cognito and Authsignal work together to create great authentication experiences that adapt to user context and business needs. Learn how non-technical business users can configure and optimize authentication flows throughout the user journey to manage both fraud and user experience.

Choosing the right authentication approach

Authentication can rely on three fundamental factors:

• Knowledge: Something you know (such as a password)
• Possession: Something you have (such as a security token)
• Inherence: Something you are (such as a fingerprint)

Combining these factors enables multi-factor authentication (MFA), which helps mitigate threats such as credential stuffing. Common implementations pair knowledge factors (passwords) with possession factors (one-time passwords (OTPs)). When selecting authentication methods, consider:

• Assurance: how difficult it is for someone other than the legitimate user to use or copy the authentication method
• Friction: how much effort users need to spend to complete the authentication process
• Cost: initial setup costs, ongoing operational expenses (such as SMS message fees), and maintenance requirements
• Availability: whether users have reliable access to the authentication method across different devices and locations

Your business needs to balance authentication methods against both risk tolerance and business needs. For example, high-value financial transactions or sensitive data access might warrant high-assurance authentication methods such as hardware security keys despite their increased friction and cost. However, lower-risk activities like viewing public account information might only require basic authentication methods to maintain user convenience.

Businesses also need to adapt as authentication method effectiveness evolves with technology and threats. For example, passkeys use public-key cryptography to combine possession (device bound) with inherence (biometrics), enabling low-friction passwordless authentication. Meanwhile, traditional methods like Short Message Service (SMS) OTP have become less secure as interception techniques advance.

Businesses can maintain strong security while minimizing friction through adaptive authentication. This approach adjusts authentication requirements based on risk signals such as:

• Device characteristics: new or unfamiliar devices, browser fingerprints, and operating system integrity
• Location patterns: unexpected countries, unusual locations for the user, and IP reputation
• Behavioral patterns: sign-in velocity, unusual times of day, and abnormal navigation patterns
• Transaction patterns: amount thresholds, new recipients, and unusual merchant categories
• Session attributes: connection type, virtual private network (VPN) or proxy usage, and session duration and activity
• Account history: previous suspicious activity, account age, and historical transaction patterns

For example, sign-ins from new devices in unexpected locations might trigger additional steps such as a push notification for authentication through your mobile application, while routine access patterns follow a streamlined flow.

However, authentication can extend beyond the initial sign-in step. Applications can benefit from a more dynamic approach to security.

The right authentication method at the right time

Single sign-in authentication requires both high-assurance authentication methods and robust session management to protect against threat actors who might attempt to intercept authenticated sessions. However, forcing users to complete high-assurance authentication steps every time they sign in creates unnecessary friction—imagine requiring a hardware security key just to check your account balance. A more effective approach implements contextual authentication throughout the user journey, balancing security and user experience based on the sensitivity of each action. This lets users start with streamlined authentication for basic access, then complete additional authentication only when attempting higher-risk actions such as large payments or changing security settings.

You can enhance this approach by incorporating risk signals and transaction information to determine the most appropriate authentication method for each user action. High-value actions combined with suspicious signals might require stronger authentication methods. For example, when a user attempts a bank transfer over $1,000 from a new country, the application requires hardware token authentication before proceeding.

By combining adaptive and continuous authentication, businesses can implement low-friction sign-in processes when risk signals permit, while enforcing additional authentication requirements for subsequent high-value actions based on both signals and business risk tolerance.

But how can you implement adaptive and continuous authentication in your application to create great authentication experiences? Let’s explore how to architect a solution to this challenge.

Architecting for adaptive and continuous authentication

A robust adaptive authentication system combines user actions, risk signals, and business rules to determine appropriate authentication requirements at the right time in the user journey. Figure 1 illustrates this architecture, where an authentication rules engine processes user actions (like sign-in attempts and transactions), risk signals, and transaction data to determine the necessary authentication methods. Key authentication decision points might include:

• Initial sign-in attempts
• High-value transactions
• Security setting changes
• Access to sensitive data
• Account recovery processes

Figure 1: User actions, including sign-in, are combined with signals to trigger a rules engine to decide on the right authentication method before allowing the user to proceed

For this architecture to effectively serve your business needs, it should include the following characteristics:

• Business-friendly configuration: The rules engine must be configurable by business users who understand risk tolerance and user impact, not only developers. While developers implement the initial integration, business users should be able to adjust authentication rules without code changes. For example, a fraud analyst should be able to lower transaction thresholds or strengthen authentication requirements for specific regions in response to emerging threats.
• Extensibility: The system must evolve alongside both emerging threats and authentication technologies. This means building a flexible architecture that can incorporate new signal sources ranging from basic IP address validation to sophisticated device fingerprinting and behavioral analysis. As authentication technology advances, your system should readily adopt new methods like WhatsApp OTP without major architectural changes. Finally, it must support custom business logic and risk models that reflect your organization’s unique security requirements and risk tolerance.
• Observability: Effective authentication management requires clear visibility into system behavior and outcomes. Business users need detailed insights into authentication patterns across different methods, helping them understand how users interact with security measures. They should be able to analyze which rules are triggering and how effectively they mitigate risks. Understanding user friction points and drop-off rates helps optimize the balance between security and usability. Additionally, comprehensive monitoring helps identify emerging fraud patterns and anomalies, enabling proactive security adjustments before they impact your business significantly.

Now that you know the required characteristics, how can you build an adaptive and continuous authentication system on AWS?

Better together: Amazon Cognito and Authsignal

Authsignal builds on the Amazon Cognito customer identity and access management (CIAM) user pool service by providing its own suite of authentication methods. Amazon Cognito sends authentication requests to Authsignal’s rules engine during sign-in, where the engine selects which Authsignal authentication method to present. As shown in Figure 2, your application also sends ongoing user actions, transaction data, and user signals to Authsignal’s rules engine. The engine makes authentication decisions based on where the user is in their journey, enabling adaptive and continuous authentication. This integration creates a system that balances security with user experience.

Figure 2: Authsignal integrates with Amazon Cognito to drive authentication at all stages of the user journey

The suite of authentication methods offered by Authsignal gives additional options for adjusting the balance between assurance, friction, cost, and availability. Methods like WhatsApp OTP offer a cost-effective alternative to SMS authentication while also reducing interception threats such as SIM swapping. High assurance biometric verification incorporating liveness detection gives businesses options to mitigate evolving deepfake threats.

You can integrate Authsignal with Amazon Cognito at any point — whether you’re starting with a new Amazon Cognito user pool or extending your existing one. For adaptive authentication during sign-in, you can continue to use Amazon Cognito Adaptive Authentication, so that you can configure your user pool to block suspicious sign-ins or add second-factor authentication based on risk levels. Alternatively, you can use Authsignal’s Amazon Cognito integration to select from Authsignal’s suite of authentication methods based on user signals and your own business rules. You can then integrate with Authsignal’s pre-built UI to progressively enhance security by adding continuous authentication for specific high-risk actions after sign-in. This flexible approach preserves your existing Amazon Cognito implementation while strengthening authentication controls where they matter most.

After being integrated, Authsignal’s no-code rules and policy engine can be used to define conditional logic based on signals and transaction data that drives the right level of authentication for a given action. This gives your non-technical business users the ability to update thresholds and mitigate risks without requiring developers to update code. And with a unified user timeline that displays all authentication activities and outcomes, your users can analyze authentication patterns and optimize policies based on real-world usage data.

Conclusion

Creating great authentication experiences requires balancing security and user experience throughout the user journey. By combining the robust CIAM capabilities provided by Amazon Cognito with Authsignal’s authentication service, businesses can implement continuous and adaptive authentication that evolves with their needs. Ready to enhance your authentication experience? Get started with Authsignal in AWS Marketplace today.

.

.

Authsignal – AWS Partner Spotlight

Authsignal provides drop-in passwordless authentication, passkeys, biometrics, and adaptive MFA without the complexity of migrations, development overhead, and operational costs of building from scratch.

Contact Authsignal | Partner Overview | AWS Marketplace