Short validity and one-time use
Use a short, clearly communicated validity period. A verified, replaced or expired code must never be accepted again.
SMS API / MFA and 2FA
An extra verification step via SMS.
Ask the user for a password, followed by a time-limited one-time code sent by your server through the SMS API. SMS is a broadly accessible added layer, but it is not phishing-resistant.
Server-side flow
From password to verified session.
The browser must never call the SMS API directly or receive the API key. Your backend owns the complete code lifecycle.
- 01
Check the first factor
Verify the user’s password on the server. Do not start the SMS step for an unknown or incorrectly authenticated account.
- 02
Generate and store securely
Generate the code with a cryptographically secure random number generator. Store only a hash with the user, purpose, expiry and attempt count.
- 03
Send through the SMS API
The backend sends the code with its protected API key. Use a short validity period, omit sensitive information from the message and bind the code to one sign-in.
- 04
Verify once
Compare the submitted code on the server. Consume it after a successful check and invalidate it when its time or attempt limit has passed.
Security controls
Protect both the code and the sending flow.
Attempt limits
Limit incorrect code attempts per challenge. Lock or replace the challenge when the limit is reached.
Rate limiting
Limit requests and resends per account, phone number, IP address and time window. Add progressive delays where appropriate.
Secure code handling
Use cryptographically secure randomness, hash codes at rest, and never log codes, API keys or full phone numbers.
Delivery status
Use delivery-report webhooks for operations and troubleshooting. Delivered does not mean that the correct person read the SMS or authenticated.
Recovery and alternatives
Provide secure recovery routes and let users enrol a stronger method. Treat phone-number changes as sensitive actions.
Integration principle
Secrets stay on the server.
The client asks your application to start an MFA challenge. The backend checks policy, generates the code, stores its hash and calls the SMS API. During verification, the backend checks the code, expiry and attempts before issuing a session.
- 01ClientRequests an MFA challenge
- 02Application serverPolicy, code, hash and attempts
- 03iP.1 SMS APISends SMS and reports status
- 04Application serverVerifies the code and creates a session
Frequently asked questions
MFA and 2FA via SMS.
What is the difference between MFA and 2FA?
2FA uses exactly two factors. MFA can use two or more. A common SMS flow combines something the user knows, their password, with access to the phone number that receives a one-time code.
Is SMS-based MFA phishing-resistant?
No. SMS codes can be exposed to phishing, social engineering and phone-number takeover. Passkeys and security keys provide phishing-resistant authentication, while authenticator apps are also a stronger choice for many use cases.
How long should an SMS code remain valid?
Use a short validity period suited to the user flow and delivery conditions, typically a few minutes. The code must also be consumed after successful verification and expire after too many incorrect attempts.
Should the browser or app call the SMS API?
No. Call the API from your backend so the API key, code generation, storage, rate limiting and verification remain on the server.
Does delivery status mean the user is verified?
No. A delivery report describes the message transport status. The user is verified only after your server accepts a valid, unused code for the correct challenge.
Get started
Build the SMS step with an API account.
Read the documentation, try a payload locally and then create an account for your server-side integration.