OAuth
We use a variation of OAuth 2.0 for user authentication. This means that to perform any user actions, or to make any changes to a user, you need to supply a valid OAuth Key in the header field of the API request. Read more about what to include in our headers here.
An OAuth key is a token representing a user's identity. See Issue OAuth Key for more information on creating an OAuth key. The OAuth key will be returned in the response of this API call and will be used in the headers of subsequent API calls to allow users to perform other actions.
OAuth keys currently expire after 2 hours. After an OAuth key expires, you can use a refresh token to generate a new OAuth Key. Please remember to take OAuth key expiration into account when building out your application.
Please note that you can only store up-to 110 valid fingerprints per user and the fingerprints follow a first in first out logic (FIFO).
This architectural decision is made to keep a limited number of fingerprints registered with a user profile to reduce security risks. A first in first out logic is chosen so that the oldest fingerprints are cycled out first.
If you OAuth with a new device (i.e. a new fingerprint), you will need to Register New Fingerprint.
Along with OAuth, we also use device fingerprints for authentication. Fingerprints are used to identify the device that is trying to access a user's information. You need to supply fingerprints when you create a user. The fingerprint supplied during the
POST user creation is the registered fingerprint associated with the user.Additionally, you can incorporate two-factor authentication ("2FA") into your user login process when your user connects with a different device. To do so, just supply the new, non-verified fingerprint. See Create OAuth Key to register a new device fingerprint to the user account and use our two-factor authentication (2FA) security protocols.
If the user supplies a non-verified fingerprint during login, the user will be directed to the 2FA flow. We return the linked phone numbers in the API call response with key
phone_numbers. You can let the user select the phone number from that list and then make the API call again by specifying the phone_number you want the 2FA to be sent. This will trigger the 2FA protocol and a PIN will be sent to the selected phone number. The user will be able to verify the device via this API call itself. You can supply validation_pin under the user object and the verification will be triggered.We strongly recommend using 2FA or some form of MFA within your authentication process.
If you do not want to use our 2FA, store the fingerprint used when creating the user and supply the fingerprint when performing actions with the user. This way the system will not detect a new device and no 2FAs will be triggered.
Alternatively, you can also pass a hashed version of your
user_pk+client_id+client_secret. That way the value is still somewhat secret and you won't need to store a different fingerprint for each user.Last modified 9mo ago