Criipto
  1. Getting Started
  2. Learn the Basics

This document explains some of the basic terminology we use at Criipto, and we try to relate these terms to concepts you are already familiar with.

This article introduces the following core concepts of Criipto: Tenants, Domains, Applications, and Identity Sources.

One important distinction in Criipto Verify is the separation of Test and Production. Inside each tenant, you may toggle the setup between Test and Production to configure each environment separately.

To set up a production domain you must first upgrade your free subscription to a paid subscription.  

For illustration purposes, we will use a fictitious company named Secure Insurance that wants to use Criipto for authentication. They have both a web and a mobile application, and they want their users to be able to log in with Swedish BankID and Danish MitID.

​
Tenants

If you haven't already signed up for a Criipto account, feel free - it's free.

When you sign up for the first time, you will be asked to create your first tenant and your first domain along with it. In Criipto, a tenant is the logical isolation unit that isolates you and your data from other Criipto tenants. The term describes a software architecture where a single instance of the software serves multiple tenants. No tenant can access the instance of another tenant, even though the software may be running on the same machine.

Tenant characteristics:

  • The tenant name has to be unique. It is used primarily for your reference and communication purposes and carries no formal significance.
  • The tenant name cannot be changed after creation.
  • You can create more than one tenant. Typically you manage both your test and production setup inside a single tenant, but please create multiple tenants as it suits you, for example, one for each environment you have (such as Development, Staging, or Production) if you have separate teams working in each tenant.

You can create additional tenants at any time. To do so, go to the upper-right corner of the Dashboard and click on your own name/email to display the pulldown menu. Click Create new....

​
Domains

As discussed in the previous section, when you create a new account with Criipto, you also create your first domain. Typically, your first domain would be something like secure-insurance-test.criipto.id.

A domain in Criipto Verify is the DNS domain on which you call our service to perform authentication.

Domains are registered for either test or production and as such determine whether you can use test eID accounts or real, live eID accounts.

As such, the domain is the key distinction between test and production.

​
Bring your own domain

For development and testing it is usually sufficient to just use the preconfigured criipto.id top-level domain, but for production you may wish to map a domain of your own, such as login.secure-insurance.com, to point to Criipto Verify. In some scenarios this is required for technical reasons, but you should also keep in mind the perception of your users. They may feel uncomfortable being taken to a third-party domain to log in. If instead you have mapped your own domain, your users may feel safer as they are being kept in the realm of your company and application.

If you choose to set up your own domain for production you must have access to your company's DNS setup and be able to acquire a so-called SSL certificate which must be uploaded to the Criipto Verify service (after setting up your DNS record).

​
Applications

Once you've set up a tenant including the first test domain, you are ready to register your application to enable its use of our service for authentication. To that end, you must register each application. (We use the term application as defined in the client role in OAuth 2.0).

When you create an application in the Applications section of the management UI, we ask you to fill out a few required fields.

Each application is assigned a Client ID upon creation. This ID is used as the key to identify authentication requests made from your application. This is an alphanumeric string and it's the unique identifier for your application (such as urn:my:application:identifier:6765) in the scope of the domain it is registered for. You can use the default format suggested by our management UI, or change it to fit your preferred format.

Note that although you may change the client ID later, you should be very careful not to do so without careful consideration of the fact that the application(s) using this client ID will have to be re-configured at the same time or they will stop working.

If you choose to use the OAuth2 code flow - a flow where sensitive information is exchanged through a back-channel between servers - another important piece of information is the Client Secret. Think of it as your application's password which must be kept confidential at all times. If anyone gains access to your Client Secret they can impersonate your application and access protected resources.

In our example, Secure Insurance has two apps: a web app (running on a server) and a mobile app. Hence, they would create two applications: one of type using the code flow, and one using the implicit flow which requires no client secret.

​
Identity Sources

Now that you have set up your Applications, you are ready to configure how your users will log in.

Criipto sits between your app and the Identity Sources that authenticate your users (such as Swedish BankID and Danish MitID). Through this abstraction, Criipto keeps your app isolated from any changes in the provider's implementation.

Each Identity Source can be shared among multiple applications. You may use all the available Identity Sources for all your applications.

Identity sources are already configured for test when you create a tenant. To be able to use an Identity Source in production you will - in most cases - have to enter into some sort of formal agreement with the provider of the particular type of eID.

In most cases, this is handled through the intermediary of Criipto, although in some cases you will also have to set up direct agreements (in countries such as Denmark and the Netherlands).

More detail on the formalities and process can be found in the section about eIDs.

​
Where to go from here

This section introduced several core concepts of Criipto. Next, we recommend learning how Criipto supports the OpenID Connect protocol and reviewing best security practices for implementing OpenID Connect authentication in client applications.