Remove dependency on Auth0

[ItalyPaleAle]

Currently, Hereditas has a dependency on Auth0. While this should not pose a security risk (Auth0 stores the application token but never sees the user passphrase, so even if an attacker managed to break Auth0, they wouldn't have enough information to decrypt the data), it represents a single point of failure. What if Auth0 went out of business? What if they changed their APIs? (I find this last point quite unlikely, given that we're using OAuth2 which is an industry-standard, but in the long run it might be possible).

We need Auth0 for two separate reasons:

1. Authenticating users. We could potentially get away with just using Google/Facebook/Microsoft accounts here, as Auth0 is just an extra layer on top of that. Removing Auth0, we'd lose the possibility to use any social provider as long as the email matches (e.g. as long as your email is user@example.com, you can use either Google or Facebook), but it could still work.
2. Whitelisting users. Without Auth0 or another similar provider we wouldn't be able to easily and securely restrict which users can authenticate to our app. Google and Microsoft allow us to restrict access to certain domains/directories only, but this requires that every user has an account in the same directory. For most users, this means creating new accounts specific for Hereditas, which would not be desirable.
3. Storing the application token and the timer, then starting the timer when normal users authenticate and resetting it when owners sign in. This point is important to ensure that Hereditas remains fully-trustless and that there's a delay before users can unlock a box.

I am not aware of any alternative solution that doesn't require having a dependency on a specific external provider, for example something decentralized or portable.

A possible solution could involve some sort of blockchain technology. At the moment, I do not believe the decentralized, blockchain-based web is mature enough for us to use it. There are too many competing technologies, evolving fast and often with unstable APIs. Also, the user experience is still far from what we'd need for Hereditas, since our end-users (that need to unlock boxes) aren't necessarily tech-savvy.

[halmos]

For the time stamping related component of the Auth0 implementation, perhaps it would be feasible to use an RFC2161 trusted timestamp authority. See the following links for some interesting notes on somewhat related issue: https://stackoverflow.com/questions/11913228/how-can-i-use-rfc3161-trusted-timestamps-to-prove-the-age-of-commits-in-my-git

The primary benefit of that approach is there a number of RFC2161 compliant servers out there so that if one of them fails, there are alternative providers available.

[ItalyPaleAle]

@halmos Thanks, I think this is an interesting part of the problem. However, it wouldn't let me remove the dependency on Auth0 quite yet, as it's important that the client app never sees the key stored inside Auth0 (at the moment) until the time is right. The challenge is that we're working with JS code, which could be modified too easily on the client.