Auth0 looks like a very promising user management solution, but I'm curious if it allows you to export a user database.
This is an important feature because:
I'd like to make my own backups. (Not so much because I'm worried Auth0 might lose my data. But what if there's a bug in my code or my Auth0 keys are compromised?)
I might want to switch user management providers someday.
From Documentation > Importing Users to Auth0, I see there's a way to import users (on-demand when you can obtain their passwords anyway). And I can see they use bcrypt for password hashing (at least by default). But I don't see any mention of exporting users.
The Auth0 Management API allows you to export your data. Additionally, we have a tool that will help you both import and export users: https://auth0.com/docs/extensions/user-import-export
For the official policy see this document: https://auth0.com/docs/policies/data-export
Auth0 does not currently provide the facility to directly export password hashes. Not on their API and not by downloading from their web interface. Probably they never will provide this doing so would somewhat reduce security since an attacker with access to your Auth0 account could then attempt to brute force all of the user's accounts rather than just the active ones.
To get a more or less compuete export of user data there are three possible ways, all of which require activity in advance.
Request a full export from support - currently you have to be already signed up for support at at least developer level for at least a month (see the document Moving out of Auth0)
Do a gradual move out by creating a new, local password hash each time the user logs in. - you will have to wait for all your users to have logged in once. This is the inverse of the procedure for migrating in to Auth0. N.B. this will mean you miss users who never log in during your migration period.
Create and store a password hash yourself using Auth0s custom database connection for use whenever your user logs in. If you already have users in Auth0 you can combine this with method 2. to migrate those users into your custom database.
The answer from Nathan Totten here covers how to get the rest of your user data, though Auth0 support should be able to provide you with an export including all of that.
Related
I have an interesting use case for you today.
My team and I are building a free, third party, calculator tool that enables users to calculate metrics using their store's data.
We are looking for ways to pull in the necessary data and perform the calculation to show users... so far the best we've come up with is asking the users to export a report from Shopify and upload it into our application.
Looking for a user experience similar to this:
User opens our tool, application is hosted on custom-domain.com
Somehow the user authenticates or logins in to Shopify, or approves our app temporary access to their data.
Our app performs the calculation for the user, ending data access
Any ideas as to how this authentication or access of data can be facilitated? Shopify doesn't seem to have a 'login with Google' kind of authentication button.
Thanks!
There are two modes for authenticated access, namely Online and Offline. What you need in this scenario is Online Access.
From Shopify Docs
Tokens with online access mode are linked to an individual user on a
store, where the access token's lifespan matches the lifespan of the
user's web session. This type of access mode is meant to be used when
a user is interacting with your app through the web, or when an app
must respect an individual user's permission level.This access mode
must be explicitly requested in the authorization phase.
It should also fulfill your needs related to ending data access.
An access token created with this access mode is temporary, and is guaranteed to expire after some amount of time.
When a user logs out of Shopify admin, all online mode access tokens created during the same web session are revoked.
Once you have the access token, you can use Shopify API to query data so that your users don't have to upload any files manually.
I am creating a iOS native app that talks to a Flask API.
My plan is to have the iOS front-end handle log in with Auth0 lock. Afterwards, the front-end would store the JWT in local memory and use that on every API request.
On the back-end I plan to have a User table with both an internal ID field and a Auth0 ID field. Per API request I would look up the user via the Auth0 ID and then use a library like flask-bouncer to handle resource authorization.
Is this a valid approach?
Are there any out of box features of Auth0
that I am rebuilding? If so what are the advantages of using the
Auth0 version?
Are there any future implications that I am missing
with this approach?
What are the advantages of using Auth0 instead of building it myself following something like this?
Anything else to consider?
Is this a valid approach?
Depends on what you call valid. But it would work, yes.
Are there any out of box features of Auth0 that I am rebuilding? If so what are the advantages of using the Auth0 version?
You're not using authorization using scopes. See Auth0's tutorial for Flask.
Are there any future implications that I am missing with this approach?
That's a broad question that I wouldn't know an answer for.
What are the advantages of using Auth0 instead of building it myself following something like this?
You do not have to worry about signup, login, verifying emails, bruteforce protection, resetting passwords, MFA, etc. You get all of those things out of the box. But... some more complex things might require additional effort on your side.
Anything else to consider?
Make a clear decision on where you're storing what info and whether you want to store your users in your database at all. An easy pitfall is to have multiple sources of truth for certain data that's both in Auth0 and your database (e.g. first and last name). Also see the User Data Storage Best Practices.
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
I'm a developer at a company that has an application that is built with PHP and MySQL. We have about 300 users that have their passwords hashed with bcrypt and stored in the users table. We're looking to rebuild the application with Angular and Firebase.
My question is, how to I migrate these users over Firebase and use Firebase Auth. It's easy to migrate the profile info over, but I want to be sure that the user can still use the same email/password when they login to the new application.
Here are some approaches that I've thought of. All of these are terrible in my opinion.
A) Create a custom auth system that uses bcrypt, and then just copy the hash over. This isn't what I want because I don't want to maintain a custom auth solution.
B) Every time a user logs into the old system, grab their password from the login field, store it in plaintext, then manually create each user in Firebase with their email/password. This would require 100% of users to login before we switch to the new app. That is unlikely. Also this is obviously a breach of privacy. I'm sure it breaks some sort of law or standard. But it works and it's a last resort option.
C) Every time the user logs in to the old system, send the email/password in plaintext to a script that auto-creates a new Firebase user with the same user/email. This would require 100% of users to login before we switch to the new app. That is unlikely. It's also harder to build than option B.
None of theses options look very good. They all have downsides. Is there a better option? If not, between B and C, which is most legal/ethical? Option B tempts me because it's super simple, but I don't want to break any laws or lose the trust of my companies clients.
[From Firebase Authentication team]
Firebase has a better solution. Firebase Authentication service has the capability to batch import password hashes of your existing users, for well known hash algorithms (hmac-sha256, bcrypt, scrypt etc.). End users just sign with their existing passwords, and your app will receive a Firebase token containing the same user_id you uploaded. None of the option A/B/C is needed.
[Update 11/19] The Firebase command line tool 3.2.0 supports importing bcrypt hashed passwords to Firebase Authentication service.
Disclosure: I work at Auth0.
Disclaimer: If you really set your mind on using Firebase from a practical point of view this might not help you as it focuses on what Auth0 provides to solve problems similar to the one you described. However, from a theoretical point of view this might help you so I deemed it worthwhile to share.
Enough with the legal stuff...
Check this guide for a fully detailed view on how Auth0 supports migrating users from your custom store to a hosted one.
... automatic migration of users to Auth0 from a custom database connection. This feature adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time.
The approach would be similar to your option C, but the only thing that would need to stay from the old system would be the database. Everyone would start using the new application and the login would happen transparently for the users. Depending on the API's made available by Firebase, you could most likely implement something similar and that would be my recommendation.
Additionally, you should not even consider any process that includes manual steps and has to deal with plain text passwords.
A final note, excellent decision on rebuilding your app to use an external authentication service, even if it's not Auth0. :)
Authentication is a hard problem and wish more application developers stopped wasting time with issues totally unrelated to the business problems that their applications solve.
The Firebase CLI very recently added an auth:import command that allows you to import an existing user database into Firebase Auth from CSV or JSON.
I've gotten pretty spoiled by the mature frameworks available in Python (Django/Flask), so as I'm starting to learn Go, I have to wonder if there are any similar frameworks already in existence in Go to django.contrib.auth or Flask-Login?
The main use case is to handle simple user authentication and be able to extend it to accommodate some permissions-based routing within the app.
As far as I know, there are not. The closest out-of-the-box authentication you can probably get is via Google AppEngine, where the user's Google account can be retrieved and certain paths can be scoped for app administrators only.
In a standard Go web server, you will generally need to roll your own auth, but it's not as difficult as it sounds. Many frameworks isolate you from decisions which are actually quite important; in typical Go fashion, you'll need to make these decisions based on the needs of your app, and then pick the existing libraries that are right for you.
Login page
Wherever you need your users to log in, you will probably use an HTML form. These will typically be rendered using the html/template package. To retrieve the values when the form is submitted, use request.FormValue.
Database
There are a number of ways to store user information; on the filesystem with os or in a SQL database using database/sql. There are mature drivers for some NoSQL databases as well, including MongoDB and Redis.
Passwords
To compute and compare hashes to passwords, you'll want to use a preexisting mechanism so that you don't have to reinvent it yourself. For this, the go.crypto subrepository provides a bcrypt package.
Sessions
If you want to store session data, you can use a solution like gorilla/sessions. Based on your security needs, you can store the session data directly in a (optionally secured) cookie or you can store it in a backend an only store a session ID in the cookie.
From the READ.me
Allows your Martini application to support user login via an OAuth 2.0 backend.
https://github.com/martini-contrib/oauth2