Frequently asked questions
Product & fit
Do my users need to do anything?
No. The check happens silently in the background while the user is on mobile data. They do not see a code, receive a message, or need to take any action. From their perspective, they simply tap login and they’re in.
What happens if a user is on Wi-Fi?
Silent Authentication requires a mobile data connection. If a user is on Wi-Fi, the check cannot be performed. Your app should fall back to your existing OTP or password flow. This is not an error — it is a normal fallback path.
What if no login_hint is provided?
If your app does not send a login_hint, tyntec automatically launches a prompt window for the End User to enter their phone number directly. This is fully supported — tyntec handles the input and proceeds with the network verification.
Can it be used alongside our existing login?
Yes. The most common deployment is as a drop-in replacement for the OTP step. You keep your existing UI, replace the SMS send with a tyntec Silent Auth call, and fall back to OTP when Silent Authentication is unavailable. No redesign required.
Is it more secure than OTP?
Yes. There is no code to intercept, no SMS to redirect via SS7 attack, and no phishing surface. Identity is confirmed at the network operator level, which is significantly harder to spoof than an SMS message.
Technical
What does MobileID mean and should I store it?
MobileID is a unique, network-derived identifier that tyntec generates for each verified user. It is consistent across sessions for the same phone number. You can use it as a stable user identifier — similar to an OAuth sub claim — without storing the phone number itself. It is returned as the mobile_id claim in the access_token JWT.
What does phone_number_verified=false mean?
It means the phone number passed in login_hint did not match the number resolved from the network. This can happen if the user typed a wrong number, or in rare cases due to a network routing issue. Treat it as a failed verification — prompt the user to retry or fall back to OTP.
Why must I validate login_hint against the token response?
This is a security requirement. If an attacker intercepts and modifies the request, they could substitute a different login_hint. By comparing the number you sent with the number returned in the token, you detect any tampering. If they don’t match, reject the session immediately.
Does this work for all mobile operators?
tyntec has integrations with mobile network operators across multiple markets. Coverage varies by geography and operator.
Do we need to change our existing login UI?
Minimal changes only. You need to add the redirect to /oauth2/authorize, handle the callback and token exchange server-side, and add a fallback path for when Silent Authentication is unavailable. The user-facing login screen can stay exactly as it is.