Privacy is an important concern in our day and age.
Some jurisdictions mandate certain privacy requirements (such as the EU’s GDPR). Even in those that don’t, privacy of user data is still important.
To that end, AuthRocket has a number of features designed to assist you in maintaining the privacy of your users’ data.
Users expect transparency with regards to personal data collection. The data AuthRocket collects from users is primarily names, emails, passwords (which are always one-way hashed, and never stored as-is), and IPs and other browser data. (Full details are in our own Privacy Policy, which is part of our Terms.)
AuthRocket does not perform marketing-type tracking as part of LoginRocket (hosted logins). However, it is possible for you to add it via custom page headers and footers. If you do this, you may need to disclose it.
AuthRocket stores event log history related to user activity. How long this data is kept varies according to your service plan with us. For plans with short event histories, portions of this data may be preserved longer as part of our abuse prevention.
AuthRocket also keeps logs, database backups, and other similar things typical of any responsible technology company. As would be expected, any user data captured in those sources will persist for a time even after data is deleted.
Nearly all data stored within AuthRocket is accessible via the API. If you need to provide a user with a copy of the data you have from them, it’s quick and easy for you to retrieve their data as well as any related event logs (subject to the retention period, of course).
If the API is overkill for your situation, you should be able to see and retrieve the data via our management portal as well.
If you ever have queries about data that cannot be retrieved via the API, let us know and we’ll be happy to help you sort it all out.
Because AuthRocket is an API-powered service, this is not any different than accessing a user’s personal data. If the data needs to be provided to the user in a programmatic format (say a specific set of JSON keys), simply transform the data accordingly.
User data provided as part of the login process (for both direct and social logins) is fully editable via the API and the management portal–likewise for any custom attributes you’ve added. You’ll find it very easy to assist your users in correcting their data, and/or providing them a self-serve way to correct it.
In practice, correcting data should be a rare issue since the data is all directly (or indirectly, in the case of a social login) provided by users themselves anyway.
Event logs and the like cannot be modified, but we can’t imagine much of a need to. However, if you or your user come up with a compelling reason to do so, let us know.
Objection to processing logins is unlikely. That said, you always have the ability to correct (above) or delete (below) any problematic data, including custom attributes.
Deleting (or erasing) user data is also fully supported by the API and management portal.
Event logs are retained by default, which is usually helpful as they will confirm deletion via presence of a ‘user.deleted’ event. If for some reason all historical events related to a user need to be deleted, please contact us with this original user ID (starting with “usr_”) and we’ll take care of it.
AuthRocket supports a “state” flag on Users. When a user’s state is marked as inactive, they will no longer be able to login, reset their password, or any other common user activity.
This does not prevent changes or deletion of the record via the API or management portal. If such is necessary, you’ll need to check the state yourself.
It’s probably a given, but terminating your service with AuthRocket will also trigger deletion of all data.
AuthRocket itself isn’t involved in the kind of automated decision making that’s likely to trigger user concerns (such as credit scoring, etc).
AuthRocket does perform automated fraud and abuse handling. The most likely impact of this is the user is prevented from logging in (the user’s acocunt is locked) due to rate-limiting. User accounts locked this way are automatically unlocked after a period of time. The management portal also allows a user’s account to be unlocked immediately if necessary.
In some jurisdictions, the question of lawful basis for data collection comes up. We believe that the act of signing up for and logging into a service is a core function, not auxillary, and thus can be classified as a legitimate interest.
A username/email and password is essential to basic logins, and expected as normal by any user. Providing a name is also expected, although AuthRocket still makes this optional for direct logins.
Social logins always provide an email, and nearly always a first and last name. These are always saved by AuthRocket when available. Demographic data, such as gender, birthdate, and so on, is not saved even if received.
IP and User Agent data is collected by AuthRocket most of the time. Since this is used in part for fraud and abuse prevention, this too can be classified as legitimate interest.
AuthRocket does allow for storing arbitrary data via custom attributes. The basis for collecting and storing this data will vary and must be determined by you.
Tagged with: privacy
Questions? Find a Typo? Get in touch.