[SEO Subhead]
This Guidance demonstrates how to implement a secure and scalable one-time passcode (OTP) delivery solution by using AWS with Okta’s identity platform. The Guidance supports multiple languages and communication methods and stores language-specific message templates in a dynamic, scalable database. This enables you to tailor OTP messages based on users’ preferred languages and delivery channels, such as SMS or voice calls. By using this Guidance, you can implement a reliable, flexible, and secure OTP delivery method that helps you accommodate a diverse user base.
Note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
A user initiates sign-in on Okta and is prompted for phone-based authentication. The user chooses SMS or voice delivery to receive the OTP. Okta’s telephony inline hook is activated, creating a JSON web token (JWT) request for OTP delivery through Amazon API Gateway.
Step 2
AWS WAF protects the API Gateway endpoint by applying rules managed by AWS to block malicious traffic. All traffic is filtered through AWS WAF web access control lists (ACL), and requests deemed safe are allowed to pass through to API Gateway.
Step 3
API Gateway first receives the JWT request from Okta. It then invokes a custom AWS Lambda function that acts as an authorizer to validate the JWT token before allowing the request to proceed.
Step 4
The Lambda authorizer is responsible for verifying the integrity and validity of the JWT token. It performs several checks to ensure the token is valid.
Step 5
The Lambda authorizer verifies the JWT token by decoding it, using Okta’s public key to validate the signature and checking the expiration time.
Step 6
If the JWT token is valid, the Lambda authorizer creates an AWS Identity and Access Management (IAM) policy that grants permission to invoke API Gateway.
Step 7
The Lambda authorizer returns the IAM policy to API Gateway. If access is allowed, API Gateway is invoked and forwards the request to the backend Lambda function.
Step 8
If the Lambda function encounters an error or exception while processing the user’s request, it may send the request to an Amazon Simple Queue Service (Amazon SQS) dead-letter queue for further investigation and troubleshooting.
Step 9
If no errors are found, the Lambda function contacts Amazon DynamoDB to retrieve message data based on the user's request details, such as their language preference and their choice of SMS or voice delivery.
A DynamoDB table stores message templates tailored for various languages and communication methods. The Lambda function retrieves the appropriate message template that matches the user’s request details.
Step 10
The Lambda function retrieves the message data and uses it to create a personalized message for the user. The message includes the OTP authentication code. Depending on the user's chosen method of communication, the function formats the message accordingly.
Step 11
AWS End User Messaging then sends the message to the user. For SMS, it sends a text message directly to the user's phone. For voice delivery, it converts the text into a voice message and delivers by phone call.
Step 1
A user initiates sign-in on Okta and is prompted for phone-based authentication. The user chooses SMS or voice delivery to receive the OTP. Okta’s telephony inline hook is activated, creating a JSON web token (JWT) request for OTP delivery through Amazon API Gateway.
Step 2
AWS WAF protects the API Gateway endpoint by applying rules managed by AWS to block malicious traffic. All traffic is filtered through AWS WAF web access control lists (ACL), and requests deemed safe are allowed to pass through to API Gateway.
Step 3
API Gateway first receives the JWT request from Okta. It then invokes a custom AWS Lambda function that acts as an authorizer to validate the JWT token before allowing the request to proceed.
Step 4
The Lambda authorizer is responsible for verifying the integrity and validity of the JWT token. It performs several checks to ensure the token is valid.
Step 5
The Lambda authorizer verifies the JWT token by decoding it, using Okta’s public key to validate the signature and checking the expiration time.
Step 6
If the JWT token is valid, the Lambda authorizer creates an AWS Identity and Access Management (IAM) policy that grants permission to invoke API Gateway.
Step 7
The Lambda authorizer returns the IAM policy to API Gateway. If access is allowed, API Gateway is invoked and forwards the request to the backend Lambda function.
Step 8
If the Lambda function encounters an error or exception while processing the user’s request, it may send the request to an Amazon Simple Queue Service (Amazon SQS) dead-letter queue for further investigation and troubleshooting.
Step 9
If no errors are found, the Lambda function contacts Amazon DynamoDB to retrieve message data based on the user's request details, such as their language preference and their choice of SMS or voice delivery.
A DynamoDB table stores message templates tailored for various languages and communication methods. The Lambda function retrieves the appropriate message template that matches the user’s request details.
Step 10
The Lambda function retrieves the message data and uses it to create a personalized message for the user. The message includes the OTP authentication code. Depending on the user's chosen method of communication, the function formats the message accordingly.
Step 11
AWS End User Messaging then sends the message to the user. For SMS, it sends a text message directly to the user's phone. For voice delivery, it converts the text into a voice message and delivers by phone call.
Get Started
Deploy this Guidance
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
This Guidance uses Lambda, API Gateway, and Amazon SQS to implement a serverless approach that provides scalability, flexibility, and ease of maintenance. For example, Lambda right-sizes its functions based on the minimum amount of memory and CPU required to complete their tasks. If one function encounters an error or exception, Lambda sends the failed event to an Amazon SQS dead-letter queue for further investigation and troubleshooting. Additionally, Amazon CloudWatch provides critical monitoring for proactive issue detection and resolution, supporting operational excellence.
-
SecurityRead the Security whitepaper
This Guidance enhances security by implementing strong access control and data protection mechanisms. AWS WAF protects the API Gateway endpoint by applying managed rules to block malicious traffic. A custom Lambda function acts as an authorizer to validate JWTs before allowing requests to proceed. This authorizer decodes the JWT (which uses Okta’s public key to validate the signature) and checks the expiration time to confirm token validity. IAM manages access permissions, using the principle of least privilege to make sure that only authorized users and services can access resources. Additionally, AWS Key Management Service (AWS KMS) encrypts sensitive data, such as OTPs, and it encrypts CloudWatch logs to protect the confidentiality of recorded information.
-
ReliabilityRead the Reliability whitepaper
This Guidance supports reliability through distributed workloads, error handling mechanisms, durable data storage, and a highly available messaging service. It distributes Lambda functions across multiple Availability Zones (AZs), helping you avoid the risk of a single point of failure caused by an AZ outage. The Amazon SQS dead-letter queue provides reliable message delivery by handling errors and retries, and it enables you to investigate any failed message processing. Additionally, DynamoDB offers a highly available and durable data store for user preferences and message templates. Finally, AWS End User Messaging enhances reliability by providing a highly available and scalable messaging service for SMS and voice communication.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
This Guidance uses serverless services so that you can quickly retrieve and process data without the need to manually manage infrastructure. Lambda scales automatically with your workloads and right-sizes its functions to achieve efficient resource use, and DynamoDB facilitates quick and efficient data retrieval. AWS End User Messaging converts text to speech on-demand for voice calls.
-
Cost OptimizationRead the Cost Optimization whitepaper
This Guidance minimizes costs by using on-demand, pay-as-you-go services. DynamoDB provides a flexible pricing model, and its on-demand capacity mode adjusts to workload volume, helping you reduce costs. For Lambda, you only pay for the compute time you consume, and its scalability helps you optimize costs.
-
SustainabilityRead the Sustainability whitepaper
This Guidance uses scalable, on-demand services to reduce the environmental impact of your cloud workloads and minimize waste. Lambda automatically scales on demand, helping you avoid the use of idle resources. Additionally, DynamoDB provides an on-demand mode that scales with the workload, delivering efficient resource use. Both services align with best practices for minimizing hardware usage and energy consumption.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.