Overview

Use of Domec platform APIs requires application login (referred as client login) as well login for end user (referred to as user login).

Client login establishes authentication and authorization for client application with Domec platform. End user login allows clients to use Domec platform tools for their own needs, that is, download reports, view application KPI, use the console for customer support, etc.

Domec is commited to security of information transferred between client applications to its server. Domec already uses industry standard security practices at transport layer (HTTPS). To go a step further, Domec APIs has optional feature to allow customers encrypt all sensitive information (account credentials) prior to sending those over API call. Sensitive information is encrypted using Domec Public Key (obtained using API call).

Domec API is production ready and is recommended for any new integrations.

In this section:

Authentication
Domec API uses JSON Web Tokens (JWTs) to authenticating requests. These tokens are signed using HMAC-SHA256 with your Global Client Secret, which can be obtained using the Token Generator on this same page. The scopes claim of this token indicates which actions can be performed with it when calling Domec API. For example, this token would grant read-only access to users and read/write access to rules. Trying to perform any other action will result in a 403 Forbidden response.
More...
Core concepts Clients
A client is one of the core concepts in Domec API, which is why it’s important to know how this relates to your applications and the impact this will have on auditing, authorization, billing, etc. Depending on the concepts or technologies you're working with, a client might also be referred to as an application or a relying party. Let’s start by looking at how clients are represented in Domec Tools and how this relates to other core concepts.
More...
Architecture Overview
This page describes the typical architecture scenarios we have identified when working with customers on implementing Domec Tools platform. The first set, called Application Configurations, describes the typical application implementation patterns. The second set, called Business Scenarios, describes the architecture depending on the type of businesses, whether that be B2C (Business to Consumer applications), B2B (Business to Business applications), B2E (Enterprise applications), or a combination of B2B and B2E. Click on any scenario to get more information.
More...
Single Page Application + API
In this scenario you have a Single Page Web Application “Client” which talks to an API (“Resource Server”). The application will use OpenID Connect with the Implicit Grant Flow to authenticate users with Domec Tools. When a user logs in, Domec Tools will return to the application an access_token as well as an id_token. The id_token is used to securely call the API on behalf of the user. Alternatively the user profile can be obtained by calling the /userinfo endpoint in the Domec Tools Authentication API with the access_token.
More...
Mobile Application + API
In this scenario you have a Mobile Application “Client” which talks to an API (“Resource Server”). The application will use OpenID Connect with the Authorization Grant Flow (with the PKCE extension) to authenticate users. When a user logs in, Domec Tools will return to the application an access_token, an id_token, and optionally a refresh_token. The access_token is used to securely call the API on behalf of the user, whereas the id_token is consumed only by the client and contains user profile data.
More...
Server Client + API
In this scenario you have server to server communication where a server “Client” needs to make secure calls to an API (“Resource Server”), but on behalf of the client vs. a user. The Client will request an access_token from Domec Tools using the Client Credentials Flow. The server client will then use that access_token to securely call the API. Since there is no user involved, no id_token will be returned, nor is their any sort of user store (connection) involved.
More...
Regular Web APP (using OIDC)
In this scenario you have a traditional web application which needs to authenticate users using OpenID Connect. The web application will use the Authorization Code Flow to authenticate the user, and can then subsequently use the id_token which is returned to obtain information about the user. The application will also typically create a user session which is stored in one or more cookies to keep track of the user which is logged in.
More...
Identity Providers
We are currently working on this topic.
More...
Single Sign-On
We are currently working on this topic
More...
User Profile
We are currently working on this topic
More...