search

ownpass / api-server

The OwnPass server application.
https://ownpass.io
7 stars 3 forks source link

Default browser communication with server? #1

Open ei8fdb opened 7 years ago

ei8fdb commented 7 years ago

I'm working on some UI sketches for the browser (for the moment generic browser) plugin.

I have a few questions about how the browser plugin communicates with the server - what is the default communications protocol between the plugin (client) and the server?

Ideally there will be no need to specify the protocol in the browser client config.

waltertamboer commented 7 years ago

Hi Bernard,

The devices (clients) will communicate with the server over HTTP. The API provides REST and RPC services build with Apigility. The services will return JSON and to be more specific, HAL JSON.

To use the API the user needs to be authenticated. Authentication will happen using OAuth 2.0. The browser plugin will have to show an username/password box which will be used to retrieve an OAuth access token. An example of a login screen in the browser can be found here: https://github.com/opensourcedesign/jobs/pull/102#issuecomment-243457712

One side-note, Two-Factor authentication will be implemented very soon after launching the 1.0. So after filling in the username and password, the next screen will be a screen where a verification code will have to be entered.

So all this communication is done behind the scene. The user will not know that OAuth is used for example. The user will have to specify the server, a username and a password. Ideally specifying the server will only have to be done once. Maybe we could make the extension smart so that it remembers previously entered servers. (ping @kwarkjes)

Does this answer your question?

waltertamboer commented 7 years ago

Oh, I forgot, thank you for investing time! :-) If you need anything, let me know.

ei8fdb commented 7 years ago

Hi @waltertamboer Yep, even too much detail! 😆 But all that extra detail answers some other questions I had :)

Two-Factor authentication will be implemented very soon after launching the 1.0. So after filling in the username and password, the next screen will be a screen where a verification code will have to be entered.

Good to know. Will the user need to enter aa 2FA verification code each time they want to retrieve a password from the manager?

And will they need to enter their password (password to the server, or passphrase, or other?) every time they want to retrieve a password?

Maybe we could make the extension smart so that it remembers previously entered servers. (ping

Yes I was thinking about this also similarly if there was a possibility/need to have multiple password manager accounts/or password files?

Similar to having a number of addressbooks (LDAP, CardDav, etc) setup on a computer....

One final question about client-server comms - is there a need/possibility for the user to specify where the password file is located on the server? Otherwise where is the password file located on the server?

Thanks! And you're welcome. A nice design challenge and also interesting to me as a user.

waltertamboer commented 7 years ago

Good to know. Will the user need to enter aa 2FA verification code each time they want to retrieve a password from the manager?

For now only when the user authenticates. Since research about security is still being done I can't say what other moments you would enter this code. But my gut-feeling tells me that you would only enter the 2FA code for authentication and a master password for other management actions.

And will they need to enter their password (password to the server, or passphrase, or other?) every time they want to retrieve a password?

No. It's a trade-off between UX and safety but I think the OAuth connection is safe enough already to load the data. Good question though.

Yes I was thinking about this also similarly if there was a possibility/need to have multiple password manager accounts/or password files?

In theory one could connect to multiple managers. We shouldn't make this too complex. There won't be any migrating of credentials from server X to Y, it's just a matter of authenticating to a different server and therefor loading different stored credentials. I don't want to sit in your chair but I'm imagining a dropdown with servers that I entered before with an extra option to connect to a different server. Does that sound weird?

One final question about client-server comms - is there a need/possibility for the user to specify where the password file is located on the server? Otherwise where is the password file located on the server?

The location of where the passwords are stored does not really matter for the user, communication will all happen via the API so in theory the password file could be retrieved from a mailbox (very weird but to stress the flexibility) and its data can be served over the API. The end-user won't see the difference if the password are loaded from a database or from an encrypted file on disk.

waltertamboer commented 7 years ago

How's it going? :+1: Anything I can do for you?