Identity Server Options

Database Options

The Identity Server needs to be connected to a PostgreSQL-compatible database. Details for the form of the URI can be found in the PostgreSQL documentation.

  • is.database-uri: Database connection URI
  • Read-Only database connection URI

Email Options

The Identity Server can be configured with different providers for sending emails. Currently the sendgrid and smtp providers are implemented.

  • Email provider to use

When sendgrid is used as provider, an API key is required. For testing, use the sandbox to prevent emails from actually being sent.

  • The SendGrid API key to use
  • Use SendGrid sandbox mode for testing

When smtp is used as provider, provide the address of the SMTP server (host:port), as well as the username and password for the SMTP server.

  • SMTP server address
  • Username to authenticate with
  • Password to authenticate with
  • Maximum number of connections to the SMTP server

The email address and name of the sender should be configured regardless of the provider that is used.

  • The address of the sender
  • The name of the sender

Most emails contain the name of the network and links to the Identity Server or Console.

  • The name of the network
  • The URL of the Identity Server
  • The URL of the Console

Although The Things Stack comes with a number of builtin email templates, it is possible to override those with custom templates. You can specify the source where to load templates from, and options for that source. For more information on email templates, see the email templates reference.

  • Source of the email template files (directory, url, blob)
  • Directory on the filesystem where email templates are located
  • URL where email templates are located
  • Bucket where email templates are located
  • Path within the bucket.

If your custom templates rely on other files, such as headers or footers, those files need to be included.

  • The email templates that will be preloaded on startup

OAuth UI Options

The OAuth user interface needs to be configured with at least the canonical URL and the base URL of the Identity Server’s HTTP API. The canonical URL needs to be the full URL of the UI, and looks like The base URL of the Identity Server’s HTTP API looks like

  • is.oauth.ui.canonical-url: The page canonical URL
  • Base URL to the HTTP API

If you do not want to serve the OAuth user interface on /oauth, you may customize the mount path.

  • is.oauth.mount: Path on the server where the OAuth server will be served

If page assets for the OAuth UI are served from a CDN or on a different path on the server, the base URL needs to be customized as well. If you want to customize the branding of the OAuth UI, you can set the base URL for where your branding assets are located.

  • is.oauth.ui.assets-base-url: The base URL to the page assets
  • is.oauth.ui.branding-base-url: The base URL to the branding assets
  • is.oauth.ui.branding-cluster-id: The cluster ID to show below the logo
  • is.oauth.ui.branding-text: The branding text to show below the logo

The appearance of The Things Stack can optionally be customized.

  • The site name
  • is.oauth.ui.title: The page title
  • is.oauth.ui.sub-title: The page sub-title
  • is.oauth.ui.descriptions: The page description
  • is.oauth.ui.language: The page language
  • is.oauth.ui.theme-color: The page theme color

Further customization of the CSS files, JS files and icons is also possible:

  • is.oauth.ui.css-file: The names of the CSS files
  • is.oauth.ui.js-file: The names of the JS files
  • is.oauth.ui.icon-prefix: The prefix to put before the page icons (favicon.ico, touch-icon.png, og-image.png)

Profile Picture Storage Options

The profile pictures that users upload for their accounts are stored in a blob bucket. The global blob configuration is used for this. In addition to those options, specify the name of the bucket and the public URL to the bucket.

  • is.profile-picture.bucket: Bucket used for storing profile pictures
  • is.profile-picture.bucket-url: Base URL for public bucket access

It is also possible to disable uploads:

  • is.profile-picture.disable-upload: Disable profile picture uploads

It is also possible to use Gravatar for profile pictures.

  • is.profile-picture.use-gravatar: Use Gravatar fallback for users without profile picture

End Device Picture Storage Options

Similar to profile pictures, end devices can have pictures associated with them.

  • is.end-device-picture.bucket: Bucket used for storing end device pictures
  • is.end-device-picture.bucket-url: Base URL for public bucket access

It is also possible to disable uploads:

  • is.end-device-picture.disable-upload: Disable end device picture uploads

User Registration Options

By default, users can register their own user accounts. User accounts can also be registered by admin users in the network. The user registration process can be customized by requiring approval by admin users, requiring email validation or by requiring new users to be invited by existing users.

  • is.user-registration.enabled: Enable user registration. If user registration is disabled, admin users can still create users. New in 3.11
  • is.user-registration.admin-approval.required: Require admin approval for new users
  • Require contact info validation for new users
  • is.user-registration.invitation.required: Require invitations for new users
  • is.user-registration.invitation.token-ttl: TTL of user invitation tokens

There are several options to customize the requirements for user passwords.

  • is.user-registration.password-requirements.max-length: Maximum password length
  • is.user-registration.password-requirements.min-digits: Minimum number of digits
  • is.user-registration.password-requirements.min-length: Minimum password length
  • is.user-registration.password-requirements.min-special: Minimum number of special characters
  • is.user-registration.password-requirements.min-uppercase: Minimum number of uppercase letters

User Rights Options

By default users can create applications, gateways, organizations and OAuth clients. With the following configuration options it is possible to restrict this, in which case only admin users are allowed to create these entities. By adding users to organizations, and assigning the appropriate rights, they can still create these entities in the organization.

  • is.user-rights.create-applications: Allow non-admin users to create applications in their user account
  • is.user-rights.create-clients: Allow non-admin users to create OAuth clients in their user account
  • is.user-rights.create-gateways: Allow non-admin users to create gateways in their user account
  • is.user-rights.create-organizations: Allow non-admin users to create organizations in their user account

Admin Rights Options New in 3.10.6

By default admins are granted almost all rights on all entities in the network. The default configuration does not allow admins to read secrets, such as the root keys of end devices, and the CUPS/LNS secrets of gateways. This also means that admins can not assign those rights to others. The following option can be used to grant admin users all possible rights.

  • is.admin-rights.all: Grant all rights to admins, including _KEYS and _ALL

Gateway Secrets Encryption Options New in 3.10

  • is.gateways.encryption-key-id: ID of the key used to encrypt gateway secrets at rest.

Tenant Administration Options

In multi-tenant deployments, tenants are managed with “tenant admin keys”. These keys need to be configured in the Identity Server.

  • is.tenancy.admin-keys: Keys that can be used for tenant administration (16, 24 or 32 hex-encoded bytes)