You can integrate your solutions with Ditto

On all APIs Ditto protects functionality and data by using

  • Authentication to make sure the requester is the one she claims to be,
  • Authorization to make sure the requester is allowed to see, use or change the information he wants to access.


User authentication at the HTTP API

A user who calls the HTTP API can be authenticated using two mechanisms:

Single sign-on (SSO)

By configuring an arbitrary OpenID Connect provider (as mentioned above) it is possible for Ditto to participate in SSO for the following browser based requests:

  • HTTP API invocations
    • sending along a JWT token as Authorization header with Bearer value
  • Establishing a WebSocket connection for bidirectional communication with Ditto via Ditto Protocol JSON messages
    • open: sending along the Authorization header containing the Bearer JWT token is not possible in the plain WebSocket API in the browser - Watch issue #661 for fixing that
  • Opening a Server sent event connection in order to receive change notifications of twins in the browser
    • passing the withCredentials: true option when creating the SSE in the browser


Authorization is implemented with an ACL (in API version 1) or a Policy (in API version 2).

Please find details at ACL and Policies.

Authorization Context in DevOps Commands

An authorizationContext which is passed to DevOps Commands needs to be a subject known to Ditto’s authentication. In the simplest case, it’s nginx:{username} where {username} is a user that is configured for basic auth in the included nginx’s nginx.htpasswd file (where the nginx: prefix comes from).

If you are using the provided docker quickstart example from Getting Started you can simply use nginx:ditto, then the commands that are passed from the connection are executed as if they were issued via HTTP from the user ditto.

Tags: model