Loading post…
OktaMaurice SharpExplainer
Approaches to keep sending OTP over SMS... for now
Summary
SMS and voice OTPs remain broadly applicable for identity verification, but the post argues they should eventually be replaced because SIM swapping, phishing, uncontrolled secret-delivery channels, device-linking gaps, and slower logins weaken them. Until then, Okta will require organizations to bring their own telephony provider, using a telephony inline hook to send codes and report outcomes. The implementation can be built in-house, outsourced, or delegated to a managed service, with regional regulations, traffic peaks, reliability, branding, security, and available resources shaping the choice. A hook has three seconds to return success or failure before Okta’s heavily rate-limited failover sends the message; teams must also secure endpoints and API keys, monitor logs, and handle vendor or delivery failures.
Context
SMS and voice authentication can help verify users broadly, but the post identifies SIM swapping and other weaknesses that make these methods less secure than authenticator apps and FIDO2. It describes how organizations can continue sending OTPs while preparing to migrate away from SMS and voice.
Approach / What changed
Organizations can implement an Okta telephony inline hook with their own provider or providers, outsource that implementation, or use a managed service. The hook receives information from Okta, constructs a request to the telephony vendor, and returns the delivery status in Okta’s expected JSON format. Teams must account for regional rules, volume and reputation limits, three-second timeouts, failover behavior, endpoint security, monitoring, and vendor management.
Takeaways
Okta’s telephony inline hook must return a success or failure result within three seconds; otherwise, Okta may send the message through its own providers, where sends are heavily rate-limited.
Regional SMS requirements can include business or sender-ID registration, short-code use, supported character formats, and message-length limits. Vendor coverage and capabilities may differ by region.
A custom implementation provides the most control but requires product, design, engineering, testing, and project-management resources. Managed services reduce technical work but still require vendor management and monitoring.
FAQ
What happens when the telephony hook fails or takes too long?
Okta takes over sending the message when the hook returns a failed status or the three-second timeout passes. Those failover messages are heavily rate-limited, and logs must be searched to determine when sends started failing.
Can an organization prevent Okta from failing over to its own providers?
Yes. An organization can always return a successful result or request that Okta disable failover, but then it must handle failed sends itself, potentially with more complex server code and multiple vendors.
What are the main options for continuing to send OTPs?
The hook can be implemented internally with one or more telephony providers, implemented by a consultant, or handled through a managed service. The choice depends on regions, expected traffic and peaks, reliability, branding, security needs, and available resources.
Source and freshness
- Source
- developer.okta.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.