Authy Users
As of November 2022, Twilio no longer provides support for Authy SMS/Voice-only customers. Customers who were also using Authy TOTP or Push prior to March 1, 2023 are still supported. The Authy API is now closed to new customers and will be fully deprecated in the future.
For new development, we encourage you to use the Verify v2 API.
Existing customers will not be impacted at this time until Authy API has reached End of Life. For more information about migration, see Migrating from Authy to Verify for SMS.
Before you can secure a user with the Twilio Authy API, you need to create a user
. The API requires you set an email, phone number and country code for each user.
When a user is first created, you will receive an authyid
which you must then store with the user's profile in your own database. Do not lose this ID - you will use it every time you wish to authenticate a user!
Your users can change their phone number registered with the API without your knowledge by using the Authy Mobile or Desktop Application. They may also use the Authy.com phone change security review. You can get webhooks of when this phone number changes via our Webhooks API.
A user may have multiple email addresses but only one phone is associated with each authy_id
. Two separate API calls to register a user with the same device and different emails will return the same authy_id
and store both emails for that user.
POST https://api.authy.com/protected/{FORMAT}/users/new
Parameters
Name | Type | Description |
---|---|---|
user[email] | String (required) | More than one email can be stored per AuthyID, but only the initially created email will display in the Dashboard until it is removed. (📇 PII ) |
user[cellphone] | String (required) | Foreign key for the AuthyID (the AuthyID will be the primary key going forward). You can use dashes, periods, spaces or nothing to separate parts of the cell phone number. (📇 PII ) |
user[country_code] | String (required) | Numeric calling country code of the country Eg: 1 for the US. 91 for India. 52 for Mexico. See: Country code list dropdown (🏢 not PII ) |
send_install_link_via_sms | Boolean (optional) | Enable or disable an sms message with a link to download the Authy App. See Sending Install Link for detailed behavior. Default can be set from the console. (🏢 not PII ) |
Response
Email and phone number must be valid for the request to succeed. An invalid request will produce the following error response:
{
"message": "User was not valid",
"success": false,
"errors": {
"email": "is invalid",
"message": "User was not valid"
},
"email": "is invalid",
"error_code": "60027"
}
Sending Install Link
The send_install_link_via_sms
parameter will override behavior set in the console. Check your application's settings. Note: the parameter is ignored and no install link will be sent if the user has synced a device with the Authy servers in the previous 90 days. You can see last_sync_date
for a user's devices via the User Status endpoint.
If you want to send an install link regardless, we recommend using Twilio Programmable SMS (note: requires a Twilio Phone Number). Include the URL https://authy.com/download/ which will autodetect the device type and redirect the user to the appropriate download link. See the SMS docs for more information.
[Optional] Allow user to set up other authenticator apps like Google Authenticator
Enrolling a user (if you use the same phone number they used to sign up for the Authy App) automatically adds your application to their Authy App. You do not need to do any additional work to support TOTP tokens in the Authy app. To support additional Authenticator apps, like Google Authenticator, display a QR code to your users that contain a compatible TOTP secret. The API will return a link to a valid QR code. Instructions for generating that QR code are in the One-Time Passcodes reference documentation.
Add a user without providing email or phone number
You might not have the email and the phone number of the user, or if you do, you might not want to share it with Twilio for compliance reasons.
For those cases you can use our Authy App based onboarding flow. The end user must have the Authy App installed and registered, meaning the end user has already provided their phone number and email to us.
This feature is only supported in the following versions of the Authy App. End users will have to update their mobile applications to the following versions:
- iOS 22.4+
- Android 23.8+
Create a JWT
First, create a JWT. The token will be used to tie the end user's Authy ID to your application. The token must:
- Follow RFC 7519.
- Be signed with your application's Production API Key found in the Twilio console.
- Contain the following:
Payload
{
"iss": "{authy_app_name}",
"iat": {issue date in NumericDate},
"exp": {expiration date in NumericDate},
"context": {
"custom_user_id": "{custom_user_id}",
"authy_app_id": "{app_authy_id}"
}
}
Header
HS256 is the only algorithm supported.
{
"alg": "HS256",
"typ": "JWT"
}
iss |
The issuer param in the JWT payload MUST be the Application name, other value will raise an error in the validation. |
iat |
The date the JWT is issued. The difference between iat and exp cannot be more than 15 minutes. |
exp |
The expiration time of the JWT. Used to prevent the JWT from being reused in the future. Maximum expiration time allowed is 15 minutes after the current time. |
custom_user_id |
Provided by you, uniquely identifies a user. We are not expecting PII or any sensitive data, so please do not provide phone numbers, emails, SSN, or other identifying information. If you only have PII to identify your users we recommend to either: • Create a de-identified ID like a UUID • De-identify the PII by sending us the HMAC of the PII. Use URL safe Base64 encoding. |
authy_app_id |
The application id can be retrieved from console by going to Applications selecting the Application, and browsing to settings. |
During development, you can validate your JWT using https://jwt.io/. The example can be found here.
Create a QR Code
Next, create a QR string with the following format:
authy://account?token={JWT}
Generate the QR Code from the transaction string
Note: we do not recommend storing the QR code since it can potentially leak sensitive data. Instead, we recommend:
- Sending the QR code as a base64 encoded image in your HTML
- Generating the QR code from your application with a library like github.com/skip2/go-qrcode. For testing, you can use an online generator like https://www.qr-code-generator.com/.
After the QR code is generated display it so your user can scan it with the Authy App.
Keep in mind the QR codes expire, so don't display it for more time than the assigned expiration. The mobile device requires internet connectivity to complete the flow.
No-PII Registration: Get the User's Authy ID
After the end user scans the QR code there are two ways to get the user's Authy ID (required for subsequent verification challenges).
- Poll registration status
- Subscribe to a registration webhook
1. Poll registration status
GET https://api.authy.com/protected/{FORMAT}/registrations/status?custom_user_id={CUSTOM_USER_ID}
URL
Name | Description |
---|---|
FORMAT String |
The format to expect back from the REST API call. json or xml . |
CUSTOM_USER_ID String |
ID provided by you to uniquely identify a user. (🏢 not PII ) |
Response Parameters
Name | Description |
---|---|
status String |
Possible responses: "pending", the user didn't scan the QR code yet. "expired", the received JWT was expired, it was either created with a short duration or the user took to long to scan. "completed", the user was successfully added. Make sure you keep your time in sync with an NTP server. |
authy_id Number |
Uniquely identifies a user in the Authy API. Use this ID to call other Authy API endpoints. |
2. Subscribe to a registration webhook
You can subscribe to a webhook that will notify you in real time when the registration is successful or not.
The payload for event user_registration_completed
:
```{ "method": "POST", "params": { "events": [ { "event": "user_registration_completed", "time": "2019-04-09T22:26:10.503Z", "objects": { "app": { "b_custom_code_allowed": false, "b_custom_message_allowed": false, "s_account_sid": "AC5f123456eabfa99ee3441ef1e84ad528", "s_device_app": null, "s_errors": "", "s_id": "54321", "s_name": "Application Name", "s_type": null }, "registration": { "s_app_id": 54321, "s_authy_id": 123456, "s_custom_id": "885de433faedf8475426f11baeee2424f88fd935" }, "user": { "as_authy_ids": [ "123456" ], "b_banned": false, "s_authy_id": "123456", "s_country_code": "57", "s_errors": "", "s_locale": "en", "s_phone_number": "953a0fd8c9ec2a9f16a5ce58183cfa03" } }, "request": { "id": "413fd53c-09af-43d6-8390-c346de8ccf0c", "ip": "IPv4_99a65f1a9e58fe49150aed5a188459b9b0b47157" }, "public": true } ], "webhook_id": "WH_50087ea9-9568-4839-9191-b43908a4abd4" }, "url": "https://example.io/webhook" }
The payload for event `user_registration_failed`:
{ "method": "POST", "params": { "events": [ { "event": "user_registration_failed", "time": "2019-04-09T22:26:10.503Z", "objects": { "app": { "b_custom_code_allowed": false, "b_custom_message_allowed": false, "s_account_sid": "AC5f586933eabfa99ee3441ef1e84ad528", "s_device_app": null, "s_errors": "", "s_id": "54321", "s_name": "Application Name", "s_type": null }, "error": { "s_code": "60000" } }, "request": { "id": "413fd53c-09af-43d6-8390-c346de8ccf0c", "ip": "IPv4_99a65f1a9e58fe49150aed5a188459b9b0b47157" }, "public": true } ], "webhook_id": "WH_50087ea9-9568-4839-9191-b43908a4abd4" }, "url": "https://example.io/webhook" } ```
Request User Status
The user status endpoint will only return a subset of the information for a given user, until that user has verified a token or approved/denied a OneTouch request.
Once a user is created and registered with your application, you can request information on that user from Twilio. Using the User status call, you will receive:
Response Parameter | Description |
country_code |
Country code of the phone number. |
phone_number |
Last 4 digits of phone number (XXX-XXX-1234 ). None if the user was registered without providing phone number. |
email |
Email provided when the user was added. None If user was added without email this field will be empty. |
devices |
List of devices, options are: android , android_tablet , ios , iphone , iphone_sdk , chrome, authy_chrome , sms , android_sdk |
detailed_devices |
List of devices including detailed registration information. See Detailed Devices below. |
deleted_devices |
Useful for determining a chain of trust. See Authy trust-chain for added devices for more information. Devices deleted before June 15th 2019 won't be returned. |
multidevice_updated_at |
Unix timestamp of the last time the user changed the multidevice toggle status (true/false) on any device |
mutidevice_enabled |
true if multidevice is enabled, false if multidevice is disabled. |
registered |
true when the Authy Mobile/Desktop App was registered. |
confirmed |
true when the user has used a valid code before. |
Trust-chain for Added Devices and detailed device response fields
Determine which end-user apps to trust for authentication. Our API records uniquely identifiable numbers for every installed app, as well as the sequence of app installs and the methods of installation. More information in our blog post: Authy trust-chain for added devices.
Information returned in the detailed_device
section of the user status
endpoint includes:
registration_method
: how the device was added (sms
,call
,push
).last_sync_date
: Unix timestamp of last time the device was synced with Authy servers.registration_device_id
: device ID of the approving device ifregistration_method
ispush
. New as of 2019-06-15, devices added before this date will benull
. See Authy trust-chain for added devices for more informationenabled_unlock_methods
: one or more ofpin
,faceid
,fingerprint
,password, none
,unknown
. Refers to the unlock method for the entire app, not just the settings page.- Only available for iOS app version 22.8+, Android app version 23.9.3+, and Desktop app version v1.8.0+
- Not available for Chrome app
- If an unlock method is enabled for iOS app, the linked Apple Watch app will still display non-transactional TOTP codes without requiring an unlock, but it will not allow a user to accept a push request.
last_unlock_method
: enabled method last used.last_unlock_date
: Unix timestamp of last time the device was unlocked.
GET https://api.authy.com/protected/{FORMAT}/users/{AUTHY_ID}/status
URL
Name | Description |
---|---|
FORMAT String |
The format to expect back from the REST API call. json or xml . |
AUTHY_ID Integer |
The Authy ID of the user. Create an Authy ID by registering a user. Note that password delivery may be upgraded to use the Authy application; see response parameters below. |
Parameters
Name | Description |
---|---|
user_ip String |
IP of the user requesting to see the application details. Optional. (📇 PII ) |
Response
Name | Description |
---|---|
status Hash |
Information about the user. (🏢 not PII ) |
message String |
A message indicating the result of the operation. (🏢 not PII ) |
success Boolean |
True if the request was successful. (🏢 not PII ) |
Remove a User
If you want to remove a user from your application you can use the Remove API. Note: removing a user will immediately disable token verifications.
Best practice is to remove a user if they disable Two-factor Authentication or remove an account with your App. If you accidentally remove a user, you can recover users through the Console - but we suggest that you instead go through your registration flow again.
curl -X POST https://api.authy.com/protected/{FORMAT}/users/{USER ID}/remove -H "X-Authy-API-Key: {KEY}"
Parameters
Name | Type | Description |
---|---|---|
user_ip | String (optional) | The ip requesting to remove the user (📇 PII ) |
Response
Need some help?
We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Stack Overflow Collective or browsing the Twilio tag on Stack Overflow.