Security

most applications need a way to control which users can write or read certain data for example, you might build an application where senior staff members can read and write documents in the "menuitems" collection while junior staff members can only read ditto's security is controlled by identities each ditto instance must identify itself to other peers in order to syncronize with them protections and materials ditto implements network protections that secure all data while in transit and at rest, including inter and intra service, client server, direct peer to peer transports communications encrypted at the transport layer using version 1 3 of the transport layer protocol (tls), clients and servers are mutually authenticated prior to transmission of api and peer to peer access credentials the use of mutually authenticated tls (mtls) mitigates potential risks posed by outside attackers attempting to masquerade as a valid api endpoint or peer in the mesh network to steal information additionally, ditto workloads and services are tightly controlled in a containerized kubernetes environment following is an overview of the authentication and authorization controls, network protections, and access credentials ditto uses to ensure access and data remain secure and resilient material issuer usage description json web token (jwt) third party identity provider used by the websocketclient and is accepted by the websocketserver, the jwt credential determines access permissions and privileges x 509 ditto used by all peer to peer transports, such as bluetooth low energy (le), as well as the tcp client and server transport in band certificate third party identity provider used to secure multi hop replication transports linkclienttransport and linkservertransport login authentication flow the authclient locally generates a peer key the peer key is a p 256 private key generated and persisted on every client device running ditto this is the primary unique identifier for each peer; its elliptic curve digital signature algorithm (ecdsa) signatures are used to prove authenticity a signing key pair this is the primary identifier for a particular unique peer device or application, but it isn’t trustworthy in addition to using a peer key to verify client identity, the transports need to prove that a given device is authorized to join the mesh using central authority (ca), a cryptographic root of trust for everybody participating in the same ditto application this trust comes in the form of signed access tokens or client certificates, depending on the transport type, which are managed by the authclient object and the on disk cache onlinewithauthentication flow when a small peer calls onlinewithauthentication , first a request for an access token specifying user access permissions and privileges in an encryption is sent to the third party identity provider integrated with your app once generated, your identity provider returns the access token, which is typically in the format of a json web token (jwt), to the calling small peer once retrieved, the small peer passes the access token to the ditto authenticator service, which then passes it to your identity provider’s authentication webhook url endpoint the small peer uses the authentication webhook endpoint to validate and decrypt the access token and then issues the small peer certificate encoded with identity and access control permissions in a json payload to the ditto database server, the big peer each peer verifies certificates of other peers and accepts or rejects reads and writes based on the certificates encoded identity and access control permissions you can issue each peer certificate manually or using onlinewithauthentication when the access token is soon to expire, if implemented, the authenticationexpiringsoon asynchronously invokes to refresh the access token before it expires in offline scenarios, a small peer that invokes the onlinewithauthentication api must connect to the internet at least once in order to authenticate and retrieve their client certificate before it can sync with other peers offline the following diagram illustrates the end to end authentication flow for client apps (small peers) invoking onlinewithauthentication