Registering your application

Before integrating with Truora Pass you need to register your application and obtain credentials. Registration is self-serve through the Truora Pass Dashboard at https://dashboard.pass.truora.com.

Create your application

  1. Sign in to your Truora account first — at https://account.truora.com. The Pass dashboard has no sign-in screen of its own — it reuses your existing Truora session from the account host.
  2. Open the dashboard at https://dashboard.pass.truora.com. You land on the list of your OAuth2 applications (empty the first time).
  3. Click + New Application.
  4. Fill in the application form — see the field reference below.
  5. Click create. The dashboard then shows your credentials exactly once, under the heading “Important: Save your client secret”: “This is the only time you’ll see the client secret. Make sure to copy and store it securely.” The screen shows your Client ID and Client Secret with show/hide and copy controls — copy both and store the secret in a secrets manager before leaving the page.

Note: The dashboard inherits your session from the account host (account.truora.com). If you open the dashboard without an active session there, loading your applications fails with an Unauthorized error and you are sent back to the account sign-in — sign in there, then return to the dashboard.

Application form fields

Field Required Description and constraints
Application Name Yes Human-readable name of your application, shown to users on the consent screen.
Description No Internal description — not shown to your users.
Redirect URIs Yes Between 1 and 10 absolute https URLs — plain http is accepted only for loopback hosts (localhost, 127.0.0.1, ::1) during development. Entered as a chip list — “The URIs where users will be redirected after authorization”. The redirect_uri in every authorize request and token exchange must exactly match one of them.
Scopes Yes The scopes your application is allowed to request — at least one; openid is always included. Every scope in an authorize request must be registered here. See the Scopes reference.
Allowed Email Domains No “Restrict sign-ups and logins to specific email domains. Leave empty to allow all.”
Enable JavaScript Client No Enables the embedded SDK flow (allows_web_message). Turning it on reveals the Authorized JavaScript origins field.
Authorized JavaScript origins Only with the JavaScript client The web origins allowed to embed Truora Pass (allowed_web_message_origins). Origin only — scheme + host, no path. Required for the embedded SDK flow: the origin of the redirect_uri used in an embedded request must be in this list.
Minimum Assurance Level No Minimum authentication strength users must meet (minimum_acr): None, urn:truora:acr:1 (single factor), urn:truora:acr:2 (strong single factor — passkey), or urn:truora:acr:3 (multi-factor + biometric).
Maximum Authentication Age No Maximum age of the user’s Truora Pass session before re-authentication is required, in seconds (max_auth_age). Up to 2592000 (30 days); empty or 0 means no policy.

Your credentials

Credential Format Handling
client_id Prefixed WLT_APP_... Public identifier of your application; appears in authorize URLs.
client_secret Random string, generated at creation Shown exactly once at creation — only a hash is stored afterwards. Save it in a secrets manager immediately.

Note: The client_secret must only ever be used from your server (in the body of POST /v1/oauth2/token and POST /v1/oauth2/bc-authorize requests). Never ship it in browser or mobile code.

If you lose your client secret

The client_secret is shown only once, and only a hash of it is stored — it cannot be displayed again, and there is no regenerate action, in the dashboard or otherwise. Where the dashboard’s application-details screen mentions regenerating a lost secret, the way to do that today is the process below. If the secret is lost or exposed:

  1. Delete the application in the dashboard and create a new one (self-serve — you get a new client_id and client_secret), or
  2. Contact Truora.

Grant types

Grant types are not part of the dashboard form. Every application uses the authorization_code grant by default, and a refresh token is issued with every code exchange — no extra registration is needed to redeem it. To enable the CIBA grant (urn:openid:params:grant-type:ciba) for the decoupled flow, contact your Truora contact or account manager.

What to prepare per integration flow

Redirect (Authorization Code flow)

Fully self-serve in the dashboard:

  • The Redirect URIs your application will receive callbacks on (HTTPS URLs on your domain).
  • The Scopes you plan to request.
  • No extra grant types needed — authorization_code is the default.

Embedded SDK (web_message)

Everything from the redirect flow, plus — also self-serve in the dashboard:

  • Enable JavaScript Client turned on (allows_web_message).
  • Authorized JavaScript origins listing every origin (scheme + host, no path) of the pages that will embed Truora Pass — the redirect_uri you pass to the SDK must have its origin in this list.

Decoupled (CIBA flow)

  • The urn:openid:params:grant-type:ciba grant type — contact your Truora contact or account manager to enable it. A CIBA-only application registered by Truora may omit redirect URIs entirely — there is no browser callback in this flow.

Editing your application

You can edit an application later from the dashboard at /applications/:id/edit — the same fields as at creation, plus an Active toggle — and delete it from the dashboard as well.

Next step

With your client_id and client_secret in hand, follow the Authorization Code flow guide for the canonical end-to-end integration, or see Getting started to pick the flow that fits your product.