deontologician
commented
8 years ago Here's a brain dump of stuff I've been looking at and thinking about wrt authentication. Authentication is pretty useless with out authorization, and there are couple places where I have to mention authorization stubs since there's some chicken-and-egg problems. For instance, a notion of an admin user makes no sense without specifying what authorization that entails, but it's pretty obvious we need to talk about the admin user here
Creating the authentication machinery
This is something the user should eventually be able to do through a web ui. It's fairly simple, but managing keys etc is tedious and not really a programmatic task. That being said, there still needs to be an api for it since the webui should build on top of fusion.
The pattern with the administrative commands is they're less recombinable, and more individual commands (even if there is some similar code/protocol underneath). So lots of different methods that do one specific thing, but don't need to do .value or .subscribe, they just return the promise directly.
Creating an admin connection
Administration connections should probably be on an entirely different port, with a different connection. I suggest 8182.
const Fusion = require('fusion')
let admin = Fusion.adminConnection('localhost:8182')The admin connection would only connect without credentials if there is not already a users table. On subsequent connections it would need to authenticate as the admin user, or with a jwt that allows for administrative actions to be performed (this is getting into the authorization side).
Creating the admin user
admin.initializeUsersTable({
'admin_password': 'plaintext password',
'auth_type': 'password',
'scrypt_cost': <optional cost specified by the user>,
})This will succeed if there is no users table and admin user, and fail otherwise.
For auth_type: password:
The server should hash the password with scrypt with the given cost parameters if given and store it in the database.
For auth_type: OAuth, I mention below what the user needs to provide to create the admin user.
Authentication methods
Password
This is the equivalent of basic auth in http, and firebase's password based auth. It needs to be over a secure connection
Handshake:
- username: unique user identifier
- password_hash: scrypt hash of user's password. With cost parameters to be determined experimentally
Notes: the hash needs to be done in the browser using something like scrypt-async to avoid easily DOSing the server. This should happen in a web worker to avoid freezing the UI thread.
Also scrypt requires a salt. Since storing the salt on the server and sending it to the user requires another round-trip, and salts are basically irrelevant with an algorithm like scrypt, I suggest we just sha1 hash the username, or whatever's easiest and doesn't require talking to the server to determine the salt.
OAuth 2.0
I don't think we should bother implementing an OAuth provider ourselves, just clients for other providers (google, facebook, twitter etc). The consensus seems to be that OAuth 2 is inferior security-wise to OAuth 1.0a, but all the major players have moved towards it and Google has deprecated their 1.0a identity api, so there's not a huge number of options unless we want to support SAML (which we totally shouldn't).
I don't think we should allow mixing auth types (password and non-password), but we should probably allow mixing auth providers for OAuth.
admin.initializeUserTable({
oauth2: {
google: { api_key: 'XXX', api_secret: 'XXX'},
twitter: { api_key: 'XXX', 'api_secret: 'YYY'},
},
admin_credentials: {
... // whatever's needed by oauth client library to authenticate
}
})Handshake:
This is a part I haven't fleshed out yet. It should be possible to pass a jwt in the handshake to get access if you've already authenticated recently. Alternately, you can trigger a fresh authentication with the provider. We should probably return a function that does the OAuth redirect if necessary, so it's dead simple to do, but doesn't fire by itself. We may also need an oauth landing page for the redirect (i.e. a non-websocket endpoint that can receive data from the OAuth provider). There might also be ways around that
New user registration
This doesn't need to be on the admin connection. We should allow registration to occur in an anonymous handshake on a normal fusion connection.
Other uses for the admin connection
I think the admin connection will get more use with authorization, where the admin user can set up permission types, etc and set default permissions for new users.
danielmewes
marshall007
nstadigs
TBD