Core concepts - How it works - Idura Verify Documentation
IduraDocumentation
  1. Verify
  2. How it works
  3. Core concepts

This document explains the core concepts we use at Idura: Tenants, Applications, Domains, and eID Providers.

To illustrate how everything fits together, we will use a fictitious company called Acme Corporation. They are building both a web application and a mobile application, and they want their users to be able to log in with Swedish BankID and Danish MitID.

​
Tenants

Sign up for a free account at Idura if you'd like to explore the dashboard as you read. For step-by-step instructions, follow our Dashboard setup guide.

In Idura, a tenant is the logical isolation unit that separates your company's data from all other Idura customers. You create a tenant when you first sign up for an account. It represents your organization's private environment at Idura where all your applications and domains are created and contained. No other company can access your tenant's data, and vice versa.

Test vs. Production environments

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

Tenant characteristics

  • The tenant name must be unique. It serves primarily for your reference and carries no formal significance.
  • You can create as many tenants as you need. For instance, if you have multiple teams working on different environments (e.g., Development vs. Production), you can create separate tenants for each team. To do so, go to the upper-left corner of the Dashboard and click on your current tenant name to display the dropdown menu. Then, click New tenant.

​
Applications

An Idura Application represents the actual software that will use our services to perform authentication. We use the term application as defined in the client role in OAuth 2.0.

When an application is registered in Idura, it is assigned a unique client ID (and, if applicable, a client secret).

  • client ID: A unique alphanumeric string used to identify your application when it makes authentication requests to Idura. You can use our default format (e.g., urn:my:application:identifier:6765) or change it to your preference. Note: While you can change your client ID later, doing so requires that you simultaneously update this value in your application's source code. Otherwise, your application's authentication will stop working.
  • client secret: If your application uses a backchannel flow (such as the Authorization Code flow), it also receives a client secret. Think of it as your application's password: it must be kept confidential at all times. If anyone gains access to it, they can impersonate your application and access protected resources.

For maximum security in production, we recommend moving away from client secret authentication and replacing it with safer alternatives:

Learn more in our OpenID Connect security best practices guide.

In our example, Acme Corporation has two apps: a web app (running on a server) and a native mobile app. They will therefore register two separate Idura applications: one for the web app, and one for the mobile app.

Different apps require different authorization flows

The two applications use different authorization flows because of their different tech stacks and security requirements.

  • The web app can use the Authorization Code flow, which requires a client secret and is suitable for server-side applications.
  • The mobile app must use the PKCE flow, which does not require a client secret and is designed for public clients.

For more information, see Authorization flows reference.

​
Domains

Your application needs a dedicated web address where end users are sent to log in, and where your application communicates with Idura. This address is your Idura domain.

Domains are registered for either Test or Production environment and determine whether you can log in using test user identities or real eID accounts. As such, the domain is the key distinction between your Test and Production environments.

Note: To set up a Production domain, you must upgrade your free subscription to a paid tier.

A test domain registered by Acme Corporation will typically look something like acme-corp-test.idura.broker.

​
Bring your own domain

For development and testing, it is usually sufficient to use the preconfigured idura.broker top-level domain. For Production, we recommend mapping your own custom domain (e.g., login.acme-corp.com) to point to Idura Verify. It allows you to build trust with your users, as they won't have to leave the realm of your application and interact with a third-party domain to log in.

Setting up your own domain for Production requires access to your company's DNS records and an SSL certificate.

​
eID Providers

eID Providers are the actual identity services that authenticate your users (such as Swedish BankID, Danish MitID, or Norwegian BankID). Idura Verify acts as an abstraction layer, sitting between your application and eID providers, so you don't have to worry about implementation changes of every specific eID.

Each eID Provider can be shared across multiple applications. You may use all available eID Providers for all your applications.

eID Providers are automatically configured and ready to use on your Test domains.

To use an eID Provider in Production, you must enter into a formal agreement with the provider. In most cases, Idura handles this process for you, though some countries require direct agreements. For more information, see our Moving to Production guide.