enricofoltran
Joined 13 years ago
Joined 13 years ago
In this example we have two servers (hello-server and auth-server) and their respective clients (hello-client and auth-client).
The client-server communication is achieved using gRPC, a RPC framework that enstabish a bi-directional stream between the parties. gRPC use http/2 as the transport protocol and protocol buffer as serialization format.
The communication is secured using TLS. By default the TLS protocol only proves the identity of the server to the client (server-side authentication), however in this example the server require the client to provide its own certificated to proves its identity (client-side authentication). In this way we have mutual authetication (or two-way authentication); two parties authenticating each other at the same time.
The mutual authentication is achieved by generating a certificate (and a private key) for each server and (potentially) one for each client (in this case clients share the same certificate). Certificates are signed by a common trusted certificate authority and can be validated on each side.
In this example the auth-server provide token based authentication as a service for the hello-server. This is done by let the user login to the auth-server, using the auth-client, by providing username and password. Once the auth-server as determined the identity of the user, it generate a JWT token an sign it with a dedicated private key, then send it back to che auth-client which store it on the user's disk.
When the user use the hello-client to communicate with the hello-server the client load the token from disk and pass it in the request. The hello-server then validate the token signature with the corresponding public key.
Doing this allow servers to communicate in a secure way only with trusted clients and only the auth-server can generate valid auth tokens, that can be validated by other servers by sharing only the public key.
Thanks for your question, hope I answered. Sorry, english isn't my native language. Bye!
To read a message a user need both the secret url and the passphrase, the message is destroyed after the first read or after 10 minutes.
The service is convenient for sharing sensitive information such as passwords, secret urls, credit card numbers sent via email or chat, in this way these informations are kept out from email or chat logs.
- it is not open source (or at least I didn't found the source code)
- it require you to sign up in order to create messages.