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. Each is explained in the following.
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 NemID.
If you haven't done so already signed up for a Criipto account, feel free - it's free.
When you signup 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.
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....
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
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 determines whether you can use test e-ID accounts or real, live e-ID accounts.
As such, the domain is the key distinction between test and production.
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. The may feel uncomfortable being taken to a third party domain to login. If instead you have mapped your own domain, your users may feel safer as they are being keept 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 aquire a socalled SSL certificate which must be uploaded to the Criipto Verify service (after setting up your DNS record).
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 authentiation. 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 with out 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.
Now that you have set up your Applications, you are ready to configure how your users will login.
Criipto sits between your app and the Identity Sources that authenticate your users (such as Swedish BankID and Danish NemID). Through this abstraction, Criipto keeps your app isolated from any changes of 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 the provider of the particular type of e-ID.
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 getting ready for real e-ID.
In this article you have familiarized yourself with several core concepts of Criipto. If you wish to learn more about the next steps in setting up Criipto, you can read more in the rest of the documentation.