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. Each is explained in the following.
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.
- 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….
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.
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. 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.
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 flwo, 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.
Where to go from here
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.