{"_id":"560221271ba3720d00a6b99d","parentDoc":null,"category":{"_id":"560220af7435de0d00fabd0d","__v":1,"project":"54e405191e51932d006abc39","pages":["560313793ee4af170004720c"],"version":"55fa37c88065a10d004e5bb6","sync":{"url":"","isSync":false},"reference":true,"createdAt":"2015-09-23T03:46:55.703Z","from_sync":false,"order":4,"slug":"oauth","title":"OAuth & Fingerprint"},"project":"54e405191e51932d006abc39","user":"54e4044e8ef7552300409dcb","version":{"_id":"55fa37c88065a10d004e5bb6","project":"54e405191e51932d006abc39","__v":9,"createdAt":"2015-09-17T03:47:20.956Z","releaseDate":"2015-09-17T03:47:20.956Z","categories":["55fa37ca8065a10d004e5bb7","55fa37ca8065a10d004e5bb8","55fa37ca8065a10d004e5bb9","55fa37ca8065a10d004e5bba","55fca6bf34ae7c0d00ab8ea0","55ff80fd9e7ccf0d000a1d93","560220af7435de0d00fabd0d","56107f21bb9d920d00303e70","563e184077681a0d00d96a02","56fafc6596ec7e0e002ac85f","5915e54f7c2c552d008b8549","59499fcd64b5f5002690bbc1"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"REST V3","version_clean":"3.1.0","version":"3.1"},"__v":7,"updates":["560720c0b7a1330d0052b253","564f4b1848a1df170083664c"],"next":{"pages":[],"description":""},"createdAt":"2015-09-23T03:48:55.846Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":true,"order":0,"body":"We use a variation of [OAuth 2.0](https://oauth.net/2/) for authentication. This means when you register a user to Synapse, you get back `oauth_key` & `refresh_token` on the user to access all of the user functionality.\n\n**OAuth Key currently expires in 2 hours**. After OAuth Key expires, you can use the refresh token to generate a new OAuth Key. When the OAuth Key is refreshed, a new refresh token might be issued as well. \n\n**Refresh tokens expire after 10 uses** and update periodically. We manage this complexity for you. To get the most recent Refresh token, do a [GET](doc:get-user) on user.\n\nAlong 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. 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.\n\nIf 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.\n\n*Here's a useful [blog post](https://discuss.synapsepay.com/t/collecting-fingerprints-on-different-devices/18) for collecting fingerprints.\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Don't want to trigger 2FA? (Not Recommended)\",\n  \"body\": \"We strongly recommend using 2FA or some form of MFA within your authentication process.\\n\\nIf 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.\\n\\nAlternatively, you can also pass a hashed version of your `user_pk+client_id+client_secret`. That way the value is still somewhat secret, but you won't need to store it for each unique user.\"\n}\n[/block]","excerpt":"","slug":"oauth-resources","type":"basic","title":"OAuth & Fingerprint"}

OAuth & Fingerprint


We use a variation of [OAuth 2.0](https://oauth.net/2/) for authentication. This means when you register a user to Synapse, you get back `oauth_key` & `refresh_token` on the user to access all of the user functionality. **OAuth Key currently expires in 2 hours**. After OAuth Key expires, you can use the refresh token to generate a new OAuth Key. When the OAuth Key is refreshed, a new refresh token might be issued as well. **Refresh tokens expire after 10 uses** and update periodically. We manage this complexity for you. To get the most recent Refresh token, do a [GET](doc:get-user) on user. 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. 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. 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. *Here's a useful [blog post](https://discuss.synapsepay.com/t/collecting-fingerprints-on-different-devices/18) for collecting fingerprints. [block:callout] { "type": "info", "title": "Don't want to trigger 2FA? (Not Recommended)", "body": "We strongly recommend using 2FA or some form of MFA within your authentication process.\n\nIf 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.\n\nAlternatively, you can also pass a hashed version of your `user_pk+client_id+client_secret`. That way the value is still somewhat secret, but you won't need to store it for each unique user." } [/block]